Skip site navigation (1)Skip section navigation (2)
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>