lkml.org 
[lkml]   [2006]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: CD writing in future Linux (stirring up a hornets' nest)
    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/

    \
     
     \ /
      Last update: 2006-02-13 13:10    [W:3.694 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site