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

[D. Hazelton]

On Friday 10 February 2006 08:25, Dmitry Torokhov wrote:
> On 2/10/06, Joerg Schilling <schilling@xxxxxxxxxxxxxxxxxxx> wrote:
> > "D. Hazelton" <dhazelton@xxxxxxxxx> wrote:
> > > And does cdrecord even need libscg anymore? From having actually gone
> > > through your code, Joerg, I can tell you that it does serve a larger
> > > purpose. But at this point I have to ask - besides cdrecord and a few
> > > other _COMPACT_ _DISC_ writing programs, does _ANYONE_ use libscg? Is
> > > it ever used to access any other devices that are either SCSI or use a
> > > SCSI command protocol (like ATAPI)?  My point there is that you have a
> > > wonderful library, but despite your wishes, there is no proof that it
> > > is ever used for anything except writing/ripping CD's.
> >
> > Name a single program (not using libscg) that implements user space SCSI
> > and runs on as many platforms as cdrecord/libscg does.
>
> Joerg,
>
> Please name a single program/package besides cdrtools that is using
> libscg. Face it, you created and maintained a very decent CD writing
> program but world domination is a bit out of reach.

Exactly.

He has done exactly that, but since then the world has moved on and he refuses 
to see the truth.

Joerg - Lieber gott in himmel! You probably missed 90% of my argument anyway. 
So here it is encapsulated:

Userspace does not define kernel semantics or facilities. Standards do that, 
and where standards are lacking, the kernel has to provide what it can.

Now before you go off and start screaming about the SCSI spec, be aware that I 
_HAVE_ _READ_ _THEM_ and nowhere do I see it stated that the kernel has to 
export the SCSI transport layers internal numbering to userspace. All I have 
seen is that the SCSI system uses a "Host/Bus/Target/Lun" identification 
system internally. As someone else pointed out, /dev/sr* can be used for 
writing CD's with the SG_IO system since the same transport code sits under 
said device as all other block devices. This means that if a program wants to 
write to the device identified by /dev/sr0 or /dev/hda the kernel knows which 
HOST/BUS/TARGET/LUN is meant by it. No need to artificially provide those 
identifiers.

As someone else also pointed out, your code doesn't map devices in a sane 
manner. BTL mapping can change with hotplug, and all your arguments about 
st_dev are bullshit. From reading the spec you pointed at it seems that 
st_dev points to the _underlying_ _device_ - which will be stable despite 
everything.

Understood?

And before I go, let me reiterate a true statement someone else said:
libscg is not the problem - it is the backend. If you _need_ said BTL 
mappings, why can't cdrecord take the provide /dev/hd* or /dev/sr* and 
translate it internally into the BTL mapping you need?

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