Date: Tue, 9 Jan 1996 23:49:15 +0100 (MET) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@FreeBSD.org Subject: Re: Good News :) Message-ID: <199601092249.XAA01300@uriah.heep.sax.de> In-Reply-To: <199601091105.GAA25461@hda.com> from "Peter Dufault" at Jan 9, 96 06:05:33 am
next in thread | previous in thread | raw e-mail | index | archive | help
As Peter Dufault wrote: > > Eventually I'd like the system to schedule I/O requests > based on the rtprio priority. I have a scratch kernel around > that prefers rtprio requests to normal ones. It makes xcdplayer > snappy. Sounds interesting. Anyway, see my more detailed posting today, the system seems to be up to the task already. > One problem with scsi(3) and therefore scsi(8) is these don't use the > start queue and so you'll get the latency to resume each process even > with a "team" approach to running scsi(8). The scsi(8) invocations aren't time-critical. Well, the final one is (the SYNCHRONISE CACHE), since it tells the drive that the write process has finished now, and there's no longer a need to complain about a buffer underrun. The actual write is finally done by write(2) anyway. Unlike Linux' cdwrite, i refuse to re-invent the wheel. (cdwrite has at least 200 lines of code that perform a task similar to dd(1) or team(1).) > I assume you're doing some combination of scsi(8) scripts to setup > then some "team" dd incantations to transfer the data to the CD-R? You're assuming right. :) See my recent posting. 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! [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? 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) . 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 cdcontrol(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 . 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). > 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. :-) Another idea would be to create a ``worm description language''. It's a bit hard however, without having access to all possibly supported devices (and their manuals). > > Who is interested in dicussing further issues of the concept (once > > i've got further)? Should i do this in this list? > > If no one else chimes in we'll take it off line. Many people expressed their interest in personal email. I think we should best keep it in this list here, and all interested parties might subscribe. (Yup, i know about your problems with freebsd-scsi, Peter -- don't care! :) About the drive: the `Plasmon' is an incident. I've just got it since it was the only one available immediately when my ``boss'' went shopping for a CD burner. They don't seem to be uncooperative, but o well, i had to fetch the SCSI manual as an (ick!) m$ word file via a transatlantic phone line from an US BBS. :) The sales/support person answering my email didn't seem to be able to mail me the document, nor does it seem that they ever knew anyone who doesn't like m$ file formats and would have prefered a postscript doc instead. At least, i've annoyed him enough to finally un-protect the originally password protected doc on the BBS. ;) I do know the procedure from Yamaha, and despite of them doing _everything_ different from all other CD-R vendors, they were requesting many silly things from me when i've been asking for a SCSI manual (``What has been your sales volume last year?'' ``How many copies of your software do you estimate to sell?''). Programming a CD-R without a SCSI manual appears to be Russian Roulette. I've misburnt three of them, even _with_ the manual in the back. -- 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?199601092249.XAA01300>