Re: Cdrtools-2.01a25 ready
>From: Andy Polyakov <appro@fy.chalmers.se>
>> - Try to support the half hearted and badly designed /dev/hd* interface
>> from Linux-2.6 in a more usable way.
>>
>> Note: The Bus mapping function inside the kernel for this interface is
>> a dummy. For this reason, we need to do the mapping ourself.
>> Busnummer is ("/dev/hd*"[7] - 'a') / 2
>> Lun is ("/dev/hd*"[7] - 'a') % 2
> ^^^ Typo?
Yes, thank you this should be "target".
>> Adding SCSI transport to something like /dev/hd*
>Pass-through SG_IO (interface is question) is not specific to /dev/hd*.
>In other words it's not an "/dev/hd* interface" or an IDE-specific hack,
If you previously did write correct code for the Linux /dev/sg* interface, you
should know better.
The fact that the interfaces share a single common ioctl() does not make
them equal.
Even before 2.01a25, I was forced to introduce significant changes on the
adaption code in scsi-linux-sg.c to make it possible that dev=/dev/hdc may
be used. If you like to use /dev/sg* correctly, you need to do things you
are not allowed to do with /dev/hd*
>but a road-map if you wish. Because the idea is to use "tangible" block
>device entries with *all* recorders, not only IDE units. Note that SCSI
>command-level programming through "tangible" block device not some
>Linux-specific novelty, but widely accepted implementation strategy.
Not correct: the most widely spread interface implementation strategy is
to support generic SCSI transport. This is a level _below_ the block device
layer.
>> on an OS that includes
>> a generic SCSI transport driver is disregarding SCSI protocol layering.
>It's rather contrary. It's not disregarding SCSI protocol layering, but
>affirming it by putting applications to the level they naturally belongs
>in. Layers lower than SCSI command block is pure kernel domain. Generic
Definitely wrong.
The UNIX device interface does not allow devices like CD-writers, scanners
and similar to be inplemented in a way that stands more than a year.
Even formatting disks is nothing that may be implemented cleanly inside a
block device driver. For this reson, the kind of code that support
CD writing scanning and similar belongs into user space.
As CD writing and scanning is a user space task, applications that
support these tasks should use the highest possible protocol layer that
may be implemented in a stable (over the time) and device independent
way. Cdrecord and libscg just follow this strategy.
The highest possible protocol layer is the generic SCSI transport layer.
It should be obvious that the naming scheme used by the generic SCSI
transport implementation should only be bound to this layer and not
depend on layers like the block device layer.
Do you really like a scanner support software to open() a block device
node? If you do, please tell me which!
>SCSI should be used with targets which are not controlled by any other
>kernel driver. Preferably generic SCSI should not even hook up all the
>targets, but only those explicitly pointed out (pretty much the way it's
Why do you like to force people to be unable to use a unique and orhogonal
way of accessing SCSI?
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Reply to: