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

[Bill Davidsen <davidsen@tmr.com>]

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/