Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

From: Stephan von Krawczynski
Date: Sun Aug 08 2004 - 06:16:25 EST


On Fri, 6 Aug 2004 22:47:46 +0000 (UTC)
hpa@xxxxxxxxx (H. Peter Anvin) wrote:

> Followup to: <20040806175937.GA296@xxxxxx>
> By author: Vojtech Pavlik <vojtech@xxxxxxx>
> In newsgroup: linux.dev.kernel
> > >
> > > If you do not fix this, you just verify that Linux does not like it's
> > > users. Linux users like to call cdrecord -scanbus and they like to see
> > > _all_ SCSI devices from a single call to cdrecord. The fact that the
> > > Linux kernel does not return instance numbers for /dev/hd* SCSI devices
> > > makes it impossible to implement a unique address space :-(
> >
> > I'm a long time Linux and cdrecord user, and I must say I always hated
> > the -scanbus thingy. It's so much easier to just pass the /dev/hdc
> > device node, where I _know_ my CD burner lives than to have to figure
> > out what fake SCSI address cdrecord has made up and requires me to pass
> > to it, even when I have just a single CD burner in my system.
> >
>
> Indeed. To a first order it doesn't matter if the default system
> namespace is crappy -- applications inventing its own namespaces
> (usually inconsistently) means that it's IMPOSSIBLE to make all
> applications do the same thing - which is actually more important to
> make them all do "the right thing." Furthermore, it blocks
> improvements such as udev.
>
> Note there is nothing that says cdrecord -scanbus can't print out
> a list, using the system device names.
>

To add a pure users' comment to the story:

Maybe you should not overestimate cdrecord as a tool (like its author obviously
does sometimes). At least for DVD there are well-working alternatives.

If Joerg feels a better home on Solaris, so be it. It's his right to decide for
solaris, just as it is a users' right to decide against cdrecord.


Regards,
Stephan
-
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/