Date: Mon, 19 May 1997 17:45:16 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Cc: henrich@crh.cl.msu.edu (Charles Henrich) Subject: Re: scsi library interface Message-ID: <19970519174516.AT53845@uriah.heep.sax.de> In-Reply-To: <19970519110533.07999@crh.cl.msu.edu>; from Charles Henrich on May 19, 1997 11:05:33 -0400 References: <19970518184034.10726@crh.cl.msu.edu> <19970519103618.LH45116@uriah.heep.sax.de> <19970519110533.07999@crh.cl.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
As Charles Henrich wrote: > Then why is it when you start sending raw SCSI read commands to > rcd0.ctl behind which lives a Toshiba, you explode the SCSI bus, yet > if you send them to /dev/cd0c things appear to work? (And with a > plextor, both work!) There is not much difference between both when it comes to passing down raw SCSI commands. They are caught by the upper layers of the SCSI driver and never passed down to the type driver. If you see a difference, it probably means you don't initialize the device correctly. Opening a regular device causes a series of actions like checking for the device being ready, sending a START UNIT command etc., whereas opening the control devices causes nothing of this. Needless to say, no userland program is meant to issue READ or WRITE commands to a CD-ROM drive at all... I would be much more happy if you would think about integrating all this into the type drivers. I've already exchanged a few ideas with Jean-Marc Zucchoni lately, who became very active on the CD-R front. Reading and writing devices in userland when there's a real device driver for it violates the layering principles. Things like jitter correction don't belong in the kernel however. Either you've got a ``good'' device, then you can copy the data with dd(1), or you don't, then you still need cdd(1) doing the error correction for you (but not doing the actual read/write). NB: the above is an ideal picture, and the ultimate goal for the future. It's not immediately reachable, see also my recent discussion about the bogus field b_blkno in the struct buf (it needs to become a b_offset in order to cope with block sizes that are not a power of 2 multiple of 512). -- 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?19970519174516.AT53845>