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

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

[David S. Miller]

From: Patrick McFarland <diablod3@gmail.com>
Date: Mon, 30 Jan 2006 20:43:55 -0500

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

I'd rather natural forces work to show him what an anti-social person
he is.  We don't need to ban him from the lists, as that is an act
which is about as low as he is, and we don't need to stoop like that.

Re: CD writing in future Linux try #2

[Gerhard Mack]

On Mon, 30 Jan 2006, David S. Miller wrote:

> Date: Mon, 30 Jan 2006 17:47:05 -0800 (PST)
> From: David S. Miller <davem@davemloft.net>
> Subject: Re: CD writing in future Linux try #2
> 
> From: Patrick McFarland <diablod3@gmail.com>
> Date: Mon, 30 Jan 2006 20:43:55 -0500
> 
> > 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.
> 
> I'd rather natural forces work to show him what an anti-social person
> he is.  We don't need to ban him from the lists, as that is an act
> which is about as low as he is, and we don't need to stoop like that.

The downside to that is that while this all gets fought out cd burning on 
Linux is more of a pain than it should be.

	Gerhard


--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: CD writing in future Linux try #2

[David S. Miller]

From: Gerhard Mack <gmack@innerfire.net>
Date: Tue, 31 Jan 2006 06:13:09 -0500 (EST)

> The downside to that is that while this all gets fought out cd burning on 
> Linux is more of a pain than it should be.

Someone remind me why the whole world is a prisoner to Joerg's cd
burning program?

Anybody can write their own, and if Joerg is a pain to work with that
is a double extra incentive for this other implementation to be
written.

In fact I'm very surprised this hasn't happened already.

Re: CD writing in future Linux try #2

[Bill Davidsen]

David S. Miller wrote:
> From: Gerhard Mack <gmack@innerfire.net>
> Date: Tue, 31 Jan 2006 06:13:09 -0500 (EST)
> 
> 
>>The downside to that is that while this all gets fought out cd burning on 
>>Linux is more of a pain than it should be.
> 
> 
> Someone remind me why the whole world is a prisoner to Joerg's cd
> burning program?
> 
> Anybody can write their own, and if Joerg is a pain to work with that
> is a double extra incentive for this other implementation to be
> written.
> 
> In fact I'm very surprised this hasn't happened already.

Because Jorg has maintained the program for a decade, has found and 
supported new vendors and devices, he seems to get new hardware sooner 
than most, and many programs and scripts use his program as an output stage.

Unless someone wants to dedicate themselves to do such a program things 
will go the way of certain other programs which were "the best" before 
they were obsolete. There's a reason why the list is called cdwrite, and 
no one uses that any more.

Joerg is technically astute, and has no clue how to interface with 
people without pissing them off. He loves the obsolete sg interface, he 
thinks his DVD-pro thing will make money but the last time I checked he 
didn't tke credit cards or paypal, and he just has no people skills or 
interest in learning them.

That's why people put up with him, he continues to support what he does.

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

[Joerg Schilling]

Bill Davidsen <davidsen@tmr.com> wrote:

> Joerg is technically astute, and has no clue how to interface with 
> people without pissing them off. He loves the obsolete sg interface, he 
> thinks his DVD-pro thing will make money but the last time I checked he 
> didn't tke credit cards or paypal, and he just has no people skills or 
> interest in learning them.

How did you manage to write 3 incorrect claims inside a single sentence?

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-01:

> Bill Davidsen <davidsen@tmr.com> wrote:
> 
> > Joerg is technically astute, and has no clue how to interface with 
> > people without pissing them off. He loves the obsolete sg interface, he 
> > thinks his DVD-pro thing will make money but the last time I checked he 
> > didn't tke credit cards or paypal, and he just has no people skills or 
> > interest in learning them.
> 
> How did you manage to write 3 incorrect claims inside a single sentence?

You don't consider yourself astute or being skilled in working with
people?  That's news to me. (Hint: list the statements you think are false).

-- 
Matthias Andree

Re: CD writing in future Linux try #2

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-01:
>
> > Bill Davidsen <davidsen@tmr.com> wrote:
> > 
> > > Joerg is technically astute, and has no clue how to interface with 
> > > people without pissing them off. He loves the obsolete sg interface, he 
> > > thinks his DVD-pro thing will make money but the last time I checked he 
> > > didn't tke credit cards or paypal, and he just has no people skills or 
> > > interest in learning them.
> > 
> > How did you manage to write 3 incorrect claims inside a single sentence?
>
> You don't consider yourself astute or being skilled in working with
> people?  That's news to me. (Hint: list the statements you think are false).

The way a reply is made depends on what it is going to reply to.

This was a reply to a really offensive mail.....

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

[Jan Engelhardt]

>> > Joerg is technically astute, and has no clue how to interface with 
>> > people without pissing them off. He loves the obsolete sg interface, he 
>> > thinks his DVD-pro thing will make money but the last time I checked he 
>> > didn't tke credit cards or paypal, and he just has no people skills or 
>> > interest in learning them.
>> 
>> How did you manage to write 3 incorrect claims inside a single sentence?
>
>You don't consider yourself astute or being skilled in working with
>people?  That's news to me. (Hint: list the statements you think are false).
>

17:26 shanghai:~ > grep astute /usr/share/dict/de-en.txt
Scharfsinnigkeit {f}; Scharfsinn {m} :: astuteness
scharfsinnig {adj} :: astute
scharfsinnig {adv} :: astutely

HTH. This word might be perceived (at least I do) in two different ways in 
German.



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

[Jan Engelhardt]

>> 
>> Someone remind me why the whole world is a prisoner to Joerg's cd
>> burning program?
>> 
>> Anybody can write their own, and if Joerg is a pain to work with that
>> is a double extra incentive for this other implementation to be
>> written.
>> 
>> In fact I'm very surprised this hasn't happened already.
>
> Because Jorg has maintained the program for a decade, has found and supported
> new vendors and devices, he seems to get new hardware sooner than most, and
> many programs and scripts use his program as an output stage.
>

Because cdrecord (and recently -prodvd) work. And they are "somewhat free".
There are not much dvd-dl writing programs around that do it without crashing
freezing or foobaring the disc. You are right, I could go to Nero or Nero4Linux
("the best of burning from Windows now for Linux"), but I don't.

> he thinks his
> DVD-pro thing will make money but the last time I checked he didn't tke credit
> cards or paypal

The last time I checked, prodvd was free for non-commercial purposes and - as
far as I can *guess* - is free for commercial purposes as long as they give
notice that it is being used. Unless commercials disguise using the
non-commercial key.


Jan Engelhardt
-- 

Re: CD writing in future Linux try #2

[Bill Davidsen]

Jan Engelhardt wrote:
>>>Someone remind me why the whole world is a prisoner to Joerg's cd
>>>burning program?
>>>
>>>Anybody can write their own, and if Joerg is a pain to work with that
>>>is a double extra incentive for this other implementation to be
>>>written.
>>>
>>>In fact I'm very surprised this hasn't happened already.
>>
>>Because Jorg has maintained the program for a decade, has found and supported
>>new vendors and devices, he seems to get new hardware sooner than most, and
>>many programs and scripts use his program as an output stage.
>>
> 
> 
> Because cdrecord (and recently -prodvd) work. And they are "somewhat free".
> There are not much dvd-dl writing programs around that do it without crashing
> freezing or foobaring the disc. You are right, I could go to Nero or Nero4Linux
> ("the best of burning from Windows now for Linux"), but I don't.
> 
> 
>>he thinks his
>>DVD-pro thing will make money but the last time I checked he didn't tke credit
>>cards or paypal
> 
> 
> The last time I checked, prodvd was free for non-commercial purposes and - as
> far as I can *guess* - is free for commercial purposes as long as they give
> notice that it is being used. Unless commercials disguise using the
> non-commercial key.

Free, but not open source, and that's an issue with a mission critical 
application. For home use it doesn't matter, for business use it really 
does. Only one person has the source, and he could be hit by a bus like 
anyone else. Or if he uses as much tact in person as he does in email, 
he might become unavailable at any moment.

I wasn't complaining about the price of ProDVD, just noting that when it 
first came out I tried to buy a license and found that Paypal wasn't an 
option.

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

Re: CD writing in future Linux try #2

[Joerg Schilling]

Bill Davidsen <davidsen@tmr.com> wrote:

> Free, but not open source, and that's an issue with a mission critical 
> application. For home use it doesn't matter, for business use it really 

Since when is mission critical requiring OpenSource?

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-03:

> Bill Davidsen <davidsen@tmr.com> wrote:
> 
> > Free, but not open source, and that's an issue with a mission critical 
> > application. For home use it doesn't matter, for business use it really 
> 
> Since when is mission critical requiring OpenSource?

Now this is really offensive. Bill stated the reason, yet you jump at
him before even reading his message through the end.

No wonder no-one's talking to you.

-- 
Matthias Andree

Re: CD writing in future Linux try #2

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-03:
>
> > Bill Davidsen <davidsen@tmr.com> wrote:
> > 
> > > Free, but not open source, and that's an issue with a mission critical 
> > > application. For home use it doesn't matter, for business use it really 
> > 
> > Since when is mission critical requiring OpenSource?
>
> Now this is really offensive. Bill stated the reason, yet you jump at
> him before even reading his message through the end.

It would really help it you try to understand first....

Today many companies buy closed source software from small companies that
may just disappear one day. So where is your point?

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

[linux-os (Dick Johnson)]

On Fri, 3 Feb 2006, Joerg Schilling wrote:

> Bill Davidsen <davidsen@tmr.com> wrote:
>
>> Free, but not open source, and that's an issue with a mission critical
>> application. For home use it doesn't matter, for business use it really
>
> Since when is mission critical requiring OpenSource?
>
> Jörg
>

Funny, when I was returning from Austin Texas with a stop at
Dallas, the B777 encountered a problem with the 1st officer's
flight-director display so the airplane was delayed while the
maintenance crew replaced a LRU. I watched as it was started
up, "booted". It was Windows CE!  Now, that's "mission critical!"


Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.66 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
To unsubscribe

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: CD writing in future Linux try #2

[Bill Davidsen]

On Fri, 3 Feb 2006, Joerg Schilling wrote:

> Bill Davidsen <davidsen@tmr.com> wrote:
> 
> > Free, but not open source, and that's an issue with a mission critical 
> > application. For home use it doesn't matter, for business use it really 
> 
> Since when is mission critical requiring OpenSource?

Clearly mission critical software should be available long term. Open 
source is one way to provide that, as is buying from a solid company. But 
if you were hit by a bus, who would maintain ProDVD?

Not having a clear answer I would assume "no one." Open source isn't a 
requirement, some viable plan other than "migrate to something else" is. 
If good size companies are willing to put their code in escrow to release 
if the company is no longer supporting for some reason, it's a viable 
business concern.

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

Re: CD writing in future Linux try #2

[Albert Cahalan]

On 1/31/06, David S. Miller <davem@davemloft.net> wrote:

> Someone remind me why the whole world is a prisoner to Joerg's cd
> burning program?
>
> Anybody can write their own, and if Joerg is a pain to work with that
> is a double extra incentive for this other implementation to be
> written.
>
> In fact I'm very surprised this hasn't happened already.

It has happened, many times, but sustaining such a project is
very difficult. The obstacles are numerous:

All the GUI apps parse cdrecord output. The output is somehow
even messier than the recent /proc/*/smaps abomination. It is
thus difficult to change or replace cdrecord. One of the major
GUI apps appears to be written by Joerg's real-life non-Internet
friend, who naturally refuses any patches to eliminate the need
for cdrecord.

Joerg is a Fraunhofer employee. That gives him connections to
many hardware companies. (and the RIAA, MPAA, Sony, Disney...)
One may wonder if this is both blessing and curse.

Forking means dealing with a giant pile of messy and ugly code.
The coding conventions are... interesting... and this code has
to run setuid. One had better be really careful making changes.
Most people are clueless about setuid code.

Starting fresh means rediscovering firmware bugs, of which there
are many. Things may be getting somewhat better though, with the
old pre-standard interfaces hopefully dying out. Getting the most
out of the hardware will require lots of device-specific code.

Joerg gets the hardware.

There are all sorts of funky formats. I've only ever heard of
mixed audio+data CDs for circa-1995 games and Sony spyware, but
maybe there are decent people who actually create these things.
In theory, somebody might be making multi-session CDs. Who knows?

That all said, I just wrote /dev scan code and I'm about half
way through documenting xcdroast's cdrecord expectations.
I'm imagining something like this:

/usr/lib/burner-helper: setuid or daemon, controlled via stdio
/usr/lib/something.so:  interacts with burner-helper
/usr/bin/cdrecord:      the crappy legacy interface
/usr/bin/something:     a non-crappy CLI interface

(no promises)

Re: CD writing in future Linux try #2

[jerome lacoste]

On 2/1/06, Albert Cahalan <acahalan@gmail.com> wrote:
> On 1/31/06, David S. Miller <davem@davemloft.net> wrote:
>
> > Someone remind me why the whole world is a prisoner to Joerg's cd
> > burning program?
> >
> > Anybody can write their own, and if Joerg is a pain to work with that
> > is a double extra incentive for this other implementation to be
> > written.
> >
> > In fact I'm very surprised this hasn't happened already.
>
> It has happened, many times, but sustaining such a project is
> very difficult. The obstacles are numerous:
>
> All the GUI apps parse cdrecord output. The output is somehow
> even messier than the recent /proc/*/smaps abomination. It is
> thus difficult to change or replace cdrecord. One of the major
> GUI apps appears to be written by Joerg's real-life non-Internet
> friend, who naturally refuses any patches to eliminate the need
> for cdrecord.

http://lists.freedesktop.org/archives/libburn/2006-January/000329.html

"Announcing cdrskin, a limited cdrecord compatibility wrapper for libburn

cdrskin currently is able to blank and burn data CDs with one or more
tracks. [...]

I am using cdrskin daily with my data backups on CD-RW where it shows about
the same reliability as cdrecord-ProDVD 2.01b31. The backup success is verified
by my backup tool via a MD5 stream checksum.

This is the initial public release 0.1.0 of cdrskin. [...]"

see also http://icculus.org/burn/

Jerome

Re: CD writing in future Linux try #2

[Joerg Schilling]

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

> http://lists.freedesktop.org/archives/libburn/2006-January/000329.html
>
> "Announcing cdrskin, a limited cdrecord compatibility wrapper for libburn

You you really believe that something like libcdburn that does not even come
close to compiling because of a syntax error in "./configure" and that
is Linux only will be of any help?

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

[Kurt Wall]

On Wed, Feb 01, 2006 at 05:42:35PM +0100, Joerg Schilling took 23 lines to write:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
> 
> > http://lists.freedesktop.org/archives/libburn/2006-January/000329.html
> >
> > "Announcing cdrskin, a limited cdrecord compatibility wrapper for libburn
> 
> You you really believe that something like libcdburn that does not even come
> close to compiling because of a syntax error in "./configure" and that
> is Linux only will be of any help?

If it avoids annual pissing contests on this topic, yes.

-- 
WHERE CAN THE MATTER BE

	Oh, dear, where can the matter be
	When it's converted to energy?
	There is a slight loss of parity.
	Johnny's so long at the fair.

Re: CD writing in future Linux try #2

[Rene Herman]

Albert Cahalan wrote:

> There are all sorts of funky formats. I've only ever heard of mixed
> audio+data CDs for circa-1995 games and Sony spyware, but maybe there
> are decent people who actually create these things.

These are in fact very common. Lots of audio CDs, with a data bit with a 
few quicktime/mpeg videos.

Rene.

Re: CD writing in future Linux try #2

[Jon Agirre]

Rene Herman wrote:

> Albert Cahalan wrote:
>
>> There are all sorts of funky formats. I've only ever heard of mixed
>> audio+data CDs for circa-1995 games and Sony spyware, but maybe there
>> are decent people who actually create these things.
>
>
> These are in fact very common. Lots of audio CDs, with a data bit with 
> a few quicktime/mpeg videos.

The MIL-CD format developed by SEGA/Yamaha for the Dreamcast is also an 
example of this (two sessions, audio-mode2 or mode2-mode2). We 
(hobbysts) use it for booting our code from normal, inexpensive CD-ROMs, 
instead of purchasing a GD-ROM writer or an official devkit.

Best regards,

Jon

-- 
********************************
Jon Agirre Hernández
Unidad de Biofisica (CSIC-UPV/EHU)
P.O.Box 644, E-48080 Bilbao, Spain.
Blog: http://lostsymmetry.blogspot.com
Web: http://www.ehu.es/biofisica
E-mail: gbbaghej@lg.ehu.es
Tel: +34 94 601 3345
Fax: +34 94 601 3360

Re: CD writing in future Linux try #2

[Jan Engelhardt]

>
>> There are all sorts of funky formats. I've only ever heard of mixed
>> audio+data CDs for circa-1995 games and Sony spyware, but maybe there
>> are decent people who actually create these things.
>
> These are in fact very common. Lots of audio CDs, with a data bit with a few
> quicktime/mpeg videos.

For the record, so-called Mixed Mode discs consisting of

  Session 1 >>
    Track 1 (Data)
    Track 2 (Audio)
    Track 3 (Audio)
    ...

exist(ed) quite a lot, when games were smaller than the audio. (Now that we 
have things like Doom3 and Ogg, this has sadfully turned around.) To name 
two of such mixedmode CDs from "popular games":
  Microsoft Fury3 and MechWarrior2 (Matrox Mystique W95 Edition)

The other type of "mixed-mode" CDs are the so-called "CD Extra", which is:

  Session 1 >>
    Track 1 (Audio)
    Track 2 (Audio)
    ...
  Session 2 >>
    Track N (Data)

from what I remember, "Music Instructor - Get freaky" was such a CD where 
the iso9660 track had an .mpg video clip. This was done so legacy audio 
players don't play all the fizzle (cat /dev/cdrom >/dev/dsp) through their 
speakers and damage them.
(I tried in the oldest HiFi stuff I could dig up, e.g. SONY UX-1 - stayed 
correctly silent on Data tracks ;-)



Jan Engelhardt
-- 

Re: CD writing in future Linux try #2

[Peter Chubb]

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

>>
>>> There are all sorts of funky formats. I've only ever heard of
>>> mixed audio+data CDs for circa-1995 games and Sony spyware, but
>>> maybe there are decent people who actually create these things.
>>  These are in fact very common. Lots of audio CDs, with a data bit
>> with a few quicktime/mpeg videos.

Jan> The other type of "mixed-mode" CDs are the so-called "CD Extra",
Jan> which is:

Jan>   Session 1 >> Track 1 (Audio) Track 2 (Audio) ...  Session 2 >>
Jan> Track N (Data)


I have some of these -- some Christian music publishers include sheet
music (as PDFs) in an ISO FS on the second session.  Published last
year, so recent.

Peter C

Re: CD writing in future Linux try #2

[Albert Cahalan]

On 2/6/06, Peter Chubb <peter@chubb.wattle.id.au> wrote:
> >>>>> "Jan" == Jan Engelhardt <jengelh@linux01.gwdg.de> writes:
>
> >>
> >>> There are all sorts of funky formats. I've only ever heard of
> >>> mixed audio+data CDs for circa-1995 games and Sony spyware, but
> >>> maybe there are decent people who actually create these things.
> >>  These are in fact very common. Lots of audio CDs, with a data bit
> >> with a few quicktime/mpeg videos.
>
> Jan> The other type of "mixed-mode" CDs are the so-called "CD Extra",
> Jan> which is:
>
> Jan>   Session 1 >> Track 1 (Audio) Track 2 (Audio) ...  Session 2 >>
> Jan> Track N (Data)
>
>
> I have some of these -- some Christian music publishers include sheet
> music (as PDFs) in an ISO FS on the second session.  Published last
> year, so recent.

In other words, a cute hack in a commercial product.

You're not doing this for computer backups, to play a custom mix in
your car CD player, to send photos to grandma, to deliver data to a
customer, or anything normal.

Re: CD writing in future Linux try #2

[Joerg Schilling]

Albert Cahalan <acahalan@gmail.com> wrote:

> Joerg is a Fraunhofer employee. That gives him connections to
> many hardware companies. (and the RIAA, MPAA, Sony, Disney...)
> One may wonder if this is both blessing and curse.

It is obvious that you are completely bejond reality.

What is your background for writing lies like this one?

How about trying to find out how reality is?


> Forking means dealing with a giant pile of messy and ugly code.
> The coding conventions are... interesting... and this code has
> to run setuid. One had better be really careful making changes.
> Most people are clueless about setuid code.

The original code demonstarates that suid root is not needed
if you run on an operating system that offers the needed features (e.g. 
Solaris).


> Starting fresh means rediscovering firmware bugs, of which there
> are many. Things may be getting somewhat better though, with the
> old pre-standard interfaces hopefully dying out. Getting the most
> out of the hardware will require lots of device-specific code.
>
> Joerg gets the hardware.

You get the hardware if you prove that you do _real_ long time work.

You constantly need to prove that you are still doing work and you need to stay 
in contact with the righ people. This is some kind of "social engineering" and 
it seems that many people from this list would have problems to do communicaton 
the right way.....

Wheening: "someboy need to to work on this" is not doing real work.

Jörg

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

Re: CD writing in future Linux try #2

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-01:

> > Forking means dealing with a giant pile of messy and ugly code.
> > The coding conventions are... interesting... and this code has
> > to run setuid. One had better be really careful making changes.
> > Most people are clueless about setuid code.
> 
> The original code demonstarates that suid root is not needed
> if you run on an operating system that offers the needed features (e.g. 
> Solaris).

That's old news, no need to repost this every other hour.

-- 
Matthias Andree

Re: CD writing in future Linux try #2

[Bill Davidsen]

Albert Cahalan wrote:
> On 1/31/06, David S. Miller <davem@davemloft.net> wrote:
> 
> 
>>Someone remind me why the whole world is a prisoner to Joerg's cd
>>burning program?
>>
>>Anybody can write their own, and if Joerg is a pain to work with that
>>is a double extra incentive for this other implementation to be
>>written.
>>
>>In fact I'm very surprised this hasn't happened already.
> 
> 
> It has happened, many times, but sustaining such a project is
> very difficult. The obstacles are numerous:
> 
> All the GUI apps parse cdrecord output. The output is somehow
> even messier than the recent /proc/*/smaps abomination. It is
> thus difficult to change or replace cdrecord. One of the major
> GUI apps appears to be written by Joerg's real-life non-Internet
> friend, who naturally refuses any patches to eliminate the need
> for cdrecord.
> 
> Joerg is a Fraunhofer employee. That gives him connections to
> many hardware companies. (and the RIAA, MPAA, Sony, Disney...)
> One may wonder if this is both blessing and curse.
> 
> Forking means dealing with a giant pile of messy and ugly code.
> The coding conventions are... interesting... and this code has
> to run setuid. One had better be really careful making changes.
> Most people are clueless about setuid code.
> 
> Starting fresh means rediscovering firmware bugs, of which there
> are many. Things may be getting somewhat better though, with the
> old pre-standard interfaces hopefully dying out. Getting the most
> out of the hardware will require lots of device-specific code.
> 
> Joerg gets the hardware.
> 
> There are all sorts of funky formats. I've only ever heard of
> mixed audio+data CDs for circa-1995 games and Sony spyware, but
> maybe there are decent people who actually create these things.
> In theory, somebody might be making multi-session CDs. Who knows?

Not just in theory, I get notes from people saying they use addir for 
backups, which is why I wrote it, because I change ~50MB/day and one CD 
will hold all the change. So addir is like growisofs with some 
additional bells and whistles I found useful, like taking a list of 
files changed taoday from stdin (find) and adding them to the end of the 
CD, preserving or renaming directory names, etc.

http://www.tmr.com/~public/source/addir if you want to see an example.

I used the mixed audio and data a few times, I'm sure there are folks 
who use it regularly. cdrecord is full function, and continues to 
support new vendors and models, work around firmware bugs etc. A real 
replacement is going to be a lot of ongoing work.

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

[Lennart Sorensen]

On Tue, Jan 31, 2006 at 06:13:09AM -0500, Gerhard Mack wrote:
> The downside to that is that while this all gets fought out cd burning on 
> Linux is more of a pain than it should be.

On the other hand, I mostly use DVDs now, and growisofs is just
wonderful, and much easier to work with from the command line.  Maybe
someday we won't care about burning CDs anymore, or maybe growisofs will
add support for it.

Or maybe someone else will maintain a patch that fixes the dumb
"warnings" and such in cdrecord that people can apply to it.  As long as
it doesn't do anything as messy as the pioneer dvd burning patch did.

Len Sorensen

Re: CD writing in future Linux try #2

[linux-os (Dick Johnson)]

On Mon, 30 Jan 2006, David S. Miller wrote:

> From: Patrick McFarland <diablod3@gmail.com>
> Date: Mon, 30 Jan 2006 20:43:55 -0500
>
>> 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.
>
> I'd rather natural forces work to show him what an anti-social person
> he is.  We don't need to ban him from the lists, as that is an act
> which is about as low as he is, and we don't need to stoop like that.
> -



For those who have just tuned in, I will present a
bit if history.

CD Writing using amateur operating systems like Windows
is really quite simple for the user. Using 3rd party
software, one can even access a CD/ROM as though it
was a "slow" disk. CD/ROM writing is built into a lot
of imaging software such as used for Kodak digital
cameras. The interface to Win/2000 and higher is
really quite straight-forward which may be why CD
writing has found its way into a lot of such applications.

Linux is a Unix variant. I/O to devices have historically
been performed using open, close, read, write, and ioctl.
These generic functions should remain for access to
CD/ROM devices as well. If you have a CD/ROM as a SCSI
device, ATA device, Firewire device, USB device, or
a fiber-channel device it should be accessed just like
any other block device and its name should be in /dev
so one can create a sym-link, possibly /dev/cdrom or
/dev/fast-CD, /dev/slow-CD, - anything the user wants.

There is nothing special about a CD/ROM except that
once written, you need a hacksaw to erase is. In fact,
you can write the output of `tar` directly to a CD/ROM
without any intervening file-system. This saves a lot
of time and space when performing backups. Of course
the driver requires some synchronization and, in fact,
some "experimentation" to determine the power-level for
a particular speed. However, those are just the details
necessary to start the write process.

Linux has a CD/ROM driver. It, for the most part, works
okay. It was written by a person who seems to have an
attitude problem. This is okay. Many smart people have
such problems. One of the things this problem creates
is the apparent refusal to understand by several persons,
including the designer, that there are many ways to
interface to a device, none better or worse than than
any other. In many cases it's all about convention.

The selection of the interface standard was created when
Multics was stripped down and Unix ported to a PDP-7
in the seventies by Dennis Ritchie. From that time on,
Unix and its variants always performed I/O using special
device files for access. There isn't even anything
special about these, either. It's just a method used
to associate a major/minor number combination with
a file-descriptor.

Linux started using devices with names like fd0, fd1, etc.,
for floppies; hda, hdb, etc., for generic hard disks; sda,
sdb, etc., for SCSI devices; scd0, scd1, etc., for
SCSI CD/ROM devices ... the list goes on.

When the current CD/ROM writer software was written, the
writer decided to reject the historical aspects of Linux
and create a device access and numbering scheme that
is alien to many Unix/Linux users. It goes like this:

scsibus0:
 	0,0,0	  0) 'SEAGATE ' 'ST32171W        ' '0484' Disk
 	0,1,0	  1) 'SEAGATE ' 'ST318233LWV     ' '0002' Disk
 	0,2,0	  2) 'SEAGATE ' 'ST39102LW       ' '0005' Disk
 	0,3,0	  3) *
 	0,4,0	  4) 'YAMAHA  ' 'CRW6416S        ' '1.0b' Removable CD-ROM
 	0,5,0	  5) *
 	0,6,0	  6) *
 	0,7,0	  7) *

Many Linux users have complained about this for several years.
The complaints have fallen upon deaf ears, which has become
irksome to many. The facts are that any/all naming and numbering
schemes are purely arbitrary. Internally, the kernel doesn't
give a rat's ass what it was called. It's just a file-descriptor
(an integer), that is associated with the device and the process
using that device.

It would be real nice if the designer of the software would
change his interface specification so it corresponds to what
the user's have become accustomed to, when dealing with Unix
and its variants, or to add an additional startup interface
that corresponds to the Unix/Linux convention. However,
as the writer of that software, he doesn't have to change
anything to placate the users. He could have designed the
software so the interface uses BSD sockets if he wanted to.
He just wanted to do his softare his way, and you can't
blame him for that.

If you want another interface, I suggest that those with
such powerful opinions that they expend a lot of effort
trying to put the guy down, just use a portion of that
effort to write a new driver. Maybe that will free up
enough time to fix some bugs.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.66 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
To unsubscribe


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

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

CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Marc Koschewski]

* Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> [2006-01-27 17:37:48 +0100]:

> Hi,
> 
> I'm stealing thread <...>

... me, too.

> I address this to everybody not only to Joerg:

... me, too.

I just tried blanking a CD-RW with the latest -git tree. The machine just became
unresponsive and then froze. When it became unresponsive the clock in GNOME still
displayed the current time but I could not focus any windows anymore. Then I had
to hard reboot the machine. The logs say nothing. I repeat: nothing.

Does anyone have similar problems?

Marc

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Phillip Susi]

Marc Koschewski wrote:
> I just tried blanking a CD-RW with the latest -git tree. The machine just became
> unresponsive and then froze. When it became unresponsive the clock in GNOME still
> displayed the current time but I could not focus any windows anymore. Then I had
> to hard reboot the machine. The logs say nothing. I repeat: nothing.
>
> Does anyone have similar problems?

Instead of rebooting, just wait for the blanking to finish.  My guess is 
that your burner and hard drive are both on the same ide channel, and so 
you can not access the disk while the burner is blanking.  If this is 
the case, put each drive on their own ide channel. 

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Gene Heskett]

On Friday 10 February 2006 14:19, Phillip Susi wrote:
>Marc Koschewski wrote:
>> I just tried blanking a CD-RW with the latest -git tree. The machine
>> just became unresponsive and then froze. When it became unresponsive
>> the clock in GNOME still displayed the current time but I could not
>> focus any windows anymore. Then I had to hard reboot the machine.
>> The logs say nothing. I repeat: nothing.
>>
>> Does anyone have similar problems?
>
>Instead of rebooting, just wait for the blanking to finish.  My guess
> is that your burner and hard drive are both on the same ide channel,
> and so you can not access the disk while the burner is blanking.  If
> this is the case, put each drive on their own ide channel.
>
It takes hard drive access to switch window focus? Yes, thats a 
question.

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Kyle Moffett]

On Feb 10, 2006, at 14:39, Gene Heskett wrote:
> On Friday 10 February 2006 14:19, Phillip Susi wrote:
>> Marc Koschewski wrote:
>>> I just tried blanking a CD-RW with the latest -git tree. The  
>>> machine just became unresponsive and then froze. When it became  
>>> unresponsive the clock in GNOME still displayed the current time  
>>> but I could not focus any windows anymore. Then I had to hard  
>>> reboot the machine. The logs say nothing. I repeat: nothing.
>>>
>>> Does anyone have similar problems?
>>
>> Instead of rebooting, just wait for the blanking to finish.  My  
>> guess is that your burner and hard drive are both on the same ide  
>> channel, and so you can not access the disk while the burner is  
>> blanking.  If this is the case, put each drive on their own ide  
>> channel.
>
> It takes hard drive access to switch window focus? Yes, thats a  
> question.

Depends on your programs and RAM.  If the program you try to switch  
to (or, say, part of X or your window manage) is swapped out for some  
reason, then yes, changing focus may cause said program to hang until  
it can swap the data in.  Usually that's a small fraction of a  
second, but if your IDE bus is waiting for a burn, then it could be  
the duration of the burn.

Cheers,
Kyle Moffett

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

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Gene Heskett]

On Friday 10 February 2006 15:12, Kyle Moffett wrote:
>On Feb 10, 2006, at 14:39, Gene Heskett wrote:
>> On Friday 10 February 2006 14:19, Phillip Susi wrote:
>>> Marc Koschewski wrote:
>>>> I just tried blanking a CD-RW with the latest -git tree. The
>>>> machine just became unresponsive and then froze. When it became
>>>> unresponsive the clock in GNOME still displayed the current time
>>>> but I could not focus any windows anymore. Then I had to hard
>>>> reboot the machine. The logs say nothing. I repeat: nothing.
>>>>
>>>> Does anyone have similar problems?
>>>
>>> Instead of rebooting, just wait for the blanking to finish.  My
>>> guess is that your burner and hard drive are both on the same ide
>>> channel, and so you can not access the disk while the burner is
>>> blanking.  If this is the case, put each drive on their own ide
>>> channel.
>>
>> It takes hard drive access to switch window focus? Yes, thats a
>> question.
>
>Depends on your programs and RAM.  If the program you try to switch
>to (or, say, part of X or your window manage) is swapped out for some
>reason, then yes, changing focus may cause said program to hang until
>it can swap the data in.  Usually that's a small fraction of a
>second, but if your IDE bus is waiting for a burn, then it could be
>the duration of the burn.
>
>Cheers,
>Kyle Moffett
>
Entirely possible I suppose, but I've seen it here quite a few times 
when there was no swap involved, I've a gig of ram, so I would, just on 
the evidence, have to assume something went gaga and its time to hit 
the reset button.  cd blanking here is a just a few seconds operation 
generally as I don't normally do the whole disk, thats a waste of time.

I've seen swap used here only one time since I rebuilt with a gig of ram 
nearly 2 years ago now.  Uptime about 2 days, memory according to htop 
is 384 megs used.

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

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Marc Koschewski]

* Phillip Susi <psusi@cfl.rr.com> [2006-02-10 14:19:16 -0500]:

> Marc Koschewski wrote:
> >I just tried blanking a CD-RW with the latest -git tree. The machine just 
> >became
> >unresponsive and then froze. When it became unresponsive the clock in 
> >GNOME still
> >displayed the current time but I could not focus any windows anymore. Then 
> >I had
> >to hard reboot the machine. The logs say nothing. I repeat: nothing.
> >
> >Does anyone have similar problems?
> 
> Instead of rebooting, just wait for the blanking to finish.  My guess is 
> that your burner and hard drive are both on the same ide channel, and so 
> you can not access the disk while the burner is blanking.  If this is 
> the case, put each drive on their own ide channel. 

I've been waiting 30 minutes for the machine to come back but no chance. SSH
didn't work either. I thought I could login remote... but uh uh.

The problem is, it's a laptop. So there not much chance to move the cdrom device
over to another controller or whatever. ;)

But let's face it: is it really crappy to render a laptop unusable just because
blanking a CD-RW. The circumstances were: run xcdroast via gksu (thus running as
root), blank CD-RW. Due to cd-burning being totally unusable as a user (problems
here and there if it was just doing anything at all). So I've no other chance
than to run this as root. Couldn't cdrecord 'watch' ide load or - even better -
forcecast it? It knows blanking leads to inresponsiveness sometimes (even more due
to the fact that both devices share the same bus). Why not kind of  'renice'
the process that blanks?

Marc

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Phillip Susi]

Marc Koschewski wrote:
> I've been waiting 30 minutes for the machine to come back but no chance. SSH
> didn't work either. I thought I could login remote... but uh uh.
>
> The problem is, it's a laptop. So there not much chance to move the cdrom device
> over to another controller or whatever. ;)
>
> But let's face it: is it really crappy to render a laptop unusable just because
> blanking a CD-RW. The circumstances were: run xcdroast via gksu (thus running as
> root), blank CD-RW. Due to cd-burning being totally unusable as a user (problems
> here and there if it was just doing anything at all). So I've no other chance
> than to run this as root. Couldn't cdrecord 'watch' ide load or - even better -
> forcecast it? It knows blanking leads to inresponsiveness sometimes (even more due
> to the fact that both devices share the same bus). Why not kind of  'renice'
> the process that blanks?
>
> Marc

If that is what is going on, there is nothing linux can do about it; 
it's a limitation of the hardware.  The IDE controller can only accept 
one command at a time, so if that command takes a while to complete, the 
other drive on the same channel can not be accessed until the first 
command completes. 

If the system doesn't come back though after sufficient time has gone by 
for the burn to complete, then this is probably not what is happening.  
I'd suggest using magic-sysreq to force an unmount and reboot, then see 
if there's anything in the logs. 

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Lennart Sorensen]

On Fri, Feb 10, 2006 at 04:26:01PM -0500, Phillip Susi wrote:
> If that is what is going on, there is nothing linux can do about it; 
> it's a limitation of the hardware.  The IDE controller can only accept 
> one command at a time, so if that command takes a while to complete, the 
> other drive on the same channel can not be accessed until the first 
> command completes. 
> 
> If the system doesn't come back though after sufficient time has gone by 
> for the burn to complete, then this is probably not what is happening.  
> I'd suggest using magic-sysreq to force an unmount and reboot, then see 
> if there's anything in the logs. 

Perhaps a good test would be to try cdrecord from the command line to
blank the cd, to avoid issues to do with X, xcdroast, etc.  Just the
minimum you can have.

Also what command line does xcdroast generate for the blanking?

Len Sorensen

Re: CD-blanking leads to machine freeze with current -git

[Jan Engelhardt]

>
> If that is what is going on, there is nothing linux can do about it; it's a
> limitation of the hardware.  The IDE controller can only accept one command at
> a time, so if that command takes a while to complete, the other drive on the
> same channel can not be accessed until the first command completes. 

CD blanking only takes "one" command for the whole operation, as 
e.g. compared to CD writing where you always have to push out data packets.

Why I think it's just one (note the quotes): You can interrupt/kill 
cdrecord in the midst of blanking a CD, and blanking will continue to the 
'end' (either fast blank or full blank, whichever was sent)

As mentioned some time earlier, I had similar, but not the same issues. I 
could continue accessing the harddrive - otherwise mplayer would have 
stopped immediately, but it played at least until EOF.

> If the system doesn't come back though after sufficient time has gone by for
> the burn to complete, then this is probably not what is happening.  I'd suggest
> using magic-sysreq to force an unmount and reboot, then see if there's anything
> in the logs. 


Jan Engelhardt
-- 

Re: CD-blanking leads to machine freeze with current -git

[Marc Koschewski]

* Jan Engelhardt <jengelh@linux01.gwdg.de> [2006-02-11 16:16:58 +0100]:

> >
> > If that is what is going on, there is nothing linux can do about it; it's a
> > limitation of the hardware.  The IDE controller can only accept one command at
> > a time, so if that command takes a while to complete, the other drive on the
> > same channel can not be accessed until the first command completes. 
> 
> CD blanking only takes "one" command for the whole operation, as 
> e.g. compared to CD writing where you always have to push out data packets.

The cdrecord man page says this:

	Setting the -immed flag will request the command to return immediately while
	the operation proceeds in background, making the bus usable for the other
	devices and avoiding the system freeze.  This is an experimental feature which
	may work or not, depending on the model of the CD/DVD writer.  A correct 
	solution would be to set up a correct cabling but there seem to be notebooks
	around that have been set up the wrong way by the manufacturer.  As it is
	impossible to fix this problem in notebooks, the -immed option has been added.

It how can the bus run the command sent on the device 'in the background' when
it can only process _one_ request at a time?

To me it sound like the foreground process (cdrecord) fork()s a process to blank
the CD-RW. Clear. But you said the bus is not able to do so... I'm not getting
this.

> 
> Why I think it's just one (note the quotes): You can interrupt/kill 
> cdrecord in the midst of blanking a CD, and blanking will continue to the 
> 'end' (either fast blank or full blank, whichever was sent)
> 
> As mentioned some time earlier, I had similar, but not the same issues. I 
> could continue accessing the harddrive - otherwise mplayer would have 
> stopped immediately, but it played at least until EOF.
> 
> > If the system doesn't come back though after sufficient time has gone by for
> > the burn to complete, then this is probably not what is happening.  I'd suggest
> > using magic-sysreq to force an unmount and reboot, then see if there's anything
> > in the logs. 
> 
> 
> Jan Engelhardt
> -- 
> 

Marc

Re: CD-blanking leads to machine freeze with current -git

[Doug McNaught]

Marc Koschewski <marc@osknowledge.org> writes:

> The cdrecord man page says this:
>
> 	Setting the -immed flag will request the command to return
> 	immediately while the operation proceeds in background, making
> 	the bus usable for the other devices and avoiding the system
> 	freeze.  This is an experimental feature which may work or
> 	not, depending on the model of the CD/DVD writer.  A correct
> 	solution would be to set up a correct cabling but there seem
> 	to be notebooks around that have been set up the wrong way by
> 	the manufacturer.  As it is impossible to fix this problem in
> 	notebooks, the -immed option has been added.

> It how can the bus run the command sent on the device 'in the
>background' when it can only process _one_ request at a time?
>
> To me it sound like the foreground process (cdrecord) fork()s a
>process to blank the CD-RW. Clear. But you said the bus is not able
>to do so... I'm not getting this.

Some CD writers are apparently able to release the bus while
blanking, allowing use of the bus by other devices.  The 'immed' flag
tries to use this feature.  fork() has nothing to do with it--he's
talking about the IDE command, not the cdrecord program.

-Doug

Re: CD-blanking leads to machine freeze with current -git

[Marc Koschewski]

* Doug McNaught <doug@mcnaught.org> [2006-02-11 10:35:19 -0500]:

> Marc Koschewski <marc@osknowledge.org> writes:
> 
> > The cdrecord man page says this:
> >
> > 	Setting the -immed flag will request the command to return
> > 	immediately while the operation proceeds in background, making
> > 	the bus usable for the other devices and avoiding the system
> > 	freeze.  This is an experimental feature which may work or
> > 	not, depending on the model of the CD/DVD writer.  A correct
> > 	solution would be to set up a correct cabling but there seem
> > 	to be notebooks around that have been set up the wrong way by
> > 	the manufacturer.  As it is impossible to fix this problem in
> > 	notebooks, the -immed option has been added.
> 
> > It how can the bus run the command sent on the device 'in the
> >background' when it can only process _one_ request at a time?
> >
> > To me it sound like the foreground process (cdrecord) fork()s a
> >process to blank the CD-RW. Clear. But you said the bus is not able
> >to do so... I'm not getting this.
> 
> Some CD writers are apparently able to release the bus while
> blanking, allowing use of the bus by other devices.  The 'immed' flag
> tries to use this feature.  fork() has nothing to do with it--he's
> talking about the IDE command, not the cdrecord program.

I just thought about fork() as Alan (surely and others) told the IDE bus cannot
run several commands at a time. So fork() was the only left-over I could think
of. I didn't know some devices can kinda 'detach' themselves as long as the
blank is going on...

Things are clear now. OK, more clear. Not clear. ;)

Marc

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Alan Cox]

On Gwe, 2006-02-10 at 22:00 +0100, Marc Koschewski wrote:
> than to run this as root. Couldn't cdrecord 'watch' ide load or - even better -
> forcecast it? It knows blanking leads to inresponsiveness sometimes (even more due
> to the fact that both devices share the same bus). Why not kind of  'renice'
> the process that blanks?

It isn't about load. You issue a command to an ATA device and there is
no disconnect sequence as SCSI has. That bus is now locked until the
command completes.

There are mechanisms for certain cases like blanking and fixating that
allow you to avoid this. Some cd record apps let you choose them.  There
isn't anything the kernel can do however.

Alan

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Marc Koschewski]

* Alan Cox <alan@lxorguk.ukuu.org.uk> [2006-02-10 23:23:54 +0000]:

> On Gwe, 2006-02-10 at 22:00 +0100, Marc Koschewski wrote:
> > than to run this as root. Couldn't cdrecord 'watch' ide load or - even better -
> > forcecast it? It knows blanking leads to inresponsiveness sometimes (even more due
> > to the fact that both devices share the same bus). Why not kind of  'renice'
> > the process that blanks?
> 
> It isn't about load. You issue a command to an ATA device and there is
> no disconnect sequence as SCSI has. That bus is now locked until the
> command completes.
> 
> There are mechanisms for certain cases like blanking and fixating that
> allow you to avoid this. Some cd record apps let you choose them.  There
> isn't anything the kernel can do however.
> 
> Alan

Alan,

	I'm curious what caused the machine to freeze now whereas it didn't some
kernels ago. I don't know when I blanked a whole CD-RW the last time. But I know
it didn't freeze the machine. OK, maybe it's caused by some setting I missed (or
enabled) but I use the config now for along time. :/

I'm also curious when DELL will release their first mobile with SCSI onboard
instead of IDE. The chips are the same size... 

Thanks anyone for clarification. There's still sooo much to learn. But the code
is here and I'll try to do my very best... ;)

Marc

Re: CD-blanking leads to machine freeze with current -git

[Doug McNaught]

Marc Koschewski <marc@osknowledge.org> writes:

> I'm also curious when DELL will release their first mobile with SCSI
> onboard instead of IDE. The chips are the same size...

That's very unlikely to ever happen, but I do hear that laptops are
starting to use SATA rather than IDE, at least for the hard disk.
That would help with the bus-locking problem...

-Doug

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Alan Cox]

On Sad, 2006-02-11 at 00:41 +0100, Marc Koschewski wrote:
> I'm also curious when DELL will release their first mobile with SCSI onboard
> instead of IDE. The chips are the same size... 

SCSI I think is dead, but SATA is normally one device per bus so the
problem goes away

> Thanks anyone for clarification. There's still sooo much to learn. But the code
> is here and I'll try to do my very best... ;)


The magic cdrecord option is "-immed"

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[hackmiester (Hunter Fuller)]

Hrm. ssh into the box and then try to blank the CD on the local machine. 
Is the ssh session still responsive? I suspect it will be, especially if 
the GNOME clock's still running.
-- 
--hackmiester
Walk a mile in my shoes and you will be a mile away in a new pair of shoes.


Marc Koschewski wrote:
> * Phillip Susi <psusi@cfl.rr.com> [2006-02-10 14:19:16 -0500]:
> 
> 
>>Marc Koschewski wrote:
>>
>>>I just tried blanking a CD-RW with the latest -git tree. The machine just 
>>>became
>>>unresponsive and then froze. When it became unresponsive the clock in 
>>>GNOME still
>>>displayed the current time but I could not focus any windows anymore. Then 
>>>I had
>>>to hard reboot the machine. The logs say nothing. I repeat: nothing.
>>>
>>>Does anyone have similar problems?
>>
>>Instead of rebooting, just wait for the blanking to finish.  My guess is 
>>that your burner and hard drive are both on the same ide channel, and so 
>>you can not access the disk while the burner is blanking.  If this is 
>>the case, put each drive on their own ide channel. 
> 
> 
> I've been waiting 30 minutes for the machine to come back but no chance. SSH
> didn't work either. I thought I could login remote... but uh uh.
> 
> The problem is, it's a laptop. So there not much chance to move the cdrom device
> over to another controller or whatever. ;)
> 
> But let's face it: is it really crappy to render a laptop unusable just because
> blanking a CD-RW. The circumstances were: run xcdroast via gksu (thus running as
> root), blank CD-RW. Due to cd-burning being totally unusable as a user (problems
> here and there if it was just doing anything at all). So I've no other chance
> than to run this as root. Couldn't cdrecord 'watch' ide load or - even better -
> forcecast it? It knows blanking leads to inresponsiveness sometimes (even more due
> to the fact that both devices share the same bus). Why not kind of  'renice'
> the process that blanks?
> 
> Marc
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]]

[Marc Koschewski]

* hackmiester (Hunter Fuller) <hackmiester@hackmiester.com> [2006-02-10 19:03:30 -0600]:

> Hrm. ssh into the box and then try to blank the CD on the local machine. 
> Is the ssh session still responsive? I suspect it will be, especially if 
> the GNOME clock's still running.

The clock stopped working after a while. I guess sshd would just 'die away' as
any other process did in that case. I'll try with the flag set as Alan suggested.

Marc

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/