Date: Wed, 10 Jan 1996 05:29:58 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Good News :) Message-ID: <199601101029.FAA28904@hda.com> In-Reply-To: <199601092249.XAA01300@uriah.heep.sax.de> from "J Wunsch" at Jan 9, 96 11:49:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. > [LKMs] > > > But don't forget some people may have more than one > > CD-R, though I don't know if they'll need more than one "personality" > > loaded at once. > > Hmm. Well, i think it's unrealistic to drive multiple burners at > once. So, a single loaded module might suffice? I don't know the economics of the situation. But someone might need to burn two or three of the same disk in parallel (read-disk write-rom0 ... write-romn). Also, if things were working perfectly you might be burning a disk on the Plasma Torch and evaluating a new unit. > My current ideas are about these: > > . think about refining the structure of worm(4) > > . create an ioctl interface of WORM* commands, that allow to prepare > the drive for a burning process, perform the `fixation' etc.; the > device-dependant part of this ioctl might be laid out as an LKM, > perhaps dispatched by a switch table (for more than one worm device) 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 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. "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. The easiest thing to do now is hardwire things in with an eye toward making it work via LKM. > . the first write(2) after all parameters have been set should ``open > the write channel'' (read: prepare a new track on the CD-R); this > eliminates any timing problems between the ioctl's and the actual > write, only the sequence of all following writes must be tight > > . i'm not sure when to close the write channel: at special request? > at close(2) time? this is done by a SYNCHRONIZE CACHE command > > . the `fixation' is independent of the tight write cycles and could be > performed separately (this includes writing a TOC, and making the > CD-R recognizable for CD readers) > > . the ioctl should be wired to the outside world by a wormcontrol(8) > command (cmp. the wormcontrol(8)) > > . it might be convenient to create something like cdwrite(1) that > wraps all necessary pieces together, consisting of some calls to > wormcontrol(8), and the rtprio/team/dd pipeline to actually dump the > data to the disk 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. Then the sequence is "wormcontrol setup"... "dd write"... "wormcontrol fixate". > . perhaps the driver should also `clone' the cd(4) driver, in order to > allow read operations; i don't care very much about this. Interest- > ing detail: the device announces itself either as type 4 or 5, > depending on the medium. This might force us to either collect a > table of all recognized CD burners, forcing them to belong to the > worm driver, or find some better-suited method (no idea on this > however). Or attach the device twice to two separate drivers. There may be locking issues here. > > An aside - one thing I'll point out is it would be easy to hack > > scsi(8) to spit out a C code interface for one of its command strings. > > I don't know if that is of interest or not. > > I'm not yet sure if i would need it. For the kernel code, it seems > that i could understand it well enough to know what has to be > done. :-) I know you won't need it - it is attractive to have a minimal specification for commands to make it easy to change interfaces. Plus you've tested with scsi(8) - it would be nice to then throw the "-S" switch. Assuming you elect to move all commands into the kernel. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601101029.FAA28904>