Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

It creates bad impressions if people from LKML are a source of unrelated rants.
Please stop this if you don't like to conribute to the subject.

BTW: I am using 'mailx' which is _the_ official mail reader from the POSIX 
standard......


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Eduard Bloch]

Moin Joerg!
Joerg Schilling schrieb am Freitag, den 06. August 2004:

> It creates bad impressions if people from LKML are a source of
> unrelated rants.

There is no rant. The threads on LKML become often too large so it is
essential to have a structure in them. Your mail client breaks this
structures while almost everybody else cares about it.

> BTW: I am using 'mailx' which is _the_ official mail reader from the POSIX 
> standard......

What's the point? ASCII is the "official US alphabet encoding" so does
that mean that you have to avoid any other chars (eg. the one in your
name)? Or how many people use ash, the spartanic "POSIX compliant"
shell for daily work? Reality check please.

Regards,
Eduard.
-- 
<stockholm> Overfiend: why dont you flame him? you are good at that.
<Overfiend> I have too much else to do.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Fri, 2004-08-06 at 10:33 +0200, Joerg Schilling wrote:
> It creates bad impressions if people from LKML are a source of unrelated rants.

That line is more than 78 characters long, in violation of another
'RECOMMENDED' in §3.5 of RFC2822. You didn't present any justification
for violating §3.6.4 -- do you have any justification for this one?

> Please stop this if you don't like to conribute to the subject.

It's not an unrelated rant. If you want to participate in a public
forum, you are expected to show a little bit of respect for netiquette.

I don't have anything to contribute to the thread -- it's not my area of
expertise. Hence I want to ignore the thread -- but that's not easy
since your broken MUA keeps creating _new_ threads.

> BTW: I am using 'mailx' which is _the_ official mail reader from the POSIX 
> standard......

I care not what it is; it's broken. Please stop using it in public fora.

I note that it also includes 8-bit data without Content-Type: or
Content-Transfer-Encoding: headers. According to §§5.2 and 6.1 of
RFC2045, the default values to be assumed in the absence of those
headers are 'text/plain; charset=us-ascii' and '7BIT' respectively. It
is therefore erroneous to use the octet 0xf6 where presumably you
intended the character 'ö', because that is not a valid US-ASCII
character, and because the octet 0xf6 is not permitted in '7bit' data.

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[DervishD]

    Hi Jörg :)

 * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> It creates bad impressions if people from LKML are a source of
> unrelated rants. Please stop this if you don't like to conribute to
> the subject.

    Joerg, don't take it bad, nor as a personal offense, but it is
*really* difficult to follow a thread which is broken, and your
messages starts new threads. That's difficult.

> BTW: I am using 'mailx' which is _the_ official mail reader from
> the POSIX standard......

    POSIX may specify 'mailx' as the name of the official mail
reader, I really don't know, but your 'mailx' is screwing the
threads.

    Believe it or not, people don't hate you and don't do things just
to annoy you, is just a bit of netiquette, no more, no less. You're a
very clever guy (the cdrecord I use everyday is there to prove it)
but sometimes you sound a bit... blunt and that causes problems.

    No offense intended ;)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[H. Peter Anvin]

Followup to:  <20040806104026.GD24158@DervishD>
By author:    DervishD <raul@pleyades.net>
In newsgroup: linux.dev.kernel
> 
> > BTW: I am using 'mailx' which is _the_ official mail reader from
> > the POSIX standard......
> 
>     POSIX may specify 'mailx' as the name of the official mail
> reader, I really don't know, but your 'mailx' is screwing the
> threads.
> 

POSIX specifies interfaces, not implementations.  It doesn't matter if
one particular implementation conforms to the POSIX mailx interface
for mail submission if its other interface (RFC 2821/2822) is broken.

	-hpa

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

Joerg Schilling schrieb am 2004-08-06:

> It creates bad impressions if people from LKML are a source of unrelated rants.
> Please stop this if you don't like to conribute to the subject.
> 
> BTW: I am using 'mailx' which is _the_ official mail reader from the POSIX 
> standard......

Please see if you like Gunnar Ritter's "nail" mailer in version 9.24 or
newer (11.1 is current), it has the POSIX mailx user interface to begin
with, but supports MIME (hence we'll read J�rg rather than J\366rg or
JXrg or J?rg) and inserts In-Reply-To: and References: headers on
replies. Best of both worlds: You keep your interface, LKML keeps its
threads.  http://nail.sourceforge.net/

I've set Reply-To and Mail-Followup-To to divert replies to this mail
off the list.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Pascal Schmidt]

On Sat, 21 Aug 2004 14:50:08 +0200, you wrote in linux.kernel:

> If the owners and permissions of the filesystem have been set up correctly,
> then there is no security problem. 

The previous Linux implementation allowed users with *read* access
to the device to send arbitrary SG_IO commands. Giving read permission
to normal users is quite common, to allow them to run isosize or play
their freshly burned SVCDs with mplayer.

It violated the principle of least surprise that a user can screw
the device without even having write permission.

Yes, it breaks user-space programs, and yes, the kernel is to blame
for its previous behavior, not user-space. However, now we need to
get on, and going back to the previous behavior, which because
the discussion is now a well-known security hole, is not an option.

-- 
Ciao,
Pascal

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Pascal Schmidt <der.eremit@email.de> wrote:

> On Sat, 21 Aug 2004 14:50:08 +0200, you wrote in linux.kernel:
>
> > If the owners and permissions of the filesystem have been set up correctly,
> > then there is no security problem. 
>
> The previous Linux implementation allowed users with *read* access
> to the device to send arbitrary SG_IO commands. Giving read permission

This is of course a kernel bug - but it could be easily fixed.
My scg driver for SunOS requires write permissions since it has been
created in August 1986.


> to normal users is quite common, to allow them to run isosize or play
> their freshly burned SVCDs with mplayer.

So changing the kernel to require write permissions would be a simple fix that
would help without breaking cdrtools as libscg of course opens the devices with 
O_RDWR.

I am not against a long term change that would require euid root too, but this 
should be announced early enough to allow prominent users of the interface to 
keep track of the interface changes.

BTW: the currely used errno EACCESS applies to file permissions while EPERM
applies to process permissions. So EPERM would be a more appropriate errno 
value.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Pascal Schmidt]

On Sat, 21 Aug 2004, Joerg Schilling wrote:

> So changing the kernel to require write permissions would be a simple
> fix that would help without breaking cdrtools as libscg of course opens
> the devices with O_RDWR.

I agree, but Linus obviously thought otherwise. Reverting that and
doing the above fix instead would create three different behaviours
for different 2.6.x kernel versions, which is also undesirable.

> I am not against a long term change that would require euid root too,
> but this should be announced early enough to allow prominent users of
> the interface to keep track of the interface changes.

Too late for that now, no matter whether we like it or not... however,
at least the discussion now has shown that changes to this interface
need to be considered carefully, so maybe the future will be
bright. ;)

-- 
Ciao,
Pascal

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Let me give some additional remarks to clear up things:

Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> Pascal Schmidt <der.eremit@email.de> wrote:

> > The previous Linux implementation allowed users with *read* access
> > to the device to send arbitrary SG_IO commands. Giving read permission
>
> This is of course a kernel bug - but it could be easily fixed.
> My scg driver for SunOS requires write permissions since it has been
> created in August 1986.

Not checking for Write access permissions at this place is a typical mistake
made by novice programmers, so I never thought this could be in Linux.....


> > to normal users is quite common, to allow them to run isosize or play
> > their freshly burned SVCDs with mplayer.
>
> So changing the kernel to require write permissions would be a simple fix that
> would help without breaking cdrtools as libscg of course opens the devices with 
> O_RDWR.

If Linux still noes not check for write permissions, I would consider there is 
still a bug.

If there is a list of "aparently safe" SCSI commands that are allowed to be 
executed, then there is another bug in Linux. The only SCSI command that could 
be called safe if Test Unit Ready and even this only if not send more then once 
every few seconds.

There are several SCSI commands that look safe but would result in coasters
if issued while a CD or DVD is written.

Conclusion: It makes no sense to start implementing a fine grained security 
model before basic secutity has been done correctly.

The best immediate fix for the problem is to just check for read & write 
permissions on the file descriptor and otherwise revert to how it has been
before 2.6.8.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

> > Pascal Schmidt <der.eremit@email.de> wrote:

>> I am not against a long term change that would require euid root too,
>> but this should be announced early enough to allow prominent users of
>> the interface to keep track of the interface changes.

>Too late for that now, no matter whether we like it or not... however,
>at least the discussion now has shown that changes to this interface
>need to be considered carefully, so maybe the future will be
>bright. ;)

Eveybody makes mistakes. Not being able to admid that and persisting to 
continue to go in a wrong direction is the real problem.

There is no problem to do what I did propose.

And the wrong decision could have even be avoided if people did contact me
before they did act....


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Sun, 22 Aug 2004 14:14:08 +0200, Joerg Schilling
<schilling@fokus.fraunhofer.de> wrote:
> Eveybody makes mistakes. Not being able to admid that and persisting to
> continue to go in a wrong direction is the real problem.
 
Yes, everyone does. Yours was flaming kernel developers over the lkml
about bugs in your own program; yet, you do not admit to this, and
continue to piss everyone off.

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Patrick McFarland <diablod3@gmail.com> wrote:

> On Sun, 22 Aug 2004 14:14:08 +0200, Joerg Schilling
> <schilling@fokus.fraunhofer.de> wrote:
> > Eveybody makes mistakes. Not being able to admid that and persisting to
> > continue to go in a wrong direction is the real problem.
>  
> Yes, everyone does. Yours was flaming kernel developers over the lkml
> about bugs in your own program; yet, you do not admit to this, and
> continue to piss everyone off.

You seem to be unable to distinct between cause and effect.

	Some pleople at Linux kernel ML did start to flame me while I was
	trying to do my best to give technical based explanations.

As it has been proven that threre _are_ reasonable people in LKML, it would 
help LKML to regain credibility if they could try to do some self cleaning
and find a way to calm down the non-serious people.


You also seem to be unable to judge where bugs are located while looking at 
problems.

	It seems that we just agreed with the reasonable members of LKML
	that there was and still is a security related bug in Linux.
	The "fix" that used in hope to remove the security problems did just
	create new problems instead of removing old ones.

If you have nothing useful to say, please stay quiet.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Horst von Brand]

Joerg Schilling <schilling@fokus.fraunhofer.de> said:
> Patrick McFarland <diablod3@gmail.com> wrote:
> > On Sun, 22 Aug 2004 14:14:08 +0200, Joerg Schilling
> > <schilling@fokus.fraunhofer.de> wrote:
> > > Eveybody makes mistakes. Not being able to admid that and persisting to
> > > continue to go in a wrong direction is the real problem.
> >  
> > Yes, everyone does. Yours was flaming kernel developers over the lkml
> > about bugs in your own program; yet, you do not admit to this, and
> > continue to piss everyone off.
> 
> You seem to be unable to distinct between cause and effect.

Exactly right.

> 	Some pleople at Linux kernel ML did start to flame me while I was
> 	trying to do my best to give technical based explanations.
> 
> As it has been proven that threre _are_ reasonable people in LKML, it would 
> help LKML to regain credibility if they could try to do some self cleaning
> and find a way to calm down the non-serious people.

Bann you from the list would go a long way, true; but I oppose such
measures as a matter of principle. Better try to convince the people
out-of-line to do their own soul searching. Hasn't worked so far, sadly.

> You also seem to be unable to judge where bugs are located while looking at 
> problems.
> 
> 	It seems that we just agreed with the reasonable members of LKML
> 	that there was and still is a security related bug in Linux.
> 	The "fix" that used in hope to remove the security problems did just
> 	create new problems instead of removing old ones.
> 
> If you have nothing useful to say, please stay quiet.

There was a security problem, I think all agree on that. LKML says any
security problem has to be fixed ASAP, especially if it is well known and
easy to exploit. You say backward compatibility is more important. The
people in charge of the kernel are the ones who decide what to do, in this
case they overwhelmingly decided against you. Though luck.

[Yes, I fully expect you to tell me this is not useful. Perhaps it isn't.
 But continuing to pour gas on the flames (as you are so fond doing)
 doesn't help either.]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Horst von Brand]

Joerg Schilling <schilling@fokus.fraunhofer.de> said:

[...]

> And the wrong decision could have even be avoided if people did contact me
> before they did act....

Exactly! They should also contact me and ask politely each time they
consider a change if I'd allow it. Really. The nerve these guys have.
Unbelievable.

In the end, I'd only say that I've been on LKML for a long, long time
(since it started, more or less). And each single time the head hackers
agreed on something, and there was a single dissenter, the dissenter was in
the wrong. Sure, this time could be different, but I have seen absolutely
no (yes, _no_) evidence here to the contrary.

The kernel changed, badly conceived interfases were (somewhat, perhaps
broken in another way) fixed. Some applications that depended on the
brokenness don't work now. Tough luck, fix the applications and
(optionally) ask _politely_, with _detailed discussion_, perhaps propose a
better fix for the kernel. Just whining that the application broke during
its "code freeze" won't get you anywhere (you just can't expect to hold the
kernel hostage to your random, mostly unrelated, program's development
schedule; that model just won't get anywhere real fast). 

Treating everybody as ignorant morons isn't exactly the best way to be
heard. And in this case there is ample evidence on hand that they are very
smart people who usually are right in regards to the techical matters they
have in their hands.

I.e., you are making a fool of yourself here.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

On Sun, 22 Aug 2004, Horst von Brand wrote:

> In the end, I'd only say that I've been on LKML for a long, long time
> (since it started, more or less). And each single time the head hackers
> agreed on something, and there was a single dissenter, the dissenter was in
> the wrong. Sure, this time could be different, but I have seen absolutely
> no (yes, _no_) evidence here to the contrary.

There _are_ cases where a kernel patch sneaked to a subsystem maintainer
has made it even when some of the "heads" said it was impossible.

The key is convincing a subsystem maintainer that the patch helps and
doesn't hurt. And that doesn't work with a rant and can sometime take a
kernel patch to show how it works.  A decent patch with a more decent
description works wonders - usually.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Pascal Schmidt]

On Sun, 22 Aug 2004, Joerg Schilling wrote:

> Not checking for Write access permissions at this place is a typical
> mistake made by novice programmers, so I never thought this could be in
> Linux.....

People will find this kind of language inflammatory. ;) However, exactly
because it is such a bad mistake did Linus put out what he deemed a
correct fix *immediately*.

> If Linux still noes not check for write permissions, I would consider
> there is still a bug.

The open question is whether write permission really is meaningful
enough to allow arbitrary SCSI commands. I personally think "being
able to wipe the drive firmware" is too much, and since filtering
of vendor commands is generally impossible to do right, sending SG_IO
should require CAP_SYS_RAWIO capability.

> If there is a list of "aparently safe" SCSI commands that are allowed to
> be executed, then there is another bug in Linux. The only SCSI command
> that could be called safe if Test Unit Ready and even this only if not
> send more then once every few seconds.

Currently (2.6.8.1), there is a list in the kernel. I agree that it
doesn't make sense. I would think read permission means to be able
to read from the device, write means you can write. I would even go
as far as *not* to have that mean "you can also read/write via SG_IO",
because for normal uses of the device, read(2) and write(2) should be
enough.

BTW, there are a number of people on the kernel list who believe a
filter list is bad and generally unmaintainable.

> There are several SCSI commands that look safe but would result in coasters
> if issued while a CD or DVD is written.

Good point.

> The best immediate fix for the problem is to just check for read & write
> permissions on the file descriptor and otherwise revert to how it has been
> before 2.6.8.

I don't think that's going to happen. You already said you'd be okay
with euid==0 being required for burning, if only the transition
period were longer. So if people complain to you that cdrecord is
broken with 2.6.8, you will have to tell them burning requires root
for the moment. Then in your next release, change your startup
code not to drop the CAP_SYS_RAWIO capability when you drop root
privileges.

Alternatively, provide a patch that changes the current code to just
require write permission or CAP_SYS_RAWIO to be able to send
arbitrary commands. Then, after a transition period, submit a patch
that changes it to just CAP_SYS_RAWIO. The patch would look like the
one below (untested).

Jens, since this seems to be your code, what do you think?


--- scsi_ioctl.c	2004-08-14 18:26:17.000000000 +0200
+++ scsi_ioctl.c.new	2004-08-22 15:08:36.000000000 +0200
@@ -105,70 +105,12 @@ static int sg_emulated_host(request_queu
 	return put_user(1, p);
 }

-#define CMD_READ_SAFE	0x01
-#define CMD_WRITE_SAFE	0x02
-#define safe_for_read(cmd)	[cmd] = CMD_READ_SAFE
-#define safe_for_write(cmd)	[cmd] = CMD_WRITE_SAFE
-
-static int verify_command(struct file *file, unsigned char *cmd)
+static int verify_command(struct file *file)
 {
-	static const unsigned char cmd_type[256] = {
-
-		/* Basic read-only commands */
-		safe_for_read(TEST_UNIT_READY),
-		safe_for_read(REQUEST_SENSE),
-		safe_for_read(READ_6),
-		safe_for_read(READ_10),
-		safe_for_read(READ_12),
-		safe_for_read(READ_16),
-		safe_for_read(READ_BUFFER),
-		safe_for_read(READ_LONG),
-		safe_for_read(INQUIRY),
-		safe_for_read(MODE_SENSE),
-		safe_for_read(MODE_SENSE_10),
-		safe_for_read(START_STOP),
-
-		/* Audio CD commands */
-		safe_for_read(GPCMD_PLAY_CD),
-		safe_for_read(GPCMD_PLAY_AUDIO_10),
-		safe_for_read(GPCMD_PLAY_AUDIO_MSF),
-		safe_for_read(GPCMD_PLAY_AUDIO_TI),
-
-		/* CD/DVD data reading */
-		safe_for_read(GPCMD_READ_CD),
-		safe_for_read(GPCMD_READ_CD_MSF),
-		safe_for_read(GPCMD_READ_DISC_INFO),
-		safe_for_read(GPCMD_READ_CDVD_CAPACITY),
-		safe_for_read(GPCMD_READ_DVD_STRUCTURE),
-		safe_for_read(GPCMD_READ_HEADER),
-		safe_for_read(GPCMD_READ_TRACK_RZONE_INFO),
-		safe_for_read(GPCMD_READ_SUBCHANNEL),
-		safe_for_read(GPCMD_READ_TOC_PMA_ATIP),
-		safe_for_read(GPCMD_REPORT_KEY),
-		safe_for_read(GPCMD_SCAN),
-
-		/* Basic writing commands */
-		safe_for_write(WRITE_6),
-		safe_for_write(WRITE_10),
-		safe_for_write(WRITE_VERIFY),
-		safe_for_write(WRITE_12),
-		safe_for_write(WRITE_VERIFY_12),
-		safe_for_write(WRITE_16),
-		safe_for_write(WRITE_BUFFER),
-		safe_for_write(WRITE_LONG),
-	};
-	unsigned char type = cmd_type[cmd[0]];
-
-	/* Anybody who can open the device can do a read-safe command */
-	if (type & CMD_READ_SAFE)
+	/* write access means being able to send any command (for now) */
+	if (file->f_mode & FMODE_WRITE)
 		return 0;

-	/* Write-safe commands just require a writable open.. */
-	if (type & CMD_WRITE_SAFE) {
-		if (file->f_mode & FMODE_WRITE)
-			return 0;
-	}
-
 	/* And root can do any command.. */
 	if (capable(CAP_SYS_RAWIO))
 		return 0;
@@ -181,7 +123,7 @@ static int sg_io(struct file *file, requ
 		struct gendisk *bd_disk, struct sg_io_hdr *hdr)
 {
 	unsigned long start_time;
-	int reading, writing;
+	int reading, writing, res;
 	struct request *rq;
 	struct bio *bio;
 	char sense[SCSI_SENSE_BUFFERSIZE];
@@ -193,8 +135,8 @@ static int sg_io(struct file *file, requ
 		return -EINVAL;
 	if (copy_from_user(cmd, hdr->cmdp, hdr->cmd_len))
 		return -EFAULT;
-	if (verify_command(file, cmd))
-		return -EPERM;
+	if (res = verify_command(file))
+		return res;

 	/*
 	 * we'll do that later

-- 
Ciao,
Pascal

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Pascal Schmidt <der.eremit@email.de> writes:

> I would even go as far as *not* to have that mean "you can also
> read/write via SG_IO", because for normal uses of the device,
> read(2) and write(2) should be enough.

Ripping a CD is in my opinion a normal use of a CD.

> On Sun, 22 Aug 2004, Joerg Schilling wrote:
> > There are several SCSI commands that look safe but would result in coasters
> > if issued while a CD or DVD is written.
> 
> Good point.

Not really, if I have write permisson to a CD burner, being able to
burn a coaster by issuing strange commands is something I expect.
Being able to destroy the firmware of the drive is not something I
expect a normal user to be able to do.

There are at least three conflicting goals here:

1. Only someone with CAP_SYS_RAWIO (i.e. root) should be able to do
   possible destructive things to a device, and only root should be
   able to bypass the normal security checks in the kernel (e.g. get
   access to /dev/mem since access to it means that you can read and
   modify internal kernel structures).

2. A Linux system should have as few suid root binaries as possible.

3. A normal user should be able to perform most tasks without needing
   root.

As you said, since the old kernel behaviour is a gaping security hole,
Linus had no other choice than to add a CAP_SYS_RAWIO check to the
SG_IO call.  This fulfills goal 1.  Unfortunately it breaks just about
every application that expects to be able to send raw SCSI commands
without being root.

There are a couple of ways of fulfilling goal 3 and allow normal users
to burn a CDR:

One is to make cdrecord suid root and then make it drop all
capabilities except for SYS_CAP_RAWIO.  But even if cdrecord is
audited, there are a lot of other applications that need to be able to
send raw SCSI commands such as mt (to change the compression or tape
format of a streamer).  And this violates goal 2, every security guide
I've seen lately recommends minimizing the amount of suid binaries,
not adding more.

Another way is to add specialized ioctls in the kernel for everything,
such as the CDROMPLAYTRKIND to play a track.  Unfortunately, this gets
a bit unmaintainable with all the different devices out there.  It
would be akin to putting the whole of cdrecord into the kernel.

Yet another way is to try to filter the raw SCSI commands and only
allow through "known safe" commands, which is what some other people
have been trying to do.  

I think Joerg is being much too harsh, adding a check for
CAP_SYS_RAWIO fixes a bloody large security hole.  It broke a few
applications, but tough shit, that is what happens every now and then
when plugging security holes.  It would be much worse to leave the
hole open.  The timing may coincide badly with the release cycle of
cdrecord, but thats life.  For now users will have to run cdrecord as
root to be able to burn a CDR.

In the future, add a patch to cdrecord so that it can be run as suid
root and not drop CAP_SYS_RAWIO which will make most users happy.
It's still a violation of goal 2 but one has to do tradeoffs every now
and then.

For the future, well, I'm not sure, but personally I think that the
filter idea is a pretty good one.  It is a coarse sieve, but by
listing some "known safe" commands most applications should work, and
if somebody needs to send a command that isn't considered as safe yet,
he can just run the application as root instead.

In my opinion, the best way forward would be to only have a
CAP_SYS_RAWIO check in the kernel and an installable command filter
that can be configured from userspace.  So when the next version of
snazzycdwriter(tm) is released it can have a line in the README file
saying:

    If you want to be able to run snazzycdwriter(tm) as a normal user,
    add the following command to your rc.local file:

        /sbin/install-scsi-filter /dev/hdc snazzycdwriter.filter

And if you have a tape drive, it could have another list of safe
commands.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Christer Weinigel <christer@weinigel.se> wrote:

> Pascal Schmidt <der.eremit@email.de> writes:
>
> > I would even go as far as *not* to have that mean "you can also
> > read/write via SG_IO", because for normal uses of the device,
> > read(2) and write(2) should be enough.
>
> Ripping a CD is in my opinion a normal use of a CD.

But in order to rip an audio CD, you need to use e.g. MODE SELECT.
If you start to distinct safe SCSI commands from possibly unsafe ones, then 
MODE SELECT could not be in the list of safe ones.

> > On Sun, 22 Aug 2004, Joerg Schilling wrote:
> > > There are several SCSI commands that look safe but would result in coasters
> > > if issued while a CD or DVD is written.
> > 
> > Good point.
>
> Not really, if I have write permisson to a CD burner, being able to
> burn a coaster by issuing strange commands is something I expect.
> Being able to destroy the firmware of the drive is not something I
> expect a normal user to be able to do.

At SCSI level, there is no real difference.


> There are at least three conflicting goals here:
>
> 1. Only someone with CAP_SYS_RAWIO (i.e. root) should be able to do
>    possible destructive things to a device, and only root should be
>    able to bypass the normal security checks in the kernel (e.g. get
>    access to /dev/mem since access to it means that you can read and
>    modify internal kernel structures).

A powerful CD/DVD recording program needs to sometimes issue "secret"
and vendor unique SCSI commands in order to give nice features.

On a Plextor drive, you need to be able to issue a vendor unique SCSI command
to know the recommended write speed for a specific medium. A SCSI command
from same list of vendor unique commands allows you to tell the drive to read
any medium at 52x. This could destroy the medium _and_ the drive.

As you see: you cannot have the needed knowledge inside the kernel.


> 2. A Linux system should have as few suid root binaries as possible.

If you like this completely, you would need to implement something RBAC and
getppriv(2)(setpiriv(2) on Solaris. If you have this, you have zero suid
root binaries on a 'Trusted OS' and one suid binary (/usr/bin/pfexec) on a non 
Trusted system.

> 3. A normal user should be able to perform most tasks without needing
>    root.

Duable if my remark to 2) has been implemented.

> As you said, since the old kernel behaviour is a gaping security hole,
> Linus had no other choice than to add a CAP_SYS_RAWIO check to the
> SG_IO call.  This fulfills goal 1.  Unfortunately it breaks just about

Not true: a simple check like in my scg driver:

        /* 
         * Must have read/write access to /dev/scgxx 
         * to send commands over SCSI Bus. 
         */ 
        if ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) 
                return (EACCES); 

was sudfficient.

> every application that expects to be able to send raw SCSI commands
> without being root.
>
> There are a couple of ways of fulfilling goal 3 and allow normal users
> to burn a CDR:
>
> One is to make cdrecord suid root and then make it drop all
> capabilities except for SYS_CAP_RAWIO.  But even if cdrecord is
> audited, there are a lot of other applications that need to be able to
> send raw SCSI commands such as mt (to change the compression or tape
> format of a streamer).  And this violates goal 2, every security guide
> I've seen lately recommends minimizing the amount of suid binaries,
> not adding more.

A better way is to have services like this in /usr/bin/pfexec that 
do the ecirity related parts before calling the other binaries.

BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via
specilized ioctls.


> I think Joerg is being much too harsh, adding a check for
> CAP_SYS_RAWIO fixes a bloody large security hole.  It broke a few
> applications, but tough shit, that is what happens every now and then

With checking for ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) less applications
would break.

> when plugging security holes.  It would be much worse to leave the
> hole open.  The timing may coincide badly with the release cycle of
> cdrecord, but thats life.  For now users will have to run cdrecord as
> root to be able to burn a CDR.

The result will be that users "find solutions" that will be less secure as
when only a check for ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) has been 
introduced and _later_ (in an agreement with prominent applications)
require root when issuing SCSI commands.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:
> But in order to rip an audio CD, you need to use e.g. MODE SELECT.
> If you start to distinct safe SCSI commands from possibly unsafe ones, then 
> MODE SELECT could not be in the list of safe ones.

Yes, I'm quite aware of that.  

So a filter would have to be smarter than just checking the command
codes.  There would have to be a special case for the mode page
commands which filters on accessible mode pages.

Are there any other commands that would need filtering at a finer
grain than the command level?

Additionally, another thing that is really needed is to match
the different variants of hdr->dxfer_direction against the direction
of the commands, otherwise one could ask for a REQUEST_SENSE but with
a direction of SG_DXFER_TO_DEV.  This isn't a security problem in the
sense that it can destroy the drive itself, but it might hang the
IDE state machine in the kernel, motherboard or drive.  

> > Not really, if I have write permisson to a CD burner, being able to
> > burn a coaster by issuing strange commands is something I expect.
> > Being able to destroy the firmware of the drive is not something I
> > expect a normal user to be able to do.
> 
> At SCSI level, there is no real difference.

SG_IO does not have to work at the SCSI level, it can filter the
commands at a higher level.

> A powerful CD/DVD recording program needs to sometimes issue "secret"
> and vendor unique SCSI commands in order to give nice features.
> 
> On a Plextor drive, you need to be able to issue a vendor unique SCSI command
> to know the recommended write speed for a specific medium. A SCSI command
> from same list of vendor unique commands allows you to tell the drive to read
> any medium at 52x. This could destroy the medium _and_ the drive.
> 
> As you see: you cannot have the needed knowledge inside the kernel.

So guess why I suggested that the kernel should contain the mechanics
to filter commands (and yes, I was aware of the mode page problems but
didn't want to make a long mail even longer), and that the list of
commands would be uploaded to the kernel from userspace.  It was at
the end of the mail you replied to...

That way an application, such as cdrecord, could keep a list of safe
commands for each device and use the appropriate list for each kind of
device.  If the device is a tape, allow access to the mode page that
can control BPI and compression settings.  If it's a cdrom, allow
access to the mode page with CDDA settings.

Of course, if it isn't possible to do this at a mode page level, maybe
the access controls would have to be at the level of individual bits
in a mode page, then it gets trickier.  It might, or might not be
feasible to implement such a filte.  I don't know which is true or
which is not, I'm just trying to look at ways of solving the problem.

> > 2. A Linux system should have as few suid root binaries as possible.
> 
> If you like this completely, you would need to implement something RBAC and
> getppriv(2)(setpiriv(2) on Solaris. If you have this, you have zero suid
> root binaries on a 'Trusted OS' and one suid binary (/usr/bin/pfexec) on a non 
> Trusted system.

Which is not all that different from suid binaries.  Instead of
trusting an application, you're trusting a user or a role.  This isn't
much different from giving "trusted" users access to /dev/scd0.  

> > As you said, since the old kernel behaviour is a gaping security hole,
> > Linus had no other choice than to add a CAP_SYS_RAWIO check to the
> > SG_IO call.  This fulfills goal 1.  Unfortunately it breaks just about
> 
> Not true: a simple check like in my scg driver:
> 
>         /* 
>          * Must have read/write access to /dev/scgxx 
>          * to send commands over SCSI Bus. 
>          */ 
>         if ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) 
>                 return (EACCES); 
>
> was sudfficient.

No.  Sure, you can redefine read access to a SCSI device to mean "may
only use normal read" and write access to "may use read, write and
send raw SCSI commands", but that is a rather bad fit to how
read/write normally are used.

What do you do if you want to allow users with read access to
read a SCSI tape (and to be able select the BPI)?  With your
suggestion, the user will need write access too, but I may just want
to give the user read access.

> BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via
> specilized ioctls.

So why can't cdrecord use specialized ioctls then?

> With checking for ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) less applications
> would break.

cdrecord probably wouldn't break.  Other applications that open
/dev/scd0 as readonly would break.  cdrecord isn't the only
application in the world you know.

The Linux philosophy is "do it right".  And when Linus has been
changing interfaces he has said that he prefers something to break
noisily (not compile) rather than to get compile fixes that leave the
bugs still in there.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Giuseppe Bilotta]

Joerg Schilling wrote:
> A powerful CD/DVD recording program needs to sometimes issue "secret"
> and vendor unique SCSI commands in order to give nice features.
> 
> On a Plextor drive, you need to be able to issue a vendor unique SCSI command
> to know the recommended write speed for a specific medium. A SCSI command
> from same list of vendor unique commands allows you to tell the drive to read
> any medium at 52x. This could destroy the medium _and_ the drive.
> 
> As you see: you cannot have the needed knowledge inside the kernel.

Actually I was wondering about this exactly: why shouldn't this 
knowledge be built into the kernel? IMO it should be. Isn't the 
kernel purpose to do that, among other things? HAL?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Julien Oster]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

> But in order to rip an audio CD, you need to use e.g. MODE SELECT.
> If you start to distinct safe SCSI commands from possibly unsafe ones, then 
> MODE SELECT could not be in the list of safe ones.

That is why I'm proposing an empty filter at boot time, which allows
no SG_IO except when having CAP_SYS_RAWIO (which enables everything)
and the possibility to open up certain commands from userspace later.

Julien

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Julien Oster <lkml-7994@mc.frodoid.org> wrote:

> Joerg Schilling <schilling@fokus.fraunhofer.de> writes:
>
> > But in order to rip an audio CD, you need to use e.g. MODE SELECT.
> > If you start to distinct safe SCSI commands from possibly unsafe ones, then 
> > MODE SELECT could not be in the list of safe ones.
>
> That is why I'm proposing an empty filter at boot time, which allows
> no SG_IO except when having CAP_SYS_RAWIO (which enables everything)
> and the possibility to open up certain commands from userspace later.

If the related /dev/* nodes are owned by root and set up rw-r-r or worse 
for others and requiring write access to send SCSI commands, then you get
the same kind of authentification, but cdrecord would continue to work.

Only if someone would chown the related /dev/* nodes to a user differen from 
root there would be a difference.

P.S.: UNIX philosohy is to allow the administrator to set up bad/wrong permissions.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

Joerg Schilling schrieb am 2004-08-23:

> Only if someone would chown the related /dev/* nodes to a user differen from 
> root there would be a difference.

...which actually happens a lot, with the devperm PAM junk that some,
particularly desktop/end-user oriented distros do, for instance SuSE
Linux twist device permissions. It is awful for shared computers in a
network.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Kai Makisara]

On Sun, 22 Aug 2004, Joerg Schilling wrote:

> Christer Weinigel <christer@weinigel.se> wrote:
> 
...
> > One is to make cdrecord suid root and then make it drop all
> > capabilities except for SYS_CAP_RAWIO.  But even if cdrecord is
> > audited, there are a lot of other applications that need to be able to
> > send raw SCSI commands such as mt (to change the compression or tape
> > format of a streamer).  And this violates goal 2, every security guide
> > I've seen lately recommends minimizing the amount of suid binaries,
> > not adding more.
> 
> A better way is to have services like this in /usr/bin/pfexec that 
> do the ecirity related parts before calling the other binaries.
> 
> BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via
> specilized ioctls.
> 
There are already ioctls for changing the tape parameters. Christer, there 
is no need to introduce tapes into this discussion.

-- 
Kai

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Kai Makisara <Kai.Makisara@kolumbus.fi> writes:

> On Sun, 22 Aug 2004, Joerg Schilling wrote:
> 
> > Christer Weinigel <christer@weinigel.se> wrote:
> > BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via
> > specilized ioctls.
> > 
> There are already ioctls for changing the tape parameters. Christer, there 
> is no need to introduce tapes into this discussion.

It was en example of another application that needs to modify the mode
pages, and it's interesting to look at how we have solved similar
problems before.

So if we want to be consistent we ought to introduce specialized
ioctls for everything cdrecord wants to do.  Otoh, tape drives don't
seem to be such a fast moving target as CD and DVD burners.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Kai Makisara <Kai.Makisara@kolumbus.fi> wrote:

> > BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via
> > specilized ioctls.
> > 
> There are already ioctls for changing the tape parameters. Christer, there 
> is no need to introduce tapes into this discussion.

This is my words....


Tape drives have a well known and simple and standardized interface since many
years (> 40). There exist ioctl()s to do anything you like.


CD/DVD writing ist still constantly evolving, so you cannot have it in the 
kernel.

BTW: I am strongly against any list of "safe commands" as this would only make 
things more complicated. Things that control security should be ket simple.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

/me keeping to the bad habit of following up to myself

Regarding the current 2.6.8 kernel, wouldn't it be a better idea to
move the CAP_SYS_RAWIO check to open time instead of when the ioctl is
called?  This would require a new flag somewhere in the file structure
I suppose, e.g. file->f_mode & FMODE_RAWIO.  

That would allow a suid root application to open the cdrom and then
drop all capabilities including RAWIO and would probably fit better
into how cdrecord expects things to work.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Sul, 2004-08-22 at 17:33, Christer Weinigel wrote:
> /me keeping to the bad habit of following up to myself
> 
> Regarding the current 2.6.8 kernel, wouldn't it be a better idea to
> move the CAP_SYS_RAWIO check to open time instead of when the ioctl is
> called?  This would require a new flag somewhere in the file structure
> I suppose, e.g. file->f_mode & FMODE_RAWIO.  

This leads to all sorts of bugs where descriptors owned by one process
are given to another less priviledged one. In the networking world
similar logic led to holes because rsh for example gave root opened fd's
to users.

Alan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Sul, 2004-08-22 at 17:33, Christer Weinigel wrote:
> > Regarding the current 2.6.8 kernel, wouldn't it be a better idea to
> > move the CAP_SYS_RAWIO check to open time instead of when the ioctl is
> > called?  This would require a new flag somewhere in the file structure
> > I suppose, e.g. file->f_mode & FMODE_RAWIO.  
> 
> This leads to all sorts of bugs where descriptors owned by one process
> are given to another less priviledged one. In the networking world
> similar logic led to holes because rsh for example gave root opened fd's
> to users.

On the other hand a bug in my favourite cd burner application could
give away SYS_CAP_RAWIO instead, and I think that is even worse.

Besides, checking SYS_CAP_RAWIO at open time is the way /dev/mem
works.  OTOH applications don't normally hand over /dev/mem to other
applications I suppose.  

I'm just tossing ideas around, please ignore me if they are stuipd :-)

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Sul, 2004-08-22 at 18:31, Christer Weinigel wrote:
> On the other hand a bug in my favourite cd burner application could
> give away SYS_CAP_RAWIO instead, and I think that is even worse.

Its not an easy trade off- I don't know if there is a right answer.
Despite the UI problems in both cdrecord and its author the internal
code is actually quite rigorous so its something I'd be more comfortable
giving limited rawio access than quite a few other apps that touch
external public data.

Alan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> Its not an easy trade off- I don't know if there is a right answer.
> Despite the UI problems in both cdrecord and its author the internal
> code is actually quite rigorous so its something I'd be more comfortable
> giving limited rawio access than quite a few other apps that touch
> external public data.

Another way would be to add a scsi ioctl such as ENABLE_SG_IO or an
open flag, e.g. open("/dev/hdc", ... | O_RAWIO) which needs
CAP_SYS_RAWIO.  That way it is much less likely that the RAWIO
permission is given away by mistake, but I must admit that it feels
kind of ugly.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Adam Sampson]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> Regarding the current 2.6.8 kernel, wouldn't it be a better idea to
>> move the CAP_SYS_RAWIO check to open time instead of when the ioctl is
>> called?
> This leads to all sorts of bugs where descriptors owned by one process
> are given to another less priviledged one.

Yes, but that's a class of bugs that are pretty well understood these
days; handing privileged FDs around is a moderately common and
pleasantly fine-grained way of doing things. Closing an FD is at least
as easy as dropping a capability, which is what you'd have to do
with the current scheme upon entering unprivileged code.

Besides, setuid CD-recording tools already have to worry about closing
unsafe FDs when they drop privileges, so this doesn't seem to add any
new security holes...

Thanks,

-- 
Adam Sampson <azz@us-lot.org>                        <http://offog.org/>

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Tonnerre]

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

Salut,

On Sun, Aug 22, 2004 at 06:00:01PM +0200, Christer Weinigel wrote:
>     If you want to be able to run snazzycdwriter(tm) as a normal user,
>     add the following command to your rc.local file:
> 
>         /sbin/install-scsi-filter /dev/hdc snazzycdwriter.filter

Well, for that it might be  a nice feature to register and delete such
filters  online, using  a  register/remove_scsi_filter interface,  but
well, otoh that might be undesirable security-wise.

			    Tonnerre

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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

Tonnerre wrote:

> Well, for that it might be  a nice feature to register and delete such
> filters  online, using  a  register/remove_scsi_filter interface,  but
> well, otoh that might be undesirable security-wise.

Let me throw out two ideas to see if anyone find them useful.

1 - loadable command filters in the kernel.

Each device could have a filter set, which could be empty to require 
RAWIO capability, or set to a kernel default. Access could be made to 
modify a filter via proc, sysfs, or ioctl. The set method is not 
relevant to the idea.

2 - a filter program.

This one can be done right now, no kernel mod needed. A program with 
appropriate permissions can be started, and will create a command/status 
fifo pair with permissions which allow only programs with group 
permission to open. This allows the admin to put in any filter desired, 
know about vendor commands, etc. It also allows various security setups, 
the group can be on the user (trusted users) or on a setgid program 
(which limits the security issues).

Note that the permissions on individual devices need not be the same; I 
can have one group for disk, another for CD/DVD. You caould even be anal 
and have the filter time sensitive, etc.

A 'standard" place for the fifos helps portability, /var/sgio/dev/hda 
might be a directory, with fifos command and status.


Okay, did I miss something, or can this be solved without any additional 
kernel hacks?

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Doug Maxey]

On Mon, 23 Aug 2004 16:25:17 EDT, Bill Davidsen wrote:
>permission to open. This allows the admin to put in any filter desired,
> know about vendor commands, etc. It also allows various security
>setups,  the group can be on the user (trusted users) or on a setgid
>program  (which limits the security issues).

  Down such path lies madness :)   This list would have to be maintained for
  most every model, of every drive, for every manufacturer.  The list could
  conceivably change weekly, if not sooner.  This could change, of course, if
  the use of linux would become as ubiquitous as the dominant redmond produnt, 
  and the manufacturers would supply the "mini-port" driver bits, as it were.

  The theory is wonderful.  Until there is enough "clout" to change the 
  manufacturers participation, it is probably futile. :-/

++doug

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

Doug Maxey wrote:
> On Mon, 23 Aug 2004 16:25:17 EDT, Bill Davidsen wrote:
> 
>>permission to open. This allows the admin to put in any filter desired,
>>know about vendor commands, etc. It also allows various security
>>setups,  the group can be on the user (trusted users) or on a setgid
>>program  (which limits the security issues).
> 
> 
>   Down such path lies madness :)   This list would have to be maintained for
>   most every model, of every drive, for every manufacturer.  The list could
>   conceivably change weekly, if not sooner.  This could change, of course, if
>   the use of linux would become as ubiquitous as the dominant redmond produnt, 
>   and the manufacturers would supply the "mini-port" driver bits, as it were.
> 
>   The theory is wonderful.  Until there is enough "clout" to change the 
>   manufacturers participation, it is probably futile. :-/

But you don't need magic vendor commands to read and write disk (or 
tape), you can do it with the base commands defined in SCSI-II. You only 
need filter lists for special cases where (a) you really do want vendor 
commands and (b) there's some reason to allow this to normal users.

I doubt that you need magic for any of the other obvious devices like 
SCSI scanners, ZIP and LS120 drives using ATA access rather than 
ide-floppy or ide-scsi, etc. I could be wrong on scanners, the setup 
commands may be more dangerous than I think.

To write CD unfortunately does seem to take more than I want the average 
user to do.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Nuno Silva]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Bill Davidsen wrote:
| Tonnerre wrote:
|
|> Well, for that it might be  a nice feature to register and delete such
|> filters  online, using  a  register/remove_scsi_filter interface,  but
|> well, otoh that might be undesirable security-wise.
|
|
| Let me throw out two ideas to see if anyone find them useful.
|
| 1 - loadable command filters in the kernel.
|
| Each device could have a filter set, which could be empty to require
| RAWIO capability, or set to a kernel default. Access could be made to
| modify a filter via proc, sysfs, or ioctl. The set method is not
| relevant to the idea.
|
| 2 - a filter program.
|
| This one can be done right now, no kernel mod needed. A program with
| appropriate permissions can be started, and will create a command/status
| fifo pair with permissions which allow only programs with group
| permission to open. This allows the admin to put in any filter desired,
| know about vendor commands, etc. It also allows various security setups,
| the group can be on the user (trusted users) or on a setgid program
| (which limits the security issues).
|
| Note that the permissions on individual devices need not be the same; I
| can have one group for disk, another for CD/DVD. You caould even be anal
| and have the filter time sensitive, etc.
|
| A 'standard" place for the fifos helps portability, /var/sgio/dev/hda
| might be a directory, with fifos command and status.
|
|
| Okay, did I miss something, or can this be solved without any additional
| kernel hacks?

Sorry for jumping in this (hot) thread, but I just want to say something:

This is, IMHO, the way to go. Keeping static white-lists in the kernel
is bad and goes against the 2.6 moto: "do it in userspace".

Anyway, I can imagine that the distros are thinking about the problem
very hard. They can't just delete the cd-burn feature as non-root :-)

Also, many things can be affected by this, right? Scanners, jukeboxes,
ip-over-scsi, etc... A programmable kernel interface or a userspace
helper is the only way. To keep things _fast_, I'd be happy with a simple
# echo 1 > /sys/block/hdd/rawio/enable_rawio_if_user_can_write
brw-rw----  1 root disk 22, 64 Mar 14  2002 /dev/hdd
Now every member of @disk can trash your data and your cdrom's firmware.

If the admin sets this flag it's his responsability[*].

Peace,
Nuno Silva

[*] Once you start refusing to let root shoot himself in the foot
there's no way back. You must "fix" 60% of Linux! :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBKqZVOPig54MP17wRAgE0AJ9LjIKpK+S1nqBYYbOZywVontBdggCdGbF6
Uf2Ok3aFvCbXp6k4Wq7Pn2A=
=cEo2
-----END PGP SIGNATURE-----

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Julien Oster]

Pascal Schmidt <der.eremit@email.de> writes:

Hello Pascal,

> The open question is whether write permission really is meaningful
> enough to allow arbitrary SCSI commands. I personally think "being
> able to wipe the drive firmware" is too much, and since filtering
> of vendor commands is generally impossible to do right, sending SG_IO
> should require CAP_SYS_RAWIO capability.

But what about the following (the first 3 points are already
familiar):

1. require read permission to do read()
2. require write premission to do write()
3. require CAP_SYS_RAWIO to do SG_IO
4. insert an initially blank (i.e. "drop everything") userspace
   controllable filter which allows the administrator to specify
   allowed SG_IO commands to the kernel at any time

That way there is no security problem, CD burning as root or generally
with CAP_SYS_RAWIO is always possible *and* admins are able to submit a
list of allowed commands to the kernel, so that CD burning as user is
possible again. This list might be specific to the CD writer hardware,
as we learned that some drives require vendor specific commands.

Prewritten filter lists for specific hardware can be published on
internet or even be submitted by cdrecord or other burning software,
i.e. with a switch "--install-filter" as root.

The filters should be separate for each SCSI device, so that you won't
enable dangerous commands on harddisk partitions when you just wanted
to enable CD burning.

If nobody else volunteers, I'll see if I can prepare a patch. I guess
sysfs is the right place for the userspace interface to the filters?

Regards,
Julien

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

>From davidsen@tmr.com  Thu Aug 12 23:08:49 2004

>But they *don't* map to consistent device names. All hot pluggable 
>devices seem to map to the next available name. Looking at one of my 
>utility systems, it has IDE drives mapped by Redhat with ide-scsi, real 
>SCSI drives, a couple of flash card slots mapped to SCSI, and a USB 
>device, all in the /dev/sdX namespace. And in the order in which they 
>were detected (connected, in other words).

Install Solaris and try to replug a USB writer - you will see the same
address as before.

>Joerg hasn't made it any better, but it isn't great anyway. I recommend 
>a script to do discovery and make symlinks somewhere to names which 
>always match the same device.

Being forced to base on a weak grounding does not make the layers above
bad if they only don't work because of the bad grounding.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Andreas Schwab]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

> Install Solaris and try to replug a USB writer - you will see the same
> address as before.

What happens when you unplug the USB writer, plug in a different one and
then replug the first writer?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Robert M. Stockmann]

On Thu, 12 Aug 2004, Jens Axboe wrote:

> On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > 
> > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > > 
> > > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > > On Thu, 12 Aug 2004, Frank Steiner wrote:
> > > > > > 
> > > > > > > Robert M. Stockmann wrote:
> > > > > > > 
> > > > > > > > i must agree here that getting cdrecord/cdrtools-2.0x going on the latest
> > > > > > > > SuSE 9.x editions has been extremely tiresome. 
> > > > > > > 
> > > > > > > Because of what? We are running the cdrecord versions that SuSE
> > > > > > > shipped with 9.0 and 9.1, and there hasn't been a single problem
> > > > > > > for over 8 months now with three different cd and dvd burners.
> > > > > > > So where's the problem?
> > > > > > 
> > > > > > I posted this on comp.os.linux.advocacy some time ago :
> > > > > > 
> > > > > > "SuSE 9.1 : i'm not impressed, its a drama"
> > > > > > http://groups.google.com/groups?as_umsgid=pan.2004.07.03.05.05.30.79714@stokkie.net
> > > > > > 
> > > > > > There's a small typo inside and that is that :
> > > > > > 
> > > > > > "Not only did the suse9.1 kernel 2.4.5 ..
> > > > > > 
> > > > > > should read
> > > > > > 
> > > > > > "Not only did the suse9.1 kernel 2.6.5 ..
> > > > > 
> > > > > If you had bothered to read this thread, you'd know that you are the one
> > > > > doing something wrong - cdrecord ATAPI driver should not be used, it
> > > > > does not support DMA in earlier 2.6 (or 2.4) kernels. Use ATA.
> > > > 
> > > > 
> > > > Ok thank you for the swift reply..
> > > > 
> > > > To be honest, the default 2.6.5 kernel from SuSE 9.1 fails anyway to
> > > > switch on DMA on my used DVD-burner. Maybe you can give an advice
> > > > which kernel upgrade to install on SuSE 9.1, in order to get DMA for
> > > > high-speed DVD Burners switched on anyway.
> > > 
> > > Send me the dmesg from the booted system.
> > > 
> > > > Allthough i have heard other people say to use the dev=ATAPI device names, i
> > > > surely will test the above, but then replacing ATAPI with ATA. If this will
> > > > improve performance and stability dramaticly i don't know. However when
> > > > comparing ATAPI to the ATA mechanism :
> > > > ( http://crashrecovery.org/oss-dvd/HOWTO-ossdvd.html )
> > > 
> > > It will, it's much better.
> > > 
> > > > method B:
> > > > ATA Packet specific SCSI transport omitting linux sg transport
> > > > thus using : # cdrecord dev=ATAPI ...
> > > >   Warning: Using ATA Packet interface.
> > > >    Warning: The related libscg interface code is in pre alpha.
> > > >    Warning: There may be fatal problems.
> > > >    Using libscg version 'schily-0.8'.
> > > > 
> > > > method C:
> > > > ATA Packet specific SCSI transport using scsi-linux-sg interface:
> > > > thus using : # cdrecord dev=ATA ..
> > > >    Warning: Using badly designed ATAPI via /dev/hd* interface.
> > > >    Linux sg driver version: 3.5.27
> > > >    Using libscg version 'schily-0.8'.
> > > >    cdrecord: Warning: using inofficial libscg transport code version (schily -
> > > >    Red Hat-scsi-linux-sg.c-1.80-RH '@(#)scsi-linux-sg.c        1.80 04/03/08
> > > >    Copyright 1997 J. Schilling').
> > > > 
> > > > Nothing tells me here that method C is superior to method B :) I tested the
> > > > above already on mandrake 10.0, and with both methods i could succesfully read
> > > > and burn a dvd iso. For SuSE 9.1 I indeed only tested method B. I stopped of
> > > > course, because SuSE 9.1 failed bitterly. So some results are due.
> > > 
> > > You are specifying a specific driver, it wont tell you that it's a bad
> > > choice. You should know better. Don't specify a driver and it'll chose
> > > the right one.
> > 
> > I might as well start burning on Win XP, sorry...
> 
> What does that have to do with it? You complain that it doesn't use DMA
> when you force the ATAPI driver, that's about as close to 'doctor it
> hurts' as it gets. Don't do that, then. If you specify a driver, you
> should know what you are doing. That cdrecord should _not_ include the
> sucky ATAPI driver is a different matter, one that I have no influence
> over.
> 
> Default should work ok, which it does.
> 
Now listen up Jens, i don't do default, i like to know what went
wrong. And if you don't change your tone, your SuSE company of 
grundliche engineerung, should certainly know more about this also.

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Robert M. Stockmann wrote:

> Now listen up Jens, i don't do default, i like to know what went

So instead of using the default which works you choose to select your
own method which does not work. And then you complain, and you don't
do that in alt.os.linux.suse or similar, but in comp.os.linux.advocacy
just telling how you disappointed you are and how much better Mandrake ist.
Sorry man, but this sound very much like a troll trying to start another
"this distribution is better than that one" flame war and not someone
asking for help or technical background information.

> grundliche engineerung

Wow wow, now you better be careful what you say next.

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Robert M. Stockmann]

On Fri, 13 Aug 2004, Frank Steiner wrote:

> Robert M. Stockmann wrote:
> 
> > Now listen up Jens, i don't do default, i like to know what went
> > wrong.
> 
> So instead of using the default which works you choose to select your
> own method which does not work. And then you complain, and you don't
> do that in alt.os.linux.suse or similar, but in comp.os.linux.advocacy
> just telling how you disappointed you are and how much better Mandrake ist.
> Sorry man, but this sound very much like a troll trying to start another
> "this distribution is better than that one" flame war and not someone
> asking for help or technical background information.
> 
> > grundliche engineerung
> 
> Wow wow, now you better be careful what you say next.
> 
care to explain to me why on Mandrake 10.0 i have none of these problems?

regards,

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Fri, Aug 13 2004, Robert M. Stockmann wrote:
> On Fri, 13 Aug 2004, Frank Steiner wrote:
> 
> > Robert M. Stockmann wrote:
> > 
> > > Now listen up Jens, i don't do default, i like to know what went
> > > wrong.
> > 
> > So instead of using the default which works you choose to select your
> > own method which does not work. And then you complain, and you don't
> > do that in alt.os.linux.suse or similar, but in comp.os.linux.advocacy
> > just telling how you disappointed you are and how much better Mandrake ist.
> > Sorry man, but this sound very much like a troll trying to start another
> > "this distribution is better than that one" flame war and not someone
> > asking for help or technical background information.
> > 
> > > grundliche engineerung
> > 
> > Wow wow, now you better be careful what you say next.
> > 
> care to explain to me why on Mandrake 10.0 i have none of these problems?

Well, you are the UNIX/Linux Specialist, you should be able to figure it
out :-)

I asked for your dmesg wrt your dma problem, you never sent it to me. I
cannot help you.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Robert M. Stockmann]

On Fri, 13 Aug 2004, Jens Axboe wrote:

> On Fri, Aug 13 2004, Robert M. Stockmann wrote:
> > On Fri, 13 Aug 2004, Frank Steiner wrote:
> > 
> > > Robert M. Stockmann wrote:
> > > 
> > > > Now listen up Jens, i don't do default, i like to know what went
> > > > wrong.
> > > 
> > > So instead of using the default which works you choose to select your
> > > own method which does not work. And then you complain, and you don't
> > > do that in alt.os.linux.suse or similar, but in comp.os.linux.advocacy
> > > just telling how you disappointed you are and how much better Mandrake ist.
> > > Sorry man, but this sound very much like a troll trying to start another
> > > "this distribution is better than that one" flame war and not someone
> > > asking for help or technical background information.
> > > 
> > > > grundliche engineerung
> > > 
> > > Wow wow, now you better be careful what you say next.
> > > 
> > care to explain to me why on Mandrake 10.0 i have none of these problems?
> 
> Well, you are the UNIX/Linux Specialist, you should be able to figure it
> out :-)
> 
> I asked for your dmesg wrt your dma problem, you never sent it to me. I
> cannot help you.
> 

Maybe you didn't fully understand my problem. What i did was the 
following. I downloaded cdrtools-2.01a27.tar.bz2 from 

ftp://ftp.berlios.de/pub/cdrecord/alpha/

and only applied this patch cdrtools-2.01a27-ossdvd.patch.bz2 from

ftp://ftp.crashrecovery.org/pub/linux/cdrtools/

The binary results runs rather poor after building it on SuSE 9.1. while
the same exercise on mandrake 10.0 gives good results :

================================================================
From: Robert M. Stockmann (stock@stokkie.net)
Subject: SuSE 9.1 : i'm not impressed, its a drama 
View: Complete Thread (2 articles) 
Newsgroups: comp.os.linux.advocacy
Date: 2004-07-02 22:05:53 PST

Hi,

Well here's my findings of facts :

the machine : a compaq proliant 800 2x PIII 500MHz/512kb (Katmai)
              128 Mb RAM, 2x 9.1Gb U2W SCSI
              _NEC DVD_RW ND-2510A Dual Layer burner

i installed a vanilla suse9.1, and tried to read a 4.5Gb dvd isoimage
to disk using the command :

# readcd -v dev=ATAPI:0,0,0 f=dvdimage.iso

and afterwards try to  burn it to a dvd-r recordable using this command:

# cdrecord -v dev=ATAPI:0,0,0 driveropts=burnfree -dao dvdimage.iso

Not only did the suse9.1 kernel 2.4.5 _NOT_ switch on DMA on that burner
,it was terrible SLOW, i got only 2Mbytes/sec. On a different machine a
dual xeon machine with 1024Mb RAM, suse91 even failed to read the dvd
iso image, always failing at the moment 1024Mb physical was getting 100%
into use. The readcd process then locks hard , and one cannot kill it.
When the readcd command was running, one was not able to operate the
SuSE91 machine interactively in a normal fashion. Apparently the reiserfs
root filesystem doesn't like a single huge file of 4.5Gb being written
onto. 

This behaviour reminds me closely of SCO OpenServer 5.0.x where making a
backup on tape, renders the application software not usable.

Apparently the virtual memory management behaviour of SuSE9.1 was
seriously lacking. Actually so bad, that my only conclusion is that
the SuSE 9.1 kernel is seriously broken. 

To put this to the test i installed on the same proliant 800, Mandrake
10.0. And not only does the Mandrake kernel switch on DMA on the NEC 2510A
Dual Layer burner, it reads the 4.5 Gb dvd iso image at a speed of 7.7
Mbytes/sec. That is on the same machine but only installing mandrake 10.0
instead of suse91. I used these RPMS for Mandrake 10.0 :

http://crashrecovery.org/oss-dvd/RPMS/mdk100/

Burning went at normal speed hovering between 6x to 8x .

I am so bitterly disappointed at SuSE9.1 , that for some time I was
thinking if Novell uses this SuSE disaster edition (9.1) as a way to
discredit Linux. This of course can not be the case.. Anyway, as of now i
dropped all SuSE related stuff and papertrail attached, as i simply cannot
take such a drama seriously. 

regards,

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net
================================================================

As to the DMA settings right after booting SuSE9.1 : Either DMA is 
switched on or not. No single userland application like cdrecord or
readcd is going to change that.

So my conclusion : vanilla cdrtools-2.01a27.tar.bz2 with my OSS DVD
Extensions patch cdrtools-2.01a27-ossdvd.patch.bz2 applied does not
work ok on SuSE9.1. That shouldn't imply that the cdrecord RPM from 
which comes with SuSE9.1 does _not_ work. However unfortunately i'm 
a hard headed asshole which only uses his own "moonshine" goodies, 
which of course are Open Source, and hopefully well documented for
other people to share with. 

What strikes me here however, is that Jörg Schilling also had his share
of unexpected unusual problems with the SuSE developers :

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0408.1/0736.html

regards,

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Robert M. Stockmann wrote:

> Maybe you didn't fully understand my problem. What i did was the 
> following. I downloaded cdrtools-2.01a27.tar.bz2 from 
> 
> ftp://ftp.berlios.de/pub/cdrecord/alpha/
> 
> and only applied this patch cdrtools-2.01a27-ossdvd.patch.bz2 from
> 
> ftp://ftp.crashrecovery.org/pub/linux/cdrtools/

And the question is: why??? SuSE comes with a cdrtools version that runs
fine. No need to download anything from an external source. Just installing
the cdrtools package from SuSE and calling "cdrecord dev=/dev/hdc ..."
works without any problems here.

You are complaining here that using some external package as replacement
for the SuSE version and additionally forcing a setting other than the
default does not work, even after a SuSE developer told you not to do
that because there are known problems with the setting you are forcing.

So what are you asking for? I guess I can find a bunch of programs that
I download from anywhere and that are not working with some distributions.
The idea of a distribution is that the packagers take care that the packages
they deliver work together. Replacing some piece with your own version
and then complaining that it does not work doesn't make any sense.
This is like replacing the "eject" on SuSE 9.1 which has been patched
to work with subfs and then complaining that your own "eject" does not
work with subfs on SuSE 9.1.

Frank


-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Fri, Aug 13 2004, Robert M. Stockmann wrote:
> On Thu, 12 Aug 2004, Jens Axboe wrote:
> 
> > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > 
> > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > > > 
> > > > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > > > On Thu, 12 Aug 2004, Frank Steiner wrote:
> > > > > > > 
> > > > > > > > Robert M. Stockmann wrote:
> > > > > > > > 
> > > > > > > > > i must agree here that getting cdrecord/cdrtools-2.0x going on the latest
> > > > > > > > > SuSE 9.x editions has been extremely tiresome. 
> > > > > > > > 
> > > > > > > > Because of what? We are running the cdrecord versions that SuSE
> > > > > > > > shipped with 9.0 and 9.1, and there hasn't been a single problem
> > > > > > > > for over 8 months now with three different cd and dvd burners.
> > > > > > > > So where's the problem?
> > > > > > > 
> > > > > > > I posted this on comp.os.linux.advocacy some time ago :
> > > > > > > 
> > > > > > > "SuSE 9.1 : i'm not impressed, its a drama"
> > > > > > > http://groups.google.com/groups?as_umsgid=pan.2004.07.03.05.05.30.79714@stokkie.net
> > > > > > > 
> > > > > > > There's a small typo inside and that is that :
> > > > > > > 
> > > > > > > "Not only did the suse9.1 kernel 2.4.5 ..
> > > > > > > 
> > > > > > > should read
> > > > > > > 
> > > > > > > "Not only did the suse9.1 kernel 2.6.5 ..
> > > > > > 
> > > > > > If you had bothered to read this thread, you'd know that you are the one
> > > > > > doing something wrong - cdrecord ATAPI driver should not be used, it
> > > > > > does not support DMA in earlier 2.6 (or 2.4) kernels. Use ATA.
> > > > > 
> > > > > 
> > > > > Ok thank you for the swift reply..
> > > > > 
> > > > > To be honest, the default 2.6.5 kernel from SuSE 9.1 fails anyway to
> > > > > switch on DMA on my used DVD-burner. Maybe you can give an advice
> > > > > which kernel upgrade to install on SuSE 9.1, in order to get DMA for
> > > > > high-speed DVD Burners switched on anyway.
> > > > 
> > > > Send me the dmesg from the booted system.
> > > > 
> > > > > Allthough i have heard other people say to use the dev=ATAPI device names, i
> > > > > surely will test the above, but then replacing ATAPI with ATA. If this will
> > > > > improve performance and stability dramaticly i don't know. However when
> > > > > comparing ATAPI to the ATA mechanism :
> > > > > ( http://crashrecovery.org/oss-dvd/HOWTO-ossdvd.html )
> > > > 
> > > > It will, it's much better.
> > > > 
> > > > > method B:
> > > > > ATA Packet specific SCSI transport omitting linux sg transport
> > > > > thus using : # cdrecord dev=ATAPI ...
> > > > >   Warning: Using ATA Packet interface.
> > > > >    Warning: The related libscg interface code is in pre alpha.
> > > > >    Warning: There may be fatal problems.
> > > > >    Using libscg version 'schily-0.8'.
> > > > > 
> > > > > method C:
> > > > > ATA Packet specific SCSI transport using scsi-linux-sg interface:
> > > > > thus using : # cdrecord dev=ATA ..
> > > > >    Warning: Using badly designed ATAPI via /dev/hd* interface.
> > > > >    Linux sg driver version: 3.5.27
> > > > >    Using libscg version 'schily-0.8'.
> > > > >    cdrecord: Warning: using inofficial libscg transport code version (schily -
> > > > >    Red Hat-scsi-linux-sg.c-1.80-RH '@(#)scsi-linux-sg.c        1.80 04/03/08
> > > > >    Copyright 1997 J. Schilling').
> > > > > 
> > > > > Nothing tells me here that method C is superior to method B :) I tested the
> > > > > above already on mandrake 10.0, and with both methods i could succesfully read
> > > > > and burn a dvd iso. For SuSE 9.1 I indeed only tested method B. I stopped of
> > > > > course, because SuSE 9.1 failed bitterly. So some results are due.
> > > > 
> > > > You are specifying a specific driver, it wont tell you that it's a bad
> > > > choice. You should know better. Don't specify a driver and it'll chose
> > > > the right one.
> > > 
> > > I might as well start burning on Win XP, sorry...
> > 
> > What does that have to do with it? You complain that it doesn't use DMA
> > when you force the ATAPI driver, that's about as close to 'doctor it
> > hurts' as it gets. Don't do that, then. If you specify a driver, you
> > should know what you are doing. That cdrecord should _not_ include the
> > sucky ATAPI driver is a different matter, one that I have no influence
> > over.
> > 
> > Default should work ok, which it does.
> > 
> Now listen up Jens, i don't do default, i like to know what went
> wrong. And if you don't change your tone, your SuSE company of 
> grundliche engineerung, should certainly know more about this also.

So read the thread, it's been explained there several times. It's how
the whole thread started.

The case in a nutshell is that you say you use force for ATAPI driver
and burning runs slow because it doesn't use DMA. So I tell you that you
should not use the ATAPI driver, exactly _because it doesn't use DMA_. I
go on to say that if you don't know what you are doing, why are you
forcing the ATAPI driver? So now you tell me you don't do default, what
on earth does that mean? You're to elite to use the default? If you
force something else than the default you're expected to know what you
are doing, end of story.

And read up on netiquette, it's bad style to cc a public list on a
private mail. I find nothing in the above mail that's insulting to you
from my side, all I see is that you are refusing to listen to why you
had problems with DMA burning.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Fri, 13 Aug 2004 04:39:46 +0200 (CEST), Robert M. Stockmann
<stock@stokkie.net> wrote:
> On Thu, 12 Aug 2004, Jens Axboe wrote:
> 
> > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > >
> > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > > >
> > > > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > > > On Thu, 12 Aug 2004, Frank Steiner wrote:
> > > > > > >
> > > > > > > > Robert M. Stockmann wrote:

Have you ever heard of trimming replies?

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Robert M. Stockmann]

On Mon, 16 Aug 2004, Patrick McFarland wrote:

> On Fri, 13 Aug 2004 04:39:46 +0200 (CEST), Robert M. Stockmann
> <stock@stokkie.net> wrote:
> > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > 
> > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > >
> > > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > > > >
> > > > > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > > > > On Thu, 12 Aug 2004, Frank Steiner wrote:
> > > > > > > >
> > > > > > > > > Robert M. Stockmann wrote:
> 
> Have you ever heard of trimming replies?
> 
> 
Yes i do, in important matters, i explicit do not.

regards,

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Mon, 16 Aug 2004 14:47:00 +0200 (CEST), Robert M. Stockmann
<stock@stokkie.net> wrote:
> On Mon, 16 Aug 2004, Patrick McFarland wrote:
> 
> > On Fri, 13 Aug 2004 04:39:46 +0200 (CEST), Robert M. Stockmann
> > <stock@stokkie.net> wrote:
> > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > >
> > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > > >
> > > > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > > > > >
> > > > > > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > > > > > On Thu, 12 Aug 2004, Frank Steiner wrote:
> > > > > > > > >
> > > > > > > > > > Robert M. Stockmann wrote:
> >
> > Have you ever heard of trimming replies?
> >
> > 
> Yes i do, in important matters, i explicit do not.

Flaming Mr. Axboe in public is important?

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1337

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Robert M. Stockmann]

On Mon, 16 Aug 2004, Patrick McFarland wrote:

> On Mon, 16 Aug 2004 14:47:00 +0200 (CEST), Robert M. Stockmann
> <stock@stokkie.net> wrote:
> > On Mon, 16 Aug 2004, Patrick McFarland wrote:
> > 
> > > On Fri, 13 Aug 2004 04:39:46 +0200 (CEST), Robert M. Stockmann
> > > <stock@stokkie.net> wrote:
> > > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > >
> > > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > > > >
> > > > > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > > > > On Thu, 12 Aug 2004, Jens Axboe wrote:
> > > > > > > >
> > > > > > > > > On Thu, Aug 12 2004, Robert M. Stockmann wrote:
> > > > > > > > > > On Thu, 12 Aug 2004, Frank Steiner wrote:
> > > > > > > > > >
> > > > > > > > > > > Robert M. Stockmann wrote:
> > >
> > > Have you ever heard of trimming replies?
> > >
> > > 
> > Yes i do, in important matters, i explicit do not.
> 
> Flaming Mr. Axboe in public is important?
> 

I was surprised to see a SuSE developer advise me to just do the
auto/auto thingy and _hope_ for the best, concerning burning a DVD-R.

I would like to emphasise, its Open Source what we are discussing here!

thanks,
best regards,

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Kyle Moffett]

On Aug 16, 2004, at 09:32, Robert M. Stockmann wrote:
> I was surprised to see a SuSE developer advise me to just do the
> auto/auto thingy and _hope_ for the best, concerning burning a DVD-R.
>
> I would like to emphasise, its Open Source what we are discussing here!

Exactly! If you don't have anything useful to contribute WRT tracking 
down
a bug or fixing it, then you are expected to quit wasting the time of 
those
who _do_ have useful information/skills/etc. Jens Axboe has _repeatedly_
asked you for your dmesg so he can determine if it's a bug or not, and 
you
have _repeatedly_ ignored his emails.  Either give us enough information
to identify and fix the issue (if any), or shut up and let Jens Axboe 
work with
people who are willing to provide all necessary information.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Robert M. Stockmann]

On Tue, 17 Aug 2004, Kyle Moffett wrote:

> On Aug 16, 2004, at 09:32, Robert M. Stockmann wrote:
> > I was surprised to see a SuSE developer advise me to just do the
> > auto/auto thingy and _hope_ for the best, concerning burning a DVD-R.
> >
> > I would like to emphasise, its Open Source what we are discussing here!
> 
> Exactly! If you don't have anything useful to contribute WRT tracking 
> down
> a bug or fixing it, then you are expected to quit wasting the time of 
> those
> who _do_ have useful information/skills/etc. Jens Axboe has _repeatedly_
> asked you for your dmesg so he can determine if it's a bug or not, and 
> you
> have _repeatedly_ ignored his emails.  Either give us enough information
> to identify and fix the issue (if any), or shut up and let Jens Axboe 
> work with
> people who are willing to provide all necessary information.
> 
> Cheers,
> Kyle Moffett

I have had many disappointing try-outs with SuSE in the past, and everytime
when i think, this SuSE version is the one which will have my iron running
at warp 12, it fails again, for me that is. Dunno why that is.

The only thing i mentioned is, that i noticed that the compaq proliant 800,
2x PIII 500 had problems switching on DMA when booting the the default
installed kernel, 2.6.5 from SuSE 9.1 , after a vanilla default installation.

So i may turn the question around : Is SuSE's techsupport or development
dep. aware that there are issue's reported about DMA failing to switch on
when dealing with UDMA DVD writers? As to the machine, the compaq proliant
800 : its already sold, and sadly doesn't run the SuSE linux version.

Cheers,

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Eric Lammerts]

On Wed, 18 Aug 2004, Robert M. Stockmann wrote:
> On Tue, 17 Aug 2004, Kyle Moffett wrote:
> > Jens Axboe has _repeatedly_ asked you for your dmesg so he can
> > determine if it's a bug or not, and you have _repeatedly_ ignored
> > his emails.  Either give us enough information to identify and fix
> > the issue (if any), or shut up
>
> So i may turn the question around : Is SuSE's techsupport or development
> dep. aware that there are issue's reported about DMA failing to switch on
> when dealing with UDMA DVD writers?

-ENODMESG

Eric

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Robert M. Stockmann]

On Wed, 18 Aug 2004, Eric Lammerts wrote:

> 
> On Wed, 18 Aug 2004, Robert M. Stockmann wrote:
> > On Tue, 17 Aug 2004, Kyle Moffett wrote:
> > > Jens Axboe has _repeatedly_ asked you for your dmesg so he can
> > > determine if it's a bug or not, and you have _repeatedly_ ignored
> > > his emails.  Either give us enough information to identify and fix
> > > the issue (if any), or shut up
> >
> > So i may turn the question around : Is SuSE's techsupport or development
> > dep. aware that there are issue's reported about DMA failing to switch on
> > when dealing with UDMA DVD writers?
> 
> -ENODMESG
> 

Well sorry about that, the machine is not in my possesion anymore. But again,
i produced enough info to be able to reproduce the error :

machine : compaq proliant 800 2x PIII 500MHz/512kb (Katmai)
	128 Mb RAM, 2x 9.1Gb U2W SCSI
	_NEC DVD_RW ND-2510A Dual Layer burner

OS : 	SuSE 9.1 i386  default vanilla installation

burning software : cdrtools-2.01a27.tar.bz2 from
			ftp://ftp.berlios.de/pub/cdrecord/alpha/
	with this patch : cdrtools-2.01a27-ossdvd.patch.bz2 from
			ftp://ftp.crashrecovery.org/pub/linux/cdrtools/

read command : 

   # readcd -v dev=ATAPI:0,0,0 f=dvdimage.iso

write command : 

   # cdrecord -v dev=ATAPI:0,0,0 driveropts=burnfree -dao dvdimage.iso

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Robert M. Stockmann wrote:

> Well sorry about that, the machine is not in my possesion anymore. 

Oh please! You are complaining, accusing and flaming SuSE for they
are shipping a cdrecord version that is not working on one single
machine (since you cannot reproduce it yourself on another machine
now to give a dmesg output, it must be very machine-specific...)
after you have forced cdrecord to use some special mode instead
of using the SuSE default.
After Jens told you that this special mode does not work well with
earlier 2.6 kernels and that the default mode SuSE selects when you
don't override it would work without exactly the problem you are
creating by overriding the mode, you still keep complaining. And
when you are asked for further info so that people can help you
the machine is not in you posession anymore.

*cough* *cough*

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Robert M. Stockmann]

On Tue, 10 Aug 2004, Joerg Schilling wrote 

> As the people who did create the bastardized version of cdrecord
> you are using did not make clear where the official defaults file
> for cdrecord is located, they did violate the license of cdrecord.
>  
> It really does mot make fun to see useless forks for software including
> only modifications that do not give you a single advantage over the original.
>  
> The license used with cdrecord allows people to make modifications and to 
> rediustribute the versions. 
>  
> Not a single modification from one of the Linux distribution I did see so far
> did introduce any advantage over the original.
>  
> I would love to see cooperations (and there is cooperation with people from 
> many places), but the big Linux distributors all fail to cooperate :-(
>  
> Look into the mkisofs source, I even needed to include a comment in hope to
> prevent people from SuSE to convert legal and correct C code into a broken
> piece of code just because they modify things they don't understand :-(
>  
> Jörg

Hello Jörg,

i must agree here that getting cdrecord/cdrtools-2.0x going on the latest
SuSE 9.x editions has been extremely tiresome. Can it not be the case that
this has something todo with SuSE's inheritance to the UnitedLinux project?

I would like to suggest and kindly propose to maybe start cooperating
with Warly from MandrakeSoft. I think he has done a fine job sofar
in the latest Mandrake editions, 9.2 and 10.0 , making your cdrtools-2.0x
software run like it should. Warly is even by you mentioned as the only
one not violating your GPL licensed cdrtools package.

His efforts to get DVD burning rolling can be found at : 

http://people.mandrakesoft.com/~warly/files/cdrtools/
 
thanks,
best regards,

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Robert M. Stockmann wrote:

> i must agree here that getting cdrecord/cdrtools-2.0x going on the latest
> SuSE 9.x editions has been extremely tiresome. 

Because of what? We are running the cdrecord versions that SuSE
shipped with 9.0 and 9.1, and there hasn't been a single problem
for over 8 months now with three different cd and dvd burners.
So where's the problem?

Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Robert M. Stockmann]

On Thu, 12 Aug 2004, Frank Steiner wrote:

> Robert M. Stockmann wrote:
> 
> > i must agree here that getting cdrecord/cdrtools-2.0x going on the latest
> > SuSE 9.x editions has been extremely tiresome. 
> 
> Because of what? We are running the cdrecord versions that SuSE
> shipped with 9.0 and 9.1, and there hasn't been a single problem
> for over 8 months now with three different cd and dvd burners.
> So where's the problem?

I posted this on comp.os.linux.advocacy some time ago :

"SuSE 9.1 : i'm not impressed, its a drama"
http://groups.google.com/groups?as_umsgid=pan.2004.07.03.05.05.30.79714@stokkie.net

There's a small typo inside and that is that :

"Not only did the suse9.1 kernel 2.4.5 ..

should read

"Not only did the suse9.1 kernel 2.6.5 ..


Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Robert M. Stockmann wrote:
> On Thu, 12 Aug 2004, Frank Steiner wrote:

> I posted this on comp.os.linux.advocacy some time ago :
> 
> "SuSE 9.1 : i'm not impressed, its a drama"
> http://groups.google.com/groups?as_umsgid=pan.2004.07.03.05.05.30.79714@stokkie.net
> 
> There's a small typo inside and that is that :
> 
> "Not only did the suse9.1 kernel 2.4.5 ..
> 
> should read
> 
> "Not only did the suse9.1 kernel 2.6.5 ..

I can't reproduce any of the problems you described there on our SuSE 9.1
hosts... Everything runs fine here,no matter if we use the command line
or xcdroast. Must be sth. special to your hardware.
Of course, the 2.6.5 kernel is already old in generel, so I guess you
should have checked a newer kernel.
And when you only use the command line anyway, I guess you checked the
dvd+rw-tools that SuSE ships with 9.1 before being "bitterly disappointed
at SuSE 9.1" :-) Note that you need the version from their update directory
to run with subfs, but this versions indeed runs fine.

cu,
Frank
-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Robert M. Stockmann]

On Wed, 04 Aug 2004, H.Rosmanith wrote:

> hi,
>  
> I've written a patch for cdrecord/cdrtools. I've sent it to Joerg Schilling
> already, but got no answer so far. Probably he's on vaccation.
>  
> I'm sending this to LKML too, because I've read about some ... nebulosity
> with respect to scsi device numbering as used by cdrtools.
>  
> To cut a long story short: the patch avoids cdrecord having to use the
> "virtual" scsi device numbering in the form of "ATAPI:x.y.z" and allows
> you to use the name of the device, e.g. /dev/hdc instead.
>  
> By removing the IDE to virtual scsi bus/host/lun mapping, a lot of confusion
> can be avoided especially if you have a lot devices of this kind in one
> system.
>  
> with kind regards,
> Herbert "herp" Rosmanith
>  
> Version: cdrtools-2.01a34
>  
> Solution: when the device specified in dev= starts with "/dev/hd" and
> this device can be found in /proc/ide, then cdrecord (and all
> it's components, such as e.g. cdrdao) is forced to use the
> ATAPI driver.
>  
> The patch is really very short and works at least on our system.
>  
> with kind regards,
> Herbert Rosmanith

Its indeed not straight forward to use cdrtools-2.0x together with
kernel 2.6.x . As an aid for the user, i wrote a small HOWTO for using 
cdrtools together with kernel 2.6, with special focus on retrieval
of which device names to use. The small HOWTO can be found on :

http://crashrecovery.org/oss-dvd/HOWTO-ossdvd.html

regards,

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Andre Tomt]

Robert M. Stockmann wrote:
> Its indeed not straight forward to use cdrtools-2.0x together with
> kernel 2.6.x . As an aid for the user, i wrote a small HOWTO for using 
> cdrtools together with kernel 2.6, with special focus on retrieval
> of which device names to use. The small HOWTO can be found on :
> 
> http://crashrecovery.org/oss-dvd/HOWTO-ossdvd.html

Whats not straight forward with dev=/dev/device-of-cdr ?

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Tomasz Torcz]

On Thu, Aug 12, 2004 at 03:57:38AM +0200, Robert M. Stockmann wrote:
> Its indeed not straight forward to use cdrtools-2.0x together with
> kernel 2.6.x . As an aid for the user, i wrote a small HOWTO for using 
> cdrtools together with kernel 2.6, with special focus on retrieval
> of which device names to use. The small HOWTO can be found on :
> http://crashrecovery.org/oss-dvd/HOWTO-ossdvd.html


 Why it's not easy? I've compiled cdrecord from source dozen times
without problems, have used it with 2.4/2.5/2.6 kernels and never
had any problem.

 My /etc/defaults/cdrecord is:

#v+
CDR_FIFOSIZE=6m
CDR_SPEED=8
CDR_DEVICE=/dev/hdc
#v-

 And works fine with my
hdc: 8X4X32, ATAPI CD/DVD-ROM drive
hdc: ATAPI 32X CD-ROM CD-R/RW drive, 8192kB Cache, DMA

 It seams that people don't have problems, but they create problems
for themselves.

-- 
Tomasz Torcz            There exists no separation between gods and men:
zdzichu@irc.-nie.spam-.pl   one blends softly casual into the other. 

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]


>From root@chaos.analogic.com  Tue Aug 10 18:07:24 2004

>Sorry to break into this wonderful conversation, but it seems
>I have all the actors corralled in one place.

>The fascist US government forced 321software out-of-business. It
>was a company that provided software that could copy DVDs.

cdrtools do not have the problem as they do not include everything you need in 
order to copy CSS DVDs. Cdrtools however allow you to create UDF images from
DVD file trees and to write the UDF images to a DVD.

If ever, I believe that deCSS could be problematic although I believe that it 
may still be distributed from European sites.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4255 bytes --]


>From axboe@suse.de  Tue Aug 10 20:49:03 2004

>Ehm yes, aren't you contradicting yourself? Here's the mail I'm
>referring to:

I don't - I have a clean and orthogonal idea for useful interfacew. As I did 
already tell, your patch did not enhance cdrecord but rather tries to remove 
useful warnings.

If you however would ever send any patch that would _really_
increase the features of cdrtools, there is a big chance that it will be 
included.

Here is what I did send as reply. It verifies that I am really taking you for 
serious and did send you a serious reply.

/*--------------------------------------------------------------------------*/
>From joerg Tue Jan 13 16:29:42 2004
To: axboe@suse.de
Subject: Re: open by devname

>From axboe@suse.de  Mon Jan 12 16:50:19 2004


>With 2.6 and SG_IO for generic block devices, it's pretty annoying and
>confusing to users that cdrecord outputs:

>"Open by 'devname' is unintentional and not supported."

The reason is to tell people that they are going to use an annoying
interface that is not really needed and that breaks the SCSI protocol layering.

In addition, it tells users that there may be problems because the Linux 
kernel folks did not include correct ioctl interfaces for

ioctl(f, SCSI_IOCTL_GET_IDLUN, &sg_id)

ioctl(f, SCSI_IOCTL_GET_BUS_NUMBER, &Bus)

and

ioctl(scgp->fd, SG_EMULATED_HOST, &emulated)

but just implemented dummies that may cause problems.

>This leads them to think they did something wrong, which they really
>didn't. Any chance you could be talked into taking that message out?

Sorry no, because what you wrote is only halfway correct.

They are forced to use something inherently wrong because the Linux kernel
now includes another SCSI interface that is not needed. Note that the
efforts that have ben put into writing this piece of code should have better
be put into writing an orthogonal DMA access interface and fixing the
DMA problems that cause DMA sizes % 512 != 0 to disable DMA for _all_ devices
and _all_ interfaces provided by the kernel.

Open by devname definitly breaks clean protocol layering on a OS
where you already have a generic SCSI transport interface like Linux has
with /dev/sg*

The  vanilla way to go is to run cdrecord -scanbus and then 
use one of the listed devices. 

ATAPI is SCSI over ATA transport and there are a lot of different official 
SCSI transport media. 

ide-scsi is not the best possible solution, but it definitely fits much better
into a  clean layering model than what Linux Torvalds likes to 
enforce (note that he doesn't own any CD writer so he is definitely unable 
to even judge about the problems). 

I really hope that Jeff Garzik continues to implement his clean way of dealing 
with ATAPI devices and that the ugly /dev/hd* based SCSI interface is becoming
obsolete soon.

libscg does not offer a service that is at the layering level that 
the /dev/hd* driver provides.

libscg instead offers a service that is just below the service of 
the /dev/hd* driver. 

It makes no sense to use naming schemes made for high level device  
acces for low level tasks like SCSI command transport. 

Libscg provides an interface for the mid level SCSI transport.
This protocol level is _above_ the Hostadaptordriver where transport
specific things are handled. It is _below_ the Blockdevice layer
where hard disk, CD-ROM and Tape specifics are handled. Libscg provides
just the protocol layer that is used by the lower end of the block device
drivers. It is inapropriate to use a naming scheme that applies to a higher
protocol layer that is not used by libscg. 

Forcing users to be unable to list all devices that use the SCSI protocol
in a single name space is just a bad idea.

As kernels usually use instance numbers for internal purposes, it is obvious
to use just something similar to implement the name space for libscg.
 
/*--------------------------------------------------------------------------*/


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]

>From: Stephan von Krawczynski <skraw@ithnet.com>

>On Tue, 10 Aug 2004 18:10:57 +0200
>Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:

>> Actually, I use Debian since, um, long ago:)  But accept that Jörg
>> doesn't really like to care about f*cked up patched versions of
>> cdrecord.

>He does not need to. Nobody told him to do.
>Besides I doubt that only the patched versions are actually "f*cked up".
>My personal experience with cdrecord is that neither version works well on my
>system.

As you did not mention which writer and wich OS you are talking, it is hard to 
tell anything about the reasons.

If you like to write DVDs, you of course need cdrecord-ProDVD

ftp://ftp.berlios.de/pub/cdrecord/ProDVD/

I am trying my best so support any DVD writer since 1997

Note that there is no DVD support in the GPLd cdrecord and if you use the 
original version, you will get hints leading you to cdrecord-ProDVD.

Also note that I don't like to feed trolls, so I don't like to discuss
cdrecord-ProDVD here and I will not answer related questions - they are all
answered in the documentation. Cdrecord-ProDVD is free for personal use and 
this will not change in the future.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Tue, 10 Aug 2004 23:33:10 +0200 (CEST)
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> >From: Stephan von Krawczynski <skraw@ithnet.com>
> 
> >On Tue, 10 Aug 2004 18:10:57 +0200
> >Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> 
> >> Actually, I use Debian since, um, long ago:)  But accept that Jörg
> >> doesn't really like to care about f*cked up patched versions of
> >> cdrecord.
> 
> >He does not need to. Nobody told him to do.
> >Besides I doubt that only the patched versions are actually "f*cked up".
> >My personal experience with cdrecord is that neither version works well on my
> >system.

> [a lot of advertising deleted by Joerg deleted]

Nobody besides you talked about that product.

Regards,
Stephan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Brian Beattie]

On Tue, 2004-08-10 at 17:33, Joerg Schilling wrote:

> 
> If you like to write DVDs, you of course need cdrecord-ProDVD
> 
> ftp://ftp.berlios.de/pub/cdrecord/ProDVD/
> 
> I am trying my best so support any DVD writer since 1997

Does this product properly support OS prefered naming?  i.e.
/dev/hd?|/dev/sg? on Linux, X: on Windows?

-- 
Brian Beattie   LFS12947 | "Honor isn't about making the right choices.
beattie@beattie-home.net | It's about dealing with the consequences."
www.beattie-home.net     | -- Midori Koto

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

>From skraw@ithnet.com  Tue Aug 10 17:48:20 2004

>Sometimes forking is unavoidable and necessary. On Joergs side things are
>pretty easy. All he has to tell the people is that according to the version
>spec they sent he refuses to help them, because they use a forked version.
>The true story behind may be that nobody wants to use his version for certain
>pecularities and that therefore merely no feedback is reaching him (any more).

The true story is that I constantly send out such messages and that the people 
are happy after they did upgrade to a non broken original version.

The problem behind this true story is that the number of people having problems
with unnecessarily broken versions from the distro's is far too high.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

>From: Jens Axboe <axboe@suse.de>

>Don't be naive. How do you discuss changes with him? The one patch I did
>create against the SUSE cdrecord for the one shipped with SL9.1 adds a
>note to use ATA over ATAPI since that is preferred, and it kills the
>silly open-by-devname warnings that are extremely confusing to users. I
>did send that back to Joerg, to no avail.

You never send such mail.... but you told me that that you liked me to
_remove_ warnings. 
Note that I also output warnings on Solaris if users use suboptimal interfaces.



>> While they (and any other distro's people and anybody else) may
>> actually hack the code to no end, I consider it being good habit to

>By far the largest modification is dvd support, which we of course need
>to ship. The rest is really minor stuff.

This "dvd support" has beed proved to be defective and it has also been proved
that it breaks CD support.

You don't like to see cdrecord to become worse do you?


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Richard B. Johnson]

Sorry to break into this wonderful conversation, but it seems
I have all the actors corralled in one place.

The fascist US government forced 321software out-of-business. It
was a company that provided software that could copy DVDs.

Does any of the DVD software that you people provide have potential
problems along this line? If so, this is something that should
be addressed, perhaps instead of whether or not the Linux software
opens a "device" or not.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Tue, 10 Aug 2004 12:05:23 -0400 (EDT), Richard B. Johnson
<root@chaos.analogic.com> wrote:
> 
> Sorry to break into this wonderful conversation, but it seems
> I have all the actors corralled in one place.
> 
> The fascist US government forced 321software out-of-business. It
> was a company that provided software that could copy DVDs.

If you're saying that they'll sue us (us as in authors of "evil"
software), then I doubt they will, simply for one reason. MPAA
proponents aren't smart enough to use Linux.

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Tue, Aug 10 2004, Joerg Schilling wrote:
> >From: Jens Axboe <axboe@suse.de>
> 
> >Don't be naive. How do you discuss changes with him? The one patch I did
> >create against the SUSE cdrecord for the one shipped with SL9.1 adds a
> >note to use ATA over ATAPI since that is preferred, and it kills the
> >silly open-by-devname warnings that are extremely confusing to users. I
> >did send that back to Joerg, to no avail.
> 
> You never send such mail.... but you told me that that you liked me to
> _remove_ warnings.  Note that I also output warnings on Solaris if
> users use suboptimal interfaces.

Ehm yes, aren't you contradicting yourself? Here's the mail I'm
referring to:

From: Jens Axboe <axboe@suse.de>
Date: Mon, 12 Jan 2004 16:50:16 +0100
To: schilling@fokus.fraunhofer.de
Subject: open by devname

[-- Attachment #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 0.3K --]

Hi Joerg,

With 2.6 and SG_IO for generic block devices, it's pretty annoying and
confusing to users that cdrecord outputs:

"Open by 'devname' is unintentional and not supported."

This leads them to think they did something wrong, which they really
didn't. Any chance you could be talked into taking that message out?

--------

Nothing fruitful came of it, so patch stayed in the SUSE rpm.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]


>From: David Woodhouse <dwmw2@infradead.org>
>> Look into the mkisofs source, I even needed to include a comment in hope to
>> prevent people from SuSE to convert legal and correct C code into a broken
>> piece of code just because  they modify things they don't understand :-(

>Funny that; they _all_ fail to co-operate, even though they all manage
>to co-operate with most other upstream authors. It's probably best that

Looks like you never asked other Authors :-(

I received complaints about similat problem to the one I have from the author
of xcdroast.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Tue, 10 Aug 2004 17:28:04 +0200 (CEST)
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> 
> >From: David Woodhouse <dwmw2@infradead.org>
> >> Look into the mkisofs source, I even needed to include a comment in hope
> >to> prevent people from SuSE to convert legal and correct C code into a
> >broken> piece of code just because  they modify things they don't understand
> >:-(
> 
> >Funny that; they _all_ fail to co-operate, even though they all manage
> >to co-operate with most other upstream authors. It's probably best that
> 
> Looks like you never asked other Authors :-(
> 
> I received complaints about similat problem to the one I have from the author
> of xcdroast.

Ohh, real great mention!
That is the guy that refuses to include minimum support for other burning tools
(i.e. not cdrecord) into his application, right? Great for him, and a good
reason to use k3b instead.

Regards,
Stephan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]


>From: David Woodhouse <dwmw2@infradead.org>

>On Tue, 2004-08-10 at 15:03 +0200, Joerg Schilling wrote:
>> It seems that you like to constantly discredit yourself :-(

>I think people stopped counting the credits a long time ago.

>> What you use if DEFINITELY NOT cdrecord.

>You argue about nomenclature. What I have definitely calls itself
>cdrecord and is definitely based on your code.

As the people who did create the bastardized version of cdrecord
you are using did not make clear where the official defaults file
for cdrecord is located, they did violate the license of cdrecord.

It really does mot make fun to see useless forks for software including
only modifications that do not give you a single advantage over the original.

The license used with cdrecord allows people to make modifications and to 
rediustribute the versions. 

Not a single modification from one of the Linux distribution I did see so far
did introduce any advantage over the original.

I would love to see cooperations (and there is cooperation with people from 
many places), but the big Linux distributors all fail to cooperate :-(

Look into the mkisofs source, I even needed to include a comment in hope to
prevent people from SuSE to convert legal and correct C code into a broken
piece of code just because  they modify things they don't understand :-(

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Tue, 2004-08-10 at 17:15 +0200, Joerg Schilling wrote:
> I would love to see cooperations (and there is cooperation with people from 
> many places), but the big Linux distributors all fail to cooperate :-(
> 
> Look into the mkisofs source, I even needed to include a comment in hope to
> prevent people from SuSE to convert legal and correct C code into a broken
> piece of code just because  they modify things they don't understand :-(

Funny that; they _all_ fail to co-operate, even though they all manage
to co-operate with most other upstream authors. It's probably best that
they take a fork and go their own way then -- all the Linux distributors
and FreeBSD together, so that they don't bother you in your own little
world any more.

> Jrg

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> As the people who did create the bastardized version of cdrecord
> you are using did not make clear where the official defaults file
> for cdrecord is located, they did violate the license of cdrecord.

What part of the license exactly?

Also, if they modified the location of the file (which is reasonable
if the default location doesn't conform to they filesystem layout),
they should make clear where the _new_ location is, mentioning the
original one is completely irrelevant.

				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
"One single semicolon. A perfect drop of perliness. The rest is padding." -- S. Manandhar

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Valdis.Kletnieks]

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

On Tue, 10 Aug 2004 17:15:58 +0200, Joerg Schilling said:

> As the people who did create the bastardized version of cdrecord
> you are using did not make clear where the official defaults file
> for cdrecord is located, they did violate the license of cdrecord.

Uh oh... if creating buggy/unclear/stupid mods to a GPL'ed program violates the
GPL, then I'm surely doomed to burn in the afterlife, for I've certainly done
my share and then some. :)


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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Tue, 10 Aug 2004 22:17:21 -0400, valdis.kletnieks@vt.edu
<valdis.kletnieks@vt.edu> wrote:
> Uh oh... if creating buggy/unclear/stupid mods to a GPL'ed program violates the
> GPL, then I'm surely doomed to burn in the afterlife, for I've certainly done
> my share and then some. :)

So has everyone. 


-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

>From: Stephan von Krawczynski <skraw@ithnet.com>
>> Indeed! Altough minor things could be better with Debian too, Debian is the
>> only true Open Source Linux distribution. Other distributions modify programs
>> without reason and do not cooperate with the original authors :-(

>Would you mind to stop your general accusations against "other distributions"
>and your talking for people (i.e. authors) that you don't know or haven't
>talked to in your whole lifetime.

>Fortunately everybody can decide for himself what distro he likes best. And if
>someone thinks he has to modify the original GPL source, then he should do.
>If you don't like that, don't use GPL, because the right to modify foreign
>sources is a major part of it.

You seem to forget that the main problems are:

-	These distributions do not talk with the original Authors which
	demonstrates that they do not like to benefit from OSS.

-	The modified versions of cdrtools found in distributions are _all_
	worse than the original. As some of the distributions (e.g. SuSE)
	even published versions known to be defective, they violate 
	the GPL (subsection 6 of the preamble).


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Tue, 10 Aug 2004 16:27:13 +0200 (CEST)
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> >From: Stephan von Krawczynski <skraw@ithnet.com>
> >> Indeed! Altough minor things could be better with Debian too, Debian is
> >the> only true Open Source Linux distribution. Other distributions modify
> >programs> without reason and do not cooperate with the original authors :-(
> 
> >Would you mind to stop your general accusations against "other
> >distributions" and your talking for people (i.e. authors) that you don't
> >know or haven't talked to in your whole lifetime.
> 
> >Fortunately everybody can decide for himself what distro he likes best. And
> >if someone thinks he has to modify the original GPL source, then he should
> >do. If you don't like that, don't use GPL, because the right to modify
> >foreign sources is a major part of it.
> 
> You seem to forget that the main problems are:
> 
> -	These distributions do not talk with the original Authors which
> 	demonstrates that they do not like to benefit from OSS.

"My car is blue, that's why it rains tommorrow." 
I can very well understand why some people refuse to talk to you, but I cannot
really see the relation to OSS in general.
Really, have you listened to yourself lately: "Commercial distros do not like
to benefit from OSS." ??? 
How do you define their primary goal, arguing with Joerg Schilling, or what?

> -	The modified versions of cdrtools found in distributions are _all_
> 	worse than the original. As some of the distributions (e.g. SuSE)
> 	even published versions known to be defective, they violate 
> 	the GPL (subsection 6 of the preamble).

Has there been one single day in your life where you accepted someone elses
opinion, differing from yours ?
It is obvious _for me_, that programmers at SuSE think your software needs some
changes and try to improve it according to their ideas. It is _your_ problem
that you cannot accept their point of view, not theirs'. 
If you see GPL violation, sue them. If you don't want your software to be
changed in any way, don't use GPL.

Regards,
Stephan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jan-Benedict Glaw]

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

On Tue, 2004-08-10 16:49:47 +0200, Stephan von Krawczynski <skraw@ithnet.com>
wrote in message <20040810164947.7f363529.skraw@ithnet.com>:
> On Tue, 10 Aug 2004 16:27:13 +0200 (CEST)
> Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > 
> > -	These distributions do not talk with the original Authors which
> > 	demonstrates that they do not like to benefit from OSS.
> 
> Really, have you listened to yourself lately: "Commercial distros do not like
> to benefit from OSS." ??? 
> How do you define their primary goal, arguing with Joerg Schilling, or what?

IIRC Jörg complained some hundred emails ago that they (the SuSE people)
don't care to try to get their patches upstream, back to Jörg, or
discussing their changes with him (but instead hacking cdrecord the way
it fits best for them).

While they (and any other distro's people and anybody else) may actually
hack the code to no end, I consider it being good habit to actually
*avoid* forking without the intent to (constantly) work in re-merging
the fork. While this is perfectly legal, I can understand that Jörg
(even while using a broken email client 8-)  doesn't like getting
complains about a hacked cdrecord, or missing useful changes the
distribution people did to cdrecord...


So what's commercial distro's primary goal?  (1) Re-packaging
software for the sole purpose of earning some $$ or  (2) acting as
a mediator between upstream authors and their paying customers?


If it is all about (1), I for one would consider (at least for my future
work) to not continue without actually *forcing* vendors into discussing
their useful changes with me as an upstream author. Like working IN but
not solely FOR a community...

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Tue, Aug 10 2004, Jan-Benedict Glaw wrote:
> On Tue, 2004-08-10 16:49:47 +0200, Stephan von Krawczynski <skraw@ithnet.com>
> wrote in message <20040810164947.7f363529.skraw@ithnet.com>:
> > On Tue, 10 Aug 2004 16:27:13 +0200 (CEST)
> > Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > > 
> > > -	These distributions do not talk with the original Authors which
> > > 	demonstrates that they do not like to benefit from OSS.
> > 
> > Really, have you listened to yourself lately: "Commercial distros do not like
> > to benefit from OSS." ??? 
> > How do you define their primary goal, arguing with Joerg Schilling, or what?
> 
> IIRC Jörg complained some hundred emails ago that they (the SuSE
> people) don't care to try to get their patches upstream, back to Jörg,
> or discussing their changes with him (but instead hacking cdrecord the
> way it fits best for them).

Don't be naive. How do you discuss changes with him? The one patch I did
create against the SUSE cdrecord for the one shipped with SL9.1 adds a
note to use ATA over ATAPI since that is preferred, and it kills the
silly open-by-devname warnings that are extremely confusing to users. I
did send that back to Joerg, to no avail.

> While they (and any other distro's people and anybody else) may
> actually hack the code to no end, I consider it being good habit to

By far the largest modification is dvd support, which we of course need
to ship. The rest is really minor stuff.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jan-Benedict Glaw]

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

On Tue, 2004-08-10 17:33:34 +0200, Jens Axboe <axboe@suse.de>
wrote in message <20040810153333.GF13369@suse.de>:

> Don't be naive. How do you discuss changes with him? The one patch I did
> create against the SUSE cdrecord for the one shipped with SL9.1 adds a
> note to use ATA over ATAPI since that is preferred, and it kills the
> silly open-by-devname warnings that are extremely confusing to users. I
> did send that back to Joerg, to no avail.

Look at lkml. For sure, you'll find a good number of examples of really
small (and not really intrusive/important/...) changes that took more
than a dozen emails to discuss (and probably to not come to an end at
all).  Right, I think distro's people should go through all that for
every single change, even while continueing to work on that. Patch
resync isn't an easy thing (even for "single" projects like the Linux
kernel) and nearly an endless game if you bring in something of the
scale of a whole distro. ...and then, there exist several of them.

So I think IFF you (as a distro) attempt to do any changes (be it adding
a well-selling feature like DVD toasting), you *will* somewhen reach a
critical mass: the point of no return (of good patches).

Seems we're slowly reaching there. (I'm just waiting to see a giant Arch
repo of a single, unified Linux distro because of that.)

> > While they (and any other distro's people and anybody else) may
> > actually hack the code to no end, I consider it being good habit to
> 
> By far the largest modification is dvd support, which we of course need
> to ship. The rest is really minor stuff.

What's more important to whom? First ship the feature, or first getting
consens with the initial author? Exactly--there are two answers:(

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

(don't trim CC lists of people you are talking to! it's rude and I
usually wont see your mail for days)

On Tue, Aug 10 2004, Jan-Benedict Glaw wrote:
> On Tue, 2004-08-10 17:33:34 +0200, Jens Axboe <axboe@suse.de>
> wrote in message <20040810153333.GF13369@suse.de>:
> 
> > Don't be naive. How do you discuss changes with him? The one patch I did
> > create against the SUSE cdrecord for the one shipped with SL9.1 adds a
> > note to use ATA over ATAPI since that is preferred, and it kills the
> > silly open-by-devname warnings that are extremely confusing to users. I
> > did send that back to Joerg, to no avail.
> 
> Look at lkml. For sure, you'll find a good number of examples of really
> small (and not really intrusive/important/...) changes that took more
> than a dozen emails to discuss (and probably to not come to an end at
> all).  Right, I think distro's people should go through all that for
> every single change, even while continueing to work on that. Patch

I agree. But time isn't divided evenly across the year, if you've ever
worked on a project you know there's a crunch time close to release
where you don't have time to do that. You only have time to fix things.
I'm not saying that's a good thing, but it happens. Then later you have
to go and push some of that stuff out, it's the individual package
maintainers duty to do so.

> > > While they (and any other distro's people and anybody else) may
> > > actually hack the code to no end, I consider it being good habit to
> > 
> > By far the largest modification is dvd support, which we of course need
> > to ship. The rest is really minor stuff.
> 
> What's more important to whom? First ship the feature, or first getting
> consens with the initial author? Exactly--there are two answers:(

If you had followed this thread at all, you'd know that in this case we
could either add the feature or spend 100% of the time being sucked into
the black hole of email writing that is Joerg.

Maybe you should consider why _every_ distro adds that patch? It's not a
new patch, it's been around for years. It's not one single distro
"forking" the code base, it's basically the same thing we ship.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Adrian Bunk]

On Tue, Aug 10, 2004 at 06:29:51PM +0200, Jan-Benedict Glaw wrote:
>...
> So I think IFF you (as a distro) attempt to do any changes (be it adding
> a well-selling feature like DVD toasting), you *will* somewhen reach a
> critical mass: the point of no return (of good patches).
> 
> Seems we're slowly reaching there. (I'm just waiting to see a giant Arch
> repo of a single, unified Linux distro because of that.)
> 
> > > While they (and any other distro's people and anybody else) may
> > > actually hack the code to no end, I consider it being good habit to
> > 
> > By far the largest modification is dvd support, which we of course need
> > to ship. The rest is really minor stuff.
> 
> What's more important to whom? First ship the feature, or first getting
> consens with the initial author? Exactly--there are two answers:(

Joerg offers his own non-free program cdrecord-ProDVD with DVD support.

So why should he ever add DVD support to the GPLed cdrecord, no matter 
how good the patches are?

> MfG, JBG

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Tue, Aug 10 2004, Adrian Bunk wrote:
> Joerg offers his own non-free program cdrecord-ProDVD with DVD support.
> 
> So why should he ever add DVD support to the GPLed cdrecord, no matter 
> how good the patches are?

It's obvious - to reduce his support load, according to the man that's
his biggest obstacle since the distros add so much broken crap to his
program. He _likes_ to say the distros ship broken crap, why else would
anyone consider getting his "pro" version?

DVD burning is commonplace and has been for years, keeping a basic
feature like that out of the open make no sense.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Tue, 10 Aug 2004 17:24:59 +0200
Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:

> IIRC Jörg complained some hundred emails ago that they (the SuSE people)
> don't care to try to get their patches upstream, back to Jörg, or
> discussing their changes with him (but instead hacking cdrecord the way
> it fits best for them).

Have you followed this thread? I can very well imagine what kind of a mess it
may be to get a patch accepted "upstream".
In fact I would have dropped this idea, too.
 
> While they (and any other distro's people and anybody else) may actually
> hack the code to no end, I consider it being good habit to actually
> *avoid* forking without the intent to (constantly) work in re-merging
> the fork. While this is perfectly legal, I can understand that Jörg
> (even while using a broken email client 8-)  doesn't like getting
> complains about a hacked cdrecord, or missing useful changes the
> distribution people did to cdrecord...

Sometimes forking is unavoidable and necessary. On Joergs side things are
pretty easy. All he has to tell the people is that according to the version
spec they sent he refuses to help them, because they use a forked version.
The true story behind may be that nobody wants to use his version for certain
pecularities and that therefore merely no feedback is reaching him (any more).
 
> So what's commercial distro's primary goal?  (1) Re-packaging
> software for the sole purpose of earning some $$ or  (2) acting as
> a mediator between upstream authors and their paying customers?
> 
> If it is all about (1), I for one would consider (at least for my future
> work) to not continue without actually *forcing* vendors into discussing
> their useful changes with me as an upstream author. Like working IN but
> not solely FOR a community...

Don't try to press politics onto distros. See what they really are: companies.
All companies want to earn bucks, that's what they are for.
If you don't like that, use debian. You got the choice, that's the fine part
about it.

Regards,
Stephan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jan-Benedict Glaw]

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

On Tue, 2004-08-10 17:48:14 +0200, Stephan von Krawczynski <skraw@ithnet.com>
wrote in message <20040810174814.414c8fdd.skraw@ithnet.com>:
> On Tue, 10 Aug 2004 17:24:59 +0200
> Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> 
> > IIRC Jörg complained some hundred emails ago that they (the SuSE people)
> > don't care to try to get their patches upstream, back to Jörg, or
> > discussing their changes with him (but instead hacking cdrecord the way
> > it fits best for them).
> 
> Have you followed this thread? I can very well imagine what kind of a mess it
> may be to get a patch accepted "upstream".
> In fact I would have dropped this idea, too.

Yes, I've read this whole thread. ...and I know, too, what amount of
hard work is required to get patches upstream. It's a *lot* more work
than needed to actually implement the chance beforehand.

> > While they (and any other distro's people and anybody else) may actually
> > hack the code to no end, I consider it being good habit to actually
> > *avoid* forking without the intent to (constantly) work in re-merging
> > the fork. While this is perfectly legal, I can understand that Jörg
> > (even while using a broken email client 8-)  doesn't like getting
> > complains about a hacked cdrecord, or missing useful changes the
> > distribution people did to cdrecord...
> 
> Sometimes forking is unavoidable and necessary. On Joergs side things are
> pretty easy. All he has to tell the people is that according to the version
> spec they sent he refuses to help them, because they use a forked version.
> The true story behind may be that nobody wants to use his version for certain
> pecularities and that therefore merely no feedback is reaching him (any more).

Get real. Most people actually *use* distros, and many of them actually
*fail* to put the bugs into the distro's BTS. Instead, the author (or
whomever they think is the author) is written to. And guess? And I can
well imaging that Jörg doesn't like getting complains about hacked
cdrecord versions because people fail to *read* that this isn't a "pure"
incarnation.

> > So what's commercial distro's primary goal?  (1) Re-packaging
> > software for the sole purpose of earning some $$ or  (2) acting as
> > a mediator between upstream authors and their paying customers?
> > 
> > If it is all about (1), I for one would consider (at least for my future
> > work) to not continue without actually *forcing* vendors into discussing
> > their useful changes with me as an upstream author. Like working IN but
> > not solely FOR a community...
> 
> Don't try to press politics onto distros. See what they really are: companies.
> All companies want to earn bucks, that's what they are for.
> If you don't like that, use debian. You got the choice, that's the fine part
> about it.

Actually, I use Debian since, um, long ago:)  But accept that Jörg
doesn't really like to care about f*cked up patched versions of
cdrecord.  And right, that's a completely different topic compared to
possible bugs/non-documented APIs etc. Jörg is complaining about.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Tue, 10 Aug 2004 18:10:57 +0200
Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:

> Actually, I use Debian since, um, long ago:)  But accept that Jörg
> doesn't really like to care about f*cked up patched versions of
> cdrecord.

He does not need to. Nobody told him to do.
Besides I doubt that only the patched versions are actually "f*cked up".
My personal experience with cdrecord is that neither version works well on my
system.
I tried several including "gods' own". Needless to mention it didn't work
either. Needless to mention he told me to upgrade the firmware, needless to
mention that did not help, but got worse instead (not even dvd worked
afterwards).
End of the story was that I gave away the old device (which works in a w*ndows
system flawlessly ever since for both CD and DVD), and bought a new one which
works well with DVD again (growisofs) but still not with cdrecord.
My personal opinion is that both product and author get more attention than
they deserve.

Regards,
Stephan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jan-Benedict Glaw]

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

On Tue, 2004-08-10 18:47:18 +0200, Stephan von Krawczynski <skraw@ithnet.com>
wrote in message <20040810184718.769c046f.skraw@ithnet.com>:
> On Tue, 10 Aug 2004 18:10:57 +0200
> Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> 
> > Actually, I use Debian since, um, long ago:)  But accept that Jörg
> > doesn't really like to care about f*cked up patched versions of
> > cdrecord.
> 
> He does not need to. Nobody told him to do.

Net being legally or by contract *in charge* to do some supportative
work doesn't mean to be asked to do that or to be expected to do that.

However, I for one *expect* people to help out if they can. ...and Jörg
is probably one of those who actually *know* all those shiny toasters
better than most of us.

MfG, JBG (who'll now continue to find the sense data from NCR5380.c ...)

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

>From: Kyle Moffett <mrmacman_g4@mac.com>

>On Aug 10, 2004, at 08:46, Joerg Schilling wrote:
>> Your statements are correct for programs that include locale support.

>Programs that do not support locales _must_ restrict themselves to
>7-bit ASCII, or they are likely to break any number of things by 
>outputting
>invalid characters to the terminal.  You could quite easily replace the 
>(C)
>symbol with the string "Copyright", or you could pick a more complicated
>solution by actually implementing locales, but you should change the
>behavior of cdrecord, as that is broken/buggy.

Guess what happens when you call

	find . -type f -exec grep © {} +

on the cdrtools root dir?

Inform yourself before posting.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]


>From: Martin Mares <mj@ucw.cz>

>> Your statements are correct for programs that include locale support.

>Would you accept a patch to cdrecord to add such support?

Locale support is on a top positoon of my TODO list, adding it for e.g. Solaris
would be extremely simple but my software runs on many platforms.

If you send a patch that includes autoconf support and everything that is needed
else, I would be glad......


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

>From: David Woodhouse <dwmw2@infradead.org>

>On Tue, 2004-08-10 at 14:47 +0200, Joerg Schilling wrote:
>> Cdrecord does not read /etc/cdrecord.conf

>And the world is flat.

>shinybook /home/dwmw2 $ strace -e open cdrecord -inq 2>&1 | grep /etc/cdrecord.conf
>open("/etc/cdrecord.conf", O_RDONLY)    = 3
>open("/etc/cdrecord.conf", O_RDONLY)    = 3
>open("/etc/cdrecord.conf", O_RDONLY)    = 3
>open("/etc/cdrecord.conf", O_RDONLY)    = 3

It seems that you like to constantly discredit yourself :-(

What you use if DEFINITELY NOT cdrecord.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Tue, 2004-08-10 at 15:03 +0200, Joerg Schilling wrote:
> It seems that you like to constantly discredit yourself :-(

I think people stopped counting the credits a long time ago.

> What you use if DEFINITELY NOT cdrecord.

You argue about nomenclature. What I have definitely calls itself
cdrecord and is definitely based on your code.

Perhaps, though, it's time that the Linux distributions and also FreeBSD
and others who feel the need to patch cdrecord forked it and called it
something different.

> Jrg

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Chris Meadors]

On Tue, 2004-08-10 at 16:00 +0100, David Woodhouse wrote:

> Perhaps, though, it's time that the Linux distributions and also FreeBSD
> and others who feel the need to patch cdrecord forked it and called it
> something different.

What happened to the dvdtools/dvdrecord project?
http://www.nongnu.org/dvdrtools/

It seems to have disappeared about the time GNU had problems with their
savannah server.

-- 
Chris

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Raphael Jacquot]

Chris Meadors wrote:
> On Tue, 2004-08-10 at 16:00 +0100, David Woodhouse wrote:
> 
> 
>>Perhaps, though, it's time that the Linux distributions and also FreeBSD
>>and others who feel the need to patch cdrecord forked it and called it
>>something different.
> 
> 
> What happened to the dvdtools/dvdrecord project?
> http://www.nongnu.org/dvdrtools/
> 
> It seems to have disappeared about the time GNU had problems with their
> savannah server.
> 

seems the site is functionnal

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Chris Meadors]

On Thu, 2004-08-26 at 17:02 +0200, Raphael Jacquot wrote:
> Chris Meadors wrote:
> > On Tue, 2004-08-10 at 16:00 +0100, David Woodhouse wrote:
> > 
> > 
> >>Perhaps, though, it's time that the Linux distributions and also FreeBSD
> >>and others who feel the need to patch cdrecord forked it and called it
> >>something different.
> > 
> > 
> > What happened to the dvdtools/dvdrecord project?
> > http://www.nongnu.org/dvdrtools/
> > 
> > It seems to have disappeared about the time GNU had problems with their
> > savannah server.
> > 
> 
> seems the site is functionnal

I was just trying the download links on the nongnu.org site, all the
files were missing there.  But heading over to
http://machiel.generaal.net/index.php?subject=dvdrtools it does look
like development is still continuing, if a little unoffically.

-- 
Chris

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Schlemmer]

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

On Tue, 2004-08-10 at 15:03, Joerg Schilling wrote:
> >From: David Woodhouse <dwmw2@infradead.org>
> 
> >On Tue, 2004-08-10 at 14:47 +0200, Joerg Schilling wrote:
> >> Cdrecord does not read /etc/cdrecord.conf
> 
> >And the world is flat.
> 
> >shinybook /home/dwmw2 $ strace -e open cdrecord -inq 2>&1 | grep /etc/cdrecord.conf
> >open("/etc/cdrecord.conf", O_RDONLY)    = 3
> >open("/etc/cdrecord.conf", O_RDONLY)    = 3
> >open("/etc/cdrecord.conf", O_RDONLY)    = 3
> >open("/etc/cdrecord.conf", O_RDONLY)    = 3
> 
> It seems that you like to constantly discredit yourself :-(
> 
> What you use if DEFINITELY NOT cdrecord.
> 

While I would rather have said something like:

  What you use is DEFINITELY a PATCHED cdrecord

it is not the original:

---
# strace -e open cdrecord -inq 2>&1 | grep '/etc/.*cdrecord'
open("/etc/default/cdrecord", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/default/cdrecord", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/default/cdrecord", O_RDONLY) = -1 ENOENT (No such file or directory)
---

stupid question: why this name and placement of the config file?
I would think that /etc/cdrecord.conf or /etc/cdrecord/defaults might
have made more sence, but this is out of a mostly linux pov.

Also, out of a user point of view:

1)  What is the big issue with supporting -dev=/dev/xxx ?  As I did
    point out above, I have limited experience with solaris and fbsd,
    but don't they all support and use /dev/ to access devices ?  It
    really is not a new way to access devices in linux as you tried
    to point out earlier - and it should be possible to implement it
    on all *nix OS's ?  Sure, maybe the exact kernel interface might
    change, but your device node should always (mostly?) point you
    in the correct direction if you know the correct one to use?
    I and I am sure many (most?) other users that have ide/usb devices
    do not want to worry about scsi topology, etc - that and scsi
    emulation adds extra overhead that we with older machines do not
    want.

    Also, it would be less confusing - on 2.6 currently -scanbus do
    not even detect any cdrw devices (sure, not a problem of yours).
    But I still remember the first time I tried to use cdrecord - and
    later with 2.5 and the -dev=x,y,z syntax ... I just went with
    gtoaster and did not look back as cli writing is not an issue
    here.

2)  As pointed out, some error messages could use some tweaking.
    There was also some nice examples ...


I hope this was put nicely enough (although a tad clueless), and valid
a similar response.  If not, please refrain from answering.


Regards,

-- 
Martin Schlemmer

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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]


>From: David Woodhouse <dwmw2@infradead.org>

>> Burn-Proof is switched off by default and other protections (invented later)
>> are switched off by cdrecord to get compatibility..... if you only had read the 
>> man page......
>> 
>> Switching Burn-Proof on will reduce the quality of the CDs.

>I haven't even stated which distribution I'm running. How can you
>possibly know what it puts into /etc/cdrecord.conf when it detects my
>CD-R? What relation has this to your man page?

Cdrecord does not read /etc/cdrecord.conf

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
./

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Tue, 2004-08-10 at 14:47 +0200, Joerg Schilling wrote:
> Cdrecord does not read /etc/cdrecord.conf

And the world is flat.

shinybook /home/dwmw2 $ strace -e open cdrecord -inq 2>&1 | grep /etc/cdrecord.conf
open("/etc/cdrecord.conf", O_RDONLY)    = 3
open("/etc/cdrecord.conf", O_RDONLY)    = 3
open("/etc/cdrecord.conf", O_RDONLY)    = 3
open("/etc/cdrecord.conf", O_RDONLY)    = 3

> Jrg

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

>From: Martin Mares <mj@ucw.cz>

>I think that it is very reasonable to expect that a program honors the locale
>settings or uses only ASCII characters.

>(In this matter, I share your feelings, because I also have non-ASCII
>characters in my name, but if I decide to print my name in its full
>glory, I respect the locales and don't assume that all the world uses
>iso-8859-2 as I do.)

Your statements are correct for programs that include locale support.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> Your statements are correct for programs that include locale support.

Would you accept a patch to cdrecord to add such support?

				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
This line is umop apisdn.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Xavier Bestel]

Le mar 10/08/2004 à 14:46, Joerg Schilling a écrit :

> Your statements are correct for programs that include locale support.

If your program doesn't have locale support, then it shouldn't print
locale-dependant text, that's all. Saying it's someone else's fault for
not using the same locale as you is misplaced at best.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Kyle Moffett]

On Aug 10, 2004, at 08:46, Joerg Schilling wrote:
> Your statements are correct for programs that include locale support.

Programs that do not support locales _must_ restrict themselves to
7-bit ASCII, or they are likely to break any number of things by 
outputting
invalid characters to the terminal.  You could quite easily replace the 
(C)
symbol with the string "Copyright", or you could pick a more complicated
solution by actually implementing locales, but you should change the
behavior of cdrecord, as that is broken/buggy.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

>From: Martin Mares <mj@ucw.cz>

>> Switching Burn-Proof on will reduce the quality of the CDs.

>BTW is it true that Burn-Proof reduces the quality exactly in the cases
>where burning without Burn-Proof would ruin the disk?

This is why it is silly to tell people that they do not need locked memory and
raised scheduling priority for 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)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> >BTW is it true that Burn-Proof reduces the quality exactly in the cases
> >where burning without Burn-Proof would ruin the disk?
> 
> This is why it is silly to tell people that they do not need locked memory and
> raised scheduling priority for CD/DVD writing.

Yes, but if it is true, you can safely turn on Burn-Proof by default,
since the only cases where it would hurt are the cases when it would
fail without Burn-Proof anyway.

Also, as many people regularly use non-suid-root cdrecord without
Burn-Proof being ever used (even though I don't assert that it is
always the case), I would very much appreciate if cdrecord could
be configured (in cdrecord.conf) that I really wish to run it
without mlocking and RT priority if I know what I'm doing.

				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
return(ENOTOBACCO); /* Read on an empty pipe */

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Tue, 10 Aug 2004 14:45:06 +0200 (CEST)
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> >From: Martin Mares <mj@ucw.cz>
> 
> >> Switching Burn-Proof on will reduce the quality of the CDs.
> 
> >BTW is it true that Burn-Proof reduces the quality exactly in the cases
> >where burning without Burn-Proof would ruin the disk?
> 
> This is why it is silly to tell people that they do not need locked memory
> and raised scheduling priority for CD/DVD writing.

Please, if you don't want to answer the original question, don't post anything.


My answer:
Yes, burn-proof (or however the vendor calls the corresponding feature) saves
your disk where otherwise you run into dead-end. That's what it was meant to
be. When there is no underrun, burn-proof should not do any harm.

Regards,
Stephan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]


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

>> >From: Jens Axboe <axboe@suse.de>
>> 
>> >> Please try again after you had a look into the cdrtools sources.
>> >> 
>> >> Cdrecord also needs privilleges to lock memory and to raise prioirity.
>> 
>> >They are not required, or at least not with the version I use. It warns
>> >of failing to set priority and lock memory, I can continue fine though.
>> >With the casual burning of CDs I do, it's never been a problem.
>> 
>> You should believe people who know better.....

>J�rg, this is insulting. Who knows better than Jens if his computer has
>needed burn-proof and if his writes have been successful?  You for one
>don't. I don't either but at least I don't claim to.

So you really like to recommend everyone to cross the street while the 
traffic light shows red just because you did not yet get any harm from doing 
so? 

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

Joerg Schilling schrieb am 2004-08-10:

> So you really like to recommend everyone to cross the street while the 
> traffic light shows red just because you did not yet get any harm from doing 
> so? 

Of course not, but you cannot claim I've been harmed crossing the street
when the lights were red when I haven't.

There are dangers when mlockall() or similar and RT scheduling don't
succeed, but that doesn't mean something MUST happen. The warning IMO is
right but let's just ditch this part of the discussion.  cdrecord user
interface discussion is off-topic here.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]


>From: Patrick McFarland <diablod3@gmail.com>

>On Mon, 9 Aug 2004 16:40:52 +0200 (CEST), Joerg Schilling
><schilling@fokus.fraunhofer.de> wrote:
>> People who use the official cdrecord know that they need to run cdrecord
>> with root privilleges. People who run the bastardized version from SuSE
>> don't know this and fail to write CDs.

>This is why people should be using Debian to begin with. Debian asks
>if you want to install cdrecord with suid so everyone can burn cds
>without needing to be root first.

Indeed! Altough minor things could be better with Debian too, Debian is the only
true Open Source Linux distribution. Other distributions modify programs 
without reason and do not cooperate with the original authors :-(

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Tue, 10 Aug 2004 12:33:16 +0200 (CEST)
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> 
> >From: Patrick McFarland <diablod3@gmail.com>
> 
> >On Mon, 9 Aug 2004 16:40:52 +0200 (CEST), Joerg Schilling
> ><schilling@fokus.fraunhofer.de> wrote:
> >> People who use the official cdrecord know that they need to run cdrecord
> >> with root privilleges. People who run the bastardized version from SuSE
> >> don't know this and fail to write CDs.
> 
> >This is why people should be using Debian to begin with. Debian asks
> >if you want to install cdrecord with suid so everyone can burn cds
> >without needing to be root first.
> 
> Indeed! Altough minor things could be better with Debian too, Debian is the
> only true Open Source Linux distribution. Other distributions modify programs
> without reason and do not cooperate with the original authors :-(

Would you mind to stop your general accusations against "other distributions"
and your talking for people (i.e. authors) that you don't know or haven't
talked to in your whole lifetime.

Fortunately everybody can decide for himself what distro he likes best. And if
someone thinks he has to modify the original GPL source, then he should do.
If you don't like that, don't use GPL, because the right to modify foreign
sources is a major part of it.

Regards,
Stephan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]


>From: David Woodhouse <dwmw2@infradead.org>

>> Cdrecord also needs privilleges to lock memory and to raise prioirity.

>Wrong. Cdrecord does not always _need_ to lock memory or to raise its
>priority.

>To do so may be useful when using older drives without buffer underrun
>protection, but is not strictly necessary on current hardware. 

Please inform yourself before posting.....

Burn-Proof is switched off by default and other protections (invented later)
are switched off by cdrecord to get compatibility..... if you only had read the 
man page......

Switching Burn-Proof on will reduce the quality of the CDs.


In addition: if you don't have the experience when Buffer Underruns occur, you 
should not post speculations that it is not a problem. I know that it _is_ and 
this should be enough for you. Unless you send me the results from a test done 
under worst conditions you need to believe in the experience of people who 
spend more time on CD/DVD recording issues than you.

Proving things to work for a 1/12th dozen only is not sufficient for granting 
quality.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> Switching Burn-Proof on will reduce the quality of the CDs.

BTW is it true that Burn-Proof reduces the quality exactly in the cases
where burning without Burn-Proof would ruin the disk?

				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
Only dead fish swim with the stream.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Tue, 2004-08-10 at 12:27 +0200, Joerg Schilling wrote:
> Please inform yourself before posting.....

Jrg, you are making a fool of yourself.

> Burn-Proof is switched off by default and other protections (invented later)
> are switched off by cdrecord to get compatibility..... if you only had read the 
> man page......
> 
> Switching Burn-Proof on will reduce the quality of the CDs.

I haven't even stated which distribution I'm running. How can you
possibly know what it puts into /etc/cdrecord.conf when it detects my
CD-R? What relation has this to your man page?

> In addition: if you don't have the experience when Buffer Underruns occur, you 
> should not post speculations that it is not a problem.

I have experience that buffer underruns do not occur, when I am not
running as root. Therefore I posted a statement that running as root is
not strictly necessary. What part of that do you not understand?

>  I know that it _is_ and this should be enough for you. Unless you
> send me the results from a test done under worst conditions you need
> to believe in the experience of people who spend more time on CD/DVD
> recording issues than you.

Perhaps I should. But I think that in the last few days you've managed
to lose even the shred of credibility you once had. I shall now take
anything you say with an _extremely_ large pinch of salt.

> Jrg

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

David Woodhouse wrote:

> I haven't even stated which distribution I'm running. How can you
> possibly know what it puts into /etc/cdrecord.conf when it detects my
> CD-R? What relation has this to your man page?

David, I don't know what program you're running, but it is NOT cdrecord! 
There is no such file used in the program, and hasn't been in versions 
going back at least a year. I don't recall there ever being such a 
thing, and I've been using it since cdwrite was active. Any program 
which uses that file has NO relation to Joerg's man page, it's not his code.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Gene Heskett]

On Tuesday 10 August 2004 06:27, Joerg Schilling wrote:

>Burn-Proof is switched off by default and other protections
> (invented later) are switched off by cdrecord to get
> compatibility..... if you only had read the man page......
>
>Switching Burn-Proof on will reduce the quality of the CDs.

How so Joerg?  Making a blanket statement such as this requires a good 
proof example IMO.  You not are giving one.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.24% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

On Tue, 10 Aug 2004, Gene Heskett wrote:

[burnproof decreases CD quality]
> How so Joerg?  Making a blanket statement such as this requires a good 
> proof example IMO.  You not are giving one.

The switch from read mode to write mode (i. e. find end of data,
increase LASER power to write and pick up writing) takes some time
(order of magnitude: µs) which means some pits/lands aren't right during
that phase. How many pits/lands are broken break depends on hard- and
firmware, write speed and model and for CAV the radial position on the
disc. Fast writers will need to reach a linear velocity around 60 m/s
(216 km/h); one µs time to ramp up LASER power from read to write level
there means up to 60 µm lost.

How far good improvements in the hard- and firmware have allowed to
reduce that gap is beyond my current knowledge. Some figures are posted
at: http://www.digital-sanyo.com/BURN-Proof/tips/No1.html
    http://www.digital-sanyo.com/BURN-Proof/tips/No2.html

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Gene Heskett]

On Tuesday 10 August 2004 20:24, Matthias Andree wrote:
>On Tue, 10 Aug 2004, Gene Heskett wrote:
>
>[burnproof decreases CD quality]
>
>> How so Joerg?  Making a blanket statement such as this requires a
>> good proof example IMO.  You not are giving one.
>
>The switch from read mode to write mode (i. e. find end of data,
>increase LASER power to write and pick up writing) takes some time
>(order of magnitude: µs) which means some pits/lands aren't right
> during that phase. How many pits/lands are broken break depends on
> hard- and firmware, write speed and model and for CAV the radial
> position on the disc. Fast writers will need to reach a linear
> velocity around 60 m/s (216 km/h); one µs time to ramp up LASER
> power from read to write level there means up to 60 µm lost.

And just how fast do you think that laser is being modulated?  At the 
bandwidth of that, the lazer's power could be brought back to write 
power levels in at least an order of magnitude less time than that.

I'd be far more concerned with the support electronics ability to 
detect the end of the previous write in a timely manner than in how 
long it took to bring the laser back up to write power.  My guess is 
that any space lost, and therefore unwritten on the disk, is much 
more an issue of detecting the loss than in 'ramping up the power' 
which can be done in modern drives in 5ns or less.  Now if the 
electronics could detect the first missing edge and initiate the 
write on that, the written edge needn't be more than 5ns late, a very 
minor glitch in the data recovery's phase locked loop, and probably 
fully recentered before the next 100 edges have gone by, certainly 
before the intersector synch data is used up and real data begins.

But, now consider this, a drive with burnproof should have a method of 
marking a burnproof event in the intersector sync data.  The drive 
should have at the point when the burnproof kicked in, written a 
known bit pattern that identifies a burnproof event in the 
intersector housekeeping.  From that, the drive can predict the end 
of the written data to a very high degree of accuracy, and switch up 
the laser precisely on time to not miss a pits edge at all.

So I don't find this argument convincing unless the drive makers are a 
bunch of dummies and haven't thought of the above scenario.  That 
theory doesn't hold any water either. The designers of these things 
will use every possible advantage to make their product a better 
mousetrap.  You can bet the farm that this method, or one even better 
is in use in every drive featureing burnproof today.

Much of what I just wrote could, I suppose, be considered proprietary 
data to the drive makers, and if I 'blew their cover', well stuff 
happens...  You cannot argue with common sense solutions to what 
looks like a complex problem to the average Joe Six-Pack.

And there's precious few of us here who think we're the Joe Six-Packs 
of this world.  "They" are not those who would subscribe to this list 
in the first place.  Generally speaking, we like to think we're a cut 
above that label...  Granted, there are many younger, brighter brains 
than mine on this list, and for that I'm thankfull every day.

>How far good improvements in the hard- and firmware have allowed to
>reduce that gap is beyond my current knowledge. Some figures are
> posted at: http://www.digital-sanyo.com/BURN-Proof/tips/No1.html
>    http://www.digital-sanyo.com/BURN-Proof/tips/No2.html

Moot point IMO, progress is made everyday by the drive people.  
Progress they aren't going to talk about for the competitive edge 
they need because if they did, the guy down the street would be out 
with a clone later today.  So take anything that purports to be "the 
bible" with an un-healthy amount of salt.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.24% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Florian Schirmer]

Hi,

>The switch from read mode to write mode (i. e. find end of data,
>increase LASER power to write and pick up writing) takes some time
>(order of magnitude: µs) which means some pits/lands aren't right during
>that phase. How many pits/lands are broken break depends on hard- and
>firmware, write speed and model and for CAV the radial position on the
>disc. Fast writers will need to reach a linear velocity around 60 m/s
>(216 km/h); one µs time to ramp up LASER power from read to write level
>there means up to 60 µm lost.
>

With burn-proof on you get a disc which is still usable but with some 
pits/lands missing/misplaced. With burnproof off you get a completely 
unusable disc. So whats the _real_ point behind disabling burn proof?

Thanks,
   Florian

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

Florian Schirmer wrote:

> With burn-proof on you get a disc which is still usable but with some 
> pits/lands missing/misplaced. With burnproof off you get a completely 
> unusable disc. So whats the _real_ point behind disabling burn proof?

There are some people who would rather not have a CD at all if it is 
even slightly defective. Jorg is one of those, and I am for backups. I 
also verify backup CDs with his c2scan option to see just how clean the 
burn is.

There's an option, you can use it or not. Maybe a burnfree CD will be 
just as good in 3-4 years, but CDs are cheap, I'll burn another if need 
be. I don't know how much this helps, but I understand terms like "good 
faith effort" and "best practices." I have no problem with making the 
user specify that option.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]


>From: Alan Cox <alan@lxorguk.ukuu.org.uk>

>> If you are right, why then is SuSE removing the warnings in cdrecord
>> that are there to tell the user that cdrecord is running with insufficient 
>> privilleges?

>You'd have to ask them. Probably for the reason that most vendors
>remove a lot of the other weird warnings - it confuses end users.

Well, It has been proven that removing the warnings confuses the users :-(

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]


>From alan@lxorguk.ukuu.org.uk  Mon Aug  9 17:35:14 2004

>export LC_ALL=cy_GB.UTF-8
>run cdrecord 
>review the output. Its using a hardcoded 8859-1/15 symbols so it breaks.

This is a problem of the people who use UTF-8..... sorry, but when
they are tought that moving to UTF-8 is without problems is is just wrong.
N.B. This is not a bug in cdrecord but wrong expectations from the users.

>> BTW: this also appears to your comments on the Solaris device handling....
>> Did you ever install Solaris 10 and test?

>I've seen it on older Solaris. When drives walk between scsi busses as
>the system is running it doesn't like it

If you like that people believe this, you would need to proof it. I've never 
seen it.....so I won't believe until you at least exactly describe the scenario
when this should ocur.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> This is a problem of the people who use UTF-8..... sorry, but when
> they are tought that moving to UTF-8 is without problems is is just wrong.

Well, but according to this argument using anything else than iso-8859-1
is just wrong. Strange. :-)

> N.B. This is not a bug in cdrecord but wrong expectations from the users.

I think that it is very reasonable to expect that a program honors the locale
settings or uses only ASCII characters.

(In this matter, I share your feelings, because I also have non-ASCII
characters in my name, but if I decide to print my name in its full
glory, I respect the locales and don't assume that all the world uses
iso-8859-2 as I do.)

				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 I need a drink, alcoholic in nature, after the tough chapters involving quantum mechanics!" = \pi

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Lenar Lõhmus]

Joerg Schilling wrote:

>>review the output. Its using a hardcoded 8859-1/15 symbols so it breaks.
>>    
>>
>This is a problem of the people who use UTF-8..... sorry, but when
>they are tought that moving to UTF-8 is without problems is is just wrong.
>N.B. This is not a bug in cdrecord but wrong expectations from the users.
>  
>
Now I just really want to know what the heck are you eating to get to 
get so mean and arrogant?
I really would consider a program spitting random garbage to my screen a 
buggy one.

Lenar

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Con Kolivas]

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

Joerg Schilling wrote:
>>>You should learn what "make sense" means, Linux-2.6 is a clear move away from 
>>>the demands of a Linux user who likes to write CDs/DVDs.
> 
> 
>>Could have fooled me. I'm a linux user who writes lots of cds and I had 
>>heaps of trouble scanning busses and trains and automobiles on the atapi 
>>interface till I could do a simple
> 
> 
>>dev=/dev/hdd
> 
> 
>>Seems they listened to this user.
> 
> 
> ever tried this with an audio CD?
> 
> geh.....

Great idea! Can you implement it please?

Cheers,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Albert Cahalan]

Alan Cox writes:
> On Llu, 2004-08-09 at 15:12, Joerg Schilling wrote:
>> [Alan Cox writes]

>>> Linux has capabilities, ACLs and SELinux rulesets which
>>> can also be used to manage this. I can give the cd burner
>>> a role that permits it certain things.
>> 
>> If you are right, why then is SuSE removing the warnings
>> in cdrecord that are there to tell the user that cdrecord
>> is running with insufficient privilleges?
>
> You'd have to ask them. Probably for the reason that most vendors
> remove a lot of the other weird warnings - it confuses end users.

Oh dear my. I'm going to, at least partially, agree with Joerg.
Pigs are cleared for take-off.

The warning about "cdrecord dev=/dev/hdc" is truly crap.
The same goes for "unsettled issues with Linux-2.5". The
other warnings are sane though, and should not be removed.

If the warnings are confusing, they need to be re-worded.
When you remove warnings, users get hurt. The users do  
things that may well fail, and then have no clue why things
are failing.

Shall we rip the printk() calls out of the kernel? Many
of them are weird. They might confuse the end users.

Joerg:
   "WARNING: Cannot do mlockall(2).\n"
   "WARNING: This causes a high risk for buffer underruns.\n"
Fixed:
   "Warning: You don't have permission to lock memory.\n"
   "         If the computer is not idle, the CD may be ruined.\n"

Joerg:
   "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
   "WARNING: This causes a high risk for buffer underruns.\n"
Fixed:
   "Warning: You don't have permission to hog the CPU.\n"
   "         If the computer is not idle, the CD may be ruined.\n"

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Con Kolivas]

Albert Cahalan writes:


> Joerg:
>    "WARNING: Cannot do mlockall(2).\n"
>    "WARNING: This causes a high risk for buffer underruns.\n"
> Fixed:
>    "Warning: You don't have permission to lock memory.\n"
>    "         If the computer is not idle, the CD may be ruined.\n"
> 
> Joerg:
>    "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
>    "WARNING: This causes a high risk for buffer underruns.\n"
> Fixed:
>    "Warning: You don't have permission to hog the CPU.\n"
>    "         If the computer is not idle, the CD may be ruined.\n"

Huh? That can't be right. Every cd burner this side of the 21st century has 
buffer underrun protection. I've burnt cds _while_ capturing and encoding 
video using truckloads of cpu and I/O without superuser privileges, had all 
the cdrecord warnings and didn't have a buffer underrun. Last time I gave 
superuser privilege to cdrecord it locked my machine - clearly it wasn't 
rt_task safe.

Con

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Lang]

I have burned one coaster in the last year with CDrecord (running as root) 
so it's still possible, it's just very rare.

David Lang

On Tue, 10 Aug 2004, Con Kolivas wrote:

> Date: Tue, 10 Aug 2004 08:59:25 +1000
> From: Con Kolivas <kernel@kolivas.org>
> To: Albert Cahalan <albert@users.sourceforge.net>
> Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>,
>     alan@lxorguk.ukuu.org.uk, dwmw2@infradead.org,
>     schilling@fokus.fraunhofer.de, axboe@suse.de
> Subject: Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices
> 
> Albert Cahalan writes:
>
>
>> Joerg:
>>    "WARNING: Cannot do mlockall(2).\n"
>>    "WARNING: This causes a high risk for buffer underruns.\n"
>> Fixed:
>>    "Warning: You don't have permission to lock memory.\n"
>>    "         If the computer is not idle, the CD may be ruined.\n"
>> 
>> Joerg:
>>    "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
>>    "WARNING: This causes a high risk for buffer underruns.\n"
>> Fixed:
>>    "Warning: You don't have permission to hog the CPU.\n"
>>    "         If the computer is not idle, the CD may be ruined.\n"
>
> Huh? That can't be right. Every cd burner this side of the 21st century has 
> buffer underrun protection. I've burnt cds _while_ capturing and encoding 
> video using truckloads of cpu and I/O without superuser privileges, had all 
> the cdrecord warnings and didn't have a buffer underrun. Last time I gave 
> superuser privilege to cdrecord it locked my machine - clearly it wasn't 
> rt_task safe.
>
> Con
>
> -
> 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/
>

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Albert Cahalan]

On Mon, 2004-08-09 at 18:59, Con Kolivas wrote:
> Albert Cahalan writes:
> 
> 
> > Joerg:
> >    "WARNING: Cannot do mlockall(2).\n"
> >    "WARNING: This causes a high risk for buffer underruns.\n"
> > Fixed:
> >    "Warning: You don't have permission to lock memory.\n"
> >    "         If the computer is not idle, the CD may be ruined.\n"
> > 
> > Joerg:
> >    "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
> >    "WARNING: This causes a high risk for buffer underruns.\n"
> > Fixed:
> >    "Warning: You don't have permission to hog the CPU.\n"
> >    "         If the computer is not idle, the CD may be ruined.\n"
> 
> Huh? That can't be right. Every cd burner this side of the 21st century has 
> buffer underrun protection.

I'm pretty sure my FireWire CD-RW/CD-R is from
another century. Not that it's unusual in 2004.

> I've burnt cds _while_ capturing and encoding 
> video using truckloads of cpu and I/O without superuser privileges, had all 
> the cdrecord warnings and didn't have a buffer underrun.

That's cool. My hardware won't come close to that.
Burning a coaster costs money.

Let me put it this way: $$ $ $$$ $$ $ $$$ $$ $

The warning, if re-worded, will save people from
frustration and wasted money.

> Last time I gave 
> superuser privilege to cdrecord it locked my machine - clearly it wasn't 
> rt_task safe.

So, you've been working on the scheduler anyway...
An option to reserve some portion of CPU time for
emergency use (say, 5% after 1 second has passed)
would let somebody get out of this situation.

Reporting and/or fixing the cdrecord bug is nice too.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Con Kolivas]

Albert Cahalan writes:

> On Mon, 2004-08-09 at 18:59, Con Kolivas wrote:
>> Albert Cahalan writes:
>> 
>> 
>> > Joerg:
>> >    "WARNING: Cannot do mlockall(2).\n"
>> >    "WARNING: This causes a high risk for buffer underruns.\n"
>> > Fixed:
>> >    "Warning: You don't have permission to lock memory.\n"
>> >    "         If the computer is not idle, the CD may be ruined.\n"
>> > 
>> > Joerg:
>> >    "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
>> >    "WARNING: This causes a high risk for buffer underruns.\n"
>> > Fixed:
>> >    "Warning: You don't have permission to hog the CPU.\n"
>> >    "         If the computer is not idle, the CD may be ruined.\n"
>> 
>> Huh? That can't be right. Every cd burner this side of the 21st century has 
>> buffer underrun protection.
> 
> I'm pretty sure my FireWire CD-RW/CD-R is from
> another century. Not that it's unusual in 2004.
> 
>> I've burnt cds _while_ capturing and encoding 
>> video using truckloads of cpu and I/O without superuser privileges, had all 
>> the cdrecord warnings and didn't have a buffer underrun.
> 
> That's cool. My hardware won't come close to that.
> Burning a coaster costs money.
> 
> Let me put it this way: $$ $ $$$ $$ $ $$$ $$ $
> 
> The warning, if re-worded, will save people from
> frustration and wasted money.

Sounds good; how about something less terrifying? That warning sounds like a 
ruined cd is likely.

>> Last time I gave 
>> superuser privilege to cdrecord it locked my machine - clearly it wasn't 
>> rt_task safe.
> 
> So, you've been working on the scheduler anyway...
> An option to reserve some portion of CPU time for
> emergency use (say, 5% after 1 second has passed)
> would let somebody get out of this situation.

This breaks the real time policy entirely. That's why I run it SCHED_ISO ... 
but of course this isn't available in mainline linux.

> Reporting and/or fixing the cdrecord bug is nice too.

It was a hard lockup and randomly happened during a cd write, creating my 
first coaster in a long time... in rt mode ironically which is how it is 
recommended to be run. So I removed the foolish superuser bit and have had 
no problem since. Yes it was unaltered cdrecord source and it was the 
so-called alpha branch and... Not much else I can say about it really?

Cheers,
Con

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Albert Cahalan]

On Tue, 2004-08-10 at 00:47, Con Kolivas wrote:
> Albert Cahalan writes:
> > On Mon, 2004-08-09 at 18:59, Con Kolivas wrote:
> >> Albert Cahalan writes:

> >> > Joerg:
> >> >    "WARNING: Cannot do mlockall(2).\n"
> >> >    "WARNING: This causes a high risk for buffer underruns.\n"
> >> > Fixed:
> >> >    "Warning: You don't have permission to lock memory.\n"
> >> >    "         If the computer is not idle, the CD may be ruined.\n"
> >> > 
> >> > Joerg:
> >> >    "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
> >> >    "WARNING: This causes a high risk for buffer underruns.\n"
> >> > Fixed:
> >> >    "Warning: You don't have permission to hog the CPU.\n"
> >> >    "         If the computer is not idle, the CD may be ruined.\n"
> >> 
> >> Huh? That can't be right. Every cd burner this side of the 21st century has 
> >> buffer underrun protection.
> > 
> > I'm pretty sure my FireWire CD-RW/CD-R is from
> > another century. Not that it's unusual in 2004.
> > 
> >> I've burnt cds _while_ capturing and encoding 
> >> video using truckloads of cpu and I/O without superuser privileges, had all 
> >> the cdrecord warnings and didn't have a buffer underrun.
> > 
> > That's cool. My hardware won't come close to that.
> > Burning a coaster costs money.
> > 
> > Let me put it this way: $$ $ $$$ $$ $ $$$ $$ $
> > 
> > The warning, if re-worded, will save people from
> > frustration and wasted money.
> 
> Sounds good; how about something less terrifying? That warning sounds like a 
> ruined cd is likely.

I'm not about to burn CDs trying, but I do believe
that "a ruined cd is likely" would be accurate if I
were to keep busy with Mozilla and such. OpenOffice
would surely ruin a cd. Light web browsing makes my
mp3 player skip.

Not all of us have hardware like you do. Encoding
video is something I wouldn't bother to try, even
without the CD burner going!

(the box isn't that old; it's fanless though)

> >> Last time I gave 
> >> superuser privilege to cdrecord it locked my machine - clearly it wasn't 
> >> rt_task safe.
> > 
> > So, you've been working on the scheduler anyway...
> > An option to reserve some portion of CPU time for
> > emergency use (say, 5% after 1 second has passed)
> > would let somebody get out of this situation.
> 
> This breaks the real time policy entirely. That's why I run it SCHED_ISO ... 
> but of course this isn't available in mainline linux.

Of course it breaks the real time policy entirely.
It would have to be enabled via a sysctl.

The NMI watchdog breaks cli/sti. We have it anyway.
This is the same thing.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Thomas Zimmerman]

On 09-Aug 10:51, Albert Cahalan wrote:
> On Tue, 2004-08-10 at 00:47, Con Kolivas wrote:
> > Albert Cahalan writes:
> > > On Mon, 2004-08-09 at 18:59, Con Kolivas wrote:
> > >> Albert Cahalan writes:
> 
> > >> > Joerg:
> > >> >    "WARNING: Cannot do mlockall(2).\n"
> > >> >    "WARNING: This causes a high risk for buffer underruns.\n"
> > >> > Fixed:
> > >> >    "Warning: You don't have permission to lock memory.\n"
> > >> >    "         If the computer is not idle, the CD may be ruined.\n"
> > >> > 
> > >> > Joerg:
> > >> >    "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
> > >> >    "WARNING: This causes a high risk for buffer underruns.\n"
> > >> > Fixed:
> > >> >    "Warning: You don't have permission to hog the CPU.\n"
> > >> >    "         If the computer is not idle, the CD may be ruined.\n"
> > >> 
> > >> Huh? That can't be right. Every cd burner this side of the 21st century has 
> > >> buffer underrun protection.
> > > 
> > > I'm pretty sure my FireWire CD-RW/CD-R is from
> > > another century. Not that it's unusual in 2004.
> > > 
> > >> I've burnt cds _while_ capturing and encoding 
> > >> video using truckloads of cpu and I/O without superuser privileges, had all 
> > >> the cdrecord warnings and didn't have a buffer underrun.
> > > 
> > > That's cool. My hardware won't come close to that.
> > > Burning a coaster costs money.
> > > 
> > > Let me put it this way: $$ $ $$$ $$ $ $$$ $$ $
> > > 
> > > The warning, if re-worded, will save people from
> > > frustration and wasted money.
> > 
> > Sounds good; how about something less terrifying? That warning sounds like a 
> > ruined cd is likely.
> 
> I'm not about to burn CDs trying, but I do believe
> that "a ruined cd is likely" would be accurate if I
> were to keep busy with Mozilla and such. OpenOffice
> would surely ruin a cd. Light web browsing makes my
> mp3 player skip.
> 
> Not all of us have hardware like you do. Encoding
> video is something I wouldn't bother to try, even
> without the CD burner going!
> 
> (the box isn't that old; it's fanless though)
> 

I've only created coaster _with_ the suid bit while ab^H^Husing the 
computer to do other things--like compiling a new kernel. 2.6 is much
better at setting up DMA access to the drive; 2.4 would use huge amounts
of system time (> 90%). When that happened, the system felt like it was 
out to lunch--mouse cursor updates would sometimes take >2 seconds. 
Cdrecord used more cpu if it was suid. I haven't had a problem in 2.6.
The  warning is counter to my expericnce with cdrecord. I think the
warning would be worded better as:

"Warning: Cdrecord was unable to get exclusive access to the cpu."
"Warning: This may cause Buffer underruns from other activity."

and

"Warning: Cdrecord was unable to get exclusive access to memory."
"Warning: This may cause Buffer underruns from other activity."

But drop the first one if you're on >2.6.

Thomas

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Albert Cahalan <albert@users.sf.net> writes:

> I'm not about to burn CDs trying, but I do believe
> that "a ruined cd is likely" would be accurate if I
> were to keep busy with Mozilla and such. OpenOffice
> would surely ruin a cd. Light web browsing makes my
> mp3 player skip.
>
> Not all of us have hardware like you do. Encoding
> video is something I wouldn't bother to try, even
> without the CD burner going!

Encoding video is a typically CPU-bound task, unless your machine is
so fast that it saturates the disk bandwidth.  The scheduler should
give the encoding lower priority than the "interactive" CD burning.

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jan Knutar]

> Light web browsing makes my
> mp3 player skip.

What kind of machine is that? I've never needed to boost priority for the mp3
player on my P133, even when running opera and/or mozilla... 

Getting offtopic here though :-\

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Albert Cahalan]

On Tue, 2004-08-10 at 18:59, Jan Knutar wrote:
> > Light web browsing makes my
> > mp3 player skip.
> 
> What kind of machine is that? I've never needed to boost priority for the mp3
> player on my P133, even when running opera and/or mozilla... 

Since the last time I tested this, things have
improved dramatically. This is 2.6.8-rc1 now; I had
been mostly using 2.6.0-test5 and 2.6.0-test11.
Still, I do get problems from:

1. resizing any window (oroborus wm + GNOME)
2. switching out of X with Alt-Ctrl-F1
3. switching into X with Alt-Ctrl-F7

I suppose this means that it is somewhat likely that
burning a CD without CAP_SYS_RESOURCE would work.
I doubt I'd like to risk my time and money on this,
but at least it isn't looking like failure would
be much more likely than success.

It irritates me that I'd need to compile up a hacked
cdrecord in order to attempt a dummy burn as a
regular user. Those warnings are treated as errors.
Grrr... If SuSE, OSDL, IBM, SGI, HP or Red Hat would
put up the money, I'd gladly fix this POS. Anybody
care enough?

FWIW, my desktop machine is:

450 MHz Mac G4 Cube, 512 MB RAM, 1600x1024 32bpp,
5400 rpm IDE, ext2, no swap, 2.6.8-rc1 kernel,
USB audio, ATI Rage 128 PF/PRO AGP 4x TMDS video

I run sound through esd, like this: mpg321 -o esd ...

Commonly, the X server grows to 300 MB and/or Mozilla
grows to 200 MB before I restart them. An old GNOME
is running with 8 desktops, Evolution and one or two
dozen xterms.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

Con Kolivas wrote:

> It was a hard lockup and randomly happened during a cd write, creating 
> my first coaster in a long time... in rt mode ironically which is how it 
> is recommended to be run. So I removed the foolish superuser bit and 
> have had no problem since. Yes it was unaltered cdrecord source and it 
> was the so-called alpha branch and... Not much else I can say about it 
> really?

I said I'd never seen this (true), but it could happen if you were 
burning an audio CD using the ide-scsi or ATA: interface. In 2.6 the 
ATAPI: interface uses DMA. I don't know what the program does if you 
just say dev=/dev/hdx, I don't normally use it that way (I got into the 
habit of using ATAPI:). Given a fast burner and the interface using PIO, 
I guess you could slow the system down some!

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Bill Davidsen <davidsen@tmr.com> writes:

> Con Kolivas wrote:
>
>> It was a hard lockup and randomly happened during a cd write,
>> creating my first coaster in a long time... in rt mode ironically
>> which is how it is recommended to be run. So I removed the foolish
>> superuser bit and have had no problem since. Yes it was unaltered
>> cdrecord source and it was the so-called alpha branch and... Not
>> much else I can say about it really?
>
> I said I'd never seen this (true), but it could happen if you were
> burning an audio CD using the ide-scsi or ATA: interface. In 2.6 the
> ATAPI: interface uses DMA. I don't know what the program does if you
> just say dev=/dev/hdx,

Whatever it does, it doesn't load the system noticeably.

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Fri, Aug 13 2004, Måns Rullgård wrote:
> Bill Davidsen <davidsen@tmr.com> writes:
> 
> > Con Kolivas wrote:
> >
> >> It was a hard lockup and randomly happened during a cd write,
> >> creating my first coaster in a long time... in rt mode ironically
> >> which is how it is recommended to be run. So I removed the foolish
> >> superuser bit and have had no problem since. Yes it was unaltered
> >> cdrecord source and it was the so-called alpha branch and... Not
> >> much else I can say about it really?
> >
> > I said I'd never seen this (true), but it could happen if you were
> > burning an audio CD using the ide-scsi or ATA: interface. In 2.6 the
> > ATAPI: interface uses DMA. I don't know what the program does if you
> > just say dev=/dev/hdx,

This is only true for recent 2.6 kernels.

> Whatever it does, it doesn't load the system noticeably.

ATA uses SG_IO. Bill should re-read most of this thread as he is
repeating what others have said and have been corrected on (not just
this mail, btw).

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Albert Cahalan <albert@users.sf.net> writes:

>> Last time I gave 
>> superuser privilege to cdrecord it locked my machine - clearly it wasn't 
>> rt_task safe.
>
> So, you've been working on the scheduler anyway...
> An option to reserve some portion of CPU time for
> emergency use (say, 5% after 1 second has passed)
> would let somebody get out of this situation.

Another option would be an Alt-Sysrq-something that lowered all RT
processes to normal levels.

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Lee Revell]

On Tue, 2004-08-10 at 04:16, Måns Rullgård wrote:
> Albert Cahalan <albert@users.sf.net> writes:
> 
> >> Last time I gave 
> >> superuser privilege to cdrecord it locked my machine - clearly it wasn't 
> >> rt_task safe.
> >
> > So, you've been working on the scheduler anyway...
> > An option to reserve some portion of CPU time for
> > emergency use (say, 5% after 1 second has passed)
> > would let somebody get out of this situation.
> 
> Another option would be an Alt-Sysrq-something that lowered all RT
> processes to normal levels.

I hate to derail a good flame-fest, but this would be extremely useful,
for more than burning CDs.  Anytime you are dealing with a SCHED_FIFO
process a bug can lock the machine, this would be useful for hacking
jackd for example.

If someone wants to code this up I and the other people on jackit-devel
would gladly test it.

Lee

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Maw, 2004-08-10 at 15:33, Lee Revell wrote:
> I hate to derail a good flame-fest, but this would be extremely useful,
> for more than burning CDs.  Anytime you are dealing with a SCHED_FIFO
> process a bug can lock the machine, this would be useful for hacking
> jackd for example.
> 
> If someone wants to code this up I and the other people on jackit-devel
> would gladly test it.

How much is this actually needed and how much is it just a user
debugging method problem. Having done real time stuff on VMS (save
the tears) we always had a policy that one serial console was a shell
at highest priority and nobody ever used that one top priority.

That gave you an emergency control channel.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Lee Revell]

On Tue, 2004-08-10 at 11:04, Alan Cox wrote:
> On Maw, 2004-08-10 at 15:33, Lee Revell wrote:
> > I hate to derail a good flame-fest, but this would be extremely useful,
> > for more than burning CDs.  Anytime you are dealing with a SCHED_FIFO
> > process a bug can lock the machine, this would be useful for hacking
> > jackd for example.
> > 
> > If someone wants to code this up I and the other people on jackit-devel
> > would gladly test it.
> 
> How much is this actually needed and how much is it just a user
> debugging method problem. Having done real time stuff on VMS (save
> the tears) we always had a policy that one serial console was a shell
> at highest priority and nobody ever used that one top priority.
> 
> That gave you an emergency control channel.

Yeah, I haven't yet been in a situation where I needed this, it would be
useful only in theory.  It sounded like someone was volunteering to code
it up.

Lee

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Lee Revell <rlrevell@joe-job.com> writes:

> On Tue, 2004-08-10 at 04:16, Måns Rullgård wrote:
>> Albert Cahalan <albert@users.sf.net> writes:
>> 
>> >> Last time I gave 
>> >> superuser privilege to cdrecord it locked my machine - clearly it wasn't 
>> >> rt_task safe.
>> >
>> > So, you've been working on the scheduler anyway...
>> > An option to reserve some portion of CPU time for
>> > emergency use (say, 5% after 1 second has passed)
>> > would let somebody get out of this situation.
>> 
>> Another option would be an Alt-Sysrq-something that lowered all RT
>> processes to normal levels.
>
> I hate to derail a good flame-fest, but this would be extremely useful,
> for more than burning CDs.  Anytime you are dealing with a SCHED_FIFO
> process a bug can lock the machine, this would be useful for hacking
> jackd for example.
>
> If someone wants to code this up I and the other people on jackit-devel
> would gladly test it.

Here you go.  Some limited testing suggests that it actually works.
Pressing Alt-Sysrq-N (as in Nice) changes all RT tasks to SCHED_NORMAL
policy.

===== drivers/char/sysrq.c 1.29 vs edited =====
--- 1.29/drivers/char/sysrq.c	2004-01-20 00:38:11 +01:00
+++ edited/drivers/char/sysrq.c	2004-08-11 01:41:38 +02:00
@@ -216,6 +216,16 @@
 
 /* END SIGNAL SYSRQ HANDLERS BLOCK */
 
+static void sysrq_handle_unrt(int key, struct pt_regs *pt_regs,
+			      struct tty_struct *tty)
+{
+	normalize_rt_tasks();
+}
+static struct sysrq_key_op sysrq_unrt_op = {
+	.handler	= sysrq_handle_unrt,
+	.help_msg	= "Nice",
+	.action_msg	= "Nice All RT Tasks"
+};
 
 /* Key Operations table and lock */
 static spinlock_t sysrq_key_table_lock = SPIN_LOCK_UNLOCKED;
@@ -250,7 +260,7 @@
 #endif
 /* l */	NULL,
 /* m */	&sysrq_showmem_op,
-/* n */	NULL,
+/* n */	&sysrq_unrt_op,
 /* o */	NULL, /* This will often be registered
 		 as 'Off' at init time */
 /* p */	&sysrq_showregs_op,
===== include/linux/sched.h 1.197 vs edited =====
--- 1.197/include/linux/sched.h	2004-04-27 07:07:44 +02:00
+++ edited/include/linux/sched.h	2004-08-11 01:45:09 +02:00
@@ -944,6 +944,12 @@
 
 #endif /* CONFIG_SMP */
 
+#ifdef CONFIG_MAGIC_SYSRQ
+
+extern void normalize_rt_tasks(void);
+
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif
===== kernel/sched.c 1.261 vs edited =====
--- 1.261/kernel/sched.c	2004-04-27 07:07:43 +02:00
+++ edited/kernel/sched.c	2004-08-11 01:38:00 +02:00
@@ -3053,3 +3053,35 @@
 
 EXPORT_SYMBOL(__preempt_write_lock);
 #endif /* defined(CONFIG_SMP) && defined(CONFIG_PREEMPT) */
+
+#ifdef CONFIG_MAGIC_SYSRQ
+void normalize_rt_tasks(void)
+{
+	struct task_struct *p;
+	prio_array_t *array;
+	unsigned long flags;
+	runqueue_t *rq;
+
+	for_each_process (p) {
+		if (!rt_task(p))
+			continue;
+
+		read_lock_irq(&tasklist_lock);
+		rq = task_rq_lock(p, &flags);
+
+		array = p->array;
+		if (array)
+			deactivate_task(p, task_rq(p));
+		__setscheduler(p, SCHED_NORMAL, 0);
+		if (array) {
+			__activate_task(p, task_rq(p));
+			resched_task(rq->curr);
+		}
+
+		task_rq_unlock(rq, &flags);
+		read_unlock_irq(&tasklist_lock);
+	}
+}
+
+EXPORT_SYMBOL(normalize_rt_tasks);
+#endif /* CONFIG_MAGIC_SYSRQ */


-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Lee Revell]

On Tue, 2004-08-10 at 20:23, Måns Rullgård wrote:
> Lee Revell <rlrevell@joe-job.com> writes:
> 
> > On Tue, 2004-08-10 at 04:16, Måns Rullgård wrote:
> >> Another option would be an Alt-Sysrq-something that lowered all RT
> >> processes to normal levels.
> >
> >
> > If someone wants to code this up I and the other people on jackit-devel
> > would gladly test it.
> 
> Here you go.  Some limited testing suggests that it actually works.
> Pressing Alt-Sysrq-N (as in Nice) changes all RT tasks to SCHED_NORMAL
> policy.
> 

I sent this patch to the jackit-devel list, and everyone seems to think
this would be a useful feature; had this been around a few years ago it
certainly would have aided JACK's development.  Debugging an RT process
becomes as easy as a regular one (read: reboot free).  I see no reason
not to merge it once it has been widely tested.

Lee

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Lee Revell <rlrevell@joe-job.com> writes:

> On Tue, 2004-08-10 at 20:23, Måns Rullgård wrote:
>> Lee Revell <rlrevell@joe-job.com> writes:
>> 
>> > On Tue, 2004-08-10 at 04:16, Måns Rullgård wrote:
>> >> Another option would be an Alt-Sysrq-something that lowered all RT
>> >> processes to normal levels.
>> >
>> >
>> > If someone wants to code this up I and the other people on jackit-devel
>> > would gladly test it.
>> 
>> Here you go.  Some limited testing suggests that it actually works.
>> Pressing Alt-Sysrq-N (as in Nice) changes all RT tasks to SCHED_NORMAL
>> policy.
>> 
>
> I sent this patch to the jackit-devel list, and everyone seems to think
> this would be a useful feature; had this been around a few years ago it
> certainly would have aided JACK's development.

So why didn't anyone write it earlier?

> Debugging an RT process becomes as easy as a regular one (read:
> reboot free).  I see no reason not to merge it once it has been
> widely tested.

Let me know how the testing works out.

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Lee Revell]

On Wed, 2004-08-11 at 03:28, Måns Rullgård wrote:
> Lee Revell <rlrevell@joe-job.com> writes:
> >
> > I sent this patch to the jackit-devel list, and everyone seems to think
> > this would be a useful feature; had this been around a few years ago it
> > certainly would have aided JACK's development.
> 
> So why didn't anyone write it earlier?
> 

Eh, possibly it's one of those things that's very useful in theory but
that no one ever actually needed enough to write.  JACK has been stable
for a while now and has mechanisms for preventing buggy clients from
locking the machine.

Lee

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

Con Kolivas wrote:
> Albert Cahalan writes:
> 
> 
>> Joerg:
>>    "WARNING: Cannot do mlockall(2).\n"
>>    "WARNING: This causes a high risk for buffer underruns.\n"
>> Fixed:
>>    "Warning: You don't have permission to lock memory.\n"
>>    "         If the computer is not idle, the CD may be ruined.\n"
>>
>> Joerg:
>>    "WARNING: Cannot set priority class parameters 
>> priocntl(PC_SETPARMS)\n"
>>    "WARNING: This causes a high risk for buffer underruns.\n"
>> Fixed:
>>    "Warning: You don't have permission to hog the CPU.\n"
>>    "         If the computer is not idle, the CD may be ruined.\n"
> 
> 
> Huh? That can't be right. Every cd burner this side of the 21st century 
> has buffer underrun protection. I've burnt cds _while_ capturing and 
> encoding video using truckloads of cpu and I/O without superuser 
> privileges, had all the cdrecord warnings and didn't have a buffer 
> underrun. Last time I gave superuser privilege to cdrecord it locked my 
> machine - clearly it wasn't rt_task safe.

This may be a side effect of your scheduler, then. Cdrecord is run as or 
by root on a lot of systems and I've never had any indication that ever 
does anything which hurts response, other than to lock down a small 
memory section for fifo.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Mon, 2004-08-09 at 16:22 -0400, Albert Cahalan wrote:
> Joerg:
>    "WARNING: Cannot do mlockall(2).\n"
>    "WARNING: This causes a high risk for buffer underruns.\n"
> Fixed:
>    "Warning: You don't have permission to lock memory.\n"
>    "         If the computer is not idle, the CD may be ruined.\n"
> 
> Joerg:
>    "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
>    "WARNING: This causes a high risk for buffer underruns.\n"
> Fixed:
>    "Warning: You don't have permission to hog the CPU.\n"
>    "         If the computer is not idle, the CD may be ruined.\n"

That seems reasonable, but _only_ if burnfree is not enabled. If the
hardware _supports_ burnfree but it's disabled, the warning should also
recommend turning it on.

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

David Woodhouse <dwmw2@infradead.org> writes:

> On Mon, 2004-08-09 at 16:22 -0400, Albert Cahalan wrote:
>> Joerg:
>>    "WARNING: Cannot do mlockall(2).\n"
>>    "WARNING: This causes a high risk for buffer underruns.\n"
>> Fixed:
>>    "Warning: You don't have permission to lock memory.\n"
>>    "         If the computer is not idle, the CD may be ruined.\n"
>> 
>> Joerg:
>>    "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
>>    "WARNING: This causes a high risk for buffer underruns.\n"
>> Fixed:
>>    "Warning: You don't have permission to hog the CPU.\n"
>>    "         If the computer is not idle, the CD may be ruined.\n"
>
> That seems reasonable, but _only_ if burnfree is not enabled. If the
> hardware _supports_ burnfree but it's disabled, the warning should also
> recommend turning it on.

I'm also wondering why cdrecord disables it by default.  Can it ever
do any harm being enabled?

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

Måns Rullgård wrote:
> David Woodhouse <dwmw2@infradead.org> writes:

>>That seems reasonable, but _only_ if burnfree is not enabled. If the
>>hardware _supports_ burnfree but it's disabled, the warning should also
>>recommend turning it on.
> 
> 
> I'm also wondering why cdrecord disables it by default.  Can it ever
> do any harm being enabled?
> 

In theory, yes. It makes the track longer, so it could in theory make 
something large not fit. In practice, there really are some readers 
which skip on audio when they see the blanks. As Joerg which ones, but 
other people have agreed that it does happen.

I have noted that even with it off my recent burners don't mind running 
out of data, so in most cases it won't hurt. Burning off NFS I see 7-10 
underruns typically.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Bill Davidsen <davidsen@tmr.com> writes:

> Måns Rullgård wrote:
>> David Woodhouse <dwmw2@infradead.org> writes:
>
>>>That seems reasonable, but _only_ if burnfree is not enabled. If the
>>>hardware _supports_ burnfree but it's disabled, the warning should also
>>>recommend turning it on.
>> I'm also wondering why cdrecord disables it by default.  Can it ever
>> do any harm being enabled?
>>
>
> In theory, yes. It makes the track longer, so it could in theory make
> something large not fit. In practice, there really are some readers
> which skip on audio when they see the blanks. As Joerg which ones, but
> other people have agreed that it does happen.

As has been pointed out by others, the alternative is a wasted disk.
Even if the quality is degraded slightly where burnfree kicks in, the
disk may still be suitable for its intended use.  CDs are often used
for moving some data to another machine and discarded after a single
use.  In these cases, a lower resistance to scratches is not a
problem.  For long-term storage the situation could of course be
different.

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

> That seems reasonable, but _only_ if burnfree is not enabled. If the
> hardware _supports_ burnfree but it's disabled, the warning should also
> recommend turning it on.

burnfree causes a few broken pits/lands on the CD-R so it is best
avoided if the hardware can do it. That you don't see these is a matter
of the reading drive not exporting such information and EFM and CIRC
usually correcting them, but it's still lower quality than a burn
process that hadn't needed burnfree at all.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Prakash K. Cheemplavam]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthias Andree wrote:
|>That seems reasonable, but _only_ if burnfree is not enabled. If the
|>hardware _supports_ burnfree but it's disabled, the warning should also
|>recommend turning it on.
|
|
| burnfree causes a few broken pits/lands on the CD-R so it is best
| avoided if the hardware can do it. That you don't see these is a matter
| of the reading drive not exporting such information and EFM and CIRC
| usually correcting them, but it's still lower quality than a burn
| process that hadn't needed burnfree at all.
|

Well shouldn't that broken pits just happen, wehn the buffer gets empty
and the laser continues where it stopped after having data in buffer
again? I guess this is better then a coaster.

BTW, I don't have problems burning as a user while doing other things...

Prakash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBGJ1nxU2n/+9+t5gRAjljAKCbjbxNX47d7//QDkQNP/e8OMB5aACfXFDa
Z3CorT523TXskw4YEBMRaDk=
=cpq7
-----END PGP SIGNATURE-----

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Prakash K. Cheemplavam]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthias Andree wrote:
|>That seems reasonable, but _only_ if burnfree is not enabled. If the
|>hardware _supports_ burnfree but it's disabled, the warning should also
|>recommend turning it on.
|
|
| burnfree causes a few broken pits/lands on the CD-R so it is best
| avoided if the hardware can do it. That you don't see these is a matter
| of the reading drive not exporting such information and EFM and CIRC
| usually correcting them, but it's still lower quality than a burn
| process that hadn't needed burnfree at all.

Some addition: Even if your statement is correct, the data read is not
different, as C1 error correction should mask it. Yes, the quality
obviosly is lower, but most probably you won't notice it, unless the
disk degrades with time/scratches and now more errors appear, so it
isn't correctable anymore. But I think it is paranoic to rather have
coasters than living with a bit less quality at some spots where buffer
underruns occured.

Prakash


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBGJ5hxU2n/+9+t5gRAtDtAKCnOgqG+6PobYDcDuNxdA6zdjPQwACgxjxL
Vy0KwpXHoMixCIvKeuxsZP0=
=WEtE
-----END PGP SIGNATURE-----

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

On Mon, 09 Aug 2004, Albert Cahalan wrote:

> Shall we rip the printk() calls out of the kernel? Many
> of them are weird. They might confuse the end users.
> 
> Joerg:
>    "WARNING: Cannot do mlockall(2).\n"
>    "WARNING: This causes a high risk for buffer underruns.\n"
> Fixed:
>    "Warning: You don't have permission to lock memory.\n"
>    "         If the computer is not idle, the CD may be ruined.\n"
> 
> Joerg:
>    "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
>    "WARNING: This causes a high risk for buffer underruns.\n"
> Fixed:
>    "Warning: You don't have permission to hog the CPU.\n"

"hog" certainly is not the right word here, but let's not discuss
application warnings on word level here.

>    "         If the computer is not idle, the CD may be ruined.\n"

The warning still needs to contain a technical information that the end
user can report to the support or maintainer. Jörg's warning isn't all
too bad only the user may not know what a buffer underrun actually
means, so another line of explanation, a recommendation to retry with
increased (root) privileges and preferably another 10 s delay would iron
this out.

Note that while the burn-proof/just-link feature allows the drive to
pick up writing but it comes at a price, a few dozen pits/lands are
hosed for every time this feature gets used, so it's best to avoid
interrupting the write stream.

One of Jörg's goals appears to let his application do the best possible
job without such micro gaps, and that deserves all support he can get.

That the DMA, ide-scsi, interfaces and naming issues can't be settled is
sad and it appears as though the naming and it seems these issues cannot
be discussed separately for some reason.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jan Knutar]

> Joerg:
>    "WARNING: Cannot do mlockall(2).\n"
>    "WARNING: This causes a high risk for buffer underruns.\n"
> Fixed:
>    "Warning: You don't have permission to lock memory.\n"
>    "         If the computer is not idle, the CD may be ruined.\n"


Does this also apply if burnproof is in use?




> Joerg:
>    "WARNING: Cannot set priority class parameters priocntl(PC_SETPARMS)\n"
>    "WARNING: This causes a high risk for buffer underruns.\n"
> Fixed:
>    "Warning: You don't have permission to hog the CPU.\n"
>    "         If the computer is not idle, the CD may be ruined.\n"

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]


>From: Jens Axboe <axboe@suse.de>

>> DMA abstraction does not fix HW bugs, it only allows you to behave the
>> same for all "DMA users" for the same HW in the kernel.

>If they all use the interface. Like with all interfaces, it takes time
>before it's being used kernel-wide.

I did mention DMA abstraction in LKML in 1999 or even earlier.....
It is a long time since then.


>I have lots of discussions on linux-kernel, and not all of them (very
>few, in fact) end up in flames. You seem to end up in flames with
>basically everyone. At least on linux-kernel, I believe my track record
>is far better than yours. Your mails are often infuriating.

You need to distinct between boot licking people and people who know what
they are talking about. It seems that you are missing the needed discussion
stile in order to be able to discuss things with people that are not of your
opinion. I _am_ able to do this and it was alway you to come up with personal
insultings, altough I know that even pure technical discussions may be very 
"hot"...

Note that you did always block when I asked you for giving technical arguments.

At last: I am always open to people wo have the needed discussion style and the
technical background to talk about things, but I don't like the kind of 
discussions I am always thrown into on LKML because they start with bashing me.

Once you learned how to discuss things on a result oriented way, I would be 
happy to see mail from you again.

Meanwhile, have a nice day.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]


>From: Jens Axboe <axboe@suse.de>

>> Please try again after you had a look into the cdrtools sources.
>> 
>> Cdrecord also needs privilleges to lock memory and to raise prioirity.

>They are not required, or at least not with the version I use. It warns
>of failing to set priority and lock memory, I can continue fine though.
>With the casual burning of CDs I do, it's never been a problem.

You should believe people who know better.....


If cdrecord runs as it is intended to run, it is not affected by Netscape
paging and similar....

Running a test first means to know what to test.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

Joerg Schilling schrieb am 2004-08-09:

> 
> >From: Jens Axboe <axboe@suse.de>
> 
> >> Please try again after you had a look into the cdrtools sources.
> >> 
> >> Cdrecord also needs privilleges to lock memory and to raise prioirity.
> 
> >They are not required, or at least not with the version I use. It warns
> >of failing to set priority and lock memory, I can continue fine though.
> >With the casual burning of CDs I do, it's never been a problem.
> 
> You should believe people who know better.....

J�rg, this is insulting. Who knows better than Jens if his computer has
needed burn-proof and if his writes have been successful?  You for one
don't. I don't either but at least I don't claim to.

There may be problems with insufficient privileges, problems when pages
aren't locked into memory, problems when cdrecord doesn't have realtime
priority, but that doesn't mean everyone encounters them.

The maintainer's (your) definition of "works" or "no problem" and the
end user's definition of "works" or "no problem" differ by an order of
magnitude. Such is a developer's life.

So consider refining the warnings and tell users what CAN happen if they
continue without root privileges and add a 15 s timer so they can read,
abort and retry with sudo.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

>From: David Woodhouse <dwmw2@infradead.org>

>On Mon, 2004-08-09 at 16:12 +0200, Joerg Schilling wrote:
>> If you are right, why then is SuSE removing the warnings in cdrecord
>> that are there to tell the user that cdrecord is running with insufficient 
>> privilleges?

>Because those warnings are bogus, put there by someone who likes to
>complain about things that are not _really_ a problem?

Try to inform yourself before sending wrong mails.....

People who use the official cdrecord know that they need to run cdrecord
with root privilleges. People who run the bastardized version from SuSE
don't know this and fail to write CDs.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Mon, 2004-08-09 at 16:40 +0200, Joerg Schilling wrote:
> >From: David Woodhouse <dwmw2@infradead.org>
> 
> >On Mon, 2004-08-09 at 16:12 +0200, Joerg Schilling wrote:
> >> If you are right, why then is SuSE removing the warnings in cdrecord
> >> that are there to tell the user that cdrecord is running with insufficient 
> >> privilleges?
> 
> >Because those warnings are bogus, put there by someone who likes to
> >complain about things that are not _really_ a problem?
> 
> Try to inform yourself before sending wrong mails.....

Jrg, you are making a fool of yourself.

> People who use the official cdrecord know that they need to run cdrecord
> with root privilleges. People who run the bastardized version from SuSE
> don't know this and fail to write CDs.

Actually I run the bastardised version from another distro -- also as
myself rather than as root. With BurnFree enabled to ensure that buffer
underruns don't cause problems (not that they happen _anyway_), I see no
failures due to not running as root.

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Mon, 9 Aug 2004 16:40:52 +0200 (CEST), Joerg Schilling
<schilling@fokus.fraunhofer.de> wrote:
> People who use the official cdrecord know that they need to run cdrecord
> with root privilleges. People who run the bastardized version from SuSE
> don't know this and fail to write CDs.

This is why people should be using Debian to begin with. Debian asks
if you want to install cdrecord with suid so everyone can burn cds
without needing to be root first.

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]


>From: Jens Axboe <axboe@suse.de>
>> If you were true and Linux would include _and_ use DMA abstraction, then
>> we would have DMA with ide-scsi for all CD sector sizes.

>Just because we have an api for helping drivers map data for dma,
>doesn't necessarily mean that they all use it. In 2.6.8 ide-scsi will

This is the first time that you mention it and you could have avoided a lot
of mail if you did do eralier.

>use dma for all transfers. As I've already stated, I wont be fixing 2.4.
>I've also included reasons for this. You seem to think that a 'DMA
>abstraction layer' means there will be no hardware bugs, I only wish
>that was so.

DMA abstraction does not fix HW bugs, it only allows you to behave the same for 
all "DMA users" for the same HW in the kernel.

>> interfaces by using a device special file instead of including the
>> same include file in the kernel code as well as in the applicatin
>> code?

>We were talking about device addressing, right? Or are you ramblinb on
>about API stability again?

This subsection did start about the Linux include file bugs.

If you like to allow kernel interfaces to evolve, then you need to make sure
that applications are able to use them. The only known way to do this correctly 
is to make both the kernel and the application to include the same definitions.

GLIBC is completely uinrelated to ioctl interfaces and it is published in 
completely unrelated time frames..... Trying to tell users to use include files
from GLIBC for SCSI Generic is just silly.

>> YOu have only shown that you in many caes try to ignoore the truth ;-(

>I'm surprised an ego of your size can even be contained inside a
>normally sized (I'm assuming, having never met you) human body. I guess
>in your opinion, anything oozing from your brain is by definition the
>truth? That's the only way that I can see your above sentence making
>sense to you.

OK, as you just verified again that you are a frequent source of insulting
people we should close this thread.

Let us start after you managed to regret and to learn to separate a technical
discussion from personal unsulting.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Joerg Schilling wrote:
> 
> >From: Jens Axboe <axboe@suse.de>
> >> If you were true and Linux would include _and_ use DMA abstraction, then
> >> we would have DMA with ide-scsi for all CD sector sizes.
> 
> >Just because we have an api for helping drivers map data for dma,
> >doesn't necessarily mean that they all use it. In 2.6.8 ide-scsi will
> 
> This is the first time that you mention it and you could have avoided a lot
> of mail if you did do eralier.

I believe your complaint was for 2.4, since it doesn't support SG_IO for
atapi devices. For 2.6 you are just wasting cycles using ide-scsi on
ATAPI burners.

> >use dma for all transfers. As I've already stated, I wont be fixing 2.4.
> >I've also included reasons for this. You seem to think that a 'DMA
> >abstraction layer' means there will be no hardware bugs, I only wish
> >that was so.
> 
> DMA abstraction does not fix HW bugs, it only allows you to behave the
> same for all "DMA users" for the same HW in the kernel.

If they all use the interface. Like with all interfaces, it takes time
before it's being used kernel-wide.

> >> YOu have only shown that you in many caes try to ignoore the truth ;-(
> 
> >I'm surprised an ego of your size can even be contained inside a
> >normally sized (I'm assuming, having never met you) human body. I guess
> >in your opinion, anything oozing from your brain is by definition the
> >truth? That's the only way that I can see your above sentence making
> >sense to you.
> 
> OK, as you just verified again that you are a frequent source of
> insulting people we should close this thread.
> 
> Let us start after you managed to regret and to learn to separate a
> technical discussion from personal unsulting.

I have lots of discussions on linux-kernel, and not all of them (very
few, in fact) end up in flames. You seem to end up in flames with
basically everyone. At least on linux-kernel, I believe my track record
is far better than yours. Your mails are often infuriating.

Since you do not listen to anything I say anyways and keep reiterating
the same comments again and again like a duracell bunny, it's hard to
have a technical discussion with you.

End of discussion from me. Before you claim I'm going away because I
have no arguments (that's rich, coming from you), I'm closing this
thread from my end since you bring nothing to the table except flame
bait and repeated empty arguments.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

>From: Jens Axboe <axboe@suse.de>

>> Just fix the bugs from the List I send you and wait some time......

>Most of them you don't want me to fix. If you truly wanted me to fix the
>problems, I'm sure you would have provided some evidence for them to be
>fixable.

Well, it is not just you... the mail is CC:d to LKML and I am sure there are 
other people who could fix the problems.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Joerg Schilling wrote:
> >From: Jens Axboe <axboe@suse.de>
> 
> >> Just fix the bugs from the List I send you and wait some time......
> 
> >Most of them you don't want me to fix. If you truly wanted me to fix the
> >problems, I'm sure you would have provided some evidence for them to be
> >fixable.
> 
> Well, it is not just you... the mail is CC:d to LKML and I am sure
> there are other people who could fix the problems.

Joerg, read what is written in the emails. You'll find it much easier to
carry a discussion if you have read what you reply to.

I said that you provide zero evidence of the bugs you list. Some of them
are fixable (sense bug we already uncovered, if you would fix it in your
code. SG_SET_RESERVED_SIZE patch has been submitted to linus from me),
some of them will not be fixed as they are not bugs (addressing issues),
and yet some of them are utterly impossible to fix since you provide
nothing to back them up. "Some SCSI driver breaks with bad dma
alignment" - what the hell am I supposed to do with that? Go audit all
SCSI drivers and your whim and see if I can find such a bug in there?

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]


>From: Jens Axboe <axboe@suse.de>

>On Mon, Aug 09 2004, Alan Cox wrote:
>> On Llu, 2004-08-09 at 13:24, Joerg Schilling wrote:
>> > On Linux, it is impossible to run cdrecord without root privilleges.
>> > Make cdrecord suid root, it has been audited....
>> 
>> Wrong. Although in part that is a bug in the kernel urgently needing
>> a fix.

>Even with that fixing, write privileges on the device would be enough.
>So root would still not be required.

Please try again after you had a look into the cdrtools sources.

Cdrecord also needs privilleges to lock memory and to raise prioirity.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Joerg Schilling wrote:
> 
> >From: Jens Axboe <axboe@suse.de>
> 
> >On Mon, Aug 09 2004, Alan Cox wrote:
> >> On Llu, 2004-08-09 at 13:24, Joerg Schilling wrote:
> >> > On Linux, it is impossible to run cdrecord without root privilleges.
> >> > Make cdrecord suid root, it has been audited....
> >> 
> >> Wrong. Although in part that is a bug in the kernel urgently needing
> >> a fix.
> 
> >Even with that fixing, write privileges on the device would be enough.
> >So root would still not be required.
> 
> Please try again after you had a look into the cdrtools sources.
> 
> Cdrecord also needs privilleges to lock memory and to raise prioirity.

They are not required, or at least not with the version I use. It warns
of failing to set priority and lock memory, I can continue fine though.
With the casual burning of CDs I do, it's never been a problem.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Mon, 2004-08-09 at 16:21 +0200, Joerg Schilling wrote:
> Please try again after you had a look into the cdrtools sources.

Jrg, you are making a fool of yourself.

> Cdrecord also needs privilleges to lock memory and to raise prioirity.

Wrong. Cdrecord does not always _need_ to lock memory or to raise its
priority.

To do so may be useful when using older drives without buffer underrun
protection, but is not strictly necessary on current hardware. 

> Jrg

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

Now, don't you all feel silly for insulting each other on a widely read forum?

(It seems my Debian joke-flame-bait has defused this otherwise hostile
situation, which is a good thing)

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 707 bytes --]


>From: Paul Jakma <paul@clubi.ie>

>> Of course, ATAPI devices on Solaris are handled by the same
>> target drivers as e.g. those on 50 pin cables.

>Yes ATAPI is.

>> The ATA driver is implemented the way one would expect it by acting 
>> as a SCSI HBA.

>Yes, as does libata on Linux.

Then I would love to see a demo that uses /dev/sg* with a ATAPI drive 
using DMA for all related sector sizes.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Paul Jakma]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=utf-8; format=flowed, Size: 511 bytes --]

On Mon, 9 Aug 2004, Joerg Schilling wrote:

> Then I would love to see a demo that uses /dev/sg* with a ATAPI drive
> using DMA for all related sector sizes.

Hmm, you'd have to wait for Jeff Garzik to finish ATAPI support in 
libata and address any issues with him.

Anyway, I was just commenting on the device naming issue.

> Jörg

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Death is only a state of mind.

Only it doesn't leave you much time to think about anything else.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Joerg Schilling wrote:
> 
> >From: Paul Jakma <paul@clubi.ie>
> 
> >> Of course, ATAPI devices on Solaris are handled by the same
> >> target drivers as e.g. those on 50 pin cables.
> 
> >Yes ATAPI is.
> 
> >> The ATA driver is implemented the way one would expect it by acting 
> >> as a SCSI HBA.
> 
> >Yes, as does libata on Linux.
> 
> Then I would love to see a demo that uses /dev/sg* with a ATAPI drive 
> using DMA for all related sector sizes.

Use /dev/hdX or /dev/sdX or /dev/srX and SG_IO and it'll just work.
Wonderful, huh?

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 796 bytes --]


>From: Alan Cox <alan@lxorguk.ukuu.org.uk>

>> On Solaris, there is ACLs, RBAC & getppriv() / setppriv()
>> 
>> http://docs.sun.com/db/doc/816-5167/6mbb2jaeu?a=expand

>and Linux has capabilities, ACLs and SELinux rulesets which can
>also be used to manage this. I can give the cd burner a role that 
>permits it certain things.

If you are right, why then is SuSE removing the warnings in cdrecord
that are there to tell the user that cdrecord is running with insufficient 
privilleges?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Mon, 2004-08-09 at 16:12 +0200, Joerg Schilling wrote:
> If you are right, why then is SuSE removing the warnings in cdrecord
> that are there to tell the user that cdrecord is running with insufficient 
> privilleges?

Because those warnings are bogus, put there by someone who likes to
complain about things that are not _really_ a problem?

> Jrg

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

David Woodhouse wrote:
> On Mon, 2004-08-09 at 16:12 +0200, Joerg Schilling wrote:
> 
>>If you are right, why then is SuSE removing the warnings in cdrecord
>>that are there to tell the user that cdrecord is running with insufficient 
>>privilleges?
> 
> 
> Because those warnings are bogus, put there by someone who likes to
> complain about things that are not _really_ a problem?

Actually they are a problem on a loaded system, it's just that 
developers seem to run system with enough power to avoid the issues. And 
if you have a system using burn-free all the time you do use more track 
and the occasional device won't read it.

If someone would note the capabilities needed to allow these things 
maybe jrg would have one less thing to complain about.


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bob Tracy]

Bill Davidsen wrote:
> David Woodhouse wrote:
> > On Mon, 2004-08-09 at 16:12 +0200, Joerg Schilling wrote:
> > 
> >>If you are right, why then is SuSE removing the warnings in cdrecord
> >>that are there to tell the user that cdrecord is running with insufficient 
> >>privilleges?
> > 
> > 
> > Because those warnings are bogus, put there by someone who likes to
> > complain about things that are not _really_ a problem?
> 
> Actually they are a problem on a loaded system, it's just that 
> developers seem to run system with enough power to avoid the issues. And 
> if you have a system using burn-free all the time you do use more track 
> and the occasional device won't read it.

Another possible reason for removing the warnings (which I encountered
while trying out the latest xcdroast today): any output to stderr during
the burn is flagged by the wrapper as an error, which violates the
principle of least astonishment from a user perspective.  In other words,
no distinction is made between warnings and errors before announcing an
error has occurred.

Understanding this, it's easy enough to scan the expanded output and see
what really happened.  FWIW, I don't think removing the warnings to avoid
this issue is the correct solution.

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Llu, 2004-08-09 at 15:12, Joerg Schilling wrote:
> >Linux has capabilities, ACLs and SELinux rulesets which can
> >also be used to manage this. I can give the cd burner a role that 
> >permits it certain things.
> 
> If you are right, why then is SuSE removing the warnings in cdrecord
> that are there to tell the user that cdrecord is running with insufficient 
> privilleges?

You'd have to ask them. Probably for the reason that most vendors
remove a lot of the other weird warnings - it confuses end users.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]


>From: Jens Axboe <axboe@suse.de>

>Joergs intentions are just as clear as ever - he would much much rather
>bash linux than fix whatever issues there might be with it, because if
>they get fixed, he would have nothing else to complain about. It's
>ironic that Linux is most likely his largest user base.

You could easily prove that you are wrong:

Just fix the bugs from the List I send you and wait some time......

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Joerg Schilling wrote:
> 
> >From: Jens Axboe <axboe@suse.de>
> 
> >Joergs intentions are just as clear as ever - he would much much rather
> >bash linux than fix whatever issues there might be with it, because if
> >they get fixed, he would have nothing else to complain about. It's
> >ironic that Linux is most likely his largest user base.
> 
> You could easily prove that you are wrong:
> 
> Just fix the bugs from the List I send you and wait some time......

Most of them you don't want me to fix. If you truly wanted me to fix the
problems, I'm sure you would have provided some evidence for them to be
fixable.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

>From: Stephan von Krawczynski <skraw@ithnet.com>

>Understand this: _nobody_ expects you to know everything about 25 different
>OS's, the only thing that can be expected is that you simply listen to the
>different parties knowing the different platforms and _take their advice_,
>really not more.

While this works for most if not all OS, it does not work for Linux.

For Linux, the percentage of things that are reported incorrect to me is higher
than 80%, so I need to use my own extertise. If I would not, cdrecord would be
unusable.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Mon, 9 Aug 2004 15:46:13 +0200 (CEST)
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> >From: Stephan von Krawczynski <skraw@ithnet.com>
> 
> >Understand this: _nobody_ expects you to know everything about 25 different
> >OS's, the only thing that can be expected is that you simply listen to the
> >different parties knowing the different platforms and _take their advice_,
> >really not more.
> 
> While this works for most if not all OS, it does not work for Linux.
> 
> For Linux, the percentage of things that are reported incorrect to me is
> higher than 80%, so I need to use my own extertise. If I would not, cdrecord
> would be unusable.

If things are that bad, why don't you just take the easy path and let _others_
implement the linux-glue to your app ? All you have to do is to specify an
interface which is completely at your will.
Then, if something does not work out, it's not your problem. You can then
always draw the Solaris card and say "look, it works under solaris. So you (the
glue-author) must have made some mistake."

Regards,
Stephan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

Joerg Schilling schrieb am 2004-08-09:

> While this works for most if not all OS, it does not work for Linux.
> 
> For Linux, the percentage of things that are reported incorrect to me is higher
> than 80%, so I need to use my own extertise. If I would not, cdrecord would be
> unusable.

What ratio (percentage) of installed copies makes Linux up for? 90%? 95%?

I don't know the figures but if it were like 80% of problems for 90% of
installations, that would mean the problem count was below average.

Just a thought.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]


>From: Jens Axboe <axboe@suse.de>

>On Mon, Aug 09 2004, Joerg Schilling wrote:
>> >From axboe@suse.de  Fri Aug  6 17:10:35 2004
>> 
>> >> Let me give you a short answer: If DMA creates so many problem on Linux,
>> >> how about imlementing a generic DMA abstraction layer like Solaris does?
>> 
>> >We do have that. But suddenly changing the alignment and length
>> >restrictions on issuing dma to a device in the _end_ of a stable series
>> >does not exactly fill me with joyful expectations. It's simply that,
>> >not lack of infrastructure.
>> 
>> If you _really_ _had_ a DMA abstraction layer, then ide-scsi would use
>> DMA for all sector sizes a CD may have. The fact that ide-scsi does
>> not use DMA easily proves that you are wrong.

>For someone who apparently doesn't even bother to look at the source,
>it's hard to discuss these things. "DMA abstraction layer" continues
>your fine history of being deliberatly vague in that it can mean
>basically anything or nothing.

In case you don't know what DMA abstraction is:

DMA abstraction includes everything that is going to be done to set up
DMA after the buffer address and the size is known.

If you were true and Linux would include _and_ use DMA abstraction, then
we would have DMA with ide-scsi for all CD sector sizes.


>> AGAIN: if you believe you did invent a better method, _describe_ it.
>> As you did not describe a _working_ method different from the one I
>> request, you need to agree that you are wrong - as long as your
>> description is missing.

>I did not invent a better method, but one exists - in Linux this is the
>device special file.

Interesting: tell us more about how Linux handles kernel user interfaces by 
using a device special file instead of including the same include file 
in the kernel code as well as in the applicatin code?

>> I am able to distinct between something that only looks like a kernel
>> problem and something that really is a kernel problem. As long as you

>You've already shown that statement to be false many times in this
>thread.

YOu have only shown that you in many caes try to ignoore the truth ;-(


>Listen, you silly little man: if you want things fixed in the kernel,
>you provide a patch. Understand that concept?

Listen arrogant little man: I have enough to to with writing free software.
I report bugs and if you are the author, you fix your bugs or I need to tell
the users of your software that you are unwilling to maintain your software.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Marc Ballarin]

On Mon, 9 Aug 2004 15:36:13 +0200 (CEST)
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> 
> Listen arrogant little man: I have enough to to with writing free
> software. I report bugs and if you are the author, you fix your bugs or
> I need to tell the users of your software that you are unwilling to
> maintain your software.
>

This is what you are doing anyway. You seem to slander Linux whenever you
get the chance. (Do I need to mention the forum at www.heise.de?)

OTOH you are even distributing *binary patches* for the all-perfect
Solaris in the cdrecord distribution. And while you talk about writing
free software, you encourage people to use an operating system (Solaris)
whose license prohibits the publication of benchmark results and user
experiences.

Regards

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Joerg Schilling wrote:
> 
> >From: Jens Axboe <axboe@suse.de>
> 
> >On Mon, Aug 09 2004, Joerg Schilling wrote:
> >> >From axboe@suse.de  Fri Aug  6 17:10:35 2004
> >> 
> >> >> Let me give you a short answer: If DMA creates so many problem on Linux,
> >> >> how about imlementing a generic DMA abstraction layer like Solaris does?
> >> 
> >> >We do have that. But suddenly changing the alignment and length
> >> >restrictions on issuing dma to a device in the _end_ of a stable series
> >> >does not exactly fill me with joyful expectations. It's simply that,
> >> >not lack of infrastructure.
> >> 
> >> If you _really_ _had_ a DMA abstraction layer, then ide-scsi would use
> >> DMA for all sector sizes a CD may have. The fact that ide-scsi does
> >> not use DMA easily proves that you are wrong.
> 
> >For someone who apparently doesn't even bother to look at the source,
> >it's hard to discuss these things. "DMA abstraction layer" continues
> >your fine history of being deliberatly vague in that it can mean
> >basically anything or nothing.
> 
> In case you don't know what DMA abstraction is:

Translation from shillyness to english: In case I didn't know what Joerg
regards as DMA abstraction.

> DMA abstraction includes everything that is going to be done to set up
> DMA after the buffer address and the size is known.
> 
> If you were true and Linux would include _and_ use DMA abstraction, then
> we would have DMA with ide-scsi for all CD sector sizes.

Just because we have an api for helping drivers map data for dma,
doesn't necessarily mean that they all use it. In 2.6.8 ide-scsi will
use dma for all transfers. As I've already stated, I wont be fixing 2.4.
I've also included reasons for this. You seem to think that a 'DMA
abstraction layer' means there will be no hardware bugs, I only wish
that was so.

> >> AGAIN: if you believe you did invent a better method, _describe_ it.
> >> As you did not describe a _working_ method different from the one I
> >> request, you need to agree that you are wrong - as long as your
> >> description is missing.
> 
> >I did not invent a better method, but one exists - in Linux this is the
> >device special file.
> 
> Interesting: tell us more about how Linux handles kernel user
> interfaces by using a device special file instead of including the
> same include file in the kernel code as well as in the applicatin
> code?

We were talking about device addressing, right? Or are you ramblinb on
about API stability again?

> >> I am able to distinct between something that only looks like a kernel
> >> problem and something that really is a kernel problem. As long as you
> 
> >You've already shown that statement to be false many times in this
> >thread.
> 
> YOu have only shown that you in many caes try to ignoore the truth ;-(

I'm surprised an ego of your size can even be contained inside a
normally sized (I'm assuming, having never met you) human body. I guess
in your opinion, anything oozing from your brain is by definition the
truth? That's the only way that I can see your above sentence making
sense to you.

> >Listen, you silly little man: if you want things fixed in the kernel,
> >you provide a patch. Understand that concept?
> 
> Listen arrogant little man: I have enough to to with writing free
> software.  I report bugs and if you are the author, you fix your bugs
> or I need to tell the users of your software that you are unwilling to
> maintain your software.

Yet you refuse to do the same yourself.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

>From: Eric Lammerts <eric@lammerts.org>

>On Fri, 6 Aug 2004, Joerg Schilling wrote:
>> The CAM interface (which is from the SCSI standards group)
>> usually is implemeted in a way that applications open /dev/cam and
>> later supply bus, target and lun in order to get connected
>> to any device on the system that talks SCSI.
>>
>> Let me repeat: If you believe that this is a bad idea, give very
>> good reasons.

>With this interface, how do you grant non-root users access to a CD
>writer, but prevent them from directly accessing a SCSI harddisk?

On Linux, it is impossible to run cdrecord without root privilleges.
Make cdrecord suid root, it has been audited....

On Solaris, there is ACLs, RBAC & getppriv() / setppriv()

http://docs.sun.com/db/doc/816-5167/6mbb2jaeu?a=expand

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Karol Kozimor]

On Monday 09 of August 2004 14:24, Joerg Schilling wrote:
> On Linux, it is impossible to run cdrecord without root privilleges.
> Make cdrecord suid root, it has been audited....

[kkozimor@athlon1 kkozimor]$ cdrecord dev=/dev/hdd -atip
Cdrecord-Clone 2.01a31-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg 
Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to 
<warly@mandrakesoft.com>.
Note: The author of cdrecord should not be bothered with problems in this 
version.
scsidev: '/dev/hdd'
devname: '/dev/hdd'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.8'.
Device type    : Removable CD-ROM
Version        : 0
Response Format: 2
Capabilities   :
Vendor_info    : 'LITE-ON '
Identifikation : 'COMBO LTC-48161H'
Revision       : 'KH0M'
Device seems to be: Generic mmc2 DVD-ROM.
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE FORCESPEED
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
ATIP info from disk:
  Indicated writing power: 5
  Is not unrestricted
  Is not erasable
  Disk sub type: Medium Type B, low Beta category (B-) (4)
  ATIP start of lead in:  -11607 (97:27/18)
  ATIP start of lead out: 359849 (79:59/74)
Disk type:    Short strategy type (Phthalocyanine or similar)
Manuf. index: 18
Manufacturer: Plasmon Data systems Ltd.
[kkozimor@athlon1 kkozimor]$ ls -l `which cdrecord`
-rwxr-xr-x  1 root root 320148 cze 14 18:16 /usr/bin/cdrecord

Go figure...

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

>>From: Eric Lammerts <eric@lammerts.org>
>
>>On Fri, 6 Aug 2004, Joerg Schilling wrote:
>>> The CAM interface (which is from the SCSI standards group)
>>> usually is implemeted in a way that applications open /dev/cam and
>>> later supply bus, target and lun in order to get connected
>>> to any device on the system that talks SCSI.
>>>
>>> Let me repeat: If you believe that this is a bad idea, give very
>>> good reasons.
>
>>With this interface, how do you grant non-root users access to a CD
>>writer, but prevent them from directly accessing a SCSI harddisk?
>
> On Linux, it is impossible to run cdrecord without root privilleges.

I do it all the time, but then again I also use dev=/dev/hdc which is
also supposedly impossible.

> Make cdrecord suid root, it has been audited....

By whom?  The author?

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Llu, 2004-08-09 at 13:24, Joerg Schilling wrote:
> On Linux, it is impossible to run cdrecord without root privilleges.
> Make cdrecord suid root, it has been audited....

Wrong. Although in part that is a bug in the kernel urgently needing
a fix.

> On Solaris, there is ACLs, RBAC & getppriv() / setppriv()
> 
> http://docs.sun.com/db/doc/816-5167/6mbb2jaeu?a=expand

and Linux has capabilities, ACLs and SELinux rulesets which can
also be used to manage this. I can give the cd burner a role that 
permits it certain things.

Alan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Alan Cox wrote:
> On Llu, 2004-08-09 at 13:24, Joerg Schilling wrote:
> > On Linux, it is impossible to run cdrecord without root privilleges.
> > Make cdrecord suid root, it has been audited....
> 
> Wrong. Although in part that is a bug in the kernel urgently needing
> a fix.

Even with that fixing, write privileges on the device would be enough.
So root would still not be required.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Eric Lammerts]

On Mon, 9 Aug 2004, Joerg Schilling wrote:
> >From: Eric Lammerts <eric@lammerts.org>
>
> >On Fri, 6 Aug 2004, Joerg Schilling wrote:
> >> The CAM interface (which is from the SCSI standards group)
> >> usually is implemeted in a way that applications open /dev/cam and
> >> later supply bus, target and lun in order to get connected
> >> to any device on the system that talks SCSI.
> >>
> >> Let me repeat: If you believe that this is a bad idea, give very
> >> good reasons.
>
> >With this interface, how do you grant non-root users access to a CD
> >writer, but prevent them from directly accessing a SCSI harddisk?
>
> On Linux, it is impossible to run cdrecord without root privilleges.
> Make cdrecord suid root, it has been audited....
>
> On Solaris, there is ACLs, RBAC & getppriv() / setppriv()

Interesting. How do you use those to grant someone access to a
particular CD writer device behind /dev/cam _without_ at the same time
granting them access to other SCSI devices too? I know that it's
possible with a trusted binary (like cdrecord) that's setuid root, or
that gets some priviledges some other way, but if that is the _only_
way, then that's a flaw in the CAM interface.

On Linux you can simply change permissions on the CD writer's device
node to allow non-root users to burn CDs.

Eric

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]


>From: Linus Torvalds <torvalds@osdl.org>
>>
>> Most of all, I would like to know (I see I'm repeating myself, but I still
>> haven't seen an answer to that) what's so special about the SCSI-like devices,

>Don't even bother.

>Joerg is wrong. SCSI number simply doesn't work, and the current Linux 
>setup is absolutely the right thing to do.

Discussions are based on exchanging arguments.......

It seems that Linus is just trying to prove that he still has no arguments.
Wouln't it be wise for him to stay quiet instead of wasting other people's time?

He should takle an advise, spend 5 minutes on something useful and fix the show 
stopper bugs in /usr/src/linux/include/scsi/sg.h & 
/usr/src/linux/include/scsi/scsi.h

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

>From: Paul Jakma <paul@clubi.ie>

>That the /dev/dsk names typically encode some *logical* topology 
>information into the names is beside the point, it's just the Solaris 
>convention, the real point is that they abstract the device location, 
>so that the user is not required to know that their disk is really 
>at, eg:

> 	/devices/pci@0,0/pci-ide@7,1/ide@1/sd@0,0:d,raw

>Which is where the /dev/ node would symlink to. The /dev/ name has 
>nothing to do with physical topology (though might be vaguely 
>similar). Also note that the logical /dev/ symlink name is encoded 
>*differently* for IDE versus SCSI. Trying to plaster SCSI notations 
>into IDE topology is just not useful. Indeed, some devices are not 
>dependent on topology at all, they depend on some other topology 
>independent identifier, eg FC UUID.

Don't comment things you don't ever try.....

Of course, ATAPI devices on Solaris are handled by the same
target drivers as e.g. those on 50 pin cables.

The ATA driver is implemented the way one would expect it by acting as a SCSI 
HBA.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Paul Jakma]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=utf-8; format=flowed, Size: 594 bytes --]

On Mon, 9 Aug 2004, Joerg Schilling wrote:

>> dependent on topology at all, they depend on some other topology
>> independent identifier, eg FC UUID.
>
> Don't comment things you don't ever try.....
>
> Of course, ATAPI devices on Solaris are handled by the same
> target drivers as e.g. those on 50 pin cables.

Yes ATAPI is.

> The ATA driver is implemented the way one would expect it by acting 
> as a SCSI HBA.

Yes, as does libata on Linux.

> Jörg

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Events are not affected, they develop.
 		-- Sri Aurobindo

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

>From: Alan Cox <alan@lxorguk.ukuu.org.uk>

>BTW while I remember cdrecord has a bug with hardcoded iso8859-1
>copyright symbols in it which mean your copyright banner is invalid
>unicode on a UTF-8 locale.


It seems that you like to write unproven and thus wrong things :-(

BTW: this also appears to your comments on the Solaris device handling....
Did you ever install Solaris 10 and test?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Llu, 2004-08-09 at 12:58, Joerg Schilling wrote:
> >From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> 
> >BTW while I remember cdrecord has a bug with hardcoded iso8859-1
> >copyright symbols in it which mean your copyright banner is invalid
> >unicode on a UTF-8 locale.
> 
> 
> It seems that you like to write unproven and thus wrong things :-(

export LC_ALL=cy_GB.UTF-8
run cdrecord 
review the output. Its using a hardcoded 8859-1/15 symbols so it breaks.

> BTW: this also appears to your comments on the Solaris device handling....
> Did you ever install Solaris 10 and test?

I've seen it on older Solaris. When drives walk between scsi busses as
the system is running it doesn't like it

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]


>From: Albert Cahalan <albert@users.sourceforge.net>

>> 5) Take a look at /etc/path_to_inst and call "man path_to_inst"
>>
>> The used method even works nicely for USB devices.

>OK, I took a look.

You obviously did not :-(

Please don't try to comment things you did not verify with a
running Solaris.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Albert Cahalan]

On Mon, 2004-08-09 at 07:56, Joerg Schilling wrote:
> >From: Albert Cahalan <albert@users.sourceforge.net>
> 
> >> 5) Take a look at /etc/path_to_inst and call "man path_to_inst"
> >>
> >> The used method even works nicely for USB devices.
> 
> >OK, I took a look.
> 
> You obviously did not :-(
> 
> Please don't try to comment things you did not verify with a
> running Solaris.

If the behavior doesn't match the man page, it's buggy.

Looking through your source code, I see that several
additional OSes can handle addressing by device name,
but you've disabled this for them. I pity the users.
It's even obvious how to use drive letters on NT.

I would be happy to maintain a decent cdrecord, provided
that somebody can find me some funding. This would take
a great deal more time than procps does currently.
It would require a never-ending supply of blank disks
and, at least initially, a pile of hardware.

I'm not kidding. If some Linux distributer or Linux .org
can fund me (my kids like to eat), I'll fix this problem.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

>From James.Bottomley@SteelEye.com  Sat Aug  7 17:01:00 2004

>On Thu, 2004-08-05 at 08:00, Jens Axboe wrote:
>> On Thu, Aug 05 2004, Joerg Schilling wrote:
>> > -	Parallel (50 bin) SCSI (unknown HBA) on Linux-2.6 does not work if
>> > 	DMA size is not a multiple of 4. The data transferred from the SCSI
>> > 	device is OK for the first part that is a multiple of 4.
>> > 	The remainder of bytes arrive as binary zeroes.
>> > 
>> > 	This is a new bug (I received the related information this week).
>> 
>> Might be a hardware issue.

>Probably it is.  Lots of hardware FIFO chips are 4 or 8 bytes wide and
>can't do partial transfers (because of the way the cycle the data off
>the bus).  Usually they have logic that sends only partial fragments on
>to the device for commands, but its not unknown for them to forget this
>on actual data transfers

I did already prove that is is a driver bug. Writing again that it _may_
be a hw bug does not help.

>> That's bogus, the SCSI stack (as well as the block layer) is very well
>> capable of reporting residual counts, and if the hardware can do it (we
>> can't get it from some ide hardware :/), we will report residuals.
>> 
>> So if it doesn't work it's a bug, but not a design bug.

>Well...more likely a driver bug.  Residuals have to be reported by the
>driver.  I thought all of the drivers that could were now doing this,
>but I might have missed some...which driver is it?

For Adaptec HW

>A selection timeout is reported as DID_NO_CONNECT.

>DID_TIME_OUT is for cards that can watchdog their commands in hw and is
>what they return when the watchdog fires.

>If you actually want visibility into the SCSI mid layer timeout, that's
>harder since it feeds directly into the error handler that tries to
>ready the transport and device for action.  In general, a command that
>times out this way is retried.  If you set the FASTFAIL flag, it will
>come out with DRIVER_TIMEOUT set in its result area.

-	Retrying commands that have been send via Generic SCSI is wrong.

-	A flag called "FASTFAI" does not exist :-( 


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Joerg Schilling wrote:
> >From James.Bottomley@SteelEye.com  Sat Aug  7 17:01:00 2004
> 
> >On Thu, 2004-08-05 at 08:00, Jens Axboe wrote:
> >> On Thu, Aug 05 2004, Joerg Schilling wrote:
> >> > -	Parallel (50 bin) SCSI (unknown HBA) on Linux-2.6 does not work if
> >> > 	DMA size is not a multiple of 4. The data transferred from the SCSI
> >> > 	device is OK for the first part that is a multiple of 4.
> >> > 	The remainder of bytes arrive as binary zeroes.
> >> > 
> >> > 	This is a new bug (I received the related information this week).
> >> 
> >> Might be a hardware issue.
> 
> >Probably it is.  Lots of hardware FIFO chips are 4 or 8 bytes wide and
> >can't do partial transfers (because of the way the cycle the data off
> >the bus).  Usually they have logic that sends only partial fragments on
> >to the device for commands, but its not unknown for them to forget this
> >on actual data transfers
> 
> I did already prove that is is a driver bug. Writing again that it _may_
> be a hw bug does not help.

You proved absolutely nothing, you cannot prove anything without
evidence. That's how these things work. It could be a driver issue of
course, but so far there's been zero evidence one way or the other.

> >> That's bogus, the SCSI stack (as well as the block layer) is very well
> >> capable of reporting residual counts, and if the hardware can do it (we
> >> can't get it from some ide hardware :/), we will report residuals.
> >> 
> >> So if it doesn't work it's a bug, but not a design bug.
> 
> >Well...more likely a driver bug.  Residuals have to be reported by the
> >driver.  I thought all of the drivers that could were now doing this,
> >but I might have missed some...which driver is it?
> 
> For Adaptec HW

Ok, so Justins aic7xxx I'm thinking. scgcheck reports residual bug with
the sym driver as well, I'll take a look at it.

> >A selection timeout is reported as DID_NO_CONNECT.
> 
> >DID_TIME_OUT is for cards that can watchdog their commands in hw and is
> >what they return when the watchdog fires.
> 
> >If you actually want visibility into the SCSI mid layer timeout, that's
> >harder since it feeds directly into the error handler that tries to
> >ready the transport and device for action.  In general, a command that
> >times out this way is retried.  If you set the FASTFAIL flag, it will
> >come out with DRIVER_TIMEOUT set in its result area.
> 
> -	Retrying commands that have been send via Generic SCSI is wrong.

Agree

> -	A flag called "FASTFAI" does not exist :-( 

It's an internal flag and it does exist. I'll add the flag to block sg.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

>From albert@users.sourceforge.net  Sat Aug  7 00:57:58 2004
>Subject: Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices
>From: Albert Cahalan <albert@users.sourceforge.net>

>In various emails, Joerg Schilling writes:

>> Linux users like to call cdrecord -scanbus and they like to
>> see _all_ SCSI devices from a single call to cdrecord.

>If you really think so, you've been smoking crack.

Sorry - but I will not have discussions with people who start a discussion
with a personal insult.

If this is usual on LKML, I'd better stop _any_ discussuin that is related
to LKML......

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Mon, 2004-08-09 at 12:33 +0200, Joerg Schilling wrote:
> If this is usual on LKML, I'd better stop _any_ discussuin that is related
> to LKML......

You were already asked to do that, until such time as you can fix your
broken mailer.

> Jrg

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3296 bytes --]

>From axboe@suse.de  Fri Aug  6 17:10:35 2004

>> Let me give you a short answer: If DMA creates so many problem on Linux,
>> how about imlementing a generic DMA abstraction layer like Solaris does?

>We do have that. But suddenly changing the alignment and length
>restrictions on issuing dma to a device in the _end_ of a stable series
>does not exactly fill me with joyful expectations. It's simply that,
>not lack of infrastructure.

If you _really_ _had_ a DMA abstraction layer, then ide-scsi would use DMA
for all sector sizes a CD may have. The fact that ide-scsi does not
use DMA easily proves that you are wrong.


>> Please try to distinct between threads I did start and threads I have
>> been drawn into. I am open to any serious discussion, however if you
>> like to insist in things that have been agreed on being suboptimal for
>> more than 20 years, you should have very good reasons _and_ be willing
>> to explain them.

>Agreed between whom? I don't agree that this naming is sound, in fact I
>think it's quite stupid.

If you like to call the Sun developers and the FreeBSD developers (which means 
people like Bill Joy and Scott Mcusick) stupid, you seem to have a real
strange idea from the world :-(

AGAIN: if you believe you did invent a better method, _describe_ it.
As you did not describe a _working_ method different from the one I request,
you need to agree that you are wrong - as long as your description is missing.



>I am focused on Linux, that's what I work on. And I truly think the
>device naming option is so much easier for users that it's not even
>funny.

So let me use other words: While I am focussed on the cdrtools uses on _all_
platforms, you are not :-(

 
>> As 50% of all problems reported for cdrecord on Linux look like Linux
>> kernel problems, this is what I do every day.

>Just because they look like Linux kernel problems, doesn't mean that
>they are :-)

I am able to distinct between something that only looks like a kernel problem
and something that really is a kernel problem. As long as you define everything
to be a non kernel problem :-( see the Linux Kernel bug with 
SG_SET_RESERVED_SIZE) I don't know how to continue the discussion with you.


>A textual description of the problem is not a fix. Or did I miss the
>patch? If so, I apologize.

Being able to read seems to be a real advantage....

>> The importance could be limited if there were unique instance numbers
>> for ATAPI devices using the same address space as the other SCSI
>> devices.  For now, ide-scsi is really important.

>It's not the same address space, so there is not.

Well you just did prove that forcing people to send SCSI commands via 
non SCSI parts of the kernel is a design bug

>> Let's see whether "Linux" is open enough to listen to the demands of
>> the users......

>We try, when they make sense...

You should learn what "make sense" means, Linux-2.6 is a clear move away from 
the demands of a Linux user who likes to write CDs/DVDs.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Joerg Schilling wrote:
> >From axboe@suse.de  Fri Aug  6 17:10:35 2004
> 
> >> Let me give you a short answer: If DMA creates so many problem on Linux,
> >> how about imlementing a generic DMA abstraction layer like Solaris does?
> 
> >We do have that. But suddenly changing the alignment and length
> >restrictions on issuing dma to a device in the _end_ of a stable series
> >does not exactly fill me with joyful expectations. It's simply that,
> >not lack of infrastructure.
> 
> If you _really_ _had_ a DMA abstraction layer, then ide-scsi would use
> DMA for all sector sizes a CD may have. The fact that ide-scsi does
> not use DMA easily proves that you are wrong.

For someone who apparently doesn't even bother to look at the source,
it's hard to discuss these things. "DMA abstraction layer" continues
your fine history of being deliberatly vague in that it can mean
basically anything or nothing.

> >> Please try to distinct between threads I did start and threads I have
> >> been drawn into. I am open to any serious discussion, however if you
> >> like to insist in things that have been agreed on being suboptimal for
> >> more than 20 years, you should have very good reasons _and_ be willing
> >> to explain them.
> 
> >Agreed between whom? I don't agree that this naming is sound, in fact I
> >think it's quite stupid.
> 
> If you like to call the Sun developers and the FreeBSD developers
> (which means people like Bill Joy and Scott Mcusick) stupid, you seem
> to have a real strange idea from the world :-(

I'm not calling anyone stupid, I'm saying that applying that addressing
to all types of devices across all OS's is stupid. And I believe you are
the one trying to do that, not any of the above mentioned people.

> AGAIN: if you believe you did invent a better method, _describe_ it.
> As you did not describe a _working_ method different from the one I
> request, you need to agree that you are wrong - as long as your
> description is missing.

I did not invent a better method, but one exists - in Linux this is the
device special file.

> >I am focused on Linux, that's what I work on. And I truly think the
> >device naming option is so much easier for users that it's not even
> >funny.
> 
> So let me use other words: While I am focussed on the cdrtools uses on
> _all_ platforms, you are not :-(

Of course I'm not, I don't hack the beast. I believe your notion of
trying to use one grand unified addressing scheme all over is completely
broken. That you attempt to shove that down the throat of Linux is your
issue, I could not care less.

> >> As 50% of all problems reported for cdrecord on Linux look like Linux
> >> kernel problems, this is what I do every day.
> 
> >Just because they look like Linux kernel problems, doesn't mean that
> >they are :-)
> 
> I am able to distinct between something that only looks like a kernel
> problem and something that really is a kernel problem. As long as you

You've already shown that statement to be false many times in this
thread.

> define everything to be a non kernel problem :-( see the Linux Kernel
> bug with SG_SET_RESERVED_SIZE) I don't know how to continue the
> discussion with you.

As I've said before, of course there are bugs in the kernel. At least I
can stand up and say "yes that's a bug, my fault, I'll fix it". I don't
even need 20 years of experience to do that.

> >A textual description of the problem is not a fix. Or did I miss the
> >patch? If so, I apologize.
> 
> Being able to read seems to be a real advantage....

Listen, you silly little man: if you want things fixed in the kernel,
you provide a patch. Understand that concept?

> >> The importance could be limited if there were unique instance numbers
> >> for ATAPI devices using the same address space as the other SCSI
> >> devices.  For now, ide-scsi is really important.
> 
> >It's not the same address space, so there is not.
> 
> Well you just did prove that forcing people to send SCSI commands via
> non SCSI parts of the kernel is a design bug

Whatever.

> >> Let's see whether "Linux" is open enough to listen to the demands of
> >> the users......
> 
> >We try, when they make sense...
> 
> You should learn what "make sense" means, Linux-2.6 is a clear move
> away from the demands of a Linux user who likes to write CDs/DVDs.

It's a move away from your silly idea of what users want. It's a move in
the right direction.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Jens Axboe <axboe@suse.de> writes:

>> You should learn what "make sense" means, Linux-2.6 is a clear move
>> away from the demands of a Linux user who likes to write CDs/DVDs.
>
> It's a move away from your silly idea of what users want. It's a move in
> the right direction.

I'll second that.  In fact, burning CDs, with the infamous cdrecord,
works better than ever with Linux 2.6.  And, yes, I'm using
dev=/dev/cdrom or similar.  Thanks for the silly warning btw, it makes
for a good laugh every time I need to burn a CD.

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Con Kolivas]

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

Joerg Schilling wrote:
>>From axboe@suse.de  Fri Aug  6 17:10:35 2004
>>We try, when they make sense...
> 
> 
> You should learn what "make sense" means, Linux-2.6 is a clear move away from 
> the demands of a Linux user who likes to write CDs/DVDs.

Could have fooled me. I'm a linux user who writes lots of cds and I had 
heaps of trouble scanning busses and trains and automobiles on the atapi 
interface till I could do a simple

dev=/dev/hdd

Seems they listened to this user.

Cheers,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Mon, 9 Aug 2004 12:13:26 +0200 (CEST)
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> If you like to call the Sun developers and the FreeBSD developers (which
> means people like Bill Joy and Scott Mcusick) stupid, you seem to have a real
> strange idea from the world :-(

Please stop throwing names as supporters into the ring that very likely are not
listening! This is pretty bad style...
 
> AGAIN: if you believe you did invent a better method, _describe_ it.
> As you did not describe a _working_ method different from the one I request,
> you need to agree that you are wrong - as long as your description is
> missing.

You obviously did not get the basics of the whole story, did you? I really
wonder how you came this far.
_You_ are writing code that should be - according to _your_ idea - platform
independent. If you do something like this it is most obvious that your code
falls mainly into two pieces: 
a) platform-independent code
b) glue code to the specific host/platform
You have full control over a) and certain unbreakable external requirements for
b).
Listening to your posts makes me wonder what your intention really is. Linux
should be only another host/platform for a new set of glue code, but it seems
you are unable to produce a working code. Instead of listening to people
_knowing_ the platform _you_ tell _them_ how they should change their code to
match your ideas.
You definitely should give a damn about the platform being well-designed or
worse, the only really interesting thing for you should be how to fit into it.
If you did it right glueing should only be about 5-10% of your whole code.
And you should be able to specify some interface for people writing glue code
for your application.
Neither you do. So what do you want _at all_ ??

Understand this: _nobody_ expects you to know everything about 25 different
OS's, the only thing that can be expected is that you simply listen to the
different parties knowing the different platforms and _take their advice_,
really not more.

Please stop being blinded by your very own glory...
People are only trying to help you.

Regards,
Stephan
(written portable driver code for: AmigaOS, DOS, Linux, Netware 3.X, 4.X,
Some Unix's, Windows 3.X, NT4, XP)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Stephan von Krawczynski wrote:
> > AGAIN: if you believe you did invent a better method, _describe_ it.
> > As you did not describe a _working_ method different from the one I request,
> > you need to agree that you are wrong - as long as your description is
> > missing.
> 
> You obviously did not get the basics of the whole story, did you? I really
> wonder how you came this far.
> _You_ are writing code that should be - according to _your_ idea - platform
> independent. If you do something like this it is most obvious that your code
> falls mainly into two pieces: 
> a) platform-independent code
> b) glue code to the specific host/platform
> You have full control over a) and certain unbreakable external requirements for
> b).
> Listening to your posts makes me wonder what your intention really is. Linux

Joergs intentions are just as clear as ever - he would much much rather
bash linux than fix whatever issues there might be with it, because if
they get fixed, he would have nothing else to complain about. It's
ironic that Linux is most likely his largest user base.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jesse Stockall]

On Mon, 2004-08-09 at 06:13, Joerg Schilling wrote:
> 
> You should learn what "make sense" means, Linux-2.6 is a clear move away from 
> the demands of a Linux user who likes to write CDs/DVDs.

Hmmm, as a Linux user who had been fighting with scsi emulation and
cdecord --scanbus for years, being able to use dev=/dev/hda is so much
easier and so much more in tune with the way the rest of Linux works. 

If you don't believe me, spend some time on irc channels like #gentoo or
#debian where people like me (and many others) give support to Linux and
cdrecord users from all over the world.

Jesse 

-- 
Jesse Stockall <stockall@magma.ca>

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

Joerg Schilling schrieb am 2004-08-09:

> >We try, when they make sense...
> 
> You should learn what "make sense" means, Linux-2.6 is a clear move away from 
> the demands of a Linux user who likes to write CDs/DVDs.

Or so you think.

cdrecord dev=/dev/hdd ... on 2.6 has given me what 2.4 didn't do:
DMA for non-2048 block sizes.

I agree that I'd rather have seen ide-scsi fixed than yet another
interface extended, but if I use /dev/sg4 or /dev/hdd, doesn't really
matter.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Albert Cahalan]

Stephan von Krawczynski writes:

> Maybe you should not overestimate cdrecord as a tool
> (like its author obviously does sometimes). At least
> for DVD there are well-working alternatives.

Unfortunately there is quite a bit of knowledge embedded
in cdrecord. There are _lots_ of weird formats and burners
to take care of. Testing costs real money. Mistakes will
cost real money for many other people.

Sorry. **ahem** This would be an easy project...

> If Joerg feels a better home on Solaris, so be it. 
> It's his right to decide for solaris, just as it is
> a users' right to decide against cdrecord.

True.

Oddly, he did admit that Solaris will support direct usage
of the device names. Here's his list of good systems:

Linux
AIX
BSD-OS (eh, meaning BSDI maybe?)
OpenBSD 
HP-UX   
SGI IRIX
Solaris

Here are the bad systems:

obsolete releases of Linux and Solaris
dead OSes like DOS, DomainOS, AmigaOS, BeOS, NeXT, SunOS 4
nearly dead: VMS, OS/2, Tru64 
SCO crap: OpenServer, UnixWare
Windows
MacOS X
QNX
FreeBSD (Maybe it's dying? It's a BSD.)

If support for the bad systems were discontinued, FreeBSD and
MacOS X would most likely be fixed up soon. Maybe QNX too.
The others can sink. Supporting SCO is just plain wrong.

So you certainly could fork this, drop the silly naming, and
still support the OSes worth caring about.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

	---->	This is a resend as it seems that somebody did remove
		linux-kernel@vger.kernel.org

>From: "H.Rosmanith (Kernel Mailing List)" <kernel@wildsau.enemy.org>

>> I can just that if you set 64KiB now, it'll be a much better alround
>> value.

>very good, it works with 64kB:

>    887         /*
>    888          * First try to raise the DMA limit to a moderate value that
>    889          * most likely does not use up all kernel memory.
>    890          */
>    891         //val = 126*1024;
>    892         val = 64*1024;

>now cdrecord will happily use the scsi-linux-sg driver even for the IDE
>burners connected to the "Digitus" controllers handled by the siimage driver.

So you found a nasty bug in the Linux kernel :-(

The official behavior for SG_SET_RESERVED_SIZE is:

1)	You call SG_SET_RESERVED_SIZE with whatever size val you like

2)	It says "thank you" and _always_ returns success

3)	You call SG_GET_RESERVED_SIZE to read the value set up
	in the kernel. This value is not directly related to the value
	used with SG_SET_RESERVED_SIZE. The proposal from Douglas
	Gilbert was to always use 512 KB. I am unhappy with this behavior
	but I have to take it as it has been defined by the Author :-(
	He told me that the value returned with SG_GET_RESERVED_SIZE
	is the value available for DMA and may be much smaller than
	the size used with SG_SET_RESERVED_SIZE.

AGAIN: I am unhappy with this behavior but this _is_ the official behavior.
If the current Linux kernel for some reasons does not behave this way it
is broken and needs to be fixed.

See also: http://www.mail-archive.com/cdwrite@other.debian.org/msg00232.html

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Albert Cahalan]

> 5) Take a look at /etc/path_to_inst and call "man path_to_inst"
>
> The used method even works nicely for USB devices.

OK, I took a look.

Solaris is mapping from devfs to dev_t with this file.
You start with a device patch like this:
    /iommu@f,e0000000/sbus@f,e0001000/sbusmem@f,0
It maps to a driver name and instance number:
    sbusmem   15
The driver name implys the major number. (in a dev_t)
The instance number is, more or less, the minor number.

Linux does something like this too now, using "udev"
and the rest of the hotplug stuff. Linux is better.
Linux lets you map from most any device attribute
(bus, serial number, vendor, scsi level, speed...)
to a device name.

Oh, the dev_t value? That's becoming a random number.
Users don't need it, and shouldn't have to deal with it.
They have the device name. Bus numbers are random too.

So let's suppose I plug in two FireWire CD burners.
The Que!Fire one is mapped to /dev/quefire-cdrw,
and the Sony one is mapped to /dev/sony-cdrw. The
device numbers will vary, as will any bus numbers,
but the users don't care. They have nice names.

Suppose I kick the FireWire cable loose. The device
nodes in /dev go away. Then I plug the cable back in,
and new device nodes appear. The numbers might change!
No matter what the numbers though, the drives always
get the names that I have assigned to them.

Before I kick the cable loose:

dev=0,0,1  matches with  /dev/quefire-cdrw
dev=0,0,2  matches with  /dev/sony-cdrw

After I plug the cable back in:

dev=0,0,0  matches with  /dev/quefire-cdrw
dev=0,0,1  matches with  /dev/sony-cdrw

Everything's cool for apps that use device names.
Only cdrecord will try to access the wrong device.

I'm sure this dynamic world isn't appealing to you.
People do kick cables loose though, and they do like
having nice device names. The days of jumpers are
long gone. Plug-and-play is here to stay, even while
the machine is running. CAM-based operating systems
will have some adjusting to do if they are to survive.

Go ahead and drop support for old Linux kernels.
Users with old kernels can use the old cdrecord.
Handling Linux 2.6.x well means using /dev names.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Albert Cahalan <albert@users.sf.net> writes:

> Go ahead and drop support for old Linux kernels.
> Users with old kernels can use the old cdrecord.
> Handling Linux 2.6.x well means using /dev names.

And the funniest thing is all that's needed is to remove the silly
warning printed by cdrecord.

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]


>From: Martin Mares <mj@ucw.cz>

>> It seems that you are not really interested to understand how it works :-(

>I am interested, but I life is too short to read the full docs of all existing
>OS's. Can you give me at least a pointer to the relevant section?

I already did! ---> "man path_to_inst"

>> If you behave this way, I tend to believe that you have a precasted opinion 
>> that you are not willing to change.

>I think that most people around there tend to believe exactly the same about you :-)
>But let's change that.

I _am_ always open to new experiences but the problem with most if not all
of the people in LKML is that they only know things about Linux while I know 
many different operating systems.

>Most of all, I would like to know (I see I'm repeating myself, but I still
>haven't seen an answer to that) what's so special about the SCSI-like devices,
>that they would have to be addressed in a completely different way from the
>other UNIX devices. For the classical SCSI, you might argue that addressing
>by the physical topology is more realistic, but for ATAPI or USB disks,
>the SCSI triplets have nothing to do with the physical topology.

I did introduce Generic SCSI in August 1986. The interface used by libscg today 
is exactly the same interface as it has been used in August 1986.

The problem with Linux is that the "interfaces" constantly change.
Let us talk again in October 2018 (then the /dev/hd* Interface on Linux
would have the same age as my libscg has now) and check what happened to this
interface. If the interface did not change and is still binary compatible, you 
_may_ be right. However this is most improbable.

>From the > 20 platforms that libscg provides abstractions from, _most_
platforms do not allow the "UNIX" /dev/something method to work with
Generic SCSI:

-	DOS

-	Win9x

-	WinNT

-	VMS

-	MacOS X

-	AmigaOS

-	Apollo DomainOS

-	BeOS (uses CAM)

-	FreeBSD (uses CAM)

-	Next Step (Generic SCSI only works only with a special /dev/sg%d)

-	OS/2

-	OSF-1 / True-64 (uses CAM)

-	QNX (uses CAM)

-	SunOS-4.x

-	Linux (all older versions)

-	SCO OpenServer

-	SCO UnixWare

These are the platforms where /dev/something could work:

-	Linux-2.6 

-	AIX

-	BSD-OS

-	OpenBSD

-	HP-UX

-	SGI IRIX

-	Solaris (newer versions only)

As you see, the vast majority does not allow the adressing method the
people on LKML seem to prefer recently.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Nicholas Miell]

On Sat, 2004-08-07 at 05:17, Joerg Schilling wrote:
> >From the > 20 platforms that libscg provides abstractions from, _most_
> platforms do not allow the "UNIX" /dev/something method to work with
> Generic SCSI:
> 
[ long list omitted ]
> 
> These are the platforms where /dev/something could work:
> 
[ shorter list omitted ]
> 
> As you see, the vast majority does not allow the addressing method the
> people on LKML seem to prefer recently.
> 
> Jrg

As a user of cdrecord, could you explain to me why referring to my CD
burner as 1,0,0 is preferable to /dev/cdrw?

-- Nicholas

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Nicholas Miell]

[ Different address, hopefully mailhub.fokus.fraunhofer.de won't drop it
this time. For those of you who've already seen this once, sorry. ]

On Sat, 2004-08-07 at 05:17, Joerg Schilling wrote:
> From the > 20 platforms that libscg provides abstractions from, _most_
> platforms do not allow the "UNIX" /dev/something method to work with
> Generic SCSI:
> 
[ long list omitted ]
> 
> These are the platforms where /dev/something could work:
> 
[ shorter list omitted ]
> 
> As you see, the vast majority does not allow the addressing method the
> people on LKML seem to prefer recently.
> 
> Jrg

As a user of cdrecord, could you explain to me why referring to my CD
burner as 1,0,0 is preferable to /dev/cdrw?

-- Nicholas

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frediano Ziglio]

Il sab, 2004-08-07 alle 14:17, Joerg Schilling ha scritto:
> >From: Martin Mares <mj@ucw.cz>
> 
> >> It seems that you are not really interested to understand how it works :-(
> 
> >I am interested, but I life is too short to read the full docs of all existing
> >OS's. Can you give me at least a pointer to the relevant section?
> 
> I already did! ---> "man path_to_inst"
> 

... omissis ...

Could we start again this thread in a less polemical way ??

>From my point of view there are two problems:
1- linux device naming
2- linux cd-rom problems (real or not)

1- My experience with unices it's not so long however taking a HP-UX
course I liked very much having tools to scan for new hardware and a
unique device identification numbering however I don't understand why a
single device should have many different devices based on behavior (like
scd0/sg0, raw/not raw, video0/audio for a grabber and so on). A friend
of mine (not a Linux guru but a simple user) simply said "why there are
so many files in /dev ?"

2- since we all use cdrecord (and/or its library) to burn CDs under
Linux if cdrecord do not works under Linux users (me too) thinks that
Linux do not support well cd-burning. So scgcheck has to work. There are
also some recent mail on LKML about cd-burning problems (with firewire
and usb) so there are some problems... I experience "no error" errors
too (so I can confirm it's a real problem).

freddy77

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[V13]

On Saturday 07 August 2004 15:17, Joerg Schilling wrote:
> From the > 20 platforms that libscg provides abstractions from, _most_
>
> platforms do not allow the "UNIX" /dev/something method to work with
> Generic SCSI:
>
[listt #1]
>
> These are the platforms where /dev/something could work:
>
[list #2]
>
> As you see, the vast majority does not allow the adressing method the
> people on LKML seem to prefer recently.

First of all, you're comparing non-unix to unix operating systems and you're 
trying to create a universal naming scheme. At exactly the same time, those 
operating systems that you're refering to are not able to distinguish between 
two identical USB recorders.

So, lets say for windows, you believe that when having two identical USB CDRs 
plugged in, it is better for the user to refer to them as 1,0,0 and 1,1,0 
instead of K: and L: ? For me none of this makes sense, but I believe that 
the user will prefer the letter naming scheme. 

I believe that X:Y:Z makes sense when dealing with devices that can have an ID 
by attaching a jumper but not for the 2004 devices. 

My point is that you cannot blame linux for beeing correct. The behaviour of 
the OSes that you're describing may be portable but is not user friendly or 
correct (in fact, it can be called broken).

I believe that if you were trying to create a new naming scheme you'd create 
something similar to /udev. You'd use names for devices and let the user or 
other programs associate those names to each hardware device instead of using 
numbers that some times are fixed and some times are changing between each 
boot.

You've created a great tool that is used by almost every non-windows user out 
here and it would be great if you could try to make it more usable and 
'correct'.

<<V13>>

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Thomas Richter]

Hi Jörg,

> >From the > 20 platforms that libscg provides abstractions from, _most_
> platforms do not allow the "UNIX" /dev/something method to work with
> Generic SCSI:

> -	AmigaOS

/* snip */

I've been following this discussion for quite a while now, fairly interested,
mainly as a user of cdrecord and linux, you here you're going a bit over the
edge. Having had my home at AmigaOs for quite a while, I should possibly
add my two cents that your above argument is pretty much "bogus".

For first, there is nothing like a CAM interface on Amiga, neither on MacOs.
MacOs implements (or at least, up to Os 9) implemented SCSI by its own
"scsi-manager" interface which is "all but CAM". It is more or less a pretty
bad abstraction of a pretty bad (hand-rolled) SCSI chipset Apple choose to
implement in the early Mac's, not much more.

As for AmigaOs, there's also nothing like a standardized SCSI interface.
Instead, you'd had to talk to the device driver ("kinna like /dev/hda") 
directly using HD_SCSICMD, which is closer to the proposed Linux device
driver interface than the "dev" setting you're putting forward. There's
no /dev, and thus there's no /dev/hda, but there's possibly a scsi.device
or an oktagon.device you had to talk to, and that's much closer to the
Linux /dev/hdx raw device interface than to CAM.

If you'd like to have an internal CAM layer, then this is possibly a good
idea to integrate cdrecord into various operating systems (if you like
to count AmigaOs as one), but as user frontend, this is a pretty bad idea.
One should talk to users in a way that integrates into the host environment,
and not in some kind of standard specified environment. After all, standards
are made to make things simpler - instead cdrecord makes things harder
by trying to follow standards that are not the standards of the host.

And please, don't tell that I'm "Linux centric". I've much more ideas
about the internal wiring of other operating systems than Linux.

> These are the platforms where /dev/something could work:

+ AmigaOs, if you prefer to count.

But, as I said, this is a non-argument. The tools should integrate into
the environment, and keeping things managable for the user should be the
goal.

Whether Linux should choose CAM as interface is another question - with
ATAPI much more popular than SCSI nowadays, one might consider this of
less importance, possibly.

Sorry, just my 0.02 Euro.

So long,
	Thomas

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Gene Heskett]

On Monday 09 August 2004 04:13, Thomas Richter wrote:
>Hi Jörg,
>
>> >From the > 20 platforms that libscg provides abstractions from,
>> > _most_
>>
>> platforms do not allow the "UNIX" /dev/something method to work
>> with Generic SCSI:
>>
>> -	AmigaOS
>
>/* snip */
>
>I've been following this discussion for quite a while now, fairly
> interested, mainly as a user of cdrecord and linux, you here you're
> going a bit over the edge. Having had my home at AmigaOs for quite
> a while, I should possibly add my two cents that your above
> argument is pretty much "bogus".
>
>For first, there is nothing like a CAM interface on Amiga, neither
> on MacOs. MacOs implements (or at least, up to Os 9) implemented
> SCSI by its own "scsi-manager" interface which is "all but CAM". It
> is more or less a pretty bad abstraction of a pretty bad
> (hand-rolled) SCSI chipset Apple choose to implement in the early
> Mac's, not much more.
>
>As for AmigaOs, there's also nothing like a standardized SCSI
> interface. Instead, you'd had to talk to the device driver ("kinna
> like /dev/hda") directly using HD_SCSICMD, which is closer to the
> proposed Linux device driver interface than the "dev" setting
> you're putting forward. There's no /dev, and thus there's no
> /dev/hda, but there's possibly a scsi.device or an oktagon.device
> you had to talk to, and that's much closer to the Linux /dev/hdx
> raw device interface than to CAM.
>
>If you'd like to have an internal CAM layer, then this is possibly a
> good idea to integrate cdrecord into various operating systems (if
> you like to count AmigaOs as one), but as user frontend, this is a
> pretty bad idea. One should talk to users in a way that integrates
> into the host environment, and not in some kind of standard
> specified environment. After all, standards are made to make things
> simpler - instead cdrecord makes things harder by trying to follow
> standards that are not the standards of the host.
>
>And please, don't tell that I'm "Linux centric". I've much more
> ideas about the internal wiring of other operating systems than
> Linux.
>
>> These are the platforms where /dev/something could work:
>
>+ AmigaOs, if you prefer to count.
>
>But, as I said, this is a non-argument. The tools should integrate
> into the environment, and keeping things managable for the user
> should be the goal.
>
>Whether Linux should choose CAM as interface is another question -
> with ATAPI much more popular than SCSI nowadays, one might consider
> this of less importance, possibly.
>
>Sorry, just my 0.02 Euro.
>
>So long,
>	Thomas
>
And, FWIW, let me assure you all that Thomas Richter does indeed 
understand what he is talking about.  He almost single-handedly 
brought the still broken AmigaOS3.1 into the modern age of being able 
to use hard drives of any size.  His work on the amiga's long after 
commode door took the money and ran to the bahamas will be forever 
appreciated by the remaining users of this once fine machine.  

Unforch, that leaves me out as a failing hard drive wrecked quite a 
bit of my once awesome system.  And thats when I discovered that the 
backup programs, regardless of what you paid for it, were worthless 
as they were not able to backup any file with an open lock on it, eg 
anything that was running.  Rather hard to restore the system when 
the system itself is missing from the backups.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.24% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Helge Hafting]

Joerg Schilling wrote:

>>From: Martin Mares <mj@ucw.cz>
>>    
>>
>
>  
>
>>>It seems that you are not really interested to understand how it works :-(
>>>      
>>>
>
>  
>
>>I am interested, but I life is too short to read the full docs of all existing
>>OS's. Can you give me at least a pointer to the relevant section?
>>    
>>
>
>I already did! ---> "man path_to_inst"
>
>  
>
>>>If you behave this way, I tend to believe that you have a precasted opinion 
>>>that you are not willing to change.
>>>      
>>>
>
>  
>
>>I think that most people around there tend to believe exactly the same about you :-)
>>But let's change that.
>>    
>>
>
>I _am_ always open to new experiences but the problem with most if not all
>of the people in LKML is that they only know things about Linux while I know 
>many different operating systems.
>
>  
>
>>Most of all, I would like to know (I see I'm repeating myself, but I still
>>haven't seen an answer to that) what's so special about the SCSI-like devices,
>>that they would have to be addressed in a completely different way from the
>>other UNIX devices. For the classical SCSI, you might argue that addressing
>>by the physical topology is more realistic, but for ATAPI or USB disks,
>>the SCSI triplets have nothing to do with the physical topology.
>>    
>>
>
>I did introduce Generic SCSI in August 1986. The interface used by libscg today 
>is exactly the same interface as it has been used in August 1986.
>
>The problem with Linux is that the "interfaces" constantly change.
>Let us talk again in October 2018 (then the /dev/hd* Interface on Linux
>would have the same age as my libscg has now) and check what happened to this
>interface. If the interface did not change and is still binary compatible, you 
>_may_ be right. However this is most improbable.
>
>>From the > 20 platforms that libscg provides abstractions from, _most_
>platforms do not allow the "UNIX" /dev/something method to work with
>Generic SCSI:
>
>-	DOS
>
>-	Win9x
>
>-	WinNT
>
>-	VMS
>
>-	MacOS X
>
>-	AmigaOS
>
>-	Apollo DomainOS
>
>-	BeOS (uses CAM)
>
>-	FreeBSD (uses CAM)
>
>-	Next Step (Generic SCSI only works only with a special /dev/sg%d)
>
>-	OS/2
>
>-	OSF-1 / True-64 (uses CAM)
>
>-	QNX (uses CAM)
>
>-	SunOS-4.x
>
>-	Linux (all older versions)
>
>-	SCO OpenServer
>
>-	SCO UnixWare
>
>These are the platforms where /dev/something could work:
>
>-	Linux-2.6 
>
>-	AIX
>
>-	BSD-OS
>
>-	OpenBSD
>
>-	HP-UX
>
>-	SGI IRIX
>
>-	Solaris (newer versions only)
>
>As you see, the vast majority does not allow the adressing method the
>people on LKML seem to prefer recently.
>  
>
People with different os'es prefer different adressing schemes.  It is
that simple, they don't want to use the scheme used in another os. Not
even if you think it is better somehow.  Most people don't want to deal 
with many os'es.

If you want to provide a multi-platform app with an acceptable user 
interface, then
you have to cope with the different adressing schemes.  If that is too much
work, consider taking patches from volunteers similiar to how the linux 
kernel
and many other big projects are managed.  I am sure you can get someone to
write "perfect" support for /dev/XYZ on linux for you, if you're willing 
to apply
such a patch.  And similiar for other os'es that diverge from your own 
preferred way.

Helge Hafting

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Helge Hafting <helge.hafting@hist.no> writes:

> If you want to provide a multi-platform app with an acceptable user
> interface, then you have to cope with the different adressing
> schemes.  If that is too much work, consider taking patches from
> volunteers similiar to how the linux kernel and many other big
> projects are managed.  I am sure you can get someone to write
> "perfect" support for /dev/XYZ on linux for you, if you're willing
> to apply such a patch.

How's this for a start?

--- libscg/scsi-linux-sg.c~     2004-01-14 18:54:01 +01:00
+++ libscg/scsi-linux-sg.c      2004-08-09 14:05:03 +02:00
@@ -476,10 +476,6 @@
                        b = device[7] - 'a';
                        if (b < 0 || b > 25)
                                b = -1;
-               }
-               if (scgp->overbose) {
-                       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);

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]


>From: Martin Mares <mj@ucw.cz>

>> >Well, so could you please enlighten the Linux people and say in a couple
>> >of words how it could be done?
>> 
>> 1)	Fetch the Solaris install CD images from:
>> 	http://wwws.sun.com/software/solaris/solaris-express/get.html

>Grrr!  I wanted you to describe the solution, not how to install Solaris!

You wanted to get a description in 'a few words' - this cannot be done.

.... So I instucted you how to get the full desciption. 

You may of course look yourself for the documentation at docs.sun.com.......

It seems that you are not really interested to understand how it works :-(
If you behave this way, I tend to believe that you have a precasted opinion 
that you are not willing to change.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> You wanted to get a description in 'a few words' - this cannot be done.
> 
> .... So I instucted you how to get the full desciption. 
> 
> You may of course look yourself for the documentation at docs.sun.com.......
> 
> It seems that you are not really interested to understand how it works :-(

I am interested, but I life is too short to read the full docs of all existing
OS's. Can you give me at least a pointer to the relevant section?

> If you behave this way, I tend to believe that you have a precasted opinion 
> that you are not willing to change.

I think that most people around there tend to believe exactly the same about you :-)
But let's change that.

Most of all, I would like to know (I see I'm repeating myself, but I still
haven't seen an answer to that) what's so special about the SCSI-like devices,
that they would have to be addressed in a completely different way from the
other UNIX devices. For the classical SCSI, you might argue that addressing
by the physical topology is more realistic, but for ATAPI or USB disks,
the SCSI triplets have nothing to do with the physical topology.

				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
Only dead fish swim with the stream.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Linus Torvalds]

On Sat, 7 Aug 2004, Martin Mares wrote:
>
> Most of all, I would like to know (I see I'm repeating myself, but I still
> haven't seen an answer to that) what's so special about the SCSI-like devices,

Don't even bother.

Joerg is wrong. SCSI number simply doesn't work, and the current Linux 
setup is absolutely the right thing to do.

If Joerg keeps breaking cdrecord, the distributions will hopefully just 
keep unbreaking it. The way you send SCSI commands to a device under Linux 
is to open the device (with O_NDELAY) and then just start sending the 
commands. None of the idiotic scanning and SCSI numbering crap.

Involving Joerg in it just makes you go crazy. Don't bother.

		Linus

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Thomas Molina]

Now that we've had our regularly-scheduled cdrecord imbriglio (my word for 
today), can we get on to one of our other periodic arguments?

> Joerg is wrong. SCSI number simply doesn't work, and the current Linux 
> setup is absolutely the right thing to do.
> 
> If Joerg keeps breaking cdrecord, the distributions will hopefully just 
> keep unbreaking it. The way you send SCSI commands to a device under Linux 
> is to open the device (with O_NDELAY) and then just start sending the 
> commands. None of the idiotic scanning and SCSI numbering crap.
> 
> Involving Joerg in it just makes you go crazy. Don't bother.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jesper Juhl]

On Sat, 7 Aug 2004, Joerg Schilling wrote:

> 
> >From: Martin Mares <mj@ucw.cz>
> 
> >> >Well, so could you please enlighten the Linux people and say in a couple
> >> >of words how it could be done?
> >> 
> >> 1)	Fetch the Solaris install CD images from:
> >> 	http://wwws.sun.com/software/solaris/solaris-express/get.html
> 
> >Grrr!  I wanted you to describe the solution, not how to install Solaris!
> 
> You wanted to get a description in 'a few words' - this cannot be done.
> 
> .... So I instucted you how to get the full desciption. 
> 
> You may of course look yourself for the documentation at docs.sun.com.......
> 
For those looking for a link to the man page in question  path_to_inst(4) 
: http://docs.sun.com/db/doc/816-5174/6mbb98uhn?q=path_to_inst&a=view


--
Jesper Juhl <juhl-lkml@dif.dk>

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]


>From: Martin Mares <mj@ucw.cz>

>> I see always the same answers from Linux people who don't know anyrthing than
>> their belly button :-(
>> 
>> Chek Solaris to see that your statements are wrong.

>Well, so could you please enlighten the Linux people and say in a couple
>of words how it could be done?

1)	Fetch the Solaris install CD images from:
	http://wwws.sun.com/software/solaris/solaris-express/get.html

	Solaris is free for personal use and free for being used to 
	develop OSS.

2)	"unzip" the CD images

3)	use cdrecord to write the CDs

4)	Start installation with CD#1

	......

5)	Take a look at /etc/path_to_inst and call "man path_to_inst"

The used method even works nicely for USB devices.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

> >Well, so could you please enlighten the Linux people and say in a couple
> >of words how it could be done?
> 
> 1)	Fetch the Solaris install CD images from:
> 	http://wwws.sun.com/software/solaris/solaris-express/get.html

Grrr!  I wanted you to describe the solution, not how to install Solaris!

You continue asserting that there is some solution to the device numbering
problem (although most other people believe that the problem is unsolvable)
and when asked for the solution, you keep pointing in random directions.

So either show a proof (and shouting that some random OS and that everybody
else should install to find out, is not a proof), or shut up and admit
that you are wrong.

Also, you still forget to state any valid reason why SCSI-like devices should
be referred to in a way different from all other devices, which traditionally
use names of special files.

				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
Nothing is smiple enough to be not screwed up.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Paul Jakma]

On Sat, 7 Aug 2004, Joerg Schilling wrote:

> 5)	Take a look at /etc/path_to_inst and call "man path_to_inst"

The irony here is that the kernel you point at does *not* try to map 
unrelated busses into the same namespace, that the tools and files 
like path_to_inst exist precisely to deal with the fact that topology 
information is no more than ephemereal, and that even the end-user 
device naming does *not* try to map IDE into SCSI.

That the /dev/dsk names typically encode some *logical* topology 
information into the names is beside the point, it's just the Solaris 
convention, the real point is that they abstract the device location, 
so that the user is not required to know that their disk is really 
at, eg:

 	/devices/pci@0,0/pci-ide@7,1/ide@1/sd@0,0:d,raw

Which is where the /dev/ node would symlink to. The /dev/ name has 
nothing to do with physical topology (though might be vaguely 
similar). Also note that the logical /dev/ symlink name is encoded 
*differently* for IDE versus SCSI. Trying to plaster SCSI notations 
into IDE topology is just not useful. Indeed, some devices are not 
dependent on topology at all, they depend on some other topology 
independent identifier, eg FC UUID.

Having user utilities try invent their own namespace, inconsistent 
with both the physical topology and the system's conventions is even 
less useful.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
QOTD:
 	"I drive my car quietly, for it goes without saying."

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

>From: Martin Mares <mj@ucw.cz>

>> Let me lead you to the right place to look for:
>> 
>> 	The CAM interface (which is from the SCSI standards group)
>> 	usually is implemeted in a way that applications open /dev/cam and
>> 	later supply bus, target and lun in order to get connected
>> 	to any device on the system that talks SCSI.
>> 
>> Let me repeat: If you believe that this is a bad idea, give very good reasons.

>There is one: hotplug. The physical topology of buses where all the SCSI-like
>devices (being it ATAPI devices, iSCSI, USB disks or other such beasts)
>are connected is too complex, so every attempt to map them to the
>(bus, target, lun) triplets in any sane way is destined to fail.

I see always the same answers from Linux people who don't know anyrthing than
their belly button :-(

Chek Solaris to see that your statements are wrong.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> I see always the same answers from Linux people who don't know anyrthing than
> their belly button :-(
> 
> Chek Solaris to see that your statements are wrong.

Well, so could you please enlighten the Linux people and say in a couple
of words how it could be done?

				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
And God said: E = 1/2mv^2 - Ze^2/r ...and there *WAS* light!

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Tim Wright]

On Fri, 2004-08-06 at 17:14, Martin Mares wrote:
> Hello!
> 
> > I see always the same answers from Linux people who don't know anyrthing than
> > their belly button :-(
> > 
> > Chek Solaris to see that your statements are wrong.
> 
> Well, so could you please enlighten the Linux people and say in a couple
> of words how it could be done?
> 
> 				Have a nice fortnight

I can offer reasons as to why it cannot :-)

The path_to_inst stuff assumes a simple physical bus topology. It is
completely unsuited to e.g. a fibre-channel fabric. It is also unsuited
to iSCSI - my disks aren't attached to eth0, they're attached to
whichever interface has a route to the server. It's also worthless for
USB. The controller, bus and target are meaningless - the target number
is dynamically assigned at plugin so giving a name to controller 0, bus
0 target 3 is utterly pointless.

Linux and/or associated drivers has mechanisms to handle consistent
naming for a number of these (WWPN-binding for FC, similar device
binding of the unique ids for iSCSI, the hotplug infrastructure for usb
etc.). All of these map devices to consistent device names in /dev. The
"Unix" way of accessing devices has always been via names in /dev. I
completely fail to understand why Joerg wants to try to force a naming
model that is both alien to the native systems (I want /dev/cdrw on
Linux; I probably want D: on Windows or something like that), and is
inadequate to the task if you move beyond the simple world of parallel
SCSI.

Tim

-- 
Tim Wright <timw@splhi.com>

RE: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Buddy Lumpkin]

Joerg has done a horrible job explaining how Solaris uses path_to_inst. The
notion that every storage device gets a controller, target and lun is just
horribly incorrect. Besides, he has way too much ego to think that anyone is
going to actually listen to him, he just does Solaris a disservice IMHO.

For instance, consider a modern scsi tape drive, connected via a SAN switch,
to a fibre-channel host bus adapter on the end system. The st (scsi tape)
driver will enumerate the devices if they haven't already been enumerated
(that's what path_to_inst is for) when you ask the system to reconfigure
devices (with devfsadm or a reconfigure boot like boot -r).

The tape drives are merely given an index, i.e. /dev/rmt/0, /dev/rmt/1,
etc.. The instance numbers are assigned and tracked by path_to_inst to add
some sanity for system administrators. It simply tracks the location of a
card in a system, to instance numbers that were assigned the first time a
card was added to a system. This allows me to remove a scsi or network card,
reboot the system, then later when I receive the new part, replace it and
the instance numbers will never move around. Here are a couple real-world
examples:

My last laptop had not built in NIC, but the docking station did. The
docking station had a 3com 3c950 NIC built in. I also had a 3com cardbus NIC
in the system as well.

If the system was undocked, the cardbus nic was eth0. Every time you docked
the laptop, the docking station NIC became eth0.

Path_to_inst solves this because it would track bus <bus>, slot <slot>, card
type <type>, driver <which driver> to the number it was enumerated at on the
first boot. Thereafter, when the system would enumerate devices, it would
compare the devices found with the file /etc/path_to_inst. This way, it
would not collapse the device numbering just because a NIC had been removed.
It assumes that you don't want software that relies on such numbering
(software RAID or cluster software for instance) to break horribly because a
scsi or network card was removed.

In the earlier example on how tape devices are enumerated. If I remove
/dev/rmt/2, on the next reboot, /dev/rmt/3 does not become /dev/rmt/2. If I
truly want /dev/rmt/3 to become /dev/rmt/2, then I need to prune dangling
links from path_to_inst via an option to the devfsadm command (-C I think).

Fibre Channel cards absolutely add some burdon beyond the physical location
of the card when trying to track devices. This boils down to the way you
bind to devices. This means part of the burdon of making device name
assignments not move around across reboots are on the writer of the device
driver.

The emulex and jaycor (JNI) host bus adapters for fibre channel and
arbitrated loop allow you to bind to devices in many ways. If you bind on
target, and a device is replaced, then the devices are going to move around
possibly on every reboot, simply because the devices will be enumerated in
the order they are seen by the SAN switch. If a device takes a little longer
than normal to be seen by the switch, it will be seen in a new order on the
following reboot and the host is none the wiser. This won't be a problem
with hard drives as their LUN is probably fixed, but the target is
meaningless for devices on a SAN, you can pick whatever target you want.

If you bind on world-wide-port-name, you can track devices by what port they
are plugged into. If you do this, you are placing trust that devices will
not be detected in different orders behind that port. If that port is a
fibre adapter on an EMC storage array, this is fine because each drive slot
is tied to a unique LUN number, but if this is a tape drive, the device
orders can still move around.

If you bind on world-wide-node-name you are binding against the actual
device. This is better for tape drives, but if you need to replace one, you
won't get your old number unless you reboot because most vendors will not
reset the wwn for you.

JNI cooked up a cool way to identify devices in a fabric that allows tape
drives to be hot-swapped called the port id. This is for loop devices only,
but it's pretty cool.

The port id is a combination of which switch domain, alpa and drive id. It
allows tape drives that are on a fabric to be hot swapped and not lose their
device index from the host perspective.

Anyway, the point of my digression is, yes not all device numbering schemes
will fit into the model of path_to_inst completely, but I have seen it save
many junior admins when working with low cost software RAID solutions that
keep track of devices based on their device paths. When the junior admin
plays musical cards, etc.. the path_to_inst file can be used to piece the
puzzle back together as long as they didn't play musical drives as well.

--Buddy







-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Tim Wright
Sent: Saturday, August 07, 2004 10:27 AM
To: Martin Mares
Cc: Joerg Schilling; James.Bottomley@steeleye.com; axboe@suse.de;
linux-kernel@vger.kernel.org
Subject: Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

On Fri, 2004-08-06 at 17:14, Martin Mares wrote:
> Hello!
> 
> > I see always the same answers from Linux people who don't know anyrthing
than
> > their belly button :-(
> > 
> > Chek Solaris to see that your statements are wrong.
> 
> Well, so could you please enlighten the Linux people and say in a couple
> of words how it could be done?
> 
> 				Have a nice fortnight

I can offer reasons as to why it cannot :-)

The path_to_inst stuff assumes a simple physical bus topology. It is
completely unsuited to e.g. a fibre-channel fabric. It is also unsuited
to iSCSI - my disks aren't attached to eth0, they're attached to
whichever interface has a route to the server. It's also worthless for
USB. The controller, bus and target are meaningless - the target number
is dynamically assigned at plugin so giving a name to controller 0, bus
0 target 3 is utterly pointless.

Linux and/or associated drivers has mechanisms to handle consistent
naming for a number of these (WWPN-binding for FC, similar device
binding of the unique ids for iSCSI, the hotplug infrastructure for usb
etc.). All of these map devices to consistent device names in /dev. The
"Unix" way of accessing devices has always been via names in /dev. I
completely fail to understand why Joerg wants to try to force a naming
model that is both alien to the native systems (I want /dev/cdrw on
Linux; I probably want D: on Windows or something like that), and is
inadequate to the task if you move beyond the simple world of parallel
SCSI.

Tim

-- 
Tim Wright <timw@splhi.com>
-
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/

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

Tim Wright wrote:
> On Fri, 2004-08-06 at 17:14, Martin Mares wrote:
> 
>>Hello!
>>
>>
>>>I see always the same answers from Linux people who don't know anyrthing than
>>>their belly button :-(
>>>
>>>Chek Solaris to see that your statements are wrong.
>>
>>Well, so could you please enlighten the Linux people and say in a couple
>>of words how it could be done?
>>
>>				Have a nice fortnight
> 
> 
> I can offer reasons as to why it cannot :-)
> 
> The path_to_inst stuff assumes a simple physical bus topology. It is
> completely unsuited to e.g. a fibre-channel fabric. It is also unsuited
> to iSCSI - my disks aren't attached to eth0, they're attached to
> whichever interface has a route to the server. It's also worthless for
> USB. The controller, bus and target are meaningless - the target number
> is dynamically assigned at plugin so giving a name to controller 0, bus
> 0 target 3 is utterly pointless.
> 
> Linux and/or associated drivers has mechanisms to handle consistent
> naming for a number of these (WWPN-binding for FC, similar device
> binding of the unique ids for iSCSI, the hotplug infrastructure for usb
> etc.). All of these map devices to consistent device names in /dev. The
> "Unix" way of accessing devices has always been via names in /dev. I
> completely fail to understand why Joerg wants to try to force a naming
> model that is both alien to the native systems (I want /dev/cdrw on
> Linux; I probably want D: on Windows or something like that), and is
> inadequate to the task if you move beyond the simple world of parallel
> SCSI.

But they *don't* map to consistent device names. All hot pluggable 
devices seem to map to the next available name. Looking at one of my 
utility systems, it has IDE drives mapped by Redhat with ide-scsi, real 
SCSI drives, a couple of flash card slots mapped to SCSI, and a USB 
device, all in the /dev/sdX namespace. And in the order in which they 
were detected (connected, in other words).

Joerg hasn't made it any better, but it isn't great anyway. I recommend 
a script to do discovery and make symlinks somewhere to names which 
always match the same device.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> But they *don't* map to consistent device names. All hot pluggable 
> devices seem to map to the next available name. Looking at one of my 
> utility systems, it has IDE drives mapped by Redhat with ide-scsi, real 
> SCSI drives, a couple of flash card slots mapped to SCSI, and a USB 
> device, all in the /dev/sdX namespace. And in the order in which they 
> were detected (connected, in other words).
> 
> Joerg hasn't made it any better, but it isn't great anyway. I recommend 
> a script to do discovery and make symlinks somewhere to names which 
> always match the same device.

Exactly. But although this is very easy with addressing by names in /dev
(just make the symlink), I do not see any sane solution in Joerg's world.

				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
If at first you don't succeed, redefine success.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Marc Ballarin]

On Thu, 12 Aug 2004 17:11:45 -0400
Bill Davidsen <davidsen@tmr.com> wrote:

> 
> But they *don't* map to consistent device names. All hot pluggable 
> devices seem to map to the next available name. Looking at one of my 
> utility systems, it has IDE drives mapped by Redhat with ide-scsi, real 
> SCSI drives, a couple of flash card slots mapped to SCSI, and a USB 
> device, all in the /dev/sdX namespace. And in the order in which they 
> were detected (connected, in other words).
> 
> Joerg hasn't made it any better, but it isn't great anyway. I recommend 
> a script to do discovery and make symlinks somewhere to names which 
> always match the same device.
> 

That's exactly what udev allows you to do (among a lot of other things).

Marc

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Mark Lord]

>>>	The CAM interface (which is from the SCSI standards group)
>>>	usually is implemeted in a way that applications open /dev/cam and
>>>	later supply bus, target and lun in order to get connected
>>>	to any device on the system that talks SCSI.

This would be great!

I'm currently fussing about how my new RAID driver
(hardware assisted) can expose it's member drives
in such a way as for the userspace RAID management s/w
to be able to find them.

The driver only sees channel:device:lun, whereas in userspace
there's no tidy way to convert that to a major:minor pair.

I figure this cannot be the only situation where this is a problem.
We're hoping to resolve it all with the scsidev utility,
which is basically a kludge to work around a very inconventient
API from the kernel.  Having a /dev/cam interface as described above
would certainly help here.

What other ways to do this should I be looking at?
(common to both 2.4.xx and 2.6.xx ??)
-- 
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Sad, 2004-08-07 at 01:01, Joerg Schilling wrote:
> >There is one: hotplug. The physical topology of buses where all the SCSI-like
> >devices (being it ATAPI devices, iSCSI, USB disks or other such beasts)
> >are connected is too complex, so every attempt to map them to the
> >(bus, target, lun) triplets in any sane way is destined to fail.
> 
> I see always the same answers from Linux people who don't know anyrthing than
> their belly button :-(
> 
> Chek Solaris to see that your statements are wrong.

Solaris also can't handle the problematic cases. One of the big problems
being that bus, target, lun (or controller, bus, target, lun) are not
actually constants in all cases.

On some Dell storage arrays for example the disks are
bus 0, target 0..4  bus 1, target 0..4 - until that is the cleaner
trips over one of the SCSI cables at which point it becomes bus 0, 
lun 0...9, live, while running.

An even more fun one is SCAM, although its a mostly dead nonstandard
thankfully. With SCAM you can get your devices changing target across
a suspend/resume.

BTW while I remember cdrecord has a bug with hardcoded iso8859-1
copyright symbols in it which mean your copyright banner is invalid
unicode on a UTF-8 locale.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Sad, 2004-08-07 at 23:08, Alan Cox wrote:
> On some Dell storage arrays for example the disks are
> bus 0, target 0..4  bus 1, target 0..4 - until that is the cleaner
> trips over one of the SCSI cables at which point it becomes bus 0, 
> lun 0...9, live, while running.

bus 0 target 0..9 I mean of course..

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> BTW while I remember cdrecord has a bug with hardcoded iso8859-1
> copyright symbols in it which mean your copyright banner is invalid
> unicode on a UTF-8 locale.

Does that also invalidate the copyright?

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jan Knutar]

On Sunday 08 August 2004 02:19, Måns Rullgård wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> > BTW while I remember cdrecord has a bug with hardcoded iso8859-1
> > copyright symbols in it which mean your copyright banner is invalid
> > unicode on a UTF-8 locale.
> 
> Does that also invalidate the copyright?
> 

I was under the impression that printing copyright symbols isn't required.
You have copyright on what you write unless you explicitly assign it away,
which supposedly isn't even possible in some parts of the world, that is,
you always retain copyright nomatter what.

<insert standard IANAL(IACOTW) disclaimer>

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Weinehall]

On Sun, Aug 08, 2004 at 05:33:39AM +0300, Jan Knutar wrote:
> On Sunday 08 August 2004 02:19, Måns Rullgård wrote:
> > Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > 
> > > BTW while I remember cdrecord has a bug with hardcoded iso8859-1
> > > copyright symbols in it which mean your copyright banner is invalid
> > > unicode on a UTF-8 locale.
> > 
> > Does that also invalidate the copyright?
> > 
> 
> I was under the impression that printing copyright symbols isn't required.
> You have copyright on what you write unless you explicitly assign it away,
> which supposedly isn't even possible in some parts of the world, that is,
> you always retain copyright nomatter what.
> 
> <insert standard IANAL(IACOTW) disclaimer>

In *some* countries your copyright claim is strengthened by having
a "Copyright" and/or "©" clause.  Writing (C) has no legal effect
however, so you should always write out the full word, like so:

Copyright © 2004 Foo Bar, Baz Inc.


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

David Weinehall <tao@debian.org> writes:

> On Sun, Aug 08, 2004 at 05:33:39AM +0300, Jan Knutar wrote:
>> On Sunday 08 August 2004 02:19, Måns Rullgård wrote:
>> > Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>> > 
>> > > BTW while I remember cdrecord has a bug with hardcoded iso8859-1
>> > > copyright symbols in it which mean your copyright banner is invalid
>> > > unicode on a UTF-8 locale.
>> > 
>> > Does that also invalidate the copyright?
>> > 
>> 
>> I was under the impression that printing copyright symbols isn't required.
>> You have copyright on what you write unless you explicitly assign it away,
>> which supposedly isn't even possible in some parts of the world, that is,
>> you always retain copyright nomatter what.
>> 
>> <insert standard IANAL(IACOTW) disclaimer>
>
> In *some* countries your copyright claim is strengthened by having
> a "Copyright" and/or "©" clause.  Writing (C) has no legal effect
> however, so you should always write out the full word, like so:
>
> Copyright © 2004 Foo Bar, Baz Inc.

Seems like I didn't make the joke clear enough, though with legalities
you can never be too careful.

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Albert Cahalan]

In various emails, Joerg Schilling writes:

> Linux users like to call cdrecord -scanbus and they like to
> see _all_ SCSI devices from a single call to cdrecord.

If you really think so, you've been smoking crack.
Users _hate_ to call "cdrecord -scanbus". They don't
see why it should be needed. The normal reaction to
reading your documentation goes something like this:

"What the fuck? Can't I just give it a device name?"

Alternately:

"Uh... I don't have SCSI. I guess I need a different program."

Heck, you could do the silly -scanbus thing internally
if you must. Then users wouldn't get it wrong and wouldn't
have to screw with it.

> Looks like a typical answer from somebody who's thoughts
> are limited to a Linux environment. Take into account, that
> cdrecord runs on more than 30 different platforms and that
> several of these platforms do not have device nodes like
> UNIX has. Cdrecord has been implemented to use a portable
> addressing method.

I'm sure a Windows user would want to use something like
a drive letter. So... give it to them. Not even a Solaris
user would really want to use raw SCSI notation. On all
platforms, people want to use the native naming system.

> The fact that the Linux kernel does not return instance
> numbers for /dev/hd* SCSI devices makes it impossible to
> implement a unique address space :-(

We have a unique address space: the /dev directory

We don't need a second address space.

> If you like to compile an application that uses kernel interfaces,
> you need to make sure that both, the application and the kernel
> are compiled with the same "interface description" which is just
> the kernel include files.

No change to the kernel headers would allow you to produce
a binary on an old system that makes use of new features.
The only way this can work is if you bring your own headers.

I use kernel interfaces all the time in procps. For the old
and standard ones, I rely on the C library. For all the rest,
I have my own header files. This works great.

I can compile procps on a system with the 2.4.xx kernel
and 2.4.xx headers. Then, I can take this binary to a system
with the 2.2.xx or 2.6.x kernel and expect it to work great.
That's 3 major kernel revisions: 2.2.xx, 2.4.xx, and 2.6.x.
Really, it's not hard.

> I wish that discussions with the Linux kernel hackers would be as
> easy and fruitful as they are with the Solaris kernel hackers.

You're trying to force Linux developers to comply with Solaris
interfaces. You should try things the other way and see how far
you get. If you don't get far, you're being unfair. If you do
get far, well, isn't that good?

> Just make sure not to use a broken version from the SuSE source tree....

I wonder why SuSE felt they needed to patch your code.
While I've found that some vendors are really crazy about
breaking things, SuSE has been pretty good.

If everyone around you seems to be insane, maybe it's you.

> Let's see whether "Linux" is open enough to listen to the
> demands of the users......

How about cdrecord? Demands of the users:

1. tools built with headers derived from Linux 2.2.xx will
   take full advantage of Linux 2.6.xx features

2. tools built with headers derived from Linux 2.6.x will
   still work on the oldest Linux you support

3. in all cases, including SCSI, the /dev/* name is used
   (the Solaris and Windows users would love that as well)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bernd Schubert]

On Friday 06 August 2004 22:26, Albert Cahalan wrote:
> In various emails, Joerg Schilling writes:
> > Linux users like to call cdrecord -scanbus and they like to
> > see _all_ SCSI devices from a single call to cdrecord.
>
> If you really think so, you've been smoking crack.

Please, no insults. I like this cdrecord -scanbus too, but I would like it 
more, if it would also print pure ide devices ;)
On the other hand I usually also don't care since k3b does all this stuff for 
me.

> Users _hate_ to call "cdrecord -scanbus". They don't
> see why it should be needed. The normal reaction to
> reading your documentation goes something like this:
>
> "What the fuck? Can't I just give it a device name?"

Well, the usual reaction is 'cdrecord whats that? Commandline interface, 
parameters? Hey, I want to burn a CD and don't like reading manpages for 
stuff like that'. I guess that at least 95% of all people who would like to 
burn a CD will prefer (and also use) a grahical interface.

The hole discussion which cdrecord -dev parameter to use is completely 
useless, it only effects a clear minority of developers and guys who probably 
don't like graphical interfaces at at all. Those guys should be able to adopt 
to whatever -dev option is possible.

Please, calm down and return to usefull technical discussions.

Bernd

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

You know what a cut/paste error is?

BTW: this could be avoided if Linux would supply correct termcap/terminfo
entries for xterm so the screen would not go white on black on
every odd try :-(


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Fri, Aug 06 2004, Joerg Schilling wrote:
> You know what a cut/paste error is?
> 
> BTW: this could be avoided if Linux would supply correct termcap/terminfo
> entries for xterm so the screen would not go white on black on
> every odd try :-(

Your mail would have been equally wrong had you written SG_MAX_SENSE.
It's a bug in cdrecord, period. Like Erik said, you could help your
image considerably admitting that instead of changing directions.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Erik Mouw]

On Fri, Aug 06, 2004 at 04:20:30PM +0200, Joerg Schilling wrote:
> You know what a cut/paste error is?

I know, but a cut error with 15 lines apart is a bit odd. You shouldn't
use the "unreadable" font for xterms, that makes the "cut" action a lot
easier :)

But then again, like I explained before: even if you would have pasted
SG_MAX_SENSE in your message, it would still not make sense, cause that
is being used in the old and deprecated sg_header interface (which you
should not and apparently do not use in cdrecord).

> BTW: this could be avoided if Linux would supply correct termcap/terminfo
> entries for xterm so the screen would not go white on black on
> every odd try :-(

Making up this kind of excuses doesn't really improve your credibility.
Just admit and fix the bug in cdrecord, and work with Jens to fix the
remaining bugs in the kernel. Everybody makes mistakes, even people
with over 20 years of experience.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]


>From: Jens Axboe <axboe@suse.de>

>So I downloaded:

>ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01a35.tar.gz

>and built it, ran scgcheck on a SCSI hard drive. And you pass in
>->mx_sb_len == 16 to the sg driver, so that's why it's not copying more
>than 16 bytes back to you. There are 18 available in that first test
>case. Here's that test case:

>Testing if at least CCS_SENSE_LEN (18) is supported...
>Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 00
>---------->     Method 0x00: expected: 18 reported: 16 max found: 16
>Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 FF FF
>---------->     Method 0xFF: expected: 18 reported: 16 max found: 16
>---------->     Minimum standard (CCS) sense length failed
>---------->     Wanted 18 sense bytes, got (16)
>Testing for 32 bytes of sense data...
>Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 00 00 00
>00 00 00 00 00 00 00 00 00 00 00 00
>---------->     Method 0x00: expected: 32 reported: 16 max found: 16
>Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 FF FF FF FF
>FF FF FF FF FF FF FF FF FF FF FF FF
>---------->     Method 0xFF: expected: 32 reported: 16 max found: 16
>---------->     Wanted 32 sense bytes, got (16)
>----------> Got a maximum of 16 sense bytes
>----------> SCSI sense count test FAILED
>----------> SCSI status byte test NOT YET READY

>Changing your scsi-linux-sg.c to set max sense to 64:

>Testing if at least CCS_SENSE_LEN (18) is supported...
>Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 03

Wonderful, so you just found another bug in the Linux kernel include files.

To fix: edit sg.h in the Linux kernel source tree and fix the value for
SG_MAX_QUEUE or if you believe you cannot change it, create a new #define
and document it......

BTW: as you did not mention the DMA residual count problem, I asume that
it is still present.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Fri, Aug 06 2004, Joerg Schilling wrote:
> 
> >From: Jens Axboe <axboe@suse.de>
> 
> >So I downloaded:
> 
> >ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01a35.tar.gz
> 
> >and built it, ran scgcheck on a SCSI hard drive. And you pass in
> >->mx_sb_len == 16 to the sg driver, so that's why it's not copying more
> >than 16 bytes back to you. There are 18 available in that first test
> >case. Here's that test case:
> 
> >Testing if at least CCS_SENSE_LEN (18) is supported...
> >Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 00
> >---------->     Method 0x00: expected: 18 reported: 16 max found: 16
> >Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 FF FF
> >---------->     Method 0xFF: expected: 18 reported: 16 max found: 16
> >---------->     Minimum standard (CCS) sense length failed
> >---------->     Wanted 18 sense bytes, got (16)
> >Testing for 32 bytes of sense data...
> >Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 00 00 00
> >00 00 00 00 00 00 00 00 00 00 00 00
> >---------->     Method 0x00: expected: 32 reported: 16 max found: 16
> >Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 FF FF FF FF
> >FF FF FF FF FF FF FF FF FF FF FF FF
> >---------->     Method 0xFF: expected: 32 reported: 16 max found: 16
> >---------->     Wanted 32 sense bytes, got (16)
> >----------> Got a maximum of 16 sense bytes
> >----------> SCSI sense count test FAILED
> >----------> SCSI status byte test NOT YET READY
> 
> >Changing your scsi-linux-sg.c to set max sense to 64:
> 
> >Testing if at least CCS_SENSE_LEN (18) is supported...
> >Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 03
> 
> Wonderful, so you just found another bug in the Linux kernel include files.
> 
> To fix: edit sg.h in the Linux kernel source tree and fix the value for
> SG_MAX_QUEUE or if you believe you cannot change it, create a new #define
> and document it......

SG_MAX_SENSE, yes? It's your bug if you are using that and using the
newer interface, it only applies to the old sg_header interface. As
scsi-linux-sg is using SG_IO, it has no relevance whatsoever. Internally
SCSI uses a much bigger sense buffer, so as long as you supply a big
enough user buffer it works.

A 1 minute grep of the sources could have told you this. I always get
the feeling that you'd rather see the bugs persist rather than have them
fixed, so you have more to complain about on Linux.

> BTW: as you did not mention the DMA residual count problem, I asume that
> it is still present.

I haven't looked that far yet, I might next week. That your scgcheck
doesn't work without /dev/sg* means I can't check on ide-cd,
unfortunately.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Erik Mouw]

On Fri, Aug 06, 2004 at 03:45:46PM +0200, Joerg Schilling wrote:
> >Testing if at least CCS_SENSE_LEN (18) is supported...
> >Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 03
> 
> Wonderful, so you just found another bug in the Linux kernel include files.
> 
> To fix: edit sg.h in the Linux kernel source tree and fix the value for
> SG_MAX_QUEUE or if you believe you cannot change it, create a new #define
> and document it......

Uhm, it *is* documented:

In include/scsi/sg.h, line 255:

/* maximum outstanding requests, write() yields EDOM if exceeded */
#define SG_MAX_QUEUE 16

SG_MAX_QUEUE has nothing to do with inquiry length but with the maximum
number of queued commands (hence the name SG_MAX_QUEUE).

I'm sorry, but I think Jens found a genuine bug in your program. IMHO
it would increase your credits on this list if you admit it and fix the
bug. If you don't, we'll keep this kind of linux-vs-cdrecord threads on
lkml. That can't be the idea, cause we all just agreed that we wanted
to keep the amount noise on this list low.


BTW, you are right for the old SG implementations. Line 267 of
include/scsi/sg.h:

/* vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv */
/*   The older SG interface based on the 'sg_header' structure follows.   */
/* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ */

#define SG_MAX_SENSE 16   /* this only applies to the sg_header interface */

You're free to use old and deprecated implementations but don't file
bugs against them cause they are old and deprecated for a reason.



Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 9626 bytes --]

>From: Jens Axboe <axboe@suse.de>

>> >SG_IO for atapi was born working that way. This should have been fixed
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Sorry - you should know better that this is not true :-( The unneeded
>> /dev/hd interface has been created with the _same_ DMA problems,
>> ide-scsi still has. Later, when I complained about the problem it has
>> been fixed. As the ide-scsi interface has not been fixed at the same
>> time, this did not look very friendly to me...

>I think I know the history of it, I picked up the pieces of the stuff
>Linus originally did. Originally, there was _no_ dma support. I can only
>imagine that Linus put it in to have someone fix it, because it was
>unustable at the time. I forget how long that lasted, but it can't have
>been more than a few weeks. So it was not the same problem at all. It
>did not use dma because it set up a contig buffer in rq->buffer, which
>ide-cd doesn't convert to prd tables for dma. This was quickly fixed and
>with granular alignment/length restrictions for dma operations, as I
>outlined it defaulted to 4-bytes for ide-cd then. This was all during
>the 2.5 development cycle.

Let me give you a short answer: If DMA creates so many problem on Linux,
how about imlementing a generic DMA abstraction layer like Solaris does?


>> Sorry, but you are wrong: ATAPI CD/DVD writers are primary SCSI
>> devices and thus need to primaryly appear in the SCSI device tree.
>> Adding SG_IO support to fd's that are a result of a call to
>> open("/dev/hd... is a nice extra but definitely not needed.

>Bogus, and I'll again refrain from commenting on that because it's a
>matter of opinion and we all know yours. They use the same command set,
>but there's absolutely no reason why you would need to export them as
>SCSI devices and fake bus/id/lun naming etc.

If you like to ignore the X10t13 SCSI standard group, it is your private 
decision but then it is hard to have a common language for discussions :-(


>> >It has been argued several times that we will not doctor bus/id/lun on
>> >atapi devices, because it does not make sense. So I'm regarding this as
>> >invalid.
>> 
>> Sorry, I have more than 20 years of experiences in Kernel and
>> Application hacking. I am able to decide myself what is a bug and what
>> is something that needs to be called at least "non-orthogonal
>> behavior". This is devinitely a bug or missing orthogonality. See
>> above to understand (These are primarily SCSI devices and therefore
>> they need to have instance numbers within the set of devices in the
>> SCSI device tree).

>Those 20 years at least do seem to buy you a whole lot of arrogance.

Looks like you are a bit confused, see below.....

>I'll explain to you why no thread you start here on lkml goes anywhere -
>because you refuse to listen to anyone. You have 20 years of experience
>so anything you say must be absolutely true, there's not a gram of
>reason in the world coming from other people. Thus there's no point in
>debating with you on these issues.

Please try to distinct between threads I did start and threads I have been
drawn into. I am open to any serious discussion, however if you like
to insist in things that have been agreed on being suboptimal for more than
20 years, you should have very good reasons _and_ be willing to explain
them.

I don't see any arrogance in my mails but in former discussions on LKML,
there have been other people who did believe that they could replace missing
knowledge by arrogance. Fortunately, they did not join this thread ;-)

Let me lead you to the right place to look for:

	The CAM interface (which is from the SCSI standards group)
	usually is implemeted in a way that applications open /dev/cam and
	later supply bus, target and lun in order to get connected
	to any device on the system that talks SCSI.

Let me repeat: If you believe that this is a bad idea, give very good reasons.

 
>I'll say again that _I_ think making up SCSI like addressing for ATAPI
>is completely bogus, because ATAPI isn't addressed that way. You are
>inventing magic numbers! Just because these devices happen to share the
>same command set (almost, which btw do most storage devices these days)
>does not mean they share the bus topology.

But what you think, differs from what the SCSI standards people do.

>> If you do not fix this, you just verify that Linux does not like it's
>> users.  Linux users like to call cdrecord -scanbus and they like to
>> see _all_ SCSI devices from a single call to cdrecord. The fact that
>> the Linux kernel does not return instance numbers for /dev/hd* SCSI
>> devices makes it impossible to implement a unique address space :-(

>I'm sure new users love to find out they need to use -dev=0,1,0 to
>specify their cd burner, they must find that really intuitive and
>straight forward. It's much easier than just using /dev/cdr, or whatever
>you want to name the special file. Indeed.

Looks like a typical answer from somebody who's thoughts are limited to a Linux
environment. Take into account, that cdrecord runs on more than 30 different
platforms and that several of these platforms do not have device nodes like
UNIX has. Cdrecord has been implemented to use a portable addressing method.


>That's fine if you work on nothing but that, but I personally don't want
>to subscribe to more lists. I don't have time to follow them anyways. If
>there's a Linux kernel bug, people should be pointed at linux-kernel and
>follow the general rules of reporting issues there.

As 50% of all problems reported for cdrecord on Linux look like Linux
kernel problems, this is what I do every day.

>> >> -	Linux Kernel include files (starting with Linux-2.5) are buggy and 
>> >> 	prevent compilation. Many files may be affected but let me name
>> >> 	the most important files for me:
>> >> 
>> >> 	-	/usr/src/linux/include/scsi/scsi.h depends on a nonexistant
>> >> 		type "u8". The correct way to fix this would be to replace
>> >> 		any "u8" by "uint8_t". A quick and dirty fix is to call:
>> >> 
>> >> 			"change u8 __u8 /usr/src/linux/include/scsi/scsi.h"
>> >> 
>> >> 		ftp://ftp.berlios.de/pub/change/
>> >> 
>> >> 	-	/usr/src/linux/include/scsi/sg.h includes "extra text" "__user"
>> >> 		in some structure definitions. This may be fixed by adding
>> >> 		#include <linux/compiler.h> somewhere at the beginning of
>> >> 		/usr/src/linux/include/scsi/sg.h
>> >> 
>> >> 	This bug has been reported several times (starting with Linux-2.5).
>> >> 
>> >> 	Time to fix: 5 minutes.
...
>> Of course, you have a second way to go:
>> 
>> 	You could set up a copy of the Linux Kernel include file tree,
>> 	fix this tree and include the fixed version with _every_ Linux source
>> 	distribution. Of course, you need to make sure that the interfaces
>> 	seen in the fixed include tree always exactly match the related
>> 	Kernel sources. Guess which method creates a higher work load.

>I've never followed these threads closely, and I'm not the guy to
>comment on that. It's been discussed here recently, you might want to
>search linux-kernel archives for include/abi and similar.

I am sorry, I am receiving far too much mail to have the time for searching
such an archive. If nobody points me to a file, I would not do it.

>> Let me make a proposal:
>> 
>> The most important problem currently is caused by the bugs in the Linux
>> kernel include files. As it takes only 5 minutes to fix the include 
>> file bugs that are related to cdrtools, I would like to see this bug
>> fixed first.

>Then either fix it and post the patch, or write a detailed bug report
>and hope that someone else fixes it. That's how it works. You have no
>support contract with me.

See above, the fix is in my mail and it has been copied over several times
now....

>> After I've seen a kernel without the named bugs appering on
>> kernel.org, I am very willing to help you to find the reason for the
>> other bugs.  Make your choice which of the problems to check
>> first....... however, it would be a nice gesture to fix the DMA only
>> for x % 512 == 0 problem in ide-scsi next.

>The importance of that bug is slowly decreasing - in 2.6 ide-scsi isn't
>needed, and 2.4 is pretty much set in stone and I doubt we'd fix this
>bug in fear of introducing regressions on some hardware.

The importance could be limited if there were unique instance numbers
for ATAPI devices using the same address space as the other SCSI devices.
For now, ide-scsi is really important.

>> I don't like to sell my soul and this is exactly why I prefer Solaris.

>I'd consider signing licenses to be able to get the OS at least partly
>selling my soul, where as Linux requires you to sign nothing and is
>completely free and open.

Let's see whether "Linux" is open enough to listen to the demands of the
users......

>> I wish that discussions with the Linux kernel hackers would be as
>> easy and fruitful as they are with the Solaris kernel hackers.
>>
>> I wish that bugs in the Linux kernel were fixed as fast as they are
>> fixed on Solaris.

>Maybe you'll have better luck when they are all hacking Linux instead in
>the future.

It seems that you are listening to missinformed people. Why should
Sun use Linux as long as they would miss all the benefits from the new
features of e.g. Solaris 10?


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Fri, Aug 06 2004, Joerg Schilling wrote:
> >From: Jens Axboe <axboe@suse.de>
> 
> >> >SG_IO for atapi was born working that way. This should have been fixed
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> Sorry - you should know better that this is not true :-( The unneeded
> >> /dev/hd interface has been created with the _same_ DMA problems,
> >> ide-scsi still has. Later, when I complained about the problem it has
> >> been fixed. As the ide-scsi interface has not been fixed at the same
> >> time, this did not look very friendly to me...
> 
> >I think I know the history of it, I picked up the pieces of the stuff
> >Linus originally did. Originally, there was _no_ dma support. I can only
> >imagine that Linus put it in to have someone fix it, because it was
> >unustable at the time. I forget how long that lasted, but it can't have
> >been more than a few weeks. So it was not the same problem at all. It
> >did not use dma because it set up a contig buffer in rq->buffer, which
> >ide-cd doesn't convert to prd tables for dma. This was quickly fixed and
> >with granular alignment/length restrictions for dma operations, as I
> >outlined it defaulted to 4-bytes for ide-cd then. This was all during
> >the 2.5 development cycle.
> 
> Let me give you a short answer: If DMA creates so many problem on Linux,
> how about imlementing a generic DMA abstraction layer like Solaris does?

We do have that. But suddenly changing the alignment and length
restrictions on issuing dma to a device in the _end_ of a stable series
does not exactly fill me with joyful expectations. It's simply that,
not lack of infrastructure.

> >> Sorry, but you are wrong: ATAPI CD/DVD writers are primary SCSI
> >> devices and thus need to primaryly appear in the SCSI device tree.
> >> Adding SG_IO support to fd's that are a result of a call to
> >> open("/dev/hd... is a nice extra but definitely not needed.
> 
> >Bogus, and I'll again refrain from commenting on that because it's a
> >matter of opinion and we all know yours. They use the same command set,
> >but there's absolutely no reason why you would need to export them as
> >SCSI devices and fake bus/id/lun naming etc.
> 
> If you like to ignore the X10t13 SCSI standard group, it is your
> private decision but then it is hard to have a common language for
> discussions :-(

And they dictate how we should name ata/atapi devices? I just think it's
a lot more logical to use /dev/burner instead of some obscure three
numbers that you cannot seriously expect any regular user to remember.
Do you want me to point them at some standards document to figure it
out? The whole reason why -scanbus is even there is because of this
stupidity, there would be no need for it if the naming was logical.

> >I'll explain to you why no thread you start here on lkml goes anywhere -
> >because you refuse to listen to anyone. You have 20 years of experience
> >so anything you say must be absolutely true, there's not a gram of
> >reason in the world coming from other people. Thus there's no point in
> >debating with you on these issues.
> 
> Please try to distinct between threads I did start and threads I have
> been drawn into. I am open to any serious discussion, however if you
> like to insist in things that have been agreed on being suboptimal for
> more than 20 years, you should have very good reasons _and_ be willing
> to explain them.

Agreed between whom? I don't agree that this naming is sound, in fact I
think it's quite stupid.

> I don't see any arrogance in my mails but in former discussions on
> LKML, there have been other people who did believe that they could
> replace missing knowledge by arrogance. Fortunately, they did not join
> this thread ;-)

Well, sometimes email is a bad media for discussions...

> Let me lead you to the right place to look for:
> 
> 	The CAM interface (which is from the SCSI standards group)
> 	usually is implemeted in a way that applications open /dev/cam and
> 	later supply bus, target and lun in order to get connected
> 	to any device on the system that talks SCSI.
> 
> Let me repeat: If you believe that this is a bad idea, give very good
> reasons.

First of all, Linux isn't based on CAM. Secondly, I already out lined
exactly why I think this naming is silly for ATAPI devices a few
paragraphs above.

> >> If you do not fix this, you just verify that Linux does not like it's
> >> users.  Linux users like to call cdrecord -scanbus and they like to
> >> see _all_ SCSI devices from a single call to cdrecord. The fact that
> >> the Linux kernel does not return instance numbers for /dev/hd* SCSI
> >> devices makes it impossible to implement a unique address space :-(
> 
> >I'm sure new users love to find out they need to use -dev=0,1,0 to
> >specify their cd burner, they must find that really intuitive and
> >straight forward. It's much easier than just using /dev/cdr, or whatever
> >you want to name the special file. Indeed.
> 
> Looks like a typical answer from somebody who's thoughts are limited
> to a Linux environment. Take into account, that cdrecord runs on more
> than 30 different platforms and that several of these platforms do not
> have device nodes like UNIX has. Cdrecord has been implemented to use
> a portable addressing method.

I can see your problem, but I think it's a classical case of try to shoe
horn something to work on everything that instead doesn't work really
well everywhere.

I am focused on Linux, that's what I work on. And I truly think the
device naming option is so much easier for users that it's not even
funny.

> >That's fine if you work on nothing but that, but I personally don't want
> >to subscribe to more lists. I don't have time to follow them anyways. If
> >there's a Linux kernel bug, people should be pointed at linux-kernel and
> >follow the general rules of reporting issues there.
> 
> As 50% of all problems reported for cdrecord on Linux look like Linux
> kernel problems, this is what I do every day.

Just because they look like Linux kernel problems, doesn't mean that
they are :-)

> >> Of course, you have a second way to go:
> >> 
> >> 	You could set up a copy of the Linux Kernel include file tree,
> >> 	fix this tree and include the fixed version with _every_ Linux source
> >> 	distribution. Of course, you need to make sure that the interfaces
> >> 	seen in the fixed include tree always exactly match the related
> >> 	Kernel sources. Guess which method creates a higher work load.
> 
> >I've never followed these threads closely, and I'm not the guy to
> >comment on that. It's been discussed here recently, you might want to
> >search linux-kernel archives for include/abi and similar.
> 
> I am sorry, I am receiving far too much mail to have the time for searching
> such an archive. If nobody points me to a file, I would not do it.

Then you lost your right to discuss it here.

> >> Let me make a proposal:
> >> 
> >> The most important problem currently is caused by the bugs in the Linux
> >> kernel include files. As it takes only 5 minutes to fix the include 
> >> file bugs that are related to cdrtools, I would like to see this bug
> >> fixed first.
> 
> >Then either fix it and post the patch, or write a detailed bug report
> >and hope that someone else fixes it. That's how it works. You have no
> >support contract with me.
> 
> See above, the fix is in my mail and it has been copied over several times
> now....

A textual description of the problem is not a fix. Or did I miss the
patch? If so, I apologize.

> >> After I've seen a kernel without the named bugs appering on
> >> kernel.org, I am very willing to help you to find the reason for the
> >> other bugs.  Make your choice which of the problems to check
> >> first....... however, it would be a nice gesture to fix the DMA only
> >> for x % 512 == 0 problem in ide-scsi next.
> 
> >The importance of that bug is slowly decreasing - in 2.6 ide-scsi isn't
> >needed, and 2.4 is pretty much set in stone and I doubt we'd fix this
> >bug in fear of introducing regressions on some hardware.
> 
> The importance could be limited if there were unique instance numbers
> for ATAPI devices using the same address space as the other SCSI
> devices.  For now, ide-scsi is really important.

It's not the same address space, so there is not.

> >> I don't like to sell my soul and this is exactly why I prefer Solaris.
> 
> >I'd consider signing licenses to be able to get the OS at least partly
> >selling my soul, where as Linux requires you to sign nothing and is
> >completely free and open.
> 
> Let's see whether "Linux" is open enough to listen to the demands of
> the users......

We try, when they make sense...

> >> I wish that discussions with the Linux kernel hackers would be as
> >> easy and fruitful as they are with the Solaris kernel hackers.
> >>
> >> I wish that bugs in the Linux kernel were fixed as fast as they are
> >> fixed on Solaris.
> 
> >Maybe you'll have better luck when they are all hacking Linux instead in
> >the future.
> 
> It seems that you are listening to missinformed people. Why should
> Sun use Linux as long as they would miss all the benefits from the new
> features of e.g. Solaris 10?

I'm sure Sun would rehire you in marketing, should you so wish to :-)

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

Jens Axboe schrieb am 2004-08-06:

> On Fri, Aug 06 2004, Joerg Schilling wrote:
> > Let me give you a short answer: If DMA creates so many problem on Linux,
> > how about imlementing a generic DMA abstraction layer like Solaris does?
> 
> We do have that. But suddenly changing the alignment and length
> restrictions on issuing dma to a device in the _end_ of a stable series
> does not exactly fill me with joyful expectations. It's simply that,
> not lack of infrastructure.

The problem has been reported again and again throughout the whole 2.4
cycle and has grown ever more painful as devices became faster.

It's not exactly fun if everything can do 48X but your favorite OS
(Linux 2.4) is limited to say 8X because it only does PIO in spite of
hdparm settings and everything else.

I didn't care much because I had a SCSI writer at that time which had
working DMA (and was also slow...) but as that turned out to become
unreliable, I bought one of the nice Plextors and now was faced with the
problem I couldn't use it at full speed. FreeBSD came to the rescue
while 2.6 started to become stable through its early releases.

It's Marcelo's call to decide if he wants the DMA addressing
requirements relaxed for 2.4.28 or if 2.4 is closed. If 2.4 is now
bugfixes-only then this certainly qualifies after some testing. If it
doesn't work out, it can still be disabled through the -rc versions, or
it can be some sysctl if you fear adverse effects.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Tue, Aug 10 2004, Matthias Andree wrote:
> Jens Axboe schrieb am 2004-08-06:
> 
> > On Fri, Aug 06 2004, Joerg Schilling wrote:
> > > Let me give you a short answer: If DMA creates so many problem on Linux,
> > > how about imlementing a generic DMA abstraction layer like Solaris does?
> > 
> > We do have that. But suddenly changing the alignment and length
> > restrictions on issuing dma to a device in the _end_ of a stable series
> > does not exactly fill me with joyful expectations. It's simply that,
> > not lack of infrastructure.
> 
> The problem has been reported again and again throughout the whole 2.4
> cycle and has grown ever more painful as devices became faster.
> 
> It's not exactly fun if everything can do 48X but your favorite OS
> (Linux 2.4) is limited to say 8X because it only does PIO in spite of
> hdparm settings and everything else.
> 
> I didn't care much because I had a SCSI writer at that time which had
> working DMA (and was also slow...) but as that turned out to become
> unreliable, I bought one of the nice Plextors and now was faced with
> the problem I couldn't use it at full speed. FreeBSD came to the
> rescue while 2.6 started to become stable through its early releases.
> 
> It's Marcelo's call to decide if he wants the DMA addressing
> requirements relaxed for 2.4.28 or if 2.4 is closed. If 2.4 is now
> bugfixes-only then this certainly qualifies after some testing. If it
> doesn't work out, it can still be disabled through the -rc versions,
> or it can be some sysctl if you fear adverse effects.

It's not going to happen for 2.4, that's pretty much given. 2.6 works
just fine, and I sure as hell don't want to risk breaking anything in
2.4 just to get a speed increase. Not at this point.

You also seem to forget that someone needs to do the actual work to make
it happen. It's not likely someone will, when they haven't already.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Erik Mouw]

On Tue, Aug 10, 2004 at 10:41:59AM +0200, Matthias Andree wrote:
> It's not exactly fun if everything can do 48X but your favorite OS
> (Linux 2.4) is limited to say 8X because it only does PIO in spite of
> hdparm settings and everything else.

FWIW, we burn CDs at 40x with a 2.4 kernel. It is however a hardware or
driver related issue: no problems whatsoever with VIA IDE interfaces,
but only PIO with the CD writer connected to a Promise 20268.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Tue, Aug 10 2004, Erik Mouw wrote:
> On Tue, Aug 10, 2004 at 10:41:59AM +0200, Matthias Andree wrote:
> > It's not exactly fun if everything can do 48X but your favorite OS
> > (Linux 2.4) is limited to say 8X because it only does PIO in spite of
> > hdparm settings and everything else.
> 
> FWIW, we burn CDs at 40x with a 2.4 kernel. It is however a hardware or
> driver related issue: no problems whatsoever with VIA IDE interfaces,
> but only PIO with the CD writer connected to a Promise 20268.

It's not a problem with data CDs, it's only a problem with non-512b
aligned sector sizes (like audio CDs).

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Erik Mouw]

On Tue, Aug 10, 2004 at 12:12:24PM +0200, Jens Axboe wrote:
> On Tue, Aug 10 2004, Erik Mouw wrote:
> > FWIW, we burn CDs at 40x with a 2.4 kernel. It is however a hardware or
> > driver related issue: no problems whatsoever with VIA IDE interfaces,
> > but only PIO with the CD writer connected to a Promise 20268.
> 
> It's not a problem with data CDs, it's only a problem with non-512b
> aligned sector sizes (like audio CDs).

This was with data CDs.

Don't investigate too much, this was with 2.4.24. It works right now
cause I moved the writer to the VIA interface. I'm thinking about
moving to 2.6 anyway.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Erik Mouw <erik@harddisk-recovery.com> writes:

> On Tue, Aug 10, 2004 at 10:41:59AM +0200, Matthias Andree wrote:
>> It's not exactly fun if everything can do 48X but your favorite OS
>> (Linux 2.4) is limited to say 8X because it only does PIO in spite of
>> hdparm settings and everything else.
>
> FWIW, we burn CDs at 40x with a 2.4 kernel. It is however a hardware or
> driver related issue: no problems whatsoever with VIA IDE interfaces,
> but only PIO with the CD writer connected to a Promise 20268.

Problems with ATAPI devices on Promise cards are common, even Promise
admits that.

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

On Tue, 10 Aug 2004, Måns Rullgård wrote:

> Problems with ATAPI devices on Promise cards are common, even Promise
> admits that.

Data point: Plextor PX-W4824A on PDC-20265R (Gigabyte 7ZX-R) in ATA mode
is completely non-functional. Promise chips of that age will also lock
up with legacy ATA queued commands (tried with a DTLA under FreeBSD ->
boom).

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

So, did Joerg Schilling ever accept this patch? If so, or if not, why?

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> Let me lead you to the right place to look for:
> 
> 	The CAM interface (which is from the SCSI standards group)
> 	usually is implemeted in a way that applications open /dev/cam and
> 	later supply bus, target and lun in order to get connected
> 	to any device on the system that talks SCSI.
> 
> Let me repeat: If you believe that this is a bad idea, give very good reasons.

There is one: hotplug. The physical topology of buses where all the SCSI-like
devices (being it ATAPI devices, iSCSI, USB disks or other such beasts)
are connected is too complex, so every attempt to map them to the
(bus, target, lun) triplets in any sane way is destined to fail.

Hence, the triplets will be just some magic numbers with no connection
to reality and while in a static world, you can assign them in some
consistent (although completely virtual) way, once you admit that
devices can be hotplugged, nobody can guarantee that these numbers will be the
same on every boot. In practice, they aren't.

Also, no matter what the SCSI standard group thinks, the traditional UNIX
way how to refer to devices is by the name of the corresponding special
file. Unless you have very strong reasons why this model is wrong for
SCSI-like devices, you should keep to the tradition. Refering to the
CD burner in different ways depending on whether I want to mount the disk
or to burn it, is outright silly.

Sure, just using device names is not a panacea for the hotplug problems,
but it makes the problems much easier to solve. And given that this has
to be done anyway, maintaining one more dynamic namespace (the SCSI triplets)
is just another pile of unnecessary extra work.

> Looks like a typical answer from somebody who's thoughts are limited to a Linux
> environment. Take into account, that cdrecord runs on more than 30 different
> platforms and that several of these platforms do not have device nodes like
> UNIX has. Cdrecord has been implemented to use a portable addressing method.

Portable, as the problems with Linux show, it isn't. There is probably no
such thing like an universal addressing scheme working on all systems.

> The importance could be limited if there were unique instance numbers
> for ATAPI devices using the same address space as the other SCSI devices.

Such "numbers" are there -- the device node names. All other SCSI devices
have them, too.

> Let's see whether "Linux" is open enough to listen to the demands of the
> users......

So far, I haven't heard much users longing for the triplet addressing
of devices. To be precise, exactly one. On the other side, whenever I have
heard people talking about cdrecord (which is otherwise a very fine piece
of software), they complained about the (lack of) device naming.

				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
Ctrl and Alt keys stuck -- press Del to continue.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[V13]

On Saturday 07 August 2004 02:15, Martin Mares wrote:
> Hello!
>
> > Let me lead you to the right place to look for:
> >
> > 	The CAM interface (which is from the SCSI standards group)
> > 	usually is implemeted in a way that applications open /dev/cam and
> > 	later supply bus, target and lun in order to get connected
> > 	to any device on the system that talks SCSI.
> >
> > Let me repeat: If you believe that this is a bad idea, give very good
> > reasons.
>
> There is one: hotplug. The physical topology of buses where all the
> SCSI-like devices (being it ATAPI devices, iSCSI, USB disks or other such
> beasts) are connected is too complex, so every attempt to map them to the
> (bus, target, lun) triplets in any sane way is destined to fail.

Just to add on this, how is someone supposed to distinguish between two 
identical USB recorders using the scanbus/X:Y:Z method? I suppose he'll have 
to try writting to both drives each time he replugs them instead of 
having /dev/cdr-red /dev/cdr-blue or something similar using hotplug/udev.

<<V13>>

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

V13 wrote:
> On Saturday 07 August 2004 02:15, Martin Mares wrote:
> 
>>Hello!
>>
>>
>>>Let me lead you to the right place to look for:
>>>
>>>	The CAM interface (which is from the SCSI standards group)
>>>	usually is implemeted in a way that applications open /dev/cam and
>>>	later supply bus, target and lun in order to get connected
>>>	to any device on the system that talks SCSI.
>>>
>>>Let me repeat: If you believe that this is a bad idea, give very good
>>>reasons.
>>
>>There is one: hotplug. The physical topology of buses where all the
>>SCSI-like devices (being it ATAPI devices, iSCSI, USB disks or other such
>>beasts) are connected is too complex, so every attempt to map them to the
>>(bus, target, lun) triplets in any sane way is destined to fail.
> 
> 
> Just to add on this, how is someone supposed to distinguish between two 
> identical USB recorders using the scanbus/X:Y:Z method? I suppose he'll have 
> to try writting to both drives each time he replugs them instead of 
> having /dev/cdr-red /dev/cdr-blue or something similar using hotplug/udev.

cat /proc/scsi/usb-storage/*

There is a utility (name escapes me) which allows binding of a NIC to a 
name by MAC address, it would be nice to be able to bind by serial 
number for IDE/SCSI/USB devices. However, until you do that, a simple 
script to create a few symlinks after discovery will solve your problem. 
Doesn't bug me enough to bother, but that's how.
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[James Bottomley]

On Fri, 2004-08-06 at 08:30, Joerg Schilling wrote:
> I don't see any arrogance in my mails but in former discussions on LKML,
> there have been other people who did believe that they could replace missing
> knowledge by arrogance. Fortunately, they did not join this thread ;-)
> 
> Let me lead you to the right place to look for:
> 
> 	The CAM interface (which is from the SCSI standards group)
> 	usually is implemeted in a way that applications open /dev/cam and
> 	later supply bus, target and lun in order to get connected
> 	to any device on the system that talks SCSI.
> 
> Let me repeat: If you believe that this is a bad idea, give very good reasons.

Although I have always thought CAM to be a bad idea, I can give you the
best of reasons why we won't be using it:  The old standard applies to
SCSI-2 and has been superceded. The committee charged with creating the
new CAM standard was disbanded in disarray, so there is no current CAM
standard.

I know all the arguments about politics and personality clashes that
have been alleged to be behind the collapse of the new standard. 
However, in my view, it was a bad standard and the evidence of its
unworkability is simply that the committee couldn't agree on it.

For us to look at CAM again, someone will have to at least make it a
current standard.

The model which looks to me to be very workable is SAM (or at least
SAM-3).  To that end, we're already moving the linux scsi layer (which
was actually pretty transport abstracted and thus SAM conformant anyway)
further in that direction with the creation of transport classes.

James

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Eric Lammerts]

On Fri, 6 Aug 2004, Joerg Schilling wrote:
> The CAM interface (which is from the SCSI standards group)
> usually is implemeted in a way that applications open /dev/cam and
> later supply bus, target and lun in order to get connected
> to any device on the system that talks SCSI.
>
> Let me repeat: If you believe that this is a bad idea, give very
> good reasons.

With this interface, how do you grant non-root users access to a CD
writer, but prevent them from directly accessing a SCSI harddisk?

Eric

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10029 bytes --]

>From: Jens Axboe <axboe@suse.de>

>> -	Linux sometimes bastardizes the SCSI commands sent to ATAPI drives.
>> 
>> 	Some people report that they cannot blank their CD-RW media for
>> 	this reason. See:
>> 
>> 	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099
>> 
>> 	Similar things happen when trying to read defective "CD-DA" media
>> 	created by the "Music Mafia". If you use a Plextor drive, everything
>> 	works fine. If you use a Pioneer drive, the SCSI command "READ FULL TOC"
>> 	aborts with "illegal field in CDB", rebooting the same PC to
>> 	SCO UnixWare makes the problem go away.
>> 
>> 	This problem has not yet been reported because I got the impression 
>> 	that nobody on LKML is interested in fixing CD/DVD writing related 
>> 	bugs. 
>> 
>> 	Time to fix: unknown - may be more than 2 weeks.

>That's very interesting, I've noted at least a few of these myself
>(where seemingly the same commands gets different results). Currently I
>have no lead on this.

This is why I say it takes more than 2 weeks....


>> -	ide-scsi does not use DMA if the "DMA size" is not a multiple of 512.
>> 	This bug has been reported many times! Last time was when you introduced
>> 	the unneeded SCSI transport via /dev/hd*. This interface initially
>> 	did have the same bug - it has been fixed. The same bug in ide-scsi
>> 	has not been fixed although I send several related mails :-(

>SG_IO for atapi was born working that way. This should have been fixed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sorry - you should know better that this is not true :-(
The unneeded /dev/hd interface has been created with the _same_ DMA
problems, ide-scsi still has. Later, when I complained about the problem it 
has been fixed. As the ide-scsi interface has not been fixed at the same time,
this did not look very friendly to me...

>in 2.4, agree, in 2.6 it's not so urgent (since /dev/hd* /dev/sr* works
>direct and does dma to anything, it'll bounce to kernel buffers if it
>has to).

Sorry, but you are wrong: ATAPI CD/DVD writers are primary SCSI devices and
thus need to primaryly appear in the SCSI device tree. Adding SG_IO support to
fd's that are a result of a call to open("/dev/hd... is a nice extra but
definitely not needed.


>> -	Parallel (50 bin) SCSI (unknown HBA) on Linux-2.6 does not work if
>> 	DMA size is not a multiple of 4. The data transferred from the SCSI
>> 	device is OK for the first part that is a multiple of 4.
>> 	The remainder of bytes arrive as binary zeroes.
>> 
>> 	This is a new bug (I received the related information this week).

>Might be a hardware issue.

It is definitely not:

1)	The user reported that this did work with a Linux-2.4 kernel
	The user was not 100% clear but it is likely that he did upgrade
	from SuSE-8.2 to SuSE-9.1

2)	This problem is a common mistake made by coders that did not
	understand 32 Bit DMA correctly.


>> -	ioctl(f, SCSI_IOCTL_GET_IDLUN, &sg_id)) and ioctl(f, SCSI_IOCTL_GET_BUS_NUMBER, &Bus)
>> 	do not return instance numbers if applied to a fd from /dev/hd*
>> 
>> 	This bug has been reported 2 years ago.
>> 
>> 	Time to fix: 10 minutes

>It has been argued several times that we will not doctor bus/id/lun on
>atapi devices, because it does not make sense. So I'm regarding this as
>invalid.

Sorry, I have more than 20 years of experiences in Kernel and Application 
hacking. I am able to decide myself what is a bug and what is something that
needs to be called at least "non-orthogonal behavior". This is devinitely 
 a bug or missing orthogonality. See above to understand (These are 
primarily SCSI devices and therefore they need to have instance numbers within 
the set of devices in the SCSI device tree).

If you do not fix this, you just verify that Linux does not like it's users.
Linux users like to call cdrecord -scanbus and they like to see _all_ SCSI 
devices from a single call to cdrecord. The fact that the Linux kernel does not
return instance numbers for /dev/hd* SCSI devices makes it impossible to
implement a unique address space :-(

>> -	DMA residual count is not returned (reported in 1998).
>> 	This is extremely important - it prevents me from unsing Linux as a
>> 	development platform.
>> 
>> 	Time to fix: about one month to rework the whole SCSI driver stack.

>That's bogus, the SCSI stack (as well as the block layer) is very well
>capable of reporting residual counts, and if the hardware can do it (we
>can't get it from some ide hardware :/), we will report residuals.

>So if it doesn't work it's a bug, but not a design bug.

For many reasons, all people in my vicinity run Linux-2.4 kernels, so I have no
way to test myself. It is easy for you to call "scgcheck" and fix the kernel 
until the interface matches the documentation.

Just make sure not to use a broken version from the SuSE source tree....
Here is the original:

	ftp://ftp.berlios.de/pub/cdrecord/alpha/


>> -	Only the first 14 bytes of SCSI Sense data is returned (reported
>>	in 1998) This is extremely important - it prevents me from unsing
>>	Linux as a development platform.	
>> 
>> 	Time to fix: about one month to rework the whole SCSI driver
>> 	stack.  With good luck, this may be done on 2 days.

>2.6 uses 96 byte sense buffers inside the command and copies back as
>much as specified in the sense buffer, I fear you have to qualify this
>bug some more (for SCSI). ide-cd uses 18 bytes.

If this is true, it could be documented by running "scgcheck". I would be happy
to include some text like "fixed in Linux-2.9.199" somewhere in README.linux
or README.ATAPI.


>> -	Many unclear problem reports lead me to the assumption that Linux-2.6
>> 	does not set up the SCSI command timeout properly. See previous point!

>Issued through SG_IO, or how? Again, more details are required.

If you like to see more details, it would make sense to read the related bug 
reports on debian.org and to subscribe to the cdrtools related mailing lists.
Bugs with unclear reasons that are most likely caused by incorrect timeouts
are reported frequently.

>> -	Linux Kernel include files (starting with Linux-2.5) are buggy and 
>> 	prevent compilation. Many files may be affected but let me name
>> 	the most important files for me:
>> 
>> 	-	/usr/src/linux/include/scsi/scsi.h depends on a nonexistant
>> 		type "u8". The correct way to fix this would be to replace
>> 		any "u8" by "uint8_t". A quick and dirty fix is to call:
>> 
>> 			"change u8 __u8 /usr/src/linux/include/scsi/scsi.h"
>> 
>> 		ftp://ftp.berlios.de/pub/change/
>> 
>> 	-	/usr/src/linux/include/scsi/sg.h includes "extra text" "__user"
>> 		in some structure definitions. This may be fixed by adding
>> 		#include <linux/compiler.h> somewhere at the beginning of
>> 		/usr/src/linux/include/scsi/sg.h
>> 
>> 	This bug has been reported several times (starting with Linux-2.5).
>> 
>> 	Time to fix: 5 minutes.

>This has also been discussed before, you should not include the kernel
>headers. Yes I know you don't agree, but that's how it is for now.

You just need to admit that the Linux kernel is _not_ related to the
rest of a typical Linux installation (so this is definitely different
situation than on e.g. FreeBSD or Solaris). If you like to compile an
application that uses kernel interfaces, you need to make sure that both,
the application and the kernel are compiled with the same
"interface description" which is just the kernel include files.

Please do not come up with the same funny arguments that other people did
use in the past by trying to tell me that the kernel interfaces used by
libscg are interfaces provided by glibc.....

Of course, you have a second way to go:

	You could set up a copy of the Linux Kernel include file tree,
	fix this tree and include the fixed version with _every_ Linux source
	distribution. Of course, you need to make sure that the interfaces
	seen in the fixed include tree always exactly match the related
	Kernel sources. Guess which method creates a higher work load.

>> There may be other problems that I do not remember now. If I would get
>> the impression that LKML is interested in fixing CD/DVD writing
>> related bugs, I would report more.....

>If they are kernel bugs, of course we want to know! The above is a
>pretty damn good start, I just wish you would include more info (or test
>cases...) as they are a bit ambigious in several places. I understand if
>you just wanted to list some of them down and that is fine. Perhaps I
>can get you to elaborate on the ones where I added followup questions?

Let me make a proposal:

The most important problem currently is caused by the bugs in the Linux
kernel include files. As it takes only 5 minutes to fix the include 
file bugs that are related to cdrtools, I would like to see this bug
fixed first.

After I've seen a kernel without the named bugs appering on kernel.org,
I am very willing to help you to find the reason for the other bugs.
Make your choice which of the problems to check first....... however,
it would be a nice gesture to fix the DMA only for x % 512 == 0
problem in ide-scsi next.


>> From the current number of problem reports, it looks like Linux-2.6 is
>> not yet ready for general use as too many problems only appear on
>> Linux-2.6. I currently give peeople the advise to either go back to
>> Linux-2.4 or to check Solaris (see
>> http://wwws.sun.com/software/solaris/solaris-express/get.html).

>If they wish to sell their soul...

I don't like to sell my soul and this is exactly why I prefer Solaris.

I wish that discussions with the Linux kernel hackers would be as
easy and fruitful as they are with the Solaris kernel hackers.

I wish that bugs in the Linux kernel were fixed as fast as they are
fixed 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)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Fri, Aug 06 2004, Joerg Schilling wrote:
> >> -	ide-scsi does not use DMA if the "DMA size" is not a multiple of 512.
> >> 	This bug has been reported many times! Last time was when you introduced
> >> 	the unneeded SCSI transport via /dev/hd*. This interface initially
> >> 	did have the same bug - it has been fixed. The same bug in ide-scsi
> >> 	has not been fixed although I send several related mails :-(
> 
> >SG_IO for atapi was born working that way. This should have been fixed
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Sorry - you should know better that this is not true :-( The unneeded
> /dev/hd interface has been created with the _same_ DMA problems,
> ide-scsi still has. Later, when I complained about the problem it has
> been fixed. As the ide-scsi interface has not been fixed at the same
> time, this did not look very friendly to me...

I think I know the history of it, I picked up the pieces of the stuff
Linus originally did. Originally, there was _no_ dma support. I can only
imagine that Linus put it in to have someone fix it, because it was
unustable at the time. I forget how long that lasted, but it can't have
been more than a few weeks. So it was not the same problem at all. It
did not use dma because it set up a contig buffer in rq->buffer, which
ide-cd doesn't convert to prd tables for dma. This was quickly fixed and
with granular alignment/length restrictions for dma operations, as I
outlined it defaulted to 4-bytes for ide-cd then. This was all during
the 2.5 development cycle.

> >in 2.4, agree, in 2.6 it's not so urgent (since /dev/hd* /dev/sr* works
> >direct and does dma to anything, it'll bounce to kernel buffers if it
> >has to).
> 
> Sorry, but you are wrong: ATAPI CD/DVD writers are primary SCSI
> devices and thus need to primaryly appear in the SCSI device tree.
> Adding SG_IO support to fd's that are a result of a call to
> open("/dev/hd... is a nice extra but definitely not needed.

Bogus, and I'll again refrain from commenting on that because it's a
matter of opinion and we all know yours. They use the same command set,
but there's absolutely no reason why you would need to export them as
SCSI devices and fake bus/id/lun naming etc.

> >> -	Parallel (50 bin) SCSI (unknown HBA) on Linux-2.6 does not work if
> >> 	DMA size is not a multiple of 4. The data transferred from the SCSI
> >> 	device is OK for the first part that is a multiple of 4.
> >> 	The remainder of bytes arrive as binary zeroes.
> >> 
> >> 	This is a new bug (I received the related information this week).
> 
> >Might be a hardware issue.
> 
> It is definitely not:
> 
> 1)	The user reported that this did work with a Linux-2.4 kernel
> 	The user was not 100% clear but it is likely that he did upgrade
> 	from SuSE-8.2 to SuSE-9.1
> 
> 2)	This problem is a common mistake made by coders that did not
> 	understand 32 Bit DMA correctly.

Then have that user report the user. You cannot possibly expect me to
give any sort of qualified advice based on a rapport so void of detail as
the above is!

> >> -	ioctl(f, SCSI_IOCTL_GET_IDLUN, &sg_id)) and ioctl(f, SCSI_IOCTL_GET_BUS_NUMBER, &Bus)
> >> 	do not return instance numbers if applied to a fd from /dev/hd*
> >> 
> >> 	This bug has been reported 2 years ago.
> >> 
> >> 	Time to fix: 10 minutes
> 
> >It has been argued several times that we will not doctor bus/id/lun on
> >atapi devices, because it does not make sense. So I'm regarding this as
> >invalid.
> 
> Sorry, I have more than 20 years of experiences in Kernel and
> Application hacking. I am able to decide myself what is a bug and what
> is something that needs to be called at least "non-orthogonal
> behavior". This is devinitely a bug or missing orthogonality. See
> above to understand (These are primarily SCSI devices and therefore
> they need to have instance numbers within the set of devices in the
> SCSI device tree).

Those 20 years at least do seem to buy you a whole lot of arrogance.
I'll explain to you why no thread you start here on lkml goes anywhere -
because you refuse to listen to anyone. You have 20 years of experience
so anything you say must be absolutely true, there's not a gram of
reason in the world coming from other people. Thus there's no point in
debating with you on these issues.

I'll say again that _I_ think making up SCSI like addressing for ATAPI
is completely bogus, because ATAPI isn't addressed that way. You are
inventing magic numbers! Just because these devices happen to share the
same command set (almost, which btw do most storage devices these days)
does not mean they share the bus topology.

> If you do not fix this, you just verify that Linux does not like it's
> users.  Linux users like to call cdrecord -scanbus and they like to
> see _all_ SCSI devices from a single call to cdrecord. The fact that
> the Linux kernel does not return instance numbers for /dev/hd* SCSI
> devices makes it impossible to implement a unique address space :-(

I'm sure new users love to find out they need to use -dev=0,1,0 to
specify their cd burner, they must find that really intuitive and
straight forward. It's much easier than just using /dev/cdr, or whatever
you want to name the special file. Indeed.

> >> -	DMA residual count is not returned (reported in 1998).
> >> 	This is extremely important - it prevents me from unsing Linux as a
> >> 	development platform.
> >> 
> >> 	Time to fix: about one month to rework the whole SCSI driver stack.
> 
> >That's bogus, the SCSI stack (as well as the block layer) is very well
> >capable of reporting residual counts, and if the hardware can do it (we
> >can't get it from some ide hardware :/), we will report residuals.
> 
> >So if it doesn't work it's a bug, but not a design bug.
> 
> For many reasons, all people in my vicinity run Linux-2.4 kernels, so
> I have no way to test myself. It is easy for you to call "scgcheck"
> and fix the kernel until the interface matches the documentation.
>
> Just make sure not to use a broken version from the SuSE source tree....
> Here is the original:
> 
> 	ftp://ftp.berlios.de/pub/cdrecord/alpha/

I'll give that a spin, thanks.

> >> -	Only the first 14 bytes of SCSI Sense data is returned (reported
> >>	in 1998) This is extremely important - it prevents me from unsing
> >>	Linux as a development platform.	
> >> 
> >> 	Time to fix: about one month to rework the whole SCSI driver
> >> 	stack.  With good luck, this may be done on 2 days.
> 
> >2.6 uses 96 byte sense buffers inside the command and copies back as
> >much as specified in the sense buffer, I fear you have to qualify this
> >bug some more (for SCSI). ide-cd uses 18 bytes.
> 
> If this is true, it could be documented by running "scgcheck". I would
> be happy to include some text like "fixed in Linux-2.9.199" somewhere
> in README.linux or README.ATAPI.

Great.

> >> -	Many unclear problem reports lead me to the assumption that Linux-2.6
> >> 	does not set up the SCSI command timeout properly. See previous point!
> 
> >Issued through SG_IO, or how? Again, more details are required.
> 
> If you like to see more details, it would make sense to read the
> related bug reports on debian.org and to subscribe to the cdrtools
> related mailing lists.  Bugs with unclear reasons that are most likely
> caused by incorrect timeouts are reported frequently.

That's fine if you work on nothing but that, but I personally don't want
to subscribe to more lists. I don't have time to follow them anyways. If
there's a Linux kernel bug, people should be pointed at linux-kernel and
follow the general rules of reporting issues there.

Likewise if I see someone report a bug here with using cdrecord that
looks like a cdrecord issue, I'll point them at you.

> >> -	Linux Kernel include files (starting with Linux-2.5) are buggy and 
> >> 	prevent compilation. Many files may be affected but let me name
> >> 	the most important files for me:
> >> 
> >> 	-	/usr/src/linux/include/scsi/scsi.h depends on a nonexistant
> >> 		type "u8". The correct way to fix this would be to replace
> >> 		any "u8" by "uint8_t". A quick and dirty fix is to call:
> >> 
> >> 			"change u8 __u8 /usr/src/linux/include/scsi/scsi.h"
> >> 
> >> 		ftp://ftp.berlios.de/pub/change/
> >> 
> >> 	-	/usr/src/linux/include/scsi/sg.h includes "extra text" "__user"
> >> 		in some structure definitions. This may be fixed by adding
> >> 		#include <linux/compiler.h> somewhere at the beginning of
> >> 		/usr/src/linux/include/scsi/sg.h
> >> 
> >> 	This bug has been reported several times (starting with Linux-2.5).
> >> 
> >> 	Time to fix: 5 minutes.
> 
> >This has also been discussed before, you should not include the kernel
> >headers. Yes I know you don't agree, but that's how it is for now.
> 
> You just need to admit that the Linux kernel is _not_ related to the
> rest of a typical Linux installation (so this is definitely different
> situation than on e.g. FreeBSD or Solaris). If you like to compile an
> application that uses kernel interfaces, you need to make sure that
> both, the application and the kernel are compiled with the same
> "interface description" which is just the kernel include files.
> 
> Please do not come up with the same funny arguments that other people did
> use in the past by trying to tell me that the kernel interfaces used by
> libscg are interfaces provided by glibc.....
> 
> Of course, you have a second way to go:
> 
> 	You could set up a copy of the Linux Kernel include file tree,
> 	fix this tree and include the fixed version with _every_ Linux source
> 	distribution. Of course, you need to make sure that the interfaces
> 	seen in the fixed include tree always exactly match the related
> 	Kernel sources. Guess which method creates a higher work load.

I've never followed these threads closely, and I'm not the guy to
comment on that. It's been discussed here recently, you might want to
search linux-kernel archives for include/abi and similar.

> >> There may be other problems that I do not remember now. If I would get
> >> the impression that LKML is interested in fixing CD/DVD writing
> >> related bugs, I would report more.....
> 
> >If they are kernel bugs, of course we want to know! The above is a
> >pretty damn good start, I just wish you would include more info (or test
> >cases...) as they are a bit ambigious in several places. I understand if
> >you just wanted to list some of them down and that is fine. Perhaps I
> >can get you to elaborate on the ones where I added followup questions?
> 
> Let me make a proposal:
> 
> The most important problem currently is caused by the bugs in the Linux
> kernel include files. As it takes only 5 minutes to fix the include 
> file bugs that are related to cdrtools, I would like to see this bug
> fixed first.

Then either fix it and post the patch, or write a detailed bug report
and hope that someone else fixes it. That's how it works. You have no
support contract with me.

> After I've seen a kernel without the named bugs appering on
> kernel.org, I am very willing to help you to find the reason for the
> other bugs.  Make your choice which of the problems to check
> first....... however, it would be a nice gesture to fix the DMA only
> for x % 512 == 0 problem in ide-scsi next.

The importance of that bug is slowly decreasing - in 2.6 ide-scsi isn't
needed, and 2.4 is pretty much set in stone and I doubt we'd fix this
bug in fear of introducing regressions on some hardware.

> >> From the current number of problem reports, it looks like Linux-2.6 is
> >> not yet ready for general use as too many problems only appear on
> >> Linux-2.6. I currently give peeople the advise to either go back to
> >> Linux-2.4 or to check Solaris (see
> >> http://wwws.sun.com/software/solaris/solaris-express/get.html).
> 
> >If they wish to sell their soul...
> 
> I don't like to sell my soul and this is exactly why I prefer Solaris.

I'd consider signing licenses to be able to get the OS at least partly
selling my soul, where as Linux requires you to sign nothing and is
completely free and open.

> I wish that discussions with the Linux kernel hackers would be as
> easy and fruitful as they are with the Solaris kernel hackers.
>
> I wish that bugs in the Linux kernel were fixed as fast as they are
> fixed on Solaris.

Maybe you'll have better luck when they are all hacking Linux instead in
the future.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Fri, Aug 06 2004, Jens Axboe wrote:
> > >> -	Only the first 14 bytes of SCSI Sense data is returned (reported
> > >>	in 1998) This is extremely important - it prevents me from unsing
> > >>	Linux as a development platform.	
> > >> 
> > >> 	Time to fix: about one month to rework the whole SCSI driver
> > >> 	stack.  With good luck, this may be done on 2 days.
> > 
> > >2.6 uses 96 byte sense buffers inside the command and copies back as
> > >much as specified in the sense buffer, I fear you have to qualify this
> > >bug some more (for SCSI). ide-cd uses 18 bytes.
> > 
> > If this is true, it could be documented by running "scgcheck". I would
> > be happy to include some text like "fixed in Linux-2.9.199" somewhere
> > in README.linux or README.ATAPI.
> 
> Great.

So I downloaded:

ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01a35.tar.gz

and built it, ran scgcheck on a SCSI hard drive. And you pass in
->mx_sb_len == 16 to the sg driver, so that's why it's not copying more
than 16 bytes back to you. There are 18 available in that first test
case. Here's that test case:

Testing if at least CCS_SENSE_LEN (18) is supported...
Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 00
---------->     Method 0x00: expected: 18 reported: 16 max found: 16
Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 FF FF
---------->     Method 0xFF: expected: 18 reported: 16 max found: 16
---------->     Minimum standard (CCS) sense length failed
---------->     Wanted 18 sense bytes, got (16)
Testing for 32 bytes of sense data...
Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
---------->     Method 0x00: expected: 32 reported: 16 max found: 16
Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF
---------->     Method 0xFF: expected: 32 reported: 16 max found: 16
---------->     Wanted 32 sense bytes, got (16)
----------> Got a maximum of 16 sense bytes
----------> SCSI sense count test FAILED
----------> SCSI status byte test NOT YET READY

Changing your scsi-linux-sg.c to set max sense to 64:

Testing if at least CCS_SENSE_LEN (18) is supported...
Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 03
---------->     Method 0x00: expected: 18 reported: 18 max found: 18
Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 03
---------->     Method 0xFF: expected: 18 reported: 18 max found: 18
---------->     Wanted 18 sense bytes, got it.
Testing for 32 bytes of sense data...
Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 03 00 00
00 00 00 00 00 00 00 00 00 00 00 00
---------->     Method 0x00: expected: 32 reported: 18 max found: 18
Sense Data: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 03 FF FF
FF FF FF FF FF FF FF FF FF FF FF FF
---------->     Method 0xFF: expected: 32 reported: 18 max found: 18
---------->     Wanted 32 sense bytes, got (18)
----------> Got a maximum of 18 sense bytes
----------> SCSI sense count test PASSED
----------> SCSI status byte test NOT YET READY

and it passes just fine. What's the deal?

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Vojtech Pavlik]

On Fri, Aug 06, 2004 at 12:18:39PM +0200, Joerg Schilling wrote:

> >> -	ioctl(f, SCSI_IOCTL_GET_IDLUN, &sg_id)) and ioctl(f, SCSI_IOCTL_GET_BUS_NUMBER, &Bus)
> >> 	do not return instance numbers if applied to a fd from /dev/hd*
> >> 
> >> 	This bug has been reported 2 years ago.
> >> 
> >> 	Time to fix: 10 minutes
> 
> >It has been argued several times that we will not doctor bus/id/lun on
> >atapi devices, because it does not make sense. So I'm regarding this as
> >invalid.
> 
> Sorry, I have more than 20 years of experiences in Kernel and Application 
> hacking. I am able to decide myself what is a bug and what is something that
> needs to be called at least "non-orthogonal behavior". This is devinitely 
>  a bug or missing orthogonality. See above to understand (These are 
> primarily SCSI devices and therefore they need to have instance numbers within 
> the set of devices in the SCSI device tree).
> 
> If you do not fix this, you just verify that Linux does not like it's users.
> Linux users like to call cdrecord -scanbus and they like to see _all_ SCSI 
> devices from a single call to cdrecord. The fact that the Linux kernel does not
> return instance numbers for /dev/hd* SCSI devices makes it impossible to
> implement a unique address space :-(
 
I'm a long time Linux and cdrecord user, and I must say I always hated
the -scanbus thingy. It's so much easier to just pass the /dev/hdc
device node, where I _know_ my CD burner lives than to have to figure
out what fake SCSI address cdrecord has made up and requires me to pass
to it, even when I have just a single CD burner in my system.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[H. Peter Anvin]

Followup to:  <20040806175937.GA296@ucw.cz>
By author:    Vojtech Pavlik <vojtech@suse.cz>
In newsgroup: linux.dev.kernel
> > 
> > If you do not fix this, you just verify that Linux does not like it's users.
> > Linux users like to call cdrecord -scanbus and they like to see _all_ SCSI 
> > devices from a single call to cdrecord. The fact that the Linux kernel does not
> > return instance numbers for /dev/hd* SCSI devices makes it impossible to
> > implement a unique address space :-(
>  
> I'm a long time Linux and cdrecord user, and I must say I always hated
> the -scanbus thingy. It's so much easier to just pass the /dev/hdc
> device node, where I _know_ my CD burner lives than to have to figure
> out what fake SCSI address cdrecord has made up and requires me to pass
> to it, even when I have just a single CD burner in my system.
> 

Indeed.  To a first order it doesn't matter if the default system
namespace is crappy -- applications inventing its own namespaces
(usually inconsistently) means that it's IMPOSSIBLE to make all
applications do the same thing - which is actually more important to
make them all do "the right thing."  Furthermore, it blocks
improvements such as udev.

Note there is nothing that says cdrecord -scanbus can't print out
a list, using the system device names.

	-hpa

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Fri, 6 Aug 2004 22:47:46 +0000 (UTC)
hpa@zytor.com (H. Peter Anvin) wrote:

> Followup to:  <20040806175937.GA296@ucw.cz>
> By author:    Vojtech Pavlik <vojtech@suse.cz>
> In newsgroup: linux.dev.kernel
> > > 
> > > If you do not fix this, you just verify that Linux does not like it's
> > > users. Linux users like to call cdrecord -scanbus and they like to see
> > > _all_ SCSI devices from a single call to cdrecord. The fact that the
> > > Linux kernel does not return instance numbers for /dev/hd* SCSI devices
> > > makes it impossible to implement a unique address space :-(
> >  
> > I'm a long time Linux and cdrecord user, and I must say I always hated
> > the -scanbus thingy. It's so much easier to just pass the /dev/hdc
> > device node, where I _know_ my CD burner lives than to have to figure
> > out what fake SCSI address cdrecord has made up and requires me to pass
> > to it, even when I have just a single CD burner in my system.
> > 
> 
> Indeed.  To a first order it doesn't matter if the default system
> namespace is crappy -- applications inventing its own namespaces
> (usually inconsistently) means that it's IMPOSSIBLE to make all
> applications do the same thing - which is actually more important to
> make them all do "the right thing."  Furthermore, it blocks
> improvements such as udev.
> 
> Note there is nothing that says cdrecord -scanbus can't print out
> a list, using the system device names.
> 

To add a pure users' comment to the story:

Maybe you should not overestimate cdrecord as a tool (like its author obviously
does sometimes). At least for DVD there are well-working alternatives.

If Joerg feels a better home on Solaris, so be it. It's his right to decide for
solaris, just as it is a users' right to decide against cdrecord.


Regards,
Stephan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Julien Oster]

Stephan von Krawczynski <skraw@ithnet.com> writes:

>> > > If you do not fix this, you just verify that Linux does not like it's
>> > > users. Linux users like to call cdrecord -scanbus and they like to see
>> > > _all_ SCSI devices from a single call to cdrecord.
[...]

> To add a pure users' comment to the story:

Considering cdrecord, I am also a pure user. And my reaction when I
first used it and discovered the -scanbus/dev=id,id,id thingy was not
very pleasent. I was very confused by the fact that I couldn't just
give it /dev/whatever like I was used to with, well, everything
else. (I'm not only used to it, /dev/... is also how Linux works, from
my pov. That's just why it exists.)

I thought a minute about it and came to the immediate conclusion:
there's something wrong with the kernel interface, which prevents
cdrecord from just using the device file. I figured that someone would
fix it very soon and accepted the dev=id,id,id solution temporarily
(without really ever getting used to it).

Now I learned that it is a deliberate design issue with cdrecord and I
am left stunned.

Even before knowing that (i.e., some days ago) I still hated to
specify dev=id,id,id.

> Maybe you should not overestimate cdrecord as a tool (like its author obviously
> does sometimes). At least for DVD there are well-working alternatives.

Oh yes. I suspect you're talking of growisofs? I'm not kidding when I
tell you that I was really thrilled when I discovered that it allows
me to specify the device file. Remember, at that point I still thought
the dev=... was a bug and I was glad that the growisofs author found a
way to fix or workaround this bug (that's what I thought).

Since growisofs was doing a nice, straightforward job for me, I tried
to burn CD-Rs instead of DVDs with it, but unfortunately this didn't
work.

> If Joerg feels a better home on Solaris, so be it. It's his right to decide for
> solaris, just as it is a users' right to decide against cdrecord.

Well, do you know any alternatives for CD-Rs? I'm normally all the
"f* it, I'm just writing the tool myself and then I know it's doing
what I want"-guy, but I really don't feel the urge to get into
that ATAPI/burning stuff pressed on me.

Regards,
Julien

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]


>From: David Woodhouse <dwmw2@infradead.org>

>On Thu, 2004-08-05 at 14:45 +0200, Joerg Schilling wrote:
>> ....I am not repsonsible for your mail box....

>Actually, you are partly responsible for the mess in my mail box. Please
>fix your mail client to correctly insert References: and/or In-Reply-To:
>headers such that your replies are not each starting a new thread of
>their own.

Before you are making the wrong conclsuions, I encourage you to read RFC-2822
and to find somebody who is able to explain you the difference between the
words "must" and "should" when used in standards....

Sorry for the typo in the last mail, it must of course not be "shall" but 
"should" ;-) Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Fri, 2004-08-06 at 10:14 +0200, Joerg Schilling wrote:
> Before you are making the wrong conclsuions, I encourage you to read RFC-2822
> and to find somebody who is able to explain you the difference between the
> words "must" and "should" when used in standards....

Actually I don't need to find somebody to explain it to me. RFC 2119
makes it very clear:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Would you care to explain what valid reasons you have for ignoring
§3.6.4 of RFC2822, and why those override the implications of doing so
(which, as stated, is that you break the threading of your replies and
cause the signal:noise ratio to degrade).

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Joerg Schilling wrote:

> Before you are making the wrong conclsuions, I encourage you to read RFC-2822
> and to find somebody who is able to explain you the difference between the
> words "must" and "should" when used in standards....
> 
> Sorry for the typo in the last mail, it must of course not be "shall" but 
> "should" ;-) Jörg

May it be must, shall or should... Your mail client destroys the thread
structure and it would indeed help everbody trying to follow the discussion
if you could try to change it...

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

>From: David Woodhouse <dwmw2@infradead.org>

>On Thu, 2004-08-05 at 14:45 +0200, Joerg Schilling wrote:
>> ....I am not repsonsible for your mail box....

>Actually, you are partly responsible for the mess in my mail box. Please
>fix your mail client to correctly insert References: and/or In-Reply-To:
>headers such that your replies are not each starting a new thread of
>their own.

Before you are making the wrong conclsuions, I encourage you to read RFC-2822
and to find somebody who is able to explain you the difference between the
woerds "must" and "shall" when used in standards....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4947 bytes --]

>From: Jens Axboe <axboe@suse.de>


>> In 1998, I did send a patch against the sg.c driver that introduced
>> everything that is needed for Generic SCSI transport. I am still
>> waiting for even the needed features to appear........

>If you have issues with SG_IO, please feel free to address them. If they
>are valid, I'd love to help you get it fixed.


Here is the current list of problems with CD/DVD writing on Linux:

-	Linux sometimes bastardizes the SCSI commands sent to ATAPI drives.

	Some people report that they cannot blank their CD-RW media for
	this reason. See:

	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099

	Similar things happen when trying to read defective "CD-DA" media
	created by the "Music Mafia". If you use a Plextor drive, everything
	works fine. If you use a Pioneer drive, the SCSI command "READ FULL TOC"
	aborts with "illegal field in CDB", rebooting the same PC to
	SCO UnixWare makes the problem go away.

	This problem has not yet been reported because I got the impression 
	that nobody on LKML is interested in fixing CD/DVD writing related 
	bugs. 

	Time to fix: unknown - may be more than 2 weeks.

-	ide-scsi does not use DMA if the "DMA size" is not a multiple of 512.
	This bug has been reported many times! Last time was when you introduced
	the unneeded SCSI transport via /dev/hd*. This interface initially
	did have the same bug - it has been fixed. The same bug in ide-scsi
	has not been fixed although I send several related mails :-(

	Time to fix: less than a day (for Jens)

-	Parallel (50 bin) SCSI (unknown HBA) on Linux-2.6 does not work if
	DMA size is not a multiple of 4. The data transferred from the SCSI
	device is OK for the first part that is a multiple of 4.
	The remainder of bytes arrive as binary zeroes.

	This is a new bug (I received the related information this week).

	Time to fix: approx. one day

-	ioctl(f, SCSI_IOCTL_GET_IDLUN, &sg_id)) and ioctl(f, SCSI_IOCTL_GET_BUS_NUMBER, &Bus)
	do not return instance numbers if applied to a fd from /dev/hd*

	This bug has been reported 2 years ago.

	Time to fix: 10 minutes

-	DMA residual count is not returned (reported in 1998).
	This is extremely important - it prevents me from unsing Linux as a
	development platform.

	Time to fix: about one month to rework the whole SCSI driver stack.

-	Only the first 14 bytes of SCSI Sense data is returned (reported in 1998)
	This is extremely important - it prevents me from unsing Linux as a
	development platform.	

	Time to fix: about one month to rework the whole SCSI driver stack.
	With good luck, this may be done on 2 days.

-	Unclear documentation whether DID_TIME_OUT should apply to a selection
	time out, a SCSI command timeout or both.

	Time to fix: one day

-	It seems that the only way to find out whether a SCSI command did time 
	out is to meter the time it takes and guess for any unclear return
	codes that coincidence with a command time >= the set up timeout to
	assume a SCSI command timeout.

	Time to fix: one day

-	Many unclear problem reports lead me to the assumption that Linux-2.6
	does not set up the SCSI command timeout properly. See previous point!

	Time to fix: 

-	Linux Kernel include files (starting with Linux-2.5) are buggy and 
	prevent compilation. Many files may be affected but let me name
	the most important files for me:

	-	/usr/src/linux/include/scsi/scsi.h depends on a nonexistant
		type "u8". The correct way to fix this would be to replace
		any "u8" by "uint8_t". A quick and dirty fix is to call:

			"change u8 __u8 /usr/src/linux/include/scsi/scsi.h"

		ftp://ftp.berlios.de/pub/change/

	-	/usr/src/linux/include/scsi/sg.h includes "extra text" "__user"
		in some structure definitions. This may be fixed by adding
		#include <linux/compiler.h> somewhere at the beginning of
		/usr/src/linux/include/scsi/sg.h

	This bug has been reported several times (starting with Linux-2.5).

	Time to fix: 5 minutes.
	
There may be other problems that I do not remember now. If I would get the 
impression that LKML is interested in fixing CD/DVD writing related bugs, I 
would report more.....

>From the current number of problem reports, it looks like Linux-2.6 is not yet 
ready for general use as too many problems only appear on Linux-2.6. I 
currently give peeople the advise to either go back to Linux-2.4 or to check
Solaris (see http://wwws.sun.com/software/solaris/solaris-express/get.html).

As my previous experiences with discussions on LKML have not been very 
fruitful, I would propose to suspend the current discussion to a time after
at least some bugs from the list above have been fixed.




Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Thu, Aug 05 2004, Joerg Schilling wrote:
> >From: Jens Axboe <axboe@suse.de>
> 
> 
> >> In 1998, I did send a patch against the sg.c driver that introduced
> >> everything that is needed for Generic SCSI transport. I am still
> >> waiting for even the needed features to appear........
> 
> >If you have issues with SG_IO, please feel free to address them. If they
> >are valid, I'd love to help you get it fixed.
> 
> 
> Here is the current list of problems with CD/DVD writing on Linux:
> 
> -	Linux sometimes bastardizes the SCSI commands sent to ATAPI drives.
> 
> 	Some people report that they cannot blank their CD-RW media for
> 	this reason. See:
> 
> 	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099
> 
> 	Similar things happen when trying to read defective "CD-DA" media
> 	created by the "Music Mafia". If you use a Plextor drive, everything
> 	works fine. If you use a Pioneer drive, the SCSI command "READ FULL TOC"
> 	aborts with "illegal field in CDB", rebooting the same PC to
> 	SCO UnixWare makes the problem go away.
> 
> 	This problem has not yet been reported because I got the impression 
> 	that nobody on LKML is interested in fixing CD/DVD writing related 
> 	bugs. 
> 
> 	Time to fix: unknown - may be more than 2 weeks.

That's very interesting, I've noted at least a few of these myself
(where seemingly the same commands gets different results). Currently I
have no lead on this.

> -	ide-scsi does not use DMA if the "DMA size" is not a multiple of 512.
> 	This bug has been reported many times! Last time was when you introduced
> 	the unneeded SCSI transport via /dev/hd*. This interface initially
> 	did have the same bug - it has been fixed. The same bug in ide-scsi
> 	has not been fixed although I send several related mails :-(

SG_IO for atapi was born working that way. This should have been fixed
in 2.4, agree, in 2.6 it's not so urgent (since /dev/hd* /dev/sr* works
direct and does dma to anything, it'll bounce to kernel buffers if it
has to).

> -	Parallel (50 bin) SCSI (unknown HBA) on Linux-2.6 does not work if
> 	DMA size is not a multiple of 4. The data transferred from the SCSI
> 	device is OK for the first part that is a multiple of 4.
> 	The remainder of bytes arrive as binary zeroes.
> 
> 	This is a new bug (I received the related information this week).

Might be a hardware issue.

> -	ioctl(f, SCSI_IOCTL_GET_IDLUN, &sg_id)) and ioctl(f, SCSI_IOCTL_GET_BUS_NUMBER, &Bus)
> 	do not return instance numbers if applied to a fd from /dev/hd*
> 
> 	This bug has been reported 2 years ago.
> 
> 	Time to fix: 10 minutes

It has been argued several times that we will not doctor bus/id/lun on
atapi devices, because it does not make sense. So I'm regarding this as
invalid.

> -	DMA residual count is not returned (reported in 1998).
> 	This is extremely important - it prevents me from unsing Linux as a
> 	development platform.
> 
> 	Time to fix: about one month to rework the whole SCSI driver stack.

That's bogus, the SCSI stack (as well as the block layer) is very well
capable of reporting residual counts, and if the hardware can do it (we
can't get it from some ide hardware :/), we will report residuals.

So if it doesn't work it's a bug, but not a design bug.

> -	Only the first 14 bytes of SCSI Sense data is returned (reported
>	in 1998) This is extremely important - it prevents me from unsing
>	Linux as a development platform.	
> 
> 	Time to fix: about one month to rework the whole SCSI driver
> 	stack.  With good luck, this may be done on 2 days.

2.6 uses 96 byte sense buffers inside the command and copies back as
much as specified in the sense buffer, I fear you have to qualify this
bug some more (for SCSI). ide-cd uses 18 bytes.

> -	Unclear documentation whether DID_TIME_OUT should apply to a selection
> 	time out, a SCSI command timeout or both.
> 
> 	Time to fix: one day
> 
> -	It seems that the only way to find out whether a SCSI command did time 
> 	out is to meter the time it takes and guess for any unclear return
> 	codes that coincidence with a command time >= the set up timeout to
> 	assume a SCSI command timeout.
> 
> 	Time to fix: one day

Maybe James can clarify these?

> -	Many unclear problem reports lead me to the assumption that Linux-2.6
> 	does not set up the SCSI command timeout properly. See previous point!

Issued through SG_IO, or how? Again, more details are required.

> -	Linux Kernel include files (starting with Linux-2.5) are buggy and 
> 	prevent compilation. Many files may be affected but let me name
> 	the most important files for me:
> 
> 	-	/usr/src/linux/include/scsi/scsi.h depends on a nonexistant
> 		type "u8". The correct way to fix this would be to replace
> 		any "u8" by "uint8_t". A quick and dirty fix is to call:
> 
> 			"change u8 __u8 /usr/src/linux/include/scsi/scsi.h"
> 
> 		ftp://ftp.berlios.de/pub/change/
> 
> 	-	/usr/src/linux/include/scsi/sg.h includes "extra text" "__user"
> 		in some structure definitions. This may be fixed by adding
> 		#include <linux/compiler.h> somewhere at the beginning of
> 		/usr/src/linux/include/scsi/sg.h
> 
> 	This bug has been reported several times (starting with Linux-2.5).
> 
> 	Time to fix: 5 minutes.

This has also been discussed before, you should not include the kernel
headers. Yes I know you don't agree, but that's how it is for now.

> There may be other problems that I do not remember now. If I would get
> the impression that LKML is interested in fixing CD/DVD writing
> related bugs, I would report more.....

If they are kernel bugs, of course we want to know! The above is a
pretty damn good start, I just wish you would include more info (or test
cases...) as they are a bit ambigious in several places. I understand if
you just wanted to list some of them down and that is fine. Perhaps I
can get you to elaborate on the ones where I added followup questions?

> From the current number of problem reports, it looks like Linux-2.6 is
> not yet ready for general use as too many problems only appear on
> Linux-2.6. I currently give peeople the advise to either go back to
> Linux-2.4 or to check Solaris (see
> http://wwws.sun.com/software/solaris/solaris-express/get.html).

If they wish to sell their soul...

2.6 is newer, so it's not unnatural if it has a few more bugs right now.
Especially since some of this infrastructure is new in 2.6. But
generally I think it works well, 2.6.8 will work a lot better as it
fixed several bugs in this area (though none of those you outline
above).

> As my previous experiences with discussions on LKML have not been very
> fruitful, I would propose to suspend the current discussion to a time
> after at least some bugs from the list above have been fixed.

Well I'm not going to point fingers.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[James Bottomley]

On Thu, 2004-08-05 at 08:00, Jens Axboe wrote:
> On Thu, Aug 05 2004, Joerg Schilling wrote:
> > -	Parallel (50 bin) SCSI (unknown HBA) on Linux-2.6 does not work if
> > 	DMA size is not a multiple of 4. The data transferred from the SCSI
> > 	device is OK for the first part that is a multiple of 4.
> > 	The remainder of bytes arrive as binary zeroes.
> > 
> > 	This is a new bug (I received the related information this week).
> 
> Might be a hardware issue.

Probably it is.  Lots of hardware FIFO chips are 4 or 8 bytes wide and
can't do partial transfers (because of the way the cycle the data off
the bus).  Usually they have logic that sends only partial fragments on
to the device for commands, but its not unknown for them to forget this
on actual data transfers

> > -	DMA residual count is not returned (reported in 1998).
> > 	This is extremely important - it prevents me from unsing Linux as a
> > 	development platform.
> > 
> > 	Time to fix: about one month to rework the whole SCSI driver stack.
> 
> That's bogus, the SCSI stack (as well as the block layer) is very well
> capable of reporting residual counts, and if the hardware can do it (we
> can't get it from some ide hardware :/), we will report residuals.
> 
> So if it doesn't work it's a bug, but not a design bug.

Well...more likely a driver bug.  Residuals have to be reported by the
driver.  I thought all of the drivers that could were now doing this,
but I might have missed some...which driver is it?

> > -	Unclear documentation whether DID_TIME_OUT should apply to a selection
> > 	time out, a SCSI command timeout or both.
> > 
> > 	Time to fix: one day
> > 
> > -	It seems that the only way to find out whether a SCSI command did time 
> > 	out is to meter the time it takes and guess for any unclear return
> > 	codes that coincidence with a command time >= the set up timeout to
> > 	assume a SCSI command timeout.
> > 
> > 	Time to fix: one day
> 
> Maybe James can clarify these?

I can try:

A selection timeout is reported as DID_NO_CONNECT.

DID_TIME_OUT is for cards that can watchdog their commands in hw and is
what they return when the watchdog fires.

If you actually want visibility into the SCSI mid layer timeout, that's
harder since it feeds directly into the error handler that tries to
ready the transport and device for action.  In general, a command that
times out this way is retried.  If you set the FASTFAIL flag, it will
come out with DRIVER_TIMEOUT set in its result area.

> > -	Many unclear problem reports lead me to the assumption that Linux-2.6
> > 	does not set up the SCSI command timeout properly. See previous point!
> 
> Issued through SG_IO, or how? Again, more details are required.

Yes, more details please.  I do a lot of limited testing on 2.6 but the
hardware manufacturers are doing much more.  The general consensus seems
to be that 2.6 is pretty solid at least for FC and SPI.

> > From the current number of problem reports, it looks like Linux-2.6 is
> > not yet ready for general use as too many problems only appear on
> > Linux-2.6. I currently give peeople the advise to either go back to
> > Linux-2.4 or to check Solaris (see
> > http://wwws.sun.com/software/solaris/solaris-express/get.html).

2.6 has just gone out to a wider audience via SLES9.  As is inevitable,
the test cases people have in the field are wider than those we
necessarily have the hw to produce, so it's expected that the arrival
rate for bugs will increase.

The only comparitive metric I have shows me that 2.4 was orders of
magnitude worse at this point (which was earlier: 2.4.2 from redhat).

James

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Arjan van de Ven]

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


> 2.6 has just gone out to a wider audience via SLES9.  As is inevitable,
> the test cases people have in the field are wider than those we
> necessarily have the hw to produce, so it's expected that the arrival
> rate for bugs will increase.
> 
> The only comparitive metric I have shows me that 2.4 was orders of
> magnitude worse at this point (which was earlier: 2.4.2 from redhat).

It's not quite fair to compare RHL to SLES; RHEL and SLES are
comparable, just like SuSE linux 9.1 and Fedora Core 2 are...


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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]


>From: Jens Axboe <axboe@suse.de>

>> Let me give you an advise: consolidate Linux so that is does only need
>> /dev/sg and fix the bugs in ide-scsi instead of constantly inventing new
>> unneeded interfaces.

>That's been the general direction for quite some time, just that SG_IO
>is the preferred method since that works all around. You were the one
>that merged support for the CDROM_SEND_PACKET interface, which has
>_never_ been advertised as a way to burn CDs in Linux. I'd suggest you
>remove that.

Again:

I'd be happy to start a discussion on this topic after the problem 
with kernel panic() or general unusability with ide-scsi for PC-card
or PCMCIA connected drives has been fixed for Linux-2.4 and all kernels
outside have been replaced by working ones...

I reported this problem to the end of y2000, this is long time ago.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Thu, Aug 05 2004, Joerg Schilling wrote:
> 
> >From: Jens Axboe <axboe@suse.de>
> 
> >> Let me give you an advise: consolidate Linux so that is does only need
> >> /dev/sg and fix the bugs in ide-scsi instead of constantly inventing new
> >> unneeded interfaces.
> 
> >That's been the general direction for quite some time, just that SG_IO
> >is the preferred method since that works all around. You were the one
> >that merged support for the CDROM_SEND_PACKET interface, which has
> >_never_ been advertised as a way to burn CDs in Linux. I'd suggest you
> >remove that.
> 
> Again:
> 
> I'd be happy to start a discussion on this topic after the problem 
> with kernel panic() or general unusability with ide-scsi for PC-card
> or PCMCIA connected drives has been fixed for Linux-2.4 and all kernels
> outside have been replaced by working ones...
> 
> I reported this problem to the end of y2000, this is long time ago.

Well resend it then? Maybe it's your attitude that prevents it from
being fixed, if you think we will chase back a 4 year old email to fix
some obscure bug.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]


>From axboe@suse.de  Thu Aug  5 14:05:22 2004

>> >Which, happily, is what already happens and why it works fine when you
>> >just do -dev=/dev/hdX. What should be removed is the warning that
>> >cdrecord spits out when you do this, and the whole ATAPI thing should
>> >just mirror ATA and scsi-linux-ata be killed completely.
>> 
>> Nice idea!
>> 
>> So please start with fixing ide-scsi for Linux-2.4 so Linux won't
>> panic() when trying to access CD/DVD-drives that are connected via a
>> PC-card interface using ide-scsi.

>Let me dig through my mail box and find that report. Hmm that's strange,
>you don't seem to have sent one. I'll just dig out the crystal ball and
>get cracking on that fix.

....I am not repsonsible for your mail box....

I send it to Alan Cox and to LKML.... a long toime ago (in 2000)

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Woodhouse]

On Thu, 2004-08-05 at 14:45 +0200, Joerg Schilling wrote:
> ....I am not repsonsible for your mail box....

Actually, you are partly responsible for the mess in my mail box. Please
fix your mail client to correctly insert References: and/or In-Reply-To:
headers such that your replies are not each starting a new thread of
their own.

-- 
dwmw2

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]


>From: Jens Axboe <axboe@suse.de>

>> this is the reason why the patch forces the ata (atapi?) driver. no
>> SCSI driver or configuring of ide-scsi required.

>Maybe newer version broke then. Until very recently, cdrecord worked
>just fine as-is and used SG_IO access method when you used open by
>device name. Which was just the way we wanted it.

>If that doesn't work now, I suggest you take it up with Joerg. It's a
>problem with his program.

It's a problem caused by the design in the Linux kernel and not a problem of
libscg or cdrecord. 

The point is that Linux constantly invents new ugly and unneeded things and
after I found a workaround, people try to prevent the workaround from
being usable. 

In 1998, I did send a patch against the sg.c driver that introduced
everything that is needed for Generic SCSI transport. I am still waiting 
for even the needed features to appear........

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Thu, Aug 05 2004, Joerg Schilling wrote:
> 
> >From: Jens Axboe <axboe@suse.de>
> 
> >> this is the reason why the patch forces the ata (atapi?) driver. no
> >> SCSI driver or configuring of ide-scsi required.
> 
> >Maybe newer version broke then. Until very recently, cdrecord worked
> >just fine as-is and used SG_IO access method when you used open by
> >device name. Which was just the way we wanted it.
> 
> >If that doesn't work now, I suggest you take it up with Joerg. It's a
> >problem with his program.
> 
> It's a problem caused by the design in the Linux kernel and not a problem of
> libscg or cdrecord. 
> 
> The point is that Linux constantly invents new ugly and unneeded things and
> after I found a workaround, people try to prevent the workaround from
> being usable. 

It's been bad in the past, I agree. But the advertised way to work with
this hasn't changed in the past few years, and was and is still sg v3.
So you should support that through read(2)/write(2) to /dev/sg*, or
through SG_IO ioctl to the device. The latter is recommended since
currently works for all devices, plus it's the simpler (and good enough)
interface to use for cdrecord since it doesn't require queuing.

> In 1998, I did send a patch against the sg.c driver that introduced
> everything that is needed for Generic SCSI transport. I am still
> waiting for even the needed features to appear........

If you have issues with SG_IO, please feel free to address them. If they
are valid, I'd love to help you get it fixed.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Thu, Aug 05 2004, Jens Axboe wrote:
> > The point is that Linux constantly invents new ugly and unneeded things and
> > after I found a workaround, people try to prevent the workaround from
> > being usable. 

BTW, what is that work-around?

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

>From: Jens Axboe <axboe@suse.de>

>ATA method is misnamed, it's really SG_IO that is used. And you want to
>use that regardless of the device type, SCSI or ATAPI. There's no such
>thing as an ATA burner, and there's no need to differentiate between
>SCSI or ATAPI CD-ROM's when burning - SG_IO is the method to use. So
>forget browsing /proc/ide and other hacks.

I am sorry but as Linux already has 6 different interfaces for sending 
Generic SCSI commands and thus, we are running out of names.

Let me give you an advise: consolidate Linux so that is does only need
/dev/sg and fix the bugs in ide-scsi instead of constantly inventing new
unneeded interfaces.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Thu, Aug 05 2004, Joerg Schilling wrote:
> >From: Jens Axboe <axboe@suse.de>
> 
> >ATA method is misnamed, it's really SG_IO that is used. And you want to
> >use that regardless of the device type, SCSI or ATAPI. There's no such
> >thing as an ATA burner, and there's no need to differentiate between
> >SCSI or ATAPI CD-ROM's when burning - SG_IO is the method to use. So
> >forget browsing /proc/ide and other hacks.
> 
> I am sorry but as Linux already has 6 different interfaces for sending 
> Generic SCSI commands and thus, we are running out of names.
> 
> Let me give you an advise: consolidate Linux so that is does only need
> /dev/sg and fix the bugs in ide-scsi instead of constantly inventing new
> unneeded interfaces.

That's been the general direction for quite some time, just that SG_IO
is the preferred method since that works all around. You were the one
that merged support for the CDROM_SEND_PACKET interface, which has
_never_ been advertised as a way to burn CDs in Linux. I'd suggest you
remove that.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Wakko Warner]

Please do keep me CCd

> >ATA method is misnamed, it's really SG_IO that is used. And you want to
> >use that regardless of the device type, SCSI or ATAPI. There's no such
> >thing as an ATA burner, and there's no need to differentiate between
> >SCSI or ATAPI CD-ROM's when burning - SG_IO is the method to use. So
> >forget browsing /proc/ide and other hacks.
> 
> I am sorry but as Linux already has 6 different interfaces for sending 
> Generic SCSI commands and thus, we are running out of names.
> 
> Let me give you an advise: consolidate Linux so that is does only need
> /dev/sg and fix the bugs in ide-scsi instead of constantly inventing new
> unneeded interfaces.

I'd like to take this and stretch it some.

First, I don't know what would be involved in doing this or if it's even
doable (but I'd think it is).  I would like to see this happen, however, I
understand that it may or may not.

Why do we have a seperate subsystem for scsi and ide, but not usb storage
devices?  What I mean is that usb-storage is a scsi adapter that attaches
usb disks to the scsi layer.  I know about ide-scsi, but that's like a
bridge that probably could be removed entirely.

Now here's what I'm thinking:

1) remove the IDE subsystem entirely (keeping the IDE drivers).  This will
eliminate the need for /dev/hd* devices and ide-scsi.

2) rename the scsi subsystem to something more generic, like disk subsystem
(I realize that scsi can handle more than disks, like tapes, scanners, I
even once saw a scsi ethernet adapter)

3) port all of the IDE drivers to be like a scsi adapter driver (ie fix piix
to function similar to say aic7xxx).  To handle the fact of multiple
interfaces on the controller (primary/secondary connectors on the board, 4
devices total) to be seperate scsi buses.  On each bus, you'll only have 2
IDs, 0 and 1 (corresponding to master and slave).

4) All access to the device will be like a scsi device.  For IDE devices, if
needed, the driver (ie piix) can translate the request.

Ideas?  Thoughts?  Flames to /dev/null.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Måns Rullgård]

Wakko Warner <wakko@animx.eu.org> writes:

> Please do keep me CCd
>
>> >ATA method is misnamed, it's really SG_IO that is used. And you want to
>> >use that regardless of the device type, SCSI or ATAPI. There's no such
>> >thing as an ATA burner, and there's no need to differentiate between
>> >SCSI or ATAPI CD-ROM's when burning - SG_IO is the method to use. So
>> >forget browsing /proc/ide and other hacks.
>> 
>> I am sorry but as Linux already has 6 different interfaces for sending 
>> Generic SCSI commands and thus, we are running out of names.
>> 
>> Let me give you an advise: consolidate Linux so that is does only need
>> /dev/sg and fix the bugs in ide-scsi instead of constantly inventing new
>> unneeded interfaces.
>
> I'd like to take this and stretch it some.
>
> First, I don't know what would be involved in doing this or if it's even
> doable (but I'd think it is).  I would like to see this happen, however, I
> understand that it may or may not.
>
> Why do we have a seperate subsystem for scsi and ide, but not usb storage
> devices?  What I mean is that usb-storage is a scsi adapter that attaches
> usb disks to the scsi layer.  I know about ide-scsi, but that's like a
> bridge that probably could be removed entirely.
>
> Now here's what I'm thinking:
>
> 1) remove the IDE subsystem entirely (keeping the IDE drivers).  This will
> eliminate the need for /dev/hd* devices and ide-scsi.
>
> 2) rename the scsi subsystem to something more generic, like disk subsystem
> (I realize that scsi can handle more than disks, like tapes, scanners, I
> even once saw a scsi ethernet adapter)
>
> 3) port all of the IDE drivers to be like a scsi adapter driver (ie fix piix
> to function similar to say aic7xxx).  To handle the fact of multiple
> interfaces on the controller (primary/secondary connectors on the board, 4
> devices total) to be seperate scsi buses.  On each bus, you'll only have 2
> IDs, 0 and 1 (corresponding to master and slave).
>
> 4) All access to the device will be like a scsi device.  For IDE devices, if
> needed, the driver (ie piix) can translate the request.

Isn't this what libata does with SATA disks?  SATA is already standard
in new machines, and within a couple of years parallel ATA is like to
be mostly obsolete.

-- 
Måns Rullgård
mru@kth.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

>From: "H.Rosmanith (Kernel Mailing List)" <kernel@wildsau.enemy.org>


>well, sigh .... been there, done that, but emails to Joerg seem to have
>a long RTT. therefore, LKML. sorry for the inconvenience :->

One day is long ?????

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

>From axboe@suse.de  Wed Aug  4 14:58:33 2004

>> That's an extremely bad idea, you want to force ATA driver in either
>> case.

>Which, happily, is what already happens and why it works fine when you
>just do -dev=/dev/hdX. What should be removed is the warning that
>cdrecord spits out when you do this, and the whole ATAPI thing should
>just mirror ATA and scsi-linux-ata be killed completely.

Nice idea!

So please start with fixing ide-scsi for Linux-2.4 so Linux won't panic()
when trying to access CD/DVD-drives that are connected via a PC-card interface
using ide-scsi.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Thu, Aug 05 2004, Joerg Schilling wrote:
> >From axboe@suse.de  Wed Aug  4 14:58:33 2004
> 
> >> That's an extremely bad idea, you want to force ATA driver in either
> >> case.
> 
> >Which, happily, is what already happens and why it works fine when you
> >just do -dev=/dev/hdX. What should be removed is the warning that
> >cdrecord spits out when you do this, and the whole ATAPI thing should
> >just mirror ATA and scsi-linux-ata be killed completely.
> 
> Nice idea!
> 
> So please start with fixing ide-scsi for Linux-2.4 so Linux won't
> panic() when trying to access CD/DVD-drives that are connected via a
> PC-card interface using ide-scsi.

Let me dig through my mail box and find that report. Hmm that's strange,
you don't seem to have sent one. I'll just dig out the crystal ball and
get cracking on that fix.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]


>From: "H.Rosmanith (Kernel Mailing List)" <kernel@wildsau.enemy.org>

>I've written a patch for cdrecord/cdrtools. I've sent it to Joerg Schilling
>already, but got no answer so far. Probably he's on vaccation.

Looks like I first need to correct you :-(

You send a mail on July 5th and received a reply on July 6th, wo where is
your problem?


>I'm sending this to LKML too, because I've read about some ... nebulosity
>with respect to scsi device numbering as used by cdrtools.

This is caused by the "mist" throughn out by parts of the Linux kernel :-(


>To cut a long story short: the patch avoids cdrecord having to use the
>"virtual" scsi device numbering in the form of "ATAPI:x.y.z" and allows
>you to use the name of the device, e.g. /dev/hdc instead.

I am sorry, but using something like dev=/dev/hdc is deprecated.
In addition, several programs distinct between so called Cooked ioctl()s and
generic SCSI by checking for UNIX device names vs. SCSI address specs.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

PATCH: cdrecord: avoiding scsi device numbering for ide devices

[H.Rosmanith (Kernel Mailing List)]

hi,

I've written a patch for cdrecord/cdrtools. I've sent it to Joerg Schilling
already, but got no answer so far. Probably he's on vaccation.

I'm sending this to LKML too, because I've read about some ... nebulosity
with respect to scsi device numbering as used by cdrtools.

To cut a long story short: the patch avoids cdrecord having to use the
"virtual" scsi device numbering in the form of "ATAPI:x.y.z" and allows
you to use the name of the device, e.g. /dev/hdc instead.

By removing the IDE to virtual scsi bus/host/lun mapping, a lot of confusion
can be avoided especially if you have a lot devices of this kind in one
system.

with kind regards,
Herbert "herp" Rosmanith

Version: cdrtools-2.01a34

Solution: when the device specified in dev= starts with "/dev/hd" and
          this device can be found in /proc/ide, then cdrecord (and all
          it's components, such as e.g. cdrdao) is forced to use the
          ATAPI driver.

The patch is really very short and works at least on our system.

with kind regards,
Herbert Rosmanith

--- snip ---
diff -ru cdrtools-2.01.orig/libscg/scsi-linux-ata.c cdrtools-2.01/libscg/scsi-linux-ata.c
--- cdrtools-2.01.orig/libscg/scsi-linux-ata.c	Sat Jun 12 12:48:12 2004
+++ cdrtools-2.01/libscg/scsi-linux-ata.c	Wed Aug  4 14:19:31 2004
@@ -42,6 +42,11 @@
  * You should have received a copy of the GNU General Public License along with
  * this program; see the file COPYING.  If not, write to the Free Software
  * Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Sat Jun 12 12:48:12 CEST 2004 herp - Herbert Rosmanith
+ *     Force ATAPI driver if dev= starts with /dev/hd and device
+ *     is present in /proc/ide/hdX
+ *
  */
 
 #ifdef	USE_ATA
@@ -60,7 +65,7 @@
 LOCAL	int	scgo_areset	__PR((SCSI *scgp, int what));
 LOCAL	int	scgo_asend	__PR((SCSI *scgp));
 
-LOCAL scg_ops_t ata_ops = {
+EXPORT scg_ops_t scg_ata_ops = {
 	scgo_asend,
 	scgo_aversion,
 	scgo_ahelp,
diff -ru cdrtools-2.01.orig/libscg/scsi-linux-sg.c cdrtools-2.01/libscg/scsi-linux-sg.c
--- cdrtools-2.01.orig/libscg/scsi-linux-sg.c	Thu May 20 15:42:12 2004
+++ cdrtools-2.01/libscg/scsi-linux-sg.c	Wed Aug  4 14:20:56 2004
@@ -40,6 +40,11 @@
  *	string is related to a modified source.
  *
  *	Copyright (c) 1997 J. Schilling
+ *
+ * Sat Jun 12 12:48:12 CEST 2004 herp - Herbert Rosmanith
+ *     Force ATAPI driver if dev= starts with /dev/hd and device
+ *     is present in /proc/ide/hdX
+ *
  */
 /*
  * This program is free software; you can redistribute it and/or modify
@@ -315,7 +320,7 @@
 	if (device != NULL && *device != '\0') {
 #ifdef	USE_ATA
 		if (strncmp(device, "ATAPI", 5) == 0) {
-			scgp->ops = &ata_ops;
+			scgp->ops = &scg_ata_ops;
 			return (SCGO_OPEN(scgp, device));
 		}
 #endif
diff -ru cdrtools-2.01.orig/libscg/scsitransp.c cdrtools-2.01/libscg/scsitransp.c
--- cdrtools-2.01.orig/libscg/scsitransp.c	Thu Jun 17 22:20:27 2004
+++ cdrtools-2.01/libscg/scsitransp.c	Wed Aug  4 14:26:07 2004
@@ -13,6 +13,11 @@
  *	string is related to a modified source.
  *
  *	Copyright (c) 1988,1995,2000-2004 J. Schilling
+ *
+ * Sat Jun 12 12:48:12 CEST 2004 herp - Herbert Rosmanith
+ *     Force ATAPI driver if dev= starts with /dev/hd and device
+ *     is present in /proc/ide/hdX
+ *
  */
 /*
  * This program is free software; you can redistribute it and/or modify
@@ -34,6 +39,7 @@
 #include <stdio.h>
 #include <standard.h>
 #include <stdxlib.h>
+#include <sys/stat.h>
 #include <unixstd.h>
 #include <errno.h>
 #include <timedefs.h>
@@ -157,7 +163,7 @@
 {
 	int	ret;
 	scg_ops_t *ops;
-extern	scg_ops_t scg_std_ops;
+extern	scg_ops_t scg_std_ops,scg_ata_ops;
 
 	/*
 	 * Begin restricted code for quality assurance.
@@ -185,6 +191,16 @@
 			scgp->ops = ops;
 	}
 
+	// XXX herp - check if atapi driver neccessary
+	//            and load if ide device found
+
+	if (device && strncmp(device,"/dev/hd",7)==0) {
+	char pdev[]="/proc/ide/XXXX";
+	struct stat st;
+		strncpy(pdev+10,device+5,4);    /* hdXY should be enough, eh? */
+		if (stat(pdev,&st)==0)
+			scgp->ops=&scg_ata_ops;
+	}
 	ret = SCGO_OPEN(scgp, device);
 	if (ret < 0)
 		return (ret);
--- snip ---

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Wed, Aug 04 2004, H.Rosmanith (Kernel Mailing List) wrote:
> 
> hi,
> 
> I've written a patch for cdrecord/cdrtools. I've sent it to Joerg Schilling
> already, but got no answer so far. Probably he's on vaccation.
> 
> I'm sending this to LKML too, because I've read about some ... nebulosity
> with respect to scsi device numbering as used by cdrtools.
> 
> To cut a long story short: the patch avoids cdrecord having to use the
> "virtual" scsi device numbering in the form of "ATAPI:x.y.z" and allows
> you to use the name of the device, e.g. /dev/hdc instead.
> 
> By removing the IDE to virtual scsi bus/host/lun mapping, a lot of confusion
> can be avoided especially if you have a lot devices of this kind in one
> system.
> 
> with kind regards,
> Herbert "herp" Rosmanith
> 
> Version: cdrtools-2.01a34
> 
> Solution: when the device specified in dev= starts with "/dev/hd" and
>           this device can be found in /proc/ide, then cdrecord (and all
>           it's components, such as e.g. cdrdao) is forced to use the
>           ATAPI driver.
> 
> The patch is really very short and works at least on our system.
> 
> with kind regards,
> Herbert Rosmanith
> 
> --- snip ---
> diff -ru cdrtools-2.01.orig/libscg/scsi-linux-ata.c cdrtools-2.01/libscg/scsi-linux-ata.c
> --- cdrtools-2.01.orig/libscg/scsi-linux-ata.c	Sat Jun 12 12:48:12 2004
> +++ cdrtools-2.01/libscg/scsi-linux-ata.c	Wed Aug  4 14:19:31 2004
> @@ -42,6 +42,11 @@
>   * You should have received a copy of the GNU General Public License along with
>   * this program; see the file COPYING.  If not, write to the Free Software
>   * Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + *
> + * Sat Jun 12 12:48:12 CEST 2004 herp - Herbert Rosmanith
> + *     Force ATAPI driver if dev= starts with /dev/hd and device
> + *     is present in /proc/ide/hdX
> + *

That's an extremely bad idea, you want to force ATA driver in either
case.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Wed, Aug 04 2004, Jens Axboe wrote:
> > + * Sat Jun 12 12:48:12 CEST 2004 herp - Herbert Rosmanith
> > + *     Force ATAPI driver if dev= starts with /dev/hd and device
> > + *     is present in /proc/ide/hdX
> > + *
> 
> That's an extremely bad idea, you want to force ATA driver in either
> case.

Which, happily, is what already happens and why it works fine when you
just do -dev=/dev/hdX. What should be removed is the warning that
cdrecord spits out when you do this, and the whole ATAPI thing should
just mirror ATA and scsi-linux-ata be killed completely.

So I suggest you do that instead and send it to Joerg, cdrecord/cdrtool
patches are off topic here.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[H.Rosmanith (Kernel Mailing List)]

> On Wed, Aug 04 2004, Jens Axboe wrote:
> > > + * Sat Jun 12 12:48:12 CEST 2004 herp - Herbert Rosmanith
> > > + *     Force ATAPI driver if dev= starts with /dev/hd and device
> > > + *     is present in /proc/ide/hdX
> > > + *
> > 
> > That's an extremely bad idea, you want to force ATA driver in either
> > case.
> 
> Which, happily, is what already happens and why it works fine when you

okay - my last email in this matter to LKML, but: it seems to only work
fine if you use ide-scsi and configure it acordingly. on our system, where
I have disabled scsi completely (ide-scsi doesnt work at all for certain
tasks, and beside from that, I need scsi), cdrecord/cdrtools will terminate with
"Cannot open /dev/hdX. Cannot open SCSI driver".

this is the reason why the patch forces the ata (atapi?) driver. no
SCSI driver or configuring of ide-scsi required.

> just do -dev=/dev/hdX. What should be removed is the warning that
> cdrecord spits out when you do this, and the whole ATAPI thing should
> just mirror ATA and scsi-linux-ata be killed completely.
> 
> So I suggest you do that instead and send it to Joerg, cdrecord/cdrtool

well, sigh .... been there, done that, but emails to Joerg seem to have
a long RTT. therefore, LKML. sorry for the inconvenience :->

bye,
herp

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Thu, Aug 05 2004, H.Rosmanith (Kernel Mailing List) wrote:
> > On Wed, Aug 04 2004, Jens Axboe wrote:
> > > > + * Sat Jun 12 12:48:12 CEST 2004 herp - Herbert Rosmanith
> > > > + *     Force ATAPI driver if dev= starts with /dev/hd and device
> > > > + *     is present in /proc/ide/hdX
> > > > + *
> > > 
> > > That's an extremely bad idea, you want to force ATA driver in either
> > > case.
> > 
> > Which, happily, is what already happens and why it works fine when you
> 
> okay - my last email in this matter to LKML, but: it seems to only work
> fine if you use ide-scsi and configure it acordingly. on our system, where
> I have disabled scsi completely (ide-scsi doesnt work at all for certain
> tasks, and beside from that, I need scsi), cdrecord/cdrtools will
> terminate with "Cannot open /dev/hdX. Cannot open SCSI driver".
> 
> this is the reason why the patch forces the ata (atapi?) driver. no
> SCSI driver or configuring of ide-scsi required.

Maybe newer version broke then. Until very recently, cdrecord worked
just fine as-is and used SG_IO access method when you used open by
device name. Which was just the way we wanted it.

If that doesn't work now, I suggest you take it up with Joerg. It's a
problem with his program.

> > just do -dev=/dev/hdX. What should be removed is the warning that
> > cdrecord spits out when you do this, and the whole ATAPI thing
> > should just mirror ATA and scsi-linux-ata be killed completely.
> > 
> > So I suggest you do that instead and send it to Joerg,
> > cdrecord/cdrtool
> 
> well, sigh .... been there, done that, but emails to Joerg seem to
> have a long RTT. therefore, LKML. sorry for the inconvenience :->

Is there no cdrecord list? lkml surely isn't appropriate.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[H.Rosmanith (Kernel Mailing List)]

> > + * Sat Jun 12 12:48:12 CEST 2004 herp - Herbert Rosmanith
> > + *     Force ATAPI driver if dev= starts with /dev/hd and device
> > + *     is present in /proc/ide/hdX
> > + *
> 
> That's an extremely bad idea, you want to force ATA driver in either
> case.

I don't think so.

If "dev=/dev/hd?" and "/dev/hd?" is *not* present in /proc/ide, then
cdrtools falls back to the default behaviour, which is: treat it as
scsi device.

If the device cannot be found in /proc/ide, it simply does not make sense
to treat it as atapi device - because it is none.

best regards,
Herbert Rosmanith

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Thu, Aug 05 2004, H.Rosmanith (Kernel Mailing List) wrote:
> > > + * Sat Jun 12 12:48:12 CEST 2004 herp - Herbert Rosmanith
> > > + *     Force ATAPI driver if dev= starts with /dev/hd and device
> > > + *     is present in /proc/ide/hdX
> > > + *
> > 
> > That's an extremely bad idea, you want to force ATA driver in either
> > case.
> 
> I don't think so.
> 
> If "dev=/dev/hd?" and "/dev/hd?" is *not* present in /proc/ide, then
> cdrtools falls back to the default behaviour, which is: treat it as
> scsi device.
> 
> If the device cannot be found in /proc/ide, it simply does not make sense
> to treat it as atapi device - because it is none.

ATA method is misnamed, it's really SG_IO that is used. And you want to
use that regardless of the device type, SCSI or ATAPI. There's no such
thing as an ATA burner, and there's no need to differentiate between
SCSI or ATAPI CD-ROM's when burning - SG_IO is the method to use. So
forget browsing /proc/ide and other hacks.

-- 
Jens Axboe

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Wed, 4 Aug 2004 14:33:09 +0200 (MET DST), H.Rosmanith (Kernel
Mailing List) <kernel@wildsau.enemy.org> wrote:
> Some stuff that started a flamewar.

If no one has noticed yet, thanks to the additional license
restrictions Joerg Schilling has added to cdrecord (due to this
thread), it may be now moved to non-free in Debian in the near future.

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Wakko Warner]

> If no one has noticed yet, thanks to the additional license
> restrictions Joerg Schilling has added to cdrecord (due to this
> thread), it may be now moved to non-free in Debian in the near future.

Humph.  Maybe this would cause someone else to start a package that actually
works well with device NAMES instead of numbers.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Lee Revell]

On Thu, 2004-08-19 at 03:04, Patrick McFarland wrote:
> On Wed, 4 Aug 2004 14:33:09 +0200 (MET DST), H.Rosmanith (Kernel
> Mailing List) <kernel@wildsau.enemy.org> wrote:
> > Some stuff that started a flamewar.
> 
> If no one has noticed yet, thanks to the additional license
> restrictions Joerg Schilling has added to cdrecord (due to this
> thread), it may be now moved to non-free in Debian in the near future.

What restrictions?  Do you have a link?

Lee

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Marc Ballarin]

On Thu, 19 Aug 2004 07:32:40 -0400
Lee Revell <rlrevell@joe-job.com> wrote:

> 
> What restrictions?  Do you have a link?
> 

Probably line 380 and onwards of cdrecord.c in cdrtools cdrtools-2.01a37.

Regards

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Diego Calleja]

El Thu, 19 Aug 2004 07:32:40 -0400 Lee Revell <rlrevell@joe-job.com> escribió:

> On Thu, 2004-08-19 at 03:04, Patrick McFarland wrote:
> > If no one has noticed yet, thanks to the additional license
> > restrictions Joerg Schilling has added to cdrecord (due to this
> > thread), it may be now moved to non-free in Debian in the near future.
> 
> What restrictions?  Do you have a link?

See http://weblogs.mozillazine.org/gerv/archives/006193.html (which may not
be the best interpretation of the changes)

Basically it was added a "linuxcheck" function which you're not allowed to
modify or delete. The function has a "warning", which results in something
like:
cdrecord: Warning: Running on Linux-2.6.8
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.

(Dunno what it prints out when you're running suse but I don't think linux
vendors are going to distribute software which says that their own software
has issues.)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

>From diegocg@teleline.es  Thu Aug 19 14:07:10 2004

>El Thu, 19 Aug 2004 07:32:40 -0400 Lee Revell <rlrevell@joe-job.com> escribió:

>> On Thu, 2004-08-19 at 03:04, Patrick McFarland wrote:
>> > If no one has noticed yet, thanks to the additional license
>> > restrictions Joerg Schilling has added to cdrecord (due to this
>> > thread), it may be now moved to non-free in Debian in the near future.
>> 
>> What restrictions?  Do you have a link?

>See http://weblogs.mozillazine.org/gerv/archives/006193.html (which may not
>be the best interpretation of the changes)

Unfortunately the person who did write this has no clue on the Copyright law :-(

The Copyright law is _very_ explicit about the fact that Authors that do minor
contributions have no right to influence the license or the way of publishing.

It is obvious that SuSE versions of cdrecord impact the original authors' 
reputations which is prohibited by the GPL.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Stephan von Krawczynski]

On Thu, 19 Aug 2004 15:04:50 +0200
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> It is obvious that SuSE versions of cdrecord impact the original authors' 
> reputations which is prohibited by the GPL.

Well, just about the only thing that has impact on your reputation is yourself
and the way you are dealing with _own_ deficiencies. Your reputation (if ever)
has not been built by SuSE, and it is not destroyed by SuSE.

As long as you deny that there is always someone with more knowledge on the net
that is capable of unveilling your faults you will always enter troubles here.
It's all about learning and only very seldom about being god.

-- 
Regards,
Stephan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Stephan von Krawczynski <skraw@ithnet.com> wrote:

> As long as you deny that there is always someone with more knowledge on the net

I don't do that, but unfortunately people with more knowlede seem to be rare on 
LKML :-(

If people on LKML would admit that other people may have more knowledge than 
they, discussions on LKML could be much easier.......

And if you look at the mails from Sunday, you even see what's happening when 
typical LKML trolls stop posting.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Adrian Bunk]

On Thu, Aug 19, 2004 at 03:04:50PM +0200, Joerg Schilling wrote:
> >From diegocg@teleline.es  Thu Aug 19 14:07:10 2004
> 
> >See http://weblogs.mozillazine.org/gerv/archives/006193.html (which may not
> >be the best interpretation of the changes)
> 
> Unfortunately the person who did write this has no clue on the Copyright law :-(
> 
> The Copyright law is _very_ explicit about the fact that Authors that do minor
> contributions have no right to influence the license or the way of publishing.
>...

"The Copyright law" is a strange term.

E.g. the German and the US copyright laws aren't exactly the same.

> Jörg

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

>From: Patrick McFarland <diablod3@gmail.com>

>On Wed, 4 Aug 2004 14:33:09 +0200 (MET DST), H.Rosmanith (Kernel
>Mailing List) <kernel@wildsau.enemy.org> wrote:
>> Some stuff that started a flamewar.

>If no one has noticed yet, thanks to the additional license
>restrictions Joerg Schilling has added to cdrecord (due to this
>thread), it may be now moved to non-free in Debian in the near future.

It makes no sense to comment things if you don't know what's going on.
So please avoid comments like this in the future.

Your statement "it may be now moved to non-free in Debian in the near future"
is just complete nonsense. Of course, I am in discussions with Debian people 
about the best method to force SuSE not to publish broken versions of cdrtools 
in the future.

Let me comment what SuSE is currently doing with cdrtools:

A program is an artwork (this is what the European Union did write into laws).

Even though you may get the permission to modify an artwork, you will not get 
the permission to create bad carricatures and call them just "modified 
versions".

The GPL requires you not to impact the original authors' reputations, but this 
is what SuSE is doing by publishing defective variants.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Iau, 2004-08-19 at 13:42, Joerg Schilling wrote:
> A program is an artwork (this is what the European Union did write into laws).

It's a "literary work". Not sure if the Germans call it something
different ansd "artwork" is a translation. Artwork means something
different in English (painting, picture, drawing).

> Even though you may get the permission to modify an artwork, you will not get 
> the permission to create bad carricatures and call them just "modified 
> versions".

The GPL gives modification rights explicitly and doesn't say "except
ones I don't like". The GPL addresses this issue in a different manner

   a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.

Any SuSE (or Red Hat or other) modifications should thus clearly state
they are modified. If people are not marking the files as modified and
you want them to you'd have a legitimate rant.

Secondly I think you would find it hard to argue that the SuSE one is a
bad caricature given existing user interface knowledge, or that it
harmed your reputation given your behaviour in the past.

Fortunately free software has a mechanism for bypassing problems as
XFree86 4.4 demonstrated so elegantly.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Alan Cox wrote:

> Any SuSE (or Red Hat or other) modifications should thus clearly state
> they are modified. If people are not marking the files as modified and
> you want them to you'd have a legitimate rant.

Here's what I see when I call cdrecord on SuSE 9.1:

Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 Jörg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to http://www.suse.de/feedback
Note: The author of cdrecord should not be bothered with problems in this version.

This states very clear that the original authour should not be bothered.
So I don't see any problem.

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Thu, 19 Aug 2004 16:34:13 +0200, Frank Steiner
<fsteiner-mail@bio.ifi.lmu.de> wrote:
> Here's what I see when I call cdrecord on SuSE 9.1:
> 
> Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 Jörg Schilling
> Note: This version is an unofficial (modified) version with DVD support
> Note: and therefore may have bugs that are not present in the original.
> Note: Please send bug reports or support requests to http://www.suse.de/feedback
> Note: The author of cdrecord should not be bothered with problems in this version.

And debian does:

Cdrecord-Clone 2.01a34 (i686-pc-linux-gnu) Copyright (C) 1995-2004
Jorg Schilling
Note: This version of cdrecord is an inofficial (modified) release of cdrecord
and thus may have bugs that are not present in the original version.
Please send bug reports and support requests to <cdrtools@packages.debian.org>.
The original author should not be bothered with problems of this version




-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Patrick McFarland <diablod3@gmail.com> wrote:

> On Thu, 19 Aug 2004 16:34:13 +0200, Frank Steiner
> <fsteiner-mail@bio.ifi.lmu.de> wrote:
> > Here's what I see when I call cdrecord on SuSE 9.1:
> > 
> > Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 Jörg Schilling
> > Note: This version is an unofficial (modified) version with DVD support
> > Note: and therefore may have bugs that are not present in the original.
> > Note: Please send bug reports or support requests to http://www.suse.de/feedback
> > Note: The author of cdrecord should not be bothered with problems in this version.
>
> And debian does:

bla bla bla.... you nicely ignored:

Message-ID: <4124C46B.nail83H31GJ2S@burner> 


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

> bla bla bla.... you nicely ignored:
> 
> Message-ID: <4124C46B.nail83H31GJ2S@burner> 

And what is he ignoring?

In that message you complained about a SuSE modified version, but as
far as I can tell you did not bring up any other arguments, except to
point at bug in the SuSE version.  A version that very clearly stated
that it is a modified version and that you should not be contacted
about bugs in that version.

So what are you complaining about?  The GPL says:

    If the software is modified by someone else and passed on, we want
    its recipients to know that what they have is not the original, so
    that any problems introduced by others will not reflect on the
    original authors' reputations.

So I belive that you are complaining about something where you have
not reason to complain, since SuSE are definitely telling the users
that they are using a modified version.

And this really does not belong on linux-kernel so can we please stop
this silly argument.  Keep technical issues on linux kernel and for
the rest, please go away.  (And yes, by posting this message I'm just
as guilty of bringing off topic stuff to l-k.  I'm sorry about that).

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> The GPL gives modification rights explicitly and doesn't say "except
> ones I don't like". The GPL addresses this issue in a different manner
> 
>    a) You must cause the modified files to carry prominent notices
>     stating that you changed the files and the date of any change.
> 
> Any SuSE (or Red Hat or other) modifications should thus clearly state
> they are modified. If people are not marking the files as modified and
> you want them to you'd have a legitimate rant.

As far as I can tell SuSE has had the following text in the cdrecord
banner for a while:

Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 Jörg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to http://www.suse.de/feedback
Note: The author of cdrecord should not be bothered with problems in this version.

So I wonder what Jörg is complaining about.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> It makes no sense to comment things if you don't know what's going on.
> So please avoid comments like this in the future.
> 
> Your statement "it may be now moved to non-free in Debian in the near future"
> is just complete nonsense. Of course, I am in discussions with Debian people 
> about the best method to force SuSE not to publish broken versions of cdrtools 
> in the future.

Hmmm, it seems that the matter is so complicated that even you don't know what's
going on ;-)  The latest issue of Debian Weekly News explicitly mentions that
cdrecord has to go to non-free unless the license additions get changed.

> Let me comment what SuSE is currently doing with cdrtools:

You accuse Linux distributors of being non-cooperative, but I think that the
major cause of not cooperating is that just everybody in the Linux world does
not share your set of dogmata, the recent discussion about addressing devices
being a prime example. Although I very much appreciate your experience with
CD recording, I feel that the ways of referring to devices should be best
left to Linux developers.

(BTW: I am not sure I haven't missed anything in the long cdrecord-related
threads on the LKML, but I still haven't seen what is exactly so broken on the
cdrecord shipped by SUSE.)

				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
System going down at 5 pm to install scheduler bug.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

>From: Martin Mares <mj@ucw.cz>

>> Your statement "it may be now moved to non-free in Debian in the near future"
>> is just complete nonsense. Of course, I am in discussions with Debian people 
>> about the best method to force SuSE not to publish broken versions of cdrtools 
>> in the future.

>Hmmm, it seems that the matter is so complicated that even you don't know what's
>going on ;-)  The latest issue of Debian Weekly News explicitly mentions that
>cdrecord has to go to non-free unless the license additions get changed.

Maybe your problem is that you are not involved with the discussion?
>From the last discussions, I can tell that Debian has no problems with what's 
going to become cdrtools-2.01-final.

I am one of the persons that publish the most Free Software per person.
I am "living" the OSS/FS rules but it seems that some companies still have to 
do their homework to understand what Free Software means. 

My intension is _not_ to make my software non-free but to tell people who 
believe that they may do with other people's software what they like that there 
are limits. If these people/companies would be cooperative, this problem was non
existent. As it sometimes is hard to find the right algorith to do the job
right, it is the the same for contracts. You may need several iterations to find
the best solution. 

>> Let me comment what SuSE is currently doing with cdrtools:

>You accuse Linux distributors of being non-cooperative, but I think that the

I explain why e.g. SuSE is non-cooperative. This is different from what you 
write.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> >Hmmm, it seems that the matter is so complicated that even you don't know what's
> >going on ;-)  The latest issue of Debian Weekly News explicitly mentions that
> >cdrecord has to go to non-free unless the license additions get changed.
> 
> Maybe your problem is that you are not involved with the discussion?
> From the last discussions, I can tell that Debian has no problems with what's 
> going to become cdrtools-2.01-final.

Yes, from the last discussions. But you cannot deny that Debian initially
considered moving cdrecord to non-free, which was the point of the post you
replied to.

> I explain why e.g. SuSE is non-cooperative. This is different from what you 
> write.

You explain that SuSE is non-cooperative, because they distribute crippled
cdrecord, but you fail to explain what crippledness do you have in mind.

Also, if you put away your flamethrower and just politely asked SUSE to add
a message like `this version has been modified by SUSE, so please send your
bug reports to support@suse.com instead of the original author', the whole
issue would be probably already settled a long time ago.

				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
Don't forget to save the Earth! We don't have any backups!

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

>From: Martin Mares <mj@ucw.cz>

>You explain that SuSE is non-cooperative, because they distribute crippled
>cdrecord, but you fail to explain what crippledness do you have in mind.

>Also, if you put away your flamethrower and just politely asked SUSE to add
>a message like `this version has been modified by SUSE, so please send your
>bug reports to support@suse.com instead of the original author', the whole
>issue would be probably already settled a long time ago.

I did talk to the official SuSE product manager 1.5 years ago and this person
just tried to take me as a clod.

Do you really believe that I am doing all this before trying to find a decent 
discussion based solution? 

SuSE did _proove_ being unwilling or unable to for a discussion :-(

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> I did talk to the official SuSE product manager 1.5 years ago and this person
> just tried to take me as a clod.
> 
> Do you really believe that I am doing all this before trying to find a decent 
> discussion based solution? 

That's really hard to believe, but on the other hand, when packaging my programs,
SUSE people were always cooperating very well.

So, let's ask the SUSE'rs around there: is there any problem with adding such
a notice to the cdrecord package?

But this problem (which I believe will be solved soon) aside, what is exactly
crippled on the version SUSE ships?

				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
Press any key to quit or any other key to continue

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Martin Mares wrote:
> Hello!
> 
> 
>>I did talk to the official SuSE product manager 1.5 years ago and this person
>>just tried to take me as a clod.
>>
>>Do you really believe that I am doing all this before trying to find a decent 
>>discussion based solution? 
> 
> 
> That's really hard to believe, but on the other hand, when packaging my programs,
> SUSE people were always cooperating very well.
> 
> So, let's ask the SUSE'rs around there: is there any problem with adding such
> a notice to the cdrecord package?

There is already. cdrecord on SuSE 9.1 tells you:
Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 Jörg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to http://www.suse.de/feedback
Note: The author of cdrecord should not be bothered with problems in this version.


-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> There is already. cdrecord on SuSE 9.1 tells you:
> Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 J??rg Schilling
> Note: This version is an unofficial (modified) version with DVD support
> Note: and therefore may have bugs that are not present in the original.
> Note: Please send bug reports or support requests to http://www.suse.de/feedback
> Note: The author of cdrecord should not be bothered with problems in this version.

So, case closed, it seems. Any other arguments, Joerg?

				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
Man is the highest animal. Man does the classifying.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

>From: Martin Mares <mj@ucw.cz>

>> There is already. cdrecord on SuSE 9.1 tells you:
>> Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 J??rg Schilling
>> Note: This version is an unofficial (modified) version with DVD support
>> Note: and therefore may have bugs that are not present in the original.
>> Note: Please send bug reports or support requests to http://www.suse.de/feedback
>> Note: The author of cdrecord should not be bothered with problems in this version.

>So, case closed, it seems. Any other arguments, Joerg?

No, of course not. But it makes no sense to discuss things again that just have 
been discussed in full detail on other mailing lists.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> >So, case closed, it seems. Any other arguments, Joerg?
> 
> No, of course not. But it makes no sense to discuss things again that just have 
> been discussed in full detail on other mailing lists.

You are ranting about SUSE (and the incompetentness of other Linux people)
on _this_ mailing list, so bring the facts _here_ (or at least the pointers
to them). Waving hands and blaming people without mentioning what exactly
did they do wrong is (1) impolite, (2) wasting bandwidth.

				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
Lottery -- a tax on people who can't do math.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

>From mj+f-190804+schilling=fokus.fraunhofer.de@ucw.cz  Thu Aug 19 17:14:47 2004

>You are ranting about SUSE (and the incompetentness of other Linux people)
>on _this_ mailing list, so bring the facts _here_ (or at least the pointers
>to them). Waving hands and blaming people without mentioning what exactly
>did they do wrong is (1) impolite, (2) wasting bandwidth.

Wrong: you are ranting against me on this list and this list while the 
discussion has been done on another list. 

The fact that you write incorrect things only foirces me to write correctlions.

EOD

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

Hello!

> Wrong: you are ranting against me on this list and this list while the 
> discussion has been done on another list. 
> 
> The fact that you write incorrect things only foirces me to write correctlions.

Somebody did inform that Debian considers moving cdrecord to non-free.
You wrote an "correction", although it was true.

You keep accusing SUSE, although they are doing it right at least in the
current distribution.

And so on. So better do not tell us who is wrong.

> EOD

Agreed.

				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: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Schlemmer]

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

On Thu, 2004-08-19 at 17:00, Martin Mares wrote:
> Hello!
> 
> > There is already. cdrecord on SuSE 9.1 tells you:
> > Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 J??rg Schilling
> > Note: This version is an unofficial (modified) version with DVD support
> > Note: and therefore may have bugs that are not present in the original.
> > Note: Please send bug reports or support requests to http://www.suse.de/feedback
> > Note: The author of cdrecord should not be bothered with problems in this version.
> 
> So, case closed, it seems. Any other arguments, Joerg?
> 

I am afraid that Joerg sees any negative comments, even if polite
as flames, so until he gets out of his bunker and drop the
flame-thrower, this wont get resolved :(  Or that is at least my
impression after reading this whole thread and asking once nicely
what would be the problem with the changes we are asking for.


-- 
Martin Schlemmer

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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

On Thu, 19 Aug 2004, Martin Mares wrote:

> That's really hard to believe, but on the other hand, when packaging
> my programs, SUSE people were always cooperating very well.

It depends on whom you talk to. The generic feedback ways don't work
well at all, 80% of issues are apparently dropped, no chance to query
status from the outside, and it takes ages until something happens.

> So, let's ask the SUSE'rs around there: is there any problem with adding such
> a notice to the cdrecord package?

Non-issue.  SuSE 9.1 PRO:

$ rpm -qf /usr/bin/cdrecord
cdrecord-2.01a27-21
$ /usr/bin/cdrecord -version
ZY�$: Operation not permitted. WARNING: Cannot set RR-scheduler
ZY�$: Permission denied. WARNING: Cannot set priority using setpriority().
ZY�$: WARNING: This causes a high risk for buffer underruns.
Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 Jörg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to http://www.suse.de/feedback
Note: The author of cdrecord should not be bothered with problems in this version.

BTW:

$ /opt/schily/bin/cdrecord -version
Cdrecord-Clone 2.01a37 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J�rg Schilling
/opt/schily/bin/cdrecord: Warning: Running on Linux-2.6.8.1
/opt/schily/bin/cdrecord: There are unsettled issues with Linux-2.5 and newer.
/opt/schily/bin/cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.

I read the discussion as though these issues had been settled with
Linux 2.6.8. Is 2.01a37 too old to be aware of the fix or is there an
issue left with finding the "right" header files?

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Please let us cluse this duplicate discussion here.
It does not give new informstion and it takes a lot of my time.

>From matthias.andree@gmx.de  Thu Aug 19 17:07:13 2004

>Non-issue.  SuSE 9.1 PRO:

>$ rpm -qf /usr/bin/cdrecord
>cdrecord-2.01a27-21
>$ /usr/bin/cdrecord -version
>ZY�$: Operation not permitted. WARNING: Cannot set RR-scheduler
>ZY�$: Permission denied. WARNING: Cannot set priority using setpriority().
>ZY�$: WARNING: This causes a high risk for buffer underruns.

What you see is 2 SuSE created bugs :-(

1)	printing this message at all in this special case

2)	SuSE using non initialized variables.

>Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 Jörg Schilling
>Note: This version is an unofficial (modified) version with DVD support
>Note: and therefore may have bugs that are not present in the original.
>Note: Please send bug reports or support requests to http://www.suse.de/feedback
>Note: The author of cdrecord should not be bothered with problems in this version.


Isn't is pure taunt to output the text "may have bugs" after verifying two bugs?


>$ /opt/schily/bin/cdrecord -version
>Cdrecord-Clone 2.01a37 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J�rg Schilling
>/opt/schily/bin/cdrecord: Warning: Running on Linux-2.6.8.1
>/opt/schily/bin/cdrecord: There are unsettled issues with Linux-2.5 and newer.
									^^^^^^
									should 
									be "later"
>/opt/schily/bin/cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.

>I read the discussion as though these issues had been settled with
>Linux 2.6.8. Is 2.01a37 too old to be aware of the fix or is there an
>issue left with finding the "right" header files?

cdrtools is in code freeze and Linux-2.6.8 did open new problems that would 
require code anhancements that cannot be done in this state of cdrtools.

There are other problems that have been discussed last week.....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Mares]

> >$ /opt/schily/bin/cdrecord -version
> >Cdrecord-Clone 2.01a37 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J???rg Schilling
> >/opt/schily/bin/cdrecord: Warning: Running on Linux-2.6.8.1
> >/opt/schily/bin/cdrecord: There are unsettled issues with Linux-2.5 and newer.
> 									^^^^^^
> 									should 
> 									be "later"

Heh, this is your own bug ;-)  This exact message is in cdrecord/cdrecord.c
in your cdrtools-2.01a38-pre.tar.bz2.

				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
Current root password is "p3s5vwF50". Keep secret.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Andreas Jaeger]

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

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

> Please let us cluse this duplicate discussion here.
> It does not give new informstion and it takes a lot of my time.
>
>>From matthias.andree@gmx.de  Thu Aug 19 17:07:13 2004
>
>>Non-issue.  SuSE 9.1 PRO:
>
>>$ rpm -qf /usr/bin/cdrecord
>>cdrecord-2.01a27-21
>>$ /usr/bin/cdrecord -version
>>ZY�$: Operation not permitted. WARNING: Cannot set RR-scheduler
>>ZY�$: Permission denied. WARNING: Cannot set priority using setpriority().
>>ZY�$: WARNING: This causes a high risk for buffer underruns.
>
> What you see is 2 SuSE created bugs :-(
>
> 1)	printing this message at all in this special case
>
> 2)	SuSE using non initialized variables.

I agree and I'm sorry about that.

Thanks, I've filed bugreports for those and those will be fixed soon,

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Julien Oster]

Andreas Jaeger <aj@suse.de> writes:

>> What you see is 2 SuSE created bugs :-(

>> 1)	printing this message at all in this special case
>> 2)	SuSE using non initialized variables.

> I agree and I'm sorry about that.
> Thanks, I've filed bugreports for those and those will be fixed soon,

>  Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj

Now, look, Jörg! Here is one of that fearful examples of a SuSE
employee. Unfriendly, not willing to fix anything, completely ignoring
bug reports!

Seriously, Jörg, stop bashing people, that's getting far beyond just
being impolite.

While I could just killfile you, I still feel that those discussions
are blocking serious development in that sector.

To you, Andreas: Thanks for the patches done in the past, they
actually do improve cdrecord.

Schöne Grüße,
Julien

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Gene Heskett]

On Thursday 19 August 2004 11:07, Matthias Andree wrote:
>On Thu, 19 Aug 2004, Martin Mares wrote:
>> That's really hard to believe, but on the other hand, when
>> packaging my programs, SUSE people were always cooperating very
>> well.
>
>It depends on whom you talk to. The generic feedback ways don't work
>well at all, 80% of issues are apparently dropped, no chance to
> query status from the outside, and it takes ages until something
> happens.
>
>> So, let's ask the SUSE'rs around there: is there any problem with
>> adding such a notice to the cdrecord package?
>
>Non-issue.  SuSE 9.1 PRO:
>
>$ rpm -qf /usr/bin/cdrecord
>cdrecord-2.01a27-21
>$ /usr/bin/cdrecord -version
>ZY�$: Operation not permitted. WARNING: Cannot set RR-scheduler
>ZY�$: Permission denied. WARNING: Cannot set priority using
> setpriority(). ZY�$: WARNING: This causes a high risk for buffer
> underruns. Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright
> (C) 1995-2004 Jörg Schilling Note: This version is an unofficial
> (modified) version with DVD support Note: and therefore may have
> bugs that are not present in the original. Note: Please send bug
> reports or support requests to http://www.suse.de/feedback Note:
> The author of cdrecord should not be bothered with problems in this
> version.
>
>BTW:
>
>$ /opt/schily/bin/cdrecord -version
>Cdrecord-Clone 2.01a37 (i686-pc-linux-gnu) Copyright (C) 1995-2004
> J�rg Schilling /opt/schily/bin/cdrecord: Warning: Running on
> Linux-2.6.8.1 /opt/schily/bin/cdrecord: There are unsettled issues
> with Linux-2.5 and newer. /opt/schily/bin/cdrecord: If you have
> unexpected problems, please try Linux-2.4 or Solaris.
>
>I read the discussion as though these issues had been settled with
>Linux 2.6.8. Is 2.01a37 too old to be aware of the fix or is there
> an issue left with finding the "right" header files?

FWIW, I had to use smake, latest version from his site, in order to 
compile 2.01a37 just yesterday.  The error messages from make (very 
carefully programmed into the Makefile) indicated that the lost 
headers it couldn't find were a bug in make-3.80, and that his make 
suffered from no such errors.  It didn't.

Since the gnu make has only had, what, 2, maybe 3 revisions in almost 
a decade, maybe, just maybe, there is a grain of truth to Jorg's 
objections and often childish squawking, at least over the gnu make 
which he has mentioned, among others.

[root@coyote cdrecord]# cdrecord --version
Cdrecord-Clone 2.01a37 (i686-pc-linux-gnu) Copyright (C) 1995-2004 
Jörg Schilling
cdrecord: Warning: Running on Linux-2.6.8-rc4
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or 
Solaris.

However Jorg, since I built from your tarball, and used smake to do 
it, why is it now proclaiming to be a "Clone".

That doesn't seem to be the intended action unless he is carrying the 
linux/solaris battles in his code with conditionals.  And thats 
childish.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.24% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Paul Rolland]

Hello,

> FWIW, I had to use smake, latest version from his site, in order to 
> compile 2.01a37 just yesterday.  The error messages from make (very 
> carefully programmed into the Makefile) indicated that the lost 
> headers it couldn't find were a bug in make-3.80, and that his make 
> suffered from no such errors.  It didn't.
> 
> Since the gnu make has only had, what, 2, maybe 3 revisions in almost 
> a decade, maybe, just maybe, there is a grain of truth to Jorg's 
> objections and often childish squawking, at least over the gnu make 
> which he has mentioned, among others.

I did compile the cdrecord 2.01a37 on my machine no later than 
yesterday.
I was running my 2.6.8.1 kernel, and make says :
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i386-redhat-linux-gnu
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug-make@gnu.org>.

Build process was really fine, no error was reported, and I don't have
any smake stuff on my machine :
17 [17:58] rol@donald:~/install/cdrtools-2.01a37> smake
smake: Command not found.

 
> [root@coyote cdrecord]# cdrecord --version
> Cdrecord-Clone 2.01a37 (i686-pc-linux-gnu) Copyright (C) 1995-2004 
> Jörg Schilling
> cdrecord: Warning: Running on Linux-2.6.8-rc4
> cdrecord: There are unsettled issues with Linux-2.5 and newer.
> cdrecord: If you have unexpected problems, please try Linux-2.4 or 
> Solaris.
> 
> However Jorg, since I built from your tarball, and used smake to do 
> it, why is it now proclaiming to be a "Clone".

Seems to be only related to the -clone option if you look at the code, 
and it indicates the feature has been compile :
#ifdef  CLONE_WRITE
        error("\t-clone         Write disk in clone write mode.\n");
#endif  

Regards,
Paul

Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator

--

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur

"Some people dream of success... while others wake up and work hard at it" 

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Gene Heskett]

On Thursday 19 August 2004 12:00, Paul Rolland wrote:
>Hello,
>
>> FWIW, I had to use smake, latest version from his site, in order
>> to compile 2.01a37 just yesterday.  The error messages from make
>> (very carefully programmed into the Makefile) indicated that the
>> lost headers it couldn't find were a bug in make-3.80, and that
>> his make suffered from no such errors.  It didn't.
>>
>> Since the gnu make has only had, what, 2, maybe 3 revisions in
>> almost a decade, maybe, just maybe, there is a grain of truth to
>> Jorg's objections and often childish squawking, at least over the
>> gnu make which he has mentioned, among others.
>
>I did compile the cdrecord 2.01a37 on my machine no later than
>yesterday.
>I was running my 2.6.8.1 kernel, and make says :
>GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
>Built for i386-redhat-linux-gnu
>Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
>        Free Software Foundation, Inc.
>This is free software; see the source for copying conditions.
>There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>PARTICULAR PURPOSE.
>
>Report bugs to <bug-make@gnu.org>.
>
Humm, I got many many losses of header stuff messages from:
[root@coyote cdrecord]# make --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

So apparently 3.80 is a regression in this case.

But, please note, your 3.79-1 is dated 2000, and my 3.80 is dated 
2002.  That to me says its all but abandoned.  Granted, its "mature" 
in that its been around for what, 30 years?  Still, when a needed 
facility was broken 2+ years ago according to these tests, why hasn't 
it since been fixed?

We seem to have an attitude that if it can build a kernel, what else 
does it need? :(

>Build process was really fine, no error was reported, and I don't
> have any smake stuff on my machine :
>17 [17:58] rol@donald:~/install/cdrtools-2.01a37> smake
>smake: Command not found.
>
>> [root@coyote cdrecord]# cdrecord --version
>> Cdrecord-Clone 2.01a37 (i686-pc-linux-gnu) Copyright (C) 1995-2004
>> Jörg Schilling
>> cdrecord: Warning: Running on Linux-2.6.8-rc4
>> cdrecord: There are unsettled issues with Linux-2.5 and newer.
>> cdrecord: If you have unexpected problems, please try Linux-2.4 or
>> Solaris.
>>
>> However Jorg, since I built from your tarball, and used smake to
>> do it, why is it now proclaiming to be a "Clone".
>
>Seems to be only related to the -clone option if you look at the
> code, and it indicates the feature has been compile :
>#ifdef  CLONE_WRITE
>        error("\t-clone         Write disk in clone write mode.\n");
>#endif
>
>Regards,
>Paul
>
>Paul Rolland, rol(at)as2917.net
>ex-AS2917 Network administrator and Peering Coordinator
>
However, here is a rather interesting tidbit to the ongoing saga of me 
trying to avoid the linux equ of the infamous BSOD.

The last time I was playing in the bios, I turned off the "external 
cache".  Well, the machine is so slow as to be almost unusable (it 
may be 30+ seconds between my typing, and seeing it on the screen, 
spamassassin in particular is having cpu for lunch!), and I expected 
that, BUT!!!!!!  The normal gnu make just made it from an "smake 
clean" tate, WITHOUT ERRORS or warnings of any kind being reported.  
But it, and yet another kernel remake took about 3x their normal 
amounts of time, as in 18 minutes to build a 6 minute kernel.

And it didn't fix the --version output either:
[root@coyote cdrtools-2.01]# cdrecord/OBJ/athlon-linux-cc/cdrecord 
--version
Cdrecord-Clone 2.01a37 (i686-pc-linux-gnu) Copyright (C) 1995-2004 
Jörg Schilling
cdrecord/OBJ/athlon-linux-cc/cdrecord: Warning: Running on 
Linux-2.6.8-rc4
cdrecord/OBJ/athlon-linux-cc/cdrecord: There are unsettled issues with 
Linux-2.5 and newer.
cdrecord/OBJ/athlon-linux-cc/cdrecord: If you have unexpected 
problems, please try Linux-2.4 or Solaris.

Now I am wondering if linux is truely aware of what memory the bios 
may be setting up as L2 cache when its enabled, and the processor and 
linux are fighting over memory they both *think* they own?  And it 
darn sure waddles and quacks like this sort of a duck.

I'm about to reboot to 2.6.8.1-mm2 and move on, but I have to ask 
everyone if I just stumbled over a clue to my dcache/icache/buffer 
problems while sitting here in the intellectual dark.  I think it 
bears a bit of investigation from the near total lack of clues that 
point to an actual (heaven forbid, errk) fixed location bug, hardware 
or software...

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.24% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christoph Hellwig]

On Thu, Aug 19, 2004 at 04:03:00PM +0200, Joerg Schilling wrote:
> I did talk to the official SuSE product manager 1.5 years ago and this person
> just tried to take me as a clod.

When I worked at a Linux Distributor (not SuSE), the product managers always
were the most clueless middle-managment you could image - after all it's
usually a marketing-driven and not technical position.
Maybe you should have talked to the package maintainer instead?

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Andreas Jaeger]

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

Martin Mares <mj@ucw.cz> writes:

>[...]
> You explain that SuSE is non-cooperative, because they distribute crippled
> cdrecord, but you fail to explain what crippledness do you have in mind.

I would be interested also in what's the problem with our current
versions.

> Also, if you put away your flamethrower and just politely asked SUSE to add
> a message like `this version has been modified by SUSE, so please send your
> bug reports to support@suse.com instead of the original author', the whole
> issue would be probably already settled a long time ago.

Just for reference, SUSE does this already since some time.  There was
one version in the 8.x series that was indeed broken but since then
I'm not aware of any issues.

SUSE Linux 9.1 has:

# cdrecord --version
Cdrecord-Clone-dvd 2.01a27 (x86_64-suse-linux) Copyright (C) 1995-2004 Jörg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to http://www.suse.de/feedback
Note: The author of cdrecord should not be bothered with problems in this version.

Andreas

P.S. Yes, I do work for SUSE.

P.P.S: I think this is getting more and more offtopic for
linux-kernel.  Should we move the discussion somewhere else?

-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Anton Altaparmakov <aia21@cam.ac.uk> wrote:

> On Thu, 19 Aug 2004, Martin Mares wrote:
> > (BTW: I am not sure I haven't missed anything in the long cdrecord-related
> > threads on the LKML, but I still haven't seen what is exactly so broken on the
> > cdrecord shipped by SUSE.)
>
> I have been following the discussion quite closely and I concur with you.  
> Noone has actually said what is broken and all I can say is that I use 
> SuSE (9.0 and 9.1 since it came out) and have burnt several CD-Rs and 
> CD-RWs with its version of cdrecord just fine...

Let me repeat: I like to do useful things (e.g. finishing the incremental 
restore code in star) and not constantly be asked to tell you why it is broken.

I did this nuch more than ance in related mailinglist. The fact that you are 
not hit by the bugs is just meanlingless.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Gerd Knorr]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

> >If no one has noticed yet, thanks to the additional license
> >restrictions Joerg Schilling has added to cdrecord (due to this
> >thread), it may be now moved to non-free in Debian in the near future.
> 
> Your statement "it may be now moved to non-free in Debian in the near future"
> is just complete nonsense.

It's not.

> Of course, I am in discussions with Debian people about the best
> method to force SuSE not to publish broken versions of cdrtools in
> the future.

Just read the Debian Free Software Guidelines.  You can't do that if
you want cdrecord stay in main and not go to non-free.  See paragraph
#3 of DFSG: "The license must allow modifications and derived works"
and paragraph #8: "License Must Not Be Specific to Debian".  Also note
#5: "No Discrimination Against Persons or Groups".

> The GPL requires you not to impact the original authors'
> reputations, but this is what SuSE is doing by publishing defective
> variants.

Those "defective variants" (which are NOT defective for me) clearly
state that they are *not* the original version and problems/bugs
should be reported to suse (as suggested by the GPL paragraph you are
refering to).  An it's not somewhere hidden, but printed every single
time you start it to the terminal, four lines long.

  Gerd

-- 
return -ENOSIG;

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Joerg Schilling wrote:

> The GPL requires you not to impact the original authors' reputations, but this 
> is what SuSE is doing by publishing defective variants.

What a stupid claim. When I call cdrecord on SuSE 9.1, I can burn CDs and
DVDs as normal user, without root permissions, without suid, without ide-scsi,
using /dev/hdc as device.

And this just works fine. So where's the problem?

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Iau, 2004-08-19 at 15:32, Frank Steiner wrote:
> What a stupid claim. When I call cdrecord on SuSE 9.1, I can burn CDs and
> DVDs as normal user, without root permissions, without suid, without ide-scsi,
> using /dev/hdc as device.
> 
> And this just works fine. So where's the problem?

You can also erase the drive firmware as a user etc. That's the problem.
When you fix that cdrecord gets broken by the security fix if you are
using the SG_IO interface. Patches are kicking around to try and sort
things out so cd burning is safe as non-root. cdrecord works as root.

As a security fix it was sufficiently important that it had to be done.

Alan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bartlomiej Zolnierkiewicz]

On Thursday 19 August 2004 16:32, Alan Cox wrote:
> On Iau, 2004-08-19 at 15:32, Frank Steiner wrote:
> > What a stupid claim. When I call cdrecord on SuSE 9.1, I can burn CDs and
> > DVDs as normal user, without root permissions, without suid, without
> > ide-scsi, using /dev/hdc as device.
> >
> > And this just works fine. So where's the problem?
>
> You can also erase the drive firmware as a user etc. That's the problem.
> When you fix that cdrecord gets broken by the security fix if you are
> using the SG_IO interface. Patches are kicking around to try and sort
> things out so cd burning is safe as non-root. cdrecord works as root.
>
> As a security fix it was sufficiently important that it had to be done.

IMO work-rounding this in kernel is a bad idea and could break a lot of 
existing apps (some you even don't know about).  Much better way to deal with 
this is to create library for handling I/O commands submission and gradually 
teach user-space apps to use it.

Bartlomiej

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

>From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>

>> As a security fix it was sufficiently important that it had to be done.

>IMO work-rounding this in kernel is a bad idea and could break a lot of 
>existing apps (some you even don't know about).  Much better way to deal with 
>this is to create library for handling I/O commands submission and gradually 
>teach user-space apps to use it.

This is exactly what libscg is for...... 
libscg already includes similar support for Solaris 9 & Solaris 10.

Cdrtools is is code freeze state. This is why I say the best idea is to remove 
this interface change from the current Linux kernel and wait until there will
be new cdrtools alpha for 2.02 releases. These alpha could get support for uid
switching. If Linux then would again switch the changes on, it makes sense.

BTW: it makes absolutely no sense to have a list of "safe" commands in the kernel
as the kernel simply cannot know which SCSI commands are "safe" and which not.
The list would be if ever subject to changess on a dayly base which is a real 
bad idea.

Note that having such a list of aparently safe commands would cause a lot of
untracable problems (why does it run for you but not for me....).


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Horst von Brand]

Joerg Schilling <schilling@fokus.fraunhofer.de> said:
> Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> said:

> >> As a security fix it was sufficiently important that it had to be done.

> >IMO work-rounding this in kernel is a bad idea and could break a lot of
> >existing apps (some you even don't know about).  Much better way to deal
> >with this is to create library for handling I/O commands submission and
> >gradually teach user-space apps to use it.

Nonsense (as I just said in another message).

> This is exactly what libscg is for...... 
> libscg already includes similar support for Solaris 9 & Solaris 10.

OK, their problem.

> Cdrtools is is code freeze state. This is why I say the best idea is to
> remove this interface change from the current Linux kernel and wait until
> there will be new cdrtools alpha for 2.02 releases. These alpha could get
> support for uid switching. If Linux then would again switch the changes
> on, it makes sense.

Sorry, you have absolutely no say in the development of the kernel
here. You fix your broken app, code freeze or no code freeze. Or let others
that fix it alone.

> BTW: it makes absolutely no sense to have a list of "safe" commands in
> the kernel as the kernel simply cannot know which SCSI commands are
> "safe" and which not.

"Normal" read/write commands are safe, others are off-limits unless you
have the required capability (one which allows you to set the device on
fire at will, that is).

>                        The list would be if ever subject to changess on a
> dayly base which is a real bad idea.

Not unless standard SCSI commands change by the day. And I somewhat doubt
that to be the case.

> Note that having such a list of aparently safe commands would cause a lot of
> untracable problems (why does it run for you but not for me....).

Right. But better "Funny, it doesn't work here..." than "Sh*t! Another
CD/DVD-writer turned into a brick!".
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bartlomiej Zolnierkiewicz]

On Thursday 19 August 2004 19:32, Horst von Brand wrote:
> Joerg Schilling <schilling@fokus.fraunhofer.de> said:
> > Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> said:
> > >> As a security fix it was sufficiently important that it had to be
> > >> done.
> > >
> > >IMO work-rounding this in kernel is a bad idea and could break a lot of
> > >existing apps (some you even don't know about).  Much better way to deal
> > >with this is to create library for handling I/O commands submission and
> > >gradually teach user-space apps to use it.
>
> Nonsense (as I just said in another message).

Please read Mark Lord's mail and my reply.

> > This is exactly what libscg is for......
> > libscg already includes similar support for Solaris 9 & Solaris 10.
>
> OK, their problem.
>
> > Cdrtools is is code freeze state. This is why I say the best idea is to
> > remove this interface change from the current Linux kernel and wait until
> > there will be new cdrtools alpha for 2.02 releases. These alpha could get
> > support for uid switching. If Linux then would again switch the changes
> > on, it makes sense.
>
> Sorry, you have absolutely no say in the development of the kernel
> here. You fix your broken app, code freeze or no code freeze. Or let others
> that fix it alone.
>
> > BTW: it makes absolutely no sense to have a list of "safe" commands in
> > the kernel as the kernel simply cannot know which SCSI commands are
> > "safe" and which not.
>
> "Normal" read/write commands are safe, others are off-limits unless you
> have the required capability (one which allows you to set the device on
> fire at will, that is).
>
> >                        The list would be if ever subject to changess on a
> > dayly base which is a real bad idea.
>
> Not unless standard SCSI commands change by the day. And I somewhat doubt
> that to be the case.

theory != practice

> > Note that having such a list of aparently safe commands would cause a lot
> > of untracable problems (why does it run for you but not for me....).
>
> Right. But better "Funny, it doesn't work here..." than "Sh*t! Another
> CD/DVD-writer turned into a brick!".

Horst, the fact that Joerg is hard to deal with and usually not right doesn't 
mean that he can't be right sometimes. ;-)

Bartlomiej

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Horst von Brand <vonbrand@inf.utfsm.cl> wrote:

> > This is exactly what libscg is for...... 
> > libscg already includes similar support for Solaris 9 & Solaris 10.
>
> OK, their problem.

If yopu don't understans what we are talking, plaese don't send useless 
comments like this.

> Sorry, you have absolutely no say in the development of the kernel
> here. You fix your broken app, code freeze or no code freeze. Or let others
> that fix it alone.

Sorry, you have absolutely nothing to say in the development of the kernel

The Linux kernel is broken because it it did break existing interfaces - period.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Fri, 20 Aug 2004 15:37:22 +0200, Joerg Schilling
<schilling@fokus.fraunhofer.de> wrote:
> The Linux kernel is broken because it it did break existing interfaces - period.

What you really meant to say is that they fixed a previously broken
interface so that it worked correctly; which just happened to break
your poorly written app. If you had any shread of self respect, you'd
silently fix cdrecord without a further mention of it here.

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Patrick McFarland <diablod3@gmail.com> wrote:

> On Fri, 20 Aug 2004 15:37:22 +0200, Joerg Schilling
> <schilling@fokus.fraunhofer.de> wrote:
> > The Linux kernel is broken because it it did break existing interfaces - period.
>
> What you really meant to say is that they fixed a previously broken
> interface so that it worked correctly; which just happened to break
> your poorly written app. If you had any shread of self respect, you'd
> silently fix cdrecord without a further mention of it here.

You seem to fail to undrstand the word "pooly" :-(

If applicable in this discussion then only to the way the Linux Kernel
deals with interfaces.....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Iau, 2004-08-19 at 17:07, Joerg Schilling wrote:
> Cdrtools is is code freeze state. This is why I say the best idea is to remove 
> this interface change from the current Linux kernel and wait until there will
> be new cdrtools alpha for 2.02 releases. These alpha could get support for uid
> switching. If Linux then would again switch the changes on, it makes sense.

While Sun did spend a year refusing to fix security holes I found -  for
"compatibility reasons" - long ago back when I was a sysadmin at NTL,
the Linux world does not work that way.

Alan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Iau, 2004-08-19 at 17:07, Joerg Schilling wrote:
> > Cdrtools is is code freeze state. This is why I say the best idea is to remove 
> > this interface change from the current Linux kernel and wait until there will
> > be new cdrtools alpha for 2.02 releases. These alpha could get support for uid
> > switching. If Linux then would again switch the changes on, it makes sense.
>
> While Sun did spend a year refusing to fix security holes I found -  for
> "compatibility reasons" - long ago back when I was a sysadmin at NTL,
> the Linux world does not work that way.

Unless you tell us what kind of "security holes" you found _and_ when this has 
been, it looks like a meaningless remark.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Gwe, 2004-08-20 at 14:41, Joerg Schilling wrote:
> > While Sun did spend a year refusing to fix security holes I found -  for
> > "compatibility reasons" - long ago back when I was a sysadmin at NTL,
> > the Linux world does not work that way.
> 
> Unless you tell us what kind of "security holes" you found _and_ when this has 
> been, it looks like a meaningless remark.

Solaris of 2.5 era had bugs that allowed any user with rsh access to
issue network configuration ioctls. The sun engineers fixed the bug the
day I reported it then various other people refused to allow it out for
a year.

Linux doesn't work this way. We fix security bugs as a priority.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Fri, 20 Aug 2004 15:41:54 +0200, Joerg Schilling
<schilling@fokus.fraunhofer.de> wrote:
> Unless you tell us what kind of "security holes" you found _and_ when this has
> been, it looks like a meaningless remark.

Face it, you think anything anyone says (including Alan, Linus, me,
and anyone else who happens by) anything about your precious cdrtools
is making meaningless remarks. Allowing users to fuck hardware using a
badly written permissions system _is_ a security hole, no matter how
much you dance around the issue.

This is why Linus added what he did, so users couldn't; which means
_fix your damn program and quit your bitching_.

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[H.Rosmanith (Kernel Mailing List)]

> > While Sun did spend a year refusing to fix security holes I found -  for
> > "compatibility reasons" - long ago back when I was a sysadmin at NTL,
> > the Linux world does not work that way.
> 
> Unless you tell us what kind of "security holes" you found _and_ when this has 
> been, it looks like a meaningless remark.

Well ... despite the danger, that this email ist just another meaninless
remark, too, I'd say that Sun acts like any other big software company: they
don't listen to single persons reporting bugs, and tend to blame misbehaviour
of software on you. Personal experience: I implemented some smartcard driver,
it didn't work, I identified a bug, reported it. Sun said: "your software is
buggy". It was only after our client (a big company) intervened, that Sun modified
their kernel drivers (allthough I think the error was "below" that).
Even though I exactly told them how to reproduce the bug, they were not able to.
Two co-workes had to go to Sun in San Francisco - and they instantly were able to
reproduce the bug on Sun's machine.

Typical scenario: small sw-company reports bugs -> reply: "you are too unskilled".
                  big company enters the scene -> things are getting fixed.

So, you see, Sun is not per se impeccable.

best regards,
H.Rosmanith

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

"H.Rosmanith (Kernel Mailing List)" <kernel@wildsau.enemy.org> wrote:

> Typical scenario: small sw-company reports bugs -> reply: "you are too unskilled".
>                   big company enters the scene -> things are getting fixed.
>
> So, you see, Sun is not per se impeccable.

The main difference between Sun and Linux as I see here in these discussions
is, that Sun remembers who does make a bug report (unfortunately this does not
apply to the local bug report centers but to the Sun central).

For this reason, it is easy for me to get attention. The right people at Sun 
just know that I did make a lot if important bug reports and take me serious.

When I send a bug report about incorrect signal handling in all known ssh 
clients out in Saturday noon, I did get a reply from Sun Saturday evening
and a reply from OpenSSH on Monday. I did never get a reply from SSH.com
although they did fix the bug too.

What I did send out a bug report against Solaris 10 USB-2 DMA problems, I did
receive a new test driver binary from the team leader 10 days later.

If you are unknown at Sun, you may habe problems......

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Richard B. Johnson]

On Fri, 20 Aug 2004, Joerg Schilling wrote:

> "H.Rosmanith (Kernel Mailing List)" <kernel@wildsau.enemy.org> wrote:
>
> > Typical scenario: small sw-company reports bugs -> reply: "you are too unskilled".
> >                   big company enters the scene -> things are getting fixed.
> >
> > So, you see, Sun is not per se impeccable.
>
> The main difference between Sun and Linux as I see here in these discussions
> is, that Sun remembers who does make a bug report
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

He He ... and they try to "get even", too! --Not by fixing bugs,
but by "reporting" "stupid" clients to their bosses. That's why
I have the only remaining Sun in the company. I was too lazy
to turn it back on after a power failure a couple of years ago.
Therefore, I didn't report any problems to Sun...and got to
keep the machine.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Martin Schlemmer]

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

On Fri, 2004-08-20 at 15:41, Joerg Schilling wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > On Iau, 2004-08-19 at 17:07, Joerg Schilling wrote:
> > > Cdrtools is is code freeze state. This is why I say the best idea is to remove 
> > > this interface change from the current Linux kernel and wait until there will
> > > be new cdrtools alpha for 2.02 releases. These alpha could get support for uid
> > > switching. If Linux then would again switch the changes on, it makes sense.
> >
> > While Sun did spend a year refusing to fix security holes I found -  for
> > "compatibility reasons" - long ago back when I was a sysadmin at NTL,
> > the Linux world does not work that way.
> 
> Unless you tell us what kind of "security holes" you found _and_ when this has 
> been, it looks like a meaningless remark.
> 

But this is the same kind of remarks you make - statements without
proof (the ones you also did not explain, and explicitly refuse to
explain or give a pointer to) - so I assume we should also consider
them as meaningless ?


-- 
Martin Schlemmer

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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Valdis.Kletnieks]

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

On Fri, 20 Aug 2004 21:28:56 +0200, Martin Schlemmer said:
> On Fri, 2004-08-20 at 15:41, Joerg Schilling wrote:
> > Unless you tell us what kind of "security holes" you found _and_ when this has
> > been, it looks like a meaningless remark.

> But this is the same kind of remarks you make - statements without
> proof (the ones you also did not explain, and explicitly refuse to
> explain or give a pointer to) - so I assume we should also consider
> them as meaningless ?

The difference is that Alan Cox has enough reputation that if he handwaves and
says something opaque about thinking that R/O permissions is enough to stop
something, the obvious explanations (in order of likelyhood) are:

1) He's found an actual hole, and is being intentionally obtuse until the patch
appears in the tree. (I've certainly seen *that* happen often enough, and I'm
not even what would be called an old-timer around here)..

2) It's something actually obvious, and his remark only appears opaque because
I'm an idiot and don't get it (that's been known to happen fairly often as
well).

3) He's actually full of it (much less likely than either of the first two)...


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

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Kyle Moffett]

On Aug 20, 2004, at 09:41, Joerg Schilling wrote:
>> While Sun did spend a year refusing to fix security holes I found -  
>> for
>> "compatibility reasons" - long ago back when I was a sysadmin at NTL,
>> the Linux world does not work that way.
>
> Unless you tell us what kind of "security holes" you found _and_ when 
> this has
> been, it looks like a meaningless remark.

Further discussion on such a topic is irrelevant.  There is at least 
one case
where a vendor has chosen compatibility over security (*cough* *cough*
Windows *cough*).  From the previous emails on the issue, the general
opinion of most Linux developers is to choose security over 
compatibility,
after all, with free software users are free to fix the 
bugs/incompatibilities
themselves.

Security issue:
	Anybody with read access to certain block devices (Like CD-RW
drives.) could reflash the firmware or otherwise turn the drive into a
rather expensive doorstop.

Chosen solution for 2.6.8.1:
	Only allow certain known-safe commands, anything else needs
root privileges, specifically CAP_SYS_RAWIO or CAP_SYS_ADMIN,
  (Seems sane, and follows with the general design of the  rest of the
kernel).

Problems with the solution:
	It breaks software, *whine*!  Well, if Microsoft suddenly fixed all
the remaining security flaws in its software, almost _all_ Windows
software would break, because they depend on silly things like writable
files on the root of the C drive.  Just because software does something
doesn't mean it's secure.

Personally, I'd rather have a setuid executable on my system than
allow anybody in the cdwriters group to reflash my CDROM drive. For
you there is a _really_ simple solution akin to the warning message
that already exists in linuxcheck(), if the version is >= 2.6.8, just 
tell
the user that it's unsupported and won't work without a patched
kernel.  That's a change that could even go in during a code freeze!

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Andreas Steinmetz]

Kyle Moffett wrote:
> Chosen solution for 2.6.8.1:
>     Only allow certain known-safe commands, anything else needs
> root privileges, specifically CAP_SYS_RAWIO or CAP_SYS_ADMIN,
>  (Seems sane, and follows with the general design of the  rest of the
> kernel).

To make this clear first: I don't want to step on anyone's toes.

So here is a snippet of code that should work nicely on 2.4 and 2.6 (the 
latter with the sanitized kernel headers) to set the required 
capabiltities in a setuid() wrapper:

#include <unistd.h>
#include <linux/capability.h>
#include <sys/prctl.h>
extern int capset(cap_user_header_t header, const cap_user_data_t data);

int do_setuid(uid_t uid)
{
   int r;
   struct __user_cap_header_struct h;
   struct __user_cap_data_struct c;

   if(geteuid())return setuid(uid);
   memset(&h,0,sizeof(h));
   h.version=_LINUX_CAPABILITY_VERSION;
   h.pid=0;
   memset(&c,0,sizeof(c));
   c.effective=1<<CAP_SYS_RAWIO|1<<CAP_SYS_ADMIN|1<<CAP_SETUID;
   c.permitted=1<<CAP_SYS_RAWIO|1<<CAP_SYS_ADMIN|1<<CAP_SETUID;
   c.inheritable=0;
   capset(&h,&c);
   prctl(PR_SET_KEEPCAPS,1,0,0,0);
   r=setuid(uid);
   memset(&h,0,sizeof(h));
   h.version=_LINUX_CAPABILITY_VERSION;
   h.pid=0;
   memset(&c,0,sizeof(c));
   c.effective=1<<CAP_SYS_RAWIO|1<<CAP_SYS_ADMIN;
   c.permitted=1<<CAP_SYS_RAWIO|1<<CAP_SYS_ADMIN;
   c.inheritable=0;
   capset(&h,&c);
   prctl(PR_SET_KEEPCAPS,0,0,0,0);
   return r;
}

Now this is what free software is all about. Reuse of knowledge for 
everyone. Jörg, feel free to use the above code. Note that the 
CAP_SETUID usage is a workaround for a 2.4 bug.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Greaves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyle Moffett wrote:

|
| Security issue:
|     Anybody with read access to certain block devices (Like CD-RW

~                    ^^^^

| drives.) could reflash the firmware or otherwise turn the drive into a
| rather expensive doorstop.
|
| Chosen solution for 2.6.8.1:
|     Only allow certain known-safe commands, anything else needs
| root privileges, specifically CAP_SYS_RAWIO or CAP_SYS_ADMIN,

~    ^^^^^^^^

|  (Seems sane, and follows with the general design of the  rest of the
| kernel).

Can someone explain why it isn't anyone with _write_ access to the device?
Surely it's better to drop a user into a group or setgid a program?

If I have write access to a device then I can wipe it's media anyway.
Is there something I'm missing?

| Personally, I'd rather have a setuid executable on my system than
| allow anybody in the cdwriters group to reflash my CDROM drive.

OK, you keep the users out of the group and make the progaram setgid
cdwriters.
Then if someone makes a mess of the set[gu]id code you lose your
cdwriter (which would be gone anyway) and not your whole system.

Why force the program to escalate to root?

David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBJvJ78LvjTle4P1gRAgFSAJ92lFbuqHqibMlotNi0jXln10SrhgCePBlS
a4xebwkvjNxVV7L9eoLB7cI=
=bswe
-----END PGP SIGNATURE-----

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Marc Ballarin]

On Sat, 21 Aug 2004 07:58:03 +0100
David Greaves <david@dgreaves.com> wrote:

> Can someone explain why it isn't anyone with _write_ access to the
> device? Surely it's better to drop a user into a group or setgid a
> program?
> 
> If I have write access to a device then I can wipe it's media anyway.
> Is there something I'm missing?
> 

With RAW_IO access you cannot only wipe the media, but the entire
firmware (not only wipe it, but also upload a malicious version that will
screw up the entire SCSI or IDE bus).

Andreas Messer and I are working on an improved filter that works per
device and is configurable from userspace. It's not easy though.

Regards

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Greaves]

Marc Ballarin wrote:

>On Sat, 21 Aug 2004 07:58:03 +0100
>David Greaves <david@dgreaves.com> wrote:
>
>  
>
>>Can someone explain why it isn't anyone with _write_ access to the
>>device? Surely it's better to drop a user into a group or setgid a
>>program?
>>
>>If I have write access to a device then I can wipe it's media anyway.
>>Is there something I'm missing?
>>
>>    
>>
>
>With RAW_IO access you cannot only wipe the media, but the entire
>firmware (not only wipe it, but also upload a malicious version that will
>screw up the entire SCSI or IDE bus).
>
>Andreas Messer and I are working on an improved filter that works per
>device and is configurable from userspace. It's not easy though.
>  
>
Thanks - I get that :)

The 'write' point is that from a data perspective you've already lost 
your data (which is the most valuable thing from a security perspective).
I agree it's nice to give people write access to hardware and not let 
them melt it permanently. However, if the semantics don't allow 'safe' 
writing then prevent all user writing and use setgid for safe programs 
(which is essentially what you are doing anyway) to allow users to write.

So, the real point: principle of least privilege.
Why root? why not set[gu]id cdwriters?

David

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Marc Ballarin]

On Sat, 21 Aug 2004 10:04:38 +0100
David Greaves <david@dgreaves.com> wrote:

> Thanks - I get that :)
> 
> The 'write' point is that from a data perspective you've already lost 
> your data (which is the most valuable thing from a security
> perspective). I agree it's nice to give people write access to hardware
> and not let them melt it permanently. However, if the semantics don't
> allow 'safe' writing then prevent all user writing and use setgid for
> safe programs (which is essentially what you are doing anyway) to allow
> users to write.
> 

That's basically my idea. By default CAP_SYS_RAWIO is needed to issue any
comand. This will work fine if the software has been adjusted accordingly
*and* there is a software for the desired purpose.

However, there are cases where users have to be granted read or write
access to devices (databases, strange hardware, co-admins). In this cases,
the admin should be able to allow certain SCSI commands even for non-root
users.

Regards

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Sad, 2004-08-21 at 10:04, David Greaves wrote:
> So, the real point: principle of least privilege.
> Why root? why not set[gu]id cdwriters?

It requires CAP_SYS_RAWIO, because that is the level of access it gives.
How you do the capability management is a user space issue.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Adam Sampson]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> It requires CAP_SYS_RAWIO, because that is the level of access it gives.

That seems like a reasonable requirement, but would it be possible to
do the capability check at open() time, rather than when the operation
is performed? That would be more consistent with how conventional
permissions checks on files/devices work, and would avoid breaking
privilege-dropping applications.

I don't really want to run my CD-writing tool with CAP_SYS_RAWIO all
the time -- if it's got a security hole that a malicious CD image can
exploit, then I'd rather it were just able to damage the CD drive than
the rest of the system...

Thanks,

-- 
Adam Sampson <azz@us-lot.org>                        <http://offog.org/>

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Xavier Bestel]

Le sam 21/08/2004 à 08:58, David Greaves a écrit :

> Can someone explain why it isn't anyone with _write_ access to the device?
> Surely it's better to drop a user into a group or setgid a program?
> 
> If I have write access to a device then I can wipe it's media anyway.
> Is there something I'm missing?

If you have write access to a single partition only, you could always
screw the entire disk (and with firmware upload, it's really totally
screwed).

	Xav

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[David Greaves]

Xavier Bestel wrote:

>Le sam 21/08/2004 à 08:58, David Greaves a écrit :
>
>  
>
>>Can someone explain why it isn't anyone with _write_ access to the device?
>>Surely it's better to drop a user into a group or setgid a program?
>>
>>If I have write access to a device then I can wipe it's media anyway.
>>Is there something I'm missing?
>>    
>>
>
>If you have write access to a single partition only, you could always
>screw the entire disk (and with firmware upload, it's really totally
>screwed).
>
OK - I was thinking of the CD problem.

So only allow these operations on the whole disk device?

If you wanted to grant them this capability on a partition then my 
understanding is that through the power of these operations you've 
essentially given them the ability to overwrite to the whole device 
anway - so just give them write permission to the whole device. MNaybe 
through setgid code though.

If you need some operations to act on the partitions then you'd have to 
differentiate between users writing to a partition and users operating 
on the partition. Difficult without better acls - so then you have to 
say "operations on the whole disk device granted through write 
permission; operations on the partition devices forbidden"

The less reasons to make users use or suid root, the better.

David

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Horst von Brand]

Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> said:
> On Thursday 19 August 2004 16:32, Alan Cox wrote:
> > On Iau, 2004-08-19 at 15:32, Frank Steiner wrote:
> > > What a stupid claim. When I call cdrecord on SuSE 9.1, I can burn CDs and
> > > DVDs as normal user, without root permissions, without suid, without
> > > ide-scsi, using /dev/hdc as device.
> > >
> > > And this just works fine. So where's the problem?
> >
> > You can also erase the drive firmware as a user etc. That's the problem.
> > When you fix that cdrecord gets broken by the security fix if you are
> > using the SG_IO interface. Patches are kicking around to try and sort
> > things out so cd burning is safe as non-root. cdrecord works as root.
> >
> > As a security fix it was sufficiently important that it had to be done.

> IMO work-rounding this in kernel is a bad idea and could break a lot of
> existing apps (some you even don't know about).  Much better way to deal
> with this is to create library for handling I/O commands submission and
> gradually teach user-space apps to use it.

Sorry to disagree, but no way. If security is involved, depending on people
do do "the right thing" because they are nice (and update their code, and
follow "good practice", and ...) is suicide. Better be safe, and swallow
the flames caused by unfixed apps while it lasts.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513 

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Iau, 2004-08-19 at 17:00, Bartlomiej Zolnierkiewicz wrote:
> > As a security fix it was sufficiently important that it had to be done.
> 
> IMO work-rounding this in kernel is a bad idea and could break a lot of 
> existing apps (some you even don't know about).  Much better way to deal with 
> this is to create library for handling I/O commands submission and gradually 
> teach user-space apps to use it.

And what do you do the day someone posts "lock IDE drive with random
password as any user" to bugtraq ?

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Mark Lord]

 >And what do you do the day someone posts "lock IDE drive with random
 >password as any user" to bugtraq ?

I should hope that these lines in the driver would prevent such:

       if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
             return -EACCES;

Cheers
-- 
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bartlomiej Zolnierkiewicz]

On Thursday 19 August 2004 21:19, Mark Lord wrote:
>  >And what do you do the day someone posts "lock IDE drive with random
>  >password as any user" to bugtraq ?
>
> I should hope that these lines in the driver would prevent such:
>
>        if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
>              return -EACCES;

Exactly.

Sending raw commands is _privileged_ operation.

Alan's example is invalid because IDE driver requires CAP_SYS_ADMIN and 
CAP_SYS_RAWIO so if there is some security risk involved - it is in the user 
apps not in the kernel.  Also Linus first fixed SG_IO correctly with 
requiring CAP_SYS_RAWIO but then (under Alan's influence?) he added filtering 
which broke cd writing and which is just unmaintainable.

Also filtering cannot work in all cases because there are vendor specific 
opcodes, some devices redefines some opcodes etc. - this should be left to 
user space.

Bartlomiej

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Iau, 2004-08-19 at 23:57, Bartlomiej Zolnierkiewicz wrote:
> Alan's example is invalid because IDE driver requires CAP_SYS_ADMIN and 
> CAP_SYS_RAWIO so if there is some security risk involved - it is in the user 
> apps not in the kernel.  Also Linus first fixed SG_IO correctly with 
> requiring CAP_SYS_RAWIO but then (under Alan's influence?) he added filtering 
> which broke cd writing and which is just unmaintainable.

SG_IO prior to 2.6.8 doesn't do any checks on any path into and through
the IDE driver. Thus I sent Linus a patch for 2.6.8 that just added
capable(CAP_SYS_RAWIO) to the raw command path.

Filtering was something Jens and I were talking about. I was a little
suprised when Linus added filters just before release. We do now have
good traces of what various apps want. Some of those commands may be
problematic without sg_io knowing the target class however.

> Also filtering cannot work in all cases because there are vendor specific 
> opcodes, some devices redefines some opcodes etc. - this should be left to 
> user space.

Possibly. Vendor commands are not in themselves a problems. The answer
to those is "no" 8)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Iau, 2004-08-19 at 20:19, Mark Lord wrote:
>  >And what do you do the day someone posts "lock IDE drive with random
>  >password as any user" to bugtraq ?
> 
> I should hope that these lines in the driver would prevent such:
> 
>        if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
>              return -EACCES;

These lines aren't in the prior to 2.6.8.1 SG_IO path...

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Alan Cox wrote:
> On Iau, 2004-08-19 at 15:32, Frank Steiner wrote:
> 
>>What a stupid claim. When I call cdrecord on SuSE 9.1, I can burn CDs and
>>DVDs as normal user, without root permissions, without suid, without ide-scsi,
>>using /dev/hdc as device.
>>
>>And this just works fine. So where's the problem?
> 
> 
> You can also erase the drive firmware as a user etc. That's the problem.

Hmm, but that's not a problem specific to the SuSE versions, is it?
Joerg was claiming that SuSE release "defective" versions that impact his
reputation. And I can't see that, because the versions shipped with at least
7.3, 9.0 and 9.1 just work fine (that's the versions I used).

The security thing and the problems with 2.6.8.1 keeping users from burning
(I have my set patched in now to allow users burning again, nor sure if
it is safe...) is a general issue as far as I understand, and nothing
SuSE specific.
Please correct me if I'm wrong!

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Gwe, 2004-08-20 at 08:46, Frank Steiner wrote:
> The security thing and the problems with 2.6.8.1 keeping users from burning
> (I have my set patched in now to allow users burning again, nor sure if
> it is safe...) is a general issue as far as I understand, and nothing
> SuSE specific.

Its a generic "kernel < 2.6.8.1" thing. Its one reason Fedora pushed a
2.6.8- kernel. If you've re-enabled unlimited access to your box you've
let your users destroy your machine. Whether that matters probably
depends on your users.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Frank Steiner]

Alan Cox wrote:

> If you've re-enabled unlimited access to your box you've
> let your users destroy your machine. Whether that matters probably
> depends on your users.

Not unlimited! I just collected all commands that were blocked from
cdrecord and growisofs. Actually, quite a lot :-/ But I'm far from
being expert enough to judge if those commands are safe or not.

Just for the records and if someone is interested it:
In addition to the patch Andreas Messer sent a while I ago, those
commands had to be set safe_for_read on SusE 9.1 with a Nec ND-1300A
and a Plextor PlexWriter W5224TA:

+               safe_for_read(GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL),
+               safe_for_read(REZERO_UNIT),
+               safe_for_read(0xe9),		/* drive specific, unknown */
+               safe_for_read(0xed),		/* drive specific, unknown */
+               safe_for_read(GPCMD_MODE_SELECT_10),
+               safe_for_read(GPCMD_READ_FORMAT_CAPACITIES),
+               safe_for_read(GPCMD_FLUSH_CACHE),
+               safe_for_read(GPCMD_SEND_OPC),
+               safe_for_read(GPCMD_BLANK),
+               safe_for_read(GPCMD_WRITE_10),
+               safe_for_read(GPCMD_FORMAT_UNIT),
+               safe_for_read(GPCMD_SEND_CUE),
+               safe_for_read(0xf5),		/* drive specific, unknown */
+               safe_for_read(GPCMD_READ_BUFFER_CAPACITY),
+               safe_for_read(GPCMD_CLOSE_TRACK),



-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> You can also erase the drive firmware as a user etc. That's the problem.

This is definitely not a "hot" problem so there is absolutely no reason to 
make incompatible changes in the kernel interface _without_ discussing this
with the most important users before.

On a decently administrated Linux system, only root is able to send SCSI 
commands because only root is able to open the apropriate /dev/* entries.

cdrecord is designed to be safely installed root and cdrecord is trustworthy - 
it does not overwrite the drive's firmware.

pxupgrade is not intended to be installed suid root, but _even_ _if_ someone
does, it will not allow you to write a file that has not been verifed to be
valid firmware for the drive in question.

> As a security fix it was sufficiently important that it had to be done.

You completely missimterpret importance :-(

Conclusion: What Linux-2.6.8 implement is a bug :-(

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Gwe, 2004-08-20 at 12:51, Joerg Schilling wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > You can also erase the drive firmware as a user etc. That's the problem.
> 
> This is definitely not a "hot" problem so there is absolutely no reason to 
> make incompatible changes in the kernel interface _without_ discussing this
> with the most important users before.

It becomes a hot problem they second someone posts the example code to
bugtraq.

> On a decently administrated Linux system, only root is able to send SCSI 
> commands because only root is able to open the apropriate /dev/* entries.

Wrong (as usual)

> cdrecord is designed to be safely installed root and cdrecord is trustworthy - 
> it does not overwrite the drive's firmware.

Running cdrecord setuid may well be the right approach. It can drop
capabilities except CAP_SYS_RAWIO and burn cdroms happily.

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > On a decently administrated Linux system, only root is able to send SCSI 
> > commands because only root is able to open the apropriate /dev/* entries.
>
> Wrong (as usual)

Useless as usual :-(

If you like to make useful contributions to a discussion, try to be serious and
either explain what you mean or just asume that nobody will believe you.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Gwe, 2004-08-20 at 15:11, Joerg Schilling wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > > On a decently administrated Linux system, only root is able to send SCSI 
> > > commands because only root is able to open the apropriate /dev/* entries.
> >
> > Wrong (as usual)
> 
> Useless as usual :-(

Unlike you I spend some of my time looking at large real world Linux
installations.

*Plonk*

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Gwe, 2004-08-20 at 15:11, Joerg Schilling wrote:
> > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > 
> > > > On a decently administrated Linux system, only root is able to send SCSI 
> > > > commands because only root is able to open the apropriate /dev/* entries.
> > >
> > > Wrong (as usual)
> > 
> > Useless as usual :-(
>
> Unlike you I spend some of my time looking at large real world Linux
> installations.

So you just like to tell us that you have no clue?

If the owners and permissions of the filesystem have been set up correctly,
then there is no security problem. 

As there is no problem in the kernel, why change the kernel?

The modification only breaks compatibility and causes trusted applications
like cdrtools to fail if installed suid root.

The change _only_ affects programs that open the /dev/ nodes with euid root
and later revert to a different user id. 

Programs that do not run with euid root cannot open the /dev/ nodes if owner
and permissions have been set up correctly.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Your mail was not delivered.
>
> Reason: entry found in the distributed idiots database

You repeatedly not send useful replies.

So either you are missing technical competence, you are missing the needed
discussion culture or you are a troll that has fun with stealing other people's 
time.

Either become reasonable or be pepared to be treated as a troll.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[V13]

On Thursday 19 August 2004 10:04, Patrick McFarland wrote:
> On Wed, 4 Aug 2004 14:33:09 +0200 (MET DST), H.Rosmanith (Kernel
>
> Mailing List) <kernel@wildsau.enemy.org> wrote:
> > Some stuff that started a flamewar.
>
> If no one has noticed yet, thanks to the additional license
> restrictions Joerg Schilling has added to cdrecord (due to this
> thread), it may be now moved to non-free in Debian in the near future.

I believe you're talking about those two comments:

/*
 * Begin restricted code for quality assurance.
 *
 * Warning: you are not allowed to modify or to remove the
 * Copyright and version printing code below!
 * See also GPL § 2 subclause c)
 *
 * If you modify cdrecord you need to include additional version
 * printing code that:
 *
 *      -       Clearly states that the current version is an
 *              inofficial (modified) version and thus may have bugs
 *              that are not present in the original.
 *
 *      -       Print your support e-mail address and tell people that
 *              you will do complete support for this version of
 *              cdrecord.
 *
 *              Or clearly state that there is absolutely no support
 *              for the modified version you did create.
 *
 *      -       Tell the users not to ask the original author for
 *              help.
 *
 * This limitation definitely also applies when you use any other
 * cdrecord release together with libscg-0.6 or later, or when you
 * use any amount of code from cdrecord-1.11a17 or later.
 * In fact, it applies to any version of cdrecord, see also
 * GPL Preamble, subsection 6.
 *
 * I am sorry for the inconvenience but I am forced to do this because
 * some people create inofficial branches. These branches create
 * problems but the initiators do not give support and thus cause the
 * development of the official cdrecord versions to slow down because
 * I am loaded with unneeded work.
 *
 * Please note that this is a memorandum on how I interpret the GPL.
 * If you use/modify/redistribute cdrecord, you need to accept it
 * this way.
 *
 *
 * The above statement is void if there has been neither a new version
 * of cdrecord nor a new version of star from the original author
 * within more then a year.
 */

open_cdrdefaults()
{
  /*
   * WARNING you are only allowed to change this filename if you also
   * change the documentation and add a statement that makes clear
   * where the official location of the file is why you did choose a
   * nonstandard location and that the nonstandard location only refers
   * to inofficial cdrecord versions.
   *
   * I was forced to add this because some people change cdrecord without
   * rational reason and then publish the result. As those people
   * don't contribute work and don't give support, they are causing extra
   * work for me and this way slow down the cdrecord development.
   */
   return (defltopen("/etc/default/cdrecord"));
}

I think he is partialy right, since noone should claim that the original 
author will support his modified versions. I don't know if this is compatible 
with GPL but, (if not) it can be rephrased sto that it will not limit 
redistribution or modifications of the program. 

Noone wants to provide support for modified versions of his programs (Lets say 
tainted kernels).

<<V13>>

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Wed, 4 Aug 2004 14:33:09 +0200 (MET DST), H.Rosmanith (Kernel
Mailing List) <kernel@wildsau.enemy.org> wrote:
> Some stuff that ended up reminding the community how much Joerg is an ass.

For those that really dislike Joerg: http://www.cafepress.com/mjg59.13063296

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989