Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Robert Hancock]

Joerg Schilling wrote:
> There is no such bug in libscg.
> 
> There is nothing that has been freezed. 
> 
> If you have the apropriate privs to send SCSI commands to any SCSI device 
> on the system, you will not come across your problem.
> 
> Now let us try to talk about real problems or stop this discussion.

It appears that you are wanting to blame all of these problems on Linux 
and refuse to accept the possibility that cdrecord/libscg is doing 
things incorrectly from a Linux perspective. If you want to "talk about 
real problems" you must accept this possibility.

Why should I have to give privileges to send SCSI commands to any device 
  in the system just to write CDs? The answer, it would appear, is that 
cdrecord is messing with things (i.e. /dev/sg interface) it has no 
business messing with in current Linux systems, since that interface 
should not be necessary for the purpose of cdrecord.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Bartlomiej Zolnierkiewicz]

Hi,

I'm stealing thread in hope of stopping flamewar
and finally having some useful discussion.

I address this to everybody not only to Joerg:

[*] As this is my thread now discussing SG_IO on /dev/hd* vs /dev/sg*
is BANNED.  Please continue discussing this in the old thread. :-)

I'm sure thare are other important things that we can agree on.

If it doesn't work it will be my first and the last mail in this thread...

On 1/27/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Vojtech Pavlik <vojtech@suse.cz> wrote:
>
> > > The only integrative (and this useful for libscg) interface on Linux is /dev/sg*
> > >
> > > /dev/hd* may look nice if you only look skin-deep
> > >
> > > How do you e.g. like send SCSI commands to ATAPI tape drives on Linux?
> >
> > I see you asking this again and again, and you seem to want to hear this
> > answer: "You don't." I haven't checked the code, but I guess the SG_IO
> > interface isn't available there. And I don't think this is a problem,
> > because a) if it was needed, it can be added trivially with minimum
> > added code, b) ATAPI tapes are dead, much the way ATAPI floppies are.
>
> Nice to see that agree that sending SCSI via /dev/hd* is a hack with limited
> benefit.
>
> Maybe (now that we did agree about the way to go) it makes sense to start
> discussing which bugs in Linux need to be fixed in order to close e.g.
> the Bugs in the Debian bug tracking system for cdrtools that are related to the
> Linux kernel.

Yes, lets talk about other problems, do you have pointers bugs handy?
I'm not very familiar with Debian bug tracking system and I see there
more than 3 bugs for cdrtools.

> This are the three most important Linux kernel bugs:
>
> -       ide-scsi does not do DMA if the DMAsize is not a multiple of 512
>         A person who knows internal Linux structures shoule be able
>         to fix this (and allow any multiple of 4) in less than one hour.

I'll take a look, it should be quite easy
and I don't see a reason for this restriction.

>         If we sum up the time spend on this discussoion, I really cannot
>         understand why this has not been fixed earlier.

Because nobody cared and flamewaring is easy in contrast
to doing some real work.

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

What are the return values of SCSI_IOCTL_GET_IDLUN
and SCSI_IOCTL_GET_BUS_NUMBER needed for?

Please elaborate as:

* SG_IO ioctl doesn't require lun and bus number for arguments
* sg_io_hdr_t also doesn't contain/require these fields

so I simply cannot see why they are needed by kernel.

If lun and bus number are needed by cdrecord please explain why
(if only for enumerating devices sorry but see [*]).

> -       If sending SCSI sia ATAPI, Linux under certain unknown conditions
>         bastardizes the content of SCSI commands. A possible reason may be

Sorry but I can't do much about it without knowing more details.

Please provide some way to reproduce the problem
("certain unknown conditions" is not very useful).

>         that it sends random data in the remainder between the actual
>         SCSI cdb size and the ATAPI SCSI cdb size.

It should send 0-s but I'll recheck this.

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

Thanks,
Bartlomiej

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> I address this to everybody not only to Joerg:
>
> [*] As this is my thread now discussing SG_IO on /dev/hd* vs /dev/sg*
> is BANNED.  Please continue discussing this in the old thread. :-)

If we also bann discussions that try to claim cdrecord -scanbus is
unneeded or unwanted, no problem.

> > Maybe (now that we did agree about the way to go) it makes sense to start
> > discussing which bugs in Linux need to be fixed in order to close e.g.
> > the Bugs in the Debian bug tracking system for cdrtools that are related to the
> > Linux kernel.
>
> Yes, lets talk about other problems, do you have pointers bugs handy?
> I'm not very familiar with Debian bug tracking system and I see there
> more than 3 bugs for cdrtools.

There unfortunately are many "Bugs" on Debian.
Most of the "Bugs" are either realls Linux bugs or just caused by the
modifications done by the Debian people.

You would need to read the reports and it makes sense to look for comments from 
me.

> > This are the three most important Linux kernel bugs:
> >
> > -       ide-scsi does not do DMA if the DMAsize is not a multiple of 512
> >         A person who knows internal Linux structures shoule be able
> >         to fix this (and allow any multiple of 4) in less than one hour.
>
> I'll take a look, it should be quite easy
> and I don't see a reason for this restriction.

Testing could be done the following way:

-	insert a blank CD into your writer and do an initial test burn.

	sdd -inull bs=2352 of= test.raw count=75x60x74
	cdrecord dev=ATA:b,t,0 -audio -sao -v test.raw

	Remember the speed that should be > 40x
	Remember the system cpu time that should be less than 5% of the 
	wall clock time.

-	Repeat the same test with ide-scsi
	Make sure ide-scsi is usable fo the drive, then call

	cdrecord dev=b,t,0 -audio -sao -v test.raw

	If the max speed is lower than 30x or the system cpu time
	ich significant more than 5% of the wall closk time you do not
	use DMA.




> >         If we sum up the time spend on this discussoion, I really cannot
> >         understand why this has not been fixed earlier.
>
> Because nobody cared and flamewaring is easy in contrast
> to doing some real work.
>
> > -       /dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
> >         SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
> >         As long as this bug is present, there is no way to see SG_IO
> >         via /dev/hd* as integral part of the Linux SCSI transport concept.
>
> What are the return values of SCSI_IOCTL_GET_IDLUN
> and SCSI_IOCTL_GET_BUS_NUMBER needed for?
>
> Please elaborate as:
>
> * SG_IO ioctl doesn't require lun and bus number for arguments
> * sg_io_hdr_t also doesn't contain/require these fields
>
> so I simply cannot see why they are needed by kernel.
>
> If lun and bus number are needed by cdrecord please explain why
> (if only for enumerating devices sorry but see [*]).

Well it is obvious that the numbers are present inside Linux, otherwise
Linux could not return useful numbers in case that ide-scsi is used.
Note that we are talking about SCSI devices (in case the actual user
of libscg is cdrecord, we talk about CD/DVD writers).

If you read the Debian bug reports, you will find that many users are confused 
because cdrecord -scanbus will not list all possible devices.


> > -       If sending SCSI sia ATAPI, Linux under certain unknown conditions
> >         bastardizes the content of SCSI commands. A possible reason may be
>
> Sorry but I can't do much about it without knowing more details.

I am sorry, but as nobody was interested on this when it was possible 
to tell more it did has been fogotten.


> Please provide some way to reproduce the problem
> ("certain unknown conditions" is not very useful).

Well if I remember  correclty, then the problem does not occur in case you
use a Plextor drive. It may IIRC make sense to try to reproduce with Pioneer 
or NEC drives.

I believe the best way to allow to reproduce the problem would be to search the 
web or the Debian bugtracking for related error reports. Unfortunately Debian 
seems to be down.

"invalid field in cdb" is the related error code from the drive

and this is most likely a result of this bug:

http://lists.debian.org/debian-user-german/2003/10/msg00058.html

I made the experience with 'Read Full Toc' and "readcd" while trying to
do a clone read. But this is something you will most likely not be able to 
find on the web as the related error is hidden because this is not a mandatory
command in SCSI.



Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Jan Engelhardt]

>Testing could be done the following way:
>
>-	insert a blank CD into your writer and do an initial test burn.
>
>	sdd -inull bs=2352 of= test.raw count=75x60x74
>	cdrecord dev=ATA:b,t,0 -audio -sao -v test.raw
>
>	Remember the speed that should be > 40x

Does speed==40 also suffice?
How about a DVD at 8x speed? (Even faster than CD at 40x)



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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Matthias Andree]

Jan Engelhardt schrieb am 2006-01-29:

> Does speed==40 also suffice?
> How about a DVD at 8x speed? (Even faster than CD at 40x)

The block size of 2352 bytes (not a power of two and not a multiple of
512 either) is important.

Just check the CPU load. The machine is pretty crawling without DMA,
with high system and I/O wait figures. Even fast machines (Athlon XP
2500+) are hogged down so much the mouse pointer gets jerky.

-- 
Matthias Andree

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

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

> >Testing could be done the following way:
> >
> >-	insert a blank CD into your writer and do an initial test burn.
> >
> >	sdd -inull bs=2352 of= test.raw count=75x60x74
> >	cdrecord dev=ATA:b,t,0 -audio -sao -v test.raw
> >
> >	Remember the speed that should be > 40x
>
> Does speed==40 also suffice?

NO, speed==40 may be too slow as I cannot grant that it will
always fail with PIO and speed <=40.

In case that the clock rate of your CPU just fits nicely, it
may be that it by accident works.

> How about a DVD at 8x speed? (Even faster than CD at 40x)

This problem is not present with DVDs as they only support
virtual sector size == 2048.

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Jan Engelhardt]

Hi,


I just found that the followig "works" (cdrom drive not supported, but 
other than that seems fine) under Solaris 11 snv_30 x86, much to my 
surprise:

  cdrecord -dev=/dev/rdsk/c1t0d0p0 -toc

which worked just as well as

  cdrecord -dev=1,0,0 -toc

I would have rather expected to get

  Warning: Open by 'devname' is unintentional and not supported.



Jan Engelhardt
-- 

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

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

> I just found that the followig "works" (cdrom drive not supported, but 
> other than that seems fine) under Solaris 11 snv_30 x86, much to my 
> surprise:
>
>   cdrecord -dev=/dev/rdsk/c1t0d0p0 -toc
>
> which worked just as well as
>
>   cdrecord -dev=1,0,0 -toc
>
> I would have rather expected to get
>
>   Warning: Open by 'devname' is unintentional and not supported.

You are the first to try this unsupported dev parameter.

Fortunately, users on Solaris usually read the man pages before
doing wrong things and then it usually works....

Once I see to many people using this kind of CLI, I'll add a note.

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[René Rebe]

Hi,

On Monday 06 February 2006 17:29, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > I just found that the followig "works" (cdrom drive not supported, but 
> > other than that seems fine) under Solaris 11 snv_30 x86, much to my 
> > surprise:
> >
> >   cdrecord -dev=/dev/rdsk/c1t0d0p0 -toc
> >
> > which worked just as well as
> >
> >   cdrecord -dev=1,0,0 -toc
> >
> > I would have rather expected to get
> >
> >   Warning: Open by 'devname' is unintentional and not supported.
> 
> You are the first to try this unsupported dev parameter.
> 
> Fortunately, users on Solaris usually read the man pages before
> doing wrong things and then it usually works....
> 
> Once I see to many people using this kind of CLI, I'll add a note.

If I would not be in Berlin as well I would ask what good drugs there are to
smoke - heck - wait - there *is* over average drug dealing going along here ...

You still never ever explained *why* you think specifing devices by name
is so bad ...

Have you patched your schillix mount, fsck.* and co to take a pseudo
SCSI ID as well?

Start to get that _the_ interface to devices on Unix and a-like systems
are device nodes in /dev (or simillar) - not artificially made up IDs the
user has to find out for the system (or add -scanbus (or what it was)
to any program executed).

Still if _you_ do not like that, 99.999% of the Linux users and developers
_do_. So stop whining about it.

PS: Yes, I run a bastarized version of cdrecord that has a whole bunch of
crap patched away.

Have fun,

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
            http://www.exactcode.de | http://www.t2-project.org
            +49 (0)30  255 897 45

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Matthias Andree]

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

[Solaris cdrecord command]
>>   cdrecord -dev=/dev/rdsk/c1t0d0p0 -toc

> Once I see to many people using this kind of CLI, I'll add a note.

Still fighting both your users and the environment, eh?

Why do you want to enforce device enumeration on your users if it isn't
needed in the first place?

Your motives remain totally unclear, and look rather suicidal.

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-29:

> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > I address this to everybody not only to Joerg:
> >
> > [*] As this is my thread now discussing SG_IO on /dev/hd* vs /dev/sg*
> > is BANNED.  Please continue discussing this in the old thread. :-)
> 
> If we also bann discussions that try to claim cdrecord -scanbus is
> unneeded or unwanted, no problem.

The real issue is that the Linux kernel support for -scanbus looks
different than your blueprints. Looks as though the most promising
approach is to tell libscg about it, as annoying though it may be.

> Well it is obvious that the numbers are present inside Linux, otherwise
> Linux could not return useful numbers in case that ide-scsi is used.
> Note that we are talking about SCSI devices (in case the actual user
> of libscg is cdrecord, we talk about CD/DVD writers).

CD/DVD writers wtih SCSI interface have nearly died out.

> If you read the Debian bug reports, you will find that many users are confused 
> because cdrecord -scanbus will not list all possible devices.

That's what I believe to be cdrecord/libscg bugs:

1) libscg or cdrecord does not automatically probe all available
   transports, but only SCSI:

2) libscg or cdrecord aborts ATA: scans as soon as one device probe
   returns EPERM, which lets devices that resmgr made accessible
   disappear from the list.

-- 
Matthias Andree

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Jan Engelhardt]

>That's what I believe to be cdrecord/libscg bugs:
>
>1) libscg or cdrecord does not automatically probe all available
>   transports, but only SCSI:

This one is IMO just "a missing feature", as I can get the ATA/PI list using
  cdrecord -dev=ATA: -scanbus



Jan Engelhardt
-- 

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

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

> >That's what I believe to be cdrecord/libscg bugs:
> >
> >1) libscg or cdrecord does not automatically probe all available
> >   transports, but only SCSI:
>
> This one is IMO just "a missing feature", as I can get the ATA/PI list using
>   cdrecord -dev=ATA: -scanbus

It cannot be fixed unless the two first bugs from my Linux kernel
bug report have been fixed.

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Albert Cahalan]

On 1/29/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
> > >That's what I believe to be cdrecord/libscg bugs:
> > >
> > >1) libscg or cdrecord does not automatically probe all available
> > >   transports, but only SCSI:
> >
> > This one is IMO just "a missing feature", as I can get the ATA/PI list using
> >   cdrecord -dev=ATA: -scanbus
>
> It cannot be fixed unless the two first bugs from my Linux kernel
> bug report have been fixed.

Which, from an earlier email, were:

> ide-scsi does not do DMA if the DMAsize is not a
> multiple of 512 A person who knows internal Linux
> structures shoule be able to fix this (and allow
> any multiple of 4) in less than one hour.

and

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

Let's address the second bug first. Linux provides full
bus number and LUN info for all block devices. You get it
like this:

struct stat sbuf;
stat("/dev/hdc", &sbuf);
int bus = sbuf.st_mode>>12;
int target = major(sbuf.st_rdev);
int lun = minor(sbuf.st_rdev);

That makes as much sense as anything, and it lets you quickly
find back the device by scanning /dev.

As for ide-scsi, your right, it's horribly broken. We should
just get rid of it. If there is anything that the normal driver
is unable to do well, I'm sure you'll let us know.

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

Albert Cahalan <acahalan@gmail.com> wrote:

> Let's address the second bug first. Linux provides full
> bus number and LUN info for all block devices. You get it
> like this:
>
> struct stat sbuf;
> stat("/dev/hdc", &sbuf);
> int bus = sbuf.st_mode>>12;
> int target = major(sbuf.st_rdev);
> int lun = minor(sbuf.st_rdev);

Now tell me how to match this with information from /dev/sg*

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Albert Cahalan]

On 1/30/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Albert Cahalan <acahalan@gmail.com> wrote:
>
> > Let's address the second bug first. Linux provides full
> > bus number and LUN info for all block devices. You get it
> > like this:
> >
> > struct stat sbuf;
> > stat("/dev/hdc", &sbuf);
> > int bus = sbuf.st_mode>>12;
> > int target = major(sbuf.st_rdev);
> > int lun = minor(sbuf.st_rdev);
>
> Now tell me how to match this with information from /dev/sg*

You do the obvious, scanning /dev to find the device file.

You can map from names to numbers (like DNS does for IP) and
back from numbers to names (like reverse DNS does).

If you need to map from /dev/hd* to /dev/sg*, then you have
found a bug. Explain what must be added to /dev/hd* so that
you don't need to go messing with /dev/sg* anymore.

The name /dev/hd* is not the high-level interface. It's the device
name, used by both high-level and low-level interfaces. It alone
is the non-kernel way to refer to the device. (inside the kernel
you just get a pointer, and the dev_t assists in translation)

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

Albert Cahalan <acahalan@gmail.com> wrote:

> On 1/30/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > Albert Cahalan <acahalan@gmail.com> wrote:
> >
> > > Let's address the second bug first. Linux provides full
> > > bus number and LUN info for all block devices. You get it
> > > like this:
> > >
> > > struct stat sbuf;
> > > stat("/dev/hdc", &sbuf);
> > > int bus = sbuf.st_mode>>12;
> > > int target = major(sbuf.st_rdev);
> > > int lun = minor(sbuf.st_rdev);
> >
> > Now tell me how to match this with information from /dev/sg*
>
> You do the obvious, scanning /dev to find the device file.

I am sorry, but you obviously did not understand the problem.

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-30:

> Albert Cahalan <acahalan@gmail.com> wrote:
> 
> > On 1/30/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > > Albert Cahalan <acahalan@gmail.com> wrote:
> > >
> > > > Let's address the second bug first. Linux provides full
> > > > bus number and LUN info for all block devices. You get it
> > > > like this:
> > > >
> > > > struct stat sbuf;
> > > > stat("/dev/hdc", &sbuf);
> > > > int bus = sbuf.st_mode>>12;
> > > > int target = major(sbuf.st_rdev);
> > > > int lun = minor(sbuf.st_rdev);
> > >
> > > Now tell me how to match this with information from /dev/sg*
> >
> > You do the obvious, scanning /dev to find the device file.
> 
> I am sorry, but you obviously did not understand the problem.

Stop offending people who are trying to be helpful just because they
suggest different solutions than you expect. You - again - elided
Albert's crucial part, which even included an offer to fix things:

: If you need to map from /dev/hd* to /dev/sg*, then you have
: found a bug. Explain what must be added to /dev/hd* so that
: you don't need to go messing with /dev/sg* anymore.

-- 
Matthias Andree

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

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

> > > > > struct stat sbuf;
> > > > > stat("/dev/hdc", &sbuf);
> > > > > int bus = sbuf.st_mode>>12;
> > > > > int target = major(sbuf.st_rdev);
> > > > > int lun = minor(sbuf.st_rdev);
> > > >
> > > > Now tell me how to match this with information from /dev/sg*
> > >
> > > You do the obvious, scanning /dev to find the device file.
> > 
> > I am sorry, but you obviously did not understand the problem.
>
> Stop offending people who are trying to be helpful just because they
> suggest different solutions than you expect. You - again - elided
> Albert's crucial part, which even included an offer to fix things:

I am sorry to see your recent dicussion style.

I was asking a question and I did get a completely useless answer as
any person who has some basic know how Linux SCSI would know that
doing a stat("/dev/sg*", ...) will not return anything useful.

If people give useful answers, it makes sense to continue a discussion but it 
turns out that "joe average" on KLML replies before thinking about the problem. 

Let me ask again:

	Is there a way to get (or construct) a closed view on the namespace 
	for all SCSI devices?


And IMPORTANT: don't answer unless you have a real answer for the problem.

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-30:

> Let me ask again:
> 
> 	Is there a way to get (or construct) a closed view on the namespace 
> 	for all SCSI devices?

Of course there is, /dev/sg*.

But that is not what you're _actually_ asking - you appear to desire a
unified namespace for SCSI + ATAPI + whatever, and the answer to that
was /dev/*.

Asking questions doesn't always turn up the answers one has expected...

-- 
Matthias Andree

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-01-30:
>
> > Let me ask again:
> > 
> > 	Is there a way to get (or construct) a closed view on the namespace 
> > 	for all SCSI devices?
>
> Of course there is, /dev/sg*.
>
> But that is not what you're _actually_ asking - you appear to desire a
> unified namespace for SCSI + ATAPI + whatever, and the answer to that
> was /dev/*.

I am only asking for a unique name space for all devices that talk SCSI.

And please: read the SCSI Standard on t10.org to learn that ATA is just one
of many possible SCSI transports.

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-30:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > Joerg Schilling schrieb am 2006-01-30:
> >
> > > Let me ask again:
> > > 
> > > 	Is there a way to get (or construct) a closed view on the namespace 
> > > 	for all SCSI devices?
> >
> > Of course there is, /dev/sg*.
> >
> > But that is not what you're _actually_ asking - you appear to desire a
> > unified namespace for SCSI + ATAPI + whatever, and the answer to that
> > was /dev/*.
> 
> I am only asking for a unique name space for all devices that talk SCSI.

That is not the same.

> And please: read the SCSI Standard on t10.org to learn that ATA is just one
> of many possible SCSI transports.

The t10.org front page mentions ATAPI links, and the links section leads
to t13.org for ATAPI. And now?

Besides that, Linux is not currently implemented to make everybody and
their dog look like SPI with ID, LUN and everything, and until now you
have not presented anything but phantoms (such as ATAPI tapes) to
support your point why it should do that. No wonder people are losing
interest in the discussion if you don't even answer questions what the
current Linux interface don't give you, and you haven't seriously
responded to my suggestion to simply scan all transports in libscg, for
instance, "" (sg+pg), ATA:, ATAPI, RSCSI:.

-- 
Matthias Andree

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[James Courtier-Dutton]

Joerg Schilling wrote:
> 
> I am only asking for a unique name space for all devices that talk SCSI.
> 

Why do you need to ask this question of the operating system.
Surely more suitable questions are:
Where are the CD writing devices?
Where is the user's preferred CD writing device?

Surely you don't care if there is a scsi tape drive or scsi hard disk on 
the SCSI bus. Don't you only care about CD writing devices?

James

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Andreas Jellinghaus]

Joerg Schilling wrote:
> I am only asking for a unique name space for all devices that talk SCSI.
> 
> And please: read the SCSI Standard on t10.org to learn that ATA is just
> one of many possible SCSI transports.

why do you need it? if you were fine with all cd bunners and dvd burners,
you could use /dev/{cdrw,dvdrw}*. if you also want the dvd device and cd
devices, have a look at /dev/cdrom* and /dev/dvd*. note: you need
to sort out duplicates yourself, for example my laptop has one dvd writer
and thus it shows up as cdrom, cdrw, dvd and dvdrw.

the obvious answer to your question would be: there is none.
as far as I understand the kernel developers, the real answer is:
you application should not need that.

Regards, Andreas

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Phillip Susi]

Joerg Schilling wrote:
> I am sorry to see your recent dicussion style.
>
> I was asking a question and I did get a completely useless answer as
> any person who has some basic know how Linux SCSI would know that
> doing a stat("/dev/sg*", ...) will not return anything useful.
>   

It certainly does return something useful, just not what you are looking 
for.  It does not return information that allows you to cleanly build 
your bus:device:lun view of the world, but it does return sufficient 
information to enumerate and communicate with all devices in the 
system.  Is that not sufficient to be able to implement cdrecord?  If it 
is, then the real issue here is that you want Linux to conform to the 
bus:device:lun world view, which it seems many people do not wish to do. 

Maybe it would be more constructive if you were to make a good argument 
for why the bus:device:lun view is better than /dev/*, but right now it 
seems to me that they are just two different ways of doing the same 
thing, and you prefer one way while the rest of the Linux developers 
prefer the other. 
> If people give useful answers, it makes sense to continue a discussion but it 
> turns out that "joe average" on KLML replies before thinking about the problem. 
>
> Let me ask again:
>
> 	Is there a way to get (or construct) a closed view on the namespace 
> 	for all SCSI devices?
>
>
> And IMPORTANT: don't answer unless you have a real answer for the problem.
>
> Jörg
>
>   

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

Phillip Susi <psusi@cfl.rr.com> wrote:

> Joerg Schilling wrote:
> > I am sorry to see your recent dicussion style.
> >
> > I was asking a question and I did get a completely useless answer as
> > any person who has some basic know how Linux SCSI would know that
> > doing a stat("/dev/sg*", ...) will not return anything useful.
> >   
>
> It certainly does return something useful, just not what you are looking 
> for.  It does not return information that allows you to cleanly build 
> your bus:device:lun view of the world, but it does return sufficient 
> information to enumerate and communicate with all devices in the 
> system.  Is that not sufficient to be able to implement cdrecord?  If it 
> is, then the real issue here is that you want Linux to conform to the 
> bus:device:lun world view, which it seems many people do not wish to do. 

It does not allow libscg to find all devices.

> Maybe it would be more constructive if you were to make a good argument 
> for why the bus:device:lun view is better than /dev/*, but right now it 
> seems to me that they are just two different ways of doing the same 
> thing, and you prefer one way while the rest of the Linux developers 
> prefer the other. 

It would help if someone would give arguments why Linux does treat all 
SCSI devices equal, except for ATAPI transport based ones.

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-31:

> > It certainly does return something useful, just not what you are looking 
> > for.  It does not return information that allows you to cleanly build 
> > your bus:device:lun view of the world, but it does return sufficient 
> > information to enumerate and communicate with all devices in the 
> > system.  Is that not sufficient to be able to implement cdrecord?  If it 
> > is, then the real issue here is that you want Linux to conform to the 
> > bus:device:lun world view, which it seems many people do not wish to do. 
> 
> It does not allow libscg to find all devices.

On my system,

sudo cdrecord -scanbus ; \
sudo cdrecord -scanbus dev=ATA:

finds all devices that talk ATAPI, SCSI, MMC.

> > Maybe it would be more constructive if you were to make a good argument 
> > for why the bus:device:lun view is better than /dev/*, but right now it 
> > seems to me that they are just two different ways of doing the same 
> > thing, and you prefer one way while the rest of the Linux developers 
> > prefer the other. 
> 
> It would help if someone would give arguments why Linux does treat all 
> SCSI devices equal, except for ATAPI transport based ones.

1a The question is rather, what is the reason that you claim libscg is
allegedly unable to find all devices?

  1b Not scanning all of the devices perhaps?

  1c Not asking the right enumeration interface perhaps?

2 And what devices are actually missing?
Name tangible devices or groups, not phantoms that no-one uses.

3 Why does libscg need to care at all which kernel driver provides SG_IO?
The device node give access to the target the user desires. Add serial
number listing to -scanbus to make those happy that have several drives
of the same brand and model.

4 Why have you not yet responded to the suggestion to use freedesktop.org
HAL to enumerate devices?

Summarizing past discussions, it appears as though you have not
presented sufficiently substantiated arguments to prove libscg is
actually missing out on device, and not sufficient evidence to convince
kernel developers to CHANGE things.

The same way as you want them to justify their using device nodes
instead bus:id:lun to map everything into a narrow namespace, they can
make you justify your request. Fact is that cdrecord+libscg appear to
work well enough so that nobody wants to care about theoretical gaps
that have no practical impact.

And given that libscg's namespace is already transport:bus:id:lun which
comprises /dev/hd* and /dev/sg* so nicely that CD writing works today,
it seems hard to justify changes beyond 1. removing irritating warnings
from cdrecord/libscg, 2. making libscg actually scan all transports and
not just one when looking for devices.

It is pretty clear now that the Linux kernel developers do not care if
your application bitches at users because you don't like a particular
interface.

-- 
Matthias Andree

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Bill Davidsen]

Joerg Schilling wrote:
> Phillip Susi <psusi@cfl.rr.com> wrote:
> 
> 
>>Joerg Schilling wrote:
>>
>>>I am sorry to see your recent dicussion style.
>>>
>>>I was asking a question and I did get a completely useless answer as
>>>any person who has some basic know how Linux SCSI would know that
>>>doing a stat("/dev/sg*", ...) will not return anything useful.
>>>  
>>
>>It certainly does return something useful, just not what you are looking 
>>for.  It does not return information that allows you to cleanly build 
>>your bus:device:lun view of the world, but it does return sufficient 
>>information to enumerate and communicate with all devices in the 
>>system.  Is that not sufficient to be able to implement cdrecord?  If it 
>>is, then the real issue here is that you want Linux to conform to the 
>>bus:device:lun world view, which it seems many people do not wish to do. 
> 
> 
> It does not allow libscg to find all devices.
> 
> 
>>Maybe it would be more constructive if you were to make a good argument 
>>for why the bus:device:lun view is better than /dev/*, but right now it 
>>seems to me that they are just two different ways of doing the same 
>>thing, and you prefer one way while the rest of the Linux developers 
>>prefer the other. 
> 
> 
> It would help if someone would give arguments why Linux does treat all 
> SCSI devices equal, except for ATAPI transport based ones.

That's a fair question, which I asked in a seperate thread. Everything 
in the system which looks like a block device, tape or optical device 
looks like SCSI except ATAPI.

However, as my mother used to say "those are the conditions which 
prevail," so perhaps it's time to accept it and move on.

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Tejun Heo]

Joerg Schilling wrote:
> Phillip Susi <psusi@cfl.rr.com> wrote:
> 
> 
>>Joerg Schilling wrote:
>>
>>>I am sorry to see your recent dicussion style.
>>>
>>>I was asking a question and I did get a completely useless answer as
>>>any person who has some basic know how Linux SCSI would know that
>>>doing a stat("/dev/sg*", ...) will not return anything useful.
>>>  
>>
>>It certainly does return something useful, just not what you are looking 
>>for.  It does not return information that allows you to cleanly build 
>>your bus:device:lun view of the world, but it does return sufficient 
>>information to enumerate and communicate with all devices in the 
>>system.  Is that not sufficient to be able to implement cdrecord?  If it 
>>is, then the real issue here is that you want Linux to conform to the 
>>bus:device:lun world view, which it seems many people do not wish to do. 
> 
> It does not allow libscg to find all devices.
> 
>>Maybe it would be more constructive if you were to make a good argument 
>>for why the bus:device:lun view is better than /dev/*, but right now it 
>>seems to me that they are just two different ways of doing the same 
>>thing, and you prefer one way while the rest of the Linux developers 
>>prefer the other. 
> 
> It would help if someone would give arguments why Linux does treat all 
> SCSI devices equal, except for ATAPI transport based ones.
> 

Mostly historic, I guess.  When IDE drivers first got implemented, ATAPI 
wasn't really considered thoroughly and later when generic SCSI command 
support became necessary it was added by bridging ATAPI devices over to 
SCSI using ide-scsi.  People didn't like ide-scsi very much for good 
reasons - special boot parameter, confusing, needed full SCSI stack 
etc...  So, the hd SG_IO came.

And, yes, hd SG_IO has certain drawbacks as you pointed out.  No generic 
command to tape device (as no generic IDE device exists), not an 
integral part of SCSI subsystem and might even contain some new bugs as 
it's different new (well, was) code base.  Yet, people in general seem 
to find the change more beneficial and I personally like the change too.

ide-scsi is obsolete now.  Going back to it just won't happen and as I 
just said, yeah, some good stuff was lost in the process but others are 
gained, so please accept it - there is no central repository of SCSI 
command aware devices on Linux, at least at the moment.  It might happen 
in time but *currently* there is none.  I also think it would be better 
to have one but, hey, that's how the current state is and it will take 
quite some amount of work and time to implement that correctly.

So, let's meet somewhere inbetween.  Reserving a SCSI bus number for 
ATAPI devices and generating ID/LUN for SG_IO devices isn't very 
difficult and probably a good thing to have.  So, unfortunately, we 
won't have pretty /dev/sg* for all SCSI-aware devices, but you only have 
to scan limited number of devices - /dev/sg* and /dev/hd*.

How does that sound?

-- 
tejun

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

Tejun Heo <htejun@gmail.com> wrote:

> So, let's meet somewhere inbetween.  Reserving a SCSI bus number for 
> ATAPI devices and generating ID/LUN for SG_IO devices isn't very 
> difficult and probably a good thing to have.  So, unfortunately, we 
> won't have pretty /dev/sg* for all SCSI-aware devices, but you only have 
> to scan limited number of devices - /dev/sg* and /dev/hd*.

libscg already has to deal with this kind of problems (see /dev/pg*).

You can't add work arounds ad nauseum.

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Bill Davidsen]

Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> 
>>>That's what I believe to be cdrecord/libscg bugs:
>>>
>>>1) libscg or cdrecord does not automatically probe all available
>>>  transports, but only SCSI:
>>
>>This one is IMO just "a missing feature", as I can get the ATA/PI list using
>>  cdrecord -dev=ATA: -scanbus
> 
> 
> It cannot be fixed unless the two first bugs from my Linux kernel
> bug report have been fixed.

Since we are making an effort to be civil, perhaps you might call these 
"characteristics" instead of bugs. Generally "bug" refers to an 
unintended behaviour, rather than an intended behaviour which may not be 
optimal.

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

Bill Davidsen <davidsen@tmr.com> wrote:

> Since we are making an effort to be civil, perhaps you might call these 
> "characteristics" instead of bugs. Generally "bug" refers to an 
> unintended behaviour, rather than an intended behaviour which may not be 
> optimal.

If you are talking about the DMA problem, this should be calle a bug as
the same problem has been fixed elsewhere.

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

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

> 2) libscg or cdrecord aborts ATA: scans as soon as one device probe
>    returns EPERM, which lets devices that resmgr made accessible
>    disappear from the list.

looks like your memory does not last long enough......

We did already discuss this before. If you call cdrecord with
apropriatr privileges, it works.


Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-30:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > 2) libscg or cdrecord aborts ATA: scans as soon as one device probe
> >    returns EPERM, which lets devices that resmgr made accessible
> >    disappear from the list.
> 
> looks like your memory does not last long enough......
> 
> We did already discuss this before. If you call cdrecord with
> apropriatr privileges, it works.

Well, if you're freezing the bugs, I don't see how there could be
progress towards a non-root cdrecord on Linux.

-- 
Matthias Andree

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Joerg Schilling]

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

> > > 2) libscg or cdrecord aborts ATA: scans as soon as one device probe
> > >    returns EPERM, which lets devices that resmgr made accessible
> > >    disappear from the list.
> > 
> > looks like your memory does not last long enough......
> > 
> > We did already discuss this before. If you call cdrecord with
> > apropriatr privileges, it works.
>
> Well, if you're freezing the bugs, I don't see how there could be
> progress towards a non-root cdrecord on Linux.

There is no such bug in libscg.

There is nothing that has been freezed. 

If you have the apropriate privs to send SCSI commands to any SCSI device 
on the system, you will not come across your problem.

Now let us try to talk about real problems or stop this discussion.

Jörg

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

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Pavel Machek]

On Po 30-01-06 18:15:49, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > > > 2) libscg or cdrecord aborts ATA: scans as soon as one device probe
> > > >    returns EPERM, which lets devices that resmgr made accessible
> > > >    disappear from the list.
> > > 
> > > looks like your memory does not last long enough......
> > > 
> > > We did already discuss this before. If you call cdrecord with
> > > apropriatr privileges, it works.
> >
> > Well, if you're freezing the bugs, I don't see how there could be
> > progress towards a non-root cdrecord on Linux.
> 
> There is no such bug in libscg.
> 
> There is nothing that has been freezed. 
> 
> If you have the apropriate privs to send SCSI commands to any SCSI device 
> on the system, you will not come across your problem.

Why should I need privs to talk to *any* SCSI device, when I want to
talk to just *one* SCSI device?

Yes, it is a missing feature in libscg. It requires priviledge to talk
to *any* device, while is only really needs to talk to *one* device.

[Imagine ls that only worked if it had priviledges for reading
/etc/shadow. That would surely be bug.]
								Pavel

-- 
Thanks, Sharp!

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Jan Engelhardt]

>> 
>> If you have the apropriate privs to send SCSI commands to any SCSI device 
>> on the system, you will not come across your problem.
>
>Why should I need privs to talk to *any* SCSI device, when I want to
>talk to just *one* SCSI device?
>

Because of the (drumroll...) -scanbus thing everyone wants!



Jan Engelhardt
-- 

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Patrick McFarland]

On Sunday 29 January 2006 06:01, Joerg Schilling wrote:
> Danger: Highly Flammable Material. <!>

I formally request that Joerg Schilling be banned from the LKML until he 
learns how to take bugs in his program seriously. cdrecord has bugs, people 
hit them, and he won't either fix the bugs, or hand maintainership over to 
someone who wants to fix them.

Not only that, he constantly trolls on the LKML about how awesome cdrecord is, 
and how stupid kernel developers are. He also rears his head in any 
discussion on CD burning under Linux, even though it not always has anything 
to do with cdrecord; and totally derails any such discussion.

In addition to the aforementioned problems, he also has a serious hate for 
Debian, and the Debian developers who maintain the cdrecord package; in 
addition, he has lesser hate for all Linux developers, users, and basically 
anyone who isn't using Schillix or worshipping the ground he walks on.

I believe LKML is for serious discussion of Linux kernel development only, and 
for this to optimally continue, we need to purge the list of trolls like him.

-- 
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: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Kyle Moffett]

On Jan 31, 2006, at 01:05, Anders Karlsson wrote:
> On 1/31/06, Patrick McFarland <diablod3@gmail.com> wrote:
>> On Sunday 29 January 2006 06:01, Joerg Schilling wrote:
>>> Danger: Highly Flammable Material. <!>
>>
>> I formally request that Joerg Schilling be banned from the LKML  
>> until he learns how to take bugs in his program seriously.  
>> cdrecord has bugs, people hit them, and he won't either fix the  
>> bugs, or hand maintainership over to someone who wants to fix them.
> [snip]
>
> Don't bother banning him, that won't fix anything. Just don't use  
> cdrecord and ignore his posts until he changes attitude. Anyone  
> with such an ego will soon notice if he/she is ignored.  At least,  
> if he is still reading the list, he'll see the quirks and bugs  
> reported.

It's always really easy to use a personal ban (IE: killfile).  Just  
stick a list of email addresses somewhere and configure a mail client  
rule to autodelete all messages from those addresses.  My list now  
has about a hundred addresses (including Jörg's).  If they later  
decide to be mature/polite/etc and wish to resume discussions,  
they're welcome to create a new email account and start posting from  
there.

Cheers,
Kyle Moffett

--
Unix was not designed to stop people from doing stupid things,  
because that would also stop them from doing clever things.
   -- Doug Gwyn

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Pekka Enberg]

Hi,

On 1/31/06, Patrick McFarland <diablod3@gmail.com> wrote:
> I formally request that Joerg Schilling be banned from the LKML until he
> learns how to take bugs in his program seriously. cdrecord has bugs, people
> hit them, and he won't either fix the bugs, or hand maintainership over to
> someone who wants to fix them.

Why bother? You can always do what I do, ignore him. Cdrecord bugs
don't matter because distributors are smart enough to apply the
appropiate patches. The Linux bugs Joerg has mentioned don't seem to
matter to anyone except Joerg himself. You can always help the libburn
people or fork cdrecord if you don't like it. Please respect the fact
that Joerg has a different view of things. Even though it doesn't seem
to be connected to the world the rest of us know, he is entitled to
it. Perhaps now is a good time to let this thread die? Pretty please?

                                   Pekka

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Jesper Juhl]

On 1/31/06, Patrick McFarland <diablod3@gmail.com> wrote:
> On Sunday 29 January 2006 06:01, Joerg Schilling wrote:
> > Danger: Highly Flammable Material. <!>
>
> I formally request that Joerg Schilling be banned from the LKML until he
> learns how to take bugs in his program seriously. cdrecord has bugs, people
> hit them, and he won't either fix the bugs, or hand maintainership over to
> someone who wants to fix them.
>
Banning Joerg (or anyone else for that matter) from LKML doesn't solve anything.
You may agree or disagree with him, but just shutting him up on LKML
doesn't solve any problems. Discussion of the issue, technical points
and counterpoints etc solve issues.
Cencorship is never a solution, that way lies stagnation and a
one-sided world view.

> Not only that, he constantly trolls on the LKML about how awesome cdrecord is,
> and how stupid kernel developers are. He also rears his head in any
> discussion on CD burning under Linux, even though it not always has anything
> to do with cdrecord; and totally derails any such discussion.
>
Do you have to have an app using a given feature of the kernel to be
allowed to participate in a discussion? That's news to me...


> In addition to the aforementioned problems, he also has a serious hate for
> Debian, and the Debian developers who maintain the cdrecord package; in
> addition, he has lesser hate for all Linux developers, users, and basically
> anyone who isn't using Schillix or worshipping the ground he walks on.
>
If you can't stand a given person then add him/her to your personal killfile.
The fact that a person likes or dislikes a specific group of people or
a specific Linux distibution or whatever may make them obnoxious or
disagreeable to you personally, but that doesn't mean that they
shouldn't be allowed to express their views.   You are always free to
ignore Joerg if you want.


> I believe LKML is for serious discussion of Linux kernel development only, and
> for this to optimally continue, we need to purge the list of trolls like him.
>
And who's to be the judge of who's a troll and who's not?  you? me?
some third party?

I personally agree with some things Joerg is saying and disagree with
others but I still believe he should be allowed to speak, and a mail
such as yours is at least as annoying/offending/trollish as anything
he has said so far.

If he bothers you, just ignore him.

Now let's get back to a technical discussion.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]

[Jan Engelhardt]

>> On Sunday 29 January 2006 06:01, Joerg Schilling wrote:
>> > Danger: Highly Flammable Material. <!>
>>
>> I formally request that Joerg Schilling be banned from the LKML until he
>> learns how to take bugs in his program seriously. cdrecord has bugs, people
>> hit them, and he won't either fix the bugs, or hand maintainership over to
>> someone who wants to fix them.
>>

LKML is not the Chinese Government.

>>
>And who's to be the judge of who's a troll and who's not?  you? me?
>some third party?
>
>I personally agree with some things Joerg is saying and disagree with
>others but I still believe he should be allowed to speak, and a mail
>such as yours is at least as annoying/offending/trollish as anything
>he has said so far.
>
>If he bothers you, just ignore him.
>
>Now let's get back to a technical discussion.
>

Yep. We were quite there. At least I got that impression.


Jan Engelhardt
--