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

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

[Albert Cahalan]

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.

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

[Jan Engelhardt]

>> 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
-- 

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

[Jens Axboe]

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

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

[Jan Engelhardt]

>
>- 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
-- 

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

[Jens Axboe]

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

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

[Joerg Schilling]

Jens Axboe <axboe@suse.de> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Matthias Andree]

Joerg Schilling wrote:
> Jens Axboe <axboe@suse.de> 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.

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

[grundig]

El Wed, 25 Jan 2006 18:03:18 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> 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....

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

[Jens Axboe]

On Wed, Jan 25 2006, grundig@teleline.es wrote:
> El Wed, 25 Jan 2006 18:03:18 +0100,
> Joerg Schilling <schilling@fokus.fraunhofer.de> 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

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

[Matthias Andree]

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.

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

[Jens Axboe]

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

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

[Matthias Andree]

(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

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

[grundig]

El Thu, 26 Jan 2006 00:14:22 +0100,
Matthias Andree <matthias.andree@gmx.de> 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...

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

[Matthias Andree]

On Thu, 26 Jan 2006, grundig@teleline.es 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

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

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 824 bytes --]

>> 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
-- 

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

[Bill Davidsen]

Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> 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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

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

[Joerg Schilling]

<grundig@teleline.es> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Nix]

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

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

[Joerg Schilling]

Nix <nix@esperi.org.uk> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Bill Davidsen]

red brick + atlantaNix wrote:
> On 25 Jan 2006, Matthias Andree prattled cheerily:
> 
>>Jens Axboe wrote:


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

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

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

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

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

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

[sean]

On Fri, 10 Feb 2006 16:06:39 -0500
Bill Davidsen <davidsen@tmr.com> 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

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

[Christian Neumair]

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 <chris@gnome-de.org>

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

[Joerg Schilling]

Christian Neumair <chris@gnome-de.org> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Martin Mares]

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   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"#define QUESTION ((bb) || !(bb))"  -- Shakespeare

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Bill Davidsen]

Joerg Schilling wrote:

>Martin Mares <mj@ucw.cz> 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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

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

[D. Hazelton]

On Saturday 18 February 2006 08:47, Bill Davidsen wrote:
> Joerg Schilling wrote:
> >Martin Mares <mj@ucw.cz> 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

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

[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

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

[D. Hazelton]

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

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[D. Hazelton]

On Monday 20 February 2006 11:41, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> 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

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Matthias Andree]

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

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

[D. Hazelton]

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

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Christian Neumair]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

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 <chris@gnome-de.org>

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

[Joerg Schilling]

Christian Neumair <chris@gnome-de.org> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Joerg Schilling]

Bill Davidsen <davidsen@tmr.com> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[D. Hazelton]

On Monday 20 February 2006 11:05, Joerg Schilling wrote:
> Bill Davidsen <davidsen@tmr.com> 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

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]

On Mon, 2006-02-20 at 13:53 -0500, D. Hazelton wrote:
> On Monday 20 February 2006 11:05, Joerg Schilling wrote:
> > Bill Davidsen <davidsen@tmr.com> 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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

[Jens Axboe]

On Mon, Feb 20 2006, D. Hazelton wrote:
> On Monday 20 February 2006 11:05, Joerg Schilling wrote:
> > Bill Davidsen <davidsen@tmr.com> 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

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Jens Axboe]

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

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

[jerome lacoste]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> 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

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

[Joerg Schilling]

jerome lacoste <jerome.lacoste@gmail.com> wrote:

> On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[jerome lacoste]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
>
> > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> 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

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

[Jan Engelhardt]

>> 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
-- 

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

[Luke-Jr]

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...

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

[Jan Engelhardt]

>> >> 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
-- 

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

[D. Hazelton]

On Monday 13 February 2006 08:24, Joerg Schilling wrote:
> Christian Neumair <chris@gnome-de.org> 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

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> On Monday 13 February 2006 08:24, Joerg Schilling wrote:
> > Christian Neumair <chris@gnome-de.org> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Greg KH]

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

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

[Olivier Galibert]

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.

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

[Greg KH]

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

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

[Olivier Galibert]

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.

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

[Krzysztof Halasa]

Olivier Galibert <galibert@pobox.com> 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

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

[Greg KH]

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

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

[Olivier Galibert]

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.

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

[Greg KH]

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

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

[Olivier Galibert]

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.

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

[Andrew James Wade]

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

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

[Olivier Galibert]

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.

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

[Greg KH]

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

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

[Olivier Galibert]

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.

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

[Greg KH]

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*

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

[Olivier Galibert]

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.

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

[Rob Landley]

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.

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

[Olivier Galibert]

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.

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

[Rob Landley]

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.

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

[Greg KH]

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

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

[Rob Landley]

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.

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

[Olivier Galibert]

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.

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

[Rob Landley]

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.

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

[Olivier Galibert]

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.

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

[Rob Landley]

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.

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

[Greg KH]

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

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

[Rob Landley]

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.

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

[Andrew James Wade]

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

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

[Olivier Galibert]

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.

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

[Michael Tokarev]

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

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

[Daniel Barkalow]

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

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

[Greg KH]

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

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

[Daniel Barkalow]

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*

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

[Greg KH]

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

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

[Dmitry Torokhov]

On 2/13/06, Greg KH <greg@kroah.com> 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

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

[Daniel Barkalow]

On Mon, 13 Feb 2006, Dmitry Torokhov wrote:

> On 2/13/06, Greg KH <greg@kroah.com> 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*

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

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

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

[D. Hazelton]

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

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

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

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

[D. Hazelton]

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)

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

[Greg KH]

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

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

[Christoph Hellwig]

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

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

[Martin Michlmayr]

* Christoph Hellwig <hch@infradead.org> [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
tbm@cyrius.com

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

[Christoph Hellwig]

On Sat, Feb 18, 2006 at 01:37:15PM +0000, Martin Michlmayr wrote:
> * Christoph Hellwig <hch@infradead.org> [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?

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

[Jens Axboe]

On Sat, Feb 18 2006, Christoph Hellwig wrote:
> On Sat, Feb 18, 2006 at 01:37:15PM +0000, Martin Michlmayr wrote:
> > * Christoph Hellwig <hch@infradead.org> [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

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

[Gene Heskett]

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.

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

[D. Hazelton]

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

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

[Gene Heskett]

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.

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

[Matthias Andree]

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

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

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

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

[Daniel Barkalow]

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*

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

[Chris Adams]

Once upon a time, Christoph Hellwig  <hch@infradead.org> 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 <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

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

[D. Hazelton]

On Saturday 18 February 2006 13:36, Chris Adams wrote:
> Once upon a time, Christoph Hellwig  <hch@infradead.org> 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

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

[Bill Davidsen]

Chris Adams wrote:
> Once upon a time, Christoph Hellwig  <hch@infradead.org> 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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

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

[Chris Adams]

Once upon a time, Bill Davidsen  <davidsen@tmr.com> 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.

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

[D. Hazelton]

On Monday 27 February 2006 16:21, Chris Adams wrote:
> Once upon a time, Bill Davidsen  <davidsen@tmr.com> 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

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

[Peter Gordon]

On 2/27/06, D. Hazelton <dhazelton@enter.net> 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

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

[D. Hazelton]

On Monday 27 February 2006 17:30, Peter Gordon wrote:
> On 2/27/06, D. Hazelton <dhazelton@enter.net> 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

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

[Sam Vilain]

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.

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

[Joerg Schilling]

Greg KH <greg@kroah.com> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Greg KH]

On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> Greg KH <greg@kroah.com> 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

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

[Joerg Schilling]

Greg KH <greg@kroah.com> wrote:

> On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > Greg KH <greg@kroah.com> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-14:

> It isd most unlikely that all SCSI devices are there.

Mind the topic: "CD writing"

-- 
Matthias Andree

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

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Matthias Andree]

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

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

[D. Hazelton]

On Tuesday 14 February 2006 14:58, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> 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

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

[D. Hazelton]

On Tuesday 14 February 2006 13:59, Joerg Schilling wrote:
> Greg KH <greg@kroah.com> wrote:
> > On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > > Greg KH <greg@kroah.com> 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

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

[Olivier Galibert]

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 <greg@kroah.com> 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.

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

[Bill Davidsen]

On Mon, 13 Feb 2006, Greg KH wrote:

> On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > Greg KH <greg@kroah.com> 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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
Doing interesting things with little computers since 1979

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

[Nix]

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

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

[Jan Engelhardt]

>
>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
-- 

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

[Olivier Galibert]

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.

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

[Greg KH]

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

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

[Nix]

On Mon, 13 Feb 2006, Joerg Schilling stated:
> Greg KH <greg@kroah.com> 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

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

[D. Hazelton]

On Monday 13 February 2006 17:14, Nix wrote:
> On Mon, 13 Feb 2006, Joerg Schilling stated:
> > Greg KH <greg@kroah.com> 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

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

[Nix]

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

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

[Matthias Andree]

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

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

[Jan Engelhardt]

>
>> (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
-- 

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

[Olivier Galibert]

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.

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

[Jan Engelhardt]

>> 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.

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

[Joerg Schilling]

Nix <nix@esperi.org.uk> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Greg KH]

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

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

[Matthias Andree]

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

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

[Greg KH]

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

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

[Matthias Andree]

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

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

[Randy.Dunlap]

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

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

[Greg KH]

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

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

[Nix]

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

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

[Joerg Schilling]

Nix <nix@esperi.org.uk> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Martin Mares]

Hello!

> ide-scsi is used and needed but made unsusable.

Used maybe, but needed by whom?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Top ten reasons to procrastinate: 1.

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

[Nix]

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.)

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

[Martin Mares]

Hello!

> MO, WORM, {ZIP,ls120} drives if you are using the full capabilities, IDE 
> tape drives, etc.
> 
> Sorry, I don't remember what capability the ls120 was using, but as of 
> 2.6.12 it didn't work through the ide-floppy interface.

Then it's a bug in ide-floppy which should be fixed.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Immanuel doesn't pun, he Kant.

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

[Ondrej Zary]

Martin Mares wrote:
> Hello!
> 
>> MO, WORM, {ZIP,ls120} drives if you are using the full capabilities, IDE 
>> tape drives, etc.
>>
>> Sorry, I don't remember what capability the ls120 was using, but as of 
>> 2.6.12 it didn't work through the ide-floppy interface.
> 
> Then it's a bug in ide-floppy which should be fixed.
> 
I fixed something in ide-floppy some time ago - when I bought LS-120 
drive and software eject did not work. See http://lkml.org/lkml/2005/9/4/83

-- 
Ondrej Zary

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

[Marc Koschewski]

* Joerg Schilling <schilling@fokus.fraunhofer.de> [2006-02-16 13:09:53 +0100]:

> Nix <nix@esperi.org.uk> 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

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

[Joerg Schilling]

Bill Davidsen <davidsen@tmr.com> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Joerg Schilling]

Anders Karlsson <trudheim@gmail.com> wrote:

> On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> [snip]
> > -       Older CD-writers identified as WORM although a CD-R is not a WORM.
>
> Nitpicking I know, but technically, CD-R is WORM in the case of single
> session write. And as long as the writer works, who cares if it is
> labled WORM, CD-R or Earthworm..

If you did know what a worm is, you would know that you are not correct:

A WORM allows you to randomly write any sector once.

A CD-R does not allows you to do this.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Jan Engelhardt]

>> Nitpicking I know, but technically, CD-R is WORM in the case of single
>> session write. And as long as the writer works, who cares if it is
>> labled WORM, CD-R or Earthworm..
>
>If you did know what a worm is, you would know that you are not correct:
>
>A WORM allows you to randomly write any sector once.
>A CD-R does not allows you to do this.
>
Nitpicking2, the CD-R case is a limitation of the cd writer ;)
Sadly there is no packet mode for CDRs. It would outbeat multisession.



Jan Engelhardt
-- 

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

[D. Hazelton]

On Monday 13 February 2006 10:12, Joerg Schilling wrote:
> Anders Karlsson <trudheim@gmail.com> wrote:
> > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > [snip]
> >
> > > -       Older CD-writers identified as WORM although a CD-R is not a
> > > WORM.
> >
> > Nitpicking I know, but technically, CD-R is WORM in the case of single
> > session write. And as long as the writer works, who cares if it is
> > labled WORM, CD-R or Earthworm..
>
> If you did know what a worm is, you would know that you are not correct:
>
> A WORM allows you to randomly write any sector once.
>
> A CD-R does not allows you to do this.

Joerg, the practical definition of WORM is "Write Once, Read Many" - whether 
or not it supports writes to random sectors is a moot point, a CDR does seem 
to fit the bill of a "write once, read many" medium.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > If you did know what a worm is, you would know that you are not correct:
> >
> > A WORM allows you to randomly write any sector once.
> >
> > A CD-R does not allows you to do this.
>
> Joerg, the practical definition of WORM is "Write Once, Read Many" - whether 
> or not it supports writes to random sectors is a moot point, a CDR does seem 
> to fit the bill of a "write once, read many" medium.

What you believe is irrelevent as long as it does not match the WORM device
definition.

See www.t10.org

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[D. Hazelton]

On Tuesday 14 February 2006 08:55, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > If you did know what a worm is, you would know that you are not
> > > correct:
> > >
> > > A WORM allows you to randomly write any sector once.
> > >
> > > A CD-R does not allows you to do this.
> >
> > Joerg, the practical definition of WORM is "Write Once, Read Many" -
> > whether or not it supports writes to random sectors is a moot point, a
> > CDR does seem to fit the bill of a "write once, read many" medium.
>
> What you believe is irrelevent as long as it does not match the WORM device
> definition.
>
> See www.t10.org
>
> Jörg

Joerg, I didn't say it was what _I_ believed. What I said was "WORM" means 
"Wrint One, Read Many" - since a CDR can be described in that fashion, it 
does match the description. Since it matches the description, most people 
lump the CDR medium in with all "WORM" medium. Is that clear enough?

DRH

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

[Nix]

On Sat, 18 Feb 2006, Bill Davidsen gibbered uncontrollably:
> There was a time when packet writing on CD-RW worked on Linux and
> people stopped using WORM for the most part. I haven't tried since
> udev became standard on most distros, I don't know if it still works
> or not.

If it doesn't work then the backup I'm now running is a mirage,
but I'm so thick with cold that it might well be illusory ;}

-- 
`... follow the bouncing internment camps.' --- Peter da Silva

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

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Olivier Galibert]

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.

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

[Joerg Schilling]

<grundig@teleline.es> wrote:

> El Wed, 25 Jan 2006 18:03:18 +0100,
> Joerg Schilling <schilling@fokus.fraunhofer.de> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Lee Revell]

On Thu, 2006-01-26 at 10:38 +0100, Joerg Schilling wrote:
> <grundig@teleline.es> wrote:
> 
> > El Wed, 25 Jan 2006 18:03:18 +0100,
> > Joerg Schilling <schilling@fokus.fraunhofer.de> 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

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

[Joerg Schilling]

Lee Revell <rlrevell@joe-job.com> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Nick Piggin]

Joerg Schilling wrote:
> Lee Revell <rlrevell@joe-job.com> 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 

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

[Joerg Schilling]

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Joerg Schilling wrote:
> > Lee Revell <rlrevell@joe-job.com> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Nick Piggin]

Joerg Schilling wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> 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 

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

[Matthias Andree]

Joerg Schilling wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
>> Joerg Schilling wrote:
>>> Lee Revell <rlrevell@joe-job.com> 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!

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

[grundig]

El Thu, 26 Jan 2006 10:38:23 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> 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)

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

[Tomasz Torcz]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Wed, Jan 25, 2006 at 06:03:18PM +0100, Joerg Schilling wrote:
> Jens Axboe <axboe@suse.de> 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
zdzichu@irc.-nie.spam-.pl    in the afternoon and evening." - Alan Cox


[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]

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

[Joerg Schilling]

Tomasz Torcz <zdzichu@irc.pl> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Tomasz Torcz]

On Thu, Jan 26, 2006 at 11:25:49AM +0100, Joerg Schilling wrote:
> Tomasz Torcz <zdzichu@irc.pl> 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->|
zdzichu@irc.-nie.spam-.pl                                          72->|   80->|

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

[Joerg Schilling]

Tomasz Torcz <zdzichu@irc.pl> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[jerome lacoste]

On 1/25/06, Jens Axboe <axboe@suse.de> 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

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

[Joerg Schilling]

jerome lacoste <jerome.lacoste@gmail.com> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[Martin Mares]

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   <mj@ucw.cz>   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?

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

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

[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
-- 

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

[Jens Axboe]

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

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

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

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

[Kyle Moffett]

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

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

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

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

[Olivier Galibert]

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.

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

[are added/removed - which]

El Wed, 25 Jan 2006 16:13:46 +0100 (MET),
Jan Engelhardt <jengelh@linux01.gwdg.de> 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...