Jan Engelhardt writes:
> Where is the difference between SG_IO-on-hdx and sg0?
It's like the /dev/ttyS* and /dev/cua* situation, where
we also ended up with multiple device files. This is bad.
SG_IO-on-hdx is modern. It properly associates everything
with one device, which you may name as desired.
sg0 is useful for devices that are not disk, tape, or CD.
A decade ago, it was also the proper way to send raw SCSI
commands to other devices. For nasty compatibility reasons,
Linux still assigns /dev/sg* devices for disk, tape, and CD.
>> Where is the difference between SG_IO-on-hdx and sg0?
>
>It's like the /dev/ttyS* and /dev/cua* situation, where
>we also ended up with multiple device files. This is bad.
>
>SG_IO-on-hdx is modern. It properly associates everything
>with one device, which you may name as desired.
Let's analyze a case:
if /dev/sg0 would always be associated with /dev/hda,
/dev/sg1 always with /dev/hdb, no matter if there was actually a
hda/sg0 device present in the system - would that simplify
the problem?
Jan Engelhardt
--
On Wed, Jan 25 2006, Jan Engelhardt wrote:
>
> >> Where is the difference between SG_IO-on-hdx and sg0?
> >
> >It's like the /dev/ttyS* and /dev/cua* situation, where
> >we also ended up with multiple device files. This is bad.
> >
> >SG_IO-on-hdx is modern. It properly associates everything
> >with one device, which you may name as desired.
>
> Let's analyze a case:
> if /dev/sg0 would always be associated with /dev/hda,
> /dev/sg1 always with /dev/hdb, no matter if there was actually a
> hda/sg0 device present in the system - would that simplify
> the problem?
Forget /dev/sg0, it's meaningless and confusing to try and bind two
unrelated names to each other. You want to talk to /dev/hda, use
/dev/hda. Don't try and create a pseudo mapping between the two. That's
also where cdrecord gets it wrong on Linux - you don't need -scanbus. If
users think they do, it's either because Joerg brain washed them or
because they have been used to that bad interface since years ago when
it was unfortunately needed.
--
Jens Axboe
>
>- you don't need -scanbus. If
>users think they do, it's either because Joerg brain washed them or
>because they have been used to that bad interface since years ago when
>it was unfortunately needed.
Now you're unfair.
-scanbus does a nice output of what cdwriters (and other capable devices)
are present. For me, that lists the cd writer and a CF slot from the
multitype usb flash reader.
There's one kind of not-so-advanced linux newbies that just go to walmart,
buy a computer and whack a linux system on it for fun, and they still don't
know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is
usually a nightmare for them, and apart that -scanbus lists scsi
host,id,lun instead of /dev/hd* (don't comment on this kthx), it is
convenient for this sort of users to find out what's available.
So, and what about that compactflash reader? It is subject to dynamic
usb->scsi device association (depending on when you connect it, it may
either become sda, or sdb, or sdc, etc.), and -scanbus yet again provides
some way (albeit not useful, because it lists scsi,id,lun rather than
/dev/sd* - don't comment either) to see where it actually is.
Jan Engelhardt
--
On Wed, Jan 25 2006, Jan Engelhardt wrote:
>
> >
> >- you don't need -scanbus. If
> >users think they do, it's either because Joerg brain washed them or
> >because they have been used to that bad interface since years ago when
> >it was unfortunately needed.
>
> Now you're unfair.
> -scanbus does a nice output of what cdwriters (and other capable devices)
> are present. For me, that lists the cd writer and a CF slot from the
> multitype usb flash reader.
>
> There's one kind of not-so-advanced linux newbies that just go to walmart,
> buy a computer and whack a linux system on it for fun, and they still don't
> know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is
> usually a nightmare for them, and apart that -scanbus lists scsi
> host,id,lun instead of /dev/hd* (don't comment on this kthx), it is
> convenient for this sort of users to find out what's available.
>
> So, and what about that compactflash reader? It is subject to dynamic
> usb->scsi device association (depending on when you connect it, it may
> either become sda, or sdb, or sdc, etc.), and -scanbus yet again provides
> some way (albeit not useful, because it lists scsi,id,lun rather than
> /dev/sd* - don't comment either) to see where it actually is.
You just want the device naming to reflect that. The user should not
need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
likely be using k3b or something graphical though, and just click on his
Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
help do this dynamically even.
If you are using cdrecord on the command line, you are by definition an
advanced user and know how to find out where that writer is.
--
Jens Axboe
Jens Axboe <[email protected]> wrote:
> You just want the device naming to reflect that. The user should not
> need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> likely be using k3b or something graphical though, and just click on his
> Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> help do this dynamically even.
Guess why cdrecord -scanbus is needed.
It serves the need of GUI programs for cdrercord and allows them to retrieve
and list possible drives of interest in a platform independent way.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
El Wed, 25 Jan 2006 16:13:46 +0100 (MET),
Jan Engelhardt <[email protected]> escribi?:
> There's one kind of not-so-advanced linux newbies that just go to walmart,
> buy a computer and whack a linux system on it for fun, and they still don't
> know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is
> usually a nightmare for them, and apart that -scanbus lists scsi
> host,id,lun instead of /dev/hd* (don't comment on this kthx), it is
> convenient for this sort of users to find out what's available.
Wait - Looking at dmesg is a nightmare for newbies, but cdrecord -scanbus
is not?
Users should be show the available devices in a pretty GUI and for that to
be possible, the kernel needs to provide a unified way to show userspace
the available devices and notify them when they are added/removed - which
happens to be sysfs + udev etc.
libscg seems to want to replace the operative system for some tasks
in the name of cross-platform compatibility. Sorry, but libscg is
not the center of the world. It's fine that cdrecord does what
it does for the apps for all those platforms where -scanbus and friends
has sense, but linux just has SG_IO. libscg wanting to offer access
to the "transport layer below /dev/hd*" looks like a layering design
violation in operative systems like linux, but it is fine that cdrecord
has it because it _is_ neccesary in other operative system which do
things differently.
Using the native features of a platform is a Good Thing when writing
cross-platform software, ie: glib provides a "threading emulation" where
threads are not available, but it uses the native pthreads if it's
available. libscg wants to do everything everywhere, and that'd have
sense if SG_IO weren't able to do what cdrecord needs, but AFAIK from the
multiple flamewars I've seen, SG_IO does everything that cdrecord
needs. I've not had a problem with SG_IO in years...
Joerg Schilling wrote:
> Jens Axboe <[email protected]> wrote:
>
>> You just want the device naming to reflect that. The user should not
>> need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
>> likely be using k3b or something graphical though, and just click on his
>> Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
>> help do this dynamically even.
>
> Guess why cdrecord -scanbus is needed.
>
> It serves the need of GUI programs for cdrercord and allows them to retrieve
> and list possible drives of interest in a platform independent way.
There are bugs in the implementation that prevent -scanbus from working
properly, and they are not Linux bugs. Once -scanbus really scans all
devices and skips those it cannot access (rather than quitting), you might
have a point.
El Wed, 25 Jan 2006 18:03:18 +0100,
Joerg Schilling <[email protected]> escribi?:
> Guess why cdrecord -scanbus is needed.
>
> It serves the need of GUI programs for cdrercord and allows them to retrieve
> and list possible drives of interest in a platform independent way.
But this is not neccesary at all, since linux platform already provides ways to
retrieve and list possible drives....
On Wed, Jan 25 2006, [email protected] wrote:
> El Wed, 25 Jan 2006 18:03:18 +0100,
> Joerg Schilling <[email protected]> escribi?:
>
> > Guess why cdrecord -scanbus is needed.
> >
> > It serves the need of GUI programs for cdrercord and allows them to retrieve
> > and list possible drives of interest in a platform independent way.
>
> But this is not neccesary at all, since linux platform already
> provides ways to retrieve and list possible drives....
In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
on potentially useful devices.
--
Jens Axboe
Jens Axboe wrote:
> In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
> on potentially useful devices.
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.
On Wed, Jan 25 2006, Matthias Andree wrote:
> Jens Axboe wrote:
>
> > In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
> > on potentially useful devices.
>
> 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.
Certainly, I'm just suggesting a better way to do it on Linux.
--
Jens Axboe
On Wed, Jan 25, 2006 at 06:03:18PM +0100, Joerg Schilling wrote:
> Jens Axboe <[email protected]> wrote:
>
> > You just want the device naming to reflect that. The user should not
> > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> > likely be using k3b or something graphical though, and just click on his
> > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> > help do this dynamically even.
>
> Guess why cdrecord -scanbus is needed.
>
> It serves the need of GUI programs for cdrercord and allows them to retrieve
> and list possible drives of interest in a platform independent way.
GUI programs tend to retrieve this kind of info form HAL
(http://freedesktop.org/wiki/Software_2fhal)
--
Tomasz Torcz "Funeral in the morning, IDE hacking
[email protected] in the afternoon and evening." - Alan Cox
On Wed, Jan 25, 2006 at 06:31:27PM +0100, Jens Axboe wrote:
> In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
> on potentially useful devices.
Serious question, what and how? If I scan /sys/block for example for
potential candidates, that won't give me the devices or tell me the
name udev decided to use for it in /dev.
And I'm not sure how to know if something is cdrom-ish and SG_IO able
from sysfs. Should I filter on driver name? But then, I don't know
which names are acceptable (*cdrom* ?)...
Or maybe I should go through the fad-of-the-day, hal/dbus?
OG.
On 1/25/06, Jens Axboe <[email protected]> wrote:
> On Wed, Jan 25 2006, Jan Engelhardt wrote:
> >
> > >
> > >- you don't need -scanbus. If
> > >users think they do, it's either because Joerg brain washed them or
> > >because they have been used to that bad interface since years ago when
> > >it was unfortunately needed.
> >
> > Now you're unfair.
> > -scanbus does a nice output of what cdwriters (and other capable devices)
> > are present. For me, that lists the cd writer and a CF slot from the
> > multitype usb flash reader.
> >
> > There's one kind of not-so-advanced linux newbies that just go to walmart,
> > buy a computer and whack a linux system on it for fun, and they still don't
> > know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is
> > usually a nightmare for them, and apart that -scanbus lists scsi
> > host,id,lun instead of /dev/hd* (don't comment on this kthx), it is
> > convenient for this sort of users to find out what's available.
> >
> > So, and what about that compactflash reader? It is subject to dynamic
> > usb->scsi device association (depending on when you connect it, it may
> > either become sda, or sdb, or sdc, etc.), and -scanbus yet again provides
> > some way (albeit not useful, because it lists scsi,id,lun rather than
> > /dev/sd* - don't comment either) to see where it actually is.
>
> You just want the device naming to reflect that. The user should not
> need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> likely be using k3b or something graphical though, and just click on his
> Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> help do this dynamically even.
>
> If you are using cdrecord on the command line, you are by definition an
> advanced user and know how to find out where that writer is.
>
> --
> Jens Axboe
As an non expert who just wants his boxes to work out of the box, I
feel that the above message best represents the issue at end.
Joerg seems to be concerned by 2 things:
- the portability of his application accross various platforms
- provide an end-to-end application for writing CDs from both the
command line and to various 3rd party front ends.
Providing a cross platform way to reference the devices seems to help
him achieve that goal.
Linux developers seem to see the world in a different way. Their main
requirements:
- compliance with the linux way of doing things
- ultimately a front end should hide all the dirty details. That
doesn't mean a command line version has to hide them as well, nor that
cdrecord should be the interface to ask things the operating system
can provide
So it looks like:
- from a cdrecord point ov view, Linux is broken.
- from a Linux developers point of view, cdrecord is doing too much
and forces things up.
<very naively>
As a developper with absolutely no competence in this area, I wonder
something: I don't see why the way to refer to a device affects the
ability to perform the functionality (write to it).
Isn't it possible to reorganize the code in such a way that the
burning part can be independent of the way the devices are referred
to?
I downloaded the code and quickly looked at it. If I am looking at the
right version, it seems that the cdrecord code that relates to both cd
burning + the Linux specific part is not that big (and very readable,
thanks Joerg). So I really don't understand why this issue doesn't get
fixed.
</very naively>
As with the communication problems between Joerg and the Linux
developers, if someone was stepping up to be the bridge betweem the 2
parties, couldn't that minimize the risk of flame wars?
cdrecord, how important is Linux to you?
Linux, how important is cdrecord to you?
If you 2 can't get along, just divorce! It's 2006 after all. And the
code is open.
Otherwise, talk together or use a counsellor and make this relationship work.
Jerome
(stripped Lee from the Cc: list)
Jens Axboe schrieb am 2006-01-25:
> > 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.
>
> Certainly, I'm just suggesting a better way to do it on Linux.
Great. There's a better way, but it is not necessary. Let Linux-specific
applications use it for their benefit, but a portable application isn't
going that way because it's too much effort. If a simpler interface that
can be shared with half a dozen other system exists, the portable
application will use that and ignore better interfaces.
--
Matthias Andree
On 25 Jan 2006, Matthias Andree prattled cheerily:
> Jens Axboe wrote:
>
>> In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
>> on potentially useful devices.
>
> 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.
(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.)
--
`Everyone has skeletons in the closet. The US has the skeletons
driving living folks into the closet.' --- Rebecca Ore
El Thu, 26 Jan 2006 00:14:22 +0100,
Matthias Andree <[email protected]> escribi?:
> Great. There's a better way, but it is not necessary. Let Linux-specific
> applications use it for their benefit, but a portable application isn't
> going that way because it's too much effort. If a simpler interface that
> can be shared with half a dozen other system exists, the portable
> application will use that and ignore better interfaces.
It's too "much effort"? Basically, what linux is asking is that cdrecord
stop wasting efforts trying to implement its own solution. Linux is
asking cdrecord to use SG_IO and leave device discovery and data transport
issues to the platform.
Linux doesn't even need -scanbus for example. You could compile out that
code. Device discovery is done by the platform - I find _scary_ that other
"modern" operative systems don't have a way of providing device discovery
services in 2006 and that a external app is needed but hey, people is free
to design their operative system as they like. Linux provides it and leaves
Schilling time to focus in other things. In my book, that's not "too much
effort", is "less effort". If someone bugs you because SG_IO doesn't work
just tell him to report the problem here - in fact cdrecord already has a
"friendly" warning about "linux-2.5 and newer". The cdrecord low level
scsi driver for SG_IO should be much simpler than all the others...
On Thu, 26 Jan 2006, [email protected] wrote:
> It's too "much effort"? Basically, what linux is asking is that cdrecord
> stop wasting efforts trying to implement its own solution. Linux is
> asking cdrecord to use SG_IO and leave device discovery and data transport
> issues to the platform.
>
> Linux doesn't even need -scanbus for example. You could compile out that
> code. Device discovery is done by the platform - I find _scary_ that other
> "modern" operative systems don't have a way of providing device discovery
> services in 2006 and that a external app is needed but hey, people is free
> to design their operative system as they like. Linux provides it and leaves
> Schilling time to focus in other things. In my book, that's not "too much
> effort", is "less effort". If someone bugs you because SG_IO doesn't work
> just tell him to report the problem here - in fact cdrecord already has a
> "friendly" warning about "linux-2.5 and newer". The cdrecord low level
> scsi driver for SG_IO should be much simpler than all the others...
Well, you need to implement 30 (or so) platform-specific ways to get a
list of devices, and portable applications aren't going to do that. To
make it explicit: no way. It is a maintenance nightmare, 30 lowly-tested
pieces of code, too.
This sounds like a huge difference, but I don't believe it actually is.
J?rg is trying to fight the system rather than stop complaining to users
about their using /dev/hd*. The scanning code is there and can be made
working with little effort probably.
--
Matthias Andree
<[email protected]> wrote:
> El Wed, 25 Jan 2006 18:03:18 +0100,
> Joerg Schilling <[email protected]> escribi?:
>
> > Guess why cdrecord -scanbus is needed.
> >
> > It serves the need of GUI programs for cdrercord and allows them to retrieve
> > and list possible drives of interest in a platform independent way.
>
> But this is not neccesary at all, since linux platform already provides ways to
> retrieve and list possible drives....
Interesting: You claim that the Linux platform provides ways to retrieve
the needed information on FreeBSD, MS-WIN, ....?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Thu, 2006-01-26 at 10:38 +0100, Joerg Schilling wrote:
> <[email protected]> wrote:
>
> > El Wed, 25 Jan 2006 18:03:18 +0100,
> > Joerg Schilling <[email protected]> escribi?:
> >
> > > Guess why cdrecord -scanbus is needed.
> > >
> > > It serves the need of GUI programs for cdrercord and allows them to retrieve
> > > and list possible drives of interest in a platform independent way.
> >
> > But this is not neccesary at all, since linux platform already provides ways to
> > retrieve and list possible drives....
>
> Interesting: You claim that the Linux platform provides ways to retrieve
> the needed information on FreeBSD, MS-WIN, ....?
>
What do FreeBSD and MS-WIN have to do with Linux?
Lee
Matthias Andree <[email protected]> wrote:
> Jens Axboe wrote:
>
> > In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
> > on potentially useful devices.
>
> 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.
Another problem is that it is hard to find whether a new feature in Linux will
still be present some time later.
If I would try to immediately add support for every new feature, I would have a
lot of dead code in my sources and would need to put a lot of effort in this
kind of coding. It seems that it makes sense to wait untill all major Linux
distributions made a new feature their default for some time.....
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Tomasz Torcz <[email protected]> wrote:
> > > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> > > likely be using k3b or something graphical though, and just click on his
> > > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> > > help do this dynamically even.
> >
> > Guess why cdrecord -scanbus is needed.
> >
> > It serves the need of GUI programs for cdrercord and allows them to retrieve
> > and list possible drives of interest in a platform independent way.
>
> GUI programs tend to retrieve this kind of info form HAL
> (http://freedesktop.org/wiki/Software_2fhal)
I am not sure what you like to tell with this.
Programs that depend on specific Linux behavior tend to be non-portable (see
e.g. nautilus on GNOME). Nautilus tries to get e.g. the drive write speeds
by reading /prov/scsi/******. Besides the fact that this is not available
elsewhere, it gives incorrect results because there are a lot of DVD writers
with broken firmware.
Cdrecord implements workarounds for this kind of problems and for this reason,
the most portable solution for a GUI is to use cdrecord to retrieve the
information.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Thu, Jan 26, 2006 at 11:25:49AM +0100, Joerg Schilling wrote:
> Tomasz Torcz <[email protected]> wrote:
>
> > > > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> > > > likely be using k3b or something graphical though, and just click on his
> > > > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> > > > help do this dynamically even.
> > >
> > > Guess why cdrecord -scanbus is needed.
> > >
> > > It serves the need of GUI programs for cdrercord and allows them to retrieve
> > > and list possible drives of interest in a platform independent way.
> >
> > GUI programs tend to retrieve this kind of info form HAL
> > (http://freedesktop.org/wiki/Software_2fhal)
>
> I am not sure what you like to tell with this.
>
> Programs that depend on specific Linux behavior tend to be non-portable (see
> e.g. nautilus on GNOME). Nautilus tries to get e.g. the drive write speeds
> by reading /prov/scsi/******. Besides the fact that this is not available
> elsewhere, it gives incorrect results because there are a lot of DVD writers
> with broken firmware.
This is a fallback if HAL isn't available. Normally this is done by:
drive->max_speed_write = libhal_device_get_property_int
(ctx, device_names [i],
"storage.cdrom.write_speed",
NULL)
/ CD_ROM_SPEED;
(natilus-burn-drive.c:1368 from version 2.12.0).
> Cdrecord implements workarounds for this kind of problems and for this reason,
> the most portable solution for a GUI is to use cdrecord to retrieve the
> information.
Yeah, sure.
/* FIXME we don't have any way to guess the real device
* from the info we get from CDRecord */
(the only FIXME in above mentioned file).
--
Tomasz Torcz 72->| 80->|
[email protected] 72->| 80->|
jerome lacoste <[email protected]> wrote:
> Joerg seems to be concerned by 2 things:
> - the portability of his application accross various platforms
> - provide an end-to-end application for writing CDs from both the
> command line and to various 3rd party front ends.
> Providing a cross platform way to reference the devices seems to help
> him achieve that goal.
Correct.
> Linux developers seem to see the world in a different way. Their main
> requirements:
> - compliance with the linux way of doing things
Which is unfortunately (in contrary to what cdrecord does) a moving target.
> - ultimately a front end should hide all the dirty details. That
> doesn't mean a command line version has to hide them as well, nor that
> cdrecord should be the interface to ask things the operating system
> can provide
The best way of making a GUI portable is by making the underlying command line
application portable and using the same CLI for every OS.
> So it looks like:
> - from a cdrecord point ov view, Linux is broken.
> - from a Linux developers point of view, cdrecord is doing too much
> and forces things up.
BTW: There are still many people who run Linux-2.2 and many people told me that
they will probably never upgrade from 2.4 to 2.6.
On Linux-2.4, cdrecord's abstraction is the only way to hide the security
relevent non-stable /dev/sg* <-> device relation.
> <very naively>
>
> As a developper with absolutely no competence in this area, I wonder
> something: I don't see why the way to refer to a device affects the
> ability to perform the functionality (write to it).
>
> Isn't it possible to reorganize the code in such a way that the
> burning part can be independent of the way the devices are referred
> to?
This is what cdrecord does!
Cdrecord uses the OS and transport independent libscg/
> I downloaded the code and quickly looked at it. If I am looking at the
> right version, it seems that the cdrecord code that relates to both cd
> burning + the Linux specific part is not that big (and very readable,
> thanks Joerg). So I really don't understand why this issue doesn't get
> fixed.
>
> </very naively>
I was never talking about cdrecord in special here but rather talkign about
libscg which does not only deal with CD/DVD-writers but with any (even unknown)
kind of SCSI devices.
The real problen with many people on this list is that they ague in a way that
might be correct in case that cdrecord would not use a anstracting library as
libscg. In that case, some of the arguments may ne right....but we need to talk
abut a generic SCSI transport - independent from the SCSI device type and from
the SCSI transport that is used for that device.
> cdrecord, how important is Linux to you?
Linux was important between 1996 and ~ 2000. In that time, I got a lot of
really exciting and valuable feedback from various kernel developers and
in that time, Linux was the only way to use CD/DVD-writers with strange exotic
transport interfaces.
But the times are changing. During the past few years, some Linux kernel
developers started a rather aggressive campaign against crecord and Linux did
become less usable for CD/DVD writing than it has been before.
Meanwhile other OS did step into the right direction. FreeBSD and Solaris added
support for other SCSI transports and I now recommend to use FreeBSd or Solaris
because things are a lot smoother on these OS.
As an example: USB on Solaris is a lot more stable than on Linux. Timeout
problems to not appear, I have been able to connect and mount my Nikon D70
out of the box on Solaris 9 (from November 2002) while Linux does not even see
the camera on USB. Solaris has a device cache for removable media and offers
stable /dev/* entries and stable major/minor numbers for hot plugged USB and
other devices while Linux happyli creates new device entries for every reconnect.
Discussions with FreeBSD and Solaris people are always friutful because these
discussions stay technical. Solaris did fix all remaining issues with CD/DVD
writing during the past 2 years and Solaris now is the free OS where CD/DVD
writing works most smoothly.
It seems that cdrecord does not need Linux anymore. Does Linux need cdrecord?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hello!
> > Linux developers seem to see the world in a different way. Their main
> > requirements:
> > - compliance with the linux way of doing things
>
> Which is unfortunately (in contrary to what cdrecord does) a moving target.
Which is *fortunately* a moving target, because what served well 20 years
ago is unlikely to serve equally well *now*.
Having a stable naming of devices is a good goal, but in no way restricted
to SCSI-like devices. What you suggest works only there, what Linux currently
uses (udev etc.) works for all devices. Guess which is better for most users.
> BTW: There are still many people who run Linux-2.2 and many people told me that
> they will probably never upgrade from 2.4 to 2.6.
Fine, so feel free consider Linux <2.6 and Linux 2.6 two completely
separate operating systems. I did the same with the IP stack interface
in the BIRD project and I consider it a very good step -- the old
interface provided by Linux 2.0 and cluttered with BSD compatibility is
almost unusable when compared to Netlink, but for sake of users who
don't want to upgrade their kernel, BIRD is able to use the old one,
though with limited functionality.
> On Linux-2.4, cdrecord's abstraction is the only way to hide the security
> relevent non-stable /dev/sg* <-> device relation.
OK. So welcome to year 2006. And to Linux 2.6.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
How do I type 'for i in *.dvi ; do xdvi $i ; done' in a GUI?
Nix <[email protected]> wrote:
> 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.
Interesting theory.... unfortunately this makes assumptions that cannot be
proved. Where is this HAL available and more impportant: how is it related
to generis transport and device independent SCSI?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
<[email protected]> wrote:
> It's too "much effort"? Basically, what linux is asking is that cdrecord
> stop wasting efforts trying to implement its own solution. Linux is
> asking cdrecord to use SG_IO and leave device discovery and data transport
> issues to the platform.
Cddrecord does not use SG_IO, cdrecord uses the platform independent libscg.
If you like to talk on cdrecord, you are talking about the wrong thing.
libscg is the target of interest.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree <[email protected]> wrote:
> Well, you need to implement 30 (or so) platform-specific ways to get a
> list of devices, and portable applications aren't going to do that. To
> make it explicit: no way. It is a maintenance nightmare, 30 lowly-tested
> pieces of code, too.
It already works in libscg since nearly 10 years.
> This sounds like a huge difference, but I don't believe it actually is.
> J?rg is trying to fight the system rather than stop complaining to users
> about their using /dev/hd*. The scanning code is there and can be made
> working with little effort probably.
Talking about /dev/hd* ignore the basic problem. Show me a way how to
send SCSI commands to a ATAPI tape drive on Linux.
Please do not forget that libscg is OS _and_ device independent.
Implementing /dev/hd* support at all is already a concession that did go to far.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Lee Revell <[email protected]> wrote:
> > Interesting: You claim that the Linux platform provides ways to retrieve
> > the needed information on FreeBSD, MS-WIN, ....?
> >
>
> What do FreeBSD and MS-WIN have to do with Linux?
What is the relevence of /dev/hd* for a device independent library like libscg?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
> Lee Revell <[email protected]> wrote:
>
>
>>>Interesting: You claim that the Linux platform provides ways to retrieve
>>>the needed information on FreeBSD, MS-WIN, ....?
>>>
>>
>>What do FreeBSD and MS-WIN have to do with Linux?
>
>
> What is the relevence of /dev/hd* for a device independent library like libscg?
>
Isn't it good practice to adhere to the naming conventions
of the system to which a program is ported to? (even if 100
of them do it one way and 1 does it another)
I don't claim to be an expert in the area at all, but it seems
like the best way to do it IMHO.
Thanks,
Nick
--
Send instant messages to your online friends http://au.messenger.yahoo.com
Tomasz Torcz <[email protected]> wrote:
> This is a fallback if HAL isn't available. Normally this is done by:
>
> drive->max_speed_write = libhal_device_get_property_int
> (ctx, device_names [i],
> "storage.cdrom.write_speed",
> NULL)
> / CD_ROM_SPEED;
>
> (natilus-burn-drive.c:1368 from version 2.12.0).
Even if this works under good conditions, it will fail in many cases
because the related software is not up to date with recent device formware bugs.
Cdrecord is kept up to date as it either deals with a new drive or not.
Delegating things to other instances only works ar long as there are clean ans
stable interfaces. This unfortunately does not apply to CD/DVD/HD-DVD.
> > Cdrecord implements workarounds for this kind of problems and for this reason,
> > the most portable solution for a GUI is to use cdrecord to retrieve the
> > information.
>
> Yeah, sure.
> /* FIXME we don't have any way to guess the real device
> * from the info we get from CDRecord */
>
> (the only FIXME in above mentioned file).
And guess why Sun is currently working on a work around this nautilus problem.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Martin Mares <[email protected]> wrote:
> > On Linux-2.4, cdrecord's abstraction is the only way to hide the security
> > relevent non-stable /dev/sg* <-> device relation.
>
> OK. So welcome to year 2006. And to Linux 2.6.
When will Linux arrive in 2006 and support ATAPI and SCSI in general, not just
ATAPI for hard disk drives and CD-ROMS?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Nick Piggin <[email protected]> wrote:
> Joerg Schilling wrote:
> > Lee Revell <[email protected]> wrote:
> >
> >
> >>>Interesting: You claim that the Linux platform provides ways to retrieve
> >>>the needed information on FreeBSD, MS-WIN, ....?
> >>>
> >>
> >>What do FreeBSD and MS-WIN have to do with Linux?
> >
> >
> > What is the relevence of /dev/hd* for a device independent library like libscg?
> >
>
> Isn't it good practice to adhere to the naming conventions
> of the system to which a program is ported to? (even if 100
> of them do it one way and 1 does it another)
Well, the problem is that (in special if you include the ATAPI tape drives)
Linux likes to enforce inapropriate naming conventions.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
> Nick Piggin <[email protected]> wrote:
>
>>Isn't it good practice to adhere to the naming conventions
>>of the system to which a program is ported to? (even if 100
>>of them do it one way and 1 does it another)
>
>
> Well, the problem is that (in special if you include the ATAPI tape drives)
> Linux likes to enforce inapropriate naming conventions.
>
But making up a new naming scheme which you happen to consider
more appropriate doesn't sound to me like a good solution. Not
even if you have good reasons for your likes/dislikes.
If I ported some Linux program to Windows I would not ask
the user if they wanted to save to /dev/hda5, or /mnt/c_drive
because I consider C: bad naming.
--
Send instant messages to your online friends http://au.messenger.yahoo.com
El Thu, 26 Jan 2006 10:38:23 +0100,
Joerg Schilling <[email protected]> escribi?:
> > > It serves the need of GUI programs for cdrercord and allows them to retrieve
> > > and list possible drives of interest in a platform independent way.
> >
> > But this is not neccesary at all, since linux platform already provides ways to
> > retrieve and list possible drives....
>
> Interesting: You claim that the Linux platform provides ways to retrieve
> the needed information on FreeBSD, MS-WIN, ....?
No. I claim that linux does have ways of retrieving the needed information.
You can keep providing your own solution on freebsd, win & friends if
you want, but _why_ do you want to do it in linux when linux can do it
by itself?? There's no reason why cdrecord should care about duplicating
existing functionality when the platform can provide that functionality
for free. Let cdrecord (name it libscg) use SG_IO and let users use
the /dev/hd*.
The case of cdrecord remembers me of X.org, which used/is poking /dev/mem
directly to discover PCI devices and/or play with framebuffers instead of
using the available APIs in linux. Except that the X.org people wants to
solve (or has already solved) such problems using the native available
APIS instead of keeping their own solutions. Well-written cross-platform
software implements all the features when needed by all the platforms as
a whole but only uses such features when a particular platform needs it,
unless using one of those features is a nightmare (which is not the
case of SG_IO IMHO)
Joerg Schilling wrote:
> Nick Piggin <[email protected]> wrote:
>
>> Joerg Schilling wrote:
>>> Lee Revell <[email protected]> wrote:
>>>
>>>
>>>>> Interesting: You claim that the Linux platform provides ways to retrieve
>>>>> the needed information on FreeBSD, MS-WIN, ....?
>>>>>
>>>> What do FreeBSD and MS-WIN have to do with Linux?
>>>
>>> What is the relevence of /dev/hd* for a device independent library like libscg?
>>>
>> Isn't it good practice to adhere to the naming conventions
>> of the system to which a program is ported to? (even if 100
>> of them do it one way and 1 does it another)
>
> Well, the problem is that (in special if you include the ATAPI tape drives)
> Linux likes to enforce inapropriate naming conventions.
Nope. Naming conventions are not subject here.
What OTHER libscg operations do not work for a particular ATAPI tape drive?
-scanbus does NOT count, don't mention it.
What is the drive manufacturer and type?
What is the failing or inaccessible operation?
Please remember to remove Jens Axboe and Lee Revell from the Cc: list!
>> This sounds like a huge difference, but I don't believe it actually is.
>> Jörg is trying to fight the system rather than stop complaining to users
>> about their using /dev/hd*. The scanning code is there and can be made
>> working with little effort probably.
>
>Talking about /dev/hd* ignore the basic problem. Show me a way how to
>send SCSI commands to a ATAPI tape drive on Linux.
ATAPI tapes writing CDs (or tapes for that amtter). It may seem possible if
the scsi command is the same.
Feels like making tea in a coffee machine, but hey, it's possible,
and sounds like Someone want's to have it. :)
>Please do not forget that libscg is OS _and_ device independent.
If so, how much effort is there in having libscg building an enumeration
out of all (related to cd writing) sysfs drives?
Jan Engelhardt
--
>You just want the device naming to reflect that. The user should not
>need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
>likely be using k3b or something graphical though, and just click on his
>Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
>help do this dynamically even.
And if you have multiple cdwriters? Then (cf. other posts) one has
/dev/cdrecorder0 /dev/cdrecrder1, etc. To me, that's just as bad as having
/dev/sg0 and /dev/sg1, because you don't have a clue at first sight what it
maps to.
"ls -l"? Sure, if cdrecorder0 was a symlink, but it does not work when it's
not (= a block device in essence then).
And I'm sure there's an analog program to "ls" to find what sg0 maps to.
>If you are using cdrecord on the command line, you are by definition an
>advanced user and know how to find out where that writer is.
And GUIs could use arbitrary names like S:I:L. Ugly, but as long as it
works... sigh.
Jan Engelhardt
--
On Thu, Jan 26 2006, Jan Engelhardt wrote:
>
> >You just want the device naming to reflect that. The user should not
> >need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> >likely be using k3b or something graphical though, and just click on his
> >Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> >help do this dynamically even.
>
> And if you have multiple cdwriters? Then (cf. other posts) one has
> /dev/cdrecorder0 /dev/cdrecrder1, etc. To me, that's just as bad as having
> /dev/sg0 and /dev/sg1, because you don't have a clue at first sight what it
> maps to.
/dev/plextorwriter and /dev/hpwriter or whatever, it's just naming.
> "ls -l"? Sure, if cdrecorder0 was a symlink, but it does not work when it's
> not (= a block device in essence then).
> And I'm sure there's an analog program to "ls" to find what sg0 maps to.
You expect the gui user to follow symlinks to find out?
--
Jens Axboe
Joerg Schilling wrote:
> Matthias Andree <[email protected]> wrote:
>
>
>>Well, you need to implement 30 (or so) platform-specific ways to get a
>>list of devices, and portable applications aren't going to do that. To
>>make it explicit: no way. It is a maintenance nightmare, 30 lowly-tested
>>pieces of code, too.
>
>
> It already works in libscg since nearly 10 years.
>
>
>>This sounds like a huge difference, but I don't believe it actually is.
>>J?rg is trying to fight the system rather than stop complaining to users
>>about their using /dev/hd*. The scanning code is there and can be made
>>working with little effort probably.
>
>
> Talking about /dev/hd* ignore the basic problem. Show me a way how to
> send SCSI commands to a ATAPI tape drive on Linux.
>
> Please do not forget that libscg is OS _and_ device independent.
> Implementing /dev/hd* support at all is already a concession that did go to far.
You added the feature, and a message that it was accidental and
unsupported. In truth is was neither, and your little message pisses off
developers and scares casual users.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Jens Axboe wrote:
> On Thu, Jan 26 2006, Jan Engelhardt wrote:
>
>>>You just want the device naming to reflect that. The user should not
>>>need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
>>>likely be using k3b or something graphical though, and just click on his
>>>Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
>>>help do this dynamically even.
>>
>>And if you have multiple cdwriters? Then (cf. other posts) one has
>>/dev/cdrecorder0 /dev/cdrecrder1, etc. To me, that's just as bad as having
>>/dev/sg0 and /dev/sg1, because you don't have a clue at first sight what it
>>maps to.
>
>
> /dev/plextorwriter and /dev/hpwriter or whatever, it's just naming.
>
>
>>"ls -l"? Sure, if cdrecorder0 was a symlink, but it does not work when it's
>>not (= a block device in essence then).
>>And I'm sure there's an analog program to "ls" to find what sg0 maps to.
>
>
> You expect the gui user to follow symlinks to find out?
>
As opposed to? That's not a rhetorical question, please don't blow it
off, what is the way for a user to go from /dev/sg0 to find out what
device is really there?
What is not easily available in Linux is a nice single place to find out
what mass storage (disk/optical/floppy/ZIP/LS120/tape) devices are on
the system, and what the system calls them. Because for low tech users
udev is the problem, not the solution. The user doesn't want to tell the
system what to call the device, he wants to see what's there, and that
includes serial numbers of drives (where available) because if a user
has several drives it's likely that they are identical.
Telling the users to "cat /proc/scsi/scsi" and
for n in /proc/ide/hd?; do echo -n "$n: "; cat $n/model; done
is not a substitute for a presentation useful to programs and people
alike. It could be in /proc or /sys or wherever is flavor of the day,
but it would sure make things easier for the users. And before someone
suggests that a program could generate this, a program would constantly
chase the changing presentation of the information, a documented "file"
in /proc or /sys would allow all applications to look in one place for
the information.
Instead of having the user tell the system what to call a device, let
the system tell the user what it is called. Then the kernel could change
without breaking anything in application land.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Jan 30, 2006, at 17:52, Bill Davidsen wrote:
> What is not easily available in Linux is a nice single place to
> find out what mass storage (disk/optical/floppy/ZIP/LS120/tape)
> devices are on the system, and what the system calls them.
Yes it is available, and a whole slew of GUI applications use it.
It's called "hal", or Hardware Abstraction Layer, and it has small
hooks into udev and a bit of sysfs code so that it has a list of all
devices of various types and knows what their associated udev-created
device nodes are. This means that I can configure udev to put my CD
drive on /dev/burner and correctly written GUI programs will just
find it and work.
> Because for low tech users udev is the problem, not the solution.
> The user doesn't want to tell the system what to call the device,
> he wants to see what's there, and that includes serial numbers of
> drives (where available) because if a user has several drives it's
> likely that they are identical.
Your average low-tech user installing stock Debian (Not even
something targeted at user-friendliness like Ubuntu), will end up
with udev/hal installed. When he plugs in his burner, it will get
the name /dev/cdrom[0-9] behind the scenes, and hal will notice.
When he starts up k3b, it will use hal and automatically notice his
drive, showing him brand, serial number, etc.
> Instead of having the user tell the system what to call a device,
> let the system tell the user what it is called.
Uhh, both happen. The system tells userspace "I just got/have a
device with brand 'foo', specs 'bar', serial 'baz', etc". Userspace
(behind the scenes, without your low-tech user caring) creates a
device node "/dev/cdrom[0-9]" and alerts hal, which sends it to your
application, which nicely alerts the user. As an admin who does a
lot on the command line, I can tie certain drive serial numbers to /
dev/blue_burner and /dev/red_burner for my own ease-of-command-line-
use without breaking the aforementioned hal system.
Cheers,
Kyle Moffett
--
I have yet to see any problem, however complicated, which, when you
looked at it in the right way, did not become still more complicated.
-- Poul Anderson
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 <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Fri, 10 Feb 2006 16:06:39 -0500
Bill Davidsen <[email protected]> wrote:
> 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.
> [snip]
All that is required is a proper device node in /dev; is this really
so much of a burden? This device node can be created statically
at install time or via udev or any other method. In fact if you're
using udev and a device node isn't automatically created for all
of your cd burners, you can file a bug report and get it fixed. So in
the end all you ever have to teach a user is to pick the device they
want from /dev.
Sean
Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen:
> 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.
Introducing more than interface for doing the same thing can be very
confusing and counter-productive. You'll create new, undocumented or
semi-documented interfaces which will lead to a dependency chaos.
Some random script will work with kernel 2.6.11, 2.6.12 and 2.6.13, but
not 2.6.14 and later because a new device class was introduced and two
typos were fixed. Especially considering that the new linux development
model makes it likely that major changes go into micro releases,
stability and reliability will be a huge problem.
> 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.
Tastes are different. I think the HAL semantics are perfectly OK for
doing what you want, i.e. you can use hal-find-by-capability together
with hal-get-property to get the block device paths of the installed
mass storage and for distinguishing them.
Distributors should ship sane udev rules applicable for 99.5% of the
people out there. They do, actually.
> > [...]
> 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,
Nice that we agree on that.
> but *in* the kernel, where it will track changes.
Oh, and BSDs and other target systems of interest for higher-level
libraries and applications don't need libhal? What do we gain by pushing
more and more functionality down the stack right into the kernel,
without guaranteeing ABI/API stability? HAL was developed with
portability in mind, why should one give it up for solving hypothetical
problems, depending on release cycles and patch review by external
projects? I thought the original plan was rather to break the kernel
down and not to make it a melting pot for all kinds of specialized
functionality, which to my impression was originally done because of the
lack of vendor support.
> 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...
Well, "any user" just opens his Windows Explorer and takes a look at the
icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
interesting to see professional programmers often argue that a
particular solution they like is appropriate for all users without
giving proof. I can't think of a single reason why a user wants to dump
all his devices without knowing the grep semantics, which in turn makes
it very likely that he will write some wrapper code around any of the
currently perfectly working solutions.
--
Christian Neumair <[email protected]>
On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
>
> 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.
It does so today in sysfs, that is what it is there for.
thanks,
greg k-h
On Fri, Feb 10, 2006 at 03:56:54PM -0800, Greg KH wrote:
> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> >
> > 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.
>
> It does so today in sysfs, that is what it is there for.
Except it does not provide the path to the device nodes themselves.
You need to call udevinfo for that, or parse /dev/.udev/*. Do you
think it would be possible to have hotplug/udev/whatever exists in the
future to give that information back in the kernel and have it appear
in sysfs?
OG.
On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote:
> On Fri, Feb 10, 2006 at 03:56:54PM -0800, Greg KH wrote:
> > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > >
> > > 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.
> >
> > It does so today in sysfs, that is what it is there for.
>
> Except it does not provide the path to the device nodes themselves.
That is not what Bill asked for. So there is no "except" here :)
> You need to call udevinfo for that, or parse /dev/.udev/*. Do you
> think it would be possible to have hotplug/udev/whatever exists in the
> future to give that information back in the kernel and have it appear
> in sysfs?
No. Why would it when it is very simple to query udevinfo for that?
thanks,
greg k-h
On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote:
> On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote:
> > You need to call udevinfo for that, or parse /dev/.udev/*. Do you
> > think it would be possible to have hotplug/udev/whatever exists in the
> > future to give that information back in the kernel and have it appear
> > in sysfs?
>
> No. Why would it when it is very simple to query udevinfo for that?
In order not to depend on a userland package for the kernel service of
device enumeration? It's udevinfo now, what will it be in two years?
OG.
Olivier Galibert <[email protected]> writes:
>> No. Why would it when it is very simple to query udevinfo for that?
>
> In order not to depend on a userland package for the kernel service of
> device enumeration? It's udevinfo now, what will it be in two years?
Come on, kernel does not need that info at all. In fact, cdrecord
doesn't need it either. Some frontends, maybe, though hal may be
better source if running.
In fact udev isn't mandatory either. We have it because it's handy,
it saves us from megatons of /dev files and keeps /dev/black-dvd in
sync with black dvd.
Personally I think the whole "cdrecord -scanbus" is bogus - command
line utils should do what they are asked to do (e.g., write to
/dev/hda1 or /dev/microcode if so requested).
--
Krzysztof Halasa
On Fri, 10 Feb 2006, Greg KH wrote:
> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> >
> > 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.
>
> It does so today in sysfs, that is what it is there for.
sysfs doesn't do quite that level of categorization; if it did, cdrom_id
would be unnecessary. It would be nice if you could do
"grep 1 /sys/block/*/burns_cds" and get a list of all the block devices in
your system that burn cds. (You can currently get a list of all of the
removable block devices in your system, but not much else.)
The kernel must know a bunch of this sort of stuff, and it would be nice
if the information available. (In fact, there's a lot that's in /proc/ide
that isn't in /sys, which is a bit annoying, since it would be useful in
/sys, especially if it would mean that you could ignore details of what
kind of bus things were on.)
-Daniel
On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote:
> On Fri, 10 Feb 2006, Greg KH wrote:
>
> > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > >
> > > 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.
> >
> > It does so today in sysfs, that is what it is there for.
>
> sysfs doesn't do quite that level of categorization; if it did, cdrom_id
> would be unnecessary.
What? cdrom_id queries the device directly to get some specific
information about the device, much like any other type of device query
(lspci, lsusb, etc.)
And yes, it would be nice if some of that information was also exported
through sysfs, and as always, patches are gladly accpeted.
> It would be nice if you could do
> "grep 1 /sys/block/*/burns_cds" and get a list of all the block devices in
> your system that burn cds. (You can currently get a list of all of the
> removable block devices in your system, but not much else.)
Well, I can see if they are disks or cdroms through sysfs quite easily,
removable or not, so you do get more information than you expect.
> The kernel must know a bunch of this sort of stuff, and it would be nice
> if the information available. (In fact, there's a lot that's in /proc/ide
> that isn't in /sys, which is a bit annoying, since it would be useful in
> /sys, especially if it would mean that you could ignore details of what
> kind of bus things were on.)
I agree, again, feel free to submit patches.
thanks,
greg k-h
On Sun, Feb 12, 2006 at 10:14:06PM +0100, Olivier Galibert wrote:
> On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote:
> > On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote:
> > > You need to call udevinfo for that, or parse /dev/.udev/*. Do you
> > > think it would be possible to have hotplug/udev/whatever exists in the
> > > future to give that information back in the kernel and have it appear
> > > in sysfs?
> >
> > No. Why would it when it is very simple to query udevinfo for that?
>
> In order not to depend on a userland package for the kernel service of
> device enumeration? It's udevinfo now, what will it be in two years?
WTF? You are depending on that same program to create your device
nodes. If you don't want to use that program to do it, then use
something else, or use a static device tree, which works like always.
sysfs exports everything that userspace needs to know, if it wants to
create a device node to talk to that specific device. udev used it to
create your /dev tree, while other programs use it to create temporary
device nodes to do other things to your devices. Either way, the kernel
doesn't know, or care what you call those device nodes.
thanks,
greg k-h
On Sun, 12 Feb 2006, Greg KH wrote:
> On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote:
> > sysfs doesn't do quite that level of categorization; if it did, cdrom_id
> > would be unnecessary.
>
> What? cdrom_id queries the device directly to get some specific
> information about the device, much like any other type of device query
> (lspci, lsusb, etc.)
>
> And yes, it would be nice if some of that information was also exported
> through sysfs, and as always, patches are gladly accpeted.
Are there guidelines on having a generic cdrom export information from its
block interface, rather than through its bus? I'm not finding any
documentation of sys/block/, aside from that it exists.
> > It would be nice if you could do
> > "grep 1 /sys/block/*/burns_cds" and get a list of all the block devices in
> > your system that burn cds. (You can currently get a list of all of the
> > removable block devices in your system, but not much else.)
>
> Well, I can see if they are disks or cdroms through sysfs quite easily,
> removable or not, so you do get more information than you expect.
Ah, okay, this is in the current -rcs. I was only looking at 2.6.15 (and
before), which is too old.
-Daniel
*This .sig left intentionally blank*
Bill Davidsen <[email protected]> wrote:
> 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.
This would make sense in case that a useful definition with a granted lifetime
of at least 10 years would be implemented.
> The kernel could provide a list of devices by category. It doesn't have
What if the kernel does not understand the cetegory?
Common oddities:
- Mac OS X tries to distinct between CD/DVD writers and CD/DVD-ROM
although there is only one device class.
- Older CD-writers identified as WORM although a CD-R is not a WORM.
> 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.
As this categorisation does not work, we need a way to find all devices
that talk SCSI and let the application decicde what device is supported.
> 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...
So you seem to agree with me.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Christian Neumair <[email protected]> wrote:
> Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen:
> > 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.
>
> Introducing more than interface for doing the same thing can be very
> confusing and counter-productive. You'll create new, undocumented or
> semi-documented interfaces which will lead to a dependency chaos.
So you concur with me that the fact that Linux introduced another interface
for SCSI was onfusing and counter-productive.
> Some random script will work with kernel 2.6.11, 2.6.12 and 2.6.13, but
> not 2.6.14 and later because a new device class was introduced and two
> typos were fixed. Especially considering that the new linux development
> model makes it likely that major changes go into micro releases,
> stability and reliability will be a huge problem.
The main problem is that there is no grant that a new model will survive
a time frame that makes sense to implement support.
> > 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...
>
> Well, "any user" just opens his Windows Explorer and takes a look at the
> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> interesting to see professional programmers often argue that a
This is not true: a drive letter mapping does not need to exist on MS-WIN
in order to be able to access it via ASPI or SPTI.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Greg KH <[email protected]> wrote:
> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> >
> > 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.
>
> It does so today in sysfs, that is what it is there for.
Do you really whant libscg to open _every_ non-directory file under /sys?
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hello!
> The main problem is that there is no grant that a new model will survive
> a time frame that makes sense to implement support.
I bet that it would take less time to implement this support than what
you spend here by arguing and trying to prove you are the only sane
person in the world. Unsuccessfully, of course.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"#define QUESTION ((bb) || !(bb))" -- Shakespeare
On 2/13/06, Joerg Schilling <[email protected]> wrote:
[...]
> > > 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...
> >
> > Well, "any user" just opens his Windows Explorer and takes a look at the
> > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> > interesting to see professional programmers often argue that a
>
> This is not true: a drive letter mapping does not need to exist on MS-WIN
> in order to be able to access it via ASPI or SPTI.
But from a user perspective, how one is supposed to identify between 2
identical burners named D: and E: on their system if cdrecord only
provides b,t,l naming and "b,t,l to cd burner name" mapping?
The "OS specific to b,t,l" mapping is clearly lacking although
cdrecord knows it there as well. Cf. scsi-wnt.c:
#ifdef _DEBUG_SCSIPT
js_fprintf(scgp_errfile, "SPTI: Adding drive %c: (%d:%d:%d)\n", 'A'+i,
pDrive->ha, pDrive->tgt, pDrive->lun);
#endif
Jerome
Martin Mares <[email protected]> wrote:
> Hello!
>
> > The main problem is that there is no grant that a new model will survive
> > a time frame that makes sense to implement support.
>
> I bet that it would take less time to implement this support than what
> you spend here by arguing and trying to prove you are the only sane
> person in the world. Unsuccessfully, of course.
If memory serves me correctly, the current model is the 3rd incompatible one
offerend within less than 5 years.
If you did ever try to write reliable code that has to deal with this kind of
oddities, you would understand that it is sometimes better to wait and to inform
related people about the problems they caused.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
jerome lacoste <[email protected]> wrote:
> On 2/13/06, Joerg Schilling <[email protected]> wrote:
> [...]
> > > > 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...
> > >
> > > Well, "any user" just opens his Windows Explorer and takes a look at the
> > > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> > > interesting to see professional programmers often argue that a
> >
> > This is not true: a drive letter mapping does not need to exist on MS-WIN
> > in order to be able to access it via ASPI or SPTI.
>
> But from a user perspective, how one is supposed to identify between 2
> identical burners named D: and E: on their system if cdrecord only
> provides b,t,l naming and "b,t,l to cd burner name" mapping?
Drive letters do not have real relevence from a OS view if talking about MS-WIN
> The "OS specific to b,t,l" mapping is clearly lacking although
> cdrecord knows it there as well. Cf. scsi-wnt.c:
>
> #ifdef _DEBUG_SCSIPT
> js_fprintf(scgp_errfile, "SPTI: Adding drive %c: (%d:%d:%d)\n", 'A'+i,
> pDrive->ha, pDrive->tgt, pDrive->lun);
> #endif
The is no mapping, libscg just let's the user use the addressing used inside
the MS-WIN kernel.
The drive letter related code was contributed by a russion guy who did
try to find a way to lock a drive in use by cdrecord, preventing
automount/autoexec. This is unfortunately a bit brain-dead and caused by
MS-WIN oddities.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 2/13/06, Joerg Schilling <[email protected]> wrote:
> jerome lacoste <[email protected]> wrote:
>
> > On 2/13/06, Joerg Schilling <[email protected]> wrote:
> > [...]
> > > > > 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...
> > > >
> > > > Well, "any user" just opens his Windows Explorer and takes a look at the
> > > > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> > > > interesting to see professional programmers often argue that a
> > >
> > > This is not true: a drive letter mapping does not need to exist on MS-WIN
> > > in order to be able to access it via ASPI or SPTI.
> >
> > But from a user perspective, how one is supposed to identify between 2
> > identical burners named D: and E: on their system if cdrecord only
> > provides b,t,l naming and "b,t,l to cd burner name" mapping?
>
> Drive letters do not have real relevence from a OS view if talking about MS-WIN
Most complaints about cdrecord are to try to make it fit with the user
perspective, not the OS one.
Mostly nobody complain about the results of cdrecord job (otherwise it
would have been rewritten). People just complain on its command line
interface.
> > The "OS specific to b,t,l" mapping is clearly lacking although
> > cdrecord knows it there as well. Cf. scsi-wnt.c:
> >
> > #ifdef _DEBUG_SCSIPT
> > js_fprintf(scgp_errfile, "SPTI: Adding drive %c: (%d:%d:%d)\n", 'A'+i,
> > pDrive->ha, pDrive->tgt, pDrive->lun);
> > #endif
>
> The is no mapping,
Maybe we disagree on the word "mapping".
Didn't this code print out the mapping between a drive letter and a
b,t,l number ?
> libscg just let's the user use the addressing used inside
> the MS-WIN kernel.
>
> The drive letter related code was contributed by a russion guy who did
> try to find a way to lock a drive in use by cdrecord, preventing
> automount/autoexec. This is unfortunately a bit brain-dead and caused by
> MS-WIN oddities.
Quote from scsi-wnt.c where I took the code extract from:
/*
* Initialization of SCSI Pass Through Interface code. Responsible for
* setting up the array of SCSI devices. This code will be a little
* different from the normal code -- it will query each drive letter from
* C: through Z: to see if it is a CD. When we identify a CD, we then
* send CDB with the INQUIRY command to it -- NT will automagically fill in
* the PathId, TargetId, and Lun for us.
*/
The code I am pointing at just maps the various OS specific drives to
SCSI b,t,l, like it is done on Linux.
This mapping is done in every single scsi-*.c file I had a look at.
E.g. openserver:
if (scgp->debug > 0) {
for (l = 0; l < nlm; l++)
js_fprintf((FILE *)scgp->errfile,
"%-4s = %5s(%d,%d,%d,%d) -> %s\n",
cmtbl[l].typ,
cmtbl[l].drv,
cmtbl[l].hba,
cmtbl[l].bus,
cmtbl[l].tgt,
cmtbl[l].lun,
cmtbl[l].dev);
js_fprintf((FILE *)scgp->errfile, "-------------------- \n");
}
So can you make this 'mapping' available to wrapper applications in a
parsable format?
Jerome
>> Well, "any user" just opens his Windows Explorer and takes a look at the
>> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
>> interesting to see professional programmers often argue that a
>
>This is not true: a drive letter mapping does not need to exist on MS-WIN
>in order to be able to access it via ASPI or SPTI.
>
I have to support this view. Linux filesystems do not show up in Windows
Explorer (because there's obviously an fs driver lacking), but there's
always a way to damage your Linux from within Windows.
Jan Engelhardt
--
On Sun, Feb 12, 2006 at 10:24:12PM -0800, Greg KH wrote:
> On Sun, Feb 12, 2006 at 10:14:06PM +0100, Olivier Galibert wrote:
> > On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote:
> > > On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote:
> > > > You need to call udevinfo for that, or parse /dev/.udev/*. Do you
> > > > think it would be possible to have hotplug/udev/whatever exists in the
> > > > future to give that information back in the kernel and have it appear
> > > > in sysfs?
> > >
> > > No. Why would it when it is very simple to query udevinfo for that?
> >
> > In order not to depend on a userland package for the kernel service of
> > device enumeration? It's udevinfo now, what will it be in two years?
>
> WTF? You are depending on that same program to create your device
> nodes. If you don't want to use that program to do it, then use
> something else, or use a static device tree, which works like always.
Funnily enough, my, say, mp3 usb key sync system would like to run as
non-root and does not want to know or care about what program creates
the device nodes. Too bad this otherwise beautiful and useful sysfs
is crippled by design.
> sysfs exports everything that userspace needs to know, if it wants to
> create a device node to talk to that specific device. udev used it to
> create your /dev tree, while other programs use it to create temporary
> device nodes to do other things to your devices. Either way, the kernel
> doesn't know, or care what you call those device nodes.
You mean root is mandatory to talk with devices, whatever they are?
OG.
On Monday 13 February 2006 16:43, Jan Engelhardt wrote:
> >> Well, "any user" just opens his Windows Explorer and takes a look at the
> >> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> >> interesting to see professional programmers often argue that a
> >
> >This is not true: a drive letter mapping does not need to exist on MS-WIN
> >in order to be able to access it via ASPI or SPTI.
>
> I have to support this view. Linux filesystems do not show up in Windows
> Explorer (because there's obviously an fs driver lacking), but there's
> always a way to damage your Linux from within Windows.
Really? My Windows-using friend has all his Linux partitions fully visible and
usable in Windows Explorer...
On Mon, Feb 13, 2006 at 05:49:11PM +0100, Olivier Galibert wrote:
> On Sun, Feb 12, 2006 at 10:24:12PM -0800, Greg KH wrote:
> > On Sun, Feb 12, 2006 at 10:14:06PM +0100, Olivier Galibert wrote:
> > > On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote:
> > > > On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote:
> > > > > You need to call udevinfo for that, or parse /dev/.udev/*. Do you
> > > > > think it would be possible to have hotplug/udev/whatever exists in the
> > > > > future to give that information back in the kernel and have it appear
> > > > > in sysfs?
> > > >
> > > > No. Why would it when it is very simple to query udevinfo for that?
> > >
> > > In order not to depend on a userland package for the kernel service of
> > > device enumeration? It's udevinfo now, what will it be in two years?
> >
> > WTF? You are depending on that same program to create your device
> > nodes. If you don't want to use that program to do it, then use
> > something else, or use a static device tree, which works like always.
>
> Funnily enough, my, say, mp3 usb key sync system would like to run as
> non-root and does not want to know or care about what program creates
> the device nodes. Too bad this otherwise beautiful and useful sysfs
> is crippled by design.
Huh? What sysfs design flaw is that?
You can run your mp3 usb ksy sync system as non-root just fine, I do
just that. When my device is plugged in, a udev rule runs a script that
changes users and resyncs my device.
But that has nothing to do with sysfs at all.
> > sysfs exports everything that userspace needs to know, if it wants to
> > create a device node to talk to that specific device. udev used it to
> > create your /dev tree, while other programs use it to create temporary
> > device nodes to do other things to your devices. Either way, the kernel
> > doesn't know, or care what you call those device nodes.
>
> You mean root is mandatory to talk with devices, whatever they are?
Not at all. You only have to be root to create a device node, nothing
new there.
thanks,
greg k-h
On Mon, Feb 13, 2006 at 03:05:49AM -0500, Daniel Barkalow wrote:
> On Sun, 12 Feb 2006, Greg KH wrote:
>
> > On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote:
> > > sysfs doesn't do quite that level of categorization; if it did, cdrom_id
> > > would be unnecessary.
> >
> > What? cdrom_id queries the device directly to get some specific
> > information about the device, much like any other type of device query
> > (lspci, lsusb, etc.)
> >
> > And yes, it would be nice if some of that information was also exported
> > through sysfs, and as always, patches are gladly accpeted.
>
> Are there guidelines on having a generic cdrom export information from its
> block interface, rather than through its bus? I'm not finding any
> documentation of sys/block/, aside from that it exists.
That information should go into the device directory, not the sys/block
directory (as it referrs to the device attributes, not the block gendev
attributes.)
thanks,
greg k-h
On 2/13/06, Greg KH <[email protected]> wrote:
> On Mon, Feb 13, 2006 at 03:05:49AM -0500, Daniel Barkalow wrote:
> > On Sun, 12 Feb 2006, Greg KH wrote:
> >
> > > On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote:
> > > > sysfs doesn't do quite that level of categorization; if it did, cdrom_id
> > > > would be unnecessary.
> > >
> > > What? cdrom_id queries the device directly to get some specific
> > > information about the device, much like any other type of device query
> > > (lspci, lsusb, etc.)
> > >
> > > And yes, it would be nice if some of that information was also exported
> > > through sysfs, and as always, patches are gladly accpeted.
> >
> > Are there guidelines on having a generic cdrom export information from its
> > block interface, rather than through its bus? I'm not finding any
> > documentation of sys/block/, aside from that it exists.
>
> That information should go into the device directory, not the sys/block
> directory (as it referrs to the device attributes, not the block gendev
> attributes.)
>
Not necessarily - it would be easier for userspace programs if we had
a separate class in sysfs - /sys/class/cdrom. The problem with this
approach is that we do not allow a device belong o several classes
without introducing intermediate class devices (I mean a DVD+RW shoudl
probably belong to classes cdrom, dvdrom, cdwriter and dvdwriter).
--
Dmitry
On Mon, 13 Feb 2006, Dmitry Torokhov wrote:
> On 2/13/06, Greg KH <[email protected]> wrote:
> > On Mon, Feb 13, 2006 at 03:05:49AM -0500, Daniel Barkalow wrote:
> > > Are there guidelines on having a generic cdrom export information from its
> > > block interface, rather than through its bus? I'm not finding any
> > > documentation of sys/block/, aside from that it exists.
> >
> > That information should go into the device directory, not the sys/block
> > directory (as it referrs to the device attributes, not the block gendev
> > attributes.)
> >
>
> Not necessarily - it would be easier for userspace programs if we had
> a separate class in sysfs - /sys/class/cdrom. The problem with this
> approach is that we do not allow a device belong o several classes
> without introducing intermediate class devices (I mean a DVD+RW shoudl
> probably belong to classes cdrom, dvdrom, cdwriter and dvdwriter).
I don't think it needs to be a class, but I think that there should be a
single place with a directory for each device that could be what you want,
with a file that tells you if it is. That's why I was looking at block/;
these things must be block devices, and there aren't an huge number of
block devices.
I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I hadn't
dug far enough in to realize that the reason I wasn't seeing anything
informative in /sys/block/*/device/ was that I didn't have any devices
with informative drivers, not that it was actually supposed to only have
links to other things.
-Daniel
*This .sig left intentionally blank*
On Mon, Feb 13, 2006 at 09:50:46AM -0800, Greg KH wrote:
> On Mon, Feb 13, 2006 at 05:49:11PM +0100, Olivier Galibert wrote:
> > You mean root is mandatory to talk with devices, whatever they are?
>
> Not at all. You only have to be root to create a device node, nothing
> new there.
Ok, since I don't think you're being deliberately dense, please pick
up your beverage of choice in order to clear up your head and let's
start again calmly.
Problem: finding and talking to all the devices which have capability
<x>, as long as the system administrator allows.
Examples of <x> can be:
- Maxgate hard drive I can do firmware upgrades on
- Motokia phone I can exchange data with
- CD/DVD drive, with or without writing capabilities
The hard drive can be ide, sata or in a usb enclosure. The phone can
be connected through serial-over-usb or serial-over-bluetooth, etc.
At that point, we get several answers:
1- You do not need to do device enumeration, the user has to know the
devices names, period.
2- Hal knows it, ask him
3- Udev knows it, ask him
4- sysfs has all the information you need, just read it
Answer 1 gets a little tiring after a while. Usability starts by not
asking the user things you can know automatically.
Answer 2 is a little annoying. Hal/dbus are not at 1.0 at that point
yet, especially Hal. The constraints they put on programs and
especially on libraries can be a little hard to swallow, mandatory
glib for a start. It's a little too much for such low-level needs.
OTOH, it has the advantage of being able to tell you dynamically of
new devices being connected.
Answer 3 is even more annoying. Udev is not very good at backwards
compatibility (udevinfo -d of fedora core 3, i.e. udev-039, is
udevinfo -e in later versions for instance). Udev is obviously not
mandatory, and may be replaced in two years or less (remember
/sbin/hotplug's fate?). And frankly, should programs that just want
to find devices have to know about the program-of-the-day for device
node creation? It also has the problem of requiring a
fork()+exec()+output parsing, which from a library context can be
annoying at best.
Answer 4 would be very nice if it was correct. sysfs is pretty much
mandatory at that point, and modulo some fixable incompleteness
provides all the capability information and model names and everything
needed to find the useful devices. What it does not provide is the
mapping between a device as found in sysfs, and a device node you can
open to talk to the device. You get the major/minor, which allows you
to create a temporary device node iff you're root. Or you can scan
all the nodes in /dev to find the one to open, which is kinda
ridiculous and inefficient. Or you have to go back to udev/hal to ask
for the sysfs node/device node path mapping, and then why use sysfs in
the first place.
At that point, sysfs would be the best choice for device enumeration
from a user program, from a point of view of resilience to userspace
fad changes and simplicity/weight of code. Except that you can't use
it for that. That's annoying.
OG.
On Mon, 13 Feb 2006, Joerg Schilling stated:
> Greg KH <[email protected]> wrote:
>
>> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
>> >
>> > 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.
>>
>> It does so today in sysfs, that is what it is there for.
>
> Do you really whant libscg to open _every_ non-directory file under /sys?
Well, that would be overkill, but iterating across, say,
/sys/class/scsi_device seems like it would be a good idea.
(I doubt libscg would ever be interested in the stuff in most of the
other directories: things like /dev/mem are not SCSI devices and never
will be, and /sys/class/scsi_device contains *everything* Linux
considers a SCSI device, no matter what transport it is on, SATA and
all. However, I don't know if it handles IDE devices that you can SG_IO
to because I don't have any such here. Anyone know?)
--
`... follow the bouncing internment camps.' --- Peter da Silva
On Monday 13 February 2006 08:24, Joerg Schilling wrote:
> Christian Neumair <[email protected]> wrote:
> > Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen:
> > > 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.
> >
> > Introducing more than interface for doing the same thing can be very
> > confusing and counter-productive. You'll create new, undocumented or
> > semi-documented interfaces which will lead to a dependency chaos.
>
> So you concur with me that the fact that Linux introduced another interface
> for SCSI was onfusing and counter-productive.
And look - ide-scsi is going away. So that "new" interface is disappearing.
<snip>
> > > 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...
> >
> > Well, "any user" just opens his Windows Explorer and takes a look at the
> > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> > interesting to see professional programmers often argue that a
>
> This is not true: a drive letter mapping does not need to exist on MS-WIN
> in order to be able to access it via ASPI or SPTI.
And only true in those cases, although I have seen (thanks to necessity, not
choice) that NT (and therefore Win32) does do btl mappings internally at
least at boot. But if you claim that SPTI or ASPI is necessary to burn CD's
on windows you are sadly mistaken. There are a number of programs which
_might_ do ASPI internally, but never export the interface, so how does
Windows use it? And with XP, again, thanks to necessity (making money in both
cases) I can easily state that Windows does burning _internally_ without
ASPI. (which I know doesn't exist because of complaints form WinAmp about the
same)
DRH
On Monday 13 February 2006 17:14, Nix wrote:
> On Mon, 13 Feb 2006, Joerg Schilling stated:
> > Greg KH <[email protected]> wrote:
> >> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> >> > 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.
> >>
> >> It does so today in sysfs, that is what it is there for.
> >
> > Do you really whant libscg to open _every_ non-directory file under /sys?
>
> Well, that would be overkill, but iterating across, say,
> /sys/class/scsi_device seems like it would be a good idea.
>
> (I doubt libscg would ever be interested in the stuff in most of the
> other directories: things like /dev/mem are not SCSI devices and never
> will be, and /sys/class/scsi_device contains *everything* Linux
> considers a SCSI device, no matter what transport it is on, SATA and
> all. However, I don't know if it handles IDE devices that you can SG_IO
> to because I don't have any such here. Anyone know?)
Not on my system, and I have a DVD-ROM and a CDRW drive attached, both of
which are capable of SG_IO.
DRH
On Mon, 13 Feb 2006, D. Hazelton whispered secretively:
> On Monday 13 February 2006 17:14, Nix wrote:
>> (I doubt libscg would ever be interested in the stuff in most of the
>> other directories: things like /dev/mem are not SCSI devices and never
>> will be, and /sys/class/scsi_device contains *everything* Linux
>> considers a SCSI device, no matter what transport it is on, SATA and
>> all. However, I don't know if it handles IDE devices that you can SG_IO
>> to because I don't have any such here. Anyone know?)
>
> Not on my system, and I have a DVD-ROM and a CDRW drive attached, both of
> which are capable of SG_IO.
Blast. Well, all these SCSI-like things *should* appear in one place
in /sys, dammit. Even if they don't right now. :/
--
`... follow the bouncing internment camps.' --- Peter da Silva
On Monday 13 February 2006 14:53, Olivier Galibert wrote:
> Problem: finding and talking to all the devices which have capability
> <x>, as long as the system administrator allows.
...
> At that point, we get several answers:
...
> 4- sysfs has all the information you need, just read it
...
> Answer 4 would be very nice if it was correct. sysfs is pretty much
> mandatory at that point, and modulo some fixable incompleteness
> provides all the capability information and model names and everything
> needed to find the useful devices. What it does not provide is the
> mapping between a device as found in sysfs, and a device node you can
> open to talk to the device. You get the major/minor, which allows you
> to create a temporary device node iff you're root. Or you can scan
> all the nodes in /dev to find the one to open, which is kinda
> ridiculous and inefficient. Or you have to go back to udev/hal to ask
> for the sysfs node/device node path mapping, and then why use sysfs in
> the first place.
They're providing different things. Enumerating devices (as the kernel
sees them) is sysfs's business. Providing device nodes is not the kernel's
business, and should not be. (The kernel doesn't know the appropriate
permissions). And while it can be used to enumerate devices, that's not
really the function of /dev. It's providing the device nodes with the
appropriate permissions, and hopefully with names that are meaningful
to the users. So you really need both sysfs and /dev. The difficulty is
the mapping between sysfs and /dev. That mapping should not live in sysfs,
/dev is none of the kernel's business and sysfs is the kernel's playground.
The mapping could be provided via symlinks, like so:
/dev/rdev/block/hdb/hdb1 -> /dev/hdb1
/dev/rdev/block/hdb -> /dev/hdb
/dev/rdev/block/hda/hda2 -> /dev/hda2
/dev/rdev/block/hda/hda1 -> /dev/hda1
/dev/rdev/block/hda -> /dev/hda
...
But I don't know if there is much point in doing so as udev already
provides that information.
Andrew Wade
>> >> Well, "any user" just opens his Windows Explorer and takes a look at the
>> >> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
>> >> interesting to see professional programmers often argue that a
>> >
>> >This is not true: a drive letter mapping does not need to exist on MS-WIN
>> >in order to be able to access it via ASPI or SPTI.
>>
>> I have to support this view. Linux filesystems do not show up in Windows
>> Explorer (because there's obviously an fs driver lacking), but there's
>> always a way to damage your Linux from within Windows.
>
>Really? My Windows-using friend has all his Linux partitions fully visible and
>usable in Windows Explorer...
>
Might depend! On DOS and Win98, there is no indication in either
DOS or Explorer that there is a second harddisk (got an xfs on it) at all.
Only partition entries with Win* type get a drive letter (which does not
imply reading is also possible).
Might be different on your Windows.
Jan Engelhardt
--
On Mon, 13 Feb 2006, Nix wrote:
> (I doubt libscg would ever be interested in the stuff in most of the
> other directories: things like /dev/mem are not SCSI devices and never
> will be, and /sys/class/scsi_device contains *everything* Linux
> considers a SCSI device, no matter what transport it is on, SATA and
> all. However, I don't know if it handles IDE devices that you can SG_IO
> to because I don't have any such here. Anyone know?)
My ATAPI DVD and CD writers are not listed in /sys/class/scsi_device.
--
Matthias Andree
On Tue, Feb 14, 2006 at 12:23:15AM -0500, Andrew James Wade wrote:
> On Monday 13 February 2006 14:53, Olivier Galibert wrote:
> > Problem: finding and talking to all the devices which have capability
> > <x>, as long as the system administrator allows.
> ...
> > At that point, we get several answers:
> ...
> > 4- sysfs has all the information you need, just read it
> ...
> > Answer 4 would be very nice if it was correct. sysfs is pretty much
> > mandatory at that point, and modulo some fixable incompleteness
> > provides all the capability information and model names and everything
> > needed to find the useful devices. What it does not provide is the
> > mapping between a device as found in sysfs, and a device node you can
> > open to talk to the device. You get the major/minor, which allows you
> > to create a temporary device node iff you're root. Or you can scan
> > all the nodes in /dev to find the one to open, which is kinda
> > ridiculous and inefficient. Or you have to go back to udev/hal to ask
> > for the sysfs node/device node path mapping, and then why use sysfs in
> > the first place.
> They're providing different things. Enumerating devices (as the kernel
> sees them) is sysfs's business. Providing device nodes is not the kernel's
> business, and should not be. (The kernel doesn't know the appropriate
> permissions). And while it can be used to enumerate devices, that's not
> really the function of /dev. It's providing the device nodes with the
> appropriate permissions, and hopefully with names that are meaningful
> to the users. So you really need both sysfs and /dev.
Indeed.
> The difficulty is the mapping between sysfs and /dev.
Which is what I say each time.
> That mapping should not live in sysfs,
> /dev is none of the kernel's business and sysfs is the kernel's playground.
Why not have udev and whatever comes after tell the kernel so that a
symlink is done in sysfs? The kernel not deciding policy do not
prevent it from storing and giving back userland-provided information.
You get the best of both worlds, complete device information including
how to talk with it in sysfs, and complete naming and policy setting
in userspace.
>
> The mapping could be provided via symlinks, like so:
>
> /dev/rdev/block/hdb/hdb1 -> /dev/hdb1
> /dev/rdev/block/hdb -> /dev/hdb
> /dev/rdev/block/hda/hda2 -> /dev/hda2
> /dev/rdev/block/hda/hda1 -> /dev/hda1
> /dev/rdev/block/hda -> /dev/hda
Why manage a directory tree in udev when you have a perfectly good one
in sysfs already. We're talking about a friggin' userland-provided
string here, nothing more.
> But I don't know if there is much point in doing so as udev already
> provides that information.
I guess you didn't bother to read the "answer 3" paragraph of my
email. Do you trust udev to still exist two years from now, given
that hotplug died in less than that? Do you trust udevinfo to have
the same interface two years from now given that the current interface
is already incompatible with a not even two-years old one (udev 039,
15-Oct-2004 according to kernel.org) which is widely deployed as part
of fedora core 3?
Of course I can always go the ALSA way, hardcode the device names and
tell udev (and the user) to fuck off.
OG.
Nix <[email protected]> wrote:
> > Do you really whant libscg to open _every_ non-directory file under /sys?
>
> Well, that would be overkill, but iterating across, say,
> /sys/class/scsi_device seems like it would be a good idea.
>
> (I doubt libscg would ever be interested in the stuff in most of the
> other directories: things like /dev/mem are not SCSI devices and never
> will be, and /sys/class/scsi_device contains *everything* Linux
> considers a SCSI device, no matter what transport it is on, SATA and
> all. However, I don't know if it handles IDE devices that you can SG_IO
> to because I don't have any such here. Anyone know?)
This statement is obviously not true :-(
Let us start in a way that makes sense:
Please send me the whitepaper that was used to define the interfaces
and functionality of the /sys device
Please send me the other documentation (e.g. man pages) on the /sys
device
Please send me a statement on how long this interface will be maintained
inside Linux without breaking interfaces.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Olivier Galibert wrote:
[]
> 4- sysfs has all the information you need, just read it
[]
> Answer 4 would be very nice if it was correct. sysfs is pretty much
> mandatory at that point, and modulo some fixable incompleteness
> provides all the capability information and model names and everything
> needed to find the useful devices. What it does not provide is the
> mapping between a device as found in sysfs, and a device node you can
> open to talk to the device. You get the major/minor, which allows you
> to create a temporary device node iff you're root. Or you can scan
> all the nodes in /dev to find the one to open, which is kinda
> ridiculous and inefficient. Or you have to go back to udev/hal to ask
> for the sysfs node/device node path mapping, and then why use sysfs in
> the first place.
That's exactly the point why I always wanted to have automatic minimal-devfs-
alike in kernel, similar to ndevfs but complete: so that kernel names of
defices are *always* present in /dev, regardless of the presense of udev or
something else. All the rest - udev, device permissions, "alternative"
names (like /dev/cdrom etc) can be built on top of that "kernel naming scheme",
but the key point is that we *always* have a device in /dev/ named exactly
the same as kernel "thinks" of it - so eg, /proc/partitions, dmesg output,
sysfs scanning etc etc will produce real and useful results.
But oh.. Am I starting new [n]devfs flamewar?
/mjt
"D. Hazelton" <[email protected]> wrote:
> On Monday 13 February 2006 08:24, Joerg Schilling wrote:
> > Christian Neumair <[email protected]> wrote:
> > > Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen:
> > > > 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.
> > >
> > > Introducing more than interface for doing the same thing can be very
> > > confusing and counter-productive. You'll create new, undocumented or
> > > semi-documented interfaces which will lead to a dependency chaos.
> >
> > So you concur with me that the fact that Linux introduced another interface
> > for SCSI was onfusing and counter-productive.
>
> And look - ide-scsi is going away. So that "new" interface is disappearing.
Try to find out what's new and what's old.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>
>> (I doubt libscg would ever be interested in the stuff in most of the
>> other directories: things like /dev/mem are not SCSI devices and never
>> will be, and /sys/class/scsi_device contains *everything* Linux
>> considers a SCSI device, no matter what transport it is on, SATA and
>> all. However, I don't know if it handles IDE devices that you can SG_IO
>> to because I don't have any such here. Anyone know?)
>
>My ATAPI DVD and CD writers are not listed in /sys/class/scsi_device.
>
My IDE one is neither nowhere in /sys/class. (Maybe I did not try looking
hard enough, though.)
Jan Engelhardt
--
On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> Greg KH <[email protected]> wrote:
>
> > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > >
> > > 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.
> >
> > It does so today in sysfs, that is what it is there for.
>
> Do you really whant libscg to open _every_ non-directory file under /sys?
Of course not. Here's one line of bash that gets you the major:minor
file of every block device in the system:
block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
The block devices are all in a specific location.
And here's a way to get the cdroms of the system:
media="$(echo /sys/block/*/device/media)"
for i in $media; do
type="$(cat $i)"
if [ "${type}" == "cdrom" ]
then
# we have a cdrom here, at $media block device
fi
done
If you want to do this in C, there is a libsysfs, which should help you
out a bit on intregrating sysfs support into your program (although udev
has recently ripped it out and replaced it with 200 lines of code that
is way smaller and much faster...)
Hope this helps,
greg k-h
On Tue, Feb 14, 2006 at 07:09:19PM +0100, Jan Engelhardt wrote:
> My IDE one is neither nowhere in /sys/class. (Maybe I did not try looking
> hard enough, though.)
Why care, official policy is that you should do device discovery
through udevinfo and not touch sysfs.
OG.
On Mon, Feb 13, 2006 at 07:49:21AM -0800, Greg KH wrote:
> On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > Greg KH <[email protected]> wrote:
> >
> > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > >
> > > > 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.
> > >
> > > It does so today in sysfs, that is what it is there for.
> >
> > Do you really whant libscg to open _every_ non-directory file under /sys?
>
> Of course not. Here's one line of bash that gets you the major:minor
> file of every block device in the system:
> block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
Of course, that's entirely useless if you're not root.
So what you _really_ have to do is to call udevinfo -e. If that
fails, call udevinfo -d, that's the old name for the option which got
changed along the way. The result is blocks of text lines separated
by blank lines, text lines of the form:
I: value
Where I is a one-letter uppercase identifier, and value a value.
If you get E: entries, you're lucky. All cdroms have a E: ID_CDROM=1
entry, but these entries appeared late. Otherwise, the best bet is to
scan the S: entries for something matching /cdrom/. When you have a
bloc of lines, get the N: entry, that's the node name, and prepend it
with the result of udevinfo -r (usually /dev/, but that's not
mandatory). That will give you the device node path to open (don't
forget O_EXCL to avoid Hal stomping all over you), which you can then
use SG_IO with.
If udevinfo is not available, you'll have to try opening all /dev/hd*,
/dev/sr*, /dev/scd*, /dev/sg*, /dev/cdr* and /dev/dvd* (don't stop at
the first -EANYTHING though, otherwise you'll miss some). Then you
can poke the device carefully with SG_IO.
OG.
Greg KH <[email protected]> wrote:
> On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > Greg KH <[email protected]> wrote:
> >
> > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > >
> > > > 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.
> > >
> > > It does so today in sysfs, that is what it is there for.
> >
> > Do you really whant libscg to open _every_ non-directory file under /sys?
>
> Of course not. Here's one line of bash that gets you the major:minor
> file of every block device in the system:
> block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
>
> The block devices are all in a specific location.
Are you sure you understand the problem?
It isd most unlikely that all SCSI devices are there.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Mon, 13 Feb 2006, Greg KH wrote:
> On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > Greg KH <[email protected]> wrote:
> >
> > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > >
> > > > 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.
> > >
> > > It does so today in sysfs, that is what it is there for.
> >
> > Do you really whant libscg to open _every_ non-directory file under /sys?
>
> Of course not. Here's one line of bash that gets you the major:minor
> file of every block device in the system:
> block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
>
> The block devices are all in a specific location.
>
> And here's a way to get the cdroms of the system:
[snip]
>
> If you want to do this in C, there is a libsysfs, which should help you
> out a bit on intregrating sysfs support into your program (although udev
> has recently ripped it out and replaced it with 200 lines of code that
> is way smaller and much faster...)
>
> Hope this helps,
Just determined that at least in FC4 the udev stuff doesn't seem to create
the sg devices, cdrecord doesn't work with devices which use the scsi
interface AFAIK, fails with USB, Firewire, and real SCSI devices.
I'm still looking at this, trying w/o udev.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with little computers since 1979
Joerg Schilling schrieb am 2006-02-14:
> It isd most unlikely that all SCSI devices are there.
Mind the topic: "CD writing"
--
Matthias Andree
Matthias Andree <[email protected]> wrote:
> Joerg Schilling schrieb am 2006-02-14:
>
> > It isd most unlikely that all SCSI devices are there.
>
> Mind the topic: "CD writing"
You don't need to repoeat this again, I already know that you are unteachable.
For the others: the topic is the device and OS independent libscg.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-14:
> You don't need to repoeat this again, I already know that you are unteachable.
Yet another insult.
> For the others: the topic is the device and OS independent libscg.
Check the subject line, and check the destination address.
This is CD writing on Linux, and it you who is still failing to provide
information about non-CD-related bugs.
--
Matthias Andree
On Tuesday 14 February 2006 13:59, Joerg Schilling wrote:
> Greg KH <[email protected]> wrote:
> > On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > > Greg KH <[email protected]> wrote:
> > > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > > > 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.
> > > >
> > > > It does so today in sysfs, that is what it is there for.
> > >
> > > Do you really whant libscg to open _every_ non-directory file under
> > > /sys?
> >
> > Of course not. Here's one line of bash that gets you the major:minor
> > file of every block device in the system:
> > block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
> >
> > The block devices are all in a specific location.
>
> Are you sure you understand the problem?
>
> It isd most unlikely that all SCSI devices are there.
>
> J?rg
Which is why there is also /sys/class/scsi_host and /sys/class/scsi_device
those two, together with the block device data available via /sys/block should
be enough to enumerate every ATAPI and SCSI device on the system.
DRH
On Tuesday 14 February 2006 14:58, Joerg Schilling wrote:
> Matthias Andree <[email protected]> wrote:
> > Joerg Schilling schrieb am 2006-02-14:
> > > It isd most unlikely that all SCSI devices are there.
> >
> > Mind the topic: "CD writing"
>
> You don't need to repoeat this again, I already know that you are
> unteachable.
>
> For the others: the topic is the device and OS independent libscg.
> J?rg
In your mind only
This thread started out as "CD writing future in Linux" and that's where it
has been. We all know that you claim all the problems cdrecord has with Linux
are in libscg, but that doesn't excuse you from ignoring the posted topic and
trying to change it so you can rant about how bad the SCSI subsystem in Linux
was designed.
DRH
On Tue, Feb 14, 2006 at 12:27:18PM +0100, Joerg Schilling wrote:
>
> Please send me the whitepaper that was used to define the interfaces
> and functionality of the /sys device
I was not aware that there is now a rule that we must write whitepapers
describing as to what the interface looks like in complete detail that
we want to add to the Linux kernel. Will you please point me to the
proper authorities that will be enforcing this newly created rule?
> Please send me the other documentation (e.g. man pages) on the /sys
> device
What "/sys device"? sysfs is a file system, and there have been many
magazine articles, and conference papers written, and talks given on the
topic.
If you have specific questions as to how it is structured, please let
the current sysfs maintainer know.
> Please send me a statement on how long this interface will be maintained
> inside Linux without breaking interfaces.
It will be stable and maintained until a major program depends on its
structure. Then it will change in new and interesting ways and break
everything :)
Seriously, it isn't going away, and new information is being added all
the time to it. Due to the structure of sysfs, changes in it is very
easy to accomidate.
thanks,
greg k-h
On Tue, Feb 14, 2006 at 11:40:04AM +0100, Olivier Galibert wrote:
> On Tue, Feb 14, 2006 at 12:23:15AM -0500, Andrew James Wade wrote:
> > On Monday 13 February 2006 14:53, Olivier Galibert wrote:
> > > Problem: finding and talking to all the devices which have capability
> > > <x>, as long as the system administrator allows.
> > ...
> > > At that point, we get several answers:
> > ...
> > > 4- sysfs has all the information you need, just read it
> > ...
> > > Answer 4 would be very nice if it was correct. sysfs is pretty much
> > > mandatory at that point, and modulo some fixable incompleteness
> > > provides all the capability information and model names and everything
> > > needed to find the useful devices. What it does not provide is the
> > > mapping between a device as found in sysfs, and a device node you can
> > > open to talk to the device. You get the major/minor, which allows you
> > > to create a temporary device node iff you're root. Or you can scan
> > > all the nodes in /dev to find the one to open, which is kinda
> > > ridiculous and inefficient. Or you have to go back to udev/hal to ask
> > > for the sysfs node/device node path mapping, and then why use sysfs in
> > > the first place.
> > They're providing different things. Enumerating devices (as the kernel
> > sees them) is sysfs's business. Providing device nodes is not the kernel's
> > business, and should not be. (The kernel doesn't know the appropriate
> > permissions). And while it can be used to enumerate devices, that's not
> > really the function of /dev. It's providing the device nodes with the
> > appropriate permissions, and hopefully with names that are meaningful
> > to the users. So you really need both sysfs and /dev.
>
> Indeed.
>
>
> > The difficulty is the mapping between sysfs and /dev.
>
> Which is what I say each time.
>
>
> > That mapping should not live in sysfs,
> > /dev is none of the kernel's business and sysfs is the kernel's playground.
>
> Why not have udev and whatever comes after tell the kernel so that a
> symlink is done in sysfs? The kernel not deciding policy do not
> prevent it from storing and giving back userland-provided information.
> You get the best of both worlds, complete device information including
> how to talk with it in sysfs, and complete naming and policy setting
> in userspace.
Because if you have to have udev push the names back into the kernel,
why not just ask udev in the first place what they were? It's just
pointless to add this to the kernel. It doesn't belong there at all.
Anyway, udev isn't the tool to rely on for this stuff anyway, that's
what HAL is for. If you don't like how HAL is working out, then go take
it up with those developers. And if you have specific udev issues,
please, bring it up on the linux-hotplug-devel mailing list.
Either way, again, it's not a kernel issue.
> I guess you didn't bother to read the "answer 3" paragraph of my
> email. Do you trust udev to still exist two years from now, given
> that hotplug died in less than that?
Huh? Do you know when hotplug showed up? 2.3.99-something. And it
still works just fine today if you want to use it. It hasn't gone away
at all. All that is changed is how the distros use that interface. The
fact that some distros have depreciated how it is used has nothing to do
with the kernel. Take it up with those distros, nothing the kernel
developers can do here.
> Do you trust udevinfo to have the same interface two years from now
> given that the current interface is already incompatible with a not
> even two-years old one (udev 039, 15-Oct-2004 according to kernel.org)
> which is widely deployed as part of fedora core 3?
Again, use HAL, not udev for this stuff. FC3 is also out of date for
lots of things becides udev, so why refer to it?
> Of course I can always go the ALSA way, hardcode the device names and
> tell udev (and the user) to fuck off.
As is your right. Have fun.
greg k-h
On Tuesday 14 February 2006 5:40 am, Olivier Galibert wrote:
> > > 4- sysfs has all the information you need, just read it
There's no ownership or permissions information in sysfs. Even busybox's
eight kilobyte micro-udev replacement has the option for an /etc/mdev.conf to
specify permissions and ownership on device nodes.
> > That mapping should not live in sysfs,
> > /dev is none of the kernel's business and sysfs is the kernel's
> > playground.
>
> Why not have udev and whatever comes after tell the kernel so that a
> symlink is done in sysfs? The kernel not deciding policy do not
> prevent it from storing and giving back userland-provided information.
That wouldn't help us. If userspace generates the info, then userspace can
drop a note in /dev or something to keep it there.
> I guess you didn't bother to read the "answer 3" paragraph of my
> email. Do you trust udev to still exist two years from now, given
> that hotplug died in less than that? Do you trust udevinfo to have
> the same interface two years from now given that the current interface
> is already incompatible with a not even two-years old one (udev 039,
> 15-Oct-2004 according to kernel.org) which is widely deployed as part
> of fedora core 3?
You want something simple and stable?
Busybox's mdev should still be there, and have the same interface, two
years from now. (We may have to fix it between now and then if the kernel
keeps moving out from under us, but that shouldn't change how you set up and
use it.)
When you call "mdev -s", we iterate through /sys/class and sys/block looking
for "dev" nodes containing a "major:minor" string, and take the name of the
directory we find each /dev node in as the name of the device to mknod
in /dev. (As an option, it can check /etc/mdev.conf which has three
space-separated fields: a regex, a numeric colon-separated uid:gid pair, and
octal permissions. "tty[0-9]* 0:42 770". Stops at the first match and uses
that ownership and permission info for the new node. If there's no mdev.conf
or it doesn't match any regex against the name it's creating, it defaults to
0:0 and 660.)
If you call it without -s, it assumes it was called from /sbin/hotplug and
looks at its environment variables to figure out what device node to
create/delete.
That's it. That's all we do. No persistent naming, no device renaming, /dev
is a flat namespace with no subdirectories, mounting tmpfs on it before
calling us is your problem, as is putting /dev/pts and /dev/shm in there...
Changes to the kernel have already managed to break us twice
(switching /sys/class from real subdirectories to symlinks means we can't
just ignore symlinks when recursing down through directories anymore, which
is a problem because the existing symlinks form loops. And
deprecating /sbin/hotplug means we've got to bloat the code with netlink
stuff.) But we'll cope, and the user interface isn't changing.
We can extend the mdev.conf file to specify other stuff. (Such as append a
command line as an optional argument #4 to execute when one of these suckers
is created/destroyed. But so far, it's really really simple and our target
audience hasn't needed more than that.)
If you want to try mdev, grab the most recent snapshot from
busybox.net/downloads/snapshots and build it this way:
make allnoconfig
echo "CONFIG_MDEV=y" >> .config
echo "CONFIG_FEATURE_MDEV_CONF=y" >> .config
make
mv busybox mdev
There you go, standalone 8k binary. It'll come standard in the busybox 1.1.1
release. (It was in 1.1.0, but had a bug.)
Rob
--
Never bet against the cheap plastic solution.
On Tue, 14 Feb 2006, Bill Davidsen stated:
> Just determined that at least in FC4 the udev stuff doesn't seem to create
> the sg devices,
It has done so for as long as I've been using udev (since 058).
What kernel are you using?
--
`... follow the bouncing internment camps.' --- Peter da Silva
On Tue, 14 Feb 2006, Joerg Schilling wrote:
> Please send me the whitepaper that was used to define the interfaces
> and functionality of the /sys device
If you seriously think that development of *anything* in the free
software world happens by means of whitepapers preceding definition, or
indeed that anything major in the Unix world has ever worked that way,
you're seriously deluded.
> Please send me the other documentation (e.g. man pages) on the /sys
> device
Oh, I thought you had *access* to the kernel source. A trivial grep
under the Documentation directory would find it (hint:
Documentation/filesystems/ is a good place to start.)
If you actually wanted to *fix* your program --- if you cared more about
users than being proved right no matter what --- then you'd have been
able to determine that for yourself in seconds.
(But then we all know that's not what you're actually after.)
> Please send me a statement on how long this interface will be maintained
> inside Linux without breaking interfaces.
What a ridiculous request. If people use it, it won't be broken. If it
proves unusable due to flaws, it will change. Sheesh.
(It is not as robust as the syscall interface, but it is still subject
to some degree of change. A trivial google would have made this clear.)
You appear not to understand the difference between development
roadmapped for years in advance by a sclerotic corporation and free
software development. Or perhaps you do understand, and are just being
pointlessly contrary. (I expect the latter is true. You're not stupid.
Just nasty.)
--
`... follow the bouncing internment camps.' --- Peter da Silva
On Tue, Feb 14, 2006 at 02:24:28PM -0800, Greg KH wrote:
> Because if you have to have udev push the names back into the kernel,
> why not just ask udev in the first place what they were?
Because there is no reason to think udev of 2008 will be compatible
with today's udev given udev's history. And that's provided udev is
still in use at that time.
> Again, use HAL, not udev for this stuff. FC3 is also out of date for
> lots of things becides udev, so why refer to it?
Because it proves you don't give a shit about backwards compatibility.
There are a lot of fc3 installations out there still. And I'm sure
there are other distributions besides that one that made the mistake
to trust the udev developers to respect the compatibility implicit
contract.
At that point Hal is *not* considered stable interface-wise by its own
developpers, so using it for anything that's supposed to stay working
for a while is *stupid*. When they decide it's 1.0 time, we'll talk.
Even *dbus* is not 1.0 yet in large part for interface stabilization
reasons.
OG.
On Tue, Feb 14, 2006 at 05:32:22PM -0500, Rob Landley wrote:
> You want something simple and stable?
I'd love to. I'm afraid the third condition is "actually used by the
main distributions".
> Busybox's mdev should still be there, and have the same interface, two
> years from now. (We may have to fix it between now and then if the kernel
> keeps moving out from under us, but that shouldn't change how you set up and
> use it.)
Neat.
> When you call "mdev -s", we iterate through /sys/class and sys/block looking
> for "dev" nodes containing a "major:minor" string, and take the name of the
> directory we find each /dev node in as the name of the device to mknod
> in /dev. (As an option, it can check /etc/mdev.conf which has three
> space-separated fields: a regex, a numeric colon-separated uid:gid pair, and
> octal permissions. "tty[0-9]* 0:42 770". Stops at the first match and uses
> that ownership and permission info for the new node. If there's no mdev.conf
> or it doesn't match any regex against the name it's creating, it defaults to
> 0:0 and 660.)
I do like the simplicity. It would be easy to have a "symlink to
create field" for user convenience too. Distinguishing between
devices can be left into the hands of the applications usually. Too
many devices do not have unique serial numbers to make a pure
sysfs-based approach reliable, and you don't want the same heuristics
to recognize two dvd writers (bus position, model) from two mp3 usb
keys (list of files, possibly a text file with owner information...).
> If you call it without -s, it assumes it was called from /sbin/hotplug and
> looks at its environment variables to figure out what device node to
> create/delete.
Hmmm, hotplug is also used to pick up firmwares.
> That's it. That's all we do. No persistent naming, no device renaming, /dev
> is a flat namespace with no subdirectories, mounting tmpfs on it before
> calling us is your problem, as is putting /dev/pts and /dev/shm in there...
No subdirectories? ALSA breaks then. They hardcode
/dev/snd/line_noise in a bunch of places in their mandatory library.
> Changes to the kernel have already managed to break us twice
> (switching /sys/class from real subdirectories to symlinks means we can't
> just ignore symlinks when recursing down through directories anymore, which
> is a problem because the existing symlinks form loops. And
> deprecating /sbin/hotplug means we've got to bloat the code with netlink
> stuff.) But we'll cope, and the user interface isn't changing.
sysfs is getting notorious for not caring about backwards
compatibility. "Put it in userspace" and "put it in a filesystem"
seems to be the two main ways to go around Linus, Andrews and others
good taste filter.
> We can extend the mdev.conf file to specify other stuff. (Such as append a
> command line as an optional argument #4 to execute when one of these suckers
> is created/destroyed. But so far, it's really really simple and our target
> audience hasn't needed more than that.)
>
> If you want to try mdev, grab the most recent snapshot from
> busybox.net/downloads/snapshots and build it this way:
>
> make allnoconfig
> echo "CONFIG_MDEV=y" >> .config
> echo "CONFIG_FEATURE_MDEV_CONF=y" >> .config
> make
> mv busybox mdev
>
> There you go, standalone 8k binary. It'll come standard in the busybox 1.1.1
> release. (It was in 1.1.0, but had a bug.)
Very nice. Too bad distributions do not seem really interested by
picking it up at that point. OTOH, if the lack of compatibility crap
goes on they may.
OG.
On Tue, Feb 14, 2006 at 05:32:22PM -0500, Rob Landley wrote:
> On Tuesday 14 February 2006 5:40 am, Olivier Galibert wrote:
> > Why not have udev and whatever comes after tell the kernel so that a
> > symlink is done in sysfs? The kernel not deciding policy do not
> > prevent it from storing and giving back userland-provided information.
>
> That wouldn't help us. If userspace generates the info, then userspace can
> drop a note in /dev or something to keep it there.
And all I've been saying is that userspace:
1- should drop a filesystem-level note, not require calling an
executable with a time-varying interface and no real reason to
think it will still be in use in a couple of years
2- should drop it in sysfs, because:
a- if it is there and cleanly defined, and "use this netlink
message to have a symlink created in sysfs pointing to the node you
just created" is clean and simple enough, all the concurrent
device-node generating tools will support it quickly (hotplug,
udev, mdev, maybe others, who knows)
b- nothing requires at that point the devices to be in /dev
c- sysfs already manages all the directory hierarchy or naming you
need to define uniquely a device, why replicate it somewhere else?
At that point I guess I just need to make a patch for the kernel side
and then we'll see.
OG.
On Wed, Feb 15, 2006 at 12:00:23AM +0100, Olivier Galibert wrote:
> On Tue, Feb 14, 2006 at 02:24:28PM -0800, Greg KH wrote:
> > Because if you have to have udev push the names back into the kernel,
> > why not just ask udev in the first place what they were?
>
> Because there is no reason to think udev of 2008 will be compatible
> with today's udev given udev's history. And that's provided udev is
> still in use at that time.
Just like gnome and kde of 2008 will not be compatible with the gnome
and kde of today.
> > Again, use HAL, not udev for this stuff. FC3 is also out of date for
> > lots of things becides udev, so why refer to it?
>
> Because it proves you don't give a shit about backwards compatibility.
*plonk*
On Tue, Feb 14, 2006 at 05:32:22PM -0500, Rob Landley wrote:
> Changes to the kernel have already managed to break us twice
> (switching /sys/class from real subdirectories to symlinks means we can't
> just ignore symlinks when recursing down through directories anymore, which
> is a problem because the existing symlinks form loops.
I've shown a simple way to handle this, so this should not be a problem
anymore.
> And deprecating /sbin/hotplug means we've got to bloat the code with
> netlink stuff.) But we'll cope, and the user interface isn't
> changing.
Since when is /sbin/hotplug "depreciated"? It still works just fine,
and isn't going anywhere anytime soon.
Turns out that some distros just don't want to use it, and use netlink
instead. That should not stop you from using it if you wish, as the
kernel sure doesn't care one way or the other.
thanks,
greg k-h
On Tuesday 14 February 2006 6:17 pm, Olivier Galibert wrote:
> > When you call "mdev -s", we iterate through /sys/class and sys/block
> > looking for "dev" nodes containing a "major:minor" string, and take the
> > name of the directory we find each /dev node in as the name of the device
> > to mknod in /dev. (As an option, it can check /etc/mdev.conf which has
> > three space-separated fields: a regex, a numeric colon-separated uid:gid
> > pair, and octal permissions. "tty[0-9]* 0:42 770". Stops at the first
> > match and uses that ownership and permission info for the new node. If
> > there's no mdev.conf or it doesn't match any regex against the name it's
> > creating, it defaults to 0:0 and 660.)
>
> I do like the simplicity. It would be easy to have a "symlink to
> create field" for user convenience too. Distinguishing between
> devices can be left into the hands of the applications usually. Too
> many devices do not have unique serial numbers to make a pure
> sysfs-based approach reliable, and you don't want the same heuristics
> to recognize two dvd writers (bus position, model) from two mp3 usb
> keys (list of files, possibly a text file with owner information...).
I don't want to complicate mdev any more than necessary, but I've pondered
adding a shellout capability from the config file where you can spawn an
arbitrary command line when the device is created/destroyed.
Pretty much "punt to a user supplied shell script" for anything complicated.
The three most interesting variables you could stick in said command line are
where in /sys does the device live, what's the /dev name we just created, and
was the device just inserted or deleted? (We could set a half-dozen
environment variables with what we know about the device. For hotplug
several are already set for us.)
We've been waiting for somebody to actually _need_ this before trying to
design it, though.
> > If you call it without -s, it assumes it was called from /sbin/hotplug
> > and looks at its environment variables to figure out what device node to
> > create/delete.
>
> Hmmm, hotplug is also used to pick up firmwares.
Shellout capability, again.
> > That's it. That's all we do. No persistent naming, no device renaming,
> > /dev is a flat namespace with no subdirectories, mounting tmpfs on it
> > before calling us is your problem, as is putting /dev/pts and /dev/shm in
> > there...
>
> No subdirectories? ALSA breaks then. They hardcode
> /dev/snd/line_noise in a bunch of places in their mandatory library.
I'm torn between "nuts to alsa", pointing out that "ln -s /dev /dev/snd"
should shut it up nicely, and thinking up a way to actually do what it wants.
If there's a real need for subdirectories, I'm sure we can come up with a way
to shunt stuff into them. (Of course a shellout could do it, but if it's
common enough we could build something into mdev...)
The easy one's the symlink, assuming there are no name collisions flinging
everything into one directory...
> > Changes to the kernel have already managed to break us twice
> > (switching /sys/class from real subdirectories to symlinks means we can't
> > just ignore symlinks when recursing down through directories anymore,
> > which is a problem because the existing symlinks form loops. And
> > deprecating /sbin/hotplug means we've got to bloat the code with netlink
> > stuff.) But we'll cope, and the user interface isn't changing.
>
> sysfs is getting notorious for not caring about backwards
> compatibility. "Put it in userspace" and "put it in a filesystem"
> seems to be the two main ways to go around Linus, Andrews and others
> good taste filter.
I plan to start objecting earlier in future next time they propose to break us
for no readily apparent reason.
The best way to stabilize an interface is to have users object, and udev
doesn't count. Not only do they implement both the kernel and the userspace
side, but in project management terms anybody who approaches shared libraries
by keeping their own custom copy of the library source in their project
source tree... Not exactly a role model for respecting and stabilizing the
interfaces they link against. Not that I ever understood what libsysfs was
for anyway, since the point of sysfs is to be _easy_to_parse_... But I'm
also not surprised libsysfs dried up and blew away when it's main user forked
the project.
If mdev accomplishes nothing else, we can poke Linus and go "no fair, this was
exported to userspace and we depend on it", which udev hasn't.
> > We can extend the mdev.conf file to specify other stuff. (Such as append
> > a command line as an optional argument #4 to execute when one of these
> > suckers is created/destroyed. But so far, it's really really simple and
> > our target audience hasn't needed more than that.)
> >
> > If you want to try mdev, grab the most recent snapshot from
> > busybox.net/downloads/snapshots and build it this way:
> >
> > make allnoconfig
> > echo "CONFIG_MDEV=y" >> .config
> > echo "CONFIG_FEATURE_MDEV_CONF=y" >> .config
> > make
> > mv busybox mdev
> >
> > There you go, standalone 8k binary. It'll come standard in the busybox
> > 1.1.1 release. (It was in 1.1.0, but had a bug.)
>
> Very nice. Too bad distributions do not seem really interested by
> picking it up at that point. OTOH, if the lack of compatibility crap
> goes on they may.
It didn't _exist_ six months ago. The first release of it (which had a bug)
was in January. The first version they really _could_ pick up is current
-svn, and should be in the next official release (sometime this week, I'm
working on it...)
They haven't really had the opportunity to become interested yet.
On a related note, a future version of busybox (possibly 1.1.2) will have a
"make standalone" mode that creates individual binaries instead of the the
one big swiss-army-knife version. The end result isn't quite as small as the
one big binary, but it's much easier to pick and choose what you want...
> OG.
Rob
--
Never bet against the cheap plastic solution.
On Tue, 14 Feb 2006, Greg KH wrote:
> On Tue, Feb 14, 2006 at 12:27:18PM +0100, Joerg Schilling wrote:
> >
> > Please send me the whitepaper that was used to define the interfaces
> > and functionality of the /sys device
>
> I was not aware that there is now a rule that we must write whitepapers
> describing as to what the interface looks like in complete detail that
> we want to add to the Linux kernel. Will you please point me to the
> proper authorities that will be enforcing this newly created rule?
Well, J?rg's questions, although ridiculously exaggerated and quixotic,
show a general problem in Linux: documentation is constantly outdated,
missing, and not part of the kernel package.
If Linux were based in Utopia, it would ship with a complete set of
kernel-related manual pages and HOWTOs.
I appreciate the efforts of the old and new man-pages maintainers, and I
know the problems in motivation when writing documentation and keeping
it up to date distracts people from writing code -- but those people
know their code best.
> > Please send me the other documentation (e.g. man pages) on the /sys
> > device
>
> What "/sys device"? sysfs is a file system, and there have been many
> magazine articles, and conference papers written, and talks given on the
> topic.
And that is the key problem. magazine here, conference there, talk
(perhaps only slides available) somewhere else -- a manual that was in
/usr/src/linux/Documentation might make a real difference. Even a
commented link list in Documentation/* might be a good starting point.
Patrick Mochel added some bits three years ago, but they were internals
and thus a bit less interesting.
--
Matthias Andree
On Tue, Feb 14, 2006 at 07:24:22PM -0500, Rob Landley wrote:
>
> I plan to start objecting earlier in future next time they propose to break us
> for no readily apparent reason.
Please do.
> The best way to stabilize an interface is to have users object, and udev
> doesn't count. Not only do they implement both the kernel and the userspace
> side, but in project management terms anybody who approaches shared libraries
> by keeping their own custom copy of the library source in their project
> source tree...
That was because we needed a local copy of libsysfs due to linking
against klibc. Also because we needed to fix up libsysfs to actually
work for our needs :)
Anyway, we've now dropped libsysfs entirely, replacing it with 200 lines
of code that is much faster and more flexible.
> Not exactly a role model for respecting and stabilizing the interfaces
> they link against. Not that I ever understood what libsysfs was for
> anyway, since the point of sysfs is to be _easy_to_parse_... But I'm
> also not surprised libsysfs dried up and blew away when it's main user
> forked the project.
libsysfs dried up and blew away when IBM abandonded it and stoped
funding the developers who were working on it. Projects need active
developers, something that IBM was not willing to provide for this one,
for whatever reason...
> If mdev accomplishes nothing else, we can poke Linus and go "no fair, this was
> exported to userspace and we depend on it", which udev hasn't.
Again, please complain if we break anything, we want to know, and I'll
do my best to keep it from happening.
thanks,
greg k-h
On Tuesday 14 February 2006 6:32 pm, Olivier Galibert wrote:
> On Tue, Feb 14, 2006 at 05:32:22PM -0500, Rob Landley wrote:
> > On Tuesday 14 February 2006 5:40 am, Olivier Galibert wrote:
> > > Why not have udev and whatever comes after tell the kernel so that a
> > > symlink is done in sysfs? The kernel not deciding policy do not
> > > prevent it from storing and giving back userland-provided information.
> >
> > That wouldn't help us. If userspace generates the info, then userspace
> > can drop a note in /dev or something to keep it there.
>
> And all I've been saying is that userspace:
>
> 1- should drop a filesystem-level note, not require calling an
> executable with a time-varying interface and no real reason to
> think it will still be in use in a couple of years
If userspace is generating the info it can put it anywhere it wants.
> 2- should drop it in sysfs, because:
Bad idea.
The point of sysfs is to communicate between the kernel and userspace. Not
between userspace and userspace.
Specifically, sysfs exports the kernel's view of the machine's hardware
layout, annotating it with information the kernel is already maintaining
about that hardware, and allows userspace to poke at that hardware by writing
new values to some of those fields.
It's not general purpose storage for information the kernel isn't going to
use. There _is_ general purpose storage. This isn't it.
> a- if it is there and cleanly defined, and "use this netlink
> message to have a symlink created in sysfs pointing to the node you
> just created" is clean and simple enough, all the concurrent
> device-node generating tools will support it quickly (hotplug,
> udev, mdev, maybe others, who knows)
If it's added, I guarantee you mdev will never set or use it. It's not
something we need, or want.
And who says there's only one /dev node for a given sysfs entry? I've got
scripts that set up a trivial chroot environment with /dev/null and friends
all the time. Nothing says that /dev/cdrom _has_ to be a symlink.
> b- nothing requires at that point the devices to be in /dev
So what? Then put the information in whatever directory or directories do
contain the device nodes. Or put it in /var/lib/mdev.
> c- sysfs already manages all the directory hierarchy or naming you
> need to define uniquely a device, why replicate it somewhere else?
It does not contain ownership or permission because only userspace knows or
cares what users are in /etc/passwd. That's not the kernel's business. Why
do you want it to contain persistent naming information that has to be
calculated by userspace in the first place? Again, it's not the kernel's
business.
> At that point I guess I just need to make a patch for the kernel side
> and then we'll see.
I'm as happy to ignore a patch implementing a bad idea as I am to ignore the
idea itself.
> OG.
Rob
--
Never bet against the cheap plastic solution.
On Tuesday 14 February 2006 6:47 pm, Greg KH wrote:
> On Tue, Feb 14, 2006 at 05:32:22PM -0500, Rob Landley wrote:
> > Changes to the kernel have already managed to break us twice
> > (switching /sys/class from real subdirectories to symlinks means we can't
> > just ignore symlinks when recursing down through directories anymore,
> > which is a problem because the existing symlinks form loops.
>
> I've shown a simple way to handle this, so this should not be a problem
> anymore.
Yup. We're ok with the current stuff, thanks.
(I haven't updated the mdev code yet because I need to build a 2.6.16-pre
kernel with the new layout to test against, but I've got a couple options
worked out.)
> > And deprecating /sbin/hotplug means we've got to bloat the code with
> > netlink stuff.) But we'll cope, and the user interface isn't
> > changing.
>
> Since when is /sbin/hotplug "depreciated"?
http://lwn.net/Articles/166377/
The hotplug helper /sbin/hotplug is now officially deprecated. The control
file /proc/sys/kernel/hotplug has moved to /sys/kernel/uevent_helper, but it
is expected to be disabled on most systems in favor of udev and the netlink
interface.
> It still works just fine, and isn't going anywhere anytime soon.
Good news for fans of small and simple, then. :)
> Turns out that some distros just don't want to use it, and use netlink
> instead. That should not stop you from using it if you wish, as the
> kernel sure doesn't care one way or the other.
Cool. For busybox, /sbin/hotplug is "the easy way".
> thanks,
>
> greg k-h
Rob
--
Never bet against the cheap plastic solution.
On Tuesday 14 February 2006 7:54 pm, Greg KH wrote:
> On Tue, Feb 14, 2006 at 07:24:22PM -0500, Rob Landley wrote:
> > I plan to start objecting earlier in future next time they propose to
> > break us for no readily apparent reason.
>
> Please do.
I will. I'm not complaining to you about failure to provide timely feedback.
(I fell behind on the list again...)
> That was because we needed a local copy of libsysfs due to linking
> against klibc. Also because we needed to fix up libsysfs to actually
> work for our needs :)
>
> Anyway, we've now dropped libsysfs entirely, replacing it with 200 lines
> of code that is much faster and more flexible.
Yup.
> libsysfs dried up and blew away when IBM abandonded it and stoped
> funding the developers who were working on it. Projects need active
> developers, something that IBM was not willing to provide for this one,
> for whatever reason...
I'm still not sure why it existed in the first place. Oh well.
> > If mdev accomplishes nothing else, we can poke Linus and go "no fair,
> > this was exported to userspace and we depend on it", which udev hasn't.
>
> Again, please complain if we break anything, we want to know, and I'll
> do my best to keep it from happening.
Understood. I'm caught up with the list again (ok, I skipped 3 months) and am
going to try to stay that way...
> thanks,
>
> greg k-h
Rob
--
Never bet against the cheap plastic solution.
On Wed, Feb 15, 2006 at 01:43:20AM +0100, Matthias Andree wrote:
> > > Please send me the other documentation (e.g. man pages) on the /sys
> > > device
> >
> > What "/sys device"? sysfs is a file system, and there have been many
> > magazine articles, and conference papers written, and talks given on the
> > topic.
>
> And that is the key problem. magazine here, conference there, talk
> (perhaps only slides available) somewhere else -- a manual that was in
> /usr/src/linux/Documentation might make a real difference. Even a
> commented link list in Documentation/* might be a good starting point.
>
> Patrick Mochel added some bits three years ago, but they were internals
> and thus a bit less interesting.
What would be "interesting"? The sysfs and driver model chapter of the
Linux Device Driver book from Oreilly, third edition? Or something
oriented toward users of sysfs, not developers using it?
thanks,
greg k-h
On Tuesday 14 February 2006 05:40, Olivier Galibert wrote:
> On Tue, Feb 14, 2006 at 12:23:15AM -0500, Andrew James Wade wrote:
> > The difficulty is the mapping between sysfs and /dev.
>
> Which is what I say each time.
Yes, sorry, you do do that.
> > That mapping should not live in sysfs,
> > /dev is none of the kernel's business and sysfs is the kernel's playground.
>
> Why not have udev and whatever comes after tell the kernel so that a
> symlink is done in sysfs? The kernel not deciding policy do not
> prevent it from storing and giving back userland-provided information.
> You get the best of both worlds, complete device information including
> how to talk with it in sysfs, and complete naming and policy setting
> in userspace.
Well, as Rob Landley pointed out, /dev is not necessarily the same across
the entire system. I don't know if this is a problem (is sysfs going to be
visible in a chrooted environment anyway?), but I take it as an indication
that /dev shouldn't be any of the kernel's business.
> >
> > The mapping could be provided via symlinks, like so:
> >
> > /dev/rdev/block/hdb/hdb1 -> /dev/hdb1
> > /dev/rdev/block/hdb -> /dev/hdb
> > /dev/rdev/block/hda/hda2 -> /dev/hda2
> > /dev/rdev/block/hda/hda1 -> /dev/hda1
> > /dev/rdev/block/hda -> /dev/hda
>
> Why manage a directory tree in udev when you have a perfectly good one
> in sysfs already. We're talking about a friggin' userland-provided
> string here, nothing more.
It is rather ugly to duplicate the directory tree. But it is better
than mission-creep of sysfs. And userspace has to maintain its own view
(or views) of devices anyway: GUIs may want to allow users to assign icons
to devices, or descriptive strings, or who knows what else. That
definitely shouldn't live in sysfs.
> > But I don't know if there is much point in doing so as udev already
> > provides that information.
>
> I guess you didn't bother to read the "answer 3" paragraph of my
> email. Do you trust udev to still exist two years from now, given
> that hotplug died in less than that? Do you trust udevinfo to have
> the same interface two years from now given that the current interface
> is already incompatible with a not even two-years old one (udev 039,
> 15-Oct-2004 according to kernel.org) which is widely deployed as part
> of fedora core 3?
No I don't trust udevinfo to have a stable interface. And that would be
a useful thing to have even if HAL is the only consumer. I suspect it would
be nice for all udev-like solutions to share the same interface. I'm just
hesitant to put forward my suggestion as the right interface.
I'd suggest answer 2 for the problem -- Hal knows it, ask him -- though
that's easy enough to say when I'm not writing the hypothetical program.
Hal can then worry about finding and integrating information about devices
in disparate places. If Hal doesn't provide a suitable interface, that
should be fixed.
Andrew Wade
On Wed, Feb 15, 2006 at 08:42:41AM -0500, Andrew James Wade wrote:
> On Tuesday 14 February 2006 05:40, Olivier Galibert wrote:
> > On Tue, Feb 14, 2006 at 12:23:15AM -0500, Andrew James Wade wrote:
>
> > > The difficulty is the mapping between sysfs and /dev.
> > > That mapping should not live in sysfs,
> > > /dev is none of the kernel's business and sysfs is the kernel's playground.
> >
> > Why not have udev and whatever comes after tell the kernel so that a
> > symlink is done in sysfs? The kernel not deciding policy do not
> > prevent it from storing and giving back userland-provided information.
> > You get the best of both worlds, complete device information including
> > how to talk with it in sysfs, and complete naming and policy setting
> > in userspace.
>
> Well, as Rob Landley pointed out, /dev is not necessarily the same across
> the entire system. I don't know if this is a problem (is sysfs going to be
> visible in a chrooted environment anyway?), but I take it as an indication
> that /dev shouldn't be any of the kernel's business.
That's true, but OTOH devices are definitively the kernel's business.
It's not an easy problem, and it really looks like it is not going to
be solved for a while at that point. Hotplug has existed for a long
time, but now the users expect the applications to do the right thing
by default when there isn't an ambiguity.
> It is rather ugly to duplicate the directory tree. But it is better
> than mission-creep of sysfs. And userspace has to maintain its own view
> (or views) of devices anyway: GUIs may want to allow users to assign icons
> to devices, or descriptive strings, or who knows what else. That
> definitely shouldn't live in sysfs.
I agree with that. But being able to find the device through sysfs
and not being able to talk to it (if allowed by the sysadmin) is
frustrating. I suspect the situation is a side effect of the
existence, and fight with, devfs. There has been some throwing of the
baby with the bathwater going on there.
> No I don't trust udevinfo to have a stable interface. And that would be
> a useful thing to have even if HAL is the only consumer. I suspect it would
> be nice for all udev-like solutions to share the same interface. I'm just
> hesitant to put forward my suggestion as the right interface.
>
> I'd suggest answer 2 for the problem -- Hal knows it, ask him -- though
> that's easy enough to say when I'm not writing the hypothetical program.
> Hal can then worry about finding and integrating information about devices
> in disparate places. If Hal doesn't provide a suitable interface, that
> should be fixed.
The problem with having Hal as a the interface to device discovery is
that at that point the Hal and Dbus developpers says themselves that
they do not consider the interfaces stable yet. Which is nice and
dandy, I don't have a problem with that, but means I won't do anything
I consider important using them yet. In practice dbus is close,
they're finishing the bindings APIs, and they said clearly that they
will be careful with compatibility after 1.0 which should be soon, but
hal isn't yet.
OG.
On Tue, Feb 14, 2006 at 03:45:46PM -0800, Greg KH wrote:
> On Wed, Feb 15, 2006 at 12:00:23AM +0100, Olivier Galibert wrote:
> > On Tue, Feb 14, 2006 at 02:24:28PM -0800, Greg KH wrote:
> > > Because if you have to have udev push the names back into the kernel,
> > > why not just ask udev in the first place what they were?
> >
> > Because there is no reason to think udev of 2008 will be compatible
> > with today's udev given udev's history. And that's provided udev is
> > still in use at that time.
>
> Just like gnome and kde of 2008 will not be compatible with the gnome
> and kde of today.
If history is a guide, it will. KDE is harder because the C++ as
implemented in gcc has changed in the meantime, so things that were
correct-ish two years ago aren't anymore and the libraries aren't
binary-compatible with the older gccs, but in the gtk/gnome case I
have programs I wrote in 1999 that still compile and work as is. And
in the X case, I have programs from before linux existed that still
compile and work as is. So I'm not sure what your point is here.
> > > Again, use HAL, not udev for this stuff. FC3 is also out of date for
> > > lots of things becides udev, so why refer to it?
> >
> > Because it proves you don't give a shit about backwards compatibility.
>
> *plonk*
Truth hurts?
OG.
>
>Of course not. Here's one line of bash that gets you the major:minor
>file of every block device in the system:
> block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
>
When was that added? /sys/block/hdc/device/ only has "power", "block",
"bus" and "driver" here on a 2.6.13-rc3.
Jan Engelhardt
--
On Wed, Feb 15, 2006 at 04:44:38PM +0100, Jan Engelhardt wrote:
> >
> >Of course not. Here's one line of bash that gets you the major:minor
> >file of every block device in the system:
> > block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
> >
> When was that added? /sys/block/hdc/device/ only has "power", "block",
> "bus" and "driver" here on a 2.6.13-rc3.
No, it's /sys/block/hdc/dev (22:0 here on 2.6.12). Makes sense to
have it there if you have multiple driver-generated device node
entries for the same physical device. I'm thinking of usb
multi-function devices here in particular (disk+bluetooth, video+hid
[dvb+remote control that is]).
OG.
On Tue, Feb 14, 2006 at 07:24:22PM -0500, Rob Landley wrote:
> I'm torn between "nuts to alsa", pointing out that "ln -s /dev /dev/snd"
> should shut it up nicely, and thinking up a way to actually do what it wants.
>
> If there's a real need for subdirectories, I'm sure we can come up with a way
> to shunt stuff into them. (Of course a shellout could do it, but if it's
> common enough we could build something into mdev...)
>
> The easy one's the symlink, assuming there are no name collisions flinging
> everything into one directory...
Let's see, on a recent kernel and recent udev I have as directories
under /dev:
- disk, a pure udev creation, so no conflict there
- loop, devices names under that are numeric. mount has /dev/loop%d
and /dev/loop/%d hardcoded
- bus/usb, this one collides with itself if flattened
- snd/sound, names except for seq and timer are pretty much line
noise. "timer" is scary though.
- net with tun and (I think) tap.
- pktcdvd with "control", not sure what tool uses it
- misc is ok (they're all ex-/dev/xx devices)
- video1394, dv1394, i2c with '0' as device name
- dri with card%d
- cpu which self-collides too
- input with a potentially dangerous event%d
So, well, I think you're going to need directories for usb and cpu
without doubt, and some of the rest is potentially risky, long-term
wise.
OG.
On Wed, Feb 15, 2006 at 04:44:38PM +0100, Jan Engelhardt wrote:
> >
> >Of course not. Here's one line of bash that gets you the major:minor
> >file of every block device in the system:
> > block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
> >
> When was that added? /sys/block/hdc/device/ only has "power", "block",
> "bus" and "driver" here on a 2.6.13-rc3.
True, that's why my above "echo" didn't point to "device" but "dev".
"device" is a symlink to the device that the block device is attached
to. "dev" is the major:minor number of this specific block device.
Hope this helps,
greg k-h
On Wednesday 15 February 2006 11:55 am, Olivier Galibert wrote:
> On Tue, Feb 14, 2006 at 07:24:22PM -0500, Rob Landley wrote:
> > I'm torn between "nuts to alsa", pointing out that "ln -s /dev /dev/snd"
> > should shut it up nicely, and thinking up a way to actually do what it
> > wants.
> >
> > If there's a real need for subdirectories, I'm sure we can come up with a
> > way to shunt stuff into them. (Of course a shellout could do it, but if
> > it's common enough we could build something into mdev...)
> >
> > The easy one's the symlink, assuming there are no name collisions
> > flinging everything into one directory...
>
> Let's see, on a recent kernel and recent udev I have as directories
> under /dev:
>
> - disk, a pure udev creation, so no conflict there
> - loop, devices names under that are numeric. mount has /dev/loop%d
> and /dev/loop/%d hardcoded
I just downloaded 2.6.13-rc3 and built it. That has:
/sys/block/{loop0,loop1,loop2,loop3,loop4,loop5,loop6,loop7}
And those are the names mdev would use. Turning /dev/loop# into /dev/loop/#
has to be some kind of udev filter in the config file.
There are no duplicate dev nodes in /sys right now. Check for yourself. Grab
all the names mdev would use:
find /sys -name dev | sed -e 's@^/sys/.*/\(.*\)/dev@\1@'
And then pipe that to sort | uniq -d
No hits on my ubuntu "flatulent badger" system. I'm not saying there won't be
any, I haven't tried plugging in a few usb memory keys and such. (But it
shouldn't be an overwhelming problem. We could keep just the first one,
stick a #2 on the second one... I'll worry about it when it crops up.)
> - bus/usb, this one collides with itself if flattened
> - snd/sound, names except for seq and timer are pretty much line
> noise. "timer" is scary though.
> - net with tun and (I think) tap.
> - pktcdvd with "control", not sure what tool uses it
> - misc is ok (they're all ex-/dev/xx devices)
> - video1394, dv1394, i2c with '0' as device name
> - dri with card%d
> - cpu which self-collides too
> - input with a potentially dangerous event%d
Don't look at the output of udev. Look at the contents of /sys.
> So, well, I think you're going to need directories for usb and cpu
> without doubt, and some of the rest is potentially risky, long-term
> wise.
The current way sys handles things like "loop0" is to call it "loop0" rather
than having a "loop" subdirectory with "0" under it. If they changed that:
A) I'd whimper on the list and make puppy eyes.
B) I could turn loop/0 back into "loop0" if I had to. Not too hard to do
mechanically...
> OG.
Rob
--
Never bet against the cheap plastic solution.
On Tue, 14 Feb 2006, Greg KH wrote:
> > And that is the key problem. magazine here, conference there, talk
> > (perhaps only slides available) somewhere else -- a manual that was in
> > /usr/src/linux/Documentation might make a real difference. Even a
> > commented link list in Documentation/* might be a good starting point.
> >
> > Patrick Mochel added some bits three years ago, but they were internals
> > and thus a bit less interesting.
>
> What would be "interesting"? The sysfs and driver model chapter of the
> Linux Device Driver book from Oreilly, third edition? Or something
> oriented toward users of sysfs, not developers using it?
Integrating documentation with the kernel. Documentation/* is constantly
out of date and incomplete, and sometimes has non-intuitive names.
--
Matthias Andree
Nix <[email protected]> wrote:
> > Please send me a statement on how long this interface will be maintained
> > inside Linux without breaking interfaces.
>
> What a ridiculous request. If people use it, it won't be broken. If it
> proves unusable due to flaws, it will change. Sheesh.
Looks like you are a Linux newby and did not yet relize how Linux
is maintained :-(
ide-scsi is used and needed but made unsusable.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hello!
> ide-scsi is used and needed but made unsusable.
Used maybe, but needed by whom?
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Top ten reasons to procrastinate: 1.
* Joerg Schilling <[email protected]> [2006-02-16 13:09:53 +0100]:
> Nix <[email protected]> wrote:
>
> > > Please send me a statement on how long this interface will be maintained
> > > inside Linux without breaking interfaces.
> >
> > What a ridiculous request. If people use it, it won't be broken. If it
> > proves unusable due to flaws, it will change. Sheesh.
>
> Looks like you are a Linux newby and did not yet relize how Linux
> is maintained :-(
>
> ide-scsi is used and needed but made unsusable.
I remember a time when I used it in order to be able to burn CDs. Nowadays it
works, however, without the module. Don't know who is using it. Or what for..
Marc
Kyle Moffett wrote:
> On Jan 30, 2006, at 17:52, Bill Davidsen wrote:
>
>> What is not easily available in Linux is a nice single place to find
>> out what mass storage (disk/optical/floppy/ZIP/LS120/tape) devices
>> are on the system, and what the system calls them.
>
>
> Yes it is available, and a whole slew of GUI applications use it.
> It's called "hal", or Hardware Abstraction Layer, and it has small
> hooks into udev and a bit of sysfs code so that it has a list of all
> devices of various types and knows what their associated udev-created
> device nodes are. This means that I can configure udev to put my CD
> drive on /dev/burner and correctly written GUI programs will just
> find it and work.
I was really talking about something stable. HAL is an application, and
as such has to be changed avery time some developer has a bad dream and
changes the interface, moves a comtrol or report from /proc to /sys, or
otherwise requires a new way of interpreting the data. If you will, HAL
*in* the kernel where it must work.
> --
> I have yet to see any problem, however complicated, which, when you
> looked at it in the right way, did not become still more complicated.
> -- Poul Anderson
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Thu, 16 Feb 2006, Matthias Andree wrote:
> On Tue, 14 Feb 2006, Greg KH wrote:
>
> > > And that is the key problem. magazine here, conference there, talk
> > > (perhaps only slides available) somewhere else -- a manual that was in
> > > /usr/src/linux/Documentation might make a real difference. Even a
> > > commented link list in Documentation/* might be a good starting point.
> > >
> > > Patrick Mochel added some bits three years ago, but they were internals
> > > and thus a bit less interesting.
> >
> > What would be "interesting"? The sysfs and driver model chapter of the
> > Linux Device Driver book from Oreilly, third edition? Or something
> > oriented toward users of sysfs, not developers using it?
>
> Integrating documentation with the kernel. Documentation/* is constantly
> out of date and incomplete, and sometimes has non-intuitive names.
I mostly agree and I'm trying to update it -- in my spare time.
Help is accepted. 8:)
--
~Randy
On Thu, Feb 16, 2006 at 11:20:02AM -0500, Bill Davidsen wrote:
> I was really talking about something stable. HAL is an application, and
> as such has to be changed avery time some developer has a bad dream and
> changes the interface, moves a comtrol or report from /proc to /sys, or
> otherwise requires a new way of interpreting the data. If you will, HAL
> *in* the kernel where it must work.
Sorry, the era of stability is over. Anything older than a year and
half or so is obsolete and should be upgraded. To their honor Linus,
Andrew and a small minority of others tried to keep stability as
important, but given that the vast majority of the other developpers
don't care they lost.
For the kernel that means syscalls are stable, but everything
filesystem isn't (proc and sysfs in particular) and change on a whim,
and also ioctls, especially on vonluntarily undocumented kernel
interfaces, are rather unstable.
OG.
On Thu, Feb 16, 2006 at 01:01:29PM +0100, Matthias Andree wrote:
> On Tue, 14 Feb 2006, Greg KH wrote:
>
> > > And that is the key problem. magazine here, conference there, talk
> > > (perhaps only slides available) somewhere else -- a manual that was in
> > > /usr/src/linux/Documentation might make a real difference. Even a
> > > commented link list in Documentation/* might be a good starting point.
> > >
> > > Patrick Mochel added some bits three years ago, but they were internals
> > > and thus a bit less interesting.
> >
> > What would be "interesting"? The sysfs and driver model chapter of the
> > Linux Device Driver book from Oreilly, third edition? Or something
> > oriented toward users of sysfs, not developers using it?
>
> Integrating documentation with the kernel.
What kind of documentation? user oriented documentation like how to
find specific stuff in sysfs? Or developer oriented documentation, like
we have there now.
> Documentation/* is constantly out of date and incomplete, and
> sometimes has non-intuitive names.
It's not always out of date. And patches are always gladly accepted.
Also, what non-intuitive names are you referring to?
thanks,
greg k-h
On Thu, 16 Feb 2006, Martin Mares noted:
> Hello!
>
>> ide-scsi is used and needed but made unsusable.
>
> Used maybe, but needed by whom?
Why, by Joerg of course, with his magic telepathy helmet which enables
him to tell exactly how long people he doesn't know have been using
Linux, and lets him determine exactly how broken all patches written by
other people are without even looking at them, and his great genius
which enables him to tell exactly how Linux must work (i.e., exactly
like Solaris), regardless of what any of those fools who actually
*wrote* it may think.
How could you possibly think anything else? Nothing else would be
*rational*. You of course should not respond until you agree with Joerg
in all matters.
(I was wondering how Joerg managed to unilaterally impose new licensing
terms on cdrecord without going through lots of trouble asking all the
other contributors. I guess I know now: there *are* no other
contributors, because nobody else can bear to work with him.)
>> My IDE one is neither nowhere in /sys/class. (Maybe I did not try looking
>> hard enough, though.)
>
>Why care, official policy is that you should do device discovery
>through udevinfo and not touch sysfs.
>
Hm, it's in /sys/block/hdb.
Daniel Barkalow wrote:
> I don't think it needs to be a class, but I think that there should be a
> single place with a directory for each device that could be what you want,
> with a file that tells you if it is. That's why I was looking at block/;
> these things must be block devices, and there aren't an huge number of
> block devices.
>
> I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I hadn't
> dug far enough in to realize that the reason I wasn't seeing anything
> informative in /sys/block/*/device/ was that I didn't have any devices
> with informative drivers, not that it was actually supposed to only have
> links to other things.
It would be nice to have one place to go to find burners, and to have
the model information in that place. I would logically think that place
is sysfs, and I know the kernel has the information because if I root
through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can
eventually find out what the system has connected.
I not entirely sure about having classes other than cdrom, just because
we already have CD, DVD, DVD-DL, and are about to add blue-ray and
HD-DVD, so if I can tell that it's a removable device which can read
CDs, the applications have a fighting chance to looking at the device to
see what it is. As a human I would like the model information because
the kernel has done the work, why should people have to chase it when it
could be in one place?
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Friday 17 February 2006 16:35, Bill Davidsen wrote:
> Daniel Barkalow wrote:
> > I don't think it needs to be a class, but I think that there should be a
> > single place with a directory for each device that could be what you
> > want, with a file that tells you if it is. That's why I was looking at
> > block/; these things must be block devices, and there aren't an huge
> > number of block devices.
> >
> > I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I
> > hadn't dug far enough in to realize that the reason I wasn't seeing
> > anything informative in /sys/block/*/device/ was that I didn't have any
> > devices with informative drivers, not that it was actually supposed to
> > only have links to other things.
>
> It would be nice to have one place to go to find burners, and to have
> the model information in that place. I would logically think that place
> is sysfs, and I know the kernel has the information because if I root
> through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can
> eventually find out what the system has connected.
>
> I not entirely sure about having classes other than cdrom, just because
> we already have CD, DVD, DVD-DL, and are about to add blue-ray and
> HD-DVD, so if I can tell that it's a removable device which can read
> CDs, the applications have a fighting chance to looking at the device to
> see what it is. As a human I would like the model information because
> the kernel has done the work, why should people have to chase it when it
> could be in one place?
The problem is that drives don't always cleanly report what they are in a
simple to access format. All SCSI and ATAPI drives provide a model,
manufacturer and serial number but usually the type of drive is buried within
the Model field, and that has a lot of variations.
(I have personally seen CD/CDRW, CD-ROM, CD-RW, CDR, CDRW and DVD/CDROM)
Now what could be done is that said information could be exported to sysfs.
Given the time I could probably manage the patch myself, but I'm currently
overextended with the number of projects I have underway.
DRH
On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote:
> I not entirely sure about having classes other than cdrom, just because
> we already have CD, DVD, DVD-DL, and are about to add blue-ray and
> HD-DVD, so if I can tell that it's a removable device which can read
> CDs, the applications have a fighting chance to looking at the device to
> see what it is. As a human I would like the model information because
> the kernel has done the work, why should people have to chase it when it
> could be in one place?
Sure, I don't object to that at all, as long as you can detect this kind
of information easily from within the kernel.
thanks,
greg k-h
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
* Christoph Hellwig <[email protected]> [2006-02-18 12:06]:
> > 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
Nice. Is that a stable interface people can rely on (seems this me it
should rather be in sys)? I maintain a tool in Debian to rip/encode
audio CDs with one command and we could use this file to find the CD
interface if it's not specified by the user.
--
Martin Michlmayr
[email protected]
Joerg Schilling wrote:
>Martin Mares <[email protected]> wrote:
>
>
>
>>Hello!
>>
>>
>>
>>>The main problem is that there is no grant that a new model will survive
>>>a time frame that makes sense to implement support.
>>>
>>>
>>I bet that it would take less time to implement this support than what
>>you spend here by arguing and trying to prove you are the only sane
>>person in the world. Unsuccessfully, of course.
>>
>>
>
>If memory serves me correctly, the current model is the 3rd incompatible one
>offerend within less than 5 years.
>
>
With that I agree. Not only does the interface change, the details
within a given interface must change.
>If you did ever try to write reliable code that has to deal with this kind of
>oddities, you would understand that it is sometimes better to wait and to inform
>related people about the problems they caused.
>
>
This ground has been covered. And at least in the case of filtering
commands, that had to be done quickly and you know it.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Sat, Feb 18, 2006 at 01:37:15PM +0000, Martin Michlmayr wrote:
> * Christoph Hellwig <[email protected]> [2006-02-18 12:06]:
> > > 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
>
> Nice. Is that a stable interface people can rely on (seems this me it
> should rather be in sys)? I maintain a tool in Debian to rip/encode
> audio CDs with one command and we could use this file to find the CD
> interface if it's not specified by the user.
I think it's pretty stable. Except for adding new capabilities it's been
unchanged since the 2.2.x days.
Maybe Jens can comment more on it?
D. Hazelton wrote:
>On Friday 17 February 2006 16:35, Bill Davidsen wrote:
>
>
>>Daniel Barkalow wrote:
>>
>>
>>>I don't think it needs to be a class, but I think that there should be a
>>>single place with a directory for each device that could be what you
>>>want, with a file that tells you if it is. That's why I was looking at
>>>block/; these things must be block devices, and there aren't an huge
>>>number of block devices.
>>>
>>>I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I
>>>hadn't dug far enough in to realize that the reason I wasn't seeing
>>>anything informative in /sys/block/*/device/ was that I didn't have any
>>>devices with informative drivers, not that it was actually supposed to
>>>only have links to other things.
>>>
>>>
>>It would be nice to have one place to go to find burners, and to have
>>the model information in that place. I would logically think that place
>>is sysfs, and I know the kernel has the information because if I root
>>through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can
>>eventually find out what the system has connected.
>>
>>I not entirely sure about having classes other than cdrom, just because
>>we already have CD, DVD, DVD-DL, and are about to add blue-ray and
>>HD-DVD, so if I can tell that it's a removable device which can read
>>CDs, the applications have a fighting chance to looking at the device to
>>see what it is. As a human I would like the model information because
>>the kernel has done the work, why should people have to chase it when it
>>could be in one place?
>>
>>
>
>The problem is that drives don't always cleanly report what they are in a
>simple to access format. All SCSI and ATAPI drives provide a model,
>manufacturer and serial number but usually the type of drive is buried within
>the Model field, and that has a lot of variations.
>
>(I have personally seen CD/CDRW, CD-ROM, CD-RW, CDR, CDRW and DVD/CDROM)
>
>Now what could be done is that said information could be exported to sysfs.
>Given the time I could probably manage the patch myself, but I'm currently
>overextended with the number of projects I have underway.
>
I would think that the model, manufacturer and serial would be useful,
and just the indication that the device was CD capable would be a huge
gain. There are at least two more type of drive coming soon in the 25GB
media race, so identification could legitimately be left to the
application as long as all CD-like devices can easily be identified for
examination.
Does that fit with your level of available time (and interest in
resolving this issue)?
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Saturday 18 February 2006 07:06, Christoph Hellwig wrote:
cat /proc/sys/dev/cdrom/info
CD-ROM information, Id: cdrom.c 3.20 2003/12/17
drive name: hdc
drive speed: 48
drive # of slots: 1
Can close tray: 1
Can open tray: 1
Can lock tray: 1
Can change speed: 1
Can select disk: 0
Can read multisession: 1
Can read MCN: 1
Reports media changed: 1
Can play audio: 1
Can write CD-R: 1
Can write CD-RW: 1
Can read DVD: 1
Can write DVD-R: 1
Can write DVD-RAM: 0
Can read MRW: 1
Can write MRW: 1
Can write RAM: 1
But I fail to see where this would help to 'find' the right device to
write to, other than the obvious prefixing of '/dev/' to $drive name.
We already knew that, and in fact it works very well. Please explain to
Joerg in one syllable words he might, if he wanted to, understand.
Also, I'm fuzzy about the last 3, so defining those might help me
understand.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Once upon a time, Christoph Hellwig <[email protected]> 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.
Problems with that file:
- What is "drive speed" (no units); also most drives do different speeds
for different modes/media.
- 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)
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.
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;
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.
--
Chris Adams <[email protected]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
On Saturday 18 February 2006 11:56, Bill Davidsen wrote:
> D. Hazelton wrote:
> >On Friday 17 February 2006 16:35, Bill Davidsen wrote:
> >>Daniel Barkalow wrote:
> >>>I don't think it needs to be a class, but I think that there should be a
> >>>single place with a directory for each device that could be what you
> >>>want, with a file that tells you if it is. That's why I was looking at
> >>>block/; these things must be block devices, and there aren't an huge
> >>>number of block devices.
> >>>
> >>>I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I
> >>>hadn't dug far enough in to realize that the reason I wasn't seeing
> >>>anything informative in /sys/block/*/device/ was that I didn't have any
> >>>devices with informative drivers, not that it was actually supposed to
> >>>only have links to other things.
> >>
> >>It would be nice to have one place to go to find burners, and to have
> >>the model information in that place. I would logically think that place
> >>is sysfs, and I know the kernel has the information because if I root
> >>through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can
> >>eventually find out what the system has connected.
> >>
> >>I not entirely sure about having classes other than cdrom, just because
> >>we already have CD, DVD, DVD-DL, and are about to add blue-ray and
> >>HD-DVD, so if I can tell that it's a removable device which can read
> >>CDs, the applications have a fighting chance to looking at the device to
> >>see what it is. As a human I would like the model information because
> >>the kernel has done the work, why should people have to chase it when it
> >>could be in one place?
> >
> >The problem is that drives don't always cleanly report what they are in a
> >simple to access format. All SCSI and ATAPI drives provide a model,
> >manufacturer and serial number but usually the type of drive is buried
> > within the Model field, and that has a lot of variations.
> >
> >(I have personally seen CD/CDRW, CD-ROM, CD-RW, CDR, CDRW and DVD/CDROM)
> >
> >Now what could be done is that said information could be exported to
> > sysfs. Given the time I could probably manage the patch myself, but I'm
> > currently overextended with the number of projects I have underway.
>
> I would think that the model, manufacturer and serial would be useful,
> and just the indication that the device was CD capable would be a huge
> gain. There are at least two more type of drive coming soon in the 25GB
> media race, so identification could legitimately be left to the
> application as long as all CD-like devices can easily be identified for
> examination.
>
> Does that fit with your level of available time (and interest in
> resolving this issue)?
seems straightforward enough. May take me a bit, since I'll need to see what
has to be done in order to make the information necessary, but I think it
could all be resolved with calls to the routines the ioctl's normally access.
DRH
(and I think that theres even more information available, from the
capabilities mode page, but I'm unsure as to how to access that)
On Saturday 18 February 2006 12:15, Gene Heskett wrote:
> On Saturday 18 February 2006 07:06, Christoph Hellwig wrote:
>
> cat /proc/sys/dev/cdrom/info
> CD-ROM information, Id: cdrom.c 3.20 2003/12/17
>
> drive name: hdc
> drive speed: 48
> drive # of slots: 1
> Can close tray: 1
> Can open tray: 1
> Can lock tray: 1
> Can change speed: 1
> Can select disk: 0
> Can read multisession: 1
> Can read MCN: 1
> Reports media changed: 1
> Can play audio: 1
> Can write CD-R: 1
> Can write CD-RW: 1
> Can read DVD: 1
> Can write DVD-R: 1
> Can write DVD-RAM: 0
> Can read MRW: 1
> Can write MRW: 1
> Can write RAM: 1
Ah, so it does already exist. Only thing left might be to stick the
manufacturer, serial and misc. data into sysfs
> But I fail to see where this would help to 'find' the right device to
> write to, other than the obvious prefixing of '/dev/' to $drive name.
> We already knew that, and in fact it works very well. Please explain to
> Joerg in one syllable words he might, if he wanted to, understand.
Well, in this case I'm actually trying to work with Joerg to produce a patch
that unifies the ATAPI and SCSI busses inside his program. One thing this
does is help to locate available drives. Negates the need to scan the entire
ATA/ATAPI bus for drives. However, since, as Joerg has pointed out, libscg is
a generic SCSI system, it doesn't negate it's need to scan the entire SCSI
bus. It's use as a backend to cdrecord is incidental in this case.
> Also, I'm fuzzy about the last 3, so defining those might help me
> understand.
I've seen the "MRW" stuff in some of the specs, but had to check the net to
find out what it was. MRW is the Mt. Rainier format - basic support was added
by Jens back in 2.4.19 according to the archives.
(http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html)
I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM type
discs
DRH
On Saturday 18 February 2006 13:36, Chris Adams wrote:
> Once upon a time, Christoph Hellwig <[email protected]> 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.
>
> Problems with that file:
>
> - What is "drive speed" (no units); also most drives do different speeds
> for different modes/media.
>
> - 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)
>
> 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.
>
> 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;
> 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.
Agreed. Which is why I'll use that file as a basis for the minor bit of work
I'll do in adding the capabilities and other information to sysfs. Though I
was under the impression that a lot of the device specific information was
being moved into sysfs anyway...
The reason it just says RAM is because, contrary to my statement in an earlier
mail it doesn't mean DVD-RAM, since my CD-RW also has that listed. (and
DVD-RAM has it's own slot in the file) I wasn't able to locate information on
what that is in the MMC docs, but in this case it might refer to the UDF
format. AFAICT the names used there are what are presented by the drive in
the capabilities mode page.
DRH
On Saturday 18 February 2006 08:47, Bill Davidsen wrote:
> Joerg Schilling wrote:
> >Martin Mares <[email protected]> wrote:
> >>Hello!
> >>
> >>>The main problem is that there is no grant that a new model will survive
> >>>a time frame that makes sense to implement support.
> >>
> >>I bet that it would take less time to implement this support than what
> >>you spend here by arguing and trying to prove you are the only sane
> >>person in the world. Unsuccessfully, of course.
> >
> >If memory serves me correctly, the current model is the 3rd incompatible
> > one offerend within less than 5 years.
>
> With that I agree. Not only does the interface change, the details
> within a given interface must change.
At this point I seem to have stumbled across a document that has what Joerg
might be looking for Linux to introduce. It's available at t10.org and is a
translation layer specification for OS's to use if they want to access ATA
devices like SCSI ones.
Seems to me this wouldn't be a good or bad thing to add to the kernel. The
problem is that introducing the layer and thereby unifying the SCSI and ATA
busses into one namespace is a big task. I know I couldn't manage it, and
don't think there are any people willing to take it on.
Introducing it would provide a standard interface, however.
DRH
On Saturday 18 February 2006 19:41, D. Hazelton wrote:
>On Saturday 18 February 2006 12:15, Gene Heskett wrote:
>> On Saturday 18 February 2006 07:06, Christoph Hellwig wrote:
>>
>> cat /proc/sys/dev/cdrom/info
>> CD-ROM information, Id: cdrom.c 3.20 2003/12/17
>>
>> drive name: hdc
>> drive speed: 48
>> drive # of slots: 1
>> Can close tray: 1
>> Can open tray: 1
>> Can lock tray: 1
>> Can change speed: 1
>> Can select disk: 0
>> Can read multisession: 1
>> Can read MCN: 1
>> Reports media changed: 1
>> Can play audio: 1
>> Can write CD-R: 1
>> Can write CD-RW: 1
>> Can read DVD: 1
>> Can write DVD-R: 1
>> Can write DVD-RAM: 0
>> Can read MRW: 1
>> Can write MRW: 1
>> Can write RAM: 1
>
>Ah, so it does already exist. Only thing left might be to stick the
>manufacturer, serial and misc. data into sysfs
>
>> But I fail to see where this would help to 'find' the right device
>> to write to, other than the obvious prefixing of '/dev/' to $drive
>> name. We already knew that, and in fact it works very well. Please
>> explain to Joerg in one syllable words he might, if he wanted to,
>> understand.
>
>Well, in this case I'm actually trying to work with Joerg to produce a
> patch that unifies the ATAPI and SCSI busses inside his program. One
> thing this does is help to locate available drives. Negates the need
> to scan the entire ATA/ATAPI bus for drives. However, since, as Joerg
> has pointed out, libscg is a generic SCSI system, it doesn't negate
> it's need to scan the entire SCSI bus. It's use as a backend to
> cdrecord is incidental in this case.
Working with Joerg? sigh
>> Also, I'm fuzzy about the last 3, so defining those might help me
>> understand.
>
>I've seen the "MRW" stuff in some of the specs, but had to check the
> net to find out what it was. MRW is the Mt. Rainier format - basic
> support was added by Jens back in 2.4.19 according to the archives.
>(http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html)
>
>I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM
> type discs
That sounds like it makes sense, thanks. I bought a spindle of
rewritable dvd's, thinking about doing backups, but a 200GB drive and
vtapes got in the way and its beaucoupe more convienient and speedy
that the dvd's will ever be. Once setup, it Just Works(TM).
That drive has since went belly up & been replaced with another that
seems even more solid, liteon of course.
>DRH
Thanks
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Sat, 18 Feb 2006, D. Hazelton wrote:
> Well, in this case I'm actually trying to work with Joerg to produce a patch
> that unifies the ATAPI and SCSI busses inside his program.
This patch already exists, see:
<http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html>
It's a proof of concept and needs to be polished (I'll look into that
again in March).
Only it still probes all /dev/hd and /dev/sg and /dev/pg in a dumb way,
rather than looking at sysfs or reading through /dev/.
> I've seen the "MRW" stuff in some of the specs, but had to check the net to
> find out what it was. MRW is the Mt. Rainier format - basic support was added
> by Jens back in 2.4.19 according to the archives.
> (http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html)
>
> I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM type
> discs
That's probably not it, since there's a separate DVD-RAM line here:
CD-ROM information, Id: cdrom.c 3.20 2003/12/17
drive name: hdd hdc sr0
drive speed: 40 48 1
drive # of slots: 1 1 1
Can close tray: 1 1 1
Can open tray: 1 1 1
Can lock tray: 1 1 1
Can change speed: 1 1 0
Can select disk: 0 0 0
Can read multisession: 1 1 1
Can read MCN: 1 1 1
Reports media changed: 1 1 1
Can play audio: 1 1 1
Can write CD-R: 1 1 0
Can write CD-RW: 1 1 0
Can read DVD: 0 1 0
Can write DVD-R: 0 1 0
Can write DVD-RAM: 0 1 0
Can read MRW: 1 1 1
Can write MRW: 1 1 1
Can write RAM: 1 1 1
hdd = Plextor PX-W4824TA
hdc = NEC ND-4550A
sr0 = Plextor PX-32TS
(Now NEC only needs to teach their drives to be more error tolerant when
reading and adjust their read speed to the actual sustained transfer
rate as Toshiba drives have been doing for ages...)
--
Matthias Andree
On Sat, 18 Feb 2006, D. Hazelton wrote:
> At this point I seem to have stumbled across a document that has what Joerg
> might be looking for Linux to introduce. It's available at t10.org and is a
> translation layer specification for OS's to use if they want to access ATA
> devices like SCSI ones.
Is that something other than CAM? If so, please mention the exact
document name.
> Seems to me this wouldn't be a good or bad thing to add to the kernel. The
Well, such an integration must avoid:
- breaking existing conformant applications, where conformant here would
apply to existing interface documentation such as the SCSI General
Programming HOWTO from torque.net.
This means that int fd = open("/dev/foo", O_RDWR, 0);
int e = ioctl(fd, SG_IO, &cmd_block);
needs to remain functional.
- duplicating code which would cause immediate bit-rot...
> problem is that introducing the layer and thereby unifying the SCSI and ATA
> busses into one namespace is a big task.
...so it could really only be an interface layer on top of existing
interfaces to avoid that. (Any other opinions?)
And then that interface would only be sensible if it actually improves
the situation, for instance, if applications gain source-level
compatibility with NetBSD or FreeBSD.
I think libata's integration of parallel ATA is already going a way that
leads to unifiying all the layers. For disks, the sd driver is used with
libata. I'd be surprised if it wouldn't work for CD/DVD drives, too, at
least in the long run.
Part of the problem is J?rg's expecting a solution the day before yesterday.
--
Matthias Andree
On Sat, Feb 18 2006, Christoph Hellwig wrote:
> On Sat, Feb 18, 2006 at 01:37:15PM +0000, Martin Michlmayr wrote:
> > * Christoph Hellwig <[email protected]> [2006-02-18 12:06]:
> > > > 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
> >
> > Nice. Is that a stable interface people can rely on (seems this me it
> > should rather be in sys)? I maintain a tool in Debian to rip/encode
> > audio CDs with one command and we could use this file to find the CD
> > interface if it's not specified by the user.
>
> I think it's pretty stable. Except for adding new capabilities it's been
> unchanged since the 2.2.x days.
>
> Maybe Jens can comment more on it?
Yeah it's stable, new entries have been added at the end if necessary. I
don't necessarily think it's a super way to find these things out,
sometimes older SCSI drives fail some of the mode sense / capability
probing and don't show correct values. So one could do better in user
space.
But at least it's a generic way to see which devices have been
registered as CDROM's, if that is the goal.
--
Jens Axboe
On Sat, 18 Feb 2006, Gene Heskett wrote:
> But I fail to see where this would help to 'find' the right device to
> write to, other than the obvious prefixing of '/dev/' to $drive name.
> We already knew that, and in fact it works very well. Please explain to
> Joerg in one syllable words he might, if he wanted to, understand.
Honestly, the right thing for Joerg is /dev/cdrom or /dev/cdroms/*. The
principle ought to be that something in userspace will talk to the kernel
and produce a /dev structure containing names the user will recognize.
(FWIW, /dev/cdrom has worked on every Linux machine I've had since my
first system 10 years ago, but I've heard of people having multiple
drives.)
Probably the right thing for getting the user to really know which thing
is which is to have a configuration program that configures udev by
listing all the devices that go through cdrom.c, giving some info about
them, letting the user open the tray on them (to distinguish identical
devices), and having the user give each a name, which then appears in
/dev/cdroms (by reconfiguring udev). All of the detailed info from the
kernel should go to the system configuration utility, not to cdrecord,
which shouldn't need it, because either the default drive (/dev/cdrom) or
the drive from /dev/cdroms that the user specifies will be right.
-Daniel
*This .sig left intentionally blank*
On Sunday 19 February 2006 04:20, Matthias Andree wrote:
> On Sat, 18 Feb 2006, D. Hazelton wrote:
> > At this point I seem to have stumbled across a document that has what
> > Joerg might be looking for Linux to introduce. It's available at t10.org
> > and is a translation layer specification for OS's to use if they want to
> > access ATA devices like SCSI ones.
>
> Is that something other than CAM? If so, please mention the exact
> document name.
The documents title is: "Information Technology - SCSI / ATA translation (SAT)
The revision I'm looking at is R08 - the most current I could find. I'll have
to dig, but it doesn't appear to just be a rewrite of CAM from the quick once
over I gave it.
> > Seems to me this wouldn't be a good or bad thing to add to the kernel.
> > The
>
> Well, such an integration must avoid:
>
> - breaking existing conformant applications, where conformant here would
> apply to existing interface documentation such as the SCSI General
> Programming HOWTO from torque.net.
>
> This means that int fd = open("/dev/foo", O_RDWR, 0);
> int e = ioctl(fd, SG_IO, &cmd_block);
> needs to remain functional.
>
> - duplicating code which would cause immediate bit-rot...
Yes, true. After all Linus has said that there is to be no more breaking of
userspace interfaces. In this case I think what the layer would do is allow
the people that want to to use /dev/sg* to access all SCSI and ATA devices on
a given system.
It's purpose, from the blurb on t10.org, is to provide a SCSI interface to ATA
disks for people that want to access them that way.
> > problem is that introducing the layer and thereby unifying the SCSI and
> > ATA busses into one namespace is a big task.
>
> ...so it could really only be an interface layer on top of existing
> interfaces to avoid that. (Any other opinions?)
>
Right. Which is one reason why I did say that I thought it might be a good
idea, but didn't think that anyone would bother. I also don't think it's
really necessary. SG_IO happens to work great and the amount of work
involved...
Anyway, to me it seems like it'd just be resurrecting a deprecated module and
expanding it so it has a wider scope. Only real difference would be that it
wouldn't take devices from their driver, just provide a second interface to
it - which also means that all the ATA drivers would need to have hooks that
it could call into. (Or am I over thinking it here?)
> And then that interface would only be sensible if it actually improves
> the situation, for instance, if applications gain source-level
> compatibility with NetBSD or FreeBSD.
Well, FreeBSD implements CAM, so if someone implemented CAM that'd provide
source-level compatability. In this case what it would do is hard to say -
the only thing I can think it _might_ do is quiet a couple of people down a
bit.
> I think libata's integration of parallel ATA is already going a way that
> leads to unifiying all the layers. For disks, the sd driver is used with
> libata. I'd be surprised if it wouldn't work for CD/DVD drives, too, at
> least in the long run.
Ah, yes. I was under the impression that libata only handled PATA and SATA -
is it going to be expanded to encompass the entire ATA bus?
> Part of the problem is J?rg's expecting a solution the day before
> yesterday.
Well, from some comments he made in private mails he seems to think he was
promised (by Linus, no less) that the DMA problems in ide-scsi were going to
be fixed. Instead the module was deprecated and SG_IO was introduced - this
seems to be one of the things he's been angry about.
DRH
Bill Davidsen <[email protected]> wrote:
> >If you did ever try to write reliable code that has to deal with this kind of
> >oddities, you would understand that it is sometimes better to wait and to inform
> >related people about the problems they caused.
> >
> >
> This ground has been covered. And at least in the case of filtering
> commands, that had to be done quickly and you know it.
We all know that filtering is not needeed to fix a bug. It could have been
implemented completely relaxed and without any time pressure as the bug
that needed fixing could have been fixed by just requiring a R/W FD to allow
SG_IO.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> wrote:
> > Part of the problem is J?rg's expecting a solution the day before
> > yesterday.
>
> Well, from some comments he made in private mails he seems to think he was
> promised (by Linus, no less) that the DMA problems in ide-scsi were going to
> be fixed. Instead the module was deprecated and SG_IO was introduced - this
> seems to be one of the things he's been angry about.
Even you have become a victim of the trolls :-(
SG_IO was used in ide-scsi a long time before it was needlessly introduced
on top of /dev/hd*
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Monday 20 February 2006 11:41, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> wrote:
> > > Part of the problem is J?rg's expecting a solution the day before
> > > yesterday.
> >
> > Well, from some comments he made in private mails he seems to think he
> > was promised (by Linus, no less) that the DMA problems in ide-scsi were
> > going to be fixed. Instead the module was deprecated and SG_IO was
> > introduced - this seems to be one of the things he's been angry about.
>
> Even you have become a victim of the trolls :-(
Never a victim. I stick my nose where I choose - in this case I stuck it in
here because I had hoped to turn a discussion I saw descending into a
flamewar into something productive.
> SG_IO was used in ide-scsi a long time before it was needlessly introduced
> on top of /dev/hd*
Needlessly? Not true. It was missing from the layer, as all modern ATA devices
do support some form of ATAPI, which is, as you've so frequently pointed out,
a form of SCSI. So why is an unneeded thing to introduce the ability to use
that full capacity?
And here I must parrot Martin Mares - you complain about problems when not
using ide-scsi but almost all the bugs you've mentioned only occur when using
ide-scsi. Now, I'll go and finish replying to all the other mails that have
come into my inbox (on this thread) and not been sorted down because they
were directly to me.
DRH
On Monday 20 February 2006 11:05, Joerg Schilling wrote:
> Bill Davidsen <[email protected]> wrote:
> > >If you did ever try to write reliable code that has to deal with this
> > > kind of oddities, you would understand that it is sometimes better to
> > > wait and to inform related people about the problems they caused.
> >
> > This ground has been covered. And at least in the case of filtering
> > commands, that had to be done quickly and you know it.
>
> We all know that filtering is not needeed to fix a bug. It could have been
> implemented completely relaxed and without any time pressure as the bug
> that needed fixing could have been fixed by just requiring a R/W FD to
> allow SG_IO.
In one post you complain that SG_IO is unneeded on /dev/hd* and related
devices and in this one you say that it's all that would have been needed to
fix a bug!
Joerg, I think it's time you stop dodging questions, shifting blame and all
the tactics you've been using and admit that you just don't like Linux. After
all, every time you are asked to provide a technical basis for an argument
you have three main tactics - Dodge it entirely, misquote POSIX or say "But
Solaris does it this way".
As you well know I've asked you for quality information I could use to try and
fix the bug in the kernel where it munges the CDB for certain drives and am
trying to work with you to develop a patch that will let libscg scan both the
SCSI and ATA/ATAPI bus on Linux. I realize I'm an unknown factor here, since
I've never found any place where my skills would come in useful on a major
project like cdrecord or Linux, but now I have.
If you do not want the help just say such. If you just want to complain about
problems and preach about how great Solaris is, then you are nothing but a
feigen schweinhund and deserve to receive no more of my time.
(and yes, my German is probably quite bad. It's been a very long time since
I've used any of it on a regular basis)
DRH
On Mon, 2006-02-20 at 13:53 -0500, D. Hazelton wrote:
> On Monday 20 February 2006 11:05, Joerg Schilling wrote:
> > Bill Davidsen <[email protected]> wrote:
> > > >If you did ever try to write reliable code that has to deal with this
> > > > kind of oddities, you would understand that it is sometimes better to
> > > > wait and to inform related people about the problems they caused.
> > >
> > > This ground has been covered. And at least in the case of filtering
> > > commands, that had to be done quickly and you know it.
> >
> > We all know that filtering is not needeed to fix a bug. It could have been
> > implemented completely relaxed and without any time pressure as the bug
> > that needed fixing could have been fixed by just requiring a R/W FD to
> > allow SG_IO.
>
Pretty sure it was not to fix a bug, but to plug a possible security
issue with non-root users being able to do whatever they wanted on a R/W
FD.
> In one post you complain that SG_IO is unneeded on /dev/hd* and related
> devices and in this one you say that it's all that would have been needed to
> fix a bug!
>
> Joerg, I think it's time you stop dodging questions, shifting blame and all
> the tactics you've been using and admit that you just don't like Linux. After
> all, every time you are asked to provide a technical basis for an argument
> you have three main tactics - Dodge it entirely, misquote POSIX or say "But
> Solaris does it this way".
>
> As you well know I've asked you for quality information I could use to try and
> fix the bug in the kernel where it munges the CDB for certain drives and am
> trying to work with you to develop a patch that will let libscg scan both the
> SCSI and ATA/ATAPI bus on Linux. I realize I'm an unknown factor here, since
> I've never found any place where my skills would come in useful on a major
> project like cdrecord or Linux, but now I have.
>
> If you do not want the help just say such. If you just want to complain about
> problems and preach about how great Solaris is, then you are nothing but a
> feigen schweinhund and deserve to receive no more of my time.
>
> (and yes, my German is probably quite bad. It's been a very long time since
> I've used any of it on a regular basis)
>
No need to waste your time .. he did not want it to work properly on
Linux for years now, and the only reason Linux support have not been
removed yet, is because then it will break his 'O so wonderful and only
proper "schily" way for "protability to more plaforms than you get from
using an GNU autoconf the way the GNU people tell you"'. Oh, and then
he looses his favourite "plaform" to rant about.
PS: quoted spelling mistakes are not a pun, its just to make sure I do
not get accused of being a liar ...
Still Amused,
--
Martin Schlemmer
Joerg, I've been thinking about your report about Linux munging CDB's sent to
certian ATAPI devices. While reading the MMC-5 spec again today (my memory of
it was starting to fail and I felt I had best be on top of it in this
discussion) a statement made about sending SCSI commands to ATAPI devices
caught me.
ATAPI command packets are fixed at a 12 byte size. Is it possible you tried to
send a CDB in excess of that fixed size re: those drives that get a munged
CDB?
Just a thought...
DRH
On Mon, Feb 20 2006, D. Hazelton wrote:
> On Monday 20 February 2006 11:05, Joerg Schilling wrote:
> > Bill Davidsen <[email protected]> wrote:
> > > >If you did ever try to write reliable code that has to deal with this
> > > > kind of oddities, you would understand that it is sometimes better to
> > > > wait and to inform related people about the problems they caused.
> > >
> > > This ground has been covered. And at least in the case of filtering
> > > commands, that had to be done quickly and you know it.
> >
> > We all know that filtering is not needeed to fix a bug. It could have been
> > implemented completely relaxed and without any time pressure as the bug
> > that needed fixing could have been fixed by just requiring a R/W FD to
> > allow SG_IO.
>
> In one post you complain that SG_IO is unneeded on /dev/hd* and related
> devices and in this one you say that it's all that would have been needed to
> fix a bug!
>
> Joerg, I think it's time you stop dodging questions, shifting blame and all
> the tactics you've been using and admit that you just don't like Linux. After
> all, every time you are asked to provide a technical basis for an argument
> you have three main tactics - Dodge it entirely, misquote POSIX or say "But
> Solaris does it this way".
Please stop CC'ing me on this pointless thread! Dunno who put me back,
but I have absolutely ZERO interesting in reading any of it anymore. I'd
rather get a root canal while listening to Michael Bolton and getting my
right leg sawed off.
--
Jens Axboe
"D. Hazelton" <[email protected]> wrote:
> > SG_IO was used in ide-scsi a long time before it was needlessly introduced
> > on top of /dev/hd*
>
> Needlessly? Not true. It was missing from the layer, as all modern ATA devices
> do support some form of ATAPI, which is, as you've so frequently pointed out,
> a form of SCSI. So why is an unneeded thing to introduce the ability to use
> that full capacity?
There used to be generic support, so this way of support is unneeded.
The fact that people did make ide-scsi (the generic way) impossible to use
is a bug that needs to be fixed.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> wrote:
> Joerg, I think it's time you stop dodging questions, shifting blame and all
> the tactics you've been using and admit that you just don't like Linux. After
> all, every time you are asked to provide a technical basis for an argument
> you have three main tactics - Dodge it entirely, misquote POSIX or say "But
> Solaris does it this way".
I did provide the details, but it is obvious that you need some basic knowledge
in order to contribute useful work.
You did look different than the trolls on this list, but now it seemd that
you also start parroting the FUD from the trolls on this list.
Note that this discussion did take many hours and it may be that it is more
efficient for me to immediately stop replying because ther is no hope that this
discussion would result in any result that is worh the effort.
> As you well know I've asked you for quality information I could use to try and
> fix the bug in the kernel where it munges the CDB for certain drives and am
> trying to work with you to develop a patch that will let libscg scan both the
> SCSI and ATA/ATAPI bus on Linux. I realize I'm an unknown factor here, since
> I've never found any place where my skills would come in useful on a major
> project like cdrecord or Linux, but now I have.
Sorry, I will not fix code that is maintained by people who have mo clean and
forseable rules for integration. This discussion has become a waste of time
and any time I spend working on Linux is definitely a waste of time as long
as decisions are comming from the belly instead of the head.
Write down a constitution for Linux, create clean rules, start making is
possible to have useful discussions on LKML and it may become different.
For now, Linux is scaring off people who know what they are doing.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-21:
> There used to be generic support, so this way of support is unneeded.
It is not your business to decide what is unneeded in Linux and what
isn't, and CD writing (still the Subject line!) doesn't require
ide-scsi. Evidently the additional SG_IO support in ide-cd doesn't break
your applications.
--
Matthias Andree
On Tue, Feb 21 2006, Joerg Schilling wrote:
> Write down a constitution for Linux, create clean rules, start making is
> possible to have useful discussions on LKML and it may become different.
> For now, Linux is scaring off people who know what they are doing.
Everyone else has fruitful discussion on lkml, except you. Clearly the
problem is with lkml and the people there, not you.
Now either stop writing here or at least stop cc'ing me like I asked you
to.
--
Jens Axboe
"D. Hazelton" <[email protected]> wrote:
> Joerg, I've been thinking about your report about Linux munging CDB's sent to
> certian ATAPI devices. While reading the MMC-5 spec again today (my memory of
> it was starting to fail and I felt I had best be on top of it in this
> discussion) a statement made about sending SCSI commands to ATAPI devices
> caught me.
>
> ATAPI command packets are fixed at a 12 byte size. Is it possible you tried to
> send a CDB in excess of that fixed size re: those drives that get a munged
> CDB?
I did write some time ago that the most probable cause for the Linux bug is that
Linux is sending uninitialized data for the amount of bytes that pad to 12 byte.
Libscg is the first application ever, that always correctly deals with CDB size
as it started to do so in August 1986 which is before any other SCSI generic
transport has been available.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Am Dienstag, den 21.02.2006, 11:36 +0100 schrieb Joerg Schilling:
> I did write some time ago that the most probable cause for the Linux
> bug is that
> Linux is sending uninitialized data for the amount of bytes that pad
> to 12 byte.
How are they supposed to be filled? I don't have a clue on the low-level
stuff involved, but isn't this as simple as initializing the rest of the
c array in idescsi_pc_t to 0?
--
Christian Neumair <[email protected]>
Christian Neumair <[email protected]> wrote:
> Am Dienstag, den 21.02.2006, 11:36 +0100 schrieb Joerg Schilling:
> > I did write some time ago that the most probable cause for the Linux
> > bug is that
> > Linux is sending uninitialized data for the amount of bytes that pad
> > to 12 byte.
>
> How are they supposed to be filled? I don't have a clue on the low-level
> stuff involved, but isn't this as simple as initializing the rest of the
> c array in idescsi_pc_t to 0?
They are supposed to be filled with null chars.
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree wrote:
> On Sat, 18 Feb 2006, D. Hazelton wrote:
>
>> Well, in this case I'm actually trying to work with Joerg to produce a patch
>> that unifies the ATAPI and SCSI busses inside his program.
>
> This patch already exists, see:
> <http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html>
>
> It's a proof of concept and needs to be polished (I'll look into that
> again in March).
>
> Only it still probes all /dev/hd and /dev/sg and /dev/pg in a dumb way,
> rather than looking at sysfs or reading through /dev/.
>
>> I've seen the "MRW" stuff in some of the specs, but had to check the net to
>> find out what it was. MRW is the Mt. Rainier format - basic support was added
>> by Jens back in 2.4.19 according to the archives.
>> (http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html)
>>
>> I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM type
>> discs
>
> That's probably not it, since there's a separate DVD-RAM line here:
>
> CD-ROM information, Id: cdrom.c 3.20 2003/12/17
>
> drive name: hdd hdc sr0
> drive speed: 40 48 1
> drive # of slots: 1 1 1
> Can close tray: 1 1 1
> Can open tray: 1 1 1
> Can lock tray: 1 1 1
> Can change speed: 1 1 0
> Can select disk: 0 0 0
> Can read multisession: 1 1 1
> Can read MCN: 1 1 1
> Reports media changed: 1 1 1
> Can play audio: 1 1 1
> Can write CD-R: 1 1 0
> Can write CD-RW: 1 1 0
> Can read DVD: 0 1 0
> Can write DVD-R: 0 1 0
> Can write DVD-RAM: 0 1 0
> Can read MRW: 1 1 1
> Can write MRW: 1 1 1
> Can write RAM: 1 1 1
>
> hdd = Plextor PX-W4824TA
> hdc = NEC ND-4550A
> sr0 = Plextor PX-32TS
Other than my 2.6.15 not producing those last three lines, looks good.
The names are those in /sys, which of course many distros change in udev
to make things hard for the user. Hard t write an app portably to cope
with /dev/scd0, /dev/sr0, /dev/cdroms/sr0, etc.
I am NOT suggesting changing a stable interface, but this really should
be in /sys I would think. It would be nice to have the major/minor and
model info, so programs could find the "better" named in /dev or just
mknod their own.
>
> (Now NEC only needs to teach their drives to be more error tolerant when
> reading and adjust their read speed to the actual sustained transfer
> rate as Toshiba drives have been doing for ages...)
>
This would appear to be almost all the user needs to at least find the
devices. I don't know why no one mentioned it several years ago.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Chris Adams wrote:
> Once upon a time, Christoph Hellwig <[email protected]> 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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Once upon a time, Bill Davidsen <[email protected]> said:
>> 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.
I wasn't aware those strings actually came from the devices. What I
meant was if that file is to be the documentation of the drive
capabilities, it needs to be updated to list all known capabilities (and
be updated promptly when new capabilities are created). It currently
has many missing formats.
>> - 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.
I've got a burner that has the following burn speeds (from memory): 16x
DVD+/-R, 8x DVD+RW, 6x DVD-RW, 4x DVD+/-R DL, 48x CD-R, and 24x CD-RW.
I don't even remember what the max read speeds are. Which is the "max"?
The 16x DVD speed or the 48x CD speed? Why?
The "x" unit is only meaningful with an associated format (since "1x" is
different for different formats) and with "read" or "write" specified.
Without units, the number is meaningless.
>> - if the drive can handle rewritable formats (for UDF support)
>
>CD-RW seems to cover that.
Not for DVD+RW, DVD-RW, and DVD-RAM (which is the only one there).
Sometime down the road, HD-DVD and Blu-Ray versions of rewritable will
also exist.
On Monday 27 February 2006 16:21, Chris Adams wrote:
> Once upon a time, Bill Davidsen <[email protected]> said:
> >> 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.
>
> I wasn't aware those strings actually came from the devices. What I
> meant was if that file is to be the documentation of the drive
> capabilities, it needs to be updated to list all known capabilities (and
> be updated promptly when new capabilities are created). It currently
> has many missing formats.
No, the strings do not come from the drive. Those capabilities, IIRC, are
presented as a series of bitflags packed into a 32 bit integer. This is
described in the MMC spec for the "capabilities mode page". The drive _does_
supply the information as to what formats it understands, but in this case
the kernel translates it into a human readable format.
> >> - 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.
>
> I've got a burner that has the following burn speeds (from memory): 16x
> DVD+/-R, 8x DVD+RW, 6x DVD-RW, 4x DVD+/-R DL, 48x CD-R, and 24x CD-RW.
> I don't even remember what the max read speeds are. Which is the "max"?
> The 16x DVD speed or the 48x CD speed? Why?
This value is also reported by the drive. I don't know about DVD drives, but
for CD drives it is a multiplier. 1x == 256K/sec transfer off the disc, 52x
is 13M/sec transfer off the disc. However, in the case of all discs, all
speeds beyond a certain cut-off value (I forget what the number is) the
number is "Maximum/Variable" because the polycarbonate the discs are made
from will deform and shatter from the centrifugal forces above a certain RPM.
(And this I have witness three times myself with a 52x drive and old discs.
It's a real bitch to have to take apart a CD drive and clean out the
fragments of the disc.)
> The "x" unit is only meaningful with an associated format (since "1x" is
> different for different formats) and with "read" or "write" specified.
>
> Without units, the number is meaningless.
It's in units as specified by the specification. The redbook spec for CDROM
drives states the minimum spin speed for stable reading and that roughly
translates to a 256K/sec read rate.
I haven't had time to look into the DVD specification, but I'm guessing that
the DVD speed is about 3x what the CDROM speed is.
> >> - if the drive can handle rewritable formats (for UDF support)
> >
> >CD-RW seems to cover that.
>
> Not for DVD+RW, DVD-RW, and DVD-RAM (which is the only one there).
> Sometime down the road, HD-DVD and Blu-Ray versions of rewritable will
> also exist.
Exactly. And these are all covered in the file. And as more formats are added
the currently unused bits in the capabilities mode page will come into use.
It will, at some point, be used up - and then I have a feeling a new mode
page will be introduced so that the current one isn't changed in a way that
would break legacy applications.
DRH
On 2/27/06, D. Hazelton <[email protected]> wrote:
> This value is also reported by the drive. I don't know about DVD drives, but
> for CD drives it is a multiplier. 1x == 256K/sec transfer off the disc [...]
For CDs, 1x is actually 150 KByte/sec.
> I haven't had time to look into the DVD specification, but I'm guessing that
> the DVD speed is about 3x what the CDROM speed is.
According to WikiPedia, the DVD speed rating is almost 9 times that of
CD speeds. I.e., 1x DVD is about 1.32 MByte/sec.
Just to make sure that we're all on the same page. :)
~~Peter
On Monday 27 February 2006 17:30, Peter Gordon wrote:
> On 2/27/06, D. Hazelton <[email protected]> wrote:
> > This value is also reported by the drive. I don't know about DVD drives,
> > but for CD drives it is a multiplier. 1x == 256K/sec transfer off the
> > disc [...]
>
> For CDs, 1x is actually 150 KByte/sec.
Well, I've been known to be wrong before, and this number was more based on
the fact that I once measured a sustained transfer rate of 1M/sec on a 4x
CDROM
> > I haven't had time to look into the DVD specification, but I'm guessing
> > that the DVD speed is about 3x what the CDROM speed is.
>
> According to WikiPedia, the DVD speed rating is almost 9 times that of
> CD speeds. I.e., 1x DVD is about 1.32 MByte/sec.
This was based on DVDx16 == CDx48 - I'm guessing someone is doing some monkey
work if a DVD is 9x a CD and a 16x DVD can't hit that mystical 52x of my
favorite CDRW drive in pure CD read mode.
>
> Just to make sure that we're all on the same page. :)
> ~~Peter
Thanks. Was just trying to dispel a few mis-statements and made some myself.
I'm grateful for the update to my poor memory.
DRH
D. Hazelton wrote:
>>>This value is also reported by the drive. I don't know about DVD drives,
>>>but for CD drives it is a multiplier. 1x == 256K/sec transfer off the
>>>disc [...]
>>For CDs, 1x is actually 150 KByte/sec.
> Well, I've been known to be wrong before, and this number was more based on
> the fact that I once measured a sustained transfer rate of 1M/sec on a 4x
> CDROM
Think about audio. Single speed = 75 frames of 2352 bytes per second,
or 176kB/s. However with data tracks you only get 2k per frame/sector,
so that works out to be 153kB/s.
Due to the CLV nature of CD-ROMs you may find the drive is faster
reading some parts of the disc than others.
>>According to WikiPedia, the DVD speed rating is almost 9 times that of
>>CD speeds. I.e., 1x DVD is about 1.32 MByte/sec.
> This was based on DVDx16 == CDx48 - I'm guessing someone is doing some monkey
> work if a DVD is 9x a CD and a 16x DVD can't hit that mystical 52x of my
> favorite CDRW drive in pure CD read mode.
You can do a similar calculation with DVDs. While I can't find a
reference for the maximum DVD total bitrate of ~10Mbit/s, this at 1.25
MByte/s this roughly agrees with the 1.32 quoted.
Sam.