Date: Wed, 10 Jan 1996 23:40:31 +0100 (MET) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@FreeBSD.ORG Subject: Re: Good News :) Message-ID: <199601102240.XAA07466@uriah.heep.sax.de> In-Reply-To: <199601101029.FAA28904@hda.com> from "Peter Dufault" at Jan 10, 96 05:29:58 am
next in thread | previous in thread | raw e-mail | index | archive | help
As Peter Dufault wrote: > > > Peter, i owe you a frame of German beer for providing us with scsi(3) > > and scsi(8). Without them, it would have been much harder to get this > > proof of concept running! > > Share some with your boss for evidently hiring you at least part > time to work on FreeBSD. Next time I'm in Dresden (Well, first time > I'm in Dresden) I'll collect in person. Well, i don't even know whether he drinks beer. :) I'm not really paid for my work on FreeBSD (except where it comes to customers), but there's an ``overlap of interests'', and to the very least, he didn't look angry after mis-burning three CD-R's. ;-) > You can evaluate moving ioctl calls into the kernel versus doing > them with scsi(8). It will be invisible to the end user since you > anticipate a wormcontrol anyway. You may find that there are few Right. > enough differences in the actual write transfer that a flag field > settable either via ioctl or as part of config is all that is needed > in the driver to support the data transfer to the different worms. A write seems to be just a write. Even the Linux cdwrite does appear to use write(2) for the actual data transfer. The differences are in the command sequence before and after the write. > "scsi_device_register" can add a new device in an LKM init entry > point, and then you must either reprobe the bus or poke around in > the unknown devices for any we should adopt. This needs more work. Hmm, our reprobing is still broken. It turns on adapter polling, which causes it to hang when used on a PCI adapter. Anybody keen to revamp it? I think it requires minor changes (the functions that are responsible for the bus probing must get passed an argument that tells whether this is at system initialization time or not), but they have to be done throughout the entire SCSI code. > When to close the write channel: It depends on whether this is > time critical or not. If it isn't time critical close(2) > is good. Opening the write channel during open and closing the > write channel during close sounds intuitive. It is time critical. Perhaps it should be done inside close(2) anyway. The sequence of write(2)'s is not less time critical, and there's no particular reason why the writing program (dd or team) should be allowed to defer the final close(2) much more than all the write's. Opening the write channel with open(2) doesn't seem to be that good, since we also have to open it in order to prepare the medium. Well, thinking more about it, we could do it just when opening the `real' device, while all ioctl's will be done via the control device (so the worm_open() is never being called for them). worm_open() could also reject an open intend on a non-prepared disk. (Btw., Julian, devfs is missing all the SCSI control devices. Ya' know, those funny thingies with the 0x20000000 bit set in the minor number.) > Then the sequence is "wormcontrol setup"... "dd write"... > "wormcontrol fixate". Yup. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601102240.XAA07466>