lkml.org 
[lkml]   [2006]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: CD writing in future Linux (stirring up a hornets' nest)
Date
On Friday 10 February 2006 08:25, Dmitry Torokhov wrote:
> On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > "D. Hazelton" <dhazelton@enter.net> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-11 04:42    [from the cache]
©2003-2011 Jasper Spaans