On Sun, Jul 14, 2002 at 04:35:02PM +0200, Adrian Bunk wrote:
> On Sun, 14 Jul 2002, Joerg Schilling wrote:
> >...
> > If a CD-ROM does not support ATAPI, you are not able to
> >
> > - open/close/lock the door.
>
> Look at drivers/cdrom/mcdx.c, a driver for proprietary (the device is
> connected via an ISA card to the computer) single and double speed Mitsumi
> CD-ROM drives. This driver supports to open the door although the drive
> definitely doesn't support ATAPI...
...nor is it an IDE(ATA) device which this discussion is about.
BTW, I consider this discussion ridiculous and I wonder whether Iäm the only
one:
Jörg, HPA and some others want to stick to the current SCSI high-level
drivers and offer more flexible transport (and to a certain extent
command) layer below. Other people are scared of some of the uglinesses of
today's SCSI code and want to offer general high-level driver (that they do
not call SCSI) with some flexible command and tranport layer below.
It's more a question of how you name it then of technical details.
And maybe in how far you allow current software (which is tailored well to
deal with our current SCSI code) to work with the future solution.
A good portion of the current SCSI midlayer code would be eliminated or
changed anyway, no matter how you call it
Given the love of Linus for the SCSI code, I would suggest not to name it
SCSI any more, but rather generic block code. I also matches reality
somewhat better.
But what we need to do then is to offer a generic interface (similar to sg)
to send down commands to the devices. Otherwise, we'd break scanners,
CD-Writers, ... which currently rely on this interface. And as we don't want
to have kernel drivers for all those, there's no alternative.
(And it should be sg like, otherwise we put a lot of load on application
developers such as Jörg, which I would call bad policy.)
Device management software will certainly also want to speak to the devices
via some exposed low-level interface, BTW. Maybe we can expose enough
information via driverfs to solve the naming stuff reasonably, i.e. allow
naming by topology, device and content, but still some things will and
should not be done in kernel space.
sg does most of this for 'real' and 'fake' (ATAPI,usb-storage,sbp2) nowadays
pretty well and we should not just scratch that because another idea looks
very sexy.
Groetjes,
-- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE Linux AG, Nuernberg, DE SCSI, Security
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:27 EST