Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree <matthias.andree@gmx.de>]

Joerg Schilling schrieb am 2006-01-30:

> > >> -	/dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
> > >> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
> > >> As long as this bug is present, there is no way to see SG_IO via
> > >> /dev/hd* as integral part of the Linux SCSI transport concept.
> >
> > Now you're talking shop ;-)
> >
> > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
> > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
> > for bus number, id or lun - independent of OS and/or cdrecord?
> 
> The drive does not return this information, but the SCSI subsystem creates
> these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
> be known to the SCSI sub-system and thus needs to have a SCSI subsystem
> related instance number.

We are talking about ATA and ATAPI drives here. They may use SCSI
commands, but the transport is different. My take is: the Kernel guys
have been refusing to invent a non-native enumeration scheme for
non-SCSI transports, and you have not provided evidence why this is
indispensable.

Why is it a *kernel* task to invent SCSI identifier for a non-SCSI
transport that does not have such identifiers, in addition to the device
name? libscg is already doing it for /dev/hd* and /dev/pg*.
How about USB or Firewire or SATA? Do they have ID or LUN?

Why isn't libscg simply scanning all transports exhaustively (i. e. not
stopping at EPERM) and inventing this itself? You're failing to answer
this questions for week now, even though you agreed resmgr or similar
setups were safe.

How is a user going to tell apart two devices of the same make and model
from -scanbus output? The answer is (s)he cannot.

Sounds unrealistic? Well, some orchestras sell fresh recordings half an
hour after the final chord, with some dozen CD writers...

> Cdrecord is a program that needs to be able to send any SCSI command as 
> it needs to be able to add new vendor unique commands for new drive/feature
> support.

Right, but evidently it does not need the kernel to invent numbering.
dev=/dev/hdc works today.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/