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

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

[Albert Cahalan]

Joerg Schilling writes:
> Matthias Andree <matthias.andree@gmx.de> wrote:

>> S3 Device enumeration/probing is a sore spot. Unprivileged
>> "cdrecord dev=ATA: -scandisk" doesn't work, and recent
>> discussions on the cdwrite@ list didn't make any progress.
>> My observation is that cdrecord stops probing /dev/hd* devices
>> as soon as one yields EPERM, on the assumption "if I cannot
>> access /dev/hda, I will not have sufficient privilege to
>> write a CD anyways". I find this wrong, Joerg finds it correct
>> and argues "if you can access /dev/hdc as unprivileged user,
>> that's a security problem".
>
> This are two problems:
>
> -     users of cdrecord like to run cdrecord -scanbus in order
>       to find all SCSI devices. This no longer works since the
>       non-orthogonal /dev/hd* SCSI transport has been added.
>
>       As Linux already implements a Generic SCSI transport
>       interface (/dev/sg*) people would asume to be able to
>       talk to _all_ SCSI devices using this interface.
>       To allows this, there is a need for a SCSI HBA driver
>       that sends SCSI commands via a ATA interface.
>
> -     some people seem to set the permissions of some of the
>       /dev/hd* nodes to unsafe values and then complain that
>       the other /dev/hd* nodes cannot be opened.

**sigh**

Matthias Andree said "(Joerg, please don't talk about layer
violations here)", yet you do.

We Linux users will forever patch your software to work the
way every Linux app is supposed to work. (well, assuming
nobody succumbs to a well-caffeinated urge to fork the code)

Really, "users of cdrecord like to run cdrecord -scanbus"???
They LIKE running a command to generate phony SCSI addresses?
That's news to me.

To better protect users from terrible accidents, Linux should
avoid assigning a /dev/sg* device for anything with a regular
device file. This, along with elimination of the obsolete
ide-scsi crud, would make things a lot more safe and sane.

BTW, before Joerg mentions portability, I'd like to remind
everyone that all modern OSes support the use of normal device
names for SCSI. The most awkward is FreeBSD, where you have
to do a syscall or two to translate the name to Joerg's very
non-hotplug non-iSCSI way of thinking. Windows, MacOS X, and
even Solaris all manage to handle device names just fine. In
numerous cases, not just Linux, cdrecord is inventing crap out
of thin air to satisfy a pre-hotplug worldview.

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

[Joerg Schilling]

Albert Cahalan <acahalan@gmail.com> wrote:

> We Linux users will forever patch your software to work the

Looks like you are not a native English speaker. "We" is incorrect here, as you 
only speak for yourself.


> BTW, before Joerg mentions portability, I'd like to remind
> everyone that all modern OSes support the use of normal device
> names for SCSI. The most awkward is FreeBSD, where you have
> to do a syscall or two to translate the name to Joerg's very
> non-hotplug non-iSCSI way of thinking. Windows, MacOS X, and
> even Solaris all manage to handle device names just fine. In
> numerous cases, not just Linux, cdrecord is inventing crap out
> of thin air to satisfy a pre-hotplug worldview.

Looks like you are badly informed, so I encourage you to get yourself informed 
properly before sending your next postig....

libscg includes 22 different SCSI low level transport implementations.

-	Only 5 of them allow a /dev/hd* device name related access.

-	11 of them use file descriptors as handles for sending SCSI 
	commands but do not have a name <-> fs relation and thus
	_need_ a SCSI device naming scheme as libscg offers.
	This is because there is no 1:1 relation between SCSI addressing
	and a fd retrieved from a /dev/* entry.

-	6 of them not even allow to get a file descriptors as handles for 
	sending SCSI commands. These platforms of course need the SCSI device 
	naming scheme as libscg offers.

Conclusion:

17 Platforms _need_ the addressing scheme libscg offers

5  Platforms _may_ use a different access method too.

NOTE: Amongst the 6 plaforms that do not allow to even get a file descriptor 
there is a modern OS like MacOS X


BTW: the wording of your posting did give you a negative score.
If you continue the same way, it may be that your next posting will 
remain unanswered even though it may be wring and needs a correction like this 
one.



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)

[Kyle Moffett]

On Jan 25, 2006, at 11:31, Joerg Schilling wrote:
> Albert Cahalan <acahalan@gmail.com> wrote:
>> We Linux users will forever patch your software to work the
>
> Looks like you are not a native English speaker. "We" is incorrect  
> here, as you only speak for yourself.

I agree completely with his statements, therefore he speaks for at  
least two people and "we" is proper usage.  I suspect given the posts  
on this list the last time this flamewar came up that there are more  
as well, but 2 is enough.

> libscg includes...

Irrelevant to the discussion at hand, we are talking only about linux  
and what should be done on linux.

> - Only 5 of them allow a /dev/hd* device name related access.

No, you have this wrong:

- One of them (IE: Linux) requires a /dev/[hs]d* device-name related  
access

- Only 4 others allow /dev/hd*

However, the later is _completely_ _irrelevant_ to the discussion, as  
we are talking about Linux *only*.

> [irrelevant discussion of other platforms]

> 17 Platforms _need_ the addressing scheme libscg offers
> 5  Platforms _may_ use a different access method too.

Wrong again:
17 platforms need libscg's addressing
4 platforms offer /dev/* access
1 platform (Linux) _requires_ /dev/* access

You are perfectly free to adjust your compatibility layer accordingly.

> BTW: the wording of your posting [...]

Personal attacks are offtopic, irrelevant, and rude.  Please refrain  
from doing so.  If you don't plan to respond to somebody's email,  
just don't, no reason to shout about it to a world who doesn't care.

Cheers,
Kyle Moffett

--
Premature optimization is the root of all evil in programming
   -- C.A.R. Hoare

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

[Matthias Andree]

Kyle Moffett wrote:
> On Jan 25, 2006, at 11:31, Joerg Schilling wrote:
>> Albert Cahalan <acahalan@gmail.com> wrote:
>>> We Linux users will forever patch your software to work the
>>
>> Looks like you are not a native English speaker. "We" is incorrect 
>> here, as you only speak for yourself.
> 
> I agree completely with his statements, therefore he speaks for at 
> least two people and "we" is proper usage.  I suspect given the posts 
> on this list the last time this flamewar came up that there are more  as
> well, but 2 is enough.
> 
>> libscg includes...
> 
> Irrelevant to the discussion at hand, we are talking only about linux 
> and what should be done on linux.

Well, cdrecord relies on libscg, so in effect most of the portability code
that is affected is in libscg; some of the real-time code however is
specific to cdrecord.

>> - Only 5 of them allow a /dev/hd* device name related access.
> 
> No, you have this wrong:
> 
> - One of them (IE: Linux) requires a /dev/[hs]d* device-name related 
> access

/dev/sd* for CD writing? I think you're off track here. AFAICS cdrecord uses
/dev/sg* to access the writer.

> - Only 4 others allow /dev/hd*
> 
> However, the later is _completely_ _irrelevant_ to the discussion, as 
> we are talking about Linux *only*.

This, and if the code can then be used on other platforms, then there is
little point in calling the Linux /dev/hd* device "badly designed", unless
there were problems with it that prevented cdrecord (or libscg, for pxupdate
or something like that) from working properly.

So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via
ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count.

The numbers we get from ide-scsi for ATAPI writers are skewed anyhow, I'm
getting 1,0,0 for a SATA hard disk, 2,0,0 for secondary master
DVD-RAM/±R[W], 3,0,0 for secondary slave CD-RW... I wonder why these could
be desirable, and if they are really as static as they pretend to be. I
doubt that, their numbers depend on the order of driver loading.

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

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> > Irrelevant to the discussion at hand, we are talking only about linux 
> > and what should be done on linux.
>
> Well, cdrecord relies on libscg, so in effect most of the portability code
> that is affected is in libscg; some of the real-time code however is
> specific to cdrecord.

This is correct, as (looking at other programs from cdrtools) cdrecord is the 
only program that needs realtime scheduling.


> So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via
> ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count.

But device enumeration is the central point when implementing -scanbus.

Note that all OS that I am aware of internally use a device enumeration scheme 
that is close to what libscg uses. This ie even true for Linux. If Linux did not
hide this information for /dev/hd* based fd's, I could implement an abstraction
layer.....

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:

>> So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via
>> ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count.
> 
> But device enumeration is the central point when implementing -scanbus.

Again: Is there anything *besides* (<German>: außer) device enumeration that
does not work with the current /dev/hd* SG_IO interface?

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

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> Joerg Schilling wrote:
>
> >> So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via
> >> ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count.
> > 
> > But device enumeration is the central point when implementing -scanbus.
>
> Again: Is there anything *besides* (<German>: außer) device enumeration that
> does not work with the current /dev/hd* SG_IO interface?

This is the main point.

People like to run cdrecord -scanbus in order to find a list of usable devices.
People like to see all SCSI devices in a single name space as they are all 
using the same protocol for communication.

A sane way to send SCSI commands to _any_ type of devices would be to have a 
SCSI generic transport layer that is independent from the high-level features 
of the OS and that is independent from whether there is a high-level driver for 
this device at all.

This is what I designed the scg driver interface for in 1986 and this is what
Adaptec did in 1988 with ASPI. This is of course also why the SCSI standard 
commitee made a proposal for the CAM SCSI interface. 

http://www.t10.org/ftp/t10/drafts/cam/cam-r12b.pdf
http://www.t10.org/ftp/t10/drafts/cam3/cam3r03.pdf

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/26/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
[...]
> People like to run cdrecord -scanbus in order to find a list of usable devices.
> People like to see all SCSI devices in a single name space as they are all
> using the same protocol for communication.

If by people you mean developer, I might agree. If by people you mean
user, I disagree.

As a Linux user, the only reason I do cdrecord -scanbus is to comply
to the cdrecord way of doing likes. I don't personally like it.

I'd rather use /dev/cdrw, in a machine independent way, as in:

  ssh user@host cdrecord dev=/dev/cdrw /path/to/file.iso

Jerome

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

[Joerg Schilling]

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


> As a Linux user, the only reason I do cdrecord -scanbus is to comply
> to the cdrecord way of doing likes. I don't personally like it.
>
> I'd rather use /dev/cdrw, in a machine independent way, as in:
>
>   ssh user@host cdrecord dev=/dev/cdrw /path/to/file.iso

On the vast majority of OS this does not work.

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)

[Gene Heskett]

On Thursday 26 January 2006 09:03, Joerg Schilling wrote:
>jerome lacoste <jerome.lacoste@gmail.com> wrote:
>> As a Linux user, the only reason I do cdrecord -scanbus is to comply
>> to the cdrecord way of doing likes. I don't personally like it.
>>
>> I'd rather use /dev/cdrw, in a machine independent way, as in:
>>
>>   ssh user@host cdrecord dev=/dev/cdrw /path/to/file.iso
>
>On the vast majority of OS this does not work.
>
>Jörg

But from the Joe SixPack user standpoint, he should be able to click to 
launch the program, and click on the file he wants to put on the cd.  
The leds on the face of the drive should come on and the cd should come 
out.

All he knows is its that thing with the coffee holder sticking out of 
the front of the box that he had to remove his beer from to put in the 
blank cd & he doesn't care, *as long as it works*.

You have been offered a way to simplify your interface by many many 
lines of code, yet you resist, insisting that all other platforms do it 
your way, when in fact they don't either according to several lengthy 
threads I've now read on this subject.  There are far more winderz 
users than linux so far, and the winderz interface, except for the 
actual names used (drive F, what a strange moniker that is) is no more 
nor less complex, and both _just work_ if properly used.  A simple 
case: statement should handle it all.  So whats the problem?

-- 
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 2005 by Maurice Eugene Heskett, all rights reserved.

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

[jerome lacoste]

On 1/26/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
>
>
> > As a Linux user, the only reason I do cdrecord -scanbus is to comply
> > to the cdrecord way of doing likes. I don't personally like it.
> >
> > I'd rather use /dev/cdrw, in a machine independent way, as in:
> >
> >   ssh user@host cdrecord dev=/dev/cdrw /path/to/file.iso
>
> On the vast majority of OS this does not work.

1- I don't care if that works or not on other OSes. This is a
fonctionality I expect to work on my target host.

2- cdrecord locks the user inside its own terminology, instead of a
being open to the platform, for 'cross-platform compatibility reasons'

Sorry but I don't buy any of that.

Now, if someone was to provide you with patches to support the Linux
way of doing things, keeping all your functionality as it is today,
just reorganizing the code in a slightly different way, would you
consider looking at the patches?

Jerome

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

[Valdis.Kletnieks]

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

On Thu, 26 Jan 2006 15:03:11 +0100, Joerg Schilling said:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:

> >   ssh user@host cdrecord dev=/dev/cdrw /path/to/file.iso
> 
> On the vast majority of OS this does not work.

OK.. If "vast majority" is the proper way to decide this issue..

.. What does WinXP call the CD writer device?

What's wrong with this picture?  Maybe "vast majority" is the wrong criteria...

'cdrecord -scanbus' tells me I'm supposed to use 'dev=0,1,0', which has *zero*
meaning to me, since my laptop has no SCSI in it.  Fortunately, I also have a
/dev/hdb, and 'dev=/dev/hdb' works the way one would expect if they weren't
attached to a 1986-style naming scheme for some transport mechanism that isn't
present on my hardware.

And you know what? I really don't give a flying <fornicate> in a rolling donut
what FreeBSD calls the device. If I did, I'd have installed FreeBSD.  But I
installed a Fedora distro of Linux, and the only sane naming scheme is the
one that Fedora uses...


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

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

[Joerg Schilling]

Valdis.Kletnieks@vt.edu wrote:

> And you know what? I really don't give a flying <fornicate> in a rolling donut
> what FreeBSD calls the device. If I did, I'd have installed FreeBSD.  But I

It has been mentioned here many times, you only need to read it.

FreeBSD comes with a T-10 (SCSI) compliant CAM interface that uses a multiplex 
device and dev=b,t,l to address the devices. This is true for _all_ kind of 
SCSI devices and thus includes ATAPI transport.

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)

[Kyle Moffett]

On Jan 27, 2006, at 08:15:02, Joerg Schilling wrote:
> Valdis.Kletnieks@vt.edu wrote:
>> And you know what? I really don't give a flying <fornicate> in a  
>> rolling donut what FreeBSD calls the device. If I did, I'd have  
>> installed FreeBSD.
>
> It has been mentioned here many times, you only need to read it.
>
> FreeBSD comes with [desc of freebsd SCSI].

Jörg, can you read English properly?  Did you read what he wrote at  
*ALL*?  This is EXACTLY why people have been flaming you on this  
list.  He just wrote in sufficiently graphic detail how he doesn't  
care what FreeBSD does.  You promptly replied with a description of  
FreeBSD.  ARE YOU READING WHAT WE TYPE?!?!?!

This is it, I give up; you cannot have a reasonable discussion on  
this list and therefore are only contributing to the noise.  Plonk!

Cheers,
Kyle Moffett

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

[Matthias Andree]

On Fri, 27 Jan 2006, Joerg Schilling wrote:

> Valdis.Kletnieks@vt.edu wrote:
> 
> > And you know what? I really don't give a flying <fornicate> in a rolling donut
> > what FreeBSD calls the device. If I did, I'd have installed FreeBSD.  But I
> 
> It has been mentioned here many times, you only need to read it.
> 
> FreeBSD comes with a T-10 (SCSI) compliant CAM interface that uses a multiplex 
> device and dev=b,t,l to address the devices. This is true for _all_ kind of 
> SCSI devices and thus includes ATAPI transport.

Is CAM relevant at all for ATAPI, USB, IEEE1394, parport and other
transports? Where is the link between ATAPI's SCSI/MMC command set and
SCSI CAM standard applying to ATAPI devices? (File name of the standard
or latest draft and chapter is sufficient.)

-- 
Matthias Andree

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-26:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > Joerg Schilling wrote:
> >
> > >> So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via
> > >> ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count.
> > > 
> > > But device enumeration is the central point when implementing -scanbus.
> >
> > Again: Is there anything *besides* (<German>: außer) device enumeration that
> > does not work with the current /dev/hd* SG_IO interface?
> 
> This is the main point.

So there is no real reason.

> People like to run cdrecord -scanbus in order to find a list of usable devices.
> People like to see all SCSI devices in a single name space as they are all 
> using the same protocol for communication.

I find -scanbus rather annoying, particularly since it doesn't scan all
buses, I need to query cdrecord for the implemented transports, run
-scanbus for each of them again, and everything.

I know what device my writer has, SG_IO is sufficiently capable to write
CDs, is the declared standard for Linux parallel ATA-PI devices and I
want cdrecord to stop pissing at my leg for knowing the device up front.

> A sane way to send SCSI commands to _any_ type of devices would be to have a 
> SCSI generic transport layer that is independent from the high-level features 
> of the OS and that is independent from whether there is a high-level driver for 
> this device at all.

It appears as though the high-level driver gave you exactly that
generic mid-level access. If Linux violates design principles, is none
of your business as long as your application works.

> This is what I designed the scg driver interface for in 1986 and this is what

Yes, 20 years ago. How relevant is this for OSes that needed to be
updated in 2005 to support cdrecord again?

And what has this got to do with libscg's bogus assumptions ("If I
cannot have /dev/hda, I don't need to probe /dev/hdc anyways") after
you've agreed that resmgr and similar to allow console users access to
ONLY the writer were no major security risk?

> Adaptec did in 1988 with ASPI. This is of course also why the SCSI standard 
> commitee made a proposal for the CAM SCSI interface. 

We don't have ASPI on Linux, you're digressing.

-- 
Matthias Andree

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

[Jens Axboe]

On Wed, Jan 25 2006, Joerg Schilling wrote:
> > So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via
> > ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count.
> 
> But device enumeration is the central point when implementing
> -scanbus.

And that's why I state it's useless on Linux.

> Note that all OS that I am aware of internally use a device
> enumeration scheme that is close to what libscg uses. This ie even
> true for Linux. If Linux did not hide this information for /dev/hd*
> based fd's, I could implement an abstraction layer.....

Not true, Linux has nothing of the sort internally for eg ATAPI devices.
I don't know why you think that, but it's simply not true at all.

-- 
Jens Axboe

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

[Joerg Schilling]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

> > [irrelevant discussion of other platforms]

Incorrect, sorry. Do you really make Linux incompatible to the rest of the 
world?


> > 17 Platforms _need_ the addressing scheme libscg offers
> > 5  Platforms _may_ use a different access method too.
>
> Wrong again:
> 17 platforms need libscg's addressing
> 4 platforms offer /dev/* access
> 1 platform (Linux) _requires_ /dev/* access

Your last line is wrong 

> You are perfectly free to adjust your compatibility layer accordingly.

The Linux Kernel fols unfortunately artificially hides information for the 
/dev/hd* interface making exactly this compatibility impossible.


> Personal attacks are offtopic, irrelevant, and rude.  Please refrain  
> from doing so.  If you don't plan to respond to somebody's email,  
> just don't, no reason to shout about it to a world who doesn't care.

If you are against personal attacks, why didn't you intercede for the
postings from Jens Axboe and Albert Cahalan?

I am against personal attacks and this is the first time where it tooks
more than a day before LKML people started with personal attacks against me.
So in principle this is some sort of progress compared to former times.
If you like to continue this discussion, I would like you to stay reasonable 
and help to keep the discussion stay based on technical based arguments.

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)

[Kyle Moffett]

On Jan 25, 2006, at 12:14:15, Joerg Schilling wrote:
> Incorrect, sorry. Do you really make Linux incompatible to the rest  
> of the world?

Why should we care about compatibility with those interfaces?  Half  
our networking stack includes interfaces (like IPTables) that aren't  
compatible with _BSD_ from which parts of it were derived, let alone  
with Windows or Solaris.

>> 1 platform (Linux) _requires_ /dev/* access
> Your last line is wrong

No, it is correct.  We require /dev/* access.  The fact that we  
included /dev/sg* devices for /dev/[sh]d* was a mistake, and should  
be fixed, but those are still /dev/* access.

>> You are perfectly free to adjust your compatibility layer  
>> accordingly.
> The Linux Kernel fols unfortunately artificially hides information  
> for the /dev/hd* interface making exactly this compatibility  
> impossible.

We provide enough information for everybody else to be happy,  
including the dvd+rw-tools package.  What else do you need and why?

>> Personal attacks are offtopic, irrelevant, and rude.  Please  
>> refrain from doing so.  If you don't plan to respond to somebody's  
>> email, just don't, no reason to shout about it to a world who  
>> doesn't care.
>
> If you are against personal attacks, why didn't you intercede for  
> the postings from Jens Axboe and Albert Cahalan?

Because I didn't see them.

> I am against personal attacks and this is the first time where it  
> tooks more than a day before LKML people started with personal  
> attacks against me.

I would encourage you to ignore all personal attacks.  The people  
making them are doing so frequently because either (A) they feel they  
have been attacked and are retaliating or (B) they don't have a valid  
technical point to make.  In either case the signal-to-noise ratio is  
better if you ignore the attack and don't respond in turn, which will  
frequently cause the offending party to cease their attacks as well.

One other note:  Please do not tell Linux kernel developers that you  
know what is best for the Linux kernel.  If you have a specific bug  
or a proposed patch it will be thoroughly considered, but vague  
declarations of problems are insufficient.

Cheers,
Kyle Moffett

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

[Joerg Schilling]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

> On Jan 25, 2006, at 12:14:15, Joerg Schilling wrote:
> > Incorrect, sorry. Do you really make Linux incompatible to the rest  
> > of the world?
..
> >> 1 platform (Linux) _requires_ /dev/* access
> > Your last line is wrong
>
> No, it is correct.  We require /dev/* access.  The fact that we  
> included /dev/sg* devices for /dev/[sh]d* was a mistake, and should  
> be fixed, but those are still /dev/* access.

Looks like you missunderstood /dev/* here.

Even with /dev/scg* on Solaris or with CAM on FreeBSD, you open a device.
But this is not a /dev/ entry for a high level device like a disk, it is 
a SCSI nexus device that allows you to send SCSI commands on any SCSI transport.




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-01-26:

> Even with /dev/scg* on Solaris or with CAM on FreeBSD, you open a device.
> But this is not a /dev/ entry for a high level device like a disk, it is 
> a SCSI nexus device that allows you to send SCSI commands on any SCSI
> transport.

As long as the device you open allows you to send SCSI commands on any
suitable (not just SCSI) transport, why bother?

-- 
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-01-26:
>
> > Even with /dev/scg* on Solaris or with CAM on FreeBSD, you open a device.
> > But this is not a /dev/ entry for a high level device like a disk, it is 
> > a SCSI nexus device that allows you to send SCSI commands on any SCSI
> > transport.
>
> As long as the device you open allows you to send SCSI commands on any
> suitable (not just SCSI) transport, why bother?

If you open e.g. /dev/cam or /dev/scg?, you open device that is not related
to a high level service like /dev/hd* and this unfortunately is unable to talk 
to other devices in the same entity (e.g. ATAPI tapes).

With /dev/cam or similar you get a single handle for a group of devices that 
than are addressed via something very similar to dev=b,t,l

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)

[sean]

On Thu, 26 Jan 2006 15:05:42 +0100
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> 
> If you open e.g. /dev/cam or /dev/scg?, you open device that is not related
> to a high level service like /dev/hd* and this unfortunately is unable to talk 
> to other devices in the same entity (e.g. ATAPI tapes).
> 
> With /dev/cam or similar you get a single handle for a group of devices that 
> than are addressed via something very similar to dev=b,t,l
> 

So what?   Why is it so important to have just a single handle in this case
as opposed to multiple handles?

Sean

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-25:

> > You are perfectly free to adjust your compatibility layer accordingly.
> 
> The Linux Kernel fols unfortunately artificially hides information for the 
> /dev/hd* interface making exactly this compatibility impossible.

What information is actually missing? You keep talking about phantoms,
without naming them. Again: device enumeration doesn't count, libscg
already does that.

> If you are against personal attacks, why didn't you intercede for the
> postings from Jens Axboe and Albert Cahalan?

Because ignoring attacks is more efficient.

-- 
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-01-25:
>
> > > You are perfectly free to adjust your compatibility layer accordingly.
> > 
> > The Linux Kernel fols unfortunately artificially hides information for the 
> > /dev/hd* interface making exactly this compatibility impossible.
>
> What information is actually missing? You keep talking about phantoms,
> without naming them. Again: device enumeration doesn't count, libscg
> already does that.

I am not talking about phantoms, I am always requestung the same things.
It only seems that people here ignore these issues.

The only integrative (and this useful for libscg) interface on Linux is /dev/sg*

/dev/hd* may look nice if you only look skin-deep

How do you e.g. like send SCSI commands to ATAPI tape drives on Linux?

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)

[Vojtech Pavlik]

On Thu, Jan 26, 2006 at 01:27:59PM +0100, Joerg Schilling wrote:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > Joerg Schilling schrieb am 2006-01-25:
> >
> > > > You are perfectly free to adjust your compatibility layer accordingly.
> > > 
> > > The Linux Kernel fols unfortunately artificially hides information for the 
> > > /dev/hd* interface making exactly this compatibility impossible.
> >
> > What information is actually missing? You keep talking about phantoms,
> > without naming them. Again: device enumeration doesn't count, libscg
> > already does that.
> 
> I am not talking about phantoms, I am always requestung the same things.
> It only seems that people here ignore these issues.
> 
> The only integrative (and this useful for libscg) interface on Linux is /dev/sg*
> 
> /dev/hd* may look nice if you only look skin-deep
> 
> How do you e.g. like send SCSI commands to ATAPI tape drives on Linux?
 
I see you asking this again and again, and you seem to want to hear this
answer: "You don't." I haven't checked the code, but I guess the SG_IO
interface isn't available there. And I don't think this is a problem,
because a) if it was needed, it can be added trivially with minimum
added code, b) ATAPI tapes are dead, much the way ATAPI floppies are.

So can you now stop repeating this question, please?

It has no relevance to CD burning. 

I admit I can see the elegance in your /dev/scg solution on Solaris, but
you should accept that you're not going to get anything like that on
Linux, because it simply doesn't fit in the Linux frame of doing things.

In Linux we have devices and operate on them. They can be hotplugged and
assigned stable names via udev. A tunnel into the transport layer, like
your /dev/scg on Solaris, simply doesn't have place in Linux.

I believe that if you added Linux 2.6 support code in libscg/cdrecord,
that'd simply accept the device name as an argument and didn't use *any*
scanning code at all, you'd make a lot of people happy (*). Quite possibly
everyone minus one man. Which would be a great achievement.


(*) It'd be impossible to burn CDs in a tape drive on Linux then, but,
    I don't think that'll cause a lot of grief.
-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[Olivier Galibert]

On Thu, Jan 26, 2006 at 05:10:28PM +0100, Vojtech Pavlik wrote:
> I believe that if you added Linux 2.6 support code in libscg/cdrecord,
> that'd simply accept the device name as an argument and didn't use *any*
> scanning code at all, you'd make a lot of people happy (*). Quite possibly
> everyone minus one man. Which would be a great achievement.

Since Jens does not seem available anymore do you know how one is
supposed to do the cdrom-ish device enumeration at that point?  Is HAL
the official kernel interface to that now?

  OG.

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

[Vojtech Pavlik]

On Thu, Jan 26, 2006 at 06:55:07PM +0100, Olivier Galibert wrote:

> > I believe that if you added Linux 2.6 support code in libscg/cdrecord,
> > that'd simply accept the device name as an argument and didn't use *any*
> > scanning code at all, you'd make a lot of people happy (*). Quite possibly
> > everyone minus one man. Which would be a great achievement.
> 
> Since Jens does not seem available anymore do you know how one is
> supposed to do the cdrom-ish device enumeration at that point?  Is HAL
> the official kernel interface to that now?
 
The kernel interface is sysfs and hotplug.

Udev interfaces that and can be set up so that it assigns
/dev/cdrecorder0, 1, ... to evey recorder in the system, implementing
the userspace interface.

HAL interfaces the above and implements the desktop interface.

So for a GUI application it's appropriate to use HAL, while a command
line program doesn't need any enumeration, as 'ls /dev/cdrecorder*'
should be enough for an experienced user.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[Olivier Galibert]

On Thu, Jan 26, 2006 at 07:10:34PM +0100, Vojtech Pavlik wrote:
> The kernel interface is sysfs and hotplug.

Hotplug, of course, can't be used from a program.  As for sysfs, as
said in the mail to Jens, I'm not sure how to:

- find the devices, what should I scan/filter on.  udev seems likes it
  needs to run a program (/sbin/cdrom_id) or scan
  /proc/sys/dev/cdrom/info just to know if a device is a cdrom...

- find the /dev name associated to a sysfs-found device.


> Udev interfaces that and can be set up so that it assigns
> /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing
> the userspace interface.

Problem is, udev doesn't.  Or at least it varies from distribution to
distribution.  For instance recent gentoo creates /dev/cdrom*,
/dev/cdrw*, /dev/dvd*, /dev/dvdrw*.  Fedora core 3 creates
/dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*.  I guess from
your email that SuSE does /dev/cdrecorder*.  And I'm not able to
guess what fedora core 5, mandrake, debian, slackware and infinite
number of derivatives do.


> HAL interfaces the above and implements the desktop interface.

I'm not sure how trustable HAL is at that point given what's going on
with udev and I'm not too happy to have to require to daemons (dbus
system and hald) to run to find the devices, but heh...

  OG.

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

[Jan Engelhardt]

>> Udev interfaces that and can be set up so that it assigns
>> /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing
>> the userspace interface.
>
>Problem is, udev doesn't.  Or at least it varies from distribution to
>distribution.  For instance recent gentoo creates /dev/cdrom*,
>/dev/cdrw*, /dev/dvd*, /dev/dvdrw*.  Fedora core 3 creates
>/dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*.  I guess from
>your email that SuSE does /dev/cdrecorder*.  And I'm not able to
>guess what fedora core 5, mandrake, debian, slackware and infinite
>number of derivatives do.

Plus you have to think about systems not using udev at all.
Cheers, chaos preprogrammed.


Jan Engelhardt
-- 

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

[Dmitry Torokhov]

On 1/26/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >> Udev interfaces that and can be set up so that it assigns
> >> /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing
> >> the userspace interface.
> >
> >Problem is, udev doesn't.  Or at least it varies from distribution to
> >distribution.  For instance recent gentoo creates /dev/cdrom*,
> >/dev/cdrw*, /dev/dvd*, /dev/dvdrw*.  Fedora core 3 creates
> >/dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*.  I guess from
> >your email that SuSE does /dev/cdrecorder*.  And I'm not able to
> >guess what fedora core 5, mandrake, debian, slackware and infinite
> >number of derivatives do.
>

The above can be standatrisized (sp?). How is it different from notmal
filesystem naming layout?

> Plus you have to think about systems not using udev at all.
> Cheers, chaos preprogrammed.
>

We might want to add a new class in sysfs, except we do not allow a
device to belong to several classes (we require splittiing it into
sub-devices which is not entirely correct in case of DVD+-RW which
should belong to classes CD, DVD, DVD-RW, OTOH maybe it is sane to
treat it as 3 different sub-devices in one
physical package).

--
Dmitry

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

[Vojtech Pavlik]

On Thu, Jan 26, 2006 at 02:07:53PM -0500, Dmitry Torokhov wrote:
> On 1/26/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> > >> Udev interfaces that and can be set up so that it assigns
> > >> /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing
> > >> the userspace interface.
> > >
> > >Problem is, udev doesn't.  Or at least it varies from distribution to
> > >distribution.  For instance recent gentoo creates /dev/cdrom*,
> > >/dev/cdrw*, /dev/dvd*, /dev/dvdrw*.  Fedora core 3 creates
> > >/dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*.  I guess from
> > >your email that SuSE does /dev/cdrecorder*.  And I'm not able to
> > >guess what fedora core 5, mandrake, debian, slackware and infinite
> > >number of derivatives do.
> >
> 
> The above can be standatrisized (sp?). How is it different from notmal
> filesystem naming layout?
> 
> > Plus you have to think about systems not using udev at all.
> > Cheers, chaos preprogrammed.
> 
> We might want to add a new class in sysfs, except we do not allow a
> device to belong to several classes (we require splittiing it into
> sub-devices which is not entirely correct in case of DVD+-RW which
> should belong to classes CD, DVD, DVD-RW, OTOH maybe it is sane to
> treat it as 3 different sub-devices in one
> physical package).
 
I don't think there is a reason for a new class. Maybe some attributes,
but not a class - they're all the same kind of devices, only plain
CD-ROMs can only write CDs at speed 0 ;).

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[Jan Engelhardt]

>I don't think there is a reason for a new class. Maybe some attributes,
>but not a class - they're all the same kind of devices, only plain
>CD-ROMs can only write CDs at speed 0 ;).

CDROMs incapable of handling unknown media sometimes try to spin them with 
insane speed, so +Inf would be more accurate. ^_^


Jan Engelhardt
-- 

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

[Vojtech Pavlik]

On Thu, Jan 26, 2006 at 07:38:37PM +0100, Jan Engelhardt wrote:
> >> Udev interfaces that and can be set up so that it assigns
> >> /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing
> >> the userspace interface.
> >
> >Problem is, udev doesn't.  Or at least it varies from distribution to
> >distribution.  For instance recent gentoo creates /dev/cdrom*,
> >/dev/cdrw*, /dev/dvd*, /dev/dvdrw*.  Fedora core 3 creates
> >/dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*.  I guess from
> >your email that SuSE does /dev/cdrecorder*.  And I'm not able to
> >guess what fedora core 5, mandrake, debian, slackware and infinite
> >number of derivatives do.
> 
> Plus you have to think about systems not using udev at all.
> Cheers, chaos preprogrammed.
 
Nope. Just let the user specify it. Either the user is experienced
enough to know what is the name of the CD recorder on his distro, or
he'll use precompiled distribution packages which will have the correct
default.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[Vojtech Pavlik]

On Thu, Jan 26, 2006 at 07:28:18PM +0100, Olivier Galibert wrote:
> On Thu, Jan 26, 2006 at 07:10:34PM +0100, Vojtech Pavlik wrote:
> > The kernel interface is sysfs and hotplug.
> 
> Hotplug, of course, can't be used from a program.  As for sysfs, as
> said in the mail to Jens, I'm not sure how to:
> 
> - find the devices, what should I scan/filter on.  udev seems likes it
>   needs to run a program (/sbin/cdrom_id) or scan
>   /proc/sys/dev/cdrom/info just to know if a device is a cdrom...
> 
> - find the /dev name associated to a sysfs-found device.

That's why I said that sysfs/hotplug are kernel interfaces. They are the
interfaces the kernel uses to tell the rest of the system what devices
are there.

They are by no means interfaces that common tools should use. 

> > Udev interfaces that and can be set up so that it assigns
> > /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing
> > the userspace interface.
> 
> Problem is, udev doesn't. Or at least it varies from distribution to
> distribution. 

Yes. That is something that can be fixed, though. It's some work, but
it's just that - no controversies involved.

> For instance recent gentoo creates /dev/cdrom*,
> /dev/cdrw*, /dev/dvd*, /dev/dvdrw*.  Fedora core 3 creates
> /dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*.  I guess from
> your email that SuSE does /dev/cdrecorder*.  And I'm not able to
> guess what fedora core 5, mandrake, debian, slackware and infinite
> number of derivatives do.

That's what LSB and other standards are for. Defining standard
filesystem layout for programs to use (this includes /dev !).

And that's what also distros are for - setting correct defaults in the
programs when they package them.

In the end, on a well done distribution it works. And some time after
one is created, the distributions do follow the standard, too.

> > HAL interfaces the above and implements the desktop interface.
> 
> I'm not sure how trustable HAL is at that point given what's going on
> with udev and I'm not too happy to have to require to daemons (dbus
> system and hald) to run to find the devices, but heh...

It's mostly required if you run GNOME or KDE, so for desktop
applications it makes perfect sense.


-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[Diego Calleja]

El Thu, 26 Jan 2006 19:28:18 +0100,
Olivier Galibert <galibert@pobox.com> escribió:

> - find the devices, what should I scan/filter on.  udev seems likes it
>   needs to run a program (/sbin/cdrom_id) or scan
>   /proc/sys/dev/cdrom/info just to know if a device is a cdrom...

Not at all - /sys/devices/pci0000:00/0000:00:0f.1/ide1/1.0/media 
tells that in my box. cdrom_id is, AFAICS, a way to find the
capabilities of the drive (ie, look if it's a cdrom or a dvd, etc)

You can get the info even with a fancy output:

root@estel# systool -v -b ide
Bus = "ide"

  Device = "0.0"
  Device path = "/sys/devices/pci0000:00/0000:00:0f.1/ide0/0.0"
    drivename           = "hda"
    media               = "disk"
    modalias            = "ide:m-disk"
    uevent              = <store method only>

  Device = "1.0"
  Device path = "/sys/devices/pci0000:00/0000:00:0f.1/ide1/1.0"
    drivename           = "hdc"
    media               = "cdrom"
    modalias            = "ide:m-cdrom"
    uevent              = <store method only>

I guess the cdrom driver could in the future be taught to export
more data (the previus cdrom drive is really a dvd drive...) to 
the sysfs interface to know if it's a dvd so that cdrom_id is 
unnecesary in some cases.



> - find the /dev name associated to a sysfs-found device.

HAL tells you that the sysfs path associated to a device.

root@estel # hal-get-property --udi '/org/freedesktop/Hal/devices/block_HL-DT-ST DVDRAM GSA-4163B-K01544H0250' --key 'block.device'
/dev/cd-rw
root@estel #

(yes, that "udi" path sucks)


> /dev/cdrw*, /dev/dvd*, /dev/dvdrw*.  Fedora core 3 creates
> /dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*.  I guess from
> your email that SuSE does /dev/cdrecorder*.  And I'm not able to
> guess what fedora core 5, mandrake, debian, slackware and infinite
> number of derivatives do.

Although that sucks, IMO the whole point of udev/hal & friends is to
be able to make programs work regardless of what the name of the device
is (or at least, if I had to use a program, I would like that the program
design is good enought that it just ask the system what cd recorders are
connected to the system).

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

[Olivier Galibert]

On Thu, Jan 26, 2006 at 08:28:32PM +0100, Diego Calleja wrote:
> El Thu, 26 Jan 2006 19:28:18 +0100,
> Olivier Galibert <galibert@pobox.com> escribió:
> 
> > - find the devices, what should I scan/filter on.  udev seems likes it
> >   needs to run a program (/sbin/cdrom_id) or scan
> >   /proc/sys/dev/cdrom/info just to know if a device is a cdrom...
> 
> Not at all - /sys/devices/pci0000:00/0000:00:0f.1/ide1/1.0/media 
> tells that in my box. cdrom_id is, AFAICS, a way to find the
> capabilities of the drive (ie, look if it's a cdrom or a dvd, etc)

Hmmm, since when?  The most recent kernel with a cdrom attached I have
handy is a 2.6.14-rc2, and it does not give a "media" entry.

/proc/ide has it though.  Of course, I'd hoped the point of sysfs and
SG_IO was not to have to care whether it's scsi, ide, usb or something
else underlying...


> > - find the /dev name associated to a sysfs-found device.
> 
> HAL tells you that the sysfs path associated to a device.
> 
> root@estel # hal-get-property --udi '/org/freedesktop/Hal/devices/block_HL-DT-ST DVDRAM GSA-4163B-K01544H0250' --key 'block.device'
> /dev/cd-rw
> root@estel #
> 
> (yes, that "udi" path sucks)

Indeed, since the model is not given in sysfs, at least with
2.6.14-rc2 or previous.  There too, /proc/ide has it.  I also have no
idea what that "GSA" thing is either.


> Although that sucks, IMO the whole point of udev/hal & friends is to
> be able to make programs work regardless of what the name of the device
> is (or at least, if I had to use a program, I would like that the program
> design is good enought that it just ask the system what cd recorders are
> connected to the system).

Me too.  But at this point it looks like we have to go back to the
good old "scan /dev/hd?, /dev/scd*, /dev/sr*, /dev/sg* and pray".
Pity.

  OG.

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

[Diego Calleja]

El Thu, 26 Jan 2006 20:44:02 +0100,
Olivier Galibert <galibert@pobox.com> escribió:

> Hmmm, since when?  The most recent kernel with a cdrom attached I have
> handy is a 2.6.14-rc2, and it does not give a "media" entry.

2.6.16-rc1 here

> Indeed, since the model is not given in sysfs, at least with
> 2.6.14-rc2 or previous.  There too, /proc/ide has it.  I also have no
> idea what that "GSA" thing is either.

Oops, I got the command wrong, it can tell you the block device *and*
the sysfs path if you use the linux.sysfs_path key (which is non
portable key I guess from the name).

But anyway, it just looked at udev and it can do the same:

root@estel 4/home/diego # udevinfo -q path -n /dev/cd-rw
/block/hdc

(IOW: /sys/block/hdc)

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

[Joerg Schilling]

Vojtech Pavlik <vojtech@suse.cz> wrote:

> > The only integrative (and this useful for libscg) interface on Linux is /dev/sg*
> > 
> > /dev/hd* may look nice if you only look skin-deep
> > 
> > How do you e.g. like send SCSI commands to ATAPI tape drives on Linux?
>  
> I see you asking this again and again, and you seem to want to hear this
> answer: "You don't." I haven't checked the code, but I guess the SG_IO
> interface isn't available there. And I don't think this is a problem,
> because a) if it was needed, it can be added trivially with minimum
> added code, b) ATAPI tapes are dead, much the way ATAPI floppies are.

Nice to see that agree that sending SCSI via /dev/hd* is a hack with limited 
benefit.

Maybe (now that we did agree about the way to go) it makes sense to start 
discussing which bugs in Linux need to be fixed in order to close e.g.
the Bugs in the Debian bug tracking system for cdrtools that are related to the 
Linux kernel.

This are the three most important Linux kernel bugs:

-	ide-scsi does not do DMA if the DMAsize is not a multiple of 512
	A person who knows internal Linux structures shoule be able
	to fix this (and allow any multiple of 4) in less than one hour.
	If we sum up the time spend on this discussoion, I really cannot
	understand why this has not been fixed earlier.

-	/dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
	SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
	As long as this bug is present, there is no way to see SG_IO 
	via /dev/hd* as integral part of the Linux SCSI transport concept.

-	If sending SCSI sia ATAPI, Linux under certain unknown conditions
	bastardizes the content of SCSI commands. A possible reason may be
	that it sends random data in the remainder between the actual 
	SCSI cdb size and the ATAPI SCSI cdb size.

	ATAPI drives that verify SCSI cdb's for correctness fail in this
	case.

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)

[James Courtier-Dutton]

Joerg Schilling wrote:
> This are the three most important Linux kernel bugs:
>
> -	ide-scsi does not do DMA if the DMAsize is not a multiple of 512
> 	A person who knows internal Linux structures shoule be able
> 	to fix this (and allow any multiple of 4) in less than one hour.
> 	If we sum up the time spend on this discussoion, I really cannot
> 	understand why this has not been fixed earlier.
>
> -	/dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
> 	SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
> 	As long as this bug is present, there is no way to see SG_IO 
> 	via /dev/hd* as integral part of the Linux SCSI transport concept.
>
> -	If sending SCSI sia ATAPI, Linux under certain unknown conditions
> 	bastardizes the content of SCSI commands. A possible reason may be
> 	that it sends random data in the remainder between the actual 
> 	SCSI cdb size and the ATAPI SCSI cdb size.
>
> 	ATAPI drives that verify SCSI cdb's for correctness fail in this
> 	case.
>
> Jörg
>   
Would you be able to add the appropriate kernel bugzilla numbers?

I think it might also be useful to make a list of all the SCSI commands 
that cdrecord uses. Including all the vendor specific ones. One could 
then verify that the Linux kernel is passing them onto the device correctly.

James

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

[Jan Engelhardt]

>> This are the three most important Linux kernel bugs:
>> 
>> -	ide-scsi does not do DMA if the DMAsize is not a multiple of 512
>> A person who knows internal Linux structures shoule be able
>> to fix this (and allow any multiple of 4) in less than one hour.
>> If we sum up the time spend on this discussoion, I really cannot
>> understand why this has not been fixed earlier.

Unfortunately, ide-scsi is deemed obsolete in 2.6, so it looks like no one 
seems to be willing to do that. About 2.4 I'm just as unsure, because it's 
in it's way to deep freeze. It might go through as a bugfix, though.

>> -	/dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
>> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
>> As long as this bug is present, there is no way to see SG_IO via
>> /dev/hd* as integral part of the Linux SCSI transport concept.

Now you're talking shop ;-)

Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
for bus number, id or lun - independent of OS and/or cdrecord?

>> -	If sending SCSI sia ATAPI, Linux under certain unknown conditions
>> bastardizes the content of SCSI commands. A possible reason may be
>> that it sends random data in the remainder between the actual SCSI
>> cdb size and the ATAPI SCSI cdb size.

Not so good (the content freakup). IMO, if one can play around with the 
scsi tunnel (SG_IO) from userspace, commands should get through unmodified.
If it's not cdrecord/libscg making my writer do coffee, it must be this 
modification step.

> I think it might also be useful to make a list of all the SCSI commands that
> cdrecord uses. Including all the vendor specific ones. One could then verify
> that the Linux kernel is passing them onto the device correctly.

Or not, for that matter. There is surely a reason for the OS to do 
something to userspace-provided SG_IO packets to prevent the worst.


Jan Engelhardt
-- 

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

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >> This are the three most important Linux kernel bugs:
> >> 
> >> -	ide-scsi does not do DMA if the DMAsize is not a multiple of 512
> >> A person who knows internal Linux structures shoule be able
> >> to fix this (and allow any multiple of 4) in less than one hour.
> >> If we sum up the time spend on this discussoion, I really cannot
> >> understand why this has not been fixed earlier.
>
> Unfortunately, ide-scsi is deemed obsolete in 2.6, so it looks like no one 
> seems to be willing to do that. About 2.4 I'm just as unsure, because it's 
> in it's way to deep freeze. It might go through as a bugfix, though.

Well, Linux offers a generic SCSI (/dev/sg*) transport, so it should be
able to do this in a way that is independent from the SCSI transport.

> >> -	/dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
> >> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
> >> As long as this bug is present, there is no way to see SG_IO via
> >> /dev/hd* as integral part of the Linux SCSI transport concept.
>
> Now you're talking shop ;-)
>
> Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
> curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
> for bus number, id or lun - independent of OS and/or cdrecord?

The drive does not return this information, but the SCSI subsystem creates
these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
be known to the SCSI sub-system and thus needs to have a SCSI subsystem
related instance number.


> >> -	If sending SCSI sia ATAPI, Linux under certain unknown conditions
> >> bastardizes the content of SCSI commands. A possible reason may be
> >> that it sends random data in the remainder between the actual SCSI
> >> cdb size and the ATAPI SCSI cdb size.
>
> Not so good (the content freakup). IMO, if one can play around with the 
> scsi tunnel (SG_IO) from userspace, commands should get through unmodified.
> If it's not cdrecord/libscg making my writer do coffee, it must be this 
> modification step.

????

> > I think it might also be useful to make a list of all the SCSI commands that
> > cdrecord uses. Including all the vendor specific ones. One could then verify
> > that the Linux kernel is passing them onto the device correctly.
>
> Or not, for that matter. There is surely a reason for the OS to do 
> something to userspace-provided SG_IO packets to prevent the worst.

Cdrecord is a program that needs to be able to send any SCSI command as 
it needs to be able to add new vendor unique commands for new drive/feature
support.


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-01-30:

> > >> -	/dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
> > >> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
> > >> As long as this bug is present, there is no way to see SG_IO via
> > >> /dev/hd* as integral part of the Linux SCSI transport concept.
> >
> > Now you're talking shop ;-)
> >
> > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
> > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
> > for bus number, id or lun - independent of OS and/or cdrecord?
> 
> The drive does not return this information, but the SCSI subsystem creates
> these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
> be known to the SCSI sub-system and thus needs to have a SCSI subsystem
> related instance number.

We are talking about ATA and ATAPI drives here. They may use SCSI
commands, but the transport is different. My take is: the Kernel guys
have been refusing to invent a non-native enumeration scheme for
non-SCSI transports, and you have not provided evidence why this is
indispensable.

Why is it a *kernel* task to invent SCSI identifier for a non-SCSI
transport that does not have such identifiers, in addition to the device
name? libscg is already doing it for /dev/hd* and /dev/pg*.
How about USB or Firewire or SATA? Do they have ID or LUN?

Why isn't libscg simply scanning all transports exhaustively (i. e. not
stopping at EPERM) and inventing this itself? You're failing to answer
this questions for week now, even though you agreed resmgr or similar
setups were safe.

How is a user going to tell apart two devices of the same make and model
from -scanbus output? The answer is (s)he cannot.

Sounds unrealistic? Well, some orchestras sell fresh recordings half an
hour after the final chord, with some dozen CD writers...

> Cdrecord is a program that needs to be able to send any SCSI command as 
> it needs to be able to add new vendor unique commands for new drive/feature
> support.

Right, but evidently it does not need the kernel to invent numbering.
dev=/dev/hdc works today.

-- 
Matthias Andree

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

[Christoph Hellwig]

On Mon, Jan 30, 2006 at 01:04:08PM +0100, Matthias Andree wrote:
> Why is it a *kernel* task to invent SCSI identifier for a non-SCSI
> transport that does not have such identifiers, in addition to the device
> name? libscg is already doing it for /dev/hd* and /dev/pg*.
> How about USB or Firewire or SATA? Do they have ID or LUN?

Nothing but SPI (parallel scsi) has a target id.  Everything that broadly
falls under SAM has luns.  Because SPI is dying transport the scsi
midlayer will get rid of having a mandatory target id mid-term.  Relying
on the target id to have any useful meaning is dangerous, it doesn't
have a really useful meaning on anything but SPI.

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

[Joerg Schilling]

Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Jan 30, 2006 at 01:04:08PM +0100, Matthias Andree wrote:
> > Why is it a *kernel* task to invent SCSI identifier for a non-SCSI
> > transport that does not have such identifiers, in addition to the device
> > name? libscg is already doing it for /dev/hd* and /dev/pg*.
> > How about USB or Firewire or SATA? Do they have ID or LUN?
>
> Nothing but SPI (parallel scsi) has a target id.  Everything that broadly
> falls under SAM has luns.  Because SPI is dying transport the scsi
> midlayer will get rid of having a mandatory target id mid-term.  Relying
> on the target id to have any useful meaning is dangerous, it doesn't
> have a really useful meaning on anything but SPI.

And now please tell me how you believe this will be inplemented.....

Every kernel implementation I am aware of uses device instance numbers
and BTW: I am open for any non-dogmatic discussion.


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)

[Christoph Hellwig]

On Mon, Jan 30, 2006 at 05:15:20PM +0100, Joerg Schilling wrote:
> > Nothing but SPI (parallel scsi) has a target id.  Everything that broadly
> > falls under SAM has luns.  Because SPI is dying transport the scsi
> > midlayer will get rid of having a mandatory target id mid-term.  Relying
> > on the target id to have any useful meaning is dangerous, it doesn't
> > have a really useful meaning on anything but SPI.
> 
> And now please tell me how you believe this will be inplemented.....

There's very little places left that need to know about the target id.
A few month ago we had a detailed list on linux-scsi, but off my head these
are:

 - sdev_printk prints the device identifier which right now includes the
   target id.  this will become a transport class callout so the transport
   can print transport-specific information
 - various scanning interfaces (scsi_scan_host_selected, scsi_scan_target,
   scsi_add_device) require a channel id.  scsi_scan_target will lose the
   id parameter because it doesn't even need it, the others will move out
   of the core into the spi transport class or another module for all spi-like
   drivers, as lots of RAID HBAs want SPI-like scanning
 - starget_for_each_device does id comparims currently, but it can be changed
   to iterate the targets parent devices list easily.

with those smaller bits the scsi core doesn't need to know about the
target id anymore.

now all this is rather pointless as you really love your scheme and don't
want to change anyway, so let's stop this discussion ;-)

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

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> > Cdrecord is a program that needs to be able to send any SCSI command as 
> > it needs to be able to add new vendor unique commands for new drive/feature
> > support.
>
> Right, but evidently it does not need the kernel to invent numbering.
> dev=/dev/hdc works today.

Maybe, I will need to enforce to use official libscg device names in future....

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-01-30:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > > Cdrecord is a program that needs to be able to send any SCSI command as 
> > > it needs to be able to add new vendor unique commands for new drive/feature
> > > support.
> >
> > Right, but evidently it does not need the kernel to invent numbering.
> > dev=/dev/hdc works today.
> 
> Maybe, I will need to enforce to use official libscg device names in future....

If you deem fighting your own user base the appropriate behavior to
enforce your distorted view on groups that outnumber you by at least
five orders of magnitude, go right ahead.

But don't complain if you're losing control that way because Albert or
somebody else really forks cdrecord then and the fork becomes more
popular than the original.

cdrecord wouldn't be the first package to see such things happen.

-- 
Matthias Andree

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

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> > > Right, but evidently it does not need the kernel to invent numbering.
> > > dev=/dev/hdc works today.
> > 
> > Maybe, I will need to enforce to use official libscg device names in future....
>
> If you deem fighting your own user base the appropriate behavior to
> enforce your distorted view on groups that outnumber you by at least
> five orders of magnitude, go right ahead.
>
> But don't complain if you're losing control that way because Albert or
> somebody else really forks cdrecord then and the fork becomes more
> popular than the original.

Many people announced forks in the past, nobody so far did contribute real 
work... 

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-01-30:

> Many people announced forks in the past, nobody so far did contribute real 
> work... 

Only the DVD patches...

-- 
Matthias Andree

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

[Jan Engelhardt]

>> Many people announced forks in the past, nobody so far did contribute real 
>> work... 
>
>Only the DVD patches...
>
Which don't always work. I remember SUSE Linux's pomped-up cdrecord-blahdvd 
thing can't even do DVD-Plus-*, not to mention DVD-DL (some sort of 
DVD-Plus).




Jan Engelhardt
-- 
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

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

[Jeff Garzik]

Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> 
>>>Cdrecord is a program that needs to be able to send any SCSI command as 
>>>it needs to be able to add new vendor unique commands for new drive/feature
>>>support.
>>
>>Right, but evidently it does not need the kernel to invent numbering.
>>dev=/dev/hdc works today.
> 
> 
> Maybe, I will need to enforce to use official libscg device names in future....

To burden users with yet another naming policy?

	Jeff

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

[Joerg Schilling]

Jeff Garzik <jgarzik@pobox.com> wrote:

> >>>Cdrecord is a program that needs to be able to send any SCSI command as 
> >>>it needs to be able to add new vendor unique commands for new drive/feature
> >>>support.
> >>
> >>Right, but evidently it does not need the kernel to invent numbering.
> >>dev=/dev/hdc works today.
> > 
> > 
> > Maybe, I will need to enforce to use official libscg device names in future....
>
> To burden users with yet another naming policy?

Well, I am open to have an unbiased discussion that may have any result but 
the parties should allow each other to convince by arguments.

The main problem currently is that changes in the Linux kernel did burden
cdrecord users and did not cause real benefit.

The longer this discussion lasts, the more I lose the hope that it may end
in useful results. If you believe that there is still a chance, let us start
with a useful discussion or stop it now.

I am just tired to see that none of the Linux kernel bugs that cause problems
for the cdrecord users have been fixed within the last ~ 3 years. Please 
understand that I really could use my time for better things than wasting
it with useless discussions with people that don't even understand the problems.

If you have a proposal that could help, you are welcome. But if there is
no way to have an unbiased discussion, just let os stop now.

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]

>> >>>Cdrecord is a program that needs to be able to send any SCSI command as 
>> >>>it needs to be able to add new vendor unique commands for new drive/feature
>> >>>support.
>> >>
>> >>Right, but evidently it does not need the kernel to invent numbering.
>> >>dev=/dev/hdc works today.
>> > 
>> > Maybe, I will need to enforce to use official libscg device names in future....
>>
>> To burden users with yet another naming policy?
>
>Well, I am open to have an unbiased discussion that may have any result but 
>the parties should allow each other to convince by arguments.
>
The user should use what the OS uses. Cdrecord, or libscg, respectively, 
can invent any numbers it wants. IOW, "we" (read: I) would like to see
  cdrecord -dev=/dev/hdc on Linux

I am not sure if I understood your other mail on the cdrecord ML, but if 
the proper syntax would be
  cdrecord -dev=/dev/hdc:@
then
  /dev/hdc
could just be transparently turned into
  /dev/hdc:@
somewhere within the getopt part.

for other OS:
  cdrecord -dev=/dev/acd0 on FreeBSD
  cdrecord -dev=E: on Win32
    cdrecord -dev=\\cdrom0 if someone really wants for Win32
  cdrecord -dev=/dev/c0t0s0d0 on Solaris
(Don't shoot me. I unfortunately have to make a guess, since I have 
not done yet any cdrecord'ing[1] on OS other than Linux.)

[1] Well with Nero, but that's not cdrecord, as in "cdrecord'ing". :)


Jan Engelhardt
-- 

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

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> The user should use what the OS uses. Cdrecord, or libscg, respectively, 
> can invent any numbers it wants. IOW, "we" (read: I) would like to see
>   cdrecord -dev=/dev/hdc on Linux

Unsupported

> I am not sure if I understood your other mail on the cdrecord ML, but if 
> the proper syntax would be
>   cdrecord -dev=/dev/hdc:@
> then
>   /dev/hdc
> could just be transparently turned into
>   /dev/hdc:@
> somewhere within the getopt part.

See complete description, the :@ is not just for fun....

> for other OS:
>   cdrecord -dev=/dev/acd0 on FreeBSD

Will not work

>   cdrecord -dev=E: on Win32

Will only wbe doable with mapping effort in a few cases.

>     cdrecord -dev=\\cdrom0 if someone really wants for Win32

	cdrecord dev=cdrom0 	works on Solaris because "cdrom0"
				is a valid nick name for the drive.

>   cdrecord -dev=/dev/c0t0s0d0 on Solaris

May work sometimes.

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: 949 bytes --]

>
>> I am not sure if I understood your other mail on the cdrecord ML, but if 
>> the proper syntax would be
>>   cdrecord -dev=/dev/hdc:@
>> then
>>   /dev/hdc
>> could just be transparently turned into
>>   /dev/hdc:@
>> somewhere within the getopt part.
>
>See complete description, the :@ is not just for fun....
>

       "If  the name of the device node that has been speci■
       fied on such a system refers to exactly one SCSI device, a shorthand in
       the form dev= devicename:@ or dev= devicename:@,lun may be used instead
       of dev= devicename:scsibus,target,lun."

So @ is equal to 0,0,0 or 0,0?


Threads indicated that every device under linux is "exactly one SCSI device",
which is why I was asking for this behind-the-scenes translation of /dev/hdc
into /dev/hdc:@.

>> for other OS:
>>   cdrecord -dev=/dev/acd0 on FreeBSD
>
>Will not work
>
I think mount uses this syntax (`mount /dev/acd0 /mnt`).



Jan Engelhardt
-- 

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

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >
> >> I am not sure if I understood your other mail on the cdrecord ML, but if 
> >> the proper syntax would be
> >>   cdrecord -dev=/dev/hdc:@
> >> then
> >>   /dev/hdc
> >> could just be transparently turned into
> >>   /dev/hdc:@
> >> somewhere within the getopt part.
> >
> >See complete description, the :@ is not just for fun....
> >
>
>        "If  the name of the device node that has been speciâ? 
>        fied on such a system refers to exactly one SCSI device, a shorthand in
>        the form dev= devicename:@ or dev= devicename:@,lun may be used instead
>        of dev= devicename:scsibus,target,lun."
>
> So @ is equal to 0,0,0 or 0,0?

":@" is a shorthand for ":@,0" which is a shorthand for ":@0,0" 

There are cases where you may like to use e.g. ":@,3"

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]

>>
>> So @ is equal to 0,0,0 or 0,0?
>
>":@" is a shorthand for ":@,0" which is a shorthand for ":@0,0" 
>
>There are cases where you may like to use e.g. ":@,3"
>

So, since Linux currently does not have anything but ":@,0" per device 
(device file)...


Jan Engelhardt
-- 

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

[Jürg Billeter]

Hi Jörg

On Mon, 2006-01-30 at 12:43 +0100, Joerg Schilling wrote:
> > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
> > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
> > for bus number, id or lun - independent of OS and/or cdrecord?
> 
> The drive does not return this information, but the SCSI subsystem creates
> these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
> be known to the SCSI sub-system and thus needs to have a SCSI subsystem
> related instance number.

Whenever someone talks about ATAPI drives, you respond with
s/ATAPI/SCSI/. Why do you insist that every transport should be used as
it was a SCSI bus? ATAPI drives use the same SCSI command set as SCSI
drives do, but that won't change the fact that ATAPI drives are not
connected to a SCSI bus.

It makes sense to address parallel SCSI devices via target id. If an
operating system likes to simulate virtual SCSI buses for other bus
types as well, ok, I have no objections. But if the operating system
doesn't like to simulate virtual SCSI buses and allows applications to
address devices by a filename, you should have no objections, too.

You and the linux developers just look at the same thing from two
perspectives. You seem to like SCSI buses, so you want to look at every
bus as it is was a SCSI bus. The linux developers seem to like the
principle of looking at single devices without obvious connection to a
physical or virtual bus from the application. There is no right or
wrong, here, that are just two different perspectives. As the linux
developers seem to like their approach - I do as well -, they won't
change their system and recommend application developers to use SG_IO on
device nodes and ignore the physical bus the devices are connected with.

Whatever the interface between cdrecord and libscg is, is obviously your
choice. But the libscg backend for linux should follow the
recommendations of the linux kernel developers and they recommend to use
SG_IO on device nodes, AFAICT. The command line interface of cdrecord is
obviously your choice again but IMO it should integrate in the system it
currently runs on and as linux command line users know how to deal with
device nodes, they want to use them.

As you were having the SCSI-only perspective in mind when writing the
scanbus functionality, it obviously doesn't fit well in the scheme of
the device-based perspective of linux. As there is no virtual parent of
all real and virtual SCSI buses in linux, libscg shouldn't try to find
one. The linux backend of libscg should just use HAL to enumerate the
devices.

It would be nice to get a comment whether this makes sense or which
statements you don't agree with.

Schönen Abend

Jürg
-- 
Jürg Billeter <j@bitron.ch>

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

[Joerg Schilling]

Jürg Billeter <j@bitron.ch> wrote:

> Hi Jörg
>
> On Mon, 2006-01-30 at 12:43 +0100, Joerg Schilling wrote:
> > > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
> > > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
> > > for bus number, id or lun - independent of OS and/or cdrecord?
> > 
> > The drive does not return this information, but the SCSI subsystem creates
> > these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
> > be known to the SCSI sub-system and thus needs to have a SCSI subsystem
> > related instance number.
>
> Whenever someone talks about ATAPI drives, you respond with
> s/ATAPI/SCSI/. Why do you insist that every transport should be used as
> it was a SCSI bus? ATAPI drives use the same SCSI command set as SCSI
> drives do, but that won't change the fact that ATAPI drives are not
> connected to a SCSI bus.

Well, this is simple: it is SCSI.

When SCSI started from modifying the SASI (Shugart Asociated System Interface)
system around 1984 and at that time come with it's own transport only
(a 50 wire cable), this did change soon (around 1986) by introducing
transports that use one or two 68 wire cable(s) (16 resp. 32 Bit SCSI).

Around 1990, even this did change while ATAPI (ATA Packet Interface) was
introduced. 

Around 1995, the T10 standard group (SCSI) did split up the SCSI standard
into a transport specific part and a protocol specific part. SCSI is now using
many different transport mechanisms.

This is a list of some known SCSI transports: 
 
	-	Good old Parallel SCSI 50/68 pin (what most people call SCSI) 
	-	SCSI over fiber optics (e.g. FACL - there are others too) 
	-	SCSI over a copper variant of FCAL (used in modern servers) 
	-	SCSI over IEEE 1394 (Fire Wire) 
	-	SCSI over USB 
	-	SCSI over IDE/ATA (ATAPI) 
	-	SCSI over TCI/IP (iSCSI)
	-	SCSI over SSCSI (see below)

SCSI over Serial SCSI cabling uses the same transport (cable type) as SATA uses.
If you buy a SATA HBA card for your PC, you may connect SSCSI & SATA
disks to this HBA using the same cables and connectors.

So the circle is closing again....


> It makes sense to address parallel SCSI devices via target id. If an
> operating system likes to simulate virtual SCSI buses for other bus
> types as well, ok, I have no objections. But if the operating system
> doesn't like to simulate virtual SCSI buses and allows applications to
> address devices by a filename, you should have no objections, too.

It seems that you missunderstand this. No operating system uses file names
internally. OS instead typically handle SCSI devices that are not connected
via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system
by asuming they are all on separate SCSI busses that only have one single drive 
conected each.

What Linux does is to artificially prevent this view to been seen from outside the
Linux kernel, or to avoid integrating a particular device into a unique SCSI
driver system although it would be apropriate.

Users like to be able to get a list of posible targets for a single protocol.
Nobody would ever think about trying to prevent people from getting a unified
view on the list possible hosts that talk TCP/IP. What cdrecord does with
-scanbus is nothing really different. 

In addition, nobody would ever think about implementing a separate TCP/IP stack 
for network interfaces that are PPP connections via a modem vs. network 
interfaces that go via a Ethernet adaptor. Nobody would ever try to convince
me that you could save code in the kernel by avoiding the usual network stack 
as a specific machine may not have Ethernet but a Modem connection only.

So why do people try to convince me that there is a need to avoid the standard 
SCSI protocol stack because a PC might have only ATAPI? 

Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, 
...). Why do people believe that Linux needs to be different? What does it buy 
you to go this way?


*] MS-WIN-NT even includes SCSI emulation (it allows you to connect to the
SCSI subsystem, set the Address and use SCSI commands from a limited list
to read/write sector from ATA only hard disks).

If the Linux folks could give technical based explanations for the questions 
from above and if they would create a new completely orthogonal view on SCSI [*]
I had no problem. But up to now, the only answer was: "We do it this 
way because we do it this way". 

*] Note that this would need to implement SCSI Generic support for drives that
have no native driver in the system.

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 Jörg!

> It seems that you missunderstand this. No operating system uses file names
> internally.

That's right. OS kernels usually use pointers for that, which are surely
not a reasonable user-space API. On Linux, the user-space API is to address
devices by their names.

> OS instead typically handle SCSI devices that are not connected
> via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system
> by asuming they are all on separate SCSI busses that only have one single drive 
> conected each.
> 
> What Linux does is to artificially prevent this view to been seen from outside the
> Linux kernel, or to avoid integrating a particular device into a unique SCSI
> driver system although it would be apropriate.

How exactly does Linux prevent this???

The devices _are_ integrated in a single driver system, at least from the user-space
point of view. You can call open() on the device name and then send the appropriate
ioctl's. The device names are just strings you shouldn't assume anything about.

Feel free to imagine that every device is on its own bus, nothing in the
kernel steps in your way.

> Users like to be able to get a list of posible targets for a single protocol.
> Nobody would ever think about trying to prevent people from getting a unified
> view on the list possible hosts that talk TCP/IP.

How do you perform -scanbus for TCP/IP? :-)

> In addition, nobody would ever think about implementing a separate TCP/IP stack 
> for network interfaces that are PPP connections via a modem vs. network 
> interfaces that go via a Ethernet adaptor. Nobody would ever try to convince
> me that you could save code in the kernel by avoiding the usual network stack 
> as a specific machine may not have Ethernet but a Modem connection only.

There is an interesting similarity: in the TCP/IP stack, you also shouldn't
assume anything about names of network interfaces, they are just opaque
identifiers (in many times assigned by the administrator, not by the kernel).
The right way of addressing is by IP addresses or DNS names, which is
pretty similar to the addressing of SCSI devices on Linux, isn't it?

> If the Linux folks could give technical based explanations for the questions 
> from above and if they would create a new completely orthogonal view on SCSI [*]
> I had no problem. But up to now, the only answer was: "We do it this 
> way because we do it this way". 

We do it this way, because we see no sense in fabricating virtual SCSI
buses, which do not exist in reality.

Also, I don't see a single reason why should I refer to my CD drive by
different names depending on whether I am mounting a CDROM and if I am
burning a CD. The device is still the same and so should be its name.

Scanning for all available CD burners is of course a nice feature, but
I don't think it should be implemented by asking all existing SCSI-like
devices if they are a CD burner (for example because there can be an
almost infinite number of them, given that you can do SCSI-over-IP
and other similar tricks). The problem of presenting devices to the
users is in no way limited to CD burners or SCSI devices, it's a general
problem and I think we should try to find a complete solution. However,
the approach libscg uses is clearly not applicable to other domains.

				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
"Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> > What Linux does is to artificially prevent this view to been seen from outside the
> > Linux kernel, or to avoid integrating a particular device into a unique SCSI
> > driver system although it would be apropriate.
>
> How exactly does Linux prevent this???

By not treating ATAPI the same as all other SCSI devices.


> > Users like to be able to get a list of posible targets for a single protocol.
> > Nobody would ever think about trying to prevent people from getting a unified
> > view on the list possible hosts that talk TCP/IP.
>
> How do you perform -scanbus for TCP/IP? :-)

There are various programs that do that for you.
You could e.g. send a ping to the broadcast address in order to find hosts
that are on the local network.


> > In addition, nobody would ever think about implementing a separate TCP/IP stack 
> > for network interfaces that are PPP connections via a modem vs. network 
> > interfaces that go via a Ethernet adaptor. Nobody would ever try to convince
> > me that you could save code in the kernel by avoiding the usual network stack 
> > as a specific machine may not have Ethernet but a Modem connection only.
>
> There is an interesting similarity: in the TCP/IP stack, you also shouldn't
> assume anything about names of network interfaces, they are just opaque
> identifiers (in many times assigned by the administrator, not by the kernel).
> The right way of addressing is by IP addresses or DNS names, which is
> pretty similar to the addressing of SCSI devices on Linux, isn't it?

If you understand this, why then insists other people in using names like 
/dev/hd*?



> Scanning for all available CD burners is of course a nice feature, but
> I don't think it should be implemented by asking all existing SCSI-like
> devices if they are a CD burner (for example because there can be an
> almost infinite number of them, given that you can do SCSI-over-IP
> and other similar tricks). The problem of presenting devices to the

And while this kind of scanning works in case that you have all devices 
integrated inside a single SCSI implementation, it does not work for ATAPI
because someont artificially decided to exclude one single SCSI transport 
from the global view.

And regarding iSCSI, If you like to talk to such a device, you need to 
authentificate first. This is typically done by the kernel that in turn
trnaferres the remote iSCSI device into a virtual local SCSI device.



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]

[stripping Cc: list]

Joerg Schilling schrieb am 2006-01-31:

> Martin Mares <mj@ucw.cz> wrote:
> 
> > > What Linux does is to artificially prevent this view to been seen from outside the
> > > Linux kernel, or to avoid integrating a particular device into a unique SCSI
> > > driver system although it would be apropriate.
> >
> > How exactly does Linux prevent this???
> 
> By not treating ATAPI the same as all other SCSI devices.

Nonsense. cdrecord can access ATAPI devices, fix your libscg device
enumeration.

> > How do you perform -scanbus for TCP/IP? :-)
> 
> There are various programs that do that for you.
> You could e.g. send a ping to the broadcast address in order to find hosts
> that are on the local network.

Responding to broadcast ping, at least when outside the LAN, is
considered a security issue.

> > Scanning for all available CD burners is of course a nice feature, but
> > I don't think it should be implemented by asking all existing SCSI-like
> > devices if they are a CD burner (for example because there can be an
> > almost infinite number of them, given that you can do SCSI-over-IP
> > and other similar tricks). The problem of presenting devices to the
> 
> And while this kind of scanning works in case that you have all devices 
> integrated inside a single SCSI implementation, it does not work for ATAPI
> because someont artificially decided to exclude one single SCSI transport 
> from the global view.

You need to work around this anyhow because the already-released 2.6
kernels will not be going away in the next 2 - 3 years even if 2.6
were fixed today.

-- 
Matthias Andree

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

[Martin Mares]

Hello!

> > How exactly does Linux prevent this???
> 
> By not treating ATAPI the same as all other SCSI devices.

Sorry, but that's false. Not treating ATAPI the same can at most
complicate it, but in no way prevent.

> > How do you perform -scanbus for TCP/IP? :-)
> 
> There are various programs that do that for you.
> You could e.g. send a ping to the broadcast address in order to find hosts
> that are on the local network.

Eh, so you are just going to treate the local network differently? ;-)

> If you understand this, why then insists other people in using names like 
> /dev/hd*?

Because at least on Linux, the NAMES are the primary identifier for user
space, not numbers of some virtual SCSI buses which don't exist in the
real world anyway.

For everything else (well, except network interfaces, but that's a different
story), we refer by names. Even when using the SCSI devices for other
purposes, we refer to them by names. Why should burning a CD be different?

I believe that this is the crucial question and the one you should
answer first, before trying to force others to share your view of the world.

> And while this kind of scanning works in case that you have all devices 
> integrated inside a single SCSI implementation, it does not work for ATAPI
> because someont artificially decided to exclude one single SCSI transport 
> from the global view.

No, you are just wrongly considering something to be a global view,
which it in fact isn't.

				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)

[Jan Engelhardt]

>> > Users like to be able to get a list of posible targets for a single protocol.
>> > Nobody would ever think about trying to prevent people from getting a unified
>> > view on the list possible hosts that talk TCP/IP.
>>
>> How do you perform -scanbus for TCP/IP? :-)
>
>There are various programs that do that for you.
>You could e.g. send a ping to the broadcast address in order to find hosts
>that are on the local network.

ping is ICMP/IP, therefore is not relevant to the question ;)
`nmap -sT` would probably do more TCP.

>If you understand this, why then insists other people in using names like 
>/dev/hd*?

It's shorter than /dev/c0t0d0s0? Well, I think it's because people think 
in terms of connectors (my drive is IDE therefore it must be hdc) rather 
than protocol (my drive does ATAPI therefore it must be 
/dev/scsi/c0t0d0s0).


Jan Engelhardt
-- 

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

[Ian Kester-Haney]

Shouldn't actively developed applications use the current methods for
accessing ddevices on target operating systems.  It seems to me that
linux/gnu users are moving away from cdrecord and it ilk because of
the artificial limitations imposed by its libscg counterpart. 
Backward compatibility is being phased out in the linux kernel to
allow for better ways to access and use devices in the system.  While
the technical nature of transport specifications might be tracked down
to an underlying SCSI mechanism, it is by no means an exclusive deal. 
Perhaps linux doesn't need cdrecord and this whole mess will go away.
Real users don't care as long as it works, even the old kernel used
/dev/* names.
Give it up.

---------------------------------------------
Only morons respond to flames
guilty as charged
----------------------------------------------

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

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> It's shorter than /dev/c0t0d0s0? Well, I think it's because people think 
> in terms of connectors (my drive is IDE therefore it must be hdc) rather 
> than protocol (my drive does ATAPI therefore it must be 
> /dev/scsi/c0t0d0s0).

Is there any reason why the people with small PCs should dominate the 
people with big machines?

If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks.

The systematical attempt is easy to remember even with a big amount of 
external hardware.

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!

> Is there any reason why the people with small PCs should dominate the 
> people with big machines?
> 
> If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks.

And this is why the current Linux naming scheme (udev etc.) gives you
the possibility to use both types of names.

When I have a single CD writer, it's silly to have to think about where
exactly it is connected. I refer to it as /dev/cdrw and everything is easy.

When I have multiple writers, I start to care about more -- but usually
it's still better to avoid using bus addresses (they are not too stable
-- after changing disks, I often end up with connecting my 2 CDWR's
to different controllers) and use udev to maintain stable naming.
I use /dev/cdrom-upper and /dev/cdrom-lower, which are assigned based
on manufacturer and serial number.

This is even easier to remember with a big amount of hardware :-)

And, which is more important, this scheme works for everything --
drives, mice, network interfaces and so on.

I don't see any reason why cdrecord on Linux should invent a different
naming scheme, especially as nobody has so far demonstrated any of its
advantages.

				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
MIPS: Meaningless Indicator of Processor Speed.

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-02:

> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > It's shorter than /dev/c0t0d0s0? Well, I think it's because people think 
> > in terms of connectors (my drive is IDE therefore it must be hdc) rather 
> > than protocol (my drive does ATAPI therefore it must be 
> > /dev/scsi/c0t0d0s0).
> 
> Is there any reason why the people with small PCs should dominate the 
> people with big machines?

No side should dominate.

> If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks.

I don't see how a letter such as /dev/hdo /dev/hdp /dev/hdq is much
different than an opaque number tuple as 1,15,0 1,16,0 1,17,0... either
is a string with systematic generation, and that's about it.

I'm still wondering why mtst (mid-layer access to control tape drives)
is happy with /dev/nst0 nst1 ... (device name) and cdrecord (or its
author) isn't. cdrecord or libscg should be agnostic of these schemas
and take any opaque string that works properly for the given system
without complaining. It can invent any numbering scheme it likes, but
requesting that the kernel does it if it has no further use for it is
barking up the wrong tree.

-- 
Matthias Andree

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

[Bartlomiej Zolnierkiewicz]

On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Jürg Billeter <j@bitron.ch> wrote:
>
> > Hi Jörg
> >
> > On Mon, 2006-01-30 at 12:43 +0100, Joerg Schilling wrote:
> > > > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of
> > > > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked
> > > > for bus number, id or lun - independent of OS and/or cdrecord?
> > >
> > > The drive does not return this information, but the SCSI subsystem creates
> > > these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
> > > be known to the SCSI sub-system and thus needs to have a SCSI subsystem
> > > related instance number.
> >
> > Whenever someone talks about ATAPI drives, you respond with
> > s/ATAPI/SCSI/. Why do you insist that every transport should be used as
> > it was a SCSI bus? ATAPI drives use the same SCSI command set as SCSI
> > drives do, but that won't change the fact that ATAPI drives are not
> > connected to a SCSI bus.
>
> Well, this is simple: it is SCSI.
>
> When SCSI started from modifying the SASI (Shugart Asociated System Interface)
> system around 1984 and at that time come with it's own transport only
> (a 50 wire cable), this did change soon (around 1986) by introducing
> transports that use one or two 68 wire cable(s) (16 resp. 32 Bit SCSI).
>
> Around 1990, even this did change while ATAPI (ATA Packet Interface) was
> introduced.
>
> Around 1995, the T10 standard group (SCSI) did split up the SCSI standard
> into a transport specific part and a protocol specific part. SCSI is now using
> many different transport mechanisms.
>
> This is a list of some known SCSI transports:
>
>         -       Good old Parallel SCSI 50/68 pin (what most people call SCSI)
>         -       SCSI over fiber optics (e.g. FACL - there are others too)
>         -       SCSI over a copper variant of FCAL (used in modern servers)
>         -       SCSI over IEEE 1394 (Fire Wire)
>         -       SCSI over USB
>         -       SCSI over IDE/ATA (ATAPI)
>         -       SCSI over TCI/IP (iSCSI)
>         -       SCSI over SSCSI (see below)
>
> SCSI over Serial SCSI cabling uses the same transport (cable type) as SATA uses.
> If you buy a SATA HBA card for your PC, you may connect SSCSI & SATA
> disks to this HBA using the same cables and connectors.
>
> So the circle is closing again....
>
>
> > It makes sense to address parallel SCSI devices via target id. If an
> > operating system likes to simulate virtual SCSI buses for other bus
> > types as well, ok, I have no objections. But if the operating system
> > doesn't like to simulate virtual SCSI buses and allows applications to
> > address devices by a filename, you should have no objections, too.
>
> It seems that you missunderstand this. No operating system uses file names
> internally. OS instead typically handle SCSI devices that are not connected
> via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system
> by asuming they are all on separate SCSI busses that only have one single drive
> conected each.
>
> What Linux does is to artificially prevent this view to been seen from outside the
> Linux kernel, or to avoid integrating a particular device into a unique SCSI
> driver system although it would be apropriate.
>
> Users like to be able to get a list of posible targets for a single protocol.
> Nobody would ever think about trying to prevent people from getting a unified
> view on the list possible hosts that talk TCP/IP. What cdrecord does with
> -scanbus is nothing really different.

Yes and it is Linux limitation (lets face it).   There are 2 problems:

* no generic block layer transport infrastructure so that you cannot
  specify in the low-level driver which transport types your device does
  support (this information would be exported to the applications).

  Jens, maybe sysfs attribute "transports" will be sufficient so that
  application  can use libsysfs to get full list of devices supporting "SCSI"
  transport (/dev/hd* is fine with this scheme).  Does it make sense?
  Having block layer sysfs attributes for device type (disk, tape, cd etc)
  would have additional bonus of not needing to inquire wrong device
  types.  This would probably simplify other applications (HAL?).
  [ These are just quick ideas... ]

  Joerg, I don't see any sense in providing users with fake SCSI
  lun and bus numbers for ATAPI devices.  I think that what users
  would like is the list of devices consisting of "fd" and actual vendor
  name of device (+ optionally serial no + optionally "x:y:z" for real
  SCSI).  Nobody wants to see some artificial "x:y:z" for her/his
  ATAPI device (it has always annoyed me in Windows), not to say
  that the majority of desktop users have absolutely no idea of meaning
  of these numbers.

* ide-* drivers for ATAPI devices are needed (some devices just doesn't
  work with ide-scsi ATM) so please accept this fact that we cannot just
  now simply switch over everything to using ide-scsi and we have to use
  SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add
  support for it).  I'm not saying this won't change in future but this requires
  doing actual work and people seem to be more interested in discussing
  stupid naming issues than doing it so...

> In addition, nobody would ever think about implementing a separate TCP/IP stack
> for network interfaces that are PPP connections via a modem vs. network
> interfaces that go via a Ethernet adaptor. Nobody would ever try to convince
> me that you could save code in the kernel by avoiding the usual network stack
> as a specific machine may not have Ethernet but a Modem connection only.
>
> So why do people try to convince me that there is a need to avoid the standard
> SCSI protocol stack because a PC might have only ATAPI?

SCSI protocol stack is far too Parallel SCSI centric (vide SAS flamewar).
Once again this is Linux problem which will get fixed with time or will fix
itself if we switch to libata for PATA.

> Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris,
> ...). Why do people believe that Linux needs to be different? What does it buy
> you to go this way?

Linux needs to be better, no? ;-)

> *] MS-WIN-NT even includes SCSI emulation (it allows you to connect to the
> SCSI subsystem, set the Address and use SCSI commands from a limited list
> to read/write sector from ATA only hard disks).
>
> If the Linux folks could give technical based explanations for the questions
> from above and if they would create a new completely orthogonal view on SCSI [*]
> I had no problem. But up to now, the only answer was: "We do it this
> way because we do it this way".

The answer is - we do this this way because of historical reasons and we
simply lack resources to change it immediately (be it your "everything is
SCSI" or mine "block layer devices claiming supported transport types").

Please also note things don't change because you say so - they require
somebody doing actual work and work/time is not free (despite what some
people think).  If you think that badmouthing Linux will motivate people to
work, you are wrong (it has the opposite effect of time wasting flamewars).

I would like you to ask to remove warnings from about /dev/hd* interface
from cdrecored - they are just confusing users.  This is the current way
of doing things in Linux and applications have to deal with it for now.

Thanks,
Bartlomiej

> *] Note that this would need to implement SCSI Generic support for drives that
> have no native driver in the system.

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

[Joerg Schilling]

Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

>   Joerg, I don't see any sense in providing users with fake SCSI
>   lun and bus numbers for ATAPI devices.  I think that what users
>   would like is the list of devices consisting of "fd" and actual vendor
>   name of device (+ optionally serial no + optionally "x:y:z" for real
>   SCSI).  Nobody wants to see some artificial "x:y:z" for her/his
>   ATAPI device (it has always annoyed me in Windows), not to say
>   that the majority of desktop users have absolutely no idea of meaning
>   of these numbers.

This is called integration and it is done by Linux e.g. for 1394 and USB SCSI 
devices. So why not for ATAPI?


> * ide-* drivers for ATAPI devices are needed (some devices just doesn't
>   work with ide-scsi ATM) so please accept this fact that we cannot just
>   now simply switch over everything to using ide-scsi and we have to use
>   SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add
>   support for it).  I'm not saying this won't change in future but this requires
>   doing actual work and people seem to be more interested in discussing
>   stupid naming issues than doing it so...

Well, the problem with ide-scsi is not a general one but caused by a simple
bug that needs to be fixed.


> > So why do people try to convince me that there is a need to avoid the standard
> > SCSI protocol stack because a PC might have only ATAPI?
>
> SCSI protocol stack is far too Parallel SCSI centric (vide SAS flamewar).
> Once again this is Linux problem which will get fixed with time or will fix
> itself if we switch to libata for PATA.

If this is true for Linux, it should be fixed. But this is not a general 
problem.

> > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris,
> > ...). Why do people believe that Linux needs to be different? What does it buy
> > you to go this way?
>
> Linux needs to be better, no? ;-)

In case that Linux would offer better methods, I would not complain.


> > If the Linux folks could give technical based explanations for the questions
> > from above and if they would create a new completely orthogonal view on SCSI [*]
> > I had no problem. But up to now, the only answer was: "We do it this
> > way because we do it this way".
>
> The answer is - we do this this way because of historical reasons and we
> simply lack resources to change it immediately (be it your "everything is
> SCSI" or mine "block layer devices claiming supported transport types").

This is obviously not true: There _was_ (and still is) a useful implementation 
with minor bugs. But instead of fixing the minor bugs, a lot of work has been 
done to introduce a new and unneded new interface.

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-01-31:

> > Linux needs to be better, no? ;-)
> 
> In case that Linux would offer better methods, I would not complain.

Well, you are closing your eyes before these methods. I'm not going to
repeat that.

I suggest that the discussion end here because you are evidently
unwilling to look at the pointers you were given.

-- 
Matthias Andree

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

[Martin Mares]

Hello!

> This is obviously not true: There _was_ (and still is) a useful implementation 
> with minor bugs. But instead of fixing the minor bugs, a lot of work has been 
> done to introduce a new and unneded new interface.

Some would say that ide-scsi is the thing which was new and unneeded.
The ide-cd driver was there first.

				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
Even nostalgia isn't what it used to be.

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

[Bartlomiej Zolnierkiewicz]

On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> >   Joerg, I don't see any sense in providing users with fake SCSI
> >   lun and bus numbers for ATAPI devices.  I think that what users
> >   would like is the list of devices consisting of "fd" and actual vendor
> >   name of device (+ optionally serial no + optionally "x:y:z" for real
> >   SCSI).  Nobody wants to see some artificial "x:y:z" for her/his
> >   ATAPI device (it has always annoyed me in Windows), not to say
> >   that the majority of desktop users have absolutely no idea of meaning
> >   of these numbers.
>
> This is called integration and it is done by Linux e.g. for 1394 and USB SCSI
> devices. So why not for ATAPI?

Because we have native drivers which do not require SCSI stack et all.

> > * ide-* drivers for ATAPI devices are needed (some devices just doesn't
> >   work with ide-scsi ATM) so please accept this fact that we cannot just
> >   now simply switch over everything to using ide-scsi and we have to use
> >   SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add
> >   support for it).  I'm not saying this won't change in future but this requires
> >   doing actual work and people seem to be more interested in discussing
> >   stupid naming issues than doing it so...
>
> Well, the problem with ide-scsi is not a general one but caused by a simple
> bug that needs to be fixed.

Please _reread_ this paragraph:
* some devices (not cd-writers) doesn't work with ide-scsi
* they require quirks which are in ide-cd so it ide-cd needs to stay as a driver
* if is very useful if cd-writing can be done with ide-cd and without SCSI stack
  (a hack but very useful one)

[ more below ]

> > > If the Linux folks could give technical based explanations for the questions
> > > from above and if they would create a new completely orthogonal view on SCSI [*]
> > > I had no problem. But up to now, the only answer was: "We do it this
> > > way because we do it this way".
> >
> > The answer is - we do this this way because of historical reasons and we
> > simply lack resources to change it immediately (be it your "everything is
> > SCSI" or mine "block layer devices claiming supported transport types").
>
> This is obviously not true: There _was_ (and still is) a useful implementation
> with minor bugs. But instead of fixing the minor bugs, a lot of work has been
> done to introduce a new and unneded new interface.

>From technical point of view:

pros:
* you don't need SCSI stack (a lot of code saved!)
* you use subsystem native driver (a lot of complexity with locking
etc avoided!)
* you don't need to provide users with fake data (SCSI lun and bus)

cons:
* user-space applications need to support it

What are the _technical_ problems with SG_IO interface besides
issue with enumaration of devices available in the system?

I know that you don't like SG_IO but it is hardly technical argument.

Thanks,
Bartlomiej

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

[Jan Engelhardt]

>>
>> This is called integration and it is done by Linux e.g. for 1394 and USB SCSI
>> devices. So why not for ATAPI?
>
>Because we have native drivers which do not require SCSI stack et all.
>
>* if [ED: it] is very useful if cd-writing can be done with ide-cd and without
>  SCSI stack (a hack but very useful one)
>* you don't need SCSI stack (a lot of code saved!)


Which unfortunately leads us back to one of the early questions.

If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
floating around?



Jan Engelhardt
-- 

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

[Bartlomiej Zolnierkiewicz]

On 2/1/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >>
> >> This is called integration and it is done by Linux e.g. for 1394 and USB SCSI
> >> devices. So why not for ATAPI?
> >
> >Because we have native drivers which do not require SCSI stack et all.
> >
> >* if [ED: it] is very useful if cd-writing can be done with ide-cd and without
> >  SCSI stack (a hack but very useful one)
> >* you don't need SCSI stack (a lot of code saved!)
>
>
> Which unfortunately leads us back to one of the early questions.
>
> If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
> without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
> floating around?

No, because this code belongs to the block layer (scsi_ioctl.c)
and is shared between SCSI and IDE drivers.

BTW This was already at least once explained in this thread.

Bartlomiej

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

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> Which unfortunately leads us back to one of the early questions.
>
> If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
> without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
> floating around?

CONFIG_SCSI???

Why not using fully dynamical loadable kernel modules as done with Solaris 
since 1992? Since that time nobody cares because what you need is auto-loaded 
on demand and there is absolutely no need for a manual configuration.

BTW: Introducing an orthogonal SCSI based implementation would save a lot of
code. The model currently used on Linux is duplicating a lot of unneeded code 
in target drivers and the SCSI glue code is only a few KB (less than 30k on 
Solaris). 

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

> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > Which unfortunately leads us back to one of the early questions.
> >
> > If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
> > without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
> > floating around?
> 
> CONFIG_SCSI???
> 
> Why not using fully dynamical loadable kernel modules as done with Solaris 
> since 1992? Since that time nobody cares because what you need is auto-loaded 
> on demand and there is absolutely no need for a manual configuration.

You mean:

Module                  Size  Used by
...
scsi_transport_spi     20864  1 sym53c8xx
scsi_mod              131304  7 st,sr_mod,sg,sym53c8xx,scsi_transport_spi,libata,sd_mod
...

autoloaded on boot, and scsi_mod has verbose sense strings built in
(call it bloat, but on a Peeceeh a few kB don't hurt).

libata is Linux's SATA driver, still under development but quite solid
for some chips, such as via 82*. Chances are that adding PATA to libata
(which is planned or in the works) obsoletes your whole ATAPI ide-* module
arguments, sym53c8xx - no surprise - the host adaptor driver, sr/sd_mod
the CD-ROM and disk block drivers, st and sg tape and generic drivers.

> BTW: Introducing an orthogonal SCSI based implementation would save a lot of
> code. The model currently used on Linux is duplicating a lot of unneeded code 
> in target drivers and the SCSI glue code is only a few KB (less than 30k on 
> Solaris). 

You've been stating this oft enough now. It won't change in a day even
if you post this every hour. Please cease posting the same stuff over
and over again.

-- 
Matthias Andree

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

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> > BTW: Introducing an orthogonal SCSI based implementation would save a lot of
> > code. The model currently used on Linux is duplicating a lot of unneeded code 
> > in target drivers and the SCSI glue code is only a few KB (less than 30k on 
> > Solaris). 
>
> You've been stating this oft enough now. It won't change in a day even
> if you post this every hour. Please cease posting the same stuff over
> and over again.

Why do you repeat posting false claims over and over?

May be we should really stop this thread.

Unless I see any move towards a more realistic way of looking at things
it does not make sense to repeat things and short time later I will see
the same unadequate replies as I did see days before.

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

> > > BTW: Introducing an orthogonal SCSI based implementation would save a lot of
> > > code. The model currently used on Linux is duplicating a lot of unneeded code 
> > > in target drivers and the SCSI glue code is only a few KB (less than 30k on 
> > > Solaris). 
> >
> > You've been stating this oft enough now. It won't change in a day even
> > if you post this every hour. Please cease posting the same stuff over
> > and over again.
> 
> Why do you repeat posting false claims over and over?

This is getting ridiculous. Point to a single false claim in the mail
you were replying to.

The only claim there was that you are posting the same stuff again and
again, and it is obviously true, as can be demostrated by anybody who
can use grep.

> Unless I see any move towards a more realistic way of looking at things
> it does not make sense to repeat things and short time later I will see
> the same unadequate replies as I did see days before.

Yes. You have been repeatedly asked to produce any sound arguments why the
current interface is bad.

So far, you have produced none. You have only written about Linux not
following your personal model of virtual SCSI buses, which is maybe
a good argument for supporting your dislike for Linux, but nothing else.

Also, you mentioned several phantoms like IDE tapes, which nobody seems
to care about, a couple of bugs which the driver developers were willing
to fix if you tell how to reproduce them.

Finally, you mentioned problems with scanning and you were told that:
(1) the current scanning code in libscg works at least for all currently
existing transports, if a trivial bug is fixed,
(2) for a complete view of the available HW, you should use the HAL,
(3) most people prefer either using a GUI interface which converges to
using HAL anyway, or refer to devices by their names.

The rest was just hand-waving.

The interface preferred by Linux has changed for very good reasons,
and a number of such reasons has been demonstrated. Also, it's not
changing daily, the switchover from emulating SCSI to performing SG_IO
directly on /dev/hd* was the only big change in last 10 years.

So unless anybody has any new arguments for either approach, let's end
this thread.

				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
Outside of a dog, a book is man's best friend. Inside a dog, it's too dark to read.

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

[Martin Mares]

Hello!

> Why not using fully dynamical loadable kernel modules as done with Solaris 
> since 1992? Since that time nobody cares because what you need is auto-loaded 
> on demand and there is absolutely no need for a manual configuration.

Yes, but it still eats the memory if loaded.

> BTW: Introducing an orthogonal SCSI based implementation would save a lot of
> code. The model currently used on Linux is duplicating a lot of unneeded code 
> in target drivers and the SCSI glue code is only a few KB (less than 30k on 
> Solaris). 

Please stop beating a dead horse and diverting this discussion to irrelevant
implementation details.

What we were (and should be) discussing are the interfaces. If you have
any sound arguments against the current interface, speak up.

Whether the interface leads to code duplication is neither yours nor
mine to judge -- the only people who should care are the maintainers
of the drivers and they seem to be happy with the current approach
and they are willing to improve it to simplify scanning.

				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
"Beware of bugs in the above code; I have only proved it correct, not tried it." -- D.E.K.

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

[Jens Axboe]

On Thu, Feb 02 2006, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > Which unfortunately leads us back to one of the early questions.
> >
> > If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
> > without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
> > floating around?
> 
> CONFIG_SCSI???
> 
> Why not using fully dynamical loadable kernel modules as done with
> Solaris since 1992? Since that time nobody cares because what you need
> is auto-loaded on demand and there is absolutely no need for a manual
> configuration.
> 
> BTW: Introducing an orthogonal SCSI based implementation would save a
> lot of code. The model currently used on Linux is duplicating a lot of
> unneeded code in target drivers and the SCSI glue code is only a few
> KB (less than 30k on Solaris). 

I have to comment on that... Your original gripe was the we should not
have so much duplicated code - which of course was shot down, we don't
have much duplicated code, basically a few hundred lines at most. And
that solely remains because /dev/sg* still exists and isn't fully
integrated with bsg (the block layer sg, which is probably misnamed as
it could be used char devices as well).

So this mail from you basically shoots huge holes in your original
gripe. The whole SCSI stack is redundant code in this scheme. A quick
check over my current tree shows over 23 _thousand_ lines of code (SCSI
stack + ide-scsi)! Auto-loading modules has _nothing_ to do with it,
it's still redundant code.

I could go on, but the point should be crystal clear already so I'll
stop. Joerg, unless you have any technical arguments please stop this
thread. And here I do mean ones that are correct. You repeatedly either
ignore mails asking you to backup your claims - or you reply to them
saying "Please stop making false claims!". Honestly, I have no idea why
you are doing that.

-- 
Jens Axboe

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

[Jan Engelhardt]

>> Which unfortunately leads us back to one of the early questions.
>>
>> If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
>> without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
>> floating around?
>
>CONFIG_SCSI???
>

What else?

>Why not using fully dynamical loadable kernel modules as done with Solaris 

Do you think I have scsi built-in? Not at all.

lsmod::
sg                     20120  0
sd_mod                 12304  0
usb_storage            73408  0
usbcore               108256  5 uhci_hcd,ohci_hcd,ehci_hcd,usb_storage
scsi_mod              103496  3 sg,sd_mod,usb_storage

/proc/config.gz:
CONFIG_SCSI=m
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_CONSTANTS=y

that's about all.

>since 1992? Since that time nobody cares because what you need is auto-loaded 
>on demand and there is absolutely no need for a manual configuration.


Jan Engelhardt
-- 
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

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

[jerome lacoste]

On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Jürg Billeter <j@bitron.ch> wrote:
[...]
> Users like to be able to get a list of posible targets for a single protocol.

The Linux users (I know of) like to be able to reference their drives
the way their Operating System names them.

If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'.

Should we make a poll ?

Jerome

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

[Oliver Neukum]

Am Dienstag, 31. Januar 2006 13:24 schrieb jerome lacoste:
> On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > Jürg Billeter <j@bitron.ch> wrote:
> [...]
> > Users like to be able to get a list of posible targets for a single protocol.
> 
> The Linux users (I know of) like to be able to reference their drives
> the way their Operating System names them.
> 
> If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'.
> 
> Should we make a poll ?

It is entirely possible that the people you know are far from a representative
sample. Most people likely prefer clicking on a description in a GUI. There
needs to be a way to get this list and if possible it should not be specific
to Linux.

	Regards
		Oliver

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

[Denis Vlasenko]

On Tuesday 31 January 2006 14:33, Oliver Neukum wrote:
> Am Dienstag, 31. Januar 2006 13:24 schrieb jerome lacoste:
> > On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > > Jürg Billeter <j@bitron.ch> wrote:
> > [...]
> > > Users like to be able to get a list of posible targets for a single protocol.
> > 
> > The Linux users (I know of) like to be able to reference their drives
> > the way their Operating System names them.
> > 
> > If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'.
> > 
> > Should we make a poll ?
> 
> It is entirely possible that the people you know are far from a representative
> sample. Most people likely prefer clicking on a description in a GUI. There
> needs to be a way to get this list and if possible it should not be specific
> to Linux.

Do we need to expose IDE master/slave, primary/secondary concepts in Linux?

So far I was perfectly happy with just /dev/hd[a-z][0-9]*
--
vda

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

[Jan Engelhardt]

>> > If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'.
>> > 
>> > Should we make a poll ?

select(), poll(), epoll(), anyone? (SCNR)

>Do we need to expose IDE master/slave, primary/secondary concepts in Linux?
>
AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's
(surprisingly) the other way round, sda just happens to be the first disk
inserted (SCA, USB, etc.)


Jan Engelhardt
-- 

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

[Bernd Petrovitsch]

On Wed, 2006-02-01 at 16:37 +0100, Jan Engelhardt wrote:
[...]
> >Do we need to expose IDE master/slave, primary/secondary concepts in Linux?
> >
> AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's
> (surprisingly) the other way round, sda just happens to be the first disk
> inserted (SCA, USB, etc.)

The (historical) reason was: There were not enough major/minor numbers
(IIRC 8 bit for each of them) for a sane (and static) SCSI device number
mapping (similar to IDE) - just multiply the possible # of partitions *
# of LUNs * # IDs for a few controllers.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

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

[Albert Cahalan]

On 2/1/06, Bernd Petrovitsch <bernd@firmix.at> wrote:
> On Wed, 2006-02-01 at 16:37 +0100, Jan Engelhardt wrote:
> [...]
> > >Do we need to expose IDE master/slave, primary/secondary concepts in Linux?
> > >
> > AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's
> > (surprisingly) the other way round, sda just happens to be the first disk
> > inserted (SCA, USB, etc.)
>
> The (historical) reason was: There were not enough major/minor numbers
> (IIRC 8 bit for each of them) for a sane (and static) SCSI device number
> mapping (similar to IDE) - just multiply the possible # of partitions *
> # of LUNs * # IDs for a few controllers.

It's a hashing problem, and should have originally been seen as such.
The constraints are that you'd like some stability as devices come
and go. Splitting /dev into fields could have worked nicely:

1. the partition
2. dev type: disk, CD-ROM, built-in (ramdisk,loop), other
3. physical: master/slave, SCSI target, IDE 1/2/other, "is USB"...
4. volatile+rare stuff: PCI slot, ISA address, USB position, LUN

(needlessly crammed into 16 bits: 5:2:4:5 or 5:2:5:4)

For the physical stuff, per-driver values are assigned explicitly
in the source code. Collisions are determined by humans. We make
USB collide with something old, like XT disks and Atari disks.
Collisions are chosen so that normal machines are unlikely to
suffer from them.

Note that I use "IDE 1/2/other". Only an x86 PC can have a primary
or secondary controller, as determined by IO port location. Macs
just have "other", as a single value. (they differentiate based on
the rare and volatile stuff as needed) USB is distinguished from SCSI,
FireWire, and IDE unless delibrately made to collide because of a bit
shortage.

Collisions found at run-time are resolved by mucking with the field
for volatile and rare stuff. Adding a new USB device can will probably
not mess up a different USB device, because the hashing is not too
likely to pick the same number. Adding a new USB device will certainly
not mess up a non-USB device unless the non-USB device is in a class
of physical devices that was delibrately made to collide with USB.
Adding a SCSI device with target ID 4 will only stand a chance of
messing up other SCSI devices with target ID 4, on other busses or
with other LUNs. It wouldn't mess up SCSI target ID 3, FireWire, USB,
or anything else UNLESS those share the "physical" field ID.

Not that Joerg would like this: LUN values and bus numbers get tossed
into a hash function. You can't recover the individual numbers.

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

[Bartlomiej Zolnierkiewicz]

On 2/1/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >> > If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'.
> >> >
> >> > Should we make a poll ?
>
> select(), poll(), epoll(), anyone? (SCNR)
>
> >Do we need to expose IDE master/slave, primary/secondary concepts in Linux?
> >
> AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's

Ehm, primary master and it is not true if you are using host drivers as modules.

Moreover providing ordering by IDE driver has been nightmare to maintain
and can't be done correctly for 100% weird cases.

> (surprisingly) the other way round, sda just happens to be the first disk
> inserted (SCA, USB, etc.)

Which is much saner approach from developers' POV.

Bartlomiej

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

[Jan Engelhardt]

>> >Do we need to expose IDE master/slave, primary/secondary concepts in Linux?
>> >
>> AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's
>
>Ehm, primary master and it is not true if you are using host drivers as modules.
>
Whoops, you are right. However, even with, say, an extra PCI IDE controller,
the ordering of the drives within that controller is "as usual", e.g. the order
is "pri ma","pri sl","sec ma","sec sl", of course relative to the start of the
respective controller.

>Moreover providing ordering by IDE driver has been nightmare to maintain
>and can't be done correctly for 100% weird cases.

So how much weird cases do we have?

>> (surprisingly) the other way round, sda just happens to be the first disk
>> inserted (SCA, USB, etc.)
>
>Which is much saner approach from developers' POV.
>
Developer... and about the user/admin? With a sparcbox (ran suse linux 7.3 the
last time it was powered on - 2.4 kernel, no udev - don't complain :),
replugging disks in put them at the end of the 'sd*' naming
chain, effectively killing the features of hotplug the machine itself offered.
(Oh, that OS starting with S.. managed it with the help of the behated/-loved
c?d?t?s? scheme, but that's OT.)



Jan Engelhardt
-- 

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

[Kyle Moffett]

On Feb 01, 2006, at 11:28, Jan Engelhardt wrote:
>> Moreover providing ordering by IDE driver has been nightmare to  
>> maintain and can't be done correctly for 100% weird cases.
>
> So how much weird cases do we have?

Speaking from personal experience, _waay_ too many.  On my old G4  
which now serves as a fileserver, I have 5 IDE busses out of 3  
controllers (Onboard ATA-66 with 2 busses, onboard ATA-33 with one  
bus, add-in PCI ATA-100 with 2 busses)  There's a _config_ option to  
control probe order specific to the two Apple onboard interfaces, and  
it used to be (before udev) that option was a nightmare to ensure  
that my new kernel has the same probe order as the old one.  Once you  
throw PCI hotplug into the mix, reliable probing order is impossible,  
and you should just use udev to dynamically assign names.


>>> (surprisingly) the other way round, sda just happens to be the  
>>> first disk
>>> inserted (SCA, USB, etc.)
>>
>> Which is much saner approach from developers' POV.
>
> Developer... and about the user/admin? With a sparcbox (ran suse  
> linux 7.3 the last time it was powered on - 2.4 kernel, no udev -  
> don't complain :), replugging disks in put them at the end of the  
> 'sd*' naming chain, effectively killing the features of hotplug the  
> machine itself offered. (Oh, that OS starting with S.. managed it  
> with the help of the behated/-loved c?d?t?s? scheme, but that's OT.)

Yeah, 2.4 was bad at hotplug, everybody knows that already.  This is  
why the changes were made for 2.6 to add udev and hal and make it  
much saner.

Cheers,
Kyle Moffett

--
I lost interest in "blade servers" when I found they didn't throw  
knives at people who weren't supposed to be in your machine room.
   -- Anthony de Boer

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

[Xavier Bestel]

On Tue, 2006-01-31 at 13:33, Oliver Neukum wrote:
> It is entirely possible that the people you know are far from a representative
> sample. Most people likely prefer clicking on a description in a GUI. There
> needs to be a way to get this list and if possible it should not be specific
> to Linux.

As repeated over and over here, there is such a way, it's called HAL and
it is cross-platform. And it's what's used by some GUIs out there (e.g.
nautilus-cd-burner).

	Xav

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

[Joerg Schilling]

Xavier Bestel <xavier.bestel@free.fr> wrote:

> On Tue, 2006-01-31 at 13:33, Oliver Neukum wrote:
> > It is entirely possible that the people you know are far from a representative
> > sample. Most people likely prefer clicking on a description in a GUI. There
> > needs to be a way to get this list and if possible it should not be specific
> > to Linux.
>
> As repeated over and over here, there is such a way, it's called HAL and
> it is cross-platform. And it's what's used by some GUIs out there (e.g.
> nautilus-cd-burner).

The fact that people here repeat unadquate proposals forces me to repeat my 
proposals. Name a list fo OS that implement HAL and then look at the list
of crecord supported platforms 
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)

[Xavier Bestel]

On Thu, 2006-02-02 at 12:19, Joerg Schilling wrote:
> Xavier Bestel <xavier.bestel@free.fr> wrote:
> 
> > On Tue, 2006-01-31 at 13:33, Oliver Neukum wrote:
> > > It is entirely possible that the people you know are far from a representative
> > > sample. Most people likely prefer clicking on a description in a GUI. There
> > > needs to be a way to get this list and if possible it should not be specific
> > > to Linux.
> >
> > As repeated over and over here, there is such a way, it's called HAL and
> > it is cross-platform. And it's what's used by some GUIs out there (e.g.
> > nautilus-cd-burner).
> 
> The fact that people here repeat unadquate proposals forces me to repeat my 
> proposals. Name a list fo OS that implement HAL and then look at the list
> of crecord supported platforms 

Well ... from your sayings it seems Linux is supported by HAL but not by
libscg. 

	Xav

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

[Joerg Schilling]

Xavier Bestel <xavier.bestel@free.fr> wrote:

> > > As repeated over and over here, there is such a way, it's called HAL and
> > > it is cross-platform. And it's what's used by some GUIs out there (e.g.
> > > nautilus-cd-burner).
> > 
> > The fact that people here repeat unadquate proposals forces me to repeat my 
> > proposals. Name a list fo OS that implement HAL and then look at the list
> > of crecord supported platforms 
>
> Well ... from your sayings it seems Linux is supported by HAL but not by
> libscg. 

Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since
10 years.

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)

[Xavier Bestel]

Hi Jörg,

On Thu, 2006-02-02 at 13:51, Joerg Schilling wrote:
> Xavier Bestel <xavier.bestel@free.fr> wrote:
> > Well ... from your sayings it seems Linux is supported by HAL but not by
> > libscg. 
> 
> Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since
> 10 years.

I understand your point, but believe me, *nobody* wants one HAL per
application. There need to be only one HAL for all, and as freedesktop's
HAL has the functionnality necessary for cdrecord (minus perhaps a few
fixable bugs), but libscg is SCSI-only (and for the matter, can't work
with Linux IDE devices), cdrecord would better move to HAL for its CD
writer discovery.

Of course, the perfect outcome of this would be you turning cdrecord
into a shared library which could be used by apps as they see fit, using
their own means of selecting a CD writer and reporting errors and
completion.

Regards,
	Xav

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

[Joerg Schilling]

Xavier Bestel <xavier.bestel@free.fr> wrote:

> On Thu, 2006-02-02 at 13:51, Joerg Schilling wrote:
> > Xavier Bestel <xavier.bestel@free.fr> wrote:
> > > Well ... from your sayings it seems Linux is supported by HAL but not by
> > > libscg. 
> > 
> > Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since
> > 10 years.
>
> I understand your point, but believe me, *nobody* wants one HAL per
> application. There need to be only one HAL for all, and as freedesktop's
> HAL has the functionnality necessary for cdrecord (minus perhaps a few

If people don't want this confusion, why do they start with a new system?

libscg & cdrecord have been available long before Linux HAL was there.

And the most important argument here is that it is extremely unlikely that
this Linux HAL will handle all oddities of all CD/DVD-writers, do it is 
unapropriate to use this interface in case that you like to get more 
information than just "the drive is there".

Note that UNIX people usually believe that is is best practice to have this 
kind of software intergrated in the kernel (or at leat in the system). This is 
what FreeBSD did try for some years, and FreeBSD has failed with this attempt.

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

> libscg & cdrecord have been available long before Linux HAL was there.

Perhaps libscg was too arcane and too badly integrated into Linux?

> And the most important argument here is that it is extremely unlikely that
> this Linux HAL will handle all oddities of all CD/DVD-writers, do it is 
> unapropriate to use this interface in case that you like to get more 
> information than just "the drive is there".
> 
> Note that UNIX people usually believe that is is best practice to have this 
> kind of software intergrated in the kernel (or at leat in the system). This is 
> what FreeBSD did try for some years, and FreeBSD has failed with this attempt.

So why would Linux want to have it in the kernel if it hasn't worked for
FreeBSD either? Thanks for proving it doesn't belong there BTW.

-- 
Matthias Andree

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

[Jan Engelhardt]

>> 
>> Note that UNIX people usually believe that is is best practice to have this 
>> kind of software intergrated in the kernel (or at leat in the system). This is 
>> what FreeBSD did try for some years, and FreeBSD has failed with this attempt.
>
>So why would Linux want to have it in the kernel if it hasn't worked for
>FreeBSD either? Thanks for proving it doesn't belong there BTW.
>
There's also something in the FreeBSD kernel that does work there, but has 
not worked out as good for Linux ;-) [devfs]

Therefore I would not generalize it and say "if it did not work on <x>, we 
don't need to implement it for our <y>".


Jan Engelhardt
-- 

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-03:
>
> > libscg & cdrecord have been available long before Linux HAL was there.
>
> Perhaps libscg was too arcane and too badly integrated into Linux?

>From a cdrecord point of view, this seems to rather apply to Linux HAL.


> > Note that UNIX people usually believe that is is best practice to have this 
> > kind of software intergrated in the kernel (or at leat in the system). This is 
> > what FreeBSD did try for some years, and FreeBSD has failed with this attempt.
>
> So why would Linux want to have it in the kernel if it hasn't worked for
> FreeBSD either? Thanks for proving it doesn't belong there BTW.

Please try to understand my text before answering.

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)

[Xavier Bestel]

On Fri, 2006-02-03 at 10:55, Joerg Schilling wrote:
> Xavier Bestel <xavier.bestel@free.fr> wrote:
> > I understand your point, but believe me, *nobody* wants one HAL per
> > application. There need to be only one HAL for all, and as freedesktop's
> > HAL has the functionnality necessary for cdrecord (minus perhaps a few
> 
> If people don't want this confusion, why do they start with a new system?
> 
> libscg & cdrecord have been available long before Linux HAL was there.

Because libscg handles only SCSI, whereas HAL does work for all disk
types, floppies, serial ports, PCI buses, graphics cards, processors,
etc. Imagine there was one library per peripheral type - oh the pain.

> And the most important argument here is that it is extremely unlikely that
> this Linux HAL will handle all oddities of all CD/DVD-writers, do it is 
> unapropriate to use this interface in case that you like to get more 
> information than just "the drive is there".

For now, it sure doesn't equal cdrecord in that area. But give it time
and it will progress. After all, there's no reason HAL can't gain from
your expertise on the matter.

> Note that UNIX people usually believe that is is best practice to have this 
> kind of software intergrated in the kernel (or at leat in the system). This is 
> what FreeBSD did try for some years, and FreeBSD has failed with this attempt.

AFAIR this was deemed too complex to live in kernelspace. Maybe
FreeBSD's failure is a good indication it's true.

	Xav

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

[grundig]

El Thu, 02 Feb 2006 13:51:19 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:

> Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since
> 10 years.


libscg being there for 10 years doesn't means that it's the right or the
better way of doing things.

Hal is _the_ HAL for linux, in fact HAL is targetted to become _the_
"standard" (freedesktop standard) HAL for open operative systems. HAL
should be already available on solaris, at least there's a @sun.com guy
who created a hald/solaris/ directory (gnome is already using HAL and
sun is interested in gnome). It doesn't seem to do nothing today but I
bet that sun is interested in getting HAL working in solaris (there're
at least people in the opensolaris mailing lists interested). I guess
the BSD guys will end up implementing BSD support some day aswell - desktop
is not as important for them as it is for linux.

So the fact is that HAL is quickly becoming _the_ HAL for unix systems.

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

[Joerg Schilling]

<grundig@teleline.es> wrote:

> El Thu, 02 Feb 2006 13:51:19 +0100,
> Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:
>
> > Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since
> > 10 years.
>
>
> libscg being there for 10 years doesn't means that it's the right or the
> better way of doing things.

Any new implementation first needs to prove that it is durable and (more 
important) that it is actively maintained. I am sure that this kind of software 
will never handle all oddities in drive firmware we know from CD/DVD-writers.


> Hal is _the_ HAL for linux, in fact HAL is targetted to become _the_
> "standard" (freedesktop standard) HAL for open operative systems. HAL
> should be already available on solaris, at least there's a @sun.com guy
> who created a hald/solaris/ directory (gnome is already using HAL and
> sun is interested in gnome). It doesn't seem to do nothing today but I

I know this person, but Sun is creating reliable software for customers and for 
this reason, it is most unlikely that an incompatible change like this will 
be intregrated before Solaris 11 GA is available to the end of 2007.
It may appear earlier in Solaris 11 beta's, but this is a different thing.

> bet that sun is interested in getting HAL working in solaris (there're
> at least people in the opensolaris mailing lists interested). I guess
> the BSD guys will end up implementing BSD support some day aswell - desktop
> is not as important for them as it is for linux.
>
> So the fact is that HAL is quickly becoming _the_ HAL for unix systems.

I hope that Sun will not base Sun's implementations on ideas on the Linux 
implementaion which is known to be an "unfriendly" program as it causes 
problems with CD/DVD-writing.

Since 1992, Sun has vold and vold is rock solid. Vold nicely coexists with 
cdrecord in the right way: It does not send inapropriate SCSI commnds to the 
drives and it does not send too many of them in a certain period of 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)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-03:

> Any new implementation first needs to prove that it is durable and (more 
> important) that it is actively maintained. I am sure that this kind of software 
> will never handle all oddities in drive firmware we know from CD/DVD-writers.

The suggestion was to use it for device enumeration and then talking
ioctl(...SG_IO...) to the device so obtained.

-- 
Matthias Andree

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

[Jan Engelhardt]

>> >
>> > As repeated over and over here, there is such a way, it's called HAL and
>> > it is cross-platform. And it's what's used by some GUIs out there (e.g.
>> > nautilus-cd-burner).
>> 
>> The fact that people here repeat unadquate proposals forces me to repeat my 
>> proposals. Name a list fo OS that implement HAL and then look at the list
>> of crecord supported platforms 
>
>Well ... from your sayings it seems Linux is supported by HAL but not by
>libscg. 
>
But sounds like freedesktop-hal is not available for all platforms libscg
currently works on!


Jan Engelhardt
-- 

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

[Alexander Samad]

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

On Thu, Feb 02, 2006 at 05:20:13PM +0100, Jan Engelhardt wrote:
> >> >
> >> > As repeated over and over here, there is such a way, it's called HAL and
> >> > it is cross-platform. And it's what's used by some GUIs out there (e.g.
> >> > nautilus-cd-burner).
> >> 
> >> The fact that people here repeat unadquate proposals forces me to repeat my 
> >> proposals. Name a list fo OS that implement HAL and then look at the list
> >> of crecord supported platforms 
> >
> >Well ... from your sayings it seems Linux is supported by HAL but not by
> >libscg. 
> >
> But sounds like freedesktop-hal is not available for all platforms libscg
> currently works on!

I presume that the system api are not the same between OS either, so why
can't there be different methods of interacting with the
cdburners/cddrives!

> 
> 
> Jan Engelhardt
> -- 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

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

[Juerg Billeter]

Thanks for your detailed response.

On Die, 2006-01-31 at 11:30 +0100, Joerg Schilling wrote:
> Jürg Billeter <j@bitron.ch> wrote:
> > It makes sense to address parallel SCSI devices via target id. If an
> > operating system likes to simulate virtual SCSI buses for other bus
> > types as well, ok, I have no objections. But if the operating system
> > doesn't like to simulate virtual SCSI buses and allows applications to
> > address devices by a filename, you should have no objections, too.
> 
> It seems that you missunderstand this. No operating system uses file names
> internally. OS instead typically handle SCSI devices that are not connected
> via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system
> by asuming they are all on separate SCSI busses that only have one single drive 
> conected each.

Are you sure about that? I don't doubt that many operating systems
handle all devices, that are able to understand the SCSI command set,
exactly as you describe it, but Linux doesn't assume such separate
virtual SCSI buses for non good old Parallel SCSI drives, not even
internally, as far as I understand it. Of course it doesn't use file
names internally, it uses major and minor numbers, but that shouldn't
matter, the major and minor numbers get exported to userspace via sysfs.

> 
> What Linux does is to artificially prevent this view to been seen from outside the
> Linux kernel, or to avoid integrating a particular device into a unique SCSI
> driver system although it would be apropriate.

That's the point where you're not quite right, if I understand it
correctly. The Linux kernel does not artificially prevent userspace
applications viewing virtual SCSI buses, these virtual SCSI buses don't
exist internally in the Linux kernel at all. So Linux doesn't
artificially prevent anything, it just doesn't artificially _create_
virtual SCSI buses.


> Users like to be able to get a list of posible targets for a single protocol.
> Nobody would ever think about trying to prevent people from getting a unified
> view on the list possible hosts that talk TCP/IP. What cdrecord does with
> -scanbus is nothing really different. 

Well, please show me how to get the list of all possible hosts that talk
TCP/IP and are directly or indirectly connected to my computer. As my
computer is attached to the internet, the list would get pretty long...
And even if only considering hosts in the local network, how do you get
a unified view of all TCP/IP hosts conected to any of my two network
adapters?


> So why do people try to convince me that there is a need to avoid the standard 
> SCSI protocol stack because a PC might have only ATAPI? 
> 
> Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, 
> ...). Why do people believe that Linux needs to be different? What does it buy 
> you to go this way?

Why do you believe that Linux needs to do the same as every other OS?
I'd agree with you if Linux would violate a standard but AFAIK the bus
view with target ids is not part of the ATAPI or a dependant standard.
Please correct me if I'm wrong but the bus/target/lun combination is
only a standard for some SCSI transports, at least it is for good old
Parallel SCSI, yes, but SCSI over ATA doesn't define target-based
addressing.

> *] MS-WIN-NT even includes SCSI emulation (it allows you to connect to the
> SCSI subsystem, set the Address and use SCSI commands from a limited list
> to read/write sector from ATA only hard disks).

Great, I have no objections but you shouldn't mandate the Linux kernel
developers to implement a copy of implementations other operating
systems provide. If the virtual SCSI bus and/or full SCSI emulation
would be part of POSIX or an other standard Linux tries to follow, Linux
should implement it, of course, but last time I checked, it's not in
POSIX.

> 
> If the Linux folks could give technical based explanations for the questions 
> from above and if they would create a new completely orthogonal view on SCSI [*]
> I had no problem. But up to now, the only answer was: "We do it this 
> way because we do it this way". 

Linux' device nodes is such an orthogonal view that should include all
devices able to speak SCSI among others. Enumeration is possible via
sysfs (low-level) or much easier via the userspace HAL library from
freedesktop.org.

> 
> *] Note that this would need to implement SCSI Generic support for drives that
> have no native driver in the system.

If there is a device that supports the SCSI command set and the device
can't be accessed with SG_IO in linux, I'd call this a Linux kernel bug.
You mentioned ATAPI tapes before; if that's really the case, it's a
Linux bug, yes, but it seems that nobody cares about speaking SCSI with
these device types. That happens in projects with limited resources.

My point is that this shouldn't matter to cdrecord. It does matter to
tape drive applications that use libscg, of course. File a bug in
bugzilla about that and if ATAPI tapes are important to a Linux
developer, he will probably implement it. But a Linux bug affecting some
device or bus types doesn't automatically mean that the whole Linux
kernel device addressing is broken by design.

Jürg

-- 
Juerg Billeter <j@bitron.ch>

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

[Joerg Schilling]

Juerg Billeter <j@bitron.ch> wrote:

> > So why do people try to convince me that there is a need to avoid the standard 
> > SCSI protocol stack because a PC might have only ATAPI? 
> > 
> > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, 
> > ...). Why do people believe that Linux needs to be different? What does it buy 
> > you to go this way?
>
> Why do you believe that Linux needs to do the same as every other OS?

Why do you believe that Linux needs to be worse than other OS?

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!

> > Why do you believe that Linux needs to do the same as every other OS?
> 
> Why do you believe that Linux needs to be worse than other OS?

Sorry, but so far you have failed to produce a single plausible argument
why the way chosen by Linux is worse.

				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
The number of UNIX installations has grown to 10, with more expected.  (6/72)

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

[Jim Crilly]

On 01/31/06 02:37:22PM +0100, Joerg Schilling wrote:
> Juerg Billeter <j@bitron.ch> wrote:
> 
> > > So why do people try to convince me that there is a need to avoid the standard 
> > > SCSI protocol stack because a PC might have only ATAPI? 
> > > 
> > > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, 
> > > ...). Why do people believe that Linux needs to be different? What does it buy 
> > > you to go this way?
> >
> > Why do you believe that Linux needs to do the same as every other OS?
> 
> Why do you believe that Linux needs to be worse than other OS?
> 

Every other method to access those devices uses the device name, i.e.
mount, fsck, etc, so why should cdrecord be different?

> Jörg


Jim.

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

[Joerg Schilling]

Jim Crilly <jim@why.dont.jablowme.net> wrote:

> Every other method to access those devices uses the device name, i.e.
> mount, fsck, etc, so why should cdrecord be different?

inadequateness on Linux did force libscg to go this way.

The current method used by libscg is well established since 10 years.

Now Linux likes to confuse people by trying to enforce a completely 
incompatible access method.

Note that I need to avoid unneeded efforts and for this reason, I need to wait
5 years until is is forseable that a recent incompatible change in Linux will
survive long enough to spent time on it.



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)

[grundig]

El Thu, 02 Feb 2006 12:17:09 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:

> Note that I need to avoid unneeded efforts and for this reason, I need to wait
> 5 years until is is forseable that a recent incompatible change in Linux will
> survive long enough to spent time on it.


Woah. No comments.

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

[Martin Mares]

Hello!

> Now Linux likes to confuse people by trying to enforce a completely 
> incompatible access method.

Completely incompatible? For years, cdrecord works with it and it only
prints an utterly silly warning and also has a trivial bug in the scanning
code, causing it to stop too early.

> Note that I need to avoid unneeded efforts and for this reason, I need to wait
> 5 years until is is forseable that a recent incompatible change in Linux will
> survive long enough to spent time on it.

If this is reason, I will send you a patch fixing the trivial bugs and
annoyances, sparing you the work.

				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
"I don't give a damn for a man that can only spell a word one way." -- M. Twain

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-02:

> Jim Crilly <jim@why.dont.jablowme.net> wrote:
> 
> > Every other method to access those devices uses the device name, i.e.
> > mount, fsck, etc, so why should cdrecord be different?
> 
> inadequateness on Linux did force libscg to go this way.
> 
> The current method used by libscg is well established since 10 years.
> 
> Now Linux likes to confuse people by trying to enforce a completely 
> incompatible access method.
> 
> Note that I need to avoid unneeded efforts and for this reason, I need to wait
> 5 years until is is forseable that a recent incompatible change in Linux will
> survive long enough to spent time on it.

It is incompatible? Looks like the code is already implemented and ATA:
is in the regular device name space (where RSCSI and the other options
reside as well).

-- 
Matthias Andree

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

[Jim Crilly]

On 02/02/06 12:17:09PM +0100, Joerg Schilling wrote:
> Jim Crilly <jim@why.dont.jablowme.net> wrote:
> 
> > Every other method to access those devices uses the device name, i.e.
> > mount, fsck, etc, so why should cdrecord be different?
> 
> inadequateness on Linux did force libscg to go this way.
> 

And inadequacies are what's causing libscg and 'cdrecord -scanbus' to fail
to list all IDE devices on Linux. Unless the comments about it stopping the
scan after getting -EPERM on one device are wrong.

> The current method used by libscg is well established since 10 years.

So? Change isn't always a bad thing.

> Now Linux likes to confuse people by trying to enforce a completely 
> incompatible access method.

>From my point of view it's cdrecord that's confusing Linux users by trying
to force a completely different device naming method on users for no good
reason.

> Note that I need to avoid unneeded efforts and for this reason, I need to wait
> 5 years until is is forseable that a recent incompatible change in Linux will
> survive long enough to spent time on it.

I could be wrong, but don't all of the other OSes that cdrecord and
libscg support access the device via the device node? When I mount
a device on Solaris I use /dev/c0t0d0s0 (or whatever it is)and not
0:0:0, right? So it would be safe to assume that users are used to
using that form of names for their devices, so why should cdrecord
be the odd man out?

Jim.

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

[Albert Cahalan]

On 2/2/06, Jim Crilly <jim@why.dont.jablowme.net> wrote:
> On 02/02/06 12:17:09PM +0100, Joerg Schilling wrote:
> > Jim Crilly <jim@why.dont.jablowme.net> wrote:
> >
> > > Every other method to access those devices uses the device name, i.e.
> > > mount, fsck, etc, so why should cdrecord be different?
> >
> > inadequateness on Linux did force libscg to go this way.
> >
>
> And inadequacies are what's causing libscg and 'cdrecord -scanbus' to fail
> to list all IDE devices on Linux. Unless the comments about it stopping the
> scan after getting -EPERM on one device are wrong.

I'm seeing even worse behavior. Since /dev/hda is a disk with mounted
filesystems, my kernel refuses access even for root. Thus, even root
is unable to scan the /dev/hd* devices!

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

[Jan Engelhardt]

>
>I'm seeing even worse behavior. Since /dev/hda is a disk with mounted
>filesystems, my kernel refuses access even for root. Thus, even root
>is unable to scan the /dev/hd* devices!
>
What sort of kernel patch do you have turned on? I'd be scared if I could 
not even do a (read-only!) hexdump of my drive while mounted.


Jan Engelhardt
-- 

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

[Jim Crilly]

On 02/02/06 09:39:02PM +0100, Jan Engelhardt wrote:
> >
> >I'm seeing even worse behavior. Since /dev/hda is a disk with mounted
> >filesystems, my kernel refuses access even for root. Thus, even root
> >is unable to scan the /dev/hd* devices!
> >
> What sort of kernel patch do you have turned on? I'd be scared if I could 
> not even do a (read-only!) hexdump of my drive while mounted.
> 

I see the same thing with, the only external kernel patch I have
applied is Suspend2. The ATA scanbus code tries to 
open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
the scanning code stops once one device fails to open the whole scan
aborts. Apparently O_EXCL was added by Ubuntu and Debian to stop
burns being corrupted by hald polling the device while a disc is
being burned. If you want to read the entire thread it's bug #262678
in Debian.

Jim.

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

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> I see the same thing with, the only external kernel patch I have
> applied is Suspend2. The ATA scanbus code tries to 
> open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since

This is not cdrecord but a bastardized version......

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)

[Jim Crilly]

On 02/02/06 10:20:18PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > I see the same thing with, the only external kernel patch I have
> > applied is Suspend2. The ATA scanbus code tries to 
> > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> 
> This is not cdrecord but a bastardized version......
> 
> Jörg

I know it's not your official version, I was merely pointing out where the
'problem' was coming from.

Jim.

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

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> > 
> > This is not cdrecord but a bastardized version......

> I know it's not your official version, I was merely pointing out where the
> 'problem' was coming from.

This was only a short reply.... see also my longer reply from today.


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)

[Albert Cahalan]

On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
>
> > I see the same thing with, the only external kernel patch I have
> > applied is Suspend2. The ATA scanbus code tries to
> > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
>
> This is not cdrecord but a bastardized version......

True enough, but it would work great if you'd fix that bug
that makes cdrecord give up while scanning. I guess
that's one more patch Debian will be applying.

Using O_EXCL is kind of broken, because you'll need to
retry any failures, but that's life. You hacked cdrecord to
properly interact with the Solaris volume manager. You
can do the same for HAL.

Giving up while scanning is a problem for other reasons.
Let me introduce you to SE Linux. One can have RAWIO
capability, RT capability, mlock() capability, and still not
have the right to access all devices. You might not even
be able to get stat() to succeed, but you could burn a CD
if you use the correct device file.

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

[Jan Engelhardt]

>Giving up while scanning is a problem for other reasons.
>Let me introduce you to SE Linux. One can have RAWIO
>capability, RT capability, mlock() capability, and still not
>have the right to access all devices. You might not even
>be able to get stat() to succeed, but you could burn a CD
>if you use the correct device file.
>
Unfortunately, setting up SELinux is currently not easy.

Jan Engelhardt
-- 
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

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

[Joerg Schilling]

Albert Cahalan <acahalan@gmail.com> wrote:

> On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> >
> > > I see the same thing with, the only external kernel patch I have
> > > applied is Suspend2. The ATA scanbus code tries to
> > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> >
> > This is not cdrecord but a bastardized version......
>
> True enough, but it would work great if you'd fix that bug
> that makes cdrecord give up while scanning. I guess
> that's one more patch Debian will be applying.

As including O_EXCL would disallow to use more than one cdrecord
program at the same time, there is no chance for the mains stream source.

> Using O_EXCL is kind of broken, because you'll need to
> retry any failures, but that's life. You hacked cdrecord to
> properly interact with the Solaris volume manager. You
> can do the same for HAL.

Well the big difference with Solaris is that several modifications have been 
applied by Sun to the vold sub-system on Solaris in order to decently 
support cdrecord.

The last change was done with Nevada Build 21 in August 2005.

It makes sense for Linux not to ignore CD/DVD writing. Solaris also did
chose not to ignore 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)

[Jim Crilly]

On 02/03/06 04:20:47PM +0100, Joerg Schilling wrote:
> Albert Cahalan <acahalan@gmail.com> wrote:
> 
> > On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > > "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> > >
> > > > I see the same thing with, the only external kernel patch I have
> > > > applied is Suspend2. The ATA scanbus code tries to
> > > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> > >
> > > This is not cdrecord but a bastardized version......
> >
> > True enough, but it would work great if you'd fix that bug
> > that makes cdrecord give up while scanning. I guess
> > that's one more patch Debian will be applying.
> 
> As including O_EXCL would disallow to use more than one cdrecord
> program at the same time, there is no chance for the mains stream source.

Maybe I'm just being thick, but wouldn't that only prevent you from using
cdrecord on the same device multiple times? The only thing I can see being
opened with O_EXCL is the target device.

> > Using O_EXCL is kind of broken, because you'll need to
> > retry any failures, but that's life. You hacked cdrecord to
> > properly interact with the Solaris volume manager. You
> > can do the same for HAL.
> 
> Well the big difference with Solaris is that several modifications have been 
> applied by Sun to the vold sub-system on Solaris in order to decently 
> support cdrecord.
> 
> The last change was done with Nevada Build 21 in August 2005.
> 
> It makes sense for Linux not to ignore CD/DVD writing. Solaris also did
> chose not to ignore cdrecord.
> 
> Jörg

A bug in HAL is not a bug in Linux. If the HAL people need to make some
changes to their daemon to make it play nice with cdrecord and the like
that's fine, but telling people here makes no sense.

Jim.

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

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> A bug in HAL is not a bug in Linux. If the HAL people need to make some
> changes to their daemon to make it play nice with cdrecord and the like
> that's fine, but telling people here makes no sense.

Please let us either asume that it is in or not....

If you tell me it is not in, then cdrecord definitely needs everything
it currently does just because Linux is missing any needed feature.

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)

[Krzysztof Halasa]

"Jim Crilly" <jim@why.dont.jablowme.net> writes:

> A bug in HAL is not a bug in Linux. If the HAL people need to make some
> changes to their daemon to make it play nice with cdrecord and the like
> that's fine, but telling people here makes no sense.

Does that mean that hald doesn't actually play nice with cdrecord?
-- 
Krzysztof Halasa

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

[Jim Crilly]

On 02/03/06 06:49:21PM +0100, Krzysztof Halasa wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> writes:
> 
> > A bug in HAL is not a bug in Linux. If the HAL people need to make some
> > changes to their daemon to make it play nice with cdrecord and the like
> > that's fine, but telling people here makes no sense.
> 
> Does that mean that hald doesn't actually play nice with cdrecord?
> -- 
> Krzysztof Halasa
> -

That's what the bug reports in Debian and Ubuntu say, the periodic polling
that hald does on the CD devices causes interruptions in the burning
process.

Jim.

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

[Joerg Schilling]

Krzysztof Halasa <khc@pm.waw.pl> wrote:

> "Jim Crilly" <jim@why.dont.jablowme.net> writes:
>
> > A bug in HAL is not a bug in Linux. If the HAL people need to make some
> > changes to their daemon to make it play nice with cdrecord and the like
> > that's fine, but telling people here makes no sense.
>
> Does that mean that hald doesn't actually play nice with cdrecord?

I cannot speak from own experiences on Linux here, but this is what I see:

-	If you check Linux distributions for related bug reports,
	you find many problems with hald.

-	If you try to find similar bug reports for Solaris vold, there is
	no report I am aware of.

Trying to rate this would make me asume that hald could be changed to play
better with 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)

[Olivier Galibert]

On Fri, Feb 03, 2006 at 10:53:50AM -0500, Jim Crilly wrote:
> A bug in HAL is not a bug in Linux. If the HAL people need to make some
> changes to their daemon to make it play nice with cdrecord and the like
> that's fine, but telling people here makes no sense.

Actually, since at that point in time HAL is the only way to do device
discovery with the linux kernel, problems in HAL are problems in
linux.  There is *no* other way than HAL to do the mapping between a
point in the sysfs tree and a device node in /dev[1].

  OG.

[1] Unless you consider stating every node in /dev acceptable just to
find the correct major/minor.

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

[Kay Sievers]

On Fri, Feb 03, 2006 at 07:04:21PM +0100, Olivier Galibert wrote:
> On Fri, Feb 03, 2006 at 10:53:50AM -0500, Jim Crilly wrote:
> > A bug in HAL is not a bug in Linux. If the HAL people need to make some
> > changes to their daemon to make it play nice with cdrecord and the like
> > that's fine, but telling people here makes no sense.
> 
> Actually, since at that point in time HAL is the only way to do device
> discovery with the linux kernel, problems in HAL are problems in
> linux.  There is *no* other way than HAL to do the mapping between a
> point in the sysfs tree and a device node in /dev[1].

That's all nonsense!

  $ udevinfo -r -q name -p /block/sr0
  /dev/sr0

  $ udevinfo -q path -n /dev/sr0
  /block/sr0

  $ udevinfo -q all -p /block/sr0
  P: /block/sr0
  N: sr0
  S: disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0
  S: cdrecorder
  S: cdrom
  E: ID_VENDOR=MATSHITA
  E: ID_MODEL=DVD-RAM_UJ-822S
  E: ID_REVISION=1.61
  E: ID_SERIAL=
  E: ID_TYPE=cd
  E: ID_BUS=scsi
  E: ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0

Kay

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

[Olivier Galibert]

On Fri, Feb 03, 2006 at 07:13:14PM +0100, Kay Sievers wrote:
> That's all nonsense!
> 
>   $ udevinfo -r -q name -p /block/sr0
>   /dev/sr0

Ok, I couldn't find it for love or money.  But it's exactly what's
needed.

I see all the useful information is in /dev/.udev.tdb.  I need to have
a look at that TDB format, but exporting the database to other
programs works.

  OG.

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

[Jim Crilly]

On 02/03/06 07:04:21PM +0100, Olivier Galibert wrote:
> On Fri, Feb 03, 2006 at 10:53:50AM -0500, Jim Crilly wrote:
> > A bug in HAL is not a bug in Linux. If the HAL people need to make some
> > changes to their daemon to make it play nice with cdrecord and the like
> > that's fine, but telling people here makes no sense.
> 
> Actually, since at that point in time HAL is the only way to do device
> discovery with the linux kernel, problems in HAL are problems in
> linux.  There is *no* other way than HAL to do the mapping between a
> point in the sysfs tree and a device node in /dev[1].
> 
>   OG.
> 
> [1] Unless you consider stating every node in /dev acceptable just to
> find the correct major/minor.

It's not about device discovery, hald is polling removable devices every 2s
to see if new media was inserted and when it polls a CD drive that's
currently burning a disc it causes problems. It's documented in Debian bug
#262678.

Jim.

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

[Krzysztof Halasa]

"Jim Crilly" <jim@why.dont.jablowme.net> writes:

> It's not about device discovery, hald is polling removable devices every 2s
> to see if new media was inserted and when it polls a CD drive that's
> currently burning a disc it causes problems. It's documented in Debian bug
> #262678.

Ok. So what's wrong with cdrecord using O_EXCL (and maybe retrying
for few seconds) so no other program (hald or, say, a user mistaking
a device) can interrupt it?

And, if we are here, what's wrong with hald using O_EXCL to not
interrupt any other program (does hald need to check the media
if it's in use)? I assume the problem wouldn't exist with hald
using O_EXCL and cdrecord not (yet) using it, would it?
-- 
Krzysztof Halasa

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

[Matthias Andree]

On Sat, 04 Feb 2006, Krzysztof Halasa wrote:

> And, if we are here, what's wrong with hald using O_EXCL to not
> interrupt any other program (does hald need to check the media
> if it's in use)? I assume the problem wouldn't exist with hald
> using O_EXCL and cdrecord not (yet) using it, would it?

Let me throw in a stupid question: Is O_EXCL cooperative, in that other
access is only blocked if both tasks use open(...O_EXCL...)?

-- 
Matthias Andree

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

[Jan Engelhardt]

>
>> And, if we are here, what's wrong with hald using O_EXCL to not
>> interrupt any other program (does hald need to check the media
>> if it's in use)? I assume the problem wouldn't exist with hald
>> using O_EXCL and cdrecord not (yet) using it, would it?
>
>Let me throw in a stupid question: Is O_EXCL cooperative, in that other
>access is only blocked if both tasks use open(...O_EXCL...)?
>
That would be some sort of "shared" what you describe.

O_EXCL basically means that there may only be one file descriptor open on 
it across the whole kernel. "if both tasks" already includes multiple file 
descriptors. (Note that dup() does not really make a new filedescriptor.)


Jan Engelhardt
-- 

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

[Jan Engelhardt]

>> It's not about device discovery, hald is polling removable devices every 2s
>> to see if new media was inserted and when it polls a CD drive that's
>> currently burning a disc it causes problems. It's documented in Debian bug
>> #262678.
>
>Ok. So what's wrong with cdrecord using O_EXCL (and maybe retrying
>for few seconds) so no other program (hald or, say, a user mistaking
>a device) can interrupt it?
>
I would say we all forgot to RTFM. Because O_EXCL does nothing *unless* 
O_CREAT is specified, which probably *is not* specified in cdrecord or 
hal. There is no reason to have hal or cdrecord create a device node - 
which you can't do with open() anyway.


Jan Engelhardt
-- 
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

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

[Krzysztof Halasa]

Jan Engelhardt <jengelh@linux01.gwdg.de> writes:

> I would say we all forgot to RTFM. Because O_EXCL does nothing *unless* 
> O_CREAT is specified, which probably *is not* specified in cdrecord or 
> hal.

That would be the case if the CD writter wasn't a block device.

For a block device fs/block_dev.c:

static int blkdev_open(struct inode * inode, struct file * filp)
{
...

        if (!(filp->f_flags & O_EXCL) )
                return 0;

        if (!(res = bd_claim(bdev, filp)))
                return 0;

        blkdev_put(bdev);
        return res;
-- 
Krzysztof Halasa

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

[Phillip Susi]

Jan Engelhardt wrote:
> I would say we all forgot to RTFM. Because O_EXCL does nothing *unless* 
> O_CREAT is specified, which probably *is not* specified in cdrecord or 
> hal. There is no reason to have hal or cdrecord create a device node - 
> which you can't do with open() anyway.
> 

I think you are misinterpreting the man page, because it isn't worded 
very clearly.  It should not even mention O_CREAT because it has nothing 
to do with O_EXCL; it is just repeating the semantics of O_CREAT ( if 
the file already exists, the call fails ) which would of course, apply 
if you do use O_CREAT in conjunction with any other flag including 
O_EXCL.  It does not say that you must use O_EXCL with O_CREAT.  The 
rest of the description talks about using lockfiles as an alternative to 
ensure exclusive access to the file on NFS where O_EXCL is broken.  The 
intent of O_EXCL is clearly to provide the caller with exclusive access 
to the file.

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

[Kyle Moffett]

On Feb 05, 2006, at 11:15, Phillip Susi wrote:
> Jan Engelhardt wrote:
>> I would say we all forgot to RTFM. Because O_EXCL does nothing  
>> *unless* O_CREAT is specified, which probably *is not* specified  
>> in cdrecord or hal. There is no reason to have hal or cdrecord  
>> create a device node - which you can't do with open() anyway.
>
> I think you are misinterpreting the man page, because it isn't  
> worded very clearly.  It should not even mention O_CREAT because it  
> has nothing to do with O_EXCL; it is just repeating the semantics  
> of O_CREAT ( if the file already exists, the call fails ) which  
> would of course, apply if you do use O_CREAT in conjunction with  
> any other flag including O_EXCL.  It does not say that you must use  
> O_EXCL with O_CREAT.  The rest of the description talks about using  
> lockfiles as an alternative to ensure exclusive access to the file  
> on NFS where O_EXCL is broken.  The intent of O_EXCL is clearly to  
> provide the caller with exclusive access to the file.

You don't have this right either.  The way open() works:

If you specify O_CREAT (and not O_EXCL), it will create the file if  
it does not exist, and open the existing file otherwise.

If you specify O_EXCL (and not O_CREAT), it is implementation defined  
what will happen (in the Linux case, this opens a block device for  
exclusive access).

If you specify O_CREAT|O_EXCL, it will atomically create the file if  
it does not exist, otherwise it will return the error -EEXIST.

Cheers,
Kyle Moffett

--
Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25.

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

[Jan Engelhardt]

>
> If you specify O_EXCL (and not O_CREAT), it is implementation defined what will
> happen (in the Linux case, this opens a block device for exclusive access).
>
And with plain files, I supose it's free-for-all, right? 'Cause that's what 
my testcase yielded. :/


Jan Engelhardt
-- 

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

[Neil Brown]

On Sunday February 5, mrmacman_g4@mac.com wrote:
> 
> If you specify O_EXCL (and not O_CREAT), it is implementation defined  
> what will happen (in the Linux case, this opens a block device for  
> exclusive access).

With Linux, O_EXCL on a block devices isn't *exactly* exclusive
access.
It only provided you exclusive access against other people who ask for
exclusive access, which includes in-kernel usage like mount, md, dm,
and swap.

So if you open a block device O_EXCL, it will fail if the block device
is already open O_EXCL or is mounted, or in use by the kernel in some
other way (including if a partition is open O_EXCL).  An if you
succeed in getting an O_EXCL open, then no-one else will be able to
get an O_EXCL open, or mount the filesystem etc.
Bit on open without O_EXCL will always succeed no matter whether
someone has it O_EXCL or not.

So it is a lot like an advisory exclusive lock on the whole block
device.

NeilBrown

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

[Krzysztof Halasa]

Neil Brown <neilb@suse.de> writes:

> Bit on open without O_EXCL will always succeed no matter whether
> someone has it O_EXCL or not.

Ok. That means hald has no use for it, but cdrecord and similar
programs could use it.
-- 
Krzysztof Halasa

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

[Jan Engelhardt]

>
>> Bit on open without O_EXCL will always succeed no matter whether
>> someone has it O_EXCL or not.
>
>Ok. That means hald has no use for it, but cdrecord and similar
>programs could use it.

But that again sounds like hald won't use O_EXCL, therefore could always be 
able to open the device and potentially send commands which interrupt cd 
writing.


Jan Engelhardt
-- 

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

[Krzysztof Halasa]

Jan Engelhardt <jengelh@linux01.gwdg.de> writes:

> But that again sounds like hald won't use O_EXCL, therefore could always be 
> able to open the device and potentially send commands which interrupt cd 
> writing.

Yep. Both need that. And I need some coffee to recover from
non-logical thinking.
-- 
Krzysztof Halasa

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

[Phillip Susi]

Out of curiosity, what commands does hal send the drive that can 
interrupt burning?  I've been reading the MMC-5 standard lately and it 
looks like while the drive is burning, attempts to send it other 
commands that would interfere with the burn are supposed to be failed 
with an error code indicating that a burn is in progress, and thus, 
avoid making a coaster. 

Krzysztof Halasa wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> writes:
>
>   
>> But that again sounds like hald won't use O_EXCL, therefore could always be 
>> able to open the device and potentially send commands which interrupt cd 
>> writing.
>>     
>
> Yep. Both need that. And I need some coffee to recover from
> non-logical thinking.
>   

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

[Jan Engelhardt]

>
> Out of curiosity, what commands does hal send the drive that can interrupt
> burning?  I've been reading the MMC-5 standard lately and it looks like while
> the drive is burning, attempts to send it other commands that would interfere
> with the burn are supposed to be failed with an error code indicating that a
> burn is in progress, and thus, avoid making a coaster. 
>
At least there needs to be a command that is not ignored to stop a burn.
Though, hald would not be /that/ evil.


Jan Engelhardt
-- 

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

[Phillip Susi]

Olivier Galibert wrote:
> Actually, since at that point in time HAL is the only way to do device
> discovery with the linux kernel, problems in HAL are problems in
> linux.  There is *no* other way than HAL to do the mapping between a
> point in the sysfs tree and a device node in /dev[1].

That information is available in /sys, which is how HAL discovers it.  
If you wanted to, you could bypass HAL and go directly to /sys to 
perform your own discovery.  Also HAL is not a part of the linux kernel, 
therefore a problem in HAL is NOT a problem in linux, even if there were 
no other way to get the information as you ( wrongly ) asserted. 

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

[Olivier Galibert]

On Fri, Feb 03, 2006 at 02:50:11PM -0500, Phillip Susi wrote:
> Olivier Galibert wrote:
> >Actually, since at that point in time HAL is the only way to do device
> >discovery with the linux kernel, problems in HAL are problems in
> >linux.  There is *no* other way than HAL to do the mapping between a
> >point in the sysfs tree and a device node in /dev[1].
> 
> That information is available in /sys, which is how HAL discovers it.  

No, it isn't.  OTOH, udev maintains it, so I guess that's good enough.
It makes udev the kernel interface though.  I hope they now care about
compatibility (/dev/.udev.pdb vs. /dev/.udev/db/* anyone?).


> If you wanted to, you could bypass HAL and go directly to /sys to 
> perform your own discovery.  Also HAL is not a part of the linux kernel, 
> therefore a problem in HAL is NOT a problem in linux, even if there were 
> no other way to get the information as you ( wrongly ) asserted. 

Bullshit.  If <x> is the only interface available to a kernel service,
then <x> is part of the kernel whether you like it or not.  Case in
point, the ALSA library.

  OG.

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

[Phillip Susi]

Olivier Galibert wrote:
> No, it isn't.  OTOH, udev maintains it, so I guess that's good enough.
> It makes udev the kernel interface though.  I hope they now care about
> compatibility (/dev/.udev.pdb vs. /dev/.udev/db/* anyone?).
> 

Yes, it is, where do you think udev gets it's information from?  That's 
right, from /sys.  Sysfs is the kernel interface, not udev; the 'u' in 
udev is for 'user', as in NOT part of the kernel.

>
> Bullshit.  If <x> is the only interface available to a kernel service,
> then <x> is part of the kernel whether you like it or not.  Case in
> point, the ALSA library.

Bullshit yourself.  If cdrecord is the only application for burning cds, 
that does not make it the kernel interface for cds, and certainly does 
not make it part of the kernel.  The kernel interface is the point of 
interaction between user and kernel code, which is sysfs.

Udev and HAL are two user mode ( NOT parts of the kernel ) components 
built to put the information from sysfs to use in user space, and other 
applications are encouraged to utilize the services those daemons 
provide.  By no stretch of the imagination does that make them part of 
the kernel.

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

[Olivier Galibert]

On Fri, Feb 03, 2006 at 04:06:13PM -0500, Phillip Susi wrote:
> Olivier Galibert wrote:
> >No, it isn't.  OTOH, udev maintains it, so I guess that's good enough.
> >It makes udev the kernel interface though.  I hope they now care about
> >compatibility (/dev/.udev.pdb vs. /dev/.udev/db/* anyone?).
> >
> 
> Yes, it is, where do you think udev gets it's information from?

The device node name?  From the rules in /etc/udev/rules.d/*.  Udev is
the one which creates it in the first place, deriving it in a
user-defined way from the sysfs information.  It does _not_ give back
that information to the kernel.  Maybe it should.


> >Bullshit.  If <x> is the only interface available to a kernel service,
> >then <x> is part of the kernel whether you like it or not.  Case in
> >point, the ALSA library.
> 
> Bullshit yourself.  If cdrecord is the only application for burning cds, 
> that does not make it the kernel interface for cds, and certainly does 
> not make it part of the kernel.  The kernel interface is the point of 
> interaction between user and kernel code, which is sysfs.

The kernel does not provide a cd burning service, only a scsi packet
transport service called SG_IO.

The kernel *does* provide a device enumeration service, only it does
it at this point through udev for reasons that are 50% technical and
50% political.  If you want to be able to use a 2.6 kernel with
hotplug devices udev[1] is mandatory.  As such, from an engineering
point of view, udev is part of the kernel even if it isn't in the
source tarball on kernel.org.  And for now it is the lowest level
interface to device enumeration.

  OG.

[1] Or hotplug, maybe.

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

[Phillip Susi]

Olivier Galibert wrote:
> The device node name?  From the rules in /etc/udev/rules.d/*.  Udev is
> the one which creates it in the first place, deriving it in a
> user-defined way from the sysfs information.  It does _not_ give back
> that information to the kernel.  Maybe it should.
>
>   
Ohh, I see what you are saying now.  Yes, it is up to udev to create the 
device nodes, and the kernel does not know or care about the nodes.  If 
an application wants to find existing nodes it can open it needs to 
query udev or hal.  If it wants to find out what devices the kernel 
exports, it can look in /sys and make its own devnode to access them. 

> The kernel does not provide a cd burning service, only a scsi packet
> transport service called SG_IO.
>
> The kernel *does* provide a device enumeration service, only it does
> it at this point through udev for reasons that are 50% technical and
>   
What part of the user/kernel separation don't you understand?  udev is 
user mode code which interfaces with the kernel via sysfs.  Other user 
mode code is free to do that as well, or just use udev.  Either way, the 
only kernel interface involved is sysfs.  The kernel does not know or 
care about udev or what it does,  only sysfs.  The kernel provides 
enumeration through sysfs, and that is all. 
> 50% political.  If you want to be able to use a 2.6 kernel with
> hotplug devices udev[1] is mandatory.  As such, from an engineering
> point of view, udev is part of the kernel even if it isn't in the
> source tarball on kernel.org.  And for now it is the lowest level
> interface to device enumeration.
>
>   

Your logic is flawed.  X + Y = Z does NOT mean that X ( linux ) and Y ( 
udev ) are one and the same even if Z ( a usable GNU/Linux system with 
hotplug support ) is desirable.  The kernel provides sysfs as it's 
interface, and udev and hal provide higher level interfaces.  In much 
the same way, the kernel frame buffer driver provides one interface, and 
Xorg provides higher level interface built on top of the kernel 
interface.  By no stretch of the imagination is Xorg the kernel 
interface to the video card, which is what you are arguing. 

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

[Phillip Susi]

Joerg Schilling wrote:
> As including O_EXCL would disallow to use more than one cdrecord
> program at the same time, there is no chance for the mains stream source.
>
>   

You CAN'T have multiple cdrecord processes burning the same disc at the 
same time; the very idea makes no sense.  The O_EXCL just prevents you 
from trying such foolishness and creating a coaster. 

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

[Joerg Schilling]

Phillip Susi <psusi@cfl.rr.com> wrote:

> You CAN'T have multiple cdrecord processes burning the same disc at the 
> same time; the very idea makes no sense.  The O_EXCL just prevents you 
> from trying such foolishness and creating a coaster. 

It does not prevent you from creatig a coaster in case you connect e.g.
two ATAPI writers to the same ATA cable.


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 CAN'T have multiple cdrecord processes burning the same disc at the 
>> same time; the very idea makes no sense.  The O_EXCL just prevents you 
>> from trying such foolishness and creating a coaster. 
>
>It does not prevent you from creatig a coaster in case you connect e.g.
>two ATAPI writers to the same ATA cable.
>
Apart from transfer speed issues and potential buffer underruns coming 
along with that, is there anything technically impossible with writing to 
two ATAPI drives at the same time?



Jan Engelhardt
-- 

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

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >
> >> You CAN'T have multiple cdrecord processes burning the same disc at the 
> >> same time; the very idea makes no sense.  The O_EXCL just prevents you 
> >> from trying such foolishness and creating a coaster. 
> >
> >It does not prevent you from creatig a coaster in case you connect e.g.
> >two ATAPI writers to the same ATA cable.
> >
> Apart from transfer speed issues and potential buffer underruns coming 
> along with that, is there anything technically impossible with writing to 
> two ATAPI drives at the same time?

It depends on what type of drive you use.

If you chose a drive that blocks the ATA cable while processing a 
START/STOP/UNIT, you are out of luck.

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]

>> >It does not prevent you from creatig a coaster in case you connect e.g.
>> >two ATAPI writers to the same ATA cable.
>> >
>> Apart from transfer speed issues and potential buffer underruns coming 
>> along with that, is there anything technically impossible with writing to 
>> two ATAPI drives at the same time?
>
>It depends on what type of drive you use.
>
>If you chose a drive that blocks the ATA cable while processing a 
>START/STOP/UNIT, you are out of luck.
>
That may be what I experienced with that aopen writer.



Jan Engelhardt
-- 

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

[Matthias Andree]

Jan Engelhardt schrieb am 2006-02-03:

> >
> >> You CAN'T have multiple cdrecord processes burning the same disc at the 
> >> same time; the very idea makes no sense.  The O_EXCL just prevents you 
> >> from trying such foolishness and creating a coaster. 
> >
> >It does not prevent you from creatig a coaster in case you connect e.g.
> >two ATAPI writers to the same ATA cable.
> >
> Apart from transfer speed issues and potential buffer underruns coming 
> along with that, is there anything technically impossible with writing to 
> two ATAPI drives at the same time?

Bus locking while waiting for command completion. If you start a
long-lasting operation on one device, the other device on the same cable
is blocked so you cannot feed the other.

Same holds for SCSI if one of the devices involved doesn't disconnect
from the bus for that long-lasting command.

Try for instance "eject /dev/hdc" while writing to /dev/hdd, or same
stuff with sr0 and sr1. Been there, done that, got a coaster.

-- 
Matthias Andree

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

[Phillip Susi]

Joerg Schilling wrote:
>> You CAN'T have multiple cdrecord processes burning the same disc at the 
>> same time; the very idea makes no sense.  The O_EXCL just prevents you 
>> from trying such foolishness and creating a coaster. 
>>     
>
> It does not prevent you from creatig a coaster in case you connect e.g.
> two ATAPI writers to the same ATA cable.

So what?  What does that have to do with my rebutting your statement 
that O_EXCL prevents multiple cdrecords?  O_EXCL also does not prevent 
you from kicking the plug out of the wall while burning, but it DOES 
prevent another process from trying to mess with the drive while 
cdrecord is and clobbering things up, which is a good thing.  It does 
not prevent you from using cdrecord at the same time on different drives. 

[cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-03:

> Albert Cahalan <acahalan@gmail.com> wrote:
> 
> > On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > > "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> > >
> > > > I see the same thing with, the only external kernel patch I have
> > > > applied is Suspend2. The ATA scanbus code tries to
> > > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> > >
> > > This is not cdrecord but a bastardized version......
> >
> > True enough, but it would work great if you'd fix that bug
> > that makes cdrecord give up while scanning. I guess
> > that's one more patch Debian will be applying.
> 
> As including O_EXCL would disallow to use more than one cdrecord
> program at the same time, there is no chance for the mains stream source.

Nobody suggested O_EXCL as a fix for the scanning bug.
It seems your capabilities to follow a complex discussion are generally
overtaxed a bit... sorry for overestimating you.

So patches to the rescue -- please review the patch below (for 2.01.01a05).
Note that GPL 2a and 2c apply, so you cannot merge a modified version of
my patch without adding a tag that you goofed my fixes.

If deemed safe, please apply and test. It appears to work for me
(as in: blanks and writes CD-RW when setuid root) on SUSE Linux 10.0
(kernel 2.6.13-15.7 i686 bigmem 4kstacks blah sülz) and it compiles
properly on FreeBSD 6-STABLE i686.

(Sorry for the off-topic bloat, but as we've had so many messages, a few
KB patching won't add much to the pain any more.)

And no, I am not going to read Solaris sources. Linux does not have to
care how Solaris works, but your Linux interface code has to work
properly on Linux and not put up artificial obstacles.

> Well the big difference with Solaris is that several modifications have been 
> applied by Sun to the vold sub-system on Solaris in order to decently 
> support cdrecord.

For the 100th time, you need to substantiate your bug claims or feature
requests with good reasons. "Somebody else is doing it." is not sufficient.

> The last change was done with Nevada Build 21 in August 2005.

Is this part of the Solaris 10 update shipped earlier this year?


Now for the patch diff, diffstat and comments first:

# cdrecord/cdrecord.c    |  114         2 +     105 -   7 !
# mkisofs/write.c        |    4         0 +     0 -     4 !
# libscg/scsi-linux-sg.c |   82         3 +     54 -    25 !
# 3 files changed, 5 insertions(+), 159 deletions(-), 36 modifications(!)

- The cdrecord patch removes bogus Linux warnings and
  adds the GPL 2a/2c guacamole.

- The write.c patch fixes trigraph, a patch Jörg keeps losing.

- The libscg patch removes bogus warnings, kills the ATA transport --
  this is an alpha version, not stable code (it can be autodetected by
  looking at the device name, I'm not sure if the LF_ATA is really
  useful nowaday), fixes the scanning bugs and unifies Linux SG_IO
  device namespaces.

Further observations:

- Jörg wants the kernel to add junk for device enumeration when removing
  artificial barriers from libscg does the same job?

  Now that's impressive after all his bold claims. I think Jens and a
  few other people deserve apologies.

- the code should glob /dev/sg* and probe everything and filter out
  dupes by looking at major/minor.

- linuxcheck() was broken and assuming fixed-format, the
  changed-interface warning disappeared with linux 2.6.10 ('1' < '8'),
  and is obsolete anyhow since 2.01.01a05. Nevermind the whining :-P

- Jörg makes a big fuss about duplicated code in Linux kernel, but this
  appears more of a "not in my back-yard" kind complaint... duplicated
  code in cdrecord anyone? Two screenful removed by the patch, help yourself.

How does this look (setuid root, the kernel appears to refuse the
obsolete "REZERO UNIT" which breaks f.i. cdrecord -toc)?

$ bins/i686-linux-cc/cdrecord -scanbus
Cdrecord-Clone 2.01.01a04 (i686-pc-linux-gnu) Copyright (C) 1995-2006 Joerg Schilling, 2006 Matthias Andree
NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord
      that removed some bogus whining of the original author. Although unlikely,
      it may have bugs that are not present in the original version.
      Please send bug reports and support requests to <matthias.andree@gmx.de>.
      The original author should not be bothered with problems of this version.

Linux sg driver version: 3.5.27
Using libscg version 'schily-0.8'.
bins/i686-linux-cc/cdrecord: Warning: using inofficial libscg transport code version (-scsi-linux-sg.c-1.86+ma '@(#)scsi-linux-sg.c     1.86 05/11/22 Copyright 1997 J. Schilling').
scsibus0:
        0,0,0     0) 'ATA     ' 'SAMSUNG SP2004C ' 'VM10' Disk
        0,1,0     1) *
        ...
scsibus1:
        1,0,0   100) '_NEC    ' 'DVD_RW ND-4550A ' '1.07' Removable CD-ROM
        1,1,0   101) 'PLEXTOR ' 'CD-R   PX-W4824A' '1.06' Removable CD-ROM
        1,2,0   102) *
        ...
scsibus2:
        2,0,0   200) *
        2,1,0   201) *
        2,2,0   202) 'PLEXTOR ' 'CD-ROM PX-32TS  ' '1.02' Removable CD-ROM
        2,3,0   203) *
        ...

0,0,0 is  /dev/sda /dev/sg0, driven by sd and sg (libata)
1,*,0 are /dev/hdc /dev/hdd, driven by ide-cd    (via82cxxx)
2,2,0 is  /dev/sr0 /dev/sg1, driven by sr and sg (sym53c8xx_2)


Sorry 'bout posting this as bloated context patch,
this is for Jörg-Schilling-compliance and perhaps Solaris 2.6 too.

*** ./cdrecord/cdrecord.c.orig	Sun Jan 29 19:52:03 2006
--- ./cdrecord/cdrecord.c	Fri Feb  3 17:17:08 2006
***************
*** 245,251 ****
  LOCAL	void	print_wrmodes	__PR((cdr_t *dp));
  LOCAL	BOOL	check_wrmode	__PR((cdr_t *dp, int wmode, int tflags));
  LOCAL	void	set_wrmode	__PR((cdr_t *dp, int wmode, int tflags));
- LOCAL	void	linuxcheck	__PR((void));
  
  struct exargs {
  	SCSI	*scgp;
--- 245,250 ----
***************
*** 352,368 ****
  #	define	CLONE_TITLE	""
  #endif
  	if ((flags & F_MSINFO) == 0 || lverbose || flags & F_VERSION) {
! 		printf("Cdrecord%s%s %s (%s-%s-%s) Copyright (C) 1995-2006 Jörg Schilling\n",
  								PRODVD_TITLE,
  								CLONE_TITLE,
  								cdr_version,
  								HOST_CPU, HOST_VENDOR, HOST_OS);
  
  #if	defined(SOURCE_MODIFIED) || !defined(IS_SCHILY_XCONFIG)
! #define	INSERT_YOUR_EMAIL_ADDRESS_HERE
  #define	NO_SUPPORT	0
  		printf("NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord\n");
! 		printf("      and thus may have bugs that are not present in the original version.\n");
  #if	NO_SUPPORT
  		printf("      The author of the modifications decided not to provide a support e-mail\n");
  		printf("      address so there is absolutely no support for this version.\n");
--- 351,370 ----
  #	define	CLONE_TITLE	""
  #endif
  	if ((flags & F_MSINFO) == 0 || lverbose || flags & F_VERSION) {
! 		printf("Cdrecord%s%s %s (%s-%s-%s) Copyright (C) 1995-2006 Joerg Schilling, 2006 Matthias Andree\n",
  								PRODVD_TITLE,
  								CLONE_TITLE,
  								cdr_version,
  								HOST_CPU, HOST_VENDOR, HOST_OS);
  
+ #define SOURCE_MODIFIED 1
+ 
  #if	defined(SOURCE_MODIFIED) || !defined(IS_SCHILY_XCONFIG)
! #define	INSERT_YOUR_EMAIL_ADDRESS_HERE "matthias.andree@gmx.de"
  #define	NO_SUPPORT	0
  		printf("NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord\n");
! 		printf("      that removed some bogus whining of the original author. Although unlikely,\n");
! 		printf("      it may have bugs that are not present in the original version.\n");
  #if	NO_SUPPORT
  		printf("      The author of the modifications decided not to provide a support e-mail\n");
  		printf("      address so there is absolutely no support for this version.\n");
***************
*** 380,410 ****
  #endif
  	}
  
- 	/*
- 	 * I am sorry that even for version 1.308 of cdrecord.c, I am forced to do
- 	 * things like this, but defective versions of cdrecord cause a lot of
- 	 * work load to me and it seems to be impossible to otherwise convince
- 	 * SuSE to cooperate.
- 	 * As people contact me and bother me with the related problems,
- 	 * it is obvious that SuSE is violating subsection 6 in the preamble of
- 	 * the GPL.
- 	 *
- 	 * The reason for including a test against SuSE's private
- 	 * distribution environment is only that SuSE violates the GPL for
- 	 * a long time and seems not to be willing to follow the requirements
- 	 * imposed by the GPL. If SuSE starts to ship non defective versions
- 	 * of cdrecord or informs their customers that they would need to
- 	 * compile cdrecord themselves in order to get a working cdrecord,
- 	 * they should contact me for a permission to change the related test.
- 	 *
- 	 * Note that although the SuSE test is effective only for SuSE, the
- 	 * intention to have non bastardized versions out is not limited
- 	 * to SuSE. It is bad to see that in special in the "Linux" business,
- 	 * companies prefer a model with many proprietary differing programs
- 	 * instead of cooperating with the program authors.
- 	 */
- 	linuxcheck();	/* For version 1.308 of cdrecord.c */
- 
  	if (flags & F_VERSION)
  		exit(0);
  	/*
--- 382,387 ----
***************
*** 4699,4780 ****
  	}
  	dsp->ds_wrmode = WM_NONE;
  }
- 
- /*
-  * I am sorry that even for version 1.308 of cdrecord.c, I am forced to do
-  * things like this, but defective versions of cdrecord cause a lot of
-  * work load to me and it seems to be impossible to otherwise convince
-  * SuSE to cooperate.
-  * As people contact me and bother me with the related problems,
-  * it is obvious that SuSE is violating subsection 6 in the preamble of
-  * the GPL.
-  *
-  * The reason for including a test against SuSE's private
-  * distribution environment is only that SuSE violates the GPL for
-  * a long time and seems not to be willing to follow the requirements
-  * imposed by the GPL. If SuSE starts to ship non defective versions
-  * of cdrecord or informs their customers that they would need to
-  * compile cdrecord themselves in order to get a working cdrecord,
-  * they should contact me for a permission to change the related test.
-  *
-  * Note that although the SuSE test is effective only for SuSE, the
-  * intention to have non bastardized versions out is not limited
-  * to SuSE. It is bad to see that in special in the "Linux" business,
-  * companies prefer a model with many proprietary differing programs
-  * instead of cooperating with the program authors.
-  */
- #if	defined(linux) || defined(__linux) || defined(__linux__)
- #ifdef	HAVE_UNAME
- #include <sys/utsname.h>
- #endif
- #endif
- 
- LOCAL void
- linuxcheck()				/* For version 1.308 of cdrecord.c */
- {
- #if	defined(linux) || defined(__linux) || defined(__linux__)
- #ifdef	HAVE_UNAME
- 	struct	utsname	un;
- 
- 	if (uname(&un) >= 0) {
- 		/*
- 		 * I really hope that the Linux kernel developers will soon
- 		 * fix the most annoying bugs (as promised). Linux-2.6.8
- 		 * has still much more reported problems than Linux-2.4.
- 		 */
- 		if ((un.release[0] == '2' && un.release[1] == '.') &&
- 		    (un.release[2] == '5' || un.release[2] == '6')) {
- 			errmsgno(EX_BAD,
- 			"Warning: Running on Linux-%s\n", un.release);
- 			errmsgno(EX_BAD,
- 			"There are unsettled issues with Linux-2.5 and newer.\n");
- 			errmsgno(EX_BAD,
- 			"If you have unexpected problems, please try Linux-2.4 or Solaris.\n");
- 		}
- 		if ((un.release[0] == '2' && un.release[1] == '.') &&
- 		    (un.release[2] > '6' ||
- 		    (un.release[2] == '6' && un.release[3] == '.' && un.release[4] >= '8'))) {
- 			errmsgno(EX_BAD,
- 			"Warning: Linux-2.6.8 introduced incompatible interface changes.\n");
- 			errmsgno(EX_BAD,
- 			"Warning: SCSI transport does no longer work for suid root programs.\n");
- 			errmsgno(EX_BAD,
- 			"Warning: if cdrecord fails, try to run it from a root account.\n");
- 		}
- 	}
- #endif
- #if	0
- 	if (streql(HOST_VENDOR, "suse")) { /* For version 1.308 of cdrecord.c */
- /* 1.308 */	errmsgno(EX_BAD,
- /* 1.308 */	"SuSE Linux is known to ship bastardized and defective versions of cdrecord.\n");
- /* 1.308 */	errmsgno(EX_BAD,
- /* 1.308 */	"SuSE is unwilling to cooperate with the authors.\n");
- /* 1.308 */	errmsgno(EX_BAD,
- /* 1.308 */	"If you like to have a working version of cdrtools, get the\n");
- /* 1.308 */	errmsgno(EX_BAD,
- /* 1.308 */	"original source from ftp://ftp.berlios.de/pub/cdrecord/\n");
- 
- 	}
- #endif
- #endif
- }
--- 4676,4678 ----
*** ./mkisofs/write.c.orig	Fri Feb  3 15:49:23 2006
--- ./mkisofs/write.c	Fri Feb  3 15:49:25 2006
***************
*** 834,843 ****
  	if (dcount < 2) {
  #ifdef	USE_LIBSCHILY
  		errmsgno(EX_BAD,
! 			"Directory size too small (. or .. missing ???)\n");
  #else
  		fprintf(stderr,
! 			"Directory size too small (. or .. missing ???)\n");
  #endif
  		sort_goof = 1;
  
--- 834,843 ----
  	if (dcount < 2) {
  #ifdef	USE_LIBSCHILY
  		errmsgno(EX_BAD,
! 			"Directory size too small (. or .. missing ??\077)\n");
  #else
  		fprintf(stderr,
! 			"Directory size too small (. or .. missing ??\077)\n");
  #endif
  		sort_goof = 1;
  
*** ./libscg/scsi-linux-sg.c.orig	Fri Feb  3 15:44:39 2006
--- ./libscg/scsi-linux-sg.c	Fri Feb  3 16:31:03 2006
***************
*** 120,126 ****
   *	Choose your name instead of "schily" and make clear that the version
   *	string is related to a modified source.
   */
! LOCAL	char	_scg_trans_version[] = "scsi-linux-sg.c-1.86";	/* The version for this transport*/
  
  #ifndef	SCSI_IOCTL_GET_BUS_NUMBER
  #define	SCSI_IOCTL_GET_BUS_NUMBER 0x5386
--- 120,126 ----
   *	Choose your name instead of "schily" and make clear that the version
   *	string is related to a modified source.
   */
! LOCAL	char	_scg_trans_version[] = "scsi-linux-sg.c-1.86+ma";	/* The version for this transport*/
  
  #ifndef	SCSI_IOCTL_GET_BUS_NUMBER
  #define	SCSI_IOCTL_GET_BUS_NUMBER 0x5386
***************
*** 273,279 ****
  		 * return "schily" for the SCG_AUTHOR request.
  		 */
  		case SCG_AUTHOR:
! 			return (_scg_auth_schily);
  		case SCG_SCCS_ID:
  			return (__sccsid);
  		case SCG_KVERSION:
--- 273,279 ----
  		 * return "schily" for the SCG_AUTHOR request.
  		 */
  		case SCG_AUTHOR:
! 			return ("");
  		case SCG_SCCS_ID:
  			return (__sccsid);
  		case SCG_KVERSION:
***************
*** 308,315 ****
  #ifdef	USE_ATA
  	scgo_ahelp(scgp, f);
  #endif
- 	__scg_help(f, "ATA", "ATA Packet specific SCSI transport using sg interface",
- 		"ATA:", "bus,target,lun", "1,2,0", TRUE, FALSE);
  	return (0);
  }
  
--- 308,313 ----
***************
*** 328,334 ****
  	register int	l;
  	register int	nopen = 0;
  	char		devname[64];
- 		BOOL	use_ata = FALSE;
  
  	if (busno >= MAX_SCG || tgt >= MAX_TGT || tlun >= MAX_LUN) {
  		errno = EINVAL;
--- 326,331 ----
***************
*** 338,381 ****
  				busno, tgt, tlun);
  		return (-1);
  	}
- 	if (device != NULL && *device != '\0') {
  #ifdef	USE_ATA
  		if (strncmp(device, "ATAPI", 5) == 0) {
  			scgp->ops = &ata_ops;
  			return (SCGO_OPEN(scgp, device));
  		}
- #endif
- 		if (strcmp(device, "ATA") == 0) {
- 			/*
- 			 * Sending generic SCSI commands via /dev/hd* is a
- 			 * really bad idea when there also is a generic
- 			 * SCSI driver interface - it breaks the protocol
- 			 * layering model. A better idea would be to
- 			 * have a SCSI host bus adapter driver that sends
- 			 * the SCSI commands via the ATA hardware. This way,
- 			 * the layering model would be honored.
- 			 *
- 			 * People like Jens Axboe should finally fix the DMA
- 			 * bugs in the ide-scsi hostadaptor emulation module
- 			 * from Linux instead of publishing childish patches
- 			 * to the comment above.
- 			 */
- 			use_ata = TRUE;
- 			device = NULL;
- 			if (scgp->overbose) {
- 				/*
- 				 * I strongly encourage people who believe that
- 				 * they need to patch this message away to read
- 				 * the messages in the Solaris USCSI libscg
- 				 * layer instead of wetting their tissues while
- 				 * being unwilling to look besides their
- 				 * own belly button.
- 				 */
- 				js_fprintf((FILE *)scgp->errfile,
- 				"Warning: Using badly designed ATAPI via /dev/hd* interface.\n");
- 			}
- 		}
  	}
  
  	if (scgp->local == NULL) {
  		scgp->local = malloc(sizeof (struct scg_local));
--- 335,348 ----
  				busno, tgt, tlun);
  		return (-1);
  	}
  #ifdef	USE_ATA
+ 	if (device != NULL && *device != '\0') {
  		if (strncmp(device, "ATAPI", 5) == 0) {
  			scgp->ops = &ata_ops;
  			return (SCGO_OPEN(scgp, device));
  		}
  	}
+ #endif
  
  	if (scgp->local == NULL) {
  		scgp->local = malloc(sizeof (struct scg_local));
***************
*** 389,396 ****
  		scglocal(scgp)->drvers = -1;
  		scglocal(scgp)->isold = -1;
  		scglocal(scgp)->flags = 0;
- 		if (use_ata)
- 			scglocal(scgp)->flags |= LF_ATA;
  		scglocal(scgp)->xbufsize = 0L;
  		scglocal(scgp)->xbuf = NULL;
  
--- 356,361 ----
***************
*** 403,415 ****
  		}
  	}
  
- 	if (use_ata)
- 		goto scanopen;
- 
  	if ((device != NULL && *device != '\0') || (busno == -2 && tgt == -2))
  		goto openbydev;
  
- scanopen:
  	/*
  	 * Note that it makes no sense to scan less than all /dev/hd* devices
  	 * as even /dev/hda may be a device that talks SCSI (e.g. a ATAPI
--- 368,376 ----
***************
*** 417,423 ****
  	 * look silly but there may be users that did boot from a SCSI hdd
  	 * and connected 4 CD/DVD writers to both IDE cables in the PC.
  	 */
! 	if (use_ata) for (i = 0; i <= 25; i++) {
  		js_snprintf(devname, sizeof (devname), "/dev/hd%c", i+'a');
  					/* O_NONBLOCK is dangerous */
  		f = open(devname, O_RDWR | O_NONBLOCK);
--- 378,384 ----
  	 * look silly but there may be users that did boot from a SCSI hdd
  	 * and connected 4 CD/DVD writers to both IDE cables in the PC.
  	 */
! 	for (i = 0; i <= 25; i++) {
  		js_snprintf(devname, sizeof (devname), "/dev/hd%c", i+'a');
  					/* O_NONBLOCK is dangerous */
  		f = open(devname, O_RDWR | O_NONBLOCK);
***************
*** 433,439 ****
  				if (scgp->errstr)
  					js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE,
  							"Cannot open '%s'", devname);
! 				return (0);
  			}
  		} else {
  			int	iparm;
--- 394,400 ----
  				if (scgp->errstr)
  					js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE,
  							"Cannot open '%s'", devname);
! 				continue;
  			}
  		} else {
  			int	iparm;
***************
*** 446,463 ****
  				continue;
  			}
  			sg_clearnblock(f);	/* Be very proper about this */
  			if (sg_setup(scgp, f, busno, tgt, tlun, i))
  				return (++nopen);
  			if (busno < 0 && tgt < 0 && tlun < 0)
  				nopen++;
  		}
  	}
! 	if (use_ata && nopen == 0)
! 		return (0);
  	if (nopen > 0 && scgp->errstr)
  		scgp->errstr[0] = '\0';
  
! 	if (nopen == 0) for (i = 0; i < 32; i++) {
  		js_snprintf(devname, sizeof (devname), "/dev/sg%d", i);
  					/* O_NONBLOCK is dangerous */
  		f = open(devname, O_RDWR | O_NONBLOCK);
--- 407,424 ----
  				continue;
  			}
  			sg_clearnblock(f);	/* Be very proper about this */
+ 			scglocal(scgp)->flags |= LF_ATA;
  			if (sg_setup(scgp, f, busno, tgt, tlun, i))
  				return (++nopen);
  			if (busno < 0 && tgt < 0 && tlun < 0)
  				nopen++;
  		}
  	}
! 
  	if (nopen > 0 && scgp->errstr)
  		scgp->errstr[0] = '\0';
  
! 	for (i = 0; i < 32; i++) {
  		js_snprintf(devname, sizeof (devname), "/dev/sg%d", i);
  					/* O_NONBLOCK is dangerous */
  		f = open(devname, O_RDWR | O_NONBLOCK);
***************
*** 473,479 ****
  				if (scgp->errstr)
  					js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE,
  							"Cannot open '%s'", devname);
! 				return (0);
  			}
  		} else {
  			sg_clearnblock(f);	/* Be very proper about this */
--- 434,440 ----
  				if (scgp->errstr)
  					js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE,
  							"Cannot open '%s'", devname);
! 				continue;
  			}
  		} else {
  			sg_clearnblock(f);	/* Be very proper about this */
***************
*** 502,508 ****
  				if (scgp->errstr)
  					js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE,
  							"Cannot open '%s'", devname);
! 				return (0);
  			}
  		} else {
  			sg_clearnblock(f);	/* Be very proper about this */
--- 463,469 ----
  				if (scgp->errstr)
  					js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE,
  							"Cannot open '%s'", devname);
! 				continue;
  			}
  		} else {
  			sg_clearnblock(f);	/* Be very proper about this */
***************
*** 523,541 ****
  			if (b < 0 || b > 25)
  				b = -1;
  		}
- 		if (scgp->overbose) {
- 			/*
- 			 * Before you patch this away, are you sure that you
- 			 * know what you are going to to?
- 			 *
- 			 * Note that this is a warning that helps users from
- 			 * cdda2wav, mkisofs and other programs (that
- 			 * distinguish SCSI addresses from file names) from
- 			 * getting unexpected results.
- 			 */
- 			js_fprintf((FILE *)scgp->errfile,
- 			"Warning: Open by 'devname' is unintentional and not supported.\n");
- 		}
  					/* O_NONBLOCK is dangerous */
  		f = open(device, O_RDWR | O_NONBLOCK);
  /*		if (f < 0 && errno == ENOENT)*/
--- 484,489 ----
***************
*** 634,645 ****
  }
  
  /*
!  * The Linux kernel becomes more and more unmaintainable.
!  * Every year, a new incompatible SCSI transport interface is added.
!  * Each of them has it's own contradictory constraints.
!  * While you cannot have O_NONBLOCK set during operation, at least one
!  * of the drivers requires O_NONBLOCK to be set during open().
!  * This is used to clear O_NONBLOCK immediately after open() succeeded.
   */
  LOCAL void
  sg_clearnblock(f)
--- 582,588 ----
  }
  
  /*
!  * This is used to clear O_NONBLOCK immediately after open() succeeded.
   */
  LOCAL void
  sg_clearnblock(f)

-- 
Matthias Andree

"Il semble que la perfection soit atteinte non quand il n'y a plus rien à
ajouter, mais quand il n'y a plus rien à retrancher." A. de Saint-Exupéry

Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> So patches to the rescue -- please review the patch below (for 2.01.01a05).
> Note that GPL 2a and 2c apply, so you cannot merge a modified version of
> my patch without adding a tag that you goofed my fixes.

OK, I did not look at it and I never will!

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: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Jim Crilly]

On 02/03/06 07:31:58PM +0100, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > So patches to the rescue -- please review the patch below (for 2.01.01a05).
> > Note that GPL 2a and 2c apply, so you cannot merge a modified version of
> > my patch without adding a tag that you goofed my fixes.
> 
> OK, I did not look at it and I never will!
> 
> Jörg

This is an excellent example to verify how bad cdrecord developent
is done.....

Jim.

Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> On 02/03/06 07:31:58PM +0100, Joerg Schilling wrote:
> > Matthias Andree <matthias.andree@gmx.de> wrote:
> > 
> > > So patches to the rescue -- please review the patch below (for 2.01.01a05).
> > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of
> > > my patch without adding a tag that you goofed my fixes.
> > 
> > OK, I did not look at it and I never will!
> > 
> > Jörg
>
> This is an excellent example to verify how bad cdrecord developent
> is done.....

Well,

cdrecord is done as good as possible. 

Note that if peope send a patch together with personal infringements or 
untrue claims, the best I can do is to ignore alltogether.

I did spend a lot of time with a fruitful discussion with Matthias.
Then Matthias started this thread.... It now seems like Matthias 
does not like to be serious anymore.

I am of course interested to make cdrecord better, but for the price
of spending an ridiculously amount of time ob LKML.

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: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Jim Crilly]

On 02/03/06 08:10:13PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > On 02/03/06 07:31:58PM +0100, Joerg Schilling wrote:
> > > Matthias Andree <matthias.andree@gmx.de> wrote:
> > > 
> > > > So patches to the rescue -- please review the patch below (for 2.01.01a05).
> > > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of
> > > > my patch without adding a tag that you goofed my fixes.
> > > 
> > > OK, I did not look at it and I never will!
> > > 
> > > Jörg
> >
> > This is an excellent example to verify how bad cdrecord developent
> > is done.....
> 
> Well,
> 
> cdrecord is done as good as possible. 

The fact that you seem to sling mud at everyone that doesn't agree
with you makes that seem questionable.

> Note that if peope send a patch together with personal infringements or 
> untrue claims, the best I can do is to ignore alltogether.
> 
> I did spend a lot of time with a fruitful discussion with Matthias.
> Then Matthias started this thread.... It now seems like Matthias 
> does not like to be serious anymore.

It's hard to have a serious discussion with you because you just keep
parotting the same things and pointing fingers over and over.

> I am of course interested to make cdrecord better, but for the price
> of spending an ridiculously amount of time ob LKML.
> 
> Jörg
> 

And you never did answer my question about why cdrecord is the only app on any
OS to use devicename:scsibus,target,lun to specify the target device. Every
other tool out there, e.g. mount, fsck, tar, etc, all use the device name
exported by the OS, e.g. /dev/c0t0s0d0, /dev/hda1, /dev/nst0, etc, so why
is it necessary for cdrecord to be different?

Jim.

Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-03:

> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > On 02/03/06 07:31:58PM +0100, Joerg Schilling wrote:
> > > Matthias Andree <matthias.andree@gmx.de> wrote:
> > > 
> > > > So patches to the rescue -- please review the patch below (for 2.01.01a05).
> > > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of
> > > > my patch without adding a tag that you goofed my fixes.
> > > 
> > > OK, I did not look at it and I never will!
> > > 
> > > Jörg
> >
> > This is an excellent example to verify how bad cdrecord developent
> > is done.....
> 
> Well,
> 
> cdrecord is done as good as possible. 

Untrue. Proof: My patch makes it operate more smoothly on Linux.

> Note that if peope send a patch together with personal infringements or 
> untrue claims, the best I can do is to ignore alltogether.

Look who's talking, and what. Personal infringements? If you're
sensitive, my apologies, I didn't mean to insult you.

> I did spend a lot of time with a fruitful discussion with Matthias.
> Then Matthias started this thread.... It now seems like Matthias 
> does not like to be serious anymore.

I am absolutely serious about the patch and about my recent findings
after looking at libscg.

I just don't want my name tainted with accidents that happen during
integration because you don't have a recent Linux installation. The
RLIMIT_MEMLOCK was enough of an effort, my first patch would've worked,
too, hence the GPL.

> I am of course interested to make cdrecord better, but for the price
> of spending an ridiculously amount of time ob LKML.

Well, if you'd listened and attempted to understand our scanning
concerns, you'd probably have had libscg use a unified ATA:/SCSI:
namespace in Linux for 1½ years. OK, spilled milk.

-- 
Matthias Andree

Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Pavel Machek]

Hi!

> > > > > So patches to the rescue -- please review the patch below (for 2.01.01a05).
> > > > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of
> > > > > my patch without adding a tag that you goofed my fixes.
> > > > 
> > > > OK, I did not look at it and I never will!
> > > > 
> > > > Jörg
> > >
> > > This is an excellent example to verify how bad cdrecord developent
> > > is done.....
> > 
> > Well,
> > 
> > cdrecord is done as good as possible. 
> 
> Untrue. Proof: My patch makes it operate more smoothly on Linux.
...
> I just don't want my name tainted with accidents that happen during
> integration because you don't have a recent Linux installation. The
> RLIMIT_MEMLOCK was enough of an effort, my first patch would've worked,
> too, hence the GPL.

Well, mailing patch with notice that it is not okay to modify it is
strange behaviour, and if I was Joerg, I'd just drop that patch, too.

If you really want the patch applied, submit it anonymously or
something like that.

							Pavel
-- 
Thanks, Sharp!

Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[jerome lacoste]

On 2/8/06, Pavel Machek <pavel@ucw.cz> wrote:
[...]
> > I just don't want my name tainted with accidents that happen during
> > integration because you don't have a recent Linux installation. The
> > RLIMIT_MEMLOCK was enough of an effort, my first patch would've worked,
> > too, hence the GPL.
>
> Well, mailing patch with notice that it is not okay to modify it is
> strange behaviour, and if I was Joerg, I'd just drop that patch, too.

That would be true except if Joerg hadn't started with the exact same
behavior. It would seem that Joerg would be capable of understanding
the irony there.

But maybe if Joerg would move his pride out of the way for 30 seconds,
have a decent look at the patch, return a technical commentary (or
point to an existing one), we could move on. I am sure that Matthias
would be pretty happy to return a better patch. That would make
everybody happy.

Matthias, can you resend the patch, without your notice? Let's see if
Joerg look at it this time.

> If you really want the patch applied, submit it anonymously or
> something like that.

Anonymous submission is not good for tracability reasons...

Jerome

Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

On Wed, 08 Feb 2006, Pavel Machek wrote:

> > I just don't want my name tainted with accidents that happen during
> > integration because you don't have a recent Linux installation. The
> > RLIMIT_MEMLOCK was enough of an effort, my first patch would've worked,
> > too, hence the GPL.
> 
> Well, mailing patch with notice that it is not okay to modify it is
> strange behaviour, and if I was Joerg, I'd just drop that patch, too.

You have apparently missed that I offered to relicense the patch under
MIT license (which is liberal, allows modifications and everything)
after I'd confirmed the integration went OK; and I was just returning
the buck of being forced to change interface identifications all over
the map from "mustn't modify" sections.

The first step would be to look at the patch nonetheless, because it
conveys information that Jörg has not extracted from messages since the
first time SG_IO in ide-cd cropped up.

-- 
Matthias Andree

Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> You have apparently missed that I offered to relicense the patch under
> MIT license (which is liberal, allows modifications and everything)

It seems that you still miss the point that you don't have the right
to require a license for your patch (check the UrhG for more information).

And please finally note that you did already cause a mail thread that
did cost more time than your patch is worth.

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: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[jerome lacoste]

On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
[...]
> And please finally note that you did already cause a mail thread that
> did cost more time than your patch is worth.

How can you know that if you didn't look at it?

J

Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-10:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > You have apparently missed that I offered to relicense the patch under
> > MIT license (which is liberal, allows modifications and everything)
> 
> It seems that you still miss the point that you don't have the right
> to require a license for your patch (check the UrhG for more information).

Why do care then?

> And please finally note that you did already cause a mail thread that
> did cost more time than your patch is worth.

Nobody forces you to answer every side note someone makes, and nobody
ask you to reiterate identical replies over and over.

-- 
Matthias Andree

Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-03:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > So patches to the rescue -- please review the patch below (for 2.01.01a05).
> > Note that GPL 2a and 2c apply, so you cannot merge a modified version of
> > my patch without adding a tag that you goofed my fixes.
> 
> OK, I did not look at it and I never will!

Perhaps you should -- the patch impairs your changes to get
needless device enumeration changes into the kernel...

Enforcing your strict interpretation of GPL v2 §§ 2a, 2c to the letter
was your own idea. I had to touch "modification prohibited" sections to
remove obsolete (bogus) warnings.

I'll amend the license: Show me your integrated patch. If it works
properly on my computer and without false warnings, you add a note to
the changelog and the AN-2.01.01a06 file, I will demote the patch's
license to the MIT license as in
<http://opensource.org/licenses/mit-license.php>. Yes, this is a license
contract offer as per the BGB. Just write you're accepting it, or accept
implicitly by sending the integration patch against 2.01.01a05.

I just want to make sure that it doesn't bear my name if the integration
breaks it again.

The code can probably be simplified even more with readdir() on /dev and
filtering it (avoiding glob() buffer issues), my patch doesn't even
attempt to do that.

And if you explain the use of LF_ATA, the kernel drivers might even be
fixes so that /dev/hd* looks confusably similar to /dev/sg*.

-- 
Matthias Andree

Re: [cdrtools PATCH (GPL)] 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-03:
>
> > Matthias Andree <matthias.andree@gmx.de> wrote:
> > 
> > > So patches to the rescue -- please review the patch below (for 2.01.01a05).
> > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of
> > > my patch without adding a tag that you goofed my fixes.
> > 
> > OK, I did not look at it and I never will!
>
> Perhaps you should -- the patch impairs your changes to get
> needless device enumeration changes into the kernel...

Well, the problem with your last mail is that it is full of idioligy.

I am of course willing to discuss useful ideas, but believe me that you
will have no luck if you leave a technical based discussion.


> I'll amend the license: Show me your integrated patch. If it works
> properly on my computer and without false warnings, you add a note to
> the changelog and the AN-2.01.01a06 file, I will demote the patch's
> license to the MIT license as in

See: http://bundesrecht.juris.de/urhg/

I hope this helps you to understand things better.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: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-03:

> Well, the problem with your last mail is that it is full of idioligy.

It is not my patch's or the discussion's fault if you cannot accept the
same rules as you are trying to impose on others.

> I am of course willing to discuss useful ideas, but believe me that you
> will have no luck if you leave a technical based discussion.

Then have a look at the patch, we'll discuss the license later.
My offer to relicense under MIT license if the integration works out for
me stands.

-- 
Matthias Andree

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

[Lee Revell]

On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> Apparently O_EXCL was added by Ubuntu and Debian to stop
> burns being corrupted by hald polling the device while a disc is
> being burned. 

IO priorities are the correct solution...

Lee

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

[Jim Crilly]

On 02/02/06 04:25:50PM -0500, Lee Revell wrote:
> On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> > Apparently O_EXCL was added by Ubuntu and Debian to stop
> > burns being corrupted by hald polling the device while a disc is
> > being burned. 
> 
> IO priorities are the correct solution...
> 
> Lee

Is this something that's available now?

Jim.

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

[Lee Revell]

On Thu, 2006-02-02 at 16:49 -0500, Jim Crilly wrote:
> On 02/02/06 04:25:50PM -0500, Lee Revell wrote:
> > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> > > Apparently O_EXCL was added by Ubuntu and Debian to stop
> > > burns being corrupted by hald polling the device while a disc is
> > > being burned. 
> > 
> > IO priorities are the correct solution...
> > 
> > Lee
> 
> Is this something that's available now?
> 

Yes but only in the CFQ IO scheduler, and a pre-release util-linux is
required to get the docs and command line utils.

Lee

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

[Lee Revell]

On Thu, 2006-02-02 at 16:49 -0500, Jim Crilly wrote:
> On 02/02/06 04:25:50PM -0500, Lee Revell wrote:
> > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> > > Apparently O_EXCL was added by Ubuntu and Debian to stop
> > > burns being corrupted by hald polling the device while a disc is
> > > being burned. 
> > 
> > IO priorities are the correct solution...
> > 
> > Lee
> 
> Is this something that's available now?
> 

Hmm, actually I'm not sure it would make a difference, as I don't think
CD writing goes through the regular IO scheduler.

Lee

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

[Jens Axboe]

On Thu, Feb 02 2006, Lee Revell wrote:
> On Thu, 2006-02-02 at 16:49 -0500, Jim Crilly wrote:
> > On 02/02/06 04:25:50PM -0500, Lee Revell wrote:
> > > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> > > > Apparently O_EXCL was added by Ubuntu and Debian to stop
> > > > burns being corrupted by hald polling the device while a disc is
> > > > being burned. 
> > > 
> > > IO priorities are the correct solution...
> > > 
> > > Lee
> > 
> > Is this something that's available now?
> > 
> 
> Hmm, actually I'm not sure it would make a difference, as I don't think
> CD writing goes through the regular IO scheduler.

Right, you can only prioritize "regular" io, not stuff sent with SG_IO.
So it'll help burning only for the case of getting the data required to
the buffer, not in getting that data out to the burner. The latter is
usually not a problem though, as these requests take a 'short cut'
directly to the dispatch queue.

-- 
Jens Axboe

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

[Joerg Schilling]

Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> > Apparently O_EXCL was added by Ubuntu and Debian to stop
> > burns being corrupted by hald polling the device while a disc is
> > being burned. 
>
> IO priorities are the correct solution...

No, they are not. 

The correct solution is to implement "hald" in a _cooperative_ way 
like e.g. vold on Solaris.

The main point is not to poll to frequent (Solaris does once everz 3 seconds)
and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing.

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]

>
>The main point is not to poll to frequent (Solaris does once everz 3 seconds)
>and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing.
>

I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although 
hal [seems to] probes more often than once/3sec, it did not interrupt any 
of my cd writing processes. Maybe that's already a feature of cdrecord*, I 
don't know.
(With an older drive (AOpen CRW1232), the whole IDE bus was even 
blocked when blanking, leaving no option but to wait.)


Jan Engelhardt
-- 

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

[Kay Sievers]

On Fri, Feb 03, 2006 at 02:51:10PM +0100, Jan Engelhardt wrote:
> >
> >The main point is not to poll to frequent (Solaris does once everz 3 seconds)
> >and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing.
> >
> 
> I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although 
> hal [seems to] probes more often than once/3sec,

It polls every 2 seconds.

> it did not interrupt any 
> of my cd writing processes. Maybe that's already a feature of cdrecord*, I 
> don't know.

I don't know of any problem in that area and almost every modern Linux
desktop has HAL running these days, so I'm sure somebody would have
complained.

Kay

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

[Joerg Schilling]

Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Fri, Feb 03, 2006 at 02:51:10PM +0100, Jan Engelhardt wrote:
> > >
> > >The main point is not to poll to frequent (Solaris does once everz 3 seconds)
> > >and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing.
> > >
> > 
> > I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although 
> > hal [seems to] probes more often than once/3sec,
>
> It polls every 2 seconds.

What SCSI commands does it use?

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]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >
> >The main point is not to poll to frequent (Solaris does once everz 3 seconds)
> >and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing.
> >
>
> I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although 
> hal [seems to] probes more often than once/3sec, it did not interrupt any 
> of my cd writing processes. Maybe that's already a feature of cdrecord*, I 
> don't know.
> (With an older drive (AOpen CRW1232), the whole IDE bus was even 
> blocked when blanking, leaving no option but to wait.)

If you like to investigate on this, you would need to e.g. use cdrecord to 
write a DVD on a Pioneer DVD writer of check a notebook with only one ATA cable 
for both HDD and DVD-writer.

The fact that it does work for you does not prove that there is no 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)

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> I see the same thing with, the only external kernel patch I have
> applied is Suspend2. The ATA scanbus code tries to 
> open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> the scanning code stops once one device fails to open the whole scan
> aborts. Apparently O_EXCL was added by Ubuntu and Debian to stop
> burns being corrupted by hald polling the device while a disc is
> being burned. If you want to read the entire thread it's bug #262678
> in Debian.

This is an excellent example to verify how bad Linux distribution developent
is done.....

Note that the main problem here is an applicaion unfriendly service 
on Linux that disturbes other applications like cdrecord.

As there is a bug in this service, I would expect that this bug should be fixed.
Instead of doing this or at least trying to get help from experienced people 
like me, some people did prefer to change cdrecord in a way that caused more
problems than it pretends to fix.

Note that the "requirement" for O_EXCL is a bad idea and needs fixing.
If you believe that this is impossible, just have a look at the OpenSolaris vold
and volfs subsystem.....

Note that Linux distributors apply other changes to cdrecord that causes 
problems in the same area: patching cdrecord to allow a grace time < 3 seconds
of course disallows a useful solution in this area.

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

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

[Jan Engelhardt]

>> Users like to be able to get a list of posible targets for a single protocol.
>> Nobody would ever think about trying to prevent people from getting a unified
>> view on the list possible hosts that talk TCP/IP. What cdrecord does with
>> -scanbus is nothing really different. 
>
>Well, please show me how to get the list of all possible hosts that talk
>TCP/IP and are directly or indirectly connected to my computer. As my
>computer is attached to the internet, the list would get pretty long...
>And even if only considering hosts in the local network, how do you get
>a unified view of all TCP/IP hosts conected to any of my two network
>adapters?
>
For direct connections (0 hop inbetween), spew pings around the local network,
look into the ARP table and try to TCP-connect to everyone listed.


Jan Engelhardt
-- 

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

[Paul Jakma]

On Tue, 31 Jan 2006, Joerg Schilling wrote:

> What Linux does is to artificially prevent this view to been seen 
> from outside the Linux kernel, or to avoid integrating a particular 
> device into a unique SCSI driver system although it would be 
> apropriate.

So let's get this straight: Linux is artificially limiting userspace 
from viewing devices in terms of parallel SCSI address (B/T/L) 
because it does not create such B/T/L addresses, ones which would 
hence be *artificial* themselves, for non-parallel-SCSI devices?

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
zeal, n.:
 	Quality seen in new graduates -- if you're quick.

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

[Albert Cahalan]

On 1/31/06, Paul Jakma <paul@clubi.ie> wrote:
> On Tue, 31 Jan 2006, Joerg Schilling wrote:
>
> > What Linux does is to artificially prevent this view to been seen
> > from outside the Linux kernel, or to avoid integrating a particular
> > device into a unique SCSI driver system although it would be
> > apropriate.
>
> So let's get this straight: Linux is artificially limiting userspace
> from viewing devices in terms of parallel SCSI address (B/T/L)
> because it does not create such B/T/L addresses, ones which would
> hence be *artificial* themselves, for non-parallel-SCSI devices?

There is a slim chance that Joerg might really believe that
Linux has an internal B/T/L view of everything. That would
be odd to us of course. He has clearly been spending time
with the Solaris kernel. If his only kernel experience comes
from systems that do make up a phony B/T/L view, then he might
just assume that all operating systems are designed this way.

For Joerg's reference, open() goes like this:

1. the /dev name
2. the inode
3. the device number
4. pointers to structs full of function pointers

Nowhere is it in B/T/L form.

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

[Paul Jakma]

On Wed, 1 Feb 2006, Albert Cahalan wrote:

> For Joerg's reference, open() goes like this:
>
> 1. the /dev name
> 2. the inode
> 3. the device number
> 4. pointers to structs full of function pointers
>
> Nowhere is it in B/T/L form.

And, for whatever it's worth, TTBOMK Solaris does not arrange SCSI 
into a B/T/L address hierarchy internally either.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Mystics always hope that science will some day overtake them.
 		-- Booth Tarkington

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

[Bill Davidsen]

> Cdrecord is a program that needs to be able to send any SCSI command as 
> it needs to be able to add new vendor unique commands for new drive/feature
> support.

On this we do agree, drive vendors seem to add every new feature with a 
vendor code. Some are NOT required to write CD, but some are needed to 
write "better" CDs, for some definition of better which could mean 
faster, more reliable, special modes, etc.

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

James Courtier-Dutton <James@superbug.co.uk> wrote:

> Would you be able to add the appropriate kernel bugzilla numbers?

As before people from LKML did not like to even talk about these bugs, 
I did stop after sending bug reports to LKML.

> I think it might also be useful to make a list of all the SCSI commands 
> that cdrecord uses. Including all the vendor specific ones. One could 
> then verify that the Linux kernel is passing them onto the device correctly.


It is simple to find the SCSI commands that cdrecord by scanning the source (*),
but this is something that is subject to frequent change in case cdrecord needs
to add new MMC-4711 commands or in case that I need to add a new vendor unique
command in order to support special features.


*) Just grep for "cdb.cmd"


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)

[Albert Cahalan]

On 1/25/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Albert Cahalan <acahalan@gmail.com> wrote:

> > BTW, before Joerg mentions portability, I'd like to remind
> > everyone that all modern OSes support the use of normal device
> > names for SCSI. The most awkward is FreeBSD, where you have
> > to do a syscall or two to translate the name to Joerg's very
> > non-hotplug non-iSCSI way of thinking. Windows, MacOS X, and
> > even Solaris all manage to handle device names just fine. In
> > numerous cases, not just Linux, cdrecord is inventing crap out
> > of thin air to satisfy a pre-hotplug worldview.
>
> Looks like you are badly informed, so I encourage you to get yourself informed
> properly before sending your next postig....
>
> libscg includes 22 different SCSI low level transport implementations.
>
> -       Only 5 of them allow a /dev/hd* device name related access.
>
> -       11 of them use file descriptors as handles for sending SCSI
>         commands but do not have a name <-> fs relation and thus
>         _need_ a SCSI device naming scheme as libscg offers.
>         This is because there is no 1:1 relation between SCSI addressing
>         and a fd retrieved from a /dev/* entry.
>
> -       6 of them not even allow to get a file descriptors as handles for
>         sending SCSI commands. These platforms of course need the SCSI device
>         naming scheme as libscg offers.
>
> Conclusion:
>
> 17 Platforms _need_ the addressing scheme libscg offers
>
> 5  Platforms _may_ use a different access method too.
>
> NOTE: Amongst the 6 plaforms that do not allow to even get a file descriptor
> there is a modern OS like MacOS X

You can't fool me, because I looked at the cdrecord source
code and at the documented APIs for various OSes.

It's misleading to say that MacOS doesn't allow a file
descriptor. MacOS has something similar to what Linux
has, but not in the normal filesystem namespace. You
specify a name to get a handle. Of course, on MacOS,
Joerg also uses -scanbus to create nonsense.

Names can be handled by Windows, FreeBSD, MacOS X,
Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX.
That's everything that isn't end-of-lifed.

The rest of your 22 platforms are dead and dying things
that are unlikely to be upgrading to the latest software or
hardware, assuming they survived the Y2K bug. It's old
stuff like the Amiga, the NeXT, etc.

Using numbers for CD burners is like trying to send email
to the IP address of the recipient, which half-way worked
until DHCP was invented. Wait, we could have all email
clients offer a -scannet option. :-)

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

[Matthias Andree]

On Wed, 25 Jan 2006, Albert Cahalan wrote:

> It's misleading to say that MacOS doesn't allow a file
> descriptor. MacOS has something similar to what Linux
> has, but not in the normal filesystem namespace. You
> specify a name to get a handle. Of course, on MacOS,
> Joerg also uses -scanbus to create nonsense.

OK, so Jörg created this "nonsense", i. e. a triple of stupid numbers,
and claims he's using them to provide device lists to applications.

What prevents any of these GUIs from treating the "name" as an opaque
string? How would ATA:4,0,0 be different from 2,2,0 or /dev/hdc?

And how is the phantom GUI application obtaining the data? It needs to
scan all buses anyhow, and run -scanbus for each and every "transport
identifier" to get a grip of all devices, because cdrecord-with-libscg
is too stupid to do that by itself and unlist inferior (in its view, or
in the public view) identifiers (such as the PIO-only ATAPI:).

Here's an idea:

recognizing cdrecord may be portable, I wonder if it (or libscg for that
matter) is extensible or made decisions where it can decouple its
devices from the GUI application. Stating that the device ID no matter
how it looks today would be an opaque string not to be processed by the
GUI might be a first step to gain the necessary degrees of freedom to
change to ATA:/dev/hdc or just /dev/hdc (I don't mind which).

> Using numbers for CD burners is like trying to send email
> to the IP address of the recipient, which half-way worked
> until DHCP was invented. Wait, we could have all email
> clients offer a -scannet option. :-)

Well, in PeeCees, the BIOS presents that list of primary/secondary
master/slave, so there's /some/ point in it. Once hotplug comes into
play, it's all vain though.

(removing Lee from the Cc: list)

-- 
Matthias Andree

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

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> On Wed, 25 Jan 2006, Albert Cahalan wrote:
>
> > It's misleading to say that MacOS doesn't allow a file
> > descriptor. MacOS has something similar to what Linux
> > has, but not in the normal filesystem namespace. You
> > specify a name to get a handle. Of course, on MacOS,
> > Joerg also uses -scanbus to create nonsense.
>
> OK, so Jörg created this "nonsense", i. e. a triple of stupid numbers,
> and claims he's using them to provide device lists to applications.

More than 2/3 of all current OS use this way of adressing and it is 
a standard: (CAM).

> Well, in PeeCees, the BIOS presents that list of primary/secondary
> master/slave, so there's /some/ point in it. Once hotplug comes into
> play, it's all vain though.

Hotplug is only a problem when implemented in a sub-optimal way.
Please have a look at Solaris for hot plug support with stable interface 
names.... 

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]

Albert Cahalan <acahalan@gmail.com> wrote:

> > Conclusion:
> >
> > 17 Platforms _need_ the addressing scheme libscg offers
> >
> > 5  Platforms _may_ use a different access method too.
> >
> > NOTE: Amongst the 6 plaforms that do not allow to even get a file descriptor
> > there is a modern OS like MacOS X
>
> You can't fool me, because I looked at the cdrecord source
> code and at the documented APIs for various OSes.

I am sorry to see that you did not look close enough...


> It's misleading to say that MacOS doesn't allow a file
> descriptor. MacOS has something similar to what Linux
> has, but not in the normal filesystem namespace. You
> specify a name to get a handle. Of course, on MacOS,
> Joerg also uses -scanbus to create nonsense.
>
> Names can be handled by Windows, FreeBSD, MacOS X,
> Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX.
> That's everything that isn't end-of-lifed.

Aha, so you like to state that MS-WIN is end-of-lifed?
Is this secret new information from Microsoft?

Solaris is not on this list, because the only way to send SCSI commands to any 
kind of SCSI target is by using my /dev/scg driver.

AIX is not on this list because the only way to send SCSI commands to any
target is by using the /dev/gsc driver from Mathew Jacob who is a former
Sun employee and who did get the idea for this driver from a talk with me 
during a visit at Sun in 1987.

FreeBSD is not on the list as it uses CAM, similar to BeOS (Zeta), 
OSF1 (True 64) and QNX.

IRIX is not on this list because it uses the same kind of interface as
e.g. HP-UX does

	snprintf(devname, sizeof (devname),
			"/dev/scsi/sc%dd%dl%d", busno, tgt, tlun);


Next try please....

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)

[Matan Peled]

Joerg Schilling wrote:
> Albert Cahalan <acahalan@gmail.com> wrote:
>> Names can be handled by Windows, FreeBSD, MacOS X,
>> Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX.
>> That's everything that isn't end-of-lifed.
> Aha, so you like to state that MS-WIN is end-of-lifed?
> Is this secret new information from Microsoft?

I'm not an expert in SCSI implementation quirks across varying platfroms, but 
you made a mistake here, Joerg.

Albert put Windows (==MS-WIN) in that list. First one, even.

-- 
[Name      ]   ::  [Matan I. Peled    ]
[Location  ]   ::  [Israel            ]
[Public Key]   ::  [0xD6F42CA5        ]
[Keyserver ]   ::  [keyserver.kjsl.com]
encrypted/signed  plain text  preferred

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

[Joerg Schilling]

Matan Peled <chaosite@gmail.com> wrote:

> Joerg Schilling wrote:
> > Albert Cahalan <acahalan@gmail.com> wrote:
> >> Names can be handled by Windows, FreeBSD, MacOS X,
> >> Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX.
> >> That's everything that isn't end-of-lifed.
> > Aha, so you like to state that MS-WIN is end-of-lifed?
> > Is this secret new information from Microsoft?
>
> I'm not an expert in SCSI implementation quirks across varying platfroms, but 
> you made a mistake here, Joerg.
>
> Albert put Windows (==MS-WIN) in that list. First one, even.

I encourage you to inform yourself about MS-WIN and to find you that
you are wrong.

Under MS-WIN, you use either ASPI -> no open fd at all
or you use something that is very similar to my /dev/scg* device 
on Solaris which uses/defines abstract SCSI transport devices instead of 
possibly unknown high level devices like a disk driver.

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]

>IRIX is not on this list because it uses the same kind of interface as
>e.g. HP-UX does
>
>	snprintf(devname, sizeof (devname),
>			"/dev/scsi/sc%dd%dl%d", busno, tgt, tlun);

So, would you want something like (free format string imagination)
   "/dev/sg-%d-%d-%d", busno, tgt, lun
on Linux?


Jan Engelhardt
-- 

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

[Albert Cahalan]

On 1/26/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Albert Cahalan <acahalan@gmail.com> wrote:

> > You can't fool me, because I looked at the cdrecord source
> > code and at the documented APIs for various OSes.
>
> I am sorry to see that you did not look close enough...
...
> > Names can be handled by Windows, FreeBSD, MacOS X,
> > Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX.
> > That's everything that isn't end-of-lifed.

OK, this is getting silly and downright offensive. I encourage
everyone else to look over the code to see that I am right.

I may just be crazy enough to fork this project. I very nearly
did about 18 months ago. I can't very well do this alone,
because I don't have all the hardware. (It's either cdrecord
or Asterisk -- I'm not sure which one pisses me off the most)

Me:

* was an RTOS developer
* day job is all about secure software
* the procps maintainer
* running Linux 2.6.xx only
* using FireWire, which is totally hot-plug

Perhaps the first thing to do would be to find a list of all the
apps that depend on cdrecord. Their interface to cdrecord
needs to be documented so that a compatibility script can
be made.

Matthias, can you give me a hand with this? I'll need a way
to sort and publish incoming patches, letting them sit for a
while. (like what Andrew Morton does for the kernel) This
can't work like procps because the hardware varies too much.

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

[Kyle Moffett]

On Jan 26, 2006, at 19:19, Albert Cahalan wrote:
> I may just be crazy enough to fork this project. I very nearly did  
> about 18 months ago. I can't very well do this alone, because I  
> don't have all the hardware

I will gladly test your fork on my various hardware here.  I have a  
desktop with Apple CD/RW+DVDROM and generic DVD+/-RW DL drive, and a  
laptop with Apple DVD+/-RW drive.  Just send or post patches  
somewhere and I'll take a look.  I suggest starting by looking at  
some of the various distro patches, IIRC some of them have already  
make significant cleanups.

> Matthias, can you give me a hand with this? I'll need a way to sort  
> and publish incoming patches, letting them sit for a while. (like  
> what Andrew Morton does for the kernel) This can't work like procps  
> because the hardware varies too much.

Might I suggest quilt or stgit?  Both allow you to maintain an  
unstable and highly variable stack of patches based off a more stable  
branch, from which some patches percolate down into stable occasionally.

Good luck with this!

Cheers,
Kyle Moffett

--
Simple things should be simple and complex things should be possible
   -- Alan Kay

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

[Xavier Bestel]

On Fri, 2006-01-27 at 01:19, Albert Cahalan wrote:
> I may just be crazy enough to fork this project. I very nearly
> did about 18 months ago. I can't very well do this alone,
> because I don't have all the hardware.

Then contribute code to libburn: <http://icculus.org/burn/>

	Xav

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

[DervishD]

    Hi Albert :)

 * Albert Cahalan <acahalan@gmail.com> dixit:
> I may just be crazy enough to fork this project. I very nearly
> did about 18 months ago. I can't very well do this alone,
> because I don't have all the hardware.

    You can count on a Plextor Premium and a AOpen 1616ARR here. I
also have another Plextor DVD708 but it no longer writes CDs :((
I will gladly test your fork here.

    And of course, you can count on any writer I can put my hands on.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

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

[Bill Davidsen]

Albert Cahalan wrote:

> OK, this is getting silly and downright offensive. I encourage
> everyone else to look over the code to see that I am right.
> 
> I may just be crazy enough to fork this project. I very nearly
> did about 18 months ago. I can't very well do this alone,
> because I don't have all the hardware. (It's either cdrecord
> or Asterisk -- I'm not sure which one pisses me off the most)

I can test on various 2.6 kernel ATAPI CD and DVD burners, and on 2.4 
kernel even a real SCSI CD burner as long as it lasts. I would love to 
see some mutual cooperation, but I doubt it's going to happen.

Just to be clear, Joerg is not the only one I think has been a problem 
here, he pissed off some of the developers who don't seem overly eager 
to do things which would be helpful for any burner software. From here 
it looks like a pissing content, with users well within splash range.
> 
> * was an RTOS developer
> * day job is all about secure software
> * the procps maintainer
> * running Linux 2.6.xx only
> * using FireWire, which is totally hot-plug
> 
> Perhaps the first thing to do would be to find a list of all the
> apps that depend on cdrecord. Their interface to cdrecord
> needs to be documented so that a compatibility script can
> be made.

Do you plan on changing the interface, then? Removing the SCSI stuff 
completely? Do bear in mind that there are still SCSI burners and people 
using them, and cdrecord is currently portable to many operating systems.
> 
> Matthias, can you give me a hand with this? I'll need a way
> to sort and publish incoming patches, letting them sit for a
> while. (like what Andrew Morton does for the kernel) This
> can't work like procps because the hardware varies too much.

Look a year down the road, when we have have two (or more) new 25GB 
optical formats coming out, probably with new features and commands and 
several vendors building drives for them. Both formats have DRM stuff in 
them, and GPL 3 forbids implementing DRM (simplification).

Better you than me, but it will be exciting. To the extent that I have 
the hardware I'll be glad to test.

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

[Matthias Andree]

On Mon, 30 Jan 2006, Bill Davidsen wrote:

> Just to be clear, Joerg is not the only one I think has been a problem 
> here, he pissed off some of the developers who don't seem overly eager 
> to do things which would be helpful for any burner software. From here 
> it looks like a pissing content, with users well within splash range.

Well, Jörg is not giving us answers to the extent that might convince a
Linux kernel hacker to change things, except for a few handrails besides
the staircase, such as Ted's suggestion WRT RLIMIT_MEMLOCK, or people
offering to fix ide-tape to talk SG_IO - Jörg however has not yet
documented how ide-tape fixes are relevant for the CD writing
application (no doubt that a SCSI /GENERAL/ interface library has
interest in such, it does not matter to the CD writing topic).

> Look a year down the road, when we have have two (or more) new 25GB 
> optical formats coming out, probably with new features and commands and 
> several vendors building drives for them. Both formats have DRM stuff in 
> them, and GPL 3 forbids implementing DRM (simplification).

I find it fascinating that everyone talks about the first public GPL v3
draft as though it were the final version. Now is the time to express
concerns, for instance, the GPL's incompatibility, to the FSF.

And no, I do not have current plans to work on a cdrecord fork as it is.

-- 
Matthias Andree

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

[Lee Revell]

On Mon, 2006-01-30 at 16:49 -0500, Bill Davidsen wrote:
> Look a year down the road, when we have have two (or more) new 25GB 
> optical formats coming out, probably with new features and commands
> and several vendors building drives for them. Both formats have DRM
> stuff in them, and GPL 3 forbids implementing DRM (simplification). 

Who cares what GPL 3 says, the kernel is GPL2.

Lee

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

[Bill Davidsen]

Lee Revell wrote:

>On Mon, 2006-01-30 at 16:49 -0500, Bill Davidsen wrote:
>  
>
>>Look a year down the road, when we have have two (or more) new 25GB 
>>optical formats coming out, probably with new features and commands
>>and several vendors building drives for them. Both formats have DRM
>>stuff in them, and GPL 3 forbids implementing DRM (simplification). 
>>    
>>
>
>Who cares what GPL 3 says, the kernel is GPL2.
>

Did you miss the subject? My reply was to a suggestion that cdrecord 
(it's not the kernel!) be forked, and discussion of what license MIGHT 
apply. I was making an information point about an application which is 
very important to a lot of people.

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