PATCH: cdrecord: avoiding scsi device numbering for ide devices

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.

GNU make alleged of "bug" (was: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Matthias Andree]

On Thu, 19 Aug 2004, Gene Heskett wrote:

> Humm, I got many many losses of header stuff messages from:
> [root@coyote cdrecord]# make --version
> GNU Make 3.80

The "bug" is not specific to GNU make 3.80 but can also be seen in
3.78.1 for instance.

The "bug" however is purely cosmetical.

GNU make writes a message that an "include" file is missing, but it
finds it has a rule, generates the include file, pulls it in and
continues as though the file had always been there.

For instance if you have this Makefile:

# BEGIN Makefile
all:    hello
hello.d:
        makedepend -f- hello.c >$@
include hello.d
# END Makefile

You'll get at "make" time:

Makefile:5: hello.d: No such file or directory
makedepend -f- hello.c >hello.d
cc   hello.o   -o hello

and a working hello program.

Jörg's complaints about GNU make aren't false but aren't helpful either
and certainly don't warrant waiting 15 seconds after that message.

There is no bug, just this confusing "Makefile:5: hello.d: No such file
or directory".

> So apparently 3.80 is a regression in this case.

No, it isn't.

-- 
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: GNU make alleged of "bug" (was: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Sam Ravnborg]

On Thu, Aug 19, 2004 at 09:47:24PM +0200, Matthias Andree wrote:
> # BEGIN Makefile
> all:    hello
> hello.d:
>         makedepend -f- hello.c >$@
> include hello.d
> # END Makefile
> 
> You'll get at "make" time:
> 
> Makefile:5: hello.d: No such file or directory
> makedepend -f- hello.c >hello.d
> cc   hello.o   -o hello
> 
> and a working hello program.

Using:
-include hello.d
will result in a silent make.

	Sam

Re: GNU make alleged of "bug" (was: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Matthias Andree]

On Fri, 20 Aug 2004, Sam Ravnborg wrote:

> On Thu, Aug 19, 2004 at 09:47:24PM +0200, Matthias Andree wrote:
> > # BEGIN Makefile
> > all:    hello
> > hello.d:
> >         makedepend -f- hello.c >$@
> > include hello.d
> > # END Makefile
> > 
> > You'll get at "make" time:
> > 
> > Makefile:5: hello.d: No such file or directory
> > makedepend -f- hello.c >hello.d
> > cc   hello.o   -o hello
> > 
> > and a working hello program.
> 
> Using:
> -include hello.d
> will result in a silent make.

Indeed it will. However, Solaris' /usr/ccs/bin/make doesn't understand
the "-include" form:

make: Fatal error in reader: Makefile, line 5: Unexpected end of line seen

include without leading "-" is fine. BSD make doesn't understand either
form.

Jörg, how about Sam's suggestion? It seems compatible with smake.

-- 
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: GNU make alleged of "bug" (was: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Joerg Schilling]

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

> > Using:
> > -include hello.d
> > will result in a silent make.
>
> Indeed it will. However, Solaris' /usr/ccs/bin/make doesn't understand
> the "-include" form:
>
> make: Fatal error in reader: Makefile, line 5: Unexpected end of line seen
>
> include without leading "-" is fine. BSD make doesn't understand either
> form.
>
> J?rg, how about Sam's suggestion? It seems compatible with smake.

-include does not work with Sun's make and it does not cure the bug in GNU make
but hides it only.

GNU make just violates the unwritten "golden rule" for all make programs:

	If you like to "use" anything, first check whether you have a rule
	that could make the file in question.

For makefiles on the Command Line, GNU make follows this rule. If you are in an 
empty directory and call "gmake", GNU make will first try if "Makefile" or 
"makefile" could be retrieved using e.g. "sccs get Makefile" before GNU make 
tries to read the file.

For makefiles that appear as argument to an include statement, GNU make ingnores
this rule. GNU make instead, later (too late) executes the rule set and creates 
the missing files using known rules. In order to be able to do anything useful, 
GNU make then executes "exec gmake <old arg list>" after it is done with 
executing the rules. This is complete nonsense.

Smake works this way:

-	if it is going to "include" a file, it checks whether there is a rule 
	to make the file that is going to be included.

-	If the file has been "made", smake includes the file.

-	After including the file, smake clears the "has been made already" 
	cache flags for the included file.

-	After all make files and all recursive include rules have been made and 
	included, smake checks all rules again. This may result in rare cases 
	that the rule for one of the the include file is executed again.

As you noe see that GNU make behaves inconsistent, I hope you believe me that 
there is a bug in GNU make that should be fixed.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  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: GNU make alleged of "bug" (was: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Sam Ravnborg]

On Fri, Aug 20, 2004 at 12:31:12AM +0200, Joerg Schilling wrote:
 
> -include does not work with Sun's make and it does not cure the bug in GNU make
> but hides it only.
> 
> GNU make just violates the unwritten "golden rule" for all make programs:
> 
> 	If you like to "use" anything, first check whether you have a rule
> 	that could make the file in question.
> 
> For makefiles on the Command Line, GNU make follows this rule. If you are in an 
> empty directory and call "gmake", GNU make will first try if "Makefile" or 
> "makefile" could be retrieved using e.g. "sccs get Makefile" before GNU make 
> tries to read the file.
> 
> For makefiles that appear as argument to an include statement, GNU make ingnores
> this rule. GNU make instead, later (too late) executes the rule set and creates 
> the missing files using known rules. In order to be able to do anything useful, 
> GNU make then executes "exec gmake <old arg list>" after it is done with 
> executing the rules. This is complete nonsense.
> 
> Smake works this way:
> 
> -	if it is going to "include" a file, it checks whether there is a rule 
> 	to make the file that is going to be included.
> 
> -	If the file has been "made", smake includes the file.
> 
> -	After including the file, smake clears the "has been made already" 
> 	cache flags for the included file.
> 
> -	After all make files and all recursive include rules have been made and 
> 	included, smake checks all rules again. This may result in rare cases 
> 	that the rule for one of the the include file is executed again.
> 
> As you noe see that GNU make behaves inconsistent, I hope you believe me that 
> there is a bug in GNU make that should be fixed.

Please post this on the make-bug list then.

	Sam

Re: GNU make alleged of "bug" (was: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Andreas Schwab]

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

> On Fri, 20 Aug 2004, Sam Ravnborg wrote:
>
>> Using:
>> -include hello.d
>> will result in a silent make.
>
> Indeed it will. However, Solaris' /usr/ccs/bin/make doesn't understand
> the "-include" form:
>
> make: Fatal error in reader: Makefile, line 5: Unexpected end of line seen
>
> include without leading "-" is fine. BSD make doesn't understand either
> form.

What about sinclude?

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: GNU make alleged of "bug" (was: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Tonnerre]

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

Salut,

On Thu, Aug 19, 2004 at 10:53:01PM +0200, Matthias Andree wrote:
> include without leading "-" is fine. BSD make doesn't understand either
> form.

They got .include IIRC

			    Tonnerre

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

Re: GNU make alleged of "bug" (was: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Lee Revell]

On Fri, 2004-08-20 at 12:15, Tonnerre wrote:
> Salut,
> 
> On Thu, Aug 19, 2004 at 10:53:01PM +0200, Matthias Andree wrote:
> > include without leading "-" is fine. BSD make doesn't understand either
> > form.
> 
> They got .include IIRC
> 

Does anyone actually use BSD make?  gmake is your friend...

Lee

Re: GNU make alleged of "bug" (was: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Joerg Schilling]

>Tonnerre <tonnerre@thundrix.ch> wrote:


>On Thu, Aug 19, 2004 at 10:53:01PM +0200, Matthias Andree wrote:
>> include without leading "-" is fine. BSD make doesn't understand either
>> form.

>They got .include IIRC

They document .include but they also implement include.

BTW: For many years, the main problem with BSD make has been that it did not
implement pattern matching macro expansions (introduced ~ 1986 by Sun) correctly.
This year, I did fix this together with BSD people.

Unfortunately, later it turned out that BSD make handles path names to files
completely different from other make files.

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: GNU make alleged of "bug" (was: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Gene Heskett]

On Thursday 19 August 2004 15:47, Matthias Andree wrote:
>On Thu, 19 Aug 2004, Gene Heskett wrote:
>> Humm, I got many many losses of header stuff messages from:
>> [root@coyote cdrecord]# make --version
>> GNU Make 3.80
>
>The "bug" is not specific to GNU make 3.80 but can also be seen in
>3.78.1 for instance.
>
>The "bug" however is purely cosmetical.
>
>GNU make writes a message that an "include" file is missing, but it
>finds it has a rule, generates the include file, pulls it in and
>continues as though the file had always been there.
>
>For instance if you have this Makefile:
>
># BEGIN Makefile
>all:    hello
>hello.d:
>        makedepend -f- hello.c >$@
>include hello.d
># END Makefile
>
>You'll get at "make" time:
>
>Makefile:5: hello.d: No such file or directory
>makedepend -f- hello.c >hello.d
>cc   hello.o   -o hello
>
>and a working hello program.
>
>Jörg's complaints about GNU make aren't false but aren't helpful
> either and certainly don't warrant waiting 15 seconds after that
> message.
>
Agreed.  Maybe he thinks those of us who speak english still need that 
long to deciher what he thinks is english but in reality reminds me 
of engrish.com, just a different language for a starting point.  I 
can get the meaning in 3 seconds, but to fully read it, and translate 
it into real english takes all of that 15 seconds.  Sigh.

>There is no bug, just this confusing "Makefile:5: hello.d: No such
> file or directory".
>
>> So apparently 3.80 is a regression in this case.
>
>No, it isn't.

In light of that explanation, I can see why both Jorg is mewling about 
it, and that it really isn't worth his stepping on our tails over it.

Thanks.

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

Please no personal insults on this list (was: GNU make alleged of "bug")

[Matthias Andree]

On Thu, 19 Aug 2004, Gene Heskett wrote:

> Agreed.  Maybe he thinks those of us who speak english still need that 
> long to deciher what he thinks is english but in reality reminds me 
> of engrish.com, just a different language for a starting point.  I 
> can get the meaning in 3 seconds, but to fully read it, and translate 
> it into real english takes all of that 15 seconds.  Sigh.

Gene,

your mail, being a "publick speling flame", was outright insulting, and
I, not being a native speaker either, do see four misspellings and one
missing comma in the paragraph I quoted alone. (misspellings between
quote marks are intentional)

You ought to seriously and honestly reconsider whether you are in the
position to badmouth Jörg or the English he writes. His skill is
software development, and although we may not share his dogmatism or
user interface, his software is a valuable contribution
functionality-wise.

The discussion was about cdrecord, its interaction with the Linux
kernel, and drifted off into a discussion about a GNU make bug that I,
even in the light of Jörg's explanation, still consider rather
unimportant. Even differing views on certain topics should _not_ cause
ad-hominem attacks like yours was.

Even if I see that someone has difficulties with the language, that is
no reason to rub his nose in it.

Reply-To and Mail-Followup-To set to my mail address to
get this unfortunate discussion of the list so at least others can get
back to work.

O si tacuisses...

-- 
Matthias Andree

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