Hi,

	Sorry to potentially waste bandwidth but I'd like to know if
there is a group/list of persons to whom I can address some technical
and style issues relating to my attempts to create a device driver for
ATAPI (in particular CD-ROM) devices.  ATAPI is essentially the same
interface as ATA (==IDE hence I'm using the wd driver plus my own
extensions) but all requests are via the new ATA packet command (0xA0)
hotly followed by the real ATAPI command itself sent as 12 bytes of
data to the device.

	The questions can be summarised as follows (apologies for
blatent naivete, but you've got to start sometime):

	+ I am a bit lost as to how read() is directed into the
kernel.  I get the ioctl() DIOCGPART (which I have punted) followed by
at least one request for 2048 bytes (BLKDEV_IOSIZE??) for the block
device, or the read does nothing bar return EINVAL for the raw device.

	+ Partly because I can't do a read() yet, I'm slightly lost as
to how to return some kinds of data, notably probing for device
information.  I can do an ioctl() to ask for say, the error state of
the device (REQUEST SENSE).  But, given that this will require the
device to interrupt back with the data, how do I synchronise the user
process with the return of data?  I was thinking that a second ioctl()
call to return the data, perhaps?  Even then, what if the device is
slow in returning?  I really need to have the user process block until
I have the data to hand.

	+ This follows onto a style question.  ATAPI devices return x
bytes of data on each interrupt (not guaranteed to be what you asked
for, unfortunately).  The Linux driver tries to buffer the data
locally, subsequently satifying reads from the local buffer first.  Is
this a good idea?

	+ ATAPI devices allow overlapping commands, ie I can ask for a
READ to return immediately the command is read, and whilst the device
is off hunting for the block, I can ask for, say, INQUIRY data, which
itself can return arbitrary amounts of data.  Should I be flushing
these through separate data channels (ie buffer them locally but
separately)?

	+ After transferring all it's data the ATAPI device returns a
final interrupt asking that the status of the device be read.  Up til
now I have been creating a dummy buf so that the interrupt routine has
something to manage.  This `end of command' buf, however, gets in the
way of any data bufs (further, the status appears to be dropped in the
ATA driver).  The information is handy - that said I'm not sure how to
use it in readiness for the next request.  The user might want to ask
for the last command's status, for example (another ioctl() perhaps?).
Any thoughts?


	Thanks for your time.  If I've failed to explain something,
let me know.

Cheers,

	Ian

-------------------------------------------------------------------------------
      Ian Fitchet			I.D.Fitchet@fulcrum.co.uk
  Fujitsu Telecommunications Europe ltd., Birmingham Business Park, B37 7YU