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.206 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site