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

[jerome lacoste <jerome.lacoste@gmail.com>]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
[...]
> > My understanding of that is you say to not use dev=/dev/sgc because it
> > isn't stable. Now that you've said that bus,tgt,lun is not stable on
> > Linux (because of a "Linux bug") why is the b,t,l scheme preferred
> > over the /dev/sg* one ?
>
> b,t,l _is_ stable as long as the OS does a reasonable and orthogonal work.
>
> This was true until ~ 2001, when Linux introduced unstable USB handling.
> Note that this fact is not a failure from libscg but from Linux.

This is true if you assume that "stable b,t,l" was an advertised Linux
functionality.
I may be wrong, but I don't think that this was ever the case. It
might just have been a side-effect of the implementation. Anyway,
point #2 is much more important, so let's focus on that:


> > 2) design question:
> >
> > - cdrecord scans then maps the device to the b,t,l scheme.
> > - the libsg uses the b,t,l ids in its interface to perform the operations
> >
> > So now, if cdrecord could have a new option called -scanbusmap that
> > displays the mapping it performs in a way that people can parse the
> > output, I think that will solve most issues.
>
> The output of cdrecord -scanbus is already parsable,

But it doesn't show the OS specific mapping.

> so what is your point?

I am aiming for a compromise.

My point is that people want to use dev=/dev/hdc in their interface,
because that's what they are used to. That's a point that I think you
cannot deny.

If you want to still keep your dev=b,t,l command line interface, just
let the users know how your mapping is done. That will allow a
cdrecord wrapper to first query the mapping, then using this mapping
information and OS specific information (e.g. links) identify the
b,t,l expected by your interface.

That way you have mostly no code change to do. And you keep your b,t,l
naming. Everybody is happy.

I've added something like:

                fprintf(stdout, "%d,%d,%d <= /dev/%s\n",
				first_free_schilly_bus, t, l, token[ID_TOKEN_SUBSYSTEM] );

in scsi-linux-ata.c and it does what I want.

WDYT?

Cheers,

Jerome
-
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/