lkml.org 
[lkml]   [2006]   [Feb]   [10]   [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)
    red brick + atlantaNix wrote:
    > On 25 Jan 2006, Matthias Andree prattled cheerily:
    >
    >>Jens Axboe wrote:


    >>Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather
    >>complicated and non-portable. I understand that applications that can just
    >>open every device and send SCSI INQUIRY might want to do that on Linux, too.
    >
    >
    > Applications (already) do this by asking HAL, which can be informed of
    > new devices in a variety of ways: the up-and-coming one is for the
    > kernel to notify udevd, following which a udev rule sends a dbus message
    > to HAL. Everything from the dbus message on up is cross-OS portable.
    > -scanbus is *totally* unnecessary.

    I notice that the first thing people suggest is to make things like
    udev, hal and sysfs required instead of optional to do something as
    simple as burn a CD. As I mentioned before, if the kernel provided a
    list of devices then applications wouldn't break every time a new kernel
    came out which needs a new this, and new that, and a few new other
    support things.

    The kernel could provide a list of devices by category. It doesn't have
    to name them, run scripts, give descriptions, or paint them blue. Just a
    list of all block devices, tapes, by major/minor and category (ie.
    block, optical, floppy) would give the application layer a chance to do
    it's own interpretation. HAL is great, but because it's not part of the
    kernel it's also going to suffer from "tracking error" for some changes.
    I find it easier to teach someone to use -scanbus than to explain how to
    make rules for udev.
    >
    > (Furthermore, it fails to work in a quite laughable fashion in the
    > presence of hotpluggable storage media. udev handles giving hotpluggable
    > storage media consistent device names with extreme ease, and tells HAL
    > about them so that users see the new devices appear even if they don't
    > have a clue that /dev even exists.
    >
    > The change that J. Random Nontechnical User will ever run `cdrecord
    > -scanbus' is *nil*, and applications don't run it either because they
    > can't judge between all the devices that are listed to pick the one
    > which is a CD recorder (consider the consequences should they guess
    > wrong!). Instead, they invariably ask for a device name, or, in more
    > recent versions get the info from HAL. HAL knows if something is a CD
    > recorder because its backend, e.g. udev, told it.)
    >
    Worth repeating: I find it easier to teach someone to use -scanbus than
    to explain how to make rules for udev. HAL is the right answer, but *in*
    the kernel, where it will track changes. Since -scanbus tells you a
    device is a CDrecorder, or something else, *any user* is likely to be
    able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices...

    Note: my example of major/minor is just that, almost any presentation
    which showed all devices user applications would normally use, in a well
    defined way, would address the identifications issue.

    --
    bill davidsen <davidsen@tmr.com>
    CTO TMR Associates, Inc
    Doing interesting things with small computers since 1979
    -
    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-10 22:07    [W:0.026 / U:59.456 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site