[lkml]   [2006]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CD writing in future Linux (stirring up a hornets' nest)
    Chris Adams wrote:
    > Once upon a time, Christoph Hellwig <> said:
    >> On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote:
    >>> It would be nice to have one place to go to find burners, and to have
    >>> the model information in that place.
    >> /proc/sys/dev/cdrom/info
    > Which is bad, as it is incomplete and requires the kernel be updated to
    > know about every format just to document them.

    Document them where? In the kernel Documentation directory? I believe
    those strings come back from the drive, as long as the human or
    application can parse them the kernel operationally needs only what you
    mentioned below.
    > Problems with that file:

    The main problem with that file is that it wasn't mentioned several
    years ago... and I hope you aren't even thinking of suggesting any
    changes to something which has been around for years and which
    applications are undoubtedly quietly using.

    A changed version of the same information in /sys would be a better
    solution if changes other than some additions are needed.
    > - What is "drive speed" (no units); also most drives do different speeds
    > for different modes/media.

    Presumably the max speed mechanically possible, in the units of "x"
    which are used to identify both media and burners and have been since
    "2x" was the fast burner.
    > - CD-RW really covers a range of different formats ("high speed" CD-RW
    > is different and IIRC there's also "ultra high speed" CD-RW).
    > - Several formats are missing: DVD-RW DVD+R DVD+RW DVD-DL DVD+DL (at
    > least).
    > - What is the "RAM" format (not "DVD-RAM")? I haven't heard of that.
    > The kernel really only needs to know:
    > - how the drive can control the tray (open/close/lock/change disc)
    > - if the drive can handle rewritable formats (for UDF support)

    CD-RW seems to cover that.
    > Alternately, every known format needs to be added to that file (both
    > read and write support). It also needs to note read and write speeds
    > for each available format.

    Why? The mmc/scsi commands work or don't, the device returns the info in
    the capabilities page if the application can use it, so it doesn't seem
    that the kernel cares, other than the cases you mentioned.
    > Also, that is an annoying to parse format. What if there's a really
    > long text column field like "Can write Blu-Ray HD dual layer v2"?
    > Something under /sys would be better with one value per file, so if you
    > want to burn a DVD-R, you look for /sys/block/*/cdinfo/write/dvd-r;

    Isn't there a problem with having the same device in multiple places?
    Someone posted that there was, but I didn't really get into the details.
    In any case, why is opening dozens of files better than opening one file
    with all of the info. Long names can be abbreviated, complexity in the
    kernel to avoid complexity in the application is bad, particularly when
    humans parse the existing format nicely.

    > maybe that file contains a space separated list of available speeds (so
    > "1 2 4 8"). Also, right now as far as I can see, /sys doesn't present
    > manufacturer, model, and/or serial number info.

    The only applications which care about speeds other than max are already
    reading the capabilities page. Use cdrecord with the "-prcap" options,
    there is a boatload of stuff there. I agree the the three text items are
    useful, and major/minor to map the device to the name actually used in
    /dev, but that data doesn't fit the format well, and might be better
    presented in /sys. Preferably in a human readable format, like
    /proc/scsi/scsi rather than multiple file per device.

    -bill davidsen (
    "The secret to procrastination is to put things off until the
    last possible moment - but no longer" -me

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-02-27 21:25    [W:0.025 / U:1.672 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site