Rationale for RLIMIT_MEMLOCK?

Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

Greetings,

debugging an application problem that used to mlockall(...FUTURE) and
failed with a subsequent mmap(), I came across the manual page for
setrlimit (see below for the relevant excerpt). I have several questions
concerning the rationale:

1. What is the reason we're having special treatment
   for the super-user here?

2. Why is it the opposite of what 2.6.8.1 and earlier did?

3. Why is this inconsistent with all other RLIMIT_*?
   Neither of which cares if a process is privileged or not.

4. Is the default hard limit of 32 kB initialized by the kernel or
   by some script in SUSE 10.0? If it's the kernel: why is the limit so
   low, and why isn't just the soft limit set?

   "[...]
    RLIMIT_MEMLOCK
      The maximum number of bytes of memory that may  be  locked  into
      RAM.  In effect this limit is rounded down to the nearest multi-
      ple of the system page size.  This limit  affects  mlock(2)  and
      mlockall(2)  and  the mmap(2) MAP_LOCKED operation.  Since Linux
      2.6.9 it also affects the shmctl(2) SHM_LOCK operation, where it
      sets a maximum on the total bytes in shared memory segments (see
      shmget(2)) that may be locked by the real user ID of the calling
      process.   The  shmctl(2) SHM_LOCK locks are accounted for sepa-
      rately  from  the  per-process  memory  locks   established   by
      mlock(2),  mlockall(2),  and  mmap(2)  MAP_LOCKED; a process can
      lock bytes up to this limit in each of these two categories.  In
      Linux  kernels before 2.6.9, this limit controlled the amount of
      memory that could be locked  by  a  privileged  process.   Since
      Linux 2.6.9, no limits are placed on the amount of memory that a
      privileged process may lock, and this limit instead governs  the
      amount of memory that an unprivileged process may lock. [...]"
   (getrlimit(2), man-pages-2.07)

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Arjan van de Ven]

`
> 
> 1. What is the reason we're having special treatment
>    for the super-user here?

it's quite common to allow root (or more specific, the right capability)
to override rlimits. Many such security check behave that way so it's
only "just" to treat this one like that as well.


> 2. Why is it the opposite of what 2.6.8.1 and earlier did?

the earlier behavior didn't really make sense, and gave cause to
multimedia apps running as root only to be able to mlock etc etc. Now
this can be dynamically controlled instead.


> 4. Is the default hard limit of 32 kB initialized by the kernel or

the kernel has a relatively low default. The reason is simple: allow too
much mlock and the user can DoS the machine too easy. The kernel default
should be safe, the admin / distro can very easily override anyway.

You may ask: why is it not zero?
It is very useful for many things to have a "small" mlock area. gpg, ssh
and basically anything that works with keys and passwords. Small
relative to the other resources such a process takes (eg kernel stacks
etc).

Re: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

On Mon, 23 Jan 2006, Arjan van de Ven wrote:

> `
> > 
> > 1. What is the reason we're having special treatment
> >    for the super-user here?
> 
> it's quite common to allow root (or more specific, the right capability)
> to override rlimits. Many such security check behave that way so it's
> only "just" to treat this one like that as well.

Why is RLIMIT_MEMLOCK special enough to warrant special treatment like
this? The right capability should be able to override with setrlimit(2)
anyways, right?

> > 2. Why is it the opposite of what 2.6.8.1 and earlier did?
> 
> the earlier behavior didn't really make sense, and gave cause to
> multimedia apps running as root only to be able to mlock etc etc. Now
> this can be dynamically controlled instead.

Quoting the manpage: "In Linux kernels before 2.6.9, this limit
controlled the amount of memory that could be locked by a privileged
process."

This is nonsense, and it appears as though 2.6.8 and earlier didn't
apply the limit to unprivileged processes. Should the behavior stay as
inconsistent as it's now, I'd suggest to reword this to "...before
2.6.9, this limit controlled the amount of memory that could be locked
by /any/ process." or something even better if someone can think of
such. (manpages maintainer Cc'd)

> > 4. Is the default hard limit of 32 kB initialized by the kernel or
> 
> the kernel has a relatively low default. The reason is simple: allow too
> much mlock and the user can DoS the machine too easy. The kernel default
> should be safe, the admin / distro can very easily override anyway.

This doesn't appear to happen for SUSE 10.0, which causes trouble with
some of the "multimedia apps" BTW... apparently the limit was lowered at
the same time as the root restrictions were relaxed.

Such changes in behavior aren't adequate for 2.6.X, there are way too
many applications that can't be bothered to check the patchlevel of the
kernel, and it's totally unintuitive to users, too. Aside from the fact
that most distros have settled on one kernel.

> You may ask: why is it not zero?

No, I'm not doing that. I rather wonder why it's so low, or whom a certain
percentage such as RAM >> 5 (that's 3.125 %) would hurt. Allowing
unlimited memory allocation while at the same time allowing only 32 kB
of mlock()ed memory seems disproportionate to me.

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Arjan van de Ven]

> > > 4. Is the default hard limit of 32 kB initialized by the kernel or
> > 
> > the kernel has a relatively low default. The reason is simple: allow too
> > much mlock and the user can DoS the machine too easy. The kernel default
> > should be safe, the admin / distro can very easily override anyway.
> 
> This doesn't appear to happen for SUSE 10.0, which causes trouble with
> some of the "multimedia apps" BTW... apparently the limit was lowered at
> the same time as the root restrictions were relaxed.

yes the behavior is like this

                 root                non-root
before        about half of ram      nothing
after         all of ram             by default small, increasable


> Such changes in behavior aren't adequate for 2.6.X, there are way too
> many applications that can't be bothered to check the patchlevel of the
> kernel, and it's totally unintuitive to users, too. 

there is NO fundamental change here other than a *general* relaxing.
This is important to note: Apps that could mlock before STILL can mlock.
Only apps that would depend on mlock failing with a security check, and
only those who do small portions, break now because suddenly the mlock
succeeds. Big deal... those would have broken when run as root already

> No, I'm not doing that. I rather wonder why it's so low, or whom a certain
> percentage such as RAM >> 5 (that's 3.125 %) would hurt. A

because it's generally a PER PROCESS limit, so fork 60 times and kaboom
things explode. (You can argue  you can forkbomb anyway, but that's
where the process count rlimit comes in)

> Allowing
> unlimited memory allocation while at the same time allowing only 32 kB
> of mlock()ed memory seems disproportionate to me.

it's not. Normal memory is swapable. And thus a far less rare commodity
than precious pinned down memory.

What application do you have in mind that broke by this relaxing of
rules?

Re: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

On Mon, 23 Jan 2006, Arjan van de Ven wrote:

> yes the behavior is like this
> 
>                  root                non-root
> before        about half of ram      nothing
> after         all of ram             by default small, increasable
> [...]
> What application do you have in mind that broke by this relaxing of
> rules?

This is not something I'd like to disclose here yet.

It is an application that calls mlockall(MCL_CURRENT|MCL_FUTURE) and
apparently copes with mlockall() returning EPERM (or doesn't even try
it) but can apparently NOT cope with valign() tripping over mmap() ==
-1/EAGAIN.

The relevant people are Bcc:d.

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Arjan van de Ven]

On Mon, 2006-01-23 at 19:01 +0100, Matthias Andree wrote:
> On Mon, 23 Jan 2006, Arjan van de Ven wrote:
> 
> > yes the behavior is like this
> > 
> >                  root                non-root
> > before        about half of ram      nothing
> > after         all of ram             by default small, increasable
> > [...]
> > What application do you have in mind that broke by this relaxing of
> > rules?
> 
> This is not something I'd like to disclose here yet.
> 
> It is an application that calls mlockall(MCL_CURRENT|MCL_FUTURE) and
> apparently copes with mlockall() returning EPERM 

hmm... curious that mlockall() succeeds with only a 32kb rlimit....

Re: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

On Mon, 23 Jan 2006, Arjan van de Ven wrote:

> hmm... curious that mlockall() succeeds with only a 32kb rlimit....

It's quite obvious with the seteuid() shuffling behind the scenes of the
app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0.

Clearly the application should do both with the same privilege or raise
the RLIMIT_MEMLOCK while running with privileges.

The question that's open is one for the libc guys: malloc(), valloc()
and others seem to use mmap() on some occasions (for some allocation
sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and
if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc
is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and
then drops privileges.

The function in question appears to be valloc() with glibc 2.3.5.

In this light, mlockall(MCL_FUTURE) is pretty useless, since there is no
way to undo MCL_FUTURE without unlocking all pages at the same time.
Particularly so for setuid apps...

I'm asking the Bcc'd gentleman to reconsider mlockall() and perhaps use
explicit mlock() instead.

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Arjan van de Ven]

On Mon, 2006-01-23 at 19:55 +0100, Matthias Andree wrote:
> On Mon, 23 Jan 2006, Arjan van de Ven wrote:
> 
> > hmm... curious that mlockall() succeeds with only a 32kb rlimit....
> 
> It's quite obvious with the seteuid() shuffling behind the scenes of the
> app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0.

hmm how on earth was that supposed to work at all????

Re: Rationale for RLIMIT_MEMLOCK?

[Joerg Schilling]

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

> On Mon, 23 Jan 2006, Arjan van de Ven wrote:
>
> > hmm... curious that mlockall() succeeds with only a 32kb rlimit....
>
> It's quite obvious with the seteuid() shuffling behind the scenes of the
> app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0.
>
> Clearly the application should do both with the same privilege or raise
> the RLIMIT_MEMLOCK while running with privileges.
>
> The question that's open is one for the libc guys: malloc(), valloc()
> and others seem to use mmap() on some occasions (for some allocation
> sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and
> if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc
> is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and
> then drops privileges.

If the behavior described by Matthias is true for current Linuc kernels,
then there is a clean bug that needs fixing.

If the Linux kernel is not willing to accept the contract by 
mlockall(MLC_FUTURE), then it should now accept the call at all.

In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later 
ignores this contract. This bug should be fixed.

Jörg

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

Re: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-23:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > On Mon, 23 Jan 2006, Arjan van de Ven wrote:
> >
> > > hmm... curious that mlockall() succeeds with only a 32kb rlimit....
> >
> > It's quite obvious with the seteuid() shuffling behind the scenes of the
> > app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0.
> >
> > Clearly the application should do both with the same privilege or raise
> > the RLIMIT_MEMLOCK while running with privileges.
> >
> > The question that's open is one for the libc guys: malloc(), valloc()
> > and others seem to use mmap() on some occasions (for some allocation
> > sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and
> > if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc
> > is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and
> > then drops privileges.
> 
> If the behavior described by Matthias is true for current Linuc kernels,
> then there is a clean bug that needs fixing.

Jörg elided my lines that said valloc() was the function in question.

Jörg, if we're talking about valloc(), this hasn't much to do with the
kernel, but is a library issue.

There is _no_ documentation that says valloc() or memalign() or
posix_memalign() is required to use mmap(). It works on some systems and
for some allocation sizes as a side effect of the valloc()
implementation.

And because this requirement is not specified in the relevant standards,
it is wrong to assume valloc() returns locked pages. You cannot rely on
mmap() returning locked pages after mlockall() either, because you might
be exceeding resource limits.

> If the Linux kernel is not willing to accept the contract by 
> mlockall(MLC_FUTURE), then it should now accept the call at all.

If the application wants locked pages, it either needs to call mmap()
explicitly, or use mlock() on the valloc()ed region. Even then,
allocation or mlock may fail due to resource constraints. I checked
FreeBSD 6-STABLE i386, Solaris 8 FCS SPARC and SUSE Linux 10.0 i386 on
this.

> In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later 
> ignores this contract. This bug should be fixed.

The complete story is, condensed, and with return values, for a
setuid-root application:

  geteuid() == 0;
  mlockall(MLC_CURRENT|MLC_FUTURE) == (success);
  seteuid(500) == (success);
  valloc(64512 + pagesize) == NULL (failure);

Jörg, correct me if the valloc() figure is wrong.

valloc() called mmap() internally, tried to grab 1 MB, and failed with
EAGAIN - as we were able to see from the strace.

SuSE Linux 10.0, kernel 2.6.13-15.7-default #1 Tue Nov 29 14:32:29 UTC 2005
on i686 athlon i386 GNU/Linux

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Joerg Schilling]

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

> > If the behavior described by Matthias is true for current Linuc kernels,
> > then there is a clean bug that needs fixing.
>
> Jörg elided my lines that said valloc() was the function in question.
>
> Jörg, if we're talking about valloc(), this hasn't much to do with the
> kernel, but is a library issue.

>From my understanding, the problem is that Linux first grants the 
mlockall(MLC_FUTURE) call and later ignores this contract.

The fact that valloc() works in a way that is not comprehensible
seems to be another issue. Libscg calls valloc(size) where size is less than
64 KB. From the strace output from Matthias, it looks like valloc first calls 
brk() to extend the size of the data segment (probably to aproach the next
pagesize aligned border) and later calls mmap() to get 1 MB or memory.
Well first it seems that valloc() tries to get too much memory but this 
is another story.

Inside the kernel handler for this call, the permission to lock the new 
memory _again_ checks for permission and this is wrong as the request
for locking all future pages of the process already has been granted.

This looks similar to when I open() a file that may only be opened as root
and late switch my uid to some other id. If read() would be implemented the 
same way as Linux implements the locking, each read() call would again check
whether the current uid would have permission to get access to the fd from a 
filename. This is obviously wrong. The _process_ has been granted the rights 
to mlock all future pages and this is something that needs to be nonored until 
the process dies.

> There is _no_ documentation that says valloc() or memalign() or
> posix_memalign() is required to use mmap(). It works on some systems and
> for some allocation sizes as a side effect of the valloc()
> implementation.

The problem seems to be independend how valloc() is implemented.


> And because this requirement is not specified in the relevant standards,
> it is wrong to assume valloc() returns locked pages. You cannot rely on
> mmap() returning locked pages after mlockall() either, because you might
> be exceeding resource limits.

If there were such resource limits, then they would need to be honored
regardless of the privileges of the process.


> > If the Linux kernel is not willing to accept the contract by 
> > mlockall(MLC_FUTURE), then it should now accept the call at all.
>
> If the application wants locked pages, it either needs to call mmap()
> explicitly, or use mlock() on the valloc()ed region. Even then,
> allocation or mlock may fail due to resource constraints. I checked
> FreeBSD 6-STABLE i386, Solaris 8 FCS SPARC and SUSE Linux 10.0 i386 on
> this.

What did you check?

Solaris does not check for any privileges whan calling mmap()

Solaris implements mlockall() via memcntl which contains the only 
place where a check for secpolicy_lock_memory(CRED()) takes place.

> > In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later 
> > ignores this contract. This bug should be fixed.
>
> The complete story is, condensed, and with return values, for a
> setuid-root application:
>
>   geteuid() == 0;
>   mlockall(MLC_CURRENT|MLC_FUTURE) == (success);
>   seteuid(500) == (success);
>   valloc(64512 + pagesize) == NULL (failure);
>
> Jörg, correct me if the valloc() figure is wrong.
>
> valloc() called mmap() internally, tried to grab 1 MB, and failed with
> EAGAIN - as we were able to see from the strace.

This is correct.

Returning EAGAIN seems to be a result of missunderstanding the POSIX
standard. The POSIX standard means real hardware resources when talking about

EAGAIN] 
        [ML]  The mapping could not be locked in memory, if required by 
	mlockall(), due to a lack of resources.  

If linux likes to ass a new RLIMIT_MEMLOCK resource, it would be needed to 
honor this resource independent from the user id in order to prevent being 
contradictory.

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: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-23:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > > If the behavior described by Matthias is true for current Linuc kernels,
> > > then there is a clean bug that needs fixing.
> >
> > Jörg elided my lines that said valloc() was the function in question.
> >
> > Jörg, if we're talking about valloc(), this hasn't much to do with the
> > kernel, but is a library issue.
> 
> From my understanding, the problem is that Linux first grants the 
> mlockall(MLC_FUTURE) call and later ignores this contract.
...
> Inside the kernel handler for this call, the permission to lock the new 
> memory _again_ checks for permission and this is wrong as the request
> for locking all future pages of the process already has been granted.

I *do* think that the kernel refused our mmap() request on grounds of
the RLIMIT_MEMLOCK (32 kB) and not any other reason, because running the
same allocation code as root succeeds, and Linux 2.6.13 is documented to
ignore RLIMIT_MEMLOCK for the super-user.

And I do believe Linux is entirely on IEEE Std 1003.1-2001 grounds here.

> > There is _no_ documentation that says valloc() or memalign() or
> > posix_memalign() is required to use mmap(). It works on some systems and
> > for some allocation sizes as a side effect of the valloc()
> > implementation.
> 
> The problem seems to be independend how valloc() is implemented.

As far as the kernel is concerned, yes.

As far as your application is concerned, valloc() does not provide
"mapped" or "locked" pages, but "allocated".

> > And because this requirement is not specified in the relevant standards,
> > it is wrong to assume valloc() returns locked pages. You cannot rely on
> > mmap() returning locked pages after mlockall() either, because you might
> > be exceeding resource limits.
> 
> If there were such resource limits, then they would need to be honored
> regardless of the privileges of the process.

That's a different story.

> > > If the Linux kernel is not willing to accept the contract by 
> > > mlockall(MLC_FUTURE), then it should now accept the call at all.
> >
> > If the application wants locked pages, it either needs to call mmap()
> > explicitly, or use mlock() on the valloc()ed region. Even then,
> > allocation or mlock may fail due to resource constraints. I checked
> > FreeBSD 6-STABLE i386, Solaris 8 FCS SPARC and SUSE Linux 10.0 i386 on
> > this.
> 
> What did you check?

The mlockall() documentation. Any OS allows later mappings to fail if
they cannot be locked, and this is what happens.

The only troublesome spot that remains is valloc() using mmap()
internally, which inherits the mlockall()/mmap() failure modes and
causes bogus "out of memory" returns by valloc().

1. valloc is not required to lock pages
2. yet it can fail if it cannot lock pages

This is a problem from the applications POV, albeit one that is in
glibc's memory allocator.

mlockall() does NOT make promises HOW MUCH memory may be allocated in
the future, and that is the problem at hand. Linux allows us 32 kB (as
unprivileged user even, we don't get that with Solaris or FreeBSD!), but
we want 63 kB and Linux says "Sorry, you can't have that. EAGAIN"

> Returning EAGAIN seems to be a result of missunderstanding the POSIX
> standard. The POSIX standard means real hardware resources when talking about

Well... mlockall() allows for, "other implementation-defined limit[s]",
so POSIX is not supportive of your argument here.

> EAGAIN] 
>         [ML]  The mapping could not be locked in memory, if required by 
> 	mlockall(), due to a lack of resources.  
> 
> If linux likes to ass a new RLIMIT_MEMLOCK resource, it would be needed to 
> honor this resource independent from the user id in order to prevent being 
> contradictory.

This is irrelevant to cdrecord, because it does not trip over this
contradiction.

If I were the cdrecord maintainer, I'd forget about mlockall()
altogether because it's just too broad and doesn't allow something like
"no more auto locking" without unlocking all locked pages (see also Lee
Revell's earlier post), lock the FIFO, command data buffers and
everything explicitly through mlock(), set the scheduler, open the
device and then call setuid() to get rid of the saved set-user-id as
well. This may be narrow-minded, but given mlock() is present in the BSD
world (FreeBSD, NetBSD), in the SysV world (Solaris) and Linux, there's
reason to support it, as these constitute a large user base.

If anything then still fails (command filter), I'd ask the kernel guys
how the restriction can be lifted so that cdrecord can work without ANY
root privileges, in the most portable way.

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Arjan van de Ven]

> c() was the function in question.
> 
> Jörg, if we're talking about valloc(), this hasn't much to do with the
> kernel, but is a library issue.
> 
> There is _no_ documentation that says valloc() or memalign() or
> posix_memalign() is required to use mmap(). It works on some systems and
> for some allocation sizes as a side effect of the valloc()
> implementation.

it doesn't matter. Regardless of the method, the memory has to be locked
due to the FUTURE requirement.



> And because this requirement is not specified in the relevant standards,
> it is wrong to assume valloc() returns locked pages. 

is it? I sort of doubt that (but I'm not a standards expert, but I'd
expect that "lock all in the future" applies to all memory, not just
mmap'd memory

> You cannot rely on
> mmap() returning locked pages after mlockall() either, because you might
> be exceeding resource limits.

this is true and fully correct



the situation is messy; I can see some value in the hack Ted proposed to
just bump the rlimit automatically at an mlockall-done-by-root.. but to
be fair it's a hack :(

Re: Rationale for RLIMIT_MEMLOCK?

[Joerg Schilling]

Arjan van de Ven <arjan@infradead.org> wrote:

> > And because this requirement is not specified in the relevant standards,
> > it is wrong to assume valloc() returns locked pages. 
>
> is it? I sort of doubt that (but I'm not a standards expert, but I'd
> expect that "lock all in the future" applies to all memory, not just
> mmap'd memory

I concur:

Locking pages into core is a property/duty of the VM subsystem.
If you have an orthogonal VM subsystem, you cannot later tell how a page was 
mapped into the user's address space. Even more: you may map a file to a 
alocation in the data segment of the proces (that has been retrieved via 
malloc()/brk()) and replace the related mapping with a mapped file.

On Solaris, there is no difference.

>
> > You cannot rely on
> > mmap() returning locked pages after mlockall() either, because you might
> > be exceeding resource limits.
>
> this is true and fully correct
>
>
>
> the situation is messy; I can see some value in the hack Ted proposed to
> just bump the rlimit automatically at an mlockall-done-by-root.. but to
> be fair it's a hack :(

As all other rlimits are honored even if you are root, it looks not orthogonal 
to disregard an existing RLIMIT_MEMLOCK rlimit if you are root.

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: Rationale for RLIMIT_MEMLOCK?

[Arjan van de Ven]

On Tue, 2006-01-24 at 10:08 +0100, Joerg Schilling wrote:
> > the situation is messy; I can see some value in the hack Ted proposed to
> > just bump the rlimit automatically at an mlockall-done-by-root.. but to
> > be fair it's a hack :(
> 
> As all other rlimits are honored even if you are root, it looks not orthogonal 
> to disregard an existing RLIMIT_MEMLOCK rlimit if you are root.

that's another solution; give root a higher rlimit by default for this.
It's also a bit messy, but a not-unreasonable default behavior.

Re: Rationale for RLIMIT_MEMLOCK?

[Joerg Schilling]

Arjan van de Ven <arjan@infradead.org> wrote:

> On Tue, 2006-01-24 at 10:08 +0100, Joerg Schilling wrote:
> > > the situation is messy; I can see some value in the hack Ted proposed to
> > > just bump the rlimit automatically at an mlockall-done-by-root.. but to
> > > be fair it's a hack :(
> > 
> > As all other rlimits are honored even if you are root, it looks not orthogonal 
> > to disregard an existing RLIMIT_MEMLOCK rlimit if you are root.
>
> that's another solution; give root a higher rlimit by default for this.
> It's also a bit messy, but a not-unreasonable default behavior.

This would only make sense in case that you bump up the limit for processes
that are suid root and do not lower it in case someone calls seteuid().

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: Rationale for RLIMIT_MEMLOCK?

[Theodore Ts'o]

On Tue, Jan 24, 2006 at 10:15:40AM +0100, Arjan van de Ven wrote:
> On Tue, 2006-01-24 at 10:08 +0100, Joerg Schilling wrote:
> > > the situation is messy; I can see some value in the hack Ted proposed to
> > > just bump the rlimit automatically at an mlockall-done-by-root.. but to
> > > be fair it's a hack :(
> > 
> > As all other rlimits are honored even if you are root, it looks not orthogonal 
> > to disregard an existing RLIMIT_MEMLOCK rlimit if you are root.
> 
> that's another solution; give root a higher rlimit by default for this.
> It's also a bit messy, but a not-unreasonable default behavior.

I thought in the case we were talking about, the problem is that we
have a setuid program which calls mlockall() but then later drops its
privileges.  So when it tries to allocate memories, RLIMIT_MEMLOCK
applies again, and so all future memory allocations would fail.  

What I proposed is a hack, but strictly speaking not necessary
according to the POSIX standards, but the problem is that a portable
program can't be expected to know that Linux has a RLIMIT_MEMLOCK
resource limit, such that a program which calls mlockall() and then
drops privileges will work under Solaris and fail under Linux.  Hence
I why proposed a hack where mlockall() would adjust RLIMIT_MEMLOCK.
Yes, no question it's a hack and a special case; the question is
whether cure or the disease is worse.

						- Ted

Re: Rationale for RLIMIT_MEMLOCK?

[Edgar Toernig]

Theodore Ts'o wrote:
>
> ... proposed a hack where mlockall() would adjust RLIMIT_MEMLOCK.
> Yes, no question it's a hack and a special case; the question is
> whether cure or the disease is worse.

What about exec?  The memory locks are removed on exec but with that
hack the raised limit would stay.  Looks like a security bug.

Ciao, ET.

Re: Rationale for RLIMIT_MEMLOCK?

[Joerg Schilling]

Edgar Toernig <froese@gmx.de> wrote:

> Theodore Ts'o wrote:
> >
> > ... proposed a hack where mlockall() would adjust RLIMIT_MEMLOCK.
> > Yes, no question it's a hack and a special case; the question is
> > whether cure or the disease is worse.
>
> What about exec?  The memory locks are removed on exec but with that
> hack the raised limit would stay.  Looks like a security bug.

The RLIMIT_MEMLOCK feature itself may be a security bug implemented the way it 
currentlyy is.

For me it would make sense to be able to lock everything in core and then
be able to tell the system that at most 1MB of additional memory may be locked.

In this case, there should be no general failure but the possibility to
verify that the value is sufficient for usual cases.

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: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

Theodore Ts'o schrieb am 2006-01-24:

> I thought in the case we were talking about, the problem is that we
> have a setuid program which calls mlockall() but then later drops its
> privileges.  So when it tries to allocate memories, RLIMIT_MEMLOCK
> applies again, and so all future memory allocations would fail.  

That's the coarse view. In fact, the application does not call setuid()
at this time, but only seteuid(), so it can regain privileges later, and
will in fact do that.

The application in question does this:

(root here)
1 mlockall()
2 seteuid(500);  /* park privileges for a moment */
3 valloc(63 kB); /* fails since 2.6.9's tight MEMLOCK limit */

The first patch I suggested for the application exchanged steps #2 and
#3 and works, but is not acceptable to Jörg. We haven't talked about the
reasons.

The idea behind my patch was this: if it wants the memory locked (which
is a privileged operation on many systems anyways), then why not
allocate as root? Would this hurt portability to any other system? I
don't think so. Is such a rationale unreasonable in itself? Not either.

Further patch suggestions negotiated forth and back on raising the limit
and to what value.

The other problem is that glibc 2.3.5 is part of the story, but
off-topic here, because glibc is the link between valloc() (application
side) and the mmap() (kernel side).

> What I proposed is a hack, [and] strictly speaking not necessary
> according to the POSIX standards, but the problem is that a portable
> program can't be expected to know that Linux has a RLIMIT_MEMLOCK
> resource limit, such that a program which calls mlockall() and then
> drops privileges will work under Solaris and fail under Linux.  Hence
> I why proposed a hack where mlockall() would adjust RLIMIT_MEMLOCK.
> Yes, no question it's a hack and a special case; the question is
> whether cure or the disease is worse.

Is the KERNEL the right place to implement policy such as setting
locked-page limits to 32 kB?

What if the limit were RLIM_INFINITY for root processes instead of
hacking mlockall() and the resource checks?

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

Matthias Andree schrieb am 2006-01-25:

> What if the limit were RLIM_INFINITY for root processes instead of
> hacking mlockall() and the resource checks?

OK, reading Edgar's hint, the answer is "It's a bad idea."

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Joerg Schilling]

"Theodore Ts'o" <tytso@mit.edu> wrote:

> I thought in the case we were talking about, the problem is that we
> have a setuid program which calls mlockall() but then later drops its
> privileges.  So when it tries to allocate memories, RLIMIT_MEMLOCK
> applies again, and so all future memory allocations would fail.  
>
> What I proposed is a hack, but strictly speaking not necessary
> according to the POSIX standards, but the problem is that a portable
> program can't be expected to know that Linux has a RLIMIT_MEMLOCK
> resource limit, such that a program which calls mlockall() and then
> drops privileges will work under Solaris and fail under Linux.  Hence
> I why proposed a hack where mlockall() would adjust RLIMIT_MEMLOCK.
> Yes, no question it's a hack and a special case; the question is
> whether cure or the disease is worse.

Maybe, I should give some hints...

RLIMIT_MEMLOCK did first apear in BSD-4.4 around 1994.
The iplementation is incomplete since then and partially disabled (size check 
for mmap() in the kernel) on FreeBSD as it has been 1994 on BSD-4.4

FreeBSD currently uses a default value of RLIMIT_INFINITY for users.

I could add this piece of code to the euid == 0 part of cdrecord:

LOCAL void 
raise_memlock() 
{ 
#ifdef  RLIMIT_MEMLOCK 
        struct rlimit rlim; 
 
        rlim.rlim_cur = rlim.rlim_max = RLIM_INFINITY; 
 
        if (setrlimit(RLIMIT_MEMLOCK, &rlim) < 0) 
                errmsg("Warning: Cannot raise RLIMIT_MEMLOCK limits."); 
#endif  /* RLIMIT_NOFILE */ 
} 

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: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

Joerg Schilling wrote:

> RLIMIT_MEMLOCK did first apear in BSD-4.4 around 1994.
> The iplementation is incomplete since then and partially disabled (size check 
> for mmap() in the kernel) on FreeBSD as it has been 1994 on BSD-4.4
> 
> FreeBSD currently uses a default value of RLIMIT_INFINITY for users.

And while it does that (or in fact, rather not distinguish between root and
unprivileged users), mlock() and mlockall() are privileged operations on
FreeBSD.

> I could add this piece of code to the euid == 0 part of cdrecord:
> 
> LOCAL void 
> raise_memlock() 
> { 
> #ifdef  RLIMIT_MEMLOCK 
>         struct rlimit rlim; 
>  
>         rlim.rlim_cur = rlim.rlim_max = RLIM_INFINITY; 
>  
>         if (setrlimit(RLIMIT_MEMLOCK, &rlim) < 0) 
>                 errmsg("Warning: Cannot raise RLIMIT_MEMLOCK limits."); 
> #endif  /* RLIMIT_NOFILE */ 
> } 

Except that your new #endif comment is wrong, that is exactly what I
suggested and what I've tried and found working.

Re: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-24:

> Arjan van de Ven <arjan@infradead.org> wrote:
> 
> > > And because this requirement is not specified in the relevant standards,
> > > it is wrong to assume valloc() returns locked pages. 
> >
> > is it? I sort of doubt that (but I'm not a standards expert, but I'd
> > expect that "lock all in the future" applies to all memory, not just
> > mmap'd memory
> 
> I concur:
> 
> Locking pages into core is a property/duty of the VM subsystem.

But where is this laid down in the standard? There must be some part
that defines this, else we cannot rely on it. The wording for malloc()
and mmap() or mlock() is different. One talks about address space and
mapping, whereas malloc() talks about "storage".

Only I haven't got time to look for it now. Just that Solaris happens to
do it doesn't make it a standard.

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Lee Revell]

On Mon, 2006-01-23 at 20:38 +0100, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > On Mon, 23 Jan 2006, Arjan van de Ven wrote:
> >
> > > hmm... curious that mlockall() succeeds with only a 32kb rlimit....
> >
> > It's quite obvious with the seteuid() shuffling behind the scenes of the
> > app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0.
> >
> > Clearly the application should do both with the same privilege or raise
> > the RLIMIT_MEMLOCK while running with privileges.
> >
> > The question that's open is one for the libc guys: malloc(), valloc()
> > and others seem to use mmap() on some occasions (for some allocation
> > sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and
> > if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc
> > is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and
> > then drops privileges.
> 
> If the behavior described by Matthias is true for current Linuc kernels,
> then there is a clean bug that needs fixing.
> 
> If the Linux kernel is not willing to accept the contract by 
> mlockall(MLC_FUTURE), then it should now accept the call at all.
> 
> In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later 
> ignores this contract. This bug should be fixed.

Joerg,

You will be happy to know that in future Linux distros, cdrecord will
not require setuid to mlock() and get SCHED_FIFO - both are now
controlled by rlimits, so if the distro ships with a sane PAM/group
configuration, all you will need to do is add cdrecord users to the
"realtime" or "cdrecord" or "audio" group.

This will take a while to make it into distros as it requires changes to
PAM and glibc in addition to the kernel.

Lee

CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Matthias Andree]

On Mon, 23 Jan 2006, Lee Revell wrote:

> You will be happy to know that in future Linux distros, cdrecord will
> not require setuid to mlock() and get SCHED_FIFO - both are now
> controlled by rlimits, so if the distro ships with a sane PAM/group
> configuration, all you will need to do is add cdrecord users to the
> "realtime" or "cdrecord" or "audio" group.

Sounds really good. Can you give a pointer as to the detailed rlimit
requirements?

Anyways, this seems like a very good point in time to pick up the old
discussion of ide-scsi, ide-cd and thereabouts, because your
announcement met Jörg's criterion that Linux had to make a step forward
in his direction before he'd try to negotiate again.

I'm more of a user who is annoyed by this war of warning messages
(ide-scsi claiming it's unsuitable for CD writing, cdrecord calling
/dev/hd* badly designed, and all that), and I'd appreciate if people
could just

1. compile a list of their requirements,

2. find out the current state of affairs,

3. match the lists found in 1 and 2

4. ONLY AFTER THAT negotiate who is going to change what to make things
   work better for us end users.

Of course, I think it's sensible to expect that Linux should adhere to
standards (POSIX) as far as possible, and if any precedent
implementations that are standards-conformant are found, I'd suggest
that Linux adheres to their interpretation, too, to reduce the clutter
and make applications more easily ported to Linux. We'll all benefit.

LIST 1 # REQUIREMENTS

R1 I'll just say we all want cdrecord, dvd recording applications and
similar to work without setuid root flags or sudo or other excessive
privilege escalation. (This needs to be split up into I/O access
privileges, device enumeration, buffer allocation, real-time
requirements such as locking buffers into memory, scheduling and so on.)

LIST 2 # CURRENT STATE

S1 Jörg is unhappy with /dev/hd* because he says that it is inferior to
the sg-access via ide-scsi. (I believe the original issues were
DMA-based, and I don't know the details.) I hope Jörg will fill in the
operations that ide-cd (/dev/hd*) lacks. (Jörg, please don't talk about
layer violations here).

S2 Jörg is concerned about the SCSI command filter being too
restrictive. I'm not sure if it still applies to 2.6.16-rc and what the
exact commands in question were. I'll let Jörg complete this list.

S3 Device enumeration/probing is a sore spot. Unprivileged "cdrecord
dev=ATA: -scandisk" doesn't work, and recent discussions on the cdwrite@
list didn't make any progress. My observation is that cdrecord stops
probing /dev/hd* devices as soon as one yields EPERM, on the assumption
"if I cannot access /dev/hda, I will not have sufficient privilege to
write a CD anyways". I find this wrong, Jörg finds it correct and argues
"if you can access /dev/hdc as unprivileged user, that's a security
problem".

These topics I brought up are my recollections from memory, without
archive research, that I deem worth developing into either requirements
or "state-of-the-art" assertions of the "we're already there" kind.

Please, everybody, ONLY list what you would like to do, why, why it
doesn't work. Please DO NOT TELL THE OTHER SIDE HOW they are supposed to
do it, unless it's worded as a polite and patient question. We've been
there, and it didn't work.

I hope this is getting a more fruitful discussion than last time.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Lee Revell]

On Mon, 2006-01-23 at 22:21 +0100, Matthias Andree wrote:
> Sounds really good. Can you give a pointer as to the detailed rlimit
> requirements? 

I don't want to touch the rest of the thread, but the best info on the
above can be found in the linux-audio-user list archives.  It's still a
little unclear exactly which packages are required, but IIRC PAM 0.80
supports it already.  I believe this requires glibc changes eventually,
but programs like PAM and bash that deal with rlimits can work around it
if glibc is not aware of the new rlimit.

Personally I still use the old realtime LSM, until this is all worked
out.

Lee

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

Lee Revell <rlrevell@joe-job.com> wrote:

> On Mon, 2006-01-23 at 22:21 +0100, Matthias Andree wrote:
> > Sounds really good. Can you give a pointer as to the detailed rlimit
> > requirements? 
>
> I don't want to touch the rest of the thread, but the best info on the
> above can be found in the linux-audio-user list archives.  It's still a
> little unclear exactly which packages are required, but IIRC PAM 0.80
> supports it already.  I believe this requires glibc changes eventually,
> but programs like PAM and bash that deal with rlimits can work around it
> if glibc is not aware of the new rlimit.

Could you explain this more in depth?

What you describe looks like you propose to add a line:

joerg::::defaultpriv=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr

to /etc/user_attr which would be honored by PAM during login.

This is not what I like to see.

What I like to see is that only specific programs like cdrecord
would get the permissions to do more than joe user.

Jörg

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Lee Revell]

On Mon, 2006-01-23 at 22:45 +0100, Joerg Schilling wrote:
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Mon, 2006-01-23 at 22:21 +0100, Matthias Andree wrote:
> > > Sounds really good. Can you give a pointer as to the detailed rlimit
> > > requirements? 
> >
> > I don't want to touch the rest of the thread, but the best info on the
> > above can be found in the linux-audio-user list archives.  It's still a
> > little unclear exactly which packages are required, but IIRC PAM 0.80
> > supports it already.  I believe this requires glibc changes eventually,
> > but programs like PAM and bash that deal with rlimits can work around it
> > if glibc is not aware of the new rlimit.
> 
> Could you explain this more in depth?
> 
> What you describe looks like you propose to add a line:
> 
> joerg::::defaultpriv=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr
> 
> to /etc/user_attr which would be honored by PAM during login.
> 
> This is not what I like to see.
> 
> What I like to see is that only specific programs like cdrecord
> would get the permissions to do more than joe user.

It's not that fine grained, it works at a user/group level.

You would add a line like:

@cdrecord        hard    rtprio           80

to /etc/security/limits.conf and add users to the cdrecord group.

Lee

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Lee Revell]

On Mon, 2006-01-23 at 22:21 +0100, Matthias Andree wrote:
> On Mon, 23 Jan 2006, Lee Revell wrote:
> 
> > You will be happy to know that in future Linux distros, cdrecord will
> > not require setuid to mlock() and get SCHED_FIFO - both are now
> > controlled by rlimits, so if the distro ships with a sane PAM/group
> > configuration, all you will need to do is add cdrecord users to the
> > "realtime" or "cdrecord" or "audio" group.
> 
> Sounds really good. Can you give a pointer as to the detailed rlimit
> requirements?

One thing I believe is still unresolved is that despite the new rlimits,
sched_get_priority_max(SCHED_FIFO) always returns 99 rather than
RLIMIT_RTPRIO.

Lee 

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

> S2 Jörg is concerned about the SCSI command filter being too
> restrictive. I'm not sure if it still applies to 2.6.16-rc and what the
> exact commands in question were. I'll let Jörg complete this list.

I am tired today and I need to do other work, so let me parly reply:

Iff there is a user space infrastructure for fine grained privileges,
there is absolutely no problem with a planned and well known restriction.

On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
that calls getexecuser() in order to find whether there is a specific treatment 
needed. If this specific treatment is needed, then the shell calls 
execve(/usr/bin/pfexec cmd <args>)
else it calls  execve(cmd <args>)

I did recently voted to require all shells to be profile enabled by default.

With the future plans for extending fine grained privs on Solaris, sending
SCSI commands will become more than one priv.

I proposed to have a low priv right to send commands like inquiry and test unit 
ready. These commands may e.g. be send without interfering a concurrent CD/DVD 
write operation.

The next priv could be the permission for sending simple SCSI commands that 
allow reading from the device.

The next priv could be the permission for sending simple SCSI Commands that
allow writing.

The final priv would allow even vendor specific commands: this is what cdrecord 
needs.

Jörg

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

> Of course, I think it's sensible to expect that Linux should adhere to
> standards (POSIX) as far as possible, and if any precedent
> implementations that are standards-conformant are found, I'd suggest
> that Linux adheres to their interpretation, too, to reduce the clutter
> and make applications more easily ported to Linux. We'll all benefit.

With respect to SCSI transport, it would also make sense tolook at the 
implementations of various other platforms.


> LIST 1 # REQUIREMENTS
>
> R1 I'll just say we all want cdrecord, dvd recording applications and
> similar to work without setuid root flags or sudo or other excessive
> privilege escalation. (This needs to be split up into I/O access
> privileges, device enumeration, buffer allocation, real-time
> requirements such as locking buffers into memory, scheduling and so on.)

With fine grained privileges and a nice inherent user level framework, this 
kind of problems should not apear inside cdrecord at all.


> LIST 2 # CURRENT STATE
>
> S1 Jörg is unhappy with /dev/hd* because he says that it is inferior to
> the sg-access via ide-scsi. (I believe the original issues were
> DMA-based, and I don't know the details.) I hope Jörg will fill in the
> operations that ide-cd (/dev/hd*) lacks. (Jörg, please don't talk about
> layer violations here).

One original issue was that ide-scsi did cause a kernel panic in case it
was used on top of PCMCIA based ATA.

The other issue is that ide-scsi does not do DMA in case DMA-size is not
a multiple of 512 while is is needed for any size % 4 == 0;
or at least size % 8 == 0


> S2 Jörg is concerned about the SCSI command filter being too
> restrictive. I'm not sure if it still applies to 2.6.16-rc and what the
> exact commands in question were. I'll let Jörg complete this list.

If this change had been announced early anough and if there was a workaround,
there would be no problem. The problem was that someone has a bad dream and
incompatibly changed the Linux kernel over night while cdrecord was in code 
freeze. Later I was called unflexible because I did follow the well known 
quality ensuring rules that are in effect short before a new stable/final 
released is published.


> S3 Device enumeration/probing is a sore spot. Unprivileged "cdrecord
> dev=ATA: -scandisk" doesn't work, and recent discussions on the cdwrite@
> list didn't make any progress. My observation is that cdrecord stops
> probing /dev/hd* devices as soon as one yields EPERM, on the assumption
> "if I cannot access /dev/hda, I will not have sufficient privilege to
> write a CD anyways". I find this wrong, Jörg finds it correct and argues
> "if you can access /dev/hdc as unprivileged user, that's a security
> problem".

This are two problems:

-	users of cdrecord like to run cdrecord -scanbus in order to find all
	SCSI devices. This no longer works since the non-orthogonal /dev/hd* 
	SCSI transport has been added.

	As Linux already implements a Generic SCSI transport interface 
	(/dev/sg*) people would asume to be able to talk to _all_ SCSI devices
	using this interface. To allows this, there is a need for a 
	SCSI HBA driver that sends SCSI commands via a ATA interface.

-	some people seem to set the permissions of some of the /dev/hd* 
	nodes to unsafe values and then complain that the other /dev/hd* 
	nodes cannot be opened.

Jörg

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3094 bytes --]


I'm joining in,
>
>1. compile a list of their requirements,

Have as few code duplicated (e.g. ATAPI and SCSI may share some - after 
all, ATAPI is (to me) some sort of SCSI tunneled in ATA.)

Make it, in accordance with the above, possible to have as few kernel 
modules loaded as possible and therefore reducing footprint - if I had not 
to load sd_mod for usb_storage fun, I would get an itch to load a 78564 
byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.)

Want to write CDs and DVDs "as usual" (see below).

De-forest the SCSI subsystem for privilege checking (see below).


>2. find out the current state of affairs,

I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW, 
DVD-DL with no problems using
    cdrecord -dev=/dev/hdb
it _currently_ works, no matter how ugly or not this is from either Jörg's 
or any other developer's POV - therefore it's fine from the end-user's POV.

I can write DVDs at 8x speed (approx 10816 KB/sec) - which looks like DMA 
is working through the current mechanism, although I can't confirm it.

There have been reports that cdrecord does not work when setuid, but only 
when you are "truly root". Not sure where this comes from,
(current->euid==0&&current->uid!=0 maybe?) scsi layer somewhere?

I'm fine (=I agree) with the general possibility of having it setuid, 
though.

>3. match the lists found in 1 and 2
>
>4. ONLY AFTER THAT negotiate who is going to change what to make things
>   work better for us end users.

>S3 Device enumeration/probing is a sore spot. Unprivileged "cdrecord
>dev=ATA: -scandisk" doesn't work, and recent discussions on the cdwrite@
>list didn't make any progress. My observation is that cdrecord stops
>probing /dev/hd* devices as soon as one yields EPERM, on the assumption
>"if I cannot access /dev/hda, I will not have sufficient privilege to
>write a CD anyways". I find this wrong, Jörg finds it correct and argues
>"if you can access /dev/hdc as unprivileged user, that's a security
>problem".

If you can access a _harddisk_ as a normal user, you _do have_ a security 
problem. If you can access a cdrom as normal user, well, the opinions 
differ here. I think you _should not either_, because it might happen that 
you just left your presentation cd in a cdrom device in a public box. You 
would certainly not want to have everyone read that out.

SUSE currently does it in A Nice Way: setfacl'ing the devices to include 
read access for currently logged-in users. (Well, if someone logs on tty1 
after you, you're screwed anyway - he could have just ejected the cd when 
he's physically at the box.)

Yes, the device numbering is not optimal. (I already hear someone saying 
'have udev make some sweety symlink in /dev'.)
But in case of /dev/hd*, we are pretty sure of what device is connected 
where. In case of sd*, it's AFAICS not - the next device plugged in gets 
the next free sd slot.


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

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

[Matthias Andree]

Jan Engelhardt schrieb am 2006-01-24:

> >2. find out the current state of affairs,
> 
> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW, 
> DVD-DL with no problems using
>     cdrecord -dev=/dev/hdb
> it _currently_ works, no matter how ugly or not this is from either Jörg's 
> or any other developer's POV - therefore it's fine from the end-user's POV.

cdrecord simply assumes that if you don't have access to /dev/hda,
scanning the other devices is pointless, on the assumption it were a
security risk. How this fits into user profiles that might allow access
to /dev/hdc, is unclear to me.

> I can write DVDs at 8x speed (approx 10816 KB/sec) - which looks like DMA 
> is working through the current mechanism, although I can't confirm it.

/dev/hd* and ATA: support DMA, newer cdrecord versions actually check
the DMA speed before starting write operations without burnproof.

> There have been reports that cdrecord does not work when setuid, but only 
> when you are "truly root". Not sure where this comes from,
> (current->euid==0&&current->uid!=0 maybe?) scsi layer somewhere?

Locking pages in memory so they aren't swapped out (a requirement for
real-time applications) -- that's the original reason for my
RLIMIT_MEMLOCK question that preceded this thread.

> If you can access a _harddisk_ as a normal user, you _do have_ a security 
> problem. If you can access a cdrom as normal user, well, the opinions 
> differ here. I think you _should not either_, because it might happen that 
> you just left your presentation cd in a cdrom device in a public box. You 
> would certainly not want to have everyone read that out.

That's less of a problem than sending vendor-specific commands - one
might be "update firmware", which would allow the user to destroy the
drive.

> SUSE currently does it in A Nice Way: setfacl'ing the devices to include 
> read access for currently logged-in users. (Well, if someone logs on tty1 
> after you, you're screwed anyway - he could have just ejected the cd when 
> he's physically at the box.)

There are some things to complicate matters. SUSE patch subfs into the
kernel and ship the needed user-space, think of this as quick
automounter. It releases the drive and unmounts the medium when the last
file is closed. In older SUSE releases, tty? logins didn't trigger
such access controls, only "desktop" logins through kdm or gdm.

> Yes, the device numbering is not optimal. (I already hear someone saying 
> 'have udev make some sweety symlink in /dev'.)
> But in case of /dev/hd*, we are pretty sure of what device is connected 
> where. In case of sd*, it's AFAICS not - the next device plugged in gets 
> the next free sd slot.

What matters is sg, and perhaps sr.

-- 
Matthias Andree

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

[Jan Engelhardt]

>> SUSE currently does it in A Nice Way: setfacl'ing the devices to include 
>> read access for currently logged-in users. (Well, if someone logs on tty1 
>> after you, you're screwed anyway - he could have just ejected the cd when 
>> he's physically at the box.)
>
>There are some things to complicate matters. SUSE patch subfs into the
>kernel and ship the needed user-space, think of this as quick
>automounter. It releases the drive and unmounts the medium when the last
>file is closed. In older SUSE releases, tty? logins didn't trigger
>such access controls, only "desktop" logins through kdm or gdm.

I think this is independent of subfs. This is, afaicg, a resmgrd thing. And 
since I do not use [a-z]dm, but tty login + startx, well, you can 
guess.

>> Yes, the device numbering is not optimal. (I already hear someone saying 
>> 'have udev make some sweety symlink in /dev'.)
>> But in case of /dev/hd*, we are pretty sure of what device is connected 
>> where. In case of sd*, it's AFAICS not - the next device plugged in gets 
>> the next free sd slot.
>
>What matters is sg, and perhaps sr.

Where is the difference between SG_IO-on-hdx and sg0?



Jan Engelhardt
-- 

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

[Joerg Schilling]

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

> Where is the difference between SG_IO-on-hdx and sg0?

-	Accessing _all_ SCSI devices from a unique name space.

-	Using a driver that if located at the right layering level
	(just above the transport) but not at the block level where 
	SCSI transport does not belong.

-	Cutting down kernel size by avoiding multiple implemenations
	of code for the same purpose.

There are of course more....



Jörg

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

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

[Joerg Schilling]

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

> cdrecord simply assumes that if you don't have access to /dev/hda,
> scanning the other devices is pointless, on the assumption it were a
> security risk. How this fits into user profiles that might allow access
> to /dev/hdc, is unclear to me.

Wrong: cdrecord asumes nothing. It is the SCSI Generic transport library libscg.

Note that libscg does not offer access to a block layer device like /dev/hd* 
but rather to the transport layer _below_ /dev/hd*. If you ignore this fact you 
will have problems to understand the rules.

> > If you can access a _harddisk_ as a normal user, you _do have_ a security 
> > problem. If you can access a cdrom as normal user, well, the opinions 
> > differ here. I think you _should not either_, because it might happen that 
> > you just left your presentation cd in a cdrom device in a public box. You 
> > would certainly not want to have everyone read that out.
>
> That's less of a problem than sending vendor-specific commands - one
> might be "update firmware", which would allow the user to destroy the
> drive.

I am not sure whether you understood the problem here. Cdrtools need to deal 
with a lot of vendor specific commands. 

Jörg

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

> >1. compile a list of their requirements,
>
> Have as few code duplicated (e.g. ATAPI and SCSI may share some - after 
> all, ATAPI is (to me) some sort of SCSI tunneled in ATA.)

Thank you! This is a vote _pro_ a unified SCSI generic implementation for all
types of devices. The current implementation unneccssarily duplicates a lot 
of code.

> Make it, in accordance with the above, possible to have as few kernel 
> modules loaded as possible and therefore reducing footprint - if I had not 
> to load sd_mod for usb_storage fun, I would get an itch to load a 78564 
> byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.)

On Solaris, the SCSI glue code (between hostadaptor drivers and target drivers) is 
really small:

/usr/ccs/bin/size /kernel/misc/scsi 
28482 + 27042 + 2036 = 57560

And if you check the amount of completely unneeded code Linux currently has 
just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
kernel when converting to a clean SCSI based design.


> Want to write CDs and DVDs "as usual" (see below).

Be careful: libscg is a _generic_ SCSI transport library.
Closing the eyes for anything but CD writing is not the right way.


> De-forest the SCSI subsystem for privilege checking (see below).

Sorry, I see nothing related below.


> >2. find out the current state of affairs,
>
> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW, 
> DVD-DL with no problems using
>     cdrecord -dev=/dev/hdb

Maybe I should enforce the official libscg device syntax in order to prevent 
this from working in the future.

Anyway: the fact that it may work is no proof for correctness.


> I can write DVDs at 8x speed (approx 10816 KB/sec) - which looks like DMA 
> is working through the current mechanism, although I can't confirm it.

In case you don't knw the story:

	Linus Torvalds once claimed that introducing SG_IO support for
	/dev/hd* would be acompanied with cleaning up DMA support in the kernel.

	At that moment it turned out that it did not help at all as /dev/hd*
	did not give DMA. Later this bug was fixed, but I am still waiting
	to see the proposed DMA fix for ide-scsi.


> There have been reports that cdrecord does not work when setuid, but only 
> when you are "truly root". Not sure where this comes from,
> (current->euid==0&&current->uid!=0 maybe?) scsi layer somewhere?

Depends on what you talk about. 

Since about a year, there is a workaround for the incompatible interface change 
introduced with Linux-2.6.8.1

On a recent RedHat system, cdrecord works installed suid root.

On a system running a kernel.org based Linux it has been reported to fail
because it does not get a SCSI transfer buffer.



> >write a CD anyways". I find this wrong, Jörg finds it correct and argues
> >"if you can access /dev/hdc as unprivileged user, that's a security
> >problem".
>
> If you can access a _harddisk_ as a normal user, you _do have_ a security 
> problem. If you can access a cdrom as normal user, well, the opinions 
> differ here. I think you _should not either_, because it might happen that 
> you just left your presentation cd in a cdrom device in a public box. You 
> would certainly not want to have everyone read that out.

Do you  want everybody to be able to read or format a floppy disk?
Ignoring usual security rules sometimes _seem_ to make life easier but usually 
does not. Just look in what kind of jungle Microsoft is just because that 
started to allow insanely things for the sake of "user convenience".


> SUSE currently does it in A Nice Way: setfacl'ing the devices to include 
> read access for currently logged-in users. (Well, if someone logs on tty1 
> after you, you're screwed anyway - he could have just ejected the cd when 
> he's physically at the box.)

It may make sense to do something like this for the user logged into the 
console. In general it is a security problem.

Jörg

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe]

On Wed, Jan 25 2006, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > >1. compile a list of their requirements,
> >
> > Have as few code duplicated (e.g. ATAPI and SCSI may share some - after 
> > all, ATAPI is (to me) some sort of SCSI tunneled in ATA.)
> 
> Thank you! This is a vote _pro_ a unified SCSI generic implementation for all
> types of devices. The current implementation unneccssarily duplicates a lot 
> of code.

The block layer SG_IO is just that, it's completely transport agnostic.
There's not a lot of duplicated code. In the future, perhaps sg will
disappear and be replaced by bsg which is just the full block layer
implementation of that (SG_IO can currently be considered a subset of
that support).

> > Make it, in accordance with the above, possible to have as few kernel 
> > modules loaded as possible and therefore reducing footprint - if I had not 
> > to load sd_mod for usb_storage fun, I would get an itch to load a 78564 
> > byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.)
> 
> On Solaris, the SCSI glue code (between hostadaptor drivers and target drivers) is 
> really small:
> 
> /usr/ccs/bin/size /kernel/misc/scsi 
> 28482 + 27042 + 2036 = 57560
> 
> And if you check the amount of completely unneeded code Linux currently has 
> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> kernel when converting to a clean SCSI based design.

Please point me at that huge amount of code. Hint: there is none.

Deja vu, anyone?

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jan Engelhardt]

>> And if you check the amount of completely unneeded code Linux currently has 
>> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
>> kernel when converting to a clean SCSI based design.
>
>Please point me at that huge amount of code. Hint: there is none.

I'm getting a grin:

15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
(no results)

Looks like it's already non-redundant :)



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe]

On Wed, Jan 25 2006, Jan Engelhardt wrote:
> 
> >> And if you check the amount of completely unneeded code Linux currently has 
> >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> >> kernel when converting to a clean SCSI based design.
> >
> >Please point me at that huge amount of code. Hint: there is none.
> 
> I'm getting a grin:
> 
> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> (no results)
> 
> Looks like it's already non-redundant :)

SG_IO turns requests into REQ_BLOCK_PC (or blk_pc_request()) types, so
you should probably check for that as well. But it's truly a miniscule
amount of code, and if I got off my ass and folded cdrom_newpc_intr()
and cdrom_pc_intr() into one (that was the intention), it would be even
less.

It just looks like Joerg needs to do his homework, before spreading
false information on lkml. Then again, all his "arguments" are the same
as last time (and the time before, and before, and so on).

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe]

On Wed, Jan 25 2006, Jens Axboe wrote:
> On Wed, Jan 25 2006, Jan Engelhardt wrote:
> > 
> > >> And if you check the amount of completely unneeded code Linux currently has 
> > >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> > >> kernel when converting to a clean SCSI based design.
> > >
> > >Please point me at that huge amount of code. Hint: there is none.
> > 
> > I'm getting a grin:
> > 
> > 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> > (no results)
> > 
> > Looks like it's already non-redundant :)
> 
> SG_IO turns requests into REQ_BLOCK_PC (or blk_pc_request()) types, so
> you should probably check for that as well. But it's truly a miniscule
> amount of code, and if I got off my ass and folded cdrom_newpc_intr()
> and cdrom_pc_intr() into one (that was the intention), it would be even
> less.

BTW, I should point out that the fact that references to REQ_BLOCK_PC
and blk_pc_request() exists doesn't indicate duplicated code. Each low
level driver or layer (like SCSI, not the SCSI low level drivers) need
to transform REQ_BLOCK_PC requests into their command types.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

Jens Axboe <axboe@suse.de> wrote:

> It just looks like Joerg needs to do his homework, before spreading
> false information on lkml. Then again, all his "arguments" are the same
> as last time (and the time before, and before, and so on).

Before spreading your false claims, please do your homework.

We previously had mostly fruitful discussion before you did appear.
Please either try to contribute useful ideas or stay out.

Jörg

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

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

[Matthias Andree]

Joerg Schilling wrote:
> Jens Axboe <axboe@suse.de> wrote:
> 
>> It just looks like Joerg needs to do his homework, before spreading
>> false information on lkml. Then again, all his "arguments" are the same
>> as last time (and the time before, and before, and so on).
> 
> Before spreading your false claims, please do your homework.

I think we'd better call the whole discussion off.

In personal conversation with Jörg, I fell prey to the illusion he might
have grown up last week-end, and Lee's promising post was the idea to start
the whole thing and see if both sides get closer together, but it seems Jörg
is unwilling to stick to a civilized discussion.

Sorry for starting this noise.

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

[Joerg Schilling]

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

> I think we'd better call the whole discussion off.

We could continue as long as people like Jens Axboe stay reasonable.

Jörg

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

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

[Jens Axboe]

On Wed, Jan 25 2006, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > I think we'd better call the whole discussion off.
> 
> We could continue as long as people like Jens Axboe stay reasonable.

I would have no problems if you weren't spreading your misguided
information disguised as real info. I've had thousands of useful
conversations on lkml in the past many years, but I fail to remember
just one with you involved (whether I participated or not).

I'll refrain from writing further mails in this thread, unless you
actually "find some time" to back up your claims with real data.

-- 
Jens Axboe

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-25:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > I think we'd better call the whole discussion off.
> 
> We could continue as long as people like Jens Axboe stay reasonable.

No. The deal was people stating their requirements, not mounting
personal attacks against others. I posted the same question (what's
lacking) several times, and your constant answer "device enumeration"
makes me assume that it's the only thing you believe is missing.

Since libscg scans all /dev/pg* and /dev/sg* (for transport indicator ""
which means plain sg) and all /dev/hd* (for transport indicator ATA:
which means /dev/hd*) and turns it into bus, host, lun anyways, there
does not appear to be a need to move this code into the kernel.

What *else* is missing?

-- 
Matthias Andree

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

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-01-25:
>
> > Matthias Andree <matthias.andree@gmx.de> wrote:
> > 
> > > I think we'd better call the whole discussion off.
> > 
> > We could continue as long as people like Jens Axboe stay reasonable.
>
> No. The deal was people stating their requirements, not mounting
> personal attacks against others. I posted the same question (what's

This is why we needed to omit Jens Axboe from this discusion.

> lacking) several times, and your constant answer "device enumeration"
> makes me assume that it's the only thing you believe is missing.

You try to go into the wrong direction by ignoring all important issues.

Tell me how to access a ATAPI tape drive via libscg.

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-26:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > Joerg Schilling schrieb am 2006-01-25:
> >
> > > Matthias Andree <matthias.andree@gmx.de> wrote:
> > > 
> > > > I think we'd better call the whole discussion off.
> > > 
> > > We could continue as long as people like Jens Axboe stay reasonable.
> >
> > No. The deal was people stating their requirements, not mounting
> > personal attacks against others. I posted the same question (what's
> 
> This is why we needed to omit Jens Axboe from this discusion.

Hold it! Who is acquainted with Linux 2.6.15-rc*, Jens or you?

This childish discussion who started bitching isn't going to take you anywhere.

> Tell me how to access a ATAPI tape drive via libscg.

It is *your* library, I have no interest in it as long as CD writing
works at the moment. Either do your research or ask the public, I'm not
going to answer or research this for you.

It is not helpful that you are (1) talking about ATAPI tapes under the
CD subject and (2) claim you know better than Linux (or Jens, for that
matter) if you haven't researched this.

If you want to talk about libscg's access methods to all kinds of
devices besides CD/DVD, start a new discussion please.

And it is about time that you stopped spamming people who explicitly
stated "No Cc:" such as Jens Axboe and Lee Revell.
Not minding these requests is rude.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> > Tell me how to access a ATAPI tape drive via libscg.
>
> It is *your* library, I have no interest in it as long as CD writing
> works at the moment. Either do your research or ask the public, I'm not
> going to answer or research this for you.

If you like to cut off the main cause for the problems, it seems that we need to
stop this discussion here as I cannot see that we will come to any useful result.



Jörg

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

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

[Jan Engelhardt]

>> Tell me how to access a ATAPI tape drive via libscg.

(I probably don't get that question.)
The top of drivers/ide/ide-tape.c shows it gets /dev/ht%d (when used 
without scsi emulation I believe). And I pick a wild guess that it gets 
/dev/sg%d when used with scsi emu.
Programs using libscg would only need to use S:I:L or ATA:/dev/ht0 (?)
I presume?



>It is *your* library, I have no interest in it as long as CD writing
>works at the moment. Either do your research or ask the public, I'm not
>going to answer or research this for you.
>
>It is not helpful that you are (1) talking about ATAPI tapes under the
>CD subject and (2) claim you know better than Linux (or Jens, for that
>matter) if you haven't researched this.

I think you (Matthias) get it slightly skewed here. As far as I am able to 
slip through the flames, libscg is used by cdrecord just as libc is used by 
all apps to have "some sort" of OS abstraction (pick some function, like 
fork()). Therefore, libscg seems +not only+ about cd writing. However, if 
you want to have a working cdrecord, you need a working libscg, just like 
you need a working libc or your system is going bye-bye.




Jan Engelhardt
-- 

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

[Matthias Andree]

Jan Engelhardt schrieb am 2006-01-26:

> I think you (Matthias) get it slightly skewed here. As far as I am able to 
> slip through the flames, libscg is used by cdrecord just as libc is used by 
> all apps to have "some sort" of OS abstraction (pick some function, like 
> fork()). Therefore, libscg seems +not only+ about cd writing. However, if 
> you want to have a working cdrecord, you need a working libscg, just like 
> you need a working libc or your system is going bye-bye.

I couldn't care less if libscg works for ATAPI tapes. No-one provided
input for ATAPI tapes that do verify-while-write (call it read after
write if you want, Hinterbandkontrolle in German) yet, and potential
libscg-can't-get-a-hold-of-ATAPI-tapes problems can be discussed in a
separate thread if you don't mind.

-- 
Matthias Andree

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

[Jens Axboe]

On Wed, Jan 25 2006, Matthias Andree wrote:
> Joerg Schilling wrote:
> > Jens Axboe <axboe@suse.de> wrote:
> > 
> >> It just looks like Joerg needs to do his homework, before spreading
> >> false information on lkml. Then again, all his "arguments" are the same
> >> as last time (and the time before, and before, and so on).
> > 
> > Before spreading your false claims, please do your homework.
> 
> I think we'd better call the whole discussion off.
> 
> In personal conversation with Jörg, I fell prey to the illusion he might
> have grown up last week-end, and Lee's promising post was the idea to start
> the whole thing and see if both sides get closer together, but it seems Jörg
> is unwilling to stick to a civilized discussion.
> 
> Sorry for starting this noise.

Agreed, it's the same thing that happens each and every time he posts
here.

-- 
Jens Axboe

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

[Joerg Schilling]

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

> I think we'd better call the whole discussion off.

Let me come back to this again and give an important statement...

	If this mailing list is not the place where to 
	make architectural design decisions, then we really better 
	should stop this discussion immediately as it then would be useless.

	Please inform me about this fact in case you know more as I really
	don't have time to waste with useless discussions.


It seems also required to give some background information:

Without Matthias, I would already never again answered any mail from LKML
as all previous experiences on this list have been a desaster. It did usually
take less than an hour until someone from the list did start personal attacks.
The last two times, the discussion has been made impossible because Jens Axboe 
started with personal infringements and his obvious false claims.

This time, it did look really promising until Jens Axboe again started with 
personal infringements. I have to admit that it would have been better to 
ignore him from the very beginning, but I was in false hope that he could have 
changed.

Let me make a proposal: I try to answer mail from people who send useful 
contributions to the discussion and I will ignore anybody who starts with 
personal infringements. I will try to reply to mails with incorrect claims if 
they are not obvious but I will stop replying to the same person if he 
continues with things that are incorrect.

Jörg

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

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

[Jens Axboe]

On Thu, Jan 26 2006, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > I think we'd better call the whole discussion off.
> 
> Let me come back to this again and give an important statement...
> 
> 	If this mailing list is not the place where to 
> 	make architectural design decisions, then we really better 
> 	should stop this discussion immediately as it then would be useless.
> 
> 	Please inform me about this fact in case you know more as I really
> 	don't have time to waste with useless discussions.
> 
> 
> It seems also required to give some background information:
> 
> Without Matthias, I would already never again answered any mail from
> LKML as all previous experiences on this list have been a desaster. It
> did usually take less than an hour until someone from the list did
> start personal attacks.  The last two times, the discussion has been
> made impossible because Jens Axboe started with personal infringements
> and his obvious false claims.
> 
> This time, it did look really promising until Jens Axboe again started
> with personal infringements. I have to admit that it would have been
> better to ignore him from the very beginning, but I was in false hope
> that he could have changed.
> 
> Let me make a proposal: I try to answer mail from people who send
> useful contributions to the discussion and I will ignore anybody who
> starts with personal infringements. I will try to reply to mails with
> incorrect claims if they are not obvious but I will stop replying to
> the same person if he continues with things that are incorrect.

What is this, kindergarten? What false claims have I made? I pointed out
several you made, to which you had no rebuttal. Then you start playing
"Jens made obviously false claims", huh?? I've had more mature
conversations with my 1 year old son.

I'm sorry if you feel that me refuting your false statements are
personal attacks. Clearly not a problem that can be fixed at my end.
Ignoring facts and continuing to write the same wrong claims over and
over again doesn't make them true in the end.

Please take me off the cc list, thanks.

-- 
Jens Axboe

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

[Matthias Andree]

Jens Axboe schrieb am 2006-01-26:

> What is this, kindergarten? What false claims have I made? I pointed out
> several you made, to which you had no rebuttal. Then you start playing
> "Jens made obviously false claims", huh?? I've had more mature
> conversations with my 1 year old son.
> 
> I'm sorry if you feel that me refuting your false statements are
> personal attacks. Clearly not a problem that can be fixed at my end.
> Ignoring facts and continuing to write the same wrong claims over and
> over again doesn't make them true in the end.

The problem appears to be that Jörg hasn't really looked at Linux in
some time, and he's used to systems that don't change architecture in
patchlevel releases, while Linux 2.6.N.M should actually have been
numbered 2.(6+2*N).M...

Jörg, any chance you might be arguing on basis of really old 2.6.X
kernels?

-- 
Matthias Andree

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

[Joerg Schilling]

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

> The problem appears to be that Jörg hasn't really looked at Linux in
> some time, and he's used to systems that don't change architecture in
> patchlevel releases, while Linux 2.6.N.M should actually have been
> numbered 2.(6+2*N).M...
>
> Jörg, any chance you might be arguing on basis of really old 2.6.X
> kernels?

All statements I send have been verified by looking at the 2.6.15 source.

Jörg

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe]

On Wed, Jan 25 2006, Joerg Schilling wrote:
> Jens Axboe <axboe@suse.de> wrote:
> 
> > It just looks like Joerg needs to do his homework, before spreading
> > false information on lkml. Then again, all his "arguments" are the same
> > as last time (and the time before, and before, and so on).
> 
> Before spreading your false claims, please do your homework.

Sorry Joerg, _you_ really are the one that has to do your homework as
you aptly demonstrated.

> We previously had mostly fruitful discussion before you did appear.
> Please either try to contribute useful ideas or stay out.

You are spreading blatently false claim about the code and repeating the
same old suggestions on what _you_ think Linux design should be like. So
I had to correct it, which I did.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

>
> >> And if you check the amount of completely unneeded code Linux currently has 
> >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> >> kernel when converting to a clean SCSI based design.
> >
> >Please point me at that huge amount of code. Hint: there is none.
>
> I'm getting a grin:
>
> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> (no results)
>
> Looks like it's already non-redundant :)

everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I 
would find more if I take some time....

Jörg

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe]

On Wed, Jan 25 2006, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> >
> > >> And if you check the amount of completely unneeded code Linux currently has 
> > >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> > >> kernel when converting to a clean SCSI based design.
> > >
> > >Please point me at that huge amount of code. Hint: there is none.
> >
> > I'm getting a grin:
> >
> > 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> > (no results)
> >
> > Looks like it's already non-redundant :)
> 
> everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I 
> would find more if I take some time....

axboe@nelson:[.]r/src/linux-2.6-block.git $ size block/scsi_ioctl.o
   text    data     bss     dec     hex filename
   2844     256       0    3100     c1c block/scsi_ioctl.o

And it's not everything that's duplicated, basically only the ioctl
parsing is. So either admit that there isn't a a lot of duplicated code,
or "take some time" and point me at it. Otherwise refrain from making
obviously false statements in the future.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Lee Revell]

On Wed, 2006-01-25 at 17:57 +0100, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> >
> > >> And if you check the amount of completely unneeded code Linux currently has 
> > >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> > >> kernel when converting to a clean SCSI based design.
> > >
> > >Please point me at that huge amount of code. Hint: there is none.
> >
> > I'm getting a grin:
> >
> > 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> > (no results)
> >
> > Looks like it's already non-redundant :)
> 
> everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I 
> would find more if I take some time....

PLEASE don't cc: me on this asinine thread anymore.

Argh, I KNEW this would end with the same exact flame war.

Lee

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jan Engelhardt]

(removing Jens and Lee, as previous posts made that quite clear)

>> I'm getting a grin:
>>
>> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
>> (no results)
>>
>> Looks like it's already non-redundant :)
>
>everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I 
>would find more if I take some time....

In what linux kernel version have you found that file?



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Vadim Lobanov]

On Thu, 26 Jan 2006, Jan Engelhardt wrote:

>
> (removing Jens and Lee, as previous posts made that quite clear)
>
> >> I'm getting a grin:
> >>
> >> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> >> (no results)
> >>
> >> Looks like it's already non-redundant :)
> >
> >everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I
> >would find more if I take some time....
>
> In what linux kernel version have you found that file?
>

In taking a look at http://sosdg.org/~coywolf/lxr/ ...
That file exists in versions 2.6.10 through 2.6.14. It's gone from
2.6.15 and onward, however.
No comment as to the validity of its contents to the argument at hand.
:-)

>
> Jan Engelhardt
> --

- Vadim Lobanov

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Gene Heskett]

On Thursday 26 January 2006 16:33, Vadim Lobanov wrote:
>On Thu, 26 Jan 2006, Jan Engelhardt wrote:
>> (removing Jens and Lee, as previous posts made that quite clear)
>>
>> >> I'm getting a grin:
>> >>
>> >> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0
>> >> grep SG_IO (no results)
>> >>
>> >> Looks like it's already non-redundant :)
>> >
>> >everything in drivers/block/scsi_ioctl.c  is duplicate code and I
>> > am sure I would find more if I take some time....
>>
>> In what linux kernel version have you found that file?
>
>In taking a look at http://sosdg.org/~coywolf/lxr/ ...
>That file exists in versions 2.6.10 through 2.6.14. It's gone from
>2.6.15 and onward, however.
>No comment as to the validity of its contents to the argument at hand.
No, its apparently been moved (works for IBM maybe?)

#>locate scsi_ioctl.c
/usr/gene/src/linux-2.4.29/drivers/scsi/scsi_ioctl.c
/usr/gene/src/linux-2.4.21-pre7/drivers/scsi/scsi_ioctl.c
/usr/gene/src/linux-2.4.18-4/drivers/scsi/scsi_ioctl.c
/usr/gene/src/linux-2.4.19/drivers/scsi/scsi_ioctl.c
/usr/gene/src/linux-2.4.21-rc1-ck6/drivers/scsi/scsi_ioctl.c
/usr/gene/src/linux-2.4.21-pre5/drivers/scsi/scsi_ioctl.c
/usr/src/2.6.15-rc2-git6.bak/drivers/scsi/scsi_ioctl.c
/usr/src/2.6.15-rc2-git6.bak/block/scsi_ioctl.c
/usr/src/2.6.14.3-bak/drivers/block/scsi_ioctl.c
/usr/src/2.6.14.3-bak/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc2-git6/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc2-git6/block/scsi_ioctl.c
/usr/src/linux-2.6.15/block/scsi_ioctl.c
/usr/src/linux-2.6.15/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc3/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc3/block/scsi_ioctl.c
/usr/src/linux-2.6.14.2-pktwrt/drivers/block/scsi_ioctl.c
/usr/src/linux-2.6.14.2-pktwrt/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.14.1/drivers/block/scsi_ioctl.c
/usr/src/linux-2.6.14.1/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.14.3/drivers/block/scsi_ioctl.c
/usr/src/linux-2.6.14.3/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc4/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc4/block/scsi_ioctl.c
/usr/src/linux-2.6.15-rc5/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc5/block/scsi_ioctl.c
/usr/src/kernel/git-core-0.99.7/linux/drivers/block/scsi_ioctl.c
/usr/src/kernel/git-core-0.99.7/linux/drivers/scsi/scsi_ioctl.c
/usr/src/kernel/linux/drivers/block/scsi_ioctl.c
/usr/src/kernel/linux/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc6/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc6/block/scsi_ioctl.c
/usr/src/linux-2.6.15-rc7/block/scsi_ioctl.c
/usr/src/linux-2.6.15-rc7/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15.1/block/scsi_ioctl.c
/usr/src/linux-2.6.15.1/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15.1/linux-2.6.15/block/scsi_ioctl.c
/usr/src/linux-2.6.15.1/linux-2.6.15/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.16-rc1/block/scsi_ioctl.c
/usr/src/linux-2.6.16-rc1/drivers/scsi/scsi_ioctl.c <----------
/usr/src/linux-2.4.23-pre8/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.4.23-pre8/linux-2.4.22/drivers/scsi/scsi_ioctl.c

And obviously its time for me to go on a housekeeping binge :)

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Vadim Lobanov]

On Thu, 26 Jan 2006, Jan Engelhardt wrote:

>
> (removing Jens and Lee, as previous posts made that quite clear)
>
> >> I'm getting a grin:
> >>
> >> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> >> (no results)
> >>
> >> Looks like it's already non-redundant :)
> >
> >everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I
> >would find more if I take some time....
>
> In what linux kernel version have you found that file?
>

In looking at http://sosdg.org/~coywolf/lxr/, that file seems to exist
in versions 2.6.10 through 2.6.14. It's gone in versions 2.6.15 and
upward, however. No comment as to the validity of that file's contents
to the discussion at hand, however. :-)

>
> Jan Engelhardt
> --

- Vadim Lobanov

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Pavel Machek]

Hi!

> > >write a CD anyways". I find this wrong, J??rg finds it correct and argues
> > >"if you can access /dev/hdc as unprivileged user, that's a security
> > >problem".
> >
> > If you can access a _harddisk_ as a normal user, you _do have_ a security 
> > problem. If you can access a cdrom as normal user, well, the opinions 
> > differ here. I think you _should not either_, because it might happen that 
> > you just left your presentation cd in a cdrom device in a public box. You 
> > would certainly not want to have everyone read that out.
> 
> Do you  want everybody to be able to read or format a floppy disk?

Why not... if I'm on box without network access, for example.

> > SUSE currently does it in A Nice Way: setfacl'ing the devices to include 
> > read access for currently logged-in users. (Well, if someone logs on tty1 
> > after you, you're screwed anyway - he could have just ejected the cd when 
> > he's physically at the box.)
> 
> It may make sense to do something like this for the user logged into the 
> console. In general it is a security problem.

Violent agreement here. For some uses, 99% of users are logged onto
the console.
								Pavel
-- 
Thanks, Sharp!

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Luke-Jr]

On Tuesday 24 January 2006 17:42, Jan Engelhardt wrote:
> >2. find out the current state of affairs,
>
> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW,
> DVD-DL with no problems using
>     cdrecord -dev=/dev/hdb
> it _currently_ works, no matter how ugly or not this is from either Jörg's
> or any other developer's POV - therefore it's fine from the end-user's POV.

How did you manage to burn a dual layer disc? I have been completely 
unsuccessful at doing this at all. :(

> There have been reports that cdrecord does not work when setuid, but only
> when you are "truly root". Not sure where this comes from,
> (current->euid==0&&current->uid!=0 maybe?) scsi layer somewhere?

I didn't look into it, but my cdrecord seems to work fine as my normal user 
(writing via cdrw group w/ perms), but not with suid-root.

> I'm fine (=I agree) with the general possibility of having it setuid,
> though.

Provided it doesn't allow burning files the real-user shouldn't be able to 
access... But since cdrecord is commonly suid-root, I presume this has long 
been taken into consideration.

> SUSE currently does it in A Nice Way: setfacl'ing the devices to include
> read access for currently logged-in users. (Well, if someone logs on tty1
> after you, you're screwed anyway - he could have just ejected the cd when
> he's physically at the box.)

Aren't user-groups per-session anyway? Why not simply have the login program 
apply a 'localusers' group to all local sessions and set device permissions 
for that group? To add to the security, perhaps there is a way to remove the 
'localusers' permissions from all backgrounded processes (screen, etc) when 
the user logs out?

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2053 bytes --]

>> >2. find out the current state of affairs,
>>
>> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW,
>> DVD-DL with no problems using
>>     cdrecord -dev=/dev/hdb
>> it _currently_ works, no matter how ugly or not this is from either Jörg's
>> or any other developer's POV - therefore it's fine from the end-user's POV.
>
>How did you manage to burn a dual layer disc? I have been completely 
>unsuccessful at doing this at all. :(
>

You have to add  -driver=mmc_dvdplusr , because the Dual Layer discs are 
not yet in the ProDVD database as it seems.

>> I'm fine (=I agree) with the general possibility of having it setuid,
>> though.
>
>Provided it doesn't allow burning files the real-user shouldn't be able to 
>access... But since cdrecord is commonly suid-root, I presume this has long 
>been taken into consideration.
>
Security-critical environments like data centers either have a Windows 
NT-style machine providing <enter whacky burning software here>, or they 
've got a specialized machine that is marked "use for cd burning - note 
security implications". Usually there is no problem with that as in that 
case, you should remove your ISO you copied over for writing after writing.

>> SUSE currently does it in A Nice Way: setfacl'ing the devices to include
>> read access for currently logged-in users. (Well, if someone logs on tty1
>> after you, you're screwed anyway - he could have just ejected the cd when
>> he's physically at the box.)
>
>Aren't user-groups per-session anyway? Why not simply have the login program 
>apply a 'localusers' group to all local sessions and set device permissions 
>for that group?

userwhat? You mean supplemental groups as printed by id(1)? I find them 
ugly, because it's a real hassle to manage it with files.

In the past, NGROUPS_MAX also was 32, being more of a limit than today.

>To add to the security, perhaps there is a way to remove the 
>'localusers' permissions from all backgrounded processes (screen, etc) when 
>the user logs out?
>


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

> >> >2. find out the current state of affairs,
> >>
> >> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW,
> >> DVD-DL with no problems using
> >>     cdrecord -dev=/dev/hdb
> >> it _currently_ works, no matter how ugly or not this is from either Jörg's
> >> or any other developer's POV - therefore it's fine from the end-user's POV.
> >
> >How did you manage to burn a dual layer disc? I have been completely 
> >unsuccessful at doing this at all. :(
> >
>
> You have to add  -driver=mmc_dvdplusr , because the Dual Layer discs are 
> not yet in the ProDVD database as it seems.

They are if you use a halfway recent cdrecord.

> userwhat? You mean supplemental groups as printed by id(1)? I find them 
> ugly, because it's a real hassle to manage it with files.
>
> In the past, NGROUPS_MAX also was 32, being more of a limit than today.

If you extend NGROUPS_MAX to be more than 16, NFS AUTH_UNIX will not work 
anymore.

And BTW: using NGROUPS seems to be a bit outdated now, more than 10 years after
ACLs have been introduced on UNIX.

Jörg

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Luke-Jr]

On Friday 03 February 2006 14:08, Jan Engelhardt wrote:
> >> >2. find out the current state of affairs,
> >>
> >> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW,
> >> DVD-DL with no problems using
> >>     cdrecord -dev=/dev/hdb
> >> it _currently_ works, no matter how ugly or not this is from either
> >> Jörg's or any other developer's POV - therefore it's fine from the
> >> end-user's POV.
> >
> >How did you manage to burn a dual layer disc? I have been completely
> >unsuccessful at doing this at all. :(
>
> You have to add  -driver=mmc_dvdplusr , because the Dual Layer discs are
> not yet in the ProDVD database as it seems.

ProDVD is immoral software. I use growisofs.

> >> I'm fine (=I agree) with the general possibility of having it setuid,
> >> though.
> >
> >Provided it doesn't allow burning files the real-user shouldn't be able to
> >access... But since cdrecord is commonly suid-root, I presume this has
> > long been taken into consideration.
>
> Security-critical environments like data centers

I'm not referring to anything security-critical, but basic minimal UNIX file 
permissions. If I have a file that's go-r, I expect that Joe Random User 
can't burn a CD/DVD with that file.

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

Luke-Jr <luke@dashjr.org> wrote:

> ProDVD is immoral software. I use growisofs.

growisofs is immoral, see 

	http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html

Either this, or the GPL applies, but not both as intended by the author....

Jörg

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-06:

> Luke-Jr <luke@dashjr.org> wrote:
> 
> > ProDVD is immoral software. I use growisofs.
> 
> growisofs is immoral, see 
> 
> 	http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html
> 
> Either this, or the GPL applies, but not both as intended by the author....

Who cares. You start complaining even about GPL patches for the software
you distributed under the terms of the GPL, without looking at
patches...

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Peter Read]

I'm confused about where software has inherited a sense of morality from?

Equally, as I can't see any restriction of the GPL in that link I
don't get the reference.  What it's essentially saying to me is 'if
you don't want it under the GPL licence terms, talk to the copyright
holder(s) or their authorised representative about alternatives'.

Plenty of people are happy to dual licence their work, & TBH I'd
rather see people do that and get something for their work than have
it misappropriated into commercial software and have to look to the
courts for a slim chance at compensation...

Anyone else rather get back to the technical discussion or is it just me?

On 06/02/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Luke-Jr <luke@dashjr.org> wrote:
>
> > ProDVD is immoral software. I use growisofs.
>
> growisofs is immoral, see
>
>         http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html
>
> Either this, or the GPL applies, but not both as intended by the author....
>
> 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
> -
> 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 writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Peter Read wrote:
> I'm confused about where software has inherited a sense of morality from?
> 
> Equally, as I can't see any restriction of the GPL in that link I
> don't get the reference.  What it's essentially saying to me is 'if
> you don't want it under the GPL licence terms, talk to the copyright
> holder(s) or their authorised representative about alternatives'.
> 
> Plenty of people are happy to dual licence their work, & TBH I'd
> rather see people do that and get something for their work than have
> it misappropriated into commercial software and have to look to the
> courts for a slim chance at compensation...
> 
> Anyone else rather get back to the technical discussion or is it just me?

Jörg likes to distract from the technical discussion, and I'm still waiting
for feedback on my GPL'd patch I posted last week.

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

[Jim Crilly]

On 02/06/06 04:15:26PM +0100, Matthias Andree wrote:
> Peter Read wrote:
> > I'm confused about where software has inherited a sense of morality from?
> > 
> > Equally, as I can't see any restriction of the GPL in that link I
> > don't get the reference.  What it's essentially saying to me is 'if
> > you don't want it under the GPL licence terms, talk to the copyright
> > holder(s) or their authorised representative about alternatives'.
> > 
> > Plenty of people are happy to dual licence their work, & TBH I'd
> > rather see people do that and get something for their work than have
> > it misappropriated into commercial software and have to look to the
> > courts for a slim chance at compensation...
> > 
> > Anyone else rather get back to the technical discussion or is it just me?
> 
> Jörg likes to distract from the technical discussion, and I'm still waiting
> for feedback on my GPL'd patch I posted last week.

You're not alone, I'm still waiting for an answer as to why cdrecord is
the only userland app on any OS to use his SCSI ID naming convention
and yet his is the correct way. I've asked twice and been blatantly
ignored both times.

Jim.

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

[Joerg Schilling]

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

> You're not alone, I'm still waiting for an answer as to why cdrecord is
> the only userland app on any OS to use his SCSI ID naming convention
> and yet his is the correct way. I've asked twice and been blatantly
> ignored both times.

Well, while I did explain this many times (*), I am still waiting 
for an explanation why Linux tries to deviate from nearly all other OS.

*) in case you like are on amnesia: without the mapping in libscg,
cdrecord could not be used reliably on Linux. And yes, I _do_ care
about people who run Linux-2.4 or older!


It seems that we should stop this discussion.

As long as the peeople who answer here are onlookers without the 
needed skills, it seems to be a waste of time.

Jörg

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

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

[Martin Mares]

Hello Joerg!

> Well, while I did explain this many times (*), I am still waiting 
> for an explanation why Linux tries to deviate from nearly all other OS.

The explanation has been given several times: the solution used by Linux
solves much more than just CD recorders.

I intentionally say "CD recorders", not "SCSI devices" nor even "CD drives",
because I don't think I can view as a consistent solution anything which
calls the same drive differently depending on whether I want to read or
write a CD.

I repeatedly asked you why do you think we should call the device
differently for different uses and there were no replies.

> *) in case you like are on amnesia: without the mapping in libscg,
> cdrecord could not be used reliably on Linux. And yes, I _do_ care
> about people who run Linux-2.4 or older!

As you were already told, you can do it by splitting the Linux port
to two, one for Linux 2.4 and older, one for the newer kernels. Some
people even offered help with maintaining the Linux parts of the libscg.

Except for the compatibility problems, I haven't heard any argument
why it "could not be used reliably on Linux".

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
P.C.M.C.I.A. stands for `People Can't Memorize Computer Industry Acronyms'

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-07:

> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > You're not alone, I'm still waiting for an answer as to why cdrecord is
> > the only userland app on any OS to use his SCSI ID naming convention
> > and yet his is the correct way. I've asked twice and been blatantly
> > ignored both times.
> 
> Well, while I did explain this many times (*), I am still waiting 
> for an explanation why Linux tries to deviate from nearly all other OS.

You documented differences between FreeBSD that require you to jump
hoops and Solaris yourself, and still your software supports FreeBSD?

> *) in case you like are on amnesia: without the mapping in libscg,
> cdrecord could not be used reliably on Linux. And yes, I _do_ care
> about people who run Linux-2.4 or older!

What about dev=/dev/sg1 (via ide-scsi) doesn't work on Linux 2.4, except
DMA for 2352 byte blocks?

> It seems that we should stop this discussion.

There is no obligation for you to respond. But don't expect to be taken
seriously or listened to if you fleet the discussion as soon as it has
become uncomfortable for you.

> As long as the peeople who answer here are onlookers without the 
> needed skills, it seems to be a waste of time.

Yes indeed. You're asked the same things a dozen times and still ignore
those questions rather than giving the answers that might someone
investigate the issue.

-- 
Matthias Andree

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

[Jim Crilly]

On 02/07/06 02:06:30PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > You're not alone, I'm still waiting for an answer as to why cdrecord is
> > the only userland app on any OS to use his SCSI ID naming convention
> > and yet his is the correct way. I've asked twice and been blatantly
> > ignored both times.
> 
> Well, while I did explain this many times (*), I am still waiting 
> for an explanation why Linux tries to deviate from nearly all other OS.
> 
> *) in case you like are on amnesia: without the mapping in libscg,
> cdrecord could not be used reliably on Linux. And yes, I _do_ care
> about people who run Linux-2.4 or older!
> 
> 
> It seems that we should stop this discussion.
> 
> As long as the peeople who answer here are onlookers without the 
> needed skills, it seems to be a waste of time.
> 
> Jörg

All you've explained is that using SCSI ID for device names is the way
you want cdrecord to work, not why it's infinitely better than using real
device names like every other userland program on every OS in existance.

And please name a case where 'cdrecord dev=/dev/cdrom file.iso' won't work
reliably because I, and it would seem many others, haven't run into it.
there was the case where recording audio doesn't do DMA, but that's a bug
in ide-scsi and I AFAIK it doesn't matter whether you use dev=/scd0 or
dev=1,0,0 to address the drive.  And also, I believe dev=/dev/scd0 will
work with ide-scsi in 2.4, but I don't have a machine to test that on.

The people replying here are your users, if you don't want to listen to
them pretty much any conversation with you will be a waste of time.

Jim.

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

[Joerg Schilling]

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

> All you've explained is that using SCSI ID for device names is the way
> you want cdrecord to work, not why it's infinitely better than using real
> device names like every other userland program on every OS in existance.

I did many times, but people don't seem to listen.


> The people replying here are your users, if you don't want to listen to
> them pretty much any conversation with you will be a waste of time.

Sorry, but from reading the mail from _real_ cdrecord users, it is obvious
that the people here are either not my users or users with a stange way of 
thinking.

Jörg

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

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

[sean]

On Wed, 08 Feb 2006 14:27:41 +0100
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> I did many times, but people don't seem to listen.

Hello Pot?  This is Kettle.

> Sorry, but from reading the mail from _real_ cdrecord users, it is obvious
> that the people here are either not my users or users with a stange way of 
> thinking.

Wrong.  Most people on this list have probably used cdrecord at one time or
another and therefore are your users.   The fact that you want to pretend
that everyone who disagrees with you doesn't matter suggests that it's
perhaps _you_ who has a strange way of thinking.


Sean

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

[Martin Mares]

Hello!

> Sorry, but from reading the mail from _real_ cdrecord users, it is obvious
> that the people here are either not my users or users with a stange way of 
> thinking.

Then, probably, almost everybody has a strange way of thinking.

Almost everybody around here (mostly experienced users, not programmers)
considers the device numbering used by cdrecord extremely impractical.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
A Bash poem: time for echo in canyon; do echo $echo $echo; done

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

[Keith Duthie]

On Wed, 8 Feb 2006, Joerg Schilling wrote:

> Sorry, but from reading the mail from _real_ cdrecord users, it is obvious
> that the people here are either not my users or users with a stange way of
> thinking.

I consider myself to be a real cdrecord user, and I find your SCSI ID
numbers to be incredibly annoying. With an external device the numbers
don't stay stable in any way shape or form, and generally change every
damned time the device is turned on.

Device names, on the other hand, do seem to be fairly stable, and are
actually meaningful (and can be made even more stable and meaningful
through creative use of udev). Why should I need to do a cdrecord -scanbus
when I can just use dev=/dev/scd0?

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

[Jim Crilly]

On 02/08/06 02:27:41PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > All you've explained is that using SCSI ID for device names is the way
> > you want cdrecord to work, not why it's infinitely better than using real
> > device names like every other userland program on every OS in existance.
> 
> I did many times, but people don't seem to listen.

But you've never answered the question as to why every other userland
program on every OS uses device names when cdrecord insists on using SCSI
IDs. Do you really think mount, fsck, tar, etc are broken because they let
the user use device names that they're accustomed to like /dev/c0t0d0s0? If
so, I look forward to the day that you try to patch OpenSolaris' userland
to work like cdrecord. 

> > The people replying here are your users, if you don't want to listen to
> > them pretty much any conversation with you will be a waste of time.
> 
> Sorry, but from reading the mail from _real_ cdrecord users, it is obvious
> that the people here are either not my users or users with a stange way of 
> thinking.

I think it's safe to say that most Linux users are cdrecord users whether
they want to be or not, there's just not any real viable alternatives
except for dvd+rw-tools and they don't work with regular CDs AFAIK.

And if you consider it strange to expect tools to accept normal device
names for the devices they're interacting with, I guess there's not much
hope of ever getting cdrecord fixed.

Jim.

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

[Joerg Schilling]

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

> On 02/08/06 02:27:41PM +0100, Joerg Schilling wrote:
> > "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> > 
> > > All you've explained is that using SCSI ID for device names is the way
> > > you want cdrecord to work, not why it's infinitely better than using real
> > > device names like every other userland program on every OS in existance.
> > 
> > I did many times, but people don't seem to listen.
>
> But you've never answered the question as to why every other userland
> program on every OS uses device names when cdrecord insists on using SCSI
> IDs. Do you really think mount, fsck, tar, etc are broken because they let
> the user use device names that they're accustomed to like /dev/c0t0d0s0? If
> so, I look forward to the day that you try to patch OpenSolaris' userland
> to work like cdrecord. 

You just verify that you don't listen...

I did answer this many times and I will not repeat it another time.

Note that you are of course wrong with your statement on other CD/DVD writing 
software.

What you like to see does not work at all on MS-WIN.

Jörg

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

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

[Jim Crilly]

On 02/08/06 05:32:38PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > On 02/08/06 02:27:41PM +0100, Joerg Schilling wrote:
> > > "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> > > 
> > > > All you've explained is that using SCSI ID for device names is the way
> > > > you want cdrecord to work, not why it's infinitely better than using real
> > > > device names like every other userland program on every OS in existance.
> > > 
> > > I did many times, but people don't seem to listen.
> >
> > But you've never answered the question as to why every other userland
> > program on every OS uses device names when cdrecord insists on using SCSI
> > IDs. Do you really think mount, fsck, tar, etc are broken because they let
> > the user use device names that they're accustomed to like /dev/c0t0d0s0? If
> > so, I look forward to the day that you try to patch OpenSolaris' userland
> > to work like cdrecord. 
> 
> You just verify that you don't listen...
 
Yes, I have been listening and I haven't seen you list one reason why
cdrecord absolutely has to use SCSI IDs when fsck can get away with using
/dev/blah just fine.

> I did answer this many times and I will not repeat it another time.
> 
> Note that you are of course wrong with your statement on other CD/DVD writing 
> software.

And of course you won't tell me exactly what I'm wrong about and/or point
me to some proof because then you might actually come off as helpful.

> What you like to see does not work at all on MS-WIN.

That's not my problem, but I would assume that Windows users would also
rather use a meaningful name like dev=D: instead of some random SCSI ID.

Jim.

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

[Joerg Schilling]

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

> > You just verify that you don't listen...
>  
> Yes, I have been listening and I haven't seen you list one reason why
> cdrecord absolutely has to use SCSI IDs when fsck can get away with using
> /dev/blah just fine.

Are you _really_ missing basic know how to understand that fsck is using the
block layer of a virtual "block device" emulated by UNIX while libscg is
offering _direct_ acces to _any_ type of device allowing you to send _commands_
understood by the device?

fsck is just sending abstract instructions to a virtual device and does 
not care about 

Please explain me:

-	how to use /dev/hd* in order to scan an image from a scanner

-	how to use /dev/hd* in order to talk to a CPU device

-	how to use /dev/hd* in order to talk to a tape device

-	how to use /dev/hd* in order to talk to a printer

-	how to use /dev/hd* in order to talk to a jukebox

-	how to use /dev/hd* in order to talk to a graphical device

Jörg

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

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

[Martin Mares]

Hello!

> Please explain me:
> 
> -	how to use /dev/hd* in order to scan an image from a scanner
> -	how to use /dev/hd* in order to talk to a CPU device
> -	how to use /dev/hd* in order to talk to a tape device
> -	how to use /dev/hd* in order to talk to a printer
> -	how to use /dev/hd* in order to talk to a jukebox
> -	how to use /dev/hd* in order to talk to a graphical device

Nobody speaks about using /dev/hd* for all that, just about that
there always will be a /dev/something corresponding to the device.

Also, as you have mentioned /dev/hd*, it seems that you consider
all these devices connected over ATAPI. Again an exercise in mythical
zoology as in the ATAPI tape example.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
For every complex problem, there's a solution that is simple, neat and wrong.

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

[Kyle Moffett]

Joerg Schilling wrote:
> -	how to use /dev/hd* in order to scan an image from a scanner
> -	how to use /dev/hd* in order to talk to a printer
> -	how to use /dev/hd* in order to talk to a jukebox
> -	how to use /dev/hd* in order to talk to a graphical device

Does cdrecord scan images, print files, or talk to SCSI graphical  
devices? No! Why do you care?  And furthermore, why the hell would  
you try to talk to one of those things via /dev/hd* anyways?  They  
certainly aren't ATA devices (aside from maybe a couple proprietary  
ATA jukeboxes, but those are likely SCSI anyways).

> -	how to use /dev/hd* in order to talk to a CPU device

Does cdrecord talk to CPU devices? No! Why do you care?  BTW: What  
the hell is a "CPU device" and why the hell would you think you could  
talk to it through a disk interface, let alone some other random SCSI  
interface?

> -	how to use /dev/hd* in order to talk to a tape device

Does cdrecord write to ATAPI tapes?  Not usually.  Why do you care?   
It's a possible bug in that /dev/hd* doesn't support ATAPI tapes, but  
nobody uses those anymore anyways (if it matters feel free to submit  
a bug report and patch).

By the way, are you ever actually going to try to point out any  
_actual_ problems?

Cheers,
Kyle Moffett

--
There are two ways of constructing a software design. One way is to  
make it so simple that there are obviously no deficiencies. And the  
other way is to make it so complicated that there are no obvious  
deficiencies.  The first method is far more difficult.
   -- C.A.R. Hoare

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

[Jim Crilly]

On 02/09/06 06:14:40PM -0500, Kyle Moffett wrote:
> Does cdrecord talk to CPU devices? No! Why do you care?  BTW: What  
> the hell is a "CPU device" and why the hell would you think you could  
> talk to it through a disk interface, let alone some other random SCSI  
> interface?
> 

We have several fiber controllers and the controller itself does show up as
a SCSI device that sg can bind to, I believe the management software can
actually manage the storage via that node but we've never used it and I
highly doubt anyone uses cdrecord or libscg for that purpose.

Jim.

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

[Joerg Schilling]

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

> On 02/09/06 06:14:40PM -0500, Kyle Moffett wrote:
> > Does cdrecord talk to CPU devices? No! Why do you care?  BTW: What  
> > the hell is a "CPU device" and why the hell would you think you could  
> > talk to it through a disk interface, let alone some other random SCSI  
> > interface?
> > 
>
> We have several fiber controllers and the controller itself does show up as
> a SCSI device that sg can bind to, I believe the management software can
> actually manage the storage via that node but we've never used it and I
> highly doubt anyone uses cdrecord or libscg for that purpose.

In fact, a "CPU device" (*) was it, that did give the initial push for my SCSI
activities in January 1985 and that did lead to the first SCSI genric driver
/dev/scg and libscg in August 1986.



*) Really a scanner but Scanner devices had not been defined by the SCSI
stabdard in 1985.


Jörg

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

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

[Joerg Schilling]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

> Joerg Schilling wrote:
> > -	how to use /dev/hd* in order to scan an image from a scanner
> > -	how to use /dev/hd* in order to talk to a printer
> > -	how to use /dev/hd* in order to talk to a jukebox
> > -	how to use /dev/hd* in order to talk to a graphical device
>
> Does cdrecord scan images, print files, or talk to SCSI graphical  

Are you _completely_ ingnoring the facts that have been discused here?

This does not apply to cdrecord but to libscg.

You either need to approach reality or stop this thread.

Jörg

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

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

[D. Hazelton]

On Friday 10 February 2006 07:15, Joerg Schilling wrote:
> Kyle Moffett <mrmacman_g4@mac.com> wrote:
> > Joerg Schilling wrote:
> > > -	how to use /dev/hd* in order to scan an image from a scanner
> > > -	how to use /dev/hd* in order to talk to a printer
> > > -	how to use /dev/hd* in order to talk to a jukebox
> > > -	how to use /dev/hd* in order to talk to a graphical device
> >
> > Does cdrecord scan images, print files, or talk to SCSI graphical
>
> Are you _completely_ ingnoring the facts that have been discused here?
>
> This does not apply to cdrecord but to libscg.
>
> You either need to approach reality or stop this thread.

I've taken the time to look through the libscg code and I see only one reason 
why it needs to use the BTL mappings at all - Joerg has a clean interface 
that is consistent across all the platforms.

Not that I'm going to defend him. I've kept quiet and tracked this thread from 
the beginning, hoping he would "see the light" as it were and realise that he 
can export a stable interface across almost all platforms with a few ifdefs 
and a bit of trickery to use various OS quirks to handle the work.

I am no expert on Windows, so I cannot comment on that, but I can, have and do 
read relevant sections of the POSIX and SuS when looking at problems and know 
that the _proper_, _portable_ and _UNIX_ way of accessing devices is via the 
block device special file. For SCSI cd burners the only way (I know of) to 
access them for writing (as /dev/sr0 cannot be opened for "write") is via the 
"SCSI Generic" (/dev/sg*) nodes, and to find and cross-map which /dev/sr* is 
which /dev/sg* is by the BTL. Needless to say, that should all be transparent 
to the user.

And, much to my surprise, Joerg's assertion that using /dev/hd* for accessing 
ATA/PI devices would require patching libscg is bunk. All he'd have to do is 
modify cdrecord to _internally_ (if it has to) perform the BTL mapping it 
wants. What's more, said interface code can be compiled out if it isn't a 
Linux system with a simple ifdef. 

But please note that libscg _is_ a generic SCSI access library. If needed it 
_can_ be used to access any SCSI device (and any ATA/PI device, at this 
point) via hand-crafted command packets. Not useful to the generic 
programmer, who is happy with the interfaces an OS provides, but for people 
doing things like data forensics...

(No disrespect meant for anyone, but if my tone comes off a bit rant-like it's 
because I'm sick of seeing one developer (of a GPL'd program) drag so many 
people down.)

DRH

PS: If I thought I had the knowledge of SCSI/ATAPI protocol to do so, I'd fork 
the code myself.

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

[Christoph Hellwig]

On Thu, Feb 09, 2006 at 07:37:46AM -0500, D. Hazelton wrote:
> read relevant sections of the POSIX and SuS when looking at problems and know 
> that the _proper_, _portable_ and _UNIX_ way of accessing devices is via the 
> block device special file. For SCSI cd burners the only way (I know of) to 
> access them for writing (as /dev/sr0 cannot be opened for "write")

You can access SCSI CDs using /dev/sr* for burning CDs.  It's backed by the
same highlevel code as SG_IO on /dev/hd* while the lowerlevel handling is
done transparently by the scsi midlayer, the same code used by /dev/sg* for
the below-blocklayer handling.

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

[Bill Davidsen]

Christoph Hellwig wrote:

> You can access SCSI CDs using /dev/sr* for burning CDs.  It's backed by the
> same highlevel code as SG_IO on /dev/hd* while the lowerlevel handling is
> done transparently by the scsi midlayer, the same code used by /dev/sg* for
> the below-blocklayer handling.
> 
This may be true if you create your own /dev entries, or are a udev guru 
and can get it to generate the right entries. And if you use ATAPI 
devices it works fine... But with Fedora and SuSE it appears that USB 
devices which appear as SCSI aren't functional. I tested the Fedora 
myself, and after killing udevd and making some entries by hand it 
worked once.

Now if you can access SCSI burners more power to you, with FC4 up to 
recent updates, my one convenient real SCSI device most definitely 
doesn't work, and I havd to fall the system back to Slackware and 2.4 
which was on it before.

Because you know how to get around the problems doesn't really suggest 
that there aren't any.

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

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

[Christoph Hellwig]

On Fri, Feb 17, 2006 at 03:55:34PM -0500, Bill Davidsen wrote:
> Christoph Hellwig wrote:
> 
> >You can access SCSI CDs using /dev/sr* for burning CDs.  It's backed by 
> >the
> >same highlevel code as SG_IO on /dev/hd* while the lowerlevel handling is
> >done transparently by the scsi midlayer, the same code used by /dev/sg* 
> >for
> >the below-blocklayer handling.
> >
> This may be true if you create your own /dev entries, or are a udev guru 
> and can get it to generate the right entries. And if you use ATAPI 
> devices it works fine... But with Fedora and SuSE it appears that USB 
> devices which appear as SCSI aren't functional. I tested the Fedora 
> myself, and after killing udevd and making some entries by hand it 
> worked once.
> 
> Now if you can access SCSI burners more power to you, with FC4 up to 
> recent updates, my one convenient real SCSI device most definitely 
> doesn't work, and I havd to fall the system back to Slackware and 2.4 
> which was on it before.
> 
> Because you know how to get around the problems doesn't really suggest 
> that there aren't any.

How are the dev entires related to CD burning?  If the device entries
don't appear for you that's a problem, but you deserve what you get
for using a POS like udev.  If you have a sd or sr node you can use
SG_IO on it, period.  Whether you can actually burn a CD of course
depends on the capability of the device.  I don't have a CD burner
connected through usb, but I couldn't think of a reason the usb <-> atapi
bridge would make problems with the scsi commands used to burn a CD.

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

[Bill Davidsen]

Christoph Hellwig wrote:

>On Fri, Feb 17, 2006 at 03:55:34PM -0500, Bill Davidsen wrote:
>  
>
>>Christoph Hellwig wrote:
>>
>>    
>>
>>>You can access SCSI CDs using /dev/sr* for burning CDs.  It's backed by 
>>>the
>>>same highlevel code as SG_IO on /dev/hd* while the lowerlevel handling is
>>>done transparently by the scsi midlayer, the same code used by /dev/sg* 
>>>for
>>>the below-blocklayer handling.
>>>
>>>      
>>>
>>This may be true if you create your own /dev entries, or are a udev guru 
>>and can get it to generate the right entries. And if you use ATAPI 
>>devices it works fine... But with Fedora and SuSE it appears that USB 
>>devices which appear as SCSI aren't functional. I tested the Fedora 
>>myself, and after killing udevd and making some entries by hand it 
>>worked once.
>>
>>Now if you can access SCSI burners more power to you, with FC4 up to 
>>recent updates, my one convenient real SCSI device most definitely 
>>doesn't work, and I havd to fall the system back to Slackware and 2.4 
>>which was on it before.
>>
>>Because you know how to get around the problems doesn't really suggest 
>>that there aren't any.
>>    
>>
>
>How are the dev entires related to CD burning?  If the device entries
>don't appear for you that's a problem, but you deserve what you get
>for using a POS like udev.  If you have a sd or sr node you can use
>SG_IO on it, period.  Whether you can actually burn a CD of course
>depends on the capability of the device.  I don't have a CD burner
>connected through usb, but I couldn't think of a reason the usb <-> atapi
>bridge would make problems with the scsi commands used to burn a CD.
>
>  
>
I'm sorry if I didn't make that clear. Some developers are saying that 
the application shouldn't be finding devices because udev does that so 
it doesn't matter that doing device location in the application is 
complex and poorly defined because udev does it for you. I was making 
the point that in the most common distributions (Fedora and SuSE) 
pluggable burners don't get proper entries in /dev to make cdrecord 
work. Based on a single report sent directly to me that seems to be the 
case in ubuntu as well, but I haven't personally tried it.

I was refuting the claim that applications no longer need to find their 
own devices; in many cases they do.

Burning using the USB devices works fine if the right devices are found 
and created.

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

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

[sean]

On Sat, 18 Feb 2006 11:44:25 -0500
Bill Davidsen <davidsen@tmr.com> wrote:

> I'm sorry if I didn't make that clear. Some developers are saying that 
> the application shouldn't be finding devices because udev does that so 
> it doesn't matter that doing device location in the application is 
> complex and poorly defined because udev does it for you. I was making 
> the point that in the most common distributions (Fedora and SuSE) 
> pluggable burners don't get proper entries in /dev to make cdrecord 
> work. Based on a single report sent directly to me that seems to be the 
> case in ubuntu as well, but I haven't personally tried it.

For whatever its worth, every burner i've ever tried on a Fedora box has
just worked.   But you misunderstand, people aren't saying udev is the 
only answer; they're just saying device nodes must exist.  It's up to each
distro to decide how that happens; and then for user space to decide how 
those device nodes are passed to each application.

> I was refuting the claim that applications no longer need to find their 
> own devices; in many cases they do.

As has been shown, everything needed for device enumeration is already 
available to user space.  Completing the job of making device enumeration 
easy for applications remains for user space services such as HAL et. al.
not the kernel.

> Burning using the USB devices works fine if the right devices are found 
> and created.

Yes, and if any device isn't found and created properly it's a bug that
should be fixed, not something which can be used to support Joerg's archaic
ideas.

Sean

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

[Luke-Jr]

On Friday 10 February 2006 12:15, Joerg Schilling wrote:
> Kyle Moffett <mrmacman_g4@mac.com> wrote:
> > Joerg Schilling wrote:
> > > -	how to use /dev/hd* in order to scan an image from a scanner
> > > -	how to use /dev/hd* in order to talk to a printer
> > > -	how to use /dev/hd* in order to talk to a jukebox
> > > -	how to use /dev/hd* in order to talk to a graphical device
> >
> > Does cdrecord scan images, print files, or talk to SCSI graphical
>
> Are you _completely_ ingnoring the facts that have been discused here?

Are you completely ignoring that nobody in this thread cares about libscg's 
ability to work with other devices? The problem is in the user-interface, and 
underlying workings is really pretty irrelevant to the matter.

> This does not apply to cdrecord but to libscg.

cdrecord contains the UI, so it is the only program relevant to the problem. 
If libscg is impeding fixing the bug (I don't think it is, but you seem to), 
then maybe cdrecord should use transport.hxx from growisofs.

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-09:

> Are you _really_ missing basic know how to understand that fsck is
> using the block layer of a virtual "block device" emulated by UNIX
> while libscg is offering _direct_ acces to _any_ type of device
> allowing you to send _commands_ understood by the device?

The key point that you are missing is that ONE device node allows you to
access the block layer as well as the mid layer. No more jumping hoops
to find out which auxiliary /dev/sr* device is associated with the
/dev/sg* you're talking to. No mapping abominations such as sg_map or
-scanbus are required to talk to the devices.

> fsck is just sending abstract instructions to a virtual device and does 
> not care about 

...what?

> Please explain me:
> 
> -	how to use /dev/hd* in order to scan an image from a scanner
> 
> -	how to use /dev/hd* in order to talk to a CPU device
> 
> -	how to use /dev/hd* in order to talk to a tape device
> 
> -	how to use /dev/hd* in order to talk to a printer
> 
> -	how to use /dev/hd* in order to talk to a jukebox
> 
> -	how to use /dev/hd* in order to talk to a graphical device

Well, you keep asking the question because you don't like the answer
that you've been given. It won't change just because you're asking
again.  The answer is still: You don't do that, and you've been told
several times.

Neither would you fsck a CPU, scan an image from a tape, rewind your CD
or request your scanner to change tapes.

The answer to all of the questions is also still: open the corresponding
/dev/* file and use SG_IO.

Where's the client code for libscg that scans, talks to CPU, printer,
sequential access device, jukebox or graphical device? Perhaps there is
none?

What is the practical device connected to Linux that libscg doesn't talk
to?  You were unable to provide examples where ATAPI tape doesn't work
(which isn't accessed via /dev/hd* BTW).

If you claim libscg is portable to Linux, you will have to accept that.
The kernel developers have decided that's their way to go, and I'm sure
as soon as a practical bug is found in that setup, you'll get the fix
quickly. I sent one fix for libscg that even simplifies the code, yet
you insist on using bugs that have been fixed a week ago as the basis
for your misguided attacks on Linux and Linux users.

This all only matters to you since you are trying to enforce the botched
view from some other OS (MS-Windows perhaps, although I'm not too sure
if it's really Windows or Jörg Schilling who is the problem in this
scenario either, and I'm a long way from defending Microsoft) onto
Linux, which you have been denied for 1½ years now, and from what I've
seen this year, with good reason.

IMO, after observing all this mess, /dev/sg* and other device nodes
should only be provided for devices not claimed by other drivers, and
all drivers should have SG_IO and other interfaces, to resolve
ambiguities in device naming. Having two device nodes for one device
doesn't seem right to me.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> This all only matters to you since you are trying to enforce the botched
> view from some other OS (MS-Windows perhaps, although I'm not too sure
> if it's really Windows or Jörg Schilling who is the problem in this
> scenario either, and I'm a long way from defending Microsoft) onto
> Linux, which you have been denied for 1½ years now, and from what I've
> seen this year, with good reason.

You look confused. It is not me but the Linux maintainers refuse to fix
bugs since about 2 years.

Jörg

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

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

[Nick Piggin]

Hi Joerg,

Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> 
>>This all only matters to you since you are trying to enforce the botched
>>view from some other OS (MS-Windows perhaps, although I'm not too sure
>>if it's really Windows or Jörg Schilling who is the problem in this
>>scenario either, and I'm a long way from defending Microsoft) onto
>>Linux, which you have been denied for 1½ years now, and from what I've
>>seen this year, with good reason.
> 
> 
> You look confused. It is not me but the Linux maintainers refuse to fix
> bugs since about 2 years.
> 

Regardless of whether you consider it a bug or the naming wrong[1], you
are not the Linux maintainer and Linux users have to put up with their
choices of kernel architecture.

So introducing your own naming scheme AFAIKS only serves to add more
confusion to the picture -- it seems fairly unlikely that you'll get the
kernel guys to change their minds.

Goes along the same lines as my point about filesystem naming. I wouldn't
write a portable program that asks users to save their files on /dev/hda
or /c_drive/blah when on windows. I'd agree to disagree with wnidows, and
use C:\ for the sake of everyone's sanity.

[1] I don't want to argue *that* point with you and I don't pretend
to know more about it than you or anyone else on this thread.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

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

[Ralf Müller]

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

On Donnerstag 09 Februar 2006 10:39, you wrote:
> Are you _really_ missing basic know how to understand that fsck is
> using the block layer of a virtual "block device" emulated by UNIX
> while libscg is offering _direct_ acces to _any_ type of device
> allowing you to send _commands_ understood by the device?

You mix things up. As this thread is about writing CD's and cdrecord, 
nobody here really wants you to use libscg to do your IO. Nobody here 
wants cdrecord to be able to access any type of device - all of the 
users of cdrecord just care about CD writers (and maybe DVD writers). 
That is because you call your program cdrecord and not scanimage oder 
cpuinfo. Actually none of the users of cdrecord even cares about how it 
is able to talk to CD writers. They know that all other operations to 
the CD writer can be done via /dev/cdrw, or however it is called on 
their system, and would like to use the same device name to write a CD. 
If libscg is unable to handle device names and needs to be feed with 
strange numbers to address the writer, then libscg may be the wrong 
tool.

> Please explain me:
>
> -	how to use /dev/hd* in order to scan an image from a scanner
>
> -	how to use /dev/hd* in order to talk to a CPU device
>
> -	how to use /dev/hd* in order to talk to a tape device
>
> -	how to use /dev/hd* in order to talk to a printer
>
> -	how to use /dev/hd* in order to talk to a jukebox
>
> -	how to use /dev/hd* in order to talk to a graphical device

I don't expect cdrecord to be able to do any of these jobs. I'd just 
like to write a CD. To be honest - even if libscg would be able to peel 
carrots I couldn't care less.

As for cdrecord I'm just one of those stupid users. I have a problem 
(write a CD) - I'd like to solve this problem. And if the device 
addressing scheme of cdrecord is different to all I've seen before from 
all the other tools in my system, I blame cdrecord to be annoying not 
the rest of my system - just because I have to investigate how to deal 
with this program, instead of just being able to use it like all the 
rest.

My 2 cents
Ralf

-- 
Van Roy's Law: -------------------------------------------------------
       An unbreakable toy is useful for breaking other toys.

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

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

[Jan Engelhardt]

>Please explain me:
>
>-	how to use /dev/hd* in order to scan an image from a scanner
>-	how to use /dev/hd* in order to talk to a CPU device
>-	how to use /dev/hd* in order to talk to a tape device
>-	how to use /dev/hd* in order to talk to a printer
>-	how to use /dev/hd* in order to talk to a jukebox
>-	how to use /dev/hd* in order to talk to a graphical device
>
With /dev/sg, this was possible?


Jan Engelhardt
-- 

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

[Joerg Schilling]

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

> >Please explain me:
> >
> >-	how to use /dev/hd* in order to scan an image from a scanner
> >-	how to use /dev/hd* in order to talk to a CPU device
> >-	how to use /dev/hd* in order to talk to a tape device
> >-	how to use /dev/hd* in order to talk to a printer
> >-	how to use /dev/hd* in order to talk to a jukebox
> >-	how to use /dev/hd* in order to talk to a graphical device
> >
> With /dev/sg, this was possible?

Of course!

Jörg

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

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

[Jan Engelhardt]

>> >Please explain me:
>> >
>> >-	how to use /dev/hd* in order to scan an image from a scanner
>> >-	how to use /dev/hd* in order to talk to a CPU device
>> >-	how to use /dev/hd* in order to talk to a tape device
>> >-	how to use /dev/hd* in order to talk to a printer
>> >-	how to use /dev/hd* in order to talk to a jukebox
>> >-	how to use /dev/hd* in order to talk to a graphical device
>> >
>> With /dev/sg, this was possible?
>
>Of course!
>
But you need to open the correct /dev/sg[0-9] too, don't you?
(otherwise cdrecord would set the jukebox on fire)


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

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

[Joerg Schilling]

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

> >> >Please explain me:
> >> >
> >> >-	how to use /dev/hd* in order to scan an image from a scanner
> >> >-	how to use /dev/hd* in order to talk to a CPU device
> >> >-	how to use /dev/hd* in order to talk to a tape device
> >> >-	how to use /dev/hd* in order to talk to a printer
> >> >-	how to use /dev/hd* in order to talk to a jukebox
> >> >-	how to use /dev/hd* in order to talk to a graphical device
> >> >
> >> With /dev/sg, this was possible?
> >
> >Of course!
> >
> But you need to open the correct /dev/sg[0-9] too, don't you?
> (otherwise cdrecord would set the jukebox on fire)

This is why the mapping engine is in the Linux adoption part of
libscg. It maps the non-stable device <-> /dev/sg* relation to a
stable b,t,l address.



Jörg

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

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

[Matthias Andree]

Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
>>>>> Please explain me:
>>>>>
>>>>> -	how to use /dev/hd* in order to scan an image from a scanner
>>>>> -	how to use /dev/hd* in order to talk to a CPU device
>>>>> -	how to use /dev/hd* in order to talk to a tape device
>>>>> -	how to use /dev/hd* in order to talk to a printer
>>>>> -	how to use /dev/hd* in order to talk to a jukebox
>>>>> -	how to use /dev/hd* in order to talk to a graphical device
>>>>>
>>>> With /dev/sg, this was possible?
>>> Of course!
>>>
>> But you need to open the correct /dev/sg[0-9] too, don't you?
>> (otherwise cdrecord would set the jukebox on fire)
> 
> This is why the mapping engine is in the Linux adoption part of
> libscg. It maps the non-stable device <-> /dev/sg* relation to a
> stable b,t,l address.

Well, the b,t,l mapping, judging from libscg code, is as stable as the
ordering of the device nodes themselves, so it is not clear what the
advantage would be other than getting a uniform and artificial b,t,l mapping.

If hotplugging shuffles /dev/sg* between running $APPLICATION -scanbus and
$APPLICATION -dowhatever, the b,t,l will change as well.

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

[Jan Engelhardt]

>>>>
>>> But you need to open the correct /dev/sg[0-9] too, don't you?
>>> (otherwise cdrecord would set the jukebox on fire)
>> 
>> This is why the mapping engine is in the Linux adoption part of
>> libscg. It maps the non-stable device <-> /dev/sg* relation to a
>> stable b,t,l address.
>
>Well, the b,t,l mapping, judging from libscg code, is as stable as the
>ordering of the device nodes themselves, so it is not clear what the
>advantage would be other than getting a uniform and artificial b,t,l mapping.
>
>If hotplugging shuffles /dev/sg* between running $APPLICATION -scanbus and
>$APPLICATION -dowhatever, the b,t,l will change as well.
>

Don't interrupt my (trick) thread (as explained before in private).
Thank you.



Jan Engelhardt
-- 

Re: CD writing in future Linux

[Jan Engelhardt]

>Don't interrupt my (trick) thread (as explained before in private).
...which consisted of avoiding potential flamewars, but it's already 
failed long before I posted.

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

[Joerg Schilling]

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

> > This is why the mapping engine is in the Linux adoption part of
> > libscg. It maps the non-stable device <-> /dev/sg* relation to a
> > stable b,t,l address.
>
> Well, the b,t,l mapping, judging from libscg code, is as stable as the
> ordering of the device nodes themselves, so it is not clear what the
> advantage would be other than getting a uniform and artificial b,t,l mapping.

It would help a lot if you at least _try_ to inform yourself before posting.

Jörg

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

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

[Martin Mares]

Hello!

> This is why the mapping engine is in the Linux adoption part of
> libscg. It maps the non-stable device <-> /dev/sg* relation to a
> stable b,t,l address.

Nonsense. The b,t,l addresses are NOT stable (at least for transports
where the kernel would have to make them up) unless you take an extra
effort to make them stable (like I understand Solaris does). But you
can use the same extra effort to make the /dev entries stable (like
udev does).

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
COBOL -- Compiles Only Because Of Luck

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> Hello!
>
> > This is why the mapping engine is in the Linux adoption part of
> > libscg. It maps the non-stable device <-> /dev/sg* relation to a
> > stable b,t,l address.
>
> Nonsense. The b,t,l addresses are NOT stable (at least for transports

Dou you like to verify that you have no clue on 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 (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-10:

> Martin Mares <mj@ucw.cz> wrote:
> 
> > Hello!
> >
> > > This is why the mapping engine is in the Linux adoption part of
> > > libscg. It maps the non-stable device <-> /dev/sg* relation to a
> > > stable b,t,l address.
> >
> > Nonsense. The b,t,l addresses are NOT stable (at least for transports
> 
> Dou you like to verify that you have no clue on SCSI?

How does, for instance, libscg make sure that the b,t,l mappings are
hotplug invariant?

How does libscg make sure that two external writers, say USB, retain
their b,t,l mappings if both are unplugged and then replugged in reverse
order, perhaps into different USB hubs?

What assumptions does libscg (or cdrecord) make to procure stable
mappings?

You complained the discussion were non-technical, yet rather than
correcting false information at detail scale, you resort to personal
insults, and I think you're standing on pretty thin ice with those
attacks. Your credibility is about to reach zero.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> > > Nonsense. The b,t,l addresses are NOT stable (at least for transports
> > 
> > Dou you like to verify that you have no clue on SCSI?
>
> How does, for instance, libscg make sure that the b,t,l mappings are
> hotplug invariant?
>
> How does libscg make sure that two external writers, say USB, retain
> their b,t,l mappings if both are unplugged and then replugged in reverse
> order, perhaps into different USB hubs?

Well, this is a deficit of the Linux kernel - not libscg.

If you are unhappy with Hot plug support on Linux, I recommend you to
check Solaris.

Jörg

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

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

[D. Hazelton]

On Friday 10 February 2006 07:35, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports
> > >
> > > Dou you like to verify that you have no clue on SCSI?
> >
> > How does, for instance, libscg make sure that the b,t,l mappings are
> > hotplug invariant?
> >
> > How does libscg make sure that two external writers, say USB, retain
> > their b,t,l mappings if both are unplugged and then replugged in reverse
> > order, perhaps into different USB hubs?
>
> Well, this is a deficit of the Linux kernel - not libscg.
>
> If you are unhappy with Hot plug support on Linux, I recommend you to
> check Solaris.
>
> Jörg

I've replied once already, but this is going to far. Joerg, if you are so 
unhappy with Linux that you'd actively tell people on the _LINUX_KERNEL_ 
mailing list to go use another OS then you have a problem.

If, however, you have a point to make, make it. I switched to Linux 
_completely_ before it even supported the box I was running fully back around 
kernel 2.0.24 and had run it alongside windows since late in Kernel 1 series. 
The system has evolved, gotten faster, better and more standards compliant. 
Then you come along with this teutonic "I'm the Perfect Programmer" BS and 
expect everyone to change the way something works just for _your_ library.
I'm sorry but that is, and I'm being nice here, childish. Programs and 
libraries *_DO_* *_NOT_* define how an OS does things, they use the framework 
the OS supplies and work within it. With that in mind I'll say the last thing 
I ever will on this subject - Your code is broken if it does things in a way 
that is non-standard to the OS.

And does cdrecord even need libscg anymore? From having actually gone through 
your code, Joerg, I can tell you that it does serve a larger purpose. But at 
this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_ 
writing programs, does _ANYONE_ use libscg? Is it ever used to access any 
other devices that are either SCSI or use a SCSI command protocol (like 
ATAPI)?  My point there is that you have a wonderful library, but despite 
your wishes, there is no proof that it is ever used for anything except 
writing/ripping CD's.

If anything, the best solution would be to split libscg away from the cdrtools 
package and release it on it's own. You do that and it might even make the 
SANE people happy. All the cdrtools package needs is an interface library for 
CDR/RW stuff and having the code capable of doing anything else is merely 
bloat.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> And does cdrecord even need libscg anymore? From having actually gone through 
> your code, Joerg, I can tell you that it does serve a larger purpose. But at 
> this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_ 
> writing programs, does _ANYONE_ use libscg? Is it ever used to access any 
> other devices that are either SCSI or use a SCSI command protocol (like 
> ATAPI)?  My point there is that you have a wonderful library, but despite 
> your wishes, there is no proof that it is ever used for anything except 
> writing/ripping CD's.

Name a single program (not using libscg) that implements user space SCSI and runs 
on as many platforms as cdrecord/libscg does.

Jörg

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

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

[D. Hazelton]

On Friday 10 February 2006 08:03, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > And does cdrecord even need libscg anymore? From having actually gone
> > through your code, Joerg, I can tell you that it does serve a larger
> > purpose. But at this point I have to ask - besides cdrecord and a few
> > other _COMPACT_ _DISC_ writing programs, does _ANYONE_ use libscg? Is it
> > ever used to access any other devices that are either SCSI or use a SCSI
> > command protocol (like ATAPI)?  My point there is that you have a
> > wonderful library, but despite your wishes, there is no proof that it is
> > ever used for anything except writing/ripping CD's.
>
> Name a single program (not using libscg) that implements user space SCSI
> and runs on as many platforms as cdrecord/libscg does.

I'm not the maintainer of a program, and hence I don't have to.

But why in the hell do you even _need_ SCSI in userspace when the kernel 
provides complete facilities? And even then your argument is specious, since 
when I did go through the code for libscg all it provided was a simple 
wrapper around those kernel facilities for as many OS's as had them. And for 
the OS's that didn't have it, then you implemented what you could. You really 
need to stop with the finger pointing and accept that you have a problem in 
your philosophy.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > Name a single program (not using libscg) that implements user space SCSI
> > and runs on as many platforms as cdrecord/libscg does.
>
> I'm not the maintainer of a program, and hence I don't have to.
>
> But why in the hell do you even _need_ SCSI in userspace when the kernel 
> provides complete facilities? And even then your argument is specious, since 

Then please try to inform yourself in order to understand that you are wrong.


libscg abstracts from a kernel specific transport and allows to write OS 
independent applications that rely in generic SCSI transport.

For this reason, it is bejond the scope of the Linux kernel team to decide on 
this abstraction layer. The Linux kernel team just need to take the current
libscg interface as given as _this_  _is_ the way to do best abstraction.

The Linux kernel team has the freedom to boycott portable user space SCSI 
applications or to support them.



Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:


> Then please try to inform yourself in order to understand that you are wrong.

No, it is _you_ and nobody else who refuses information.

> For this reason, it is bejond the scope of the Linux kernel team to decide on 
> this abstraction layer. The Linux kernel team just need to take the current
> libscg interface as given as _this_  _is_ the way to do best abstraction.

This is ridiculous. The abstraction (SG_IO on an open special file) is
in the kernel. Feel free to stack as many layers on top as you wish, but
the kernel isn't going to bend just to support a random abstraction
library that cannot achieve its goals in its current form anyways.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> > For this reason, it is bejond the scope of the Linux kernel team to decide on 
> > this abstraction layer. The Linux kernel team just need to take the current
> > libscg interface as given as _this_  _is_ the way to do best abstraction.
>
> This is ridiculous. The abstraction (SG_IO on an open special file) is
> in the kernel. Feel free to stack as many layers on top as you wish, but
> the kernel isn't going to bend just to support a random abstraction
> library that cannot achieve its goals in its current form anyways.

Try to inform yourself on the difference between an IOCTL and a /dev/ entry.

Jörg

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

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

[D. Hazelton]

On Monday 13 February 2006 10:15, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> > > For this reason, it is bejond the scope of the Linux kernel team to
> > > decide on this abstraction layer. The Linux kernel team just need to
> > > take the current libscg interface as given as _this_  _is_ the way to
> > > do best abstraction.
> >
> > This is ridiculous. The abstraction (SG_IO on an open special file) is
> > in the kernel. Feel free to stack as many layers on top as you wish, but
> > the kernel isn't going to bend just to support a random abstraction
> > library that cannot achieve its goals in its current form anyways.
>
> Try to inform yourself on the difference between an IOCTL and a /dev/
> entry.

I believe he did make the distinction there. He states "The abstraction (SG_IO 
on an open special file) is in the kernel." An "open special file" could be 
anything, but in this case it's meant to refer to a /dev/ entry. The point he 
made is valid, and it appears that in this case, Joerg, you are the one who 
is "technically uninformed".

DRH

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

[Martin Mares]

Hello!

> libscg abstracts from a kernel specific transport and allows to write OS 
> independent applications that rely in generic SCSI transport.
> 
> For this reason, it is bejond the scope of the Linux kernel team to decide on 
> this abstraction layer. The Linux kernel team just need to take the current
> libscg interface as given as _this_  _is_ the way to do best abstraction.

Do you really believe that libscg is the only way in the world how to
access SCSI devices?

How can you be so sure that the abstraction you have chosen is the only
possible one?

If an answer to either of this questions is NO, why do you insist on
everybody bending their rules to suit your model?

> The Linux kernel team has the freedom to boycott portable user space SCSI 
> applications or to support them.

That's really an interesting view ... if anybody is boycotting anybody,
then it's clearly you, because you refuse to extend libscg to support
the Linux model, although it's clearly possible.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Ctrl and Alt keys stuck -- press Del to continue.

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> Hello!
>
> > libscg abstracts from a kernel specific transport and allows to write OS 
> > independent applications that rely in generic SCSI transport.
> > 
> > For this reason, it is bejond the scope of the Linux kernel team to decide on 
> > this abstraction layer. The Linux kernel team just need to take the current
> > libscg interface as given as _this_  _is_ the way to do best abstraction.
>
> Do you really believe that libscg is the only way in the world how to
> access SCSI devices?
>
> How can you be so sure that the abstraction you have chosen is the only
> possible one?
>
> If an answer to either of this questions is NO, why do you insist on
> everybody bending their rules to suit your model?

Name me any other lib that is as OS independent and as clean/stable as
libscg is. Note that the interface from libscg did not really change 
since August 1986. 


> > The Linux kernel team has the freedom to boycott portable user space SCSI 
> > applications or to support them.
>
> That's really an interesting view ... if anybody is boycotting anybody,
> then it's clearly you, because you refuse to extend libscg to support
> the Linux model, although it's clearly possible.

Looks like you did not follow the discussion :-(

I am constantly working on better support for Linux while the Linux kernel
folks do not even fix obvious bugs.

Jörg

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

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

[Jim Crilly]

On 02/13/06 04:29:37PM +0100, Joerg Schilling wrote:
> Martin Mares <mj@ucw.cz> wrote:
> Looks like you did not follow the discussion :-(
> 
> I am constantly working on better support for Linux while the Linux kernel
> folks do not even fix obvious bugs.
> 
> Jörg

I guess that depends on your definition of 'working'. From everyone's
perspective but your own, all you've done is sling mud and scream about
how great Solaris is and how Linux needs to emulate it's conventions.

Jim.

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

[D. Hazelton]

On Monday 13 February 2006 10:29, Joerg Schilling wrote:
> Martin Mares <mj@ucw.cz> wrote:
> > Hello!
> >
> > > libscg abstracts from a kernel specific transport and allows to write
> > > OS independent applications that rely in generic SCSI transport.
> > >
> > > For this reason, it is bejond the scope of the Linux kernel team to
> > > decide on this abstraction layer. The Linux kernel team just need to
> > > take the current libscg interface as given as _this_  _is_ the way to
> > > do best abstraction.
> >
> > Do you really believe that libscg is the only way in the world how to
> > access SCSI devices?
> >
> > How can you be so sure that the abstraction you have chosen is the only
> > possible one?
> >
> > If an answer to either of this questions is NO, why do you insist on
> > everybody bending their rules to suit your model?
>
> Name me any other lib that is as OS independent and as clean/stable as
> libscg is. Note that the interface from libscg did not really change
> since August 1986.

OS Independant? Almost every userspace library that a linux system uses is OS 
independant. Stable interface? That's much harder since _most_ libraries 
change their interfaces incrementally as new technology or techniques become 
available to support them.

I did have an idea the other day and was wondering - why can't you, Joerg, add 
the capacity to CDRECORD to silently take a given /dev entry and turn it into 
your "needed" btl mapping?

> > > The Linux kernel team has the freedom to boycott portable user space
> > > SCSI applications or to support them.
> >
> > That's really an interesting view ... if anybody is boycotting anybody,
> > then it's clearly you, because you refuse to extend libscg to support
> > the Linux model, although it's clearly possible.
>
> Looks like you did not follow the discussion :-(
>
> I am constantly working on better support for Linux while the Linux kernel
> folks do not even fix obvious bugs.
>

Yes, you are, but you have made a very large mistake in your thinking. As an 
application and library developer you are supposed to build an application 
that works properly inside the framework provided by the OS. If your 
application does not work within the OS, then there is either a large bug in 
the OS (Not unheard of for M$ products, but in an Open Source product like 
Linux bugs that large do not survive long) or a bug in your program.

Since there is obviously no bug in the OS, and obviously no bug in cdrecord (I 
use it about once a week to make multi-cd backups) then your complaints about 
the "badly designed /dev/hd*" interface are just complaints from a programmer 
that thinks he's smarter than a hundred other people.

Since you appear to be a proponent of Solaris and use that on a regular basis 
it's my guess that you either 1) don't have the skill to create an OS and 
release it or 2) you are so mired in history and the "beauty" of your code 
that you refuse to change it at all. In this case I think the second option 
is the truth.

DRH

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

[Alexander Samad]

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

On Mon, Feb 13, 2006 at 04:29:37PM +0100, Joerg Schilling wrote:
> Martin Mares <mj@ucw.cz> wrote:
> 
> > Hello!
> >
> > > libscg abstracts from a kernel specific transport and allows to write OS 
> > > independent applications that rely in generic SCSI transport.
> > > 
> > > For this reason, it is bejond the scope of the Linux kernel team to decide on 
> > > this abstraction layer. The Linux kernel team just need to take the current
> > > libscg interface as given as _this_  _is_ the way to do best abstraction.
> >
> > Do you really believe that libscg is the only way in the world how to
> > access SCSI devices?
> >
> > How can you be so sure that the abstraction you have chosen is the only
> > possible one?
> >
> > If an answer to either of this questions is NO, why do you insist on
> > everybody bending their rules to suit your model?
> 
> Name me any other lib that is as OS independent and as clean/stable as
> libscg is. Note that the interface from libscg did not really change 
> since August 1986. 

off the top of my head the standard C library been fairly stable

> 
> 
> > > The Linux kernel team has the freedom to boycott portable user space SCSI 
> > > applications or to support them.
> >
> > That's really an interesting view ... if anybody is boycotting anybody,
> > then it's clearly you, because you refuse to extend libscg to support
> > the Linux model, although it's clearly possible.
> 
> Looks like you did not follow the discussion :-(
> 
> I am constantly working on better support for Linux while the Linux kernel
> folks do not even fix obvious bugs.
> 
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

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

[D. Hazelton]

On Monday 13 February 2006 08:40, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > Name a single program (not using libscg) that implements user space
> > > SCSI and runs on as many platforms as cdrecord/libscg does.
> >
> > I'm not the maintainer of a program, and hence I don't have to.
> >
> > But why in the hell do you even _need_ SCSI in userspace when the kernel
> > provides complete facilities? And even then your argument is specious,
> > since
>
> Then please try to inform yourself in order to understand that you are
> wrong.

Inform myself? Before this discussion even began I had spent hours trying to 
figure out how to use libscg and decided to just use the provided linux 
systems and worry about porting to other systems if I ever finished the 
project. As far as I'm concerned, Linux provides enough of an abstraction 
layer that anyone with a bit of programming skill and access to the proper 
documentation can do _anything_ they want.

A personal attack like this is how flame wars get started - I will not be 
party to one. And again you show your colors as a troll, by making a personal 
attack. The only saving grace is that you did explain yourself.

>
> libscg abstracts from a kernel specific transport and allows to write OS
> independent applications that rely in generic SCSI transport.

I still think that on modern operating systems libscg needs to be nothing more 
than a wrapper around the OS specific code. Anything added extra beyond that 
is actually unneeded.

> For this reason, it is bejond the scope of the Linux kernel team to decide
> on this abstraction layer. The Linux kernel team just need to take the
> current libscg interface as given as _this_  _is_ the way to do best
> abstraction.

Why is it the best? Because you wrote it? Beyond cdrtools I have seen only one 
user of it (and I don't know that that program hasn't been silently folded 
into cdrtools recently). The fact that no one else has written a SCSI wrapper 
means a few things. One: That nobody else has ever seen the need for it. Two: 
That most programmers are like me - lazy and unwilling to "reinvent the 
wheel" for any project. In truth, it's not an "either-or" it's both of those 
reasons. 

And my point still remains - applications and libraries must _WORK_ _WITHIN_ 
the framework provided by the OS. No application or library that attempts to 
define the way an OS works is valid - this is a simple fact that you seem 
unable to grasp.

> The Linux kernel team has the freedom to boycott portable user space SCSI
> applications or to support them.

so I'm guessing you think that your userbase is happy with your scheme? If 
they are anything like most people I know they have just resigned themselves 
to using a bad interface or they use a GUI that hides the complexities of the 
interface from them.

And even then, as someone else pointed out, two drives that are identical in 
all respects except color, plugged onto two seperate busses, will appear the 
same in the scanbus listing. How can a user tell them apart?

DRH

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

[Dmitry Torokhov]

On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
>
> > And does cdrecord even need libscg anymore? From having actually gone through
> > your code, Joerg, I can tell you that it does serve a larger purpose. But at
> > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_
> > writing programs, does _ANYONE_ use libscg? Is it ever used to access any
> > other devices that are either SCSI or use a SCSI command protocol (like
> > ATAPI)?  My point there is that you have a wonderful library, but despite
> > your wishes, there is no proof that it is ever used for anything except
> > writing/ripping CD's.
>
> Name a single program (not using libscg) that implements user space SCSI and runs
> on as many platforms as cdrecord/libscg does.
>

Joerg,

Please name a single program/package besides cdrtools that is using
libscg. Face it, you created and maintained a very decent CD writing
program but world domination is a bit out of reach.

--
Dmitry

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

[D. Hazelton]

On Friday 10 February 2006 08:25, Dmitry Torokhov wrote:
> On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > "D. Hazelton" <dhazelton@enter.net> wrote:
> > > And does cdrecord even need libscg anymore? From having actually gone
> > > through your code, Joerg, I can tell you that it does serve a larger
> > > purpose. But at this point I have to ask - besides cdrecord and a few
> > > other _COMPACT_ _DISC_ writing programs, does _ANYONE_ use libscg? Is
> > > it ever used to access any other devices that are either SCSI or use a
> > > SCSI command protocol (like ATAPI)?  My point there is that you have a
> > > wonderful library, but despite your wishes, there is no proof that it
> > > is ever used for anything except writing/ripping CD's.
> >
> > Name a single program (not using libscg) that implements user space SCSI
> > and runs on as many platforms as cdrecord/libscg does.
>
> Joerg,
>
> Please name a single program/package besides cdrtools that is using
> libscg. Face it, you created and maintained a very decent CD writing
> program but world domination is a bit out of reach.

Exactly.

He has done exactly that, but since then the world has moved on and he refuses 
to see the truth.

Joerg - Lieber gott in himmel! You probably missed 90% of my argument anyway. 
So here it is encapsulated:

Userspace does not define kernel semantics or facilities. Standards do that, 
and where standards are lacking, the kernel has to provide what it can.

Now before you go off and start screaming about the SCSI spec, be aware that I 
_HAVE_ _READ_ _THEM_ and nowhere do I see it stated that the kernel has to 
export the SCSI transport layers internal numbering to userspace. All I have 
seen is that the SCSI system uses a "Host/Bus/Target/Lun" identification 
system internally. As someone else pointed out, /dev/sr* can be used for 
writing CD's with the SG_IO system since the same transport code sits under 
said device as all other block devices. This means that if a program wants to 
write to the device identified by /dev/sr0 or /dev/hda the kernel knows which 
HOST/BUS/TARGET/LUN is meant by it. No need to artificially provide those 
identifiers.

As someone else also pointed out, your code doesn't map devices in a sane 
manner. BTL mapping can change with hotplug, and all your arguments about 
st_dev are bullshit. From reading the spec you pointed at it seems that 
st_dev points to the _underlying_ _device_ - which will be stable despite 
everything.

Understood?

And before I go, let me reiterate a true statement someone else said:
libscg is not the problem - it is the backend. If you _need_ said BTL 
mappings, why can't cdrecord take the provide /dev/hd* or /dev/sr* and 
translate it internally into the BTL mapping you need?

DRH

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

[jerome lacoste]

On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
>
> > And does cdrecord even need libscg anymore? From having actually gone through
> > your code, Joerg, I can tell you that it does serve a larger purpose. But at
> > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_
> > writing programs, does _ANYONE_ use libscg? Is it ever used to access any
> > other devices that are either SCSI or use a SCSI command protocol (like
> > ATAPI)?  My point there is that you have a wonderful library, but despite
> > your wishes, there is no proof that it is ever used for anything except
> > writing/ripping CD's.
>
> Name a single program (not using libscg) that implements user space SCSI and runs
> on as many platforms as cdrecord/libscg does.


I have 2 technical questions, and I hope that you will take the time
to answer them.

1) extract from the README of the latest stable cdrtools package:

        Linux driver design oddities ******************************************
        Although cdrecord supports to use dev=/dev/sgc, it is not recommended
        and it is unsupported.

        The /dev/sg* device mapping in Linux is not stable! Using dev=/dev/sgc
        in a shell script may fail after a reboot because the device you want
        to talk to has moved to /dev/sgd. For the proper and OS independent
        dev=<bus>,<tgt>,<lun> syntax read the man page of cdrecord.

My understanding of that is you say to not use dev=/dev/sgc because it
isn't stable. Now that you've said that bus,tgt,lun is not stable on
Linux (because of a "Linux bug") why is the b,t,l scheme preferred
over the /dev/sg* one ?


2) design question:

- cdrecord scans then maps the device to the b,t,l scheme.
- the libsg uses the b,t,l ids in its interface to perform the operations

So now, if cdrecord could have a new option called -scanbusmap that
displays the mapping it performs in a way that people can parse the
output, I think that will solve most issues.

cdrecord already has this information available, it just doesn't display it:

$ cdrecord debug=2 dev=ATAPI -scanbus 2>&1 | grep INFO
INFO: /dev/hdc, (host0/bus1/target0/lun0) will be mapped on the
schilly bus No 0 (0,0,0)
INFO: /dev/hdd, (host0/bus1/target1/lun0) will be mapped on the
schilly bus No 0 (0,1,0)

It could perform in the following way:

$ cdrecord dev=ATAPI  -scanbusmap
...

0,0,0 <= /dev/hdc
0,1,0 <= /dev/hdd


Are you accepting such a patch?

Jerome

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

[D. Hazelton]

On Friday 10 February 2006 10:38, jerome lacoste wrote:
> On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > "D. Hazelton" <dhazelton@enter.net> wrote:
> > > And does cdrecord even need libscg anymore? From having actually gone
> > > through your code, Joerg, I can tell you that it does serve a larger
> > > purpose. But at this point I have to ask - besides cdrecord and a few
> > > other _COMPACT_ _DISC_ writing programs, does _ANYONE_ use libscg? Is
> > > it ever used to access any other devices that are either SCSI or use a
> > > SCSI command protocol (like ATAPI)?  My point there is that you have a
> > > wonderful library, but despite your wishes, there is no proof that it
> > > is ever used for anything except writing/ripping CD's.
> >
> > Name a single program (not using libscg) that implements user space SCSI
> > and runs on as many platforms as cdrecord/libscg does.
>
> I have 2 technical questions, and I hope that you will take the time
> to answer them.
>
> 1) extract from the README of the latest stable cdrtools package:
>
>         Linux driver design oddities
> ****************************************** Although cdrecord supports to
> use dev=/dev/sgc, it is not recommended and it is unsupported.
>
>         The /dev/sg* device mapping in Linux is not stable! Using
> dev=/dev/sgc in a shell script may fail after a reboot because the device
> you want to talk to has moved to /dev/sgd. For the proper and OS
> independent dev=<bus>,<tgt>,<lun> syntax read the man page of cdrecord.
>
> My understanding of that is you say to not use dev=/dev/sgc because it
> isn't stable. Now that you've said that bus,tgt,lun is not stable on
> Linux (because of a "Linux bug") why is the b,t,l scheme preferred
> over the /dev/sg* one ?

Excellent question. Well Joerg, can you give us a good answer, or will it be 
more finger pointing, mud slinging and FUD ?

>
> 2) design question:
>
> - cdrecord scans then maps the device to the b,t,l scheme.
> - the libsg uses the b,t,l ids in its interface to perform the operations
>
> So now, if cdrecord could have a new option called -scanbusmap that
> displays the mapping it performs in a way that people can parse the
> output, I think that will solve most issues.

I'm wondering this myself. If Joerg didn't seem to think everyone in the world 
was an idiot I'd attempt this myself and submit it.

> cdrecord already has this information available, it just doesn't display
> it:
>
> $ cdrecord debug=2 dev=ATAPI -scanbus 2>&1 | grep INFO
> INFO: /dev/hdc, (host0/bus1/target0/lun0) will be mapped on the
> schilly bus No 0 (0,0,0)
> INFO: /dev/hdd, (host0/bus1/target1/lun0) will be mapped on the
> schilly bus No 0 (0,1,0)
>
> It could perform in the following way:
>
> $ cdrecord dev=ATAPI  -scanbusmap
> ...
>
> 0,0,0 <= /dev/hdc
> 0,1,0 <= /dev/hdd
>
>
> Are you accepting such a patch?

If his response to the last patch someone provided is any example the answer 
is going to be no. And I firmly believe the old adage that a leopard can't 
change it's spots.

> Jerome


DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > Are you accepting such a patch?
>
> If his response to the last patch someone provided is any example the answer 
> is going to be no. And I firmly believe the old adage that a leopard can't 
> change it's spots.

Any patch that

-	does not break things

-	fits into the spirit of the currnt implementation

-	offers useful new features

-	conforms to coding style standards

-	does not need more time to integrate than I would need to
	write this from scratch

Unfortunately, many people who send patches to me do not follow
these simple rules.


Jörg

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

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

[jerome lacoste]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
>
> > > Are you accepting such a patch?
> >
> > If his response to the last patch someone provided is any example the answer
> > is going to be no. And I firmly believe the old adage that a leopard can't
> > change it's spots.
>
> Any patch that
>
> -       does not break things
>
> -       fits into the spirit of the currnt implementation
>
> -       offers useful new features
>
> -       conforms to coding style standards
>
> -       does not need more time to integrate than I would need to
>         write this from scratch
>
> Unfortunately, many people who send patches to me do not follow
> these simple rules.

I am still waiting for an answer as to whether such a patch would be
accepted. We will take on the practical details later on.

Jerome

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

[Joerg Schilling]

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

> On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > "D. Hazelton" <dhazelton@enter.net> wrote:
> >
> > > > Are you accepting such a patch?
> > >
> > > If his response to the last patch someone provided is any example the answer
> > > is going to be no. And I firmly believe the old adage that a leopard can't
> > > change it's spots.
> >
> > Any patch that
> >
> > -       does not break things
> >
> > -       fits into the spirit of the currnt implementation
> >
> > -       offers useful new features
> >
> > -       conforms to coding style standards
> >
> > -       does not need more time to integrate than I would need to
> >         write this from scratch
> >
> > Unfortunately, many people who send patches to me do not follow
> > these simple rules.
>
> I am still waiting for an answer as to whether such a patch would be
> accepted. We will take on the practical details later on.

If this answer is not sufficient to you, you seem to be wrong here.

Jörg

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

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

[jerome lacoste]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
>
> > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > > "D. Hazelton" <dhazelton@enter.net> wrote:
> > >
> > > > > Are you accepting such a patch?
> > > >
> > > > If his response to the last patch someone provided is any example the answer
> > > > is going to be no. And I firmly believe the old adage that a leopard can't
> > > > change it's spots.
> > >
> > > Any patch that
> > >
> > > -       does not break things
> > >
> > > -       fits into the spirit of the currnt implementation
> > >
> > > -       offers useful new features
> > >
> > > -       conforms to coding style standards
> > >
> > > -       does not need more time to integrate than I would need to
> > >         write this from scratch
> > >
> > > Unfortunately, many people who send patches to me do not follow
> > > these simple rules.
> >
> > I am still waiting for an answer as to whether such a patch would be
> > accepted. We will take on the practical details later on.
>
> If this answer is not sufficient to you, you seem to be wrong here.

We probably misunderstood each other here. I want a technical approval
regarding the proposal I made (which is "publicise the os specific to
b,t,l mapping found by cdrecord").

Then I write the patch and I will make sure it will pass all your
defined criteria.

Jerome

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

[Joerg Schilling]

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

> > If this answer is not sufficient to you, you seem to be wrong here.
>
> We probably misunderstood each other here. I want a technical approval
> regarding the proposal I made (which is "publicise the os specific to
> b,t,l mapping found by cdrecord").
>
> Then I write the patch and I will make sure it will pass all your
> defined criteria.

I did give you the criteria. I don't know what you like to do. I
cannot tell you something on code I don't know.



Jörg

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

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

[D. Hazelton]

On Monday 13 February 2006 08:44, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > Are you accepting such a patch?
> >
> > If his response to the last patch someone provided is any example the
> > answer is going to be no. And I firmly believe the old adage that a
> > leopard can't change it's spots.
>
> Any patch that
>
> -	does not break things
>
> -	fits into the spirit of the currnt implementation
>
> -	offers useful new features
>
> -	conforms to coding style standards
>
> -	does not need more time to integrate than I would need to
> 	write this from scratch
>
> Unfortunately, many people who send patches to me do not follow
> these simple rules.

Okay - show me your standards document and I'll get to work on a patch to do 
what I earlier proposed. It won't be "adding new functionality" but it will 
be making the interface a tiny bit simpler for the novice user.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > -	does not need more time to integrate than I would need to
> > 	write this from scratch
> >
> > Unfortunately, many people who send patches to me do not follow
> > these simple rules.
>
> Okay - show me your standards document and I'll get to work on a patch to do 
> what I earlier proposed. It won't be "adding new functionality" but it will 
> be making the interface a tiny bit simpler for the novice user.

?????

1)	RTFM
2)	ftp://ftp.berlios.de/pub/cdrecord/PORTING
3)	http://cdrecord.berlios.de/old/private/port.ps
4)	http://cvs.opensolaris.org/source/xref/on/usr/src/tools/scripts/cstyle.pl


If you do not follow the spirit of the interface design or of you break
things on other OS, your patch will not be accepted.

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-14:

> If you do not follow the spirit of the interface design

This is not a technical restriction, but a soaking sponge you can
throw in anyone's face.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-14:
>
> > If you do not follow the spirit of the interface design
>
> This is not a technical restriction, but a soaking sponge you can
> throw in anyone's face.

Well, it is a _lot_ more open than what Linux requieres. 
On Linux you need to meet the current feeling of a potentially unknown
lord of the manor.

Jörg

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

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

[D. Hazelton]

On Tuesday 14 February 2006 11:55, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> > Joerg Schilling schrieb am 2006-02-14:
> > > If you do not follow the spirit of the interface design
> >
> > This is not a technical restriction, but a soaking sponge you can
> > throw in anyone's face.
>
> Well, it is a _lot_ more open than what Linux requieres.
> On Linux you need to meet the current feeling of a potentially unknown
> lord of the manor.
>
> Jörg

Bullshit, Joerg. The only difference in this case is that we know exactly who 
"the lord of the manor" is.

DRH

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

[Jim Crilly]

On 02/14/06 02:37:14PM +0100, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> 
> > > -	does not need more time to integrate than I would need to
> > > 	write this from scratch
> > >
> > > Unfortunately, many people who send patches to me do not follow
> > > these simple rules.
> >
> > Okay - show me your standards document and I'll get to work on a patch to do 
> > what I earlier proposed. It won't be "adding new functionality" but it will 
> > be making the interface a tiny bit simpler for the novice user.
> 
> ?????
> 
> 1)	RTFM
> 2)	ftp://ftp.berlios.de/pub/cdrecord/PORTING
> 3)	http://cdrecord.berlios.de/old/private/port.ps
> 4)	http://cvs.opensolaris.org/source/xref/on/usr/src/tools/scripts/cstyle.pl
> 
> 
> If you do not follow the spirit of the interface design or of you break
> things on other OS, your patch will not be accepted.
> 
> Jörg

You're allowed to yell RTFM to him, but when you were pointed to the HAL
documentation you cried that you didn't want to spend time reading it? How
does that work?

Jim.

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

[Olivier Galibert]

On Tue, Feb 14, 2006 at 01:43:25PM -0500, Jim Crilly wrote:
> You're allowed to yell RTFM to him, but when you were pointed to the HAL
> documentation you cried that you didn't want to spend time reading it? How
> does that work?

Dbus hasn't reached 1.0 yet (bindings are finishing being cleaned up
if I followed the list correctly), and Hal is very much still in beta.
It's way too early to base any long-term code on it if you don't have
the level of political pressure for stability kde or gnome has.

  OG.

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

[D. Hazelton]

On Tuesday 14 February 2006 08:37, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > -	does not need more time to integrate than I would need to
> > > 	write this from scratch
> > >
> > > Unfortunately, many people who send patches to me do not follow
> > > these simple rules.
> >
> > Okay - show me your standards document and I'll get to work on a patch to
> > do what I earlier proposed. It won't be "adding new functionality" but it
> > will be making the interface a tiny bit simpler for the novice user.
>
> ?????
>
> 1)	RTFM
> 2)	ftp://ftp.berlios.de/pub/cdrecord/PORTING
> 3)	http://cdrecord.berlios.de/old/private/port.ps
> 4)	http://cvs.opensolaris.org/source/xref/on/usr/src/tools/scripts/cstyle.p
>l
>
>
> If you do not follow the spirit of the interface design or of you break
> things on other OS, your patch will not be accepted.
>
> Jörg

I shall and thank you. Given current constraints on my time I should have the 
patch I mentioned available in no more than two weeks.

If my patch breaks something on another OS, then please inform me so that I 
can modify the code and send you a fixed patch. After all, as I've said 
before, I don't have the access to the resources you do for testing.

DRH

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

[kernel]

On Mon, 2006-02-13 at 08:44, Joerg Schilling wrote:
> Any patch that
> 
> -	does not break things
> 
Good. Makes sense.  Acceptable.


> -	fits into the spirit of the currnt implementation
> 
Bad.  Subject to the gate keeper's ideas, whims, and personal agenda.


> -	offers useful new features
> 
Good.  Makes sense.  Acceptable.


> -	conforms to coding style standards
> 
Good.  Makes sense.  Acceptable.


> -	does not need more time to integrate than I would need to
> 	write this from scratch
Good.  Makes sense.  Acceptable.


To sum, all technical and acceptable points *except* for one.  And of
course, this one is the one that has kept this thread (in various forms)
going for what seems like *years*.

Do you know what's really scary?  The normal users, the managers, the
technical users, etc. who've read LKML and have read this thread (either
in its entirety or partial) (such as myself and my colleagues) who
suddenly pucker when they feel that the fate of writing to CD media in
Linux is in the hands of *one* person.  And this one person projects the
identity of the angry child in the schoolyard who would grab his toys
and walk away to play by himself if everyone else playing the same game
didn't do what he said, when he said, how he said.  People looking into
Linux, perhaps considering investing in it, read this thread and think
"Wow, they can't even get together on CD burning!" (Simplified, I know.)

This is one impression given in this most recent thread pertaining to
this topic.  I cannot believe that somewhere on this planet other
developers don't band together to write something equally as good or
better to end this current nonsense *and* to prevent future hassles with
this current implementation of this program and the developer.  (No, I
don't code, but in instances like this I wish I did.)  I see this thread
and I just keep thinking "Couldn't have it all been solved by now?  How
many lines in this thread versus how many lines of code would it take?"

Please, talented developers, look into writing a similar program that
does fit with the current and planned Linux way and remove reliance on
this unbending individual.  It's a big world.  I've seen other projects
start small and gain momentum and grow.  Y'all are no stranger to this
same phenomenon.  Certainly there are other coders and testers willing
to assist in this project.

And BTW, wouldn't the ultimate salute to Jorg be to never have to endure
another LKML thread like this one because Linux users are using another
bit of code?

regards,
-fd

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

[Joerg Schilling]

kernel <kernel@crazytrain.com> wrote:

> On Mon, 2006-02-13 at 08:44, Joerg Schilling wrote:
> > Any patch that
> > 
> > -	does not break things
> > 
> Good. Makes sense.  Acceptable.
>
>
> > -	fits into the spirit of the currnt implementation
> > 
> Bad.  Subject to the gate keeper's ideas, whims, and personal agenda.

So you like to tell us that you don"t like this?

Well, then start a campaign against Linux......


Jörg

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

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

[Gene Heskett]

On Friday 10 February 2006 10:38, jerome lacoste wrote:
>On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
>> "D. Hazelton" <dhazelton@enter.net> wrote:
>> > And does cdrecord even need libscg anymore? From having actually
>> > gone through your code, Joerg, I can tell you that it does serve a
>> > larger purpose. But at this point I have to ask - besides cdrecord
>> > and a few other _COMPACT_ _DISC_ writing programs, does _ANYONE_
>> > use libscg? Is it ever used to access any other devices that are
>> > either SCSI or use a SCSI command protocol (like ATAPI)?  My point
>> > there is that you have a wonderful library, but despite your
>> > wishes, there is no proof that it is ever used for anything except
>> > writing/ripping CD's.
>>
>> Name a single program (not using libscg) that implements user space
>> SCSI and runs on as many platforms as cdrecord/libscg does.
>
>I have 2 technical questions, and I hope that you will take the time
>to answer them.
>
>1) extract from the README of the latest stable cdrtools package:
>
>        Linux driver design oddities
> ****************************************** Although cdrecord supports
> to use dev=/dev/sgc, it is not recommended and it is unsupported.
>
>        The /dev/sg* device mapping in Linux is not stable! Using
> dev=/dev/sgc in a shell script may fail after a reboot because the
> device you want to talk to has moved to /dev/sgd. For the proper and
> OS independent dev=<bus>,<tgt>,<lun> syntax read the man page of
> cdrecord.
>
>My understanding of that is you say to not use dev=/dev/sgc because it
>isn't stable. Now that you've said that bus,tgt,lun is not stable on
>Linux (because of a "Linux bug") why is the b,t,l scheme preferred
>over the /dev/sg* one ?
>
>
>2) design question:
>
>- cdrecord scans then maps the device to the b,t,l scheme.
>- the libsg uses the b,t,l ids in its interface to perform the
> operations
>
>So now, if cdrecord could have a new option called -scanbusmap that
>displays the mapping it performs in a way that people can parse the
>output, I think that will solve most issues.
>
>cdrecord already has this information available, it just doesn't
> display it:
>
>$ cdrecord debug=2 dev=ATAPI -scanbus 2>&1 | grep INFO
>INFO: /dev/hdc, (host0/bus1/target0/lun0) will be mapped on the
>schilly bus No 0 (0,0,0)
>INFO: /dev/hdd, (host0/bus1/target1/lun0) will be mapped on the
>schilly bus No 0 (0,1,0)

And here I'd call the -scanbus output broken, extremely so, and in a 
manner that makes all of your arguments rather specious.  I've tried to 
stay the hell out of this thread because its clearly a pissing match 
between some with excessive ego's, but this example requires an answer.

[root@coyote]# cdrecord debug=2 dev=ATAPI -scanbus 2>&1 | grep INFO
INFO: /dev/hdd, (host0/bus1/target1/lun0) will be mapped on the schilly 
bus No 0 (0,1,0)
INFO: /dev/hdc, (host0/bus1/target0/lun0) will be mapped on the schilly 
bus No 0 (0,0,0)
INFO: /dev/hda, (host0/bus0/target0/lun0) will be mapped on the schilly 
bus No 1 (1,0,0)

The above make very little sense, and argues against Jorg's assertions 
that his way is the 'correct' way.

Since when in the hello is /dev/hda NOT the first device in this 
so-called mapping scheme? 

This is clearly broken, but I have no trouble at all burning whatever I 
want to burn when using /deb/hdc at the target in k3b.

True, cdrecord does place that target at 0,0,0 but that has to be 
because of some mechanation in the cdrecord code to defeat what really 
should be common sense that says /dev/hdc SHOULD be 1,0,0 as its the 
first device found on the 2nd buss(or cable as some would call it).

Now, take this next as a users statement, not from the point of a coder 
although I have written some in past decades when the machinery was a 
little simpler.  Now I'm just an old codger user at 71.

So how Jorg, can you justify your reticence to make use of a system that  
linux has, and which clearly works now since very close to the 2.6 
kernel series transition?  Your constant harping on how solaris does it 
is as distastefull as some winderz dweeb coming in here to try and 
evangelize windows use.  This IS linux, and our numbers probably exceed 
solaris users by a factor of at least 10.  We're here, and unless a 
buss hits Linus and no similar minded person is named as his successor, 
get over it.  You are drasticly outnumbered.

We just want it to work and we don't care about your mostly FUD, often 
silly, usually specious/empty arguments because no facts are ever 
stated more than once over a given 5 year period.  We are all in your 
view expected to have photographic memory.  Not guilty here, we do have 
other concerns in life.

>It could perform in the following way:
>
>$ cdrecord dev=ATAPI  -scanbusmap
>...
>
>0,0,0 <= /dev/hdc
>0,1,0 <= /dev/hdd
>
>
>Are you accepting such a patch?
>
>Jerome

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

[ot] Linux heritage (was Re: CD writing in future Linux)

[Jan Engelhardt]

>We're here, and unless a 
>buss hits Linus and no similar minded person is named as his successor, 
>[...]

This issue should actually be resolved before that happens. Just in case, 
so that currently active members don't fight for 1st place :)


Jan Engelhardt
-- 

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

[Joerg Schilling]

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

> On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > "D. Hazelton" <dhazelton@enter.net> wrote:
> >
> > > And does cdrecord even need libscg anymore? From having actually gone through
> > > your code, Joerg, I can tell you that it does serve a larger purpose. But at
> > > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_
> > > writing programs, does _ANYONE_ use libscg? Is it ever used to access any
> > > other devices that are either SCSI or use a SCSI command protocol (like
> > > ATAPI)?  My point there is that you have a wonderful library, but despite
> > > your wishes, there is no proof that it is ever used for anything except
> > > writing/ripping CD's.
> >
> > Name a single program (not using libscg) that implements user space SCSI and runs
> > on as many platforms as cdrecord/libscg does.
>
>
> I have 2 technical questions, and I hope that you will take the time
> to answer them.
>
> 1) extract from the README of the latest stable cdrtools package:
>
>         Linux driver design oddities ******************************************
>         Although cdrecord supports to use dev=/dev/sgc, it is not recommended
>         and it is unsupported.
>
>         The /dev/sg* device mapping in Linux is not stable! Using dev=/dev/sgc
>         in a shell script may fail after a reboot because the device you want
>         to talk to has moved to /dev/sgd. For the proper and OS independent
>         dev=<bus>,<tgt>,<lun> syntax read the man page of cdrecord.
>
> My understanding of that is you say to not use dev=/dev/sgc because it
> isn't stable. Now that you've said that bus,tgt,lun is not stable on
> Linux (because of a "Linux bug") why is the b,t,l scheme preferred
> over the /dev/sg* one ?

b,t,l _is_ stable as long as the OS does a reasonable and orthogonal work.

This was true until ~ 2001, when Linux introduced unstable USB handling.
Note that this fact is not a failure from libscg but from Linux.


> 2) design question:
>
> - cdrecord scans then maps the device to the b,t,l scheme.
> - the libsg uses the b,t,l ids in its interface to perform the operations
>
> So now, if cdrecord could have a new option called -scanbusmap that
> displays the mapping it performs in a way that people can parse the
> output, I think that will solve most issues.

The output of cdrecord -scanbus is already parsable, so what 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 (stirring up a hornets' nest)

[Martin Mares]

Hello!

> This was true until ~ 2001, when Linux introduced unstable USB handling.

Even before that point it wasn't true, adding a new controller card
could always result in renumbering the previously existing controllers.

The key failure in your reasoning is that there is no definition of "the
same device", which would be both consistent and useful.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Not all rumors are as misleading as this one.

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> Hello!
>
> > This was true until ~ 2001, when Linux introduced unstable USB handling.
>
> Even before that point it wasn't true, adding a new controller card
> could always result in renumbering the previously existing controllers.

Even in this case, this was a deficit from Linux.

On Solaris, adding a new controler always asigns this new controler a new
higher ID (except for the case when the sysadmin explicitly requests different 
behavior). On Linux a sysadmin needs to know how the evaluation works....

And BTW: if a sysadmin does not know how things work on Linux and thus
causes a remapping, all /etc/vfstab entries would be void. So you are talking 
about a major fault that should be avoided under all circumstances.


Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:

> And BTW: if a sysadmin does not know how things work on Linux and thus
> causes a remapping, all /etc/vfstab entries would be void. So you are talking 
> about a major fault that should be avoided under all circumstances.

Talk about people who "do[...] not know how things work on Linux" and
name /etc/vfstab in the same breath.

Brilliant!

Oh, and in case you didn't know, Linux isn't using b,t,l in its mount
table. No, I'm not naming the file, find out for yourself, you need it.

-- 
Matthias Andree

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

[Jan Engelhardt]

>
>On Solaris, adding a new controler always asigns this new controler a new
>higher ID (except for the case when the sysadmin explicitly requests different 
>behavior).

What if the OS runs out of next-higher IDs?

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

[Joerg Schilling]

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

> >
> >On Solaris, adding a new controler always asigns this new controler a new
> >higher ID (except for the case when the sysadmin explicitly requests different 
> >behavior).
>
> What if the OS runs out of next-higher IDs?

????

Do you believe that an int32_t is not sufficient?

Jörg

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

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

[Jan Engelhardt]

>> >
>> >On Solaris, adding a new controler always asigns this new controler a new
>> >higher ID (except for the case when the sysadmin explicitly requests different 
>> >behavior).
>>
>> What if the OS runs out of next-higher IDs?
>
>????
>
>Do you believe that an int32_t is not sufficient?
>

I can replug some media in and out repeatedly, maybe even use software to 
do so. (stuff like sdparm -C eject on USB flash media do their thing)
The problem exists. You play it down like one does not need to check 
malloc() for NULL just because "there's probably enough memory" when the 
superuser started this process... I mean, it sounds like that.


Jan Engelhardt
-- 

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

[Jan Engelhardt]

>
>The key failure in your reasoning is that there is no definition of "the
>same device", which would be both consistent and useful.
>

Serial number of the device, but that's quite quirky too.



Jan Engelhardt
-- 

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

[Marcin Dalecki]

On 2006-02-13, at 11:52, Martin Mares wrote:
>
> The key failure in your reasoning is that there is no definition of  
> "the
> same device", which would be both consistent and useful.

This claim is a bit surprising since only, but the most irrelevant  
stuff from the
dust bin of history, doesn't define a world global unique id those days.

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

[Martin Mares]

Hello!

> This claim is a bit surprising since only, but the most irrelevant
> stuff from the dust bin of history, doesn't define a world global
> unique id those days.

That's unfortunately not true -- many USB devices don't have a usable
serial number.

Also, if I have a single device of its kind, let's say a USB mouse,
I really want to call it "The Mouse" and I don't want to reconfigure
anything if I plug it to a different port or replace it with a slightly
different mouse. All mice are considered equivalent by the user
as there is no reason to distinguish between them.

The same applies to CD burners -- as long as I have only one (which is
still the most common situation), I shouldn't have to think about how
to call it. Let it be just /dev/cdrw.

When I get multiple such devices, things start getting interesting, but
there is no single naming strategy which fits all uses. For example,
if I have two USB ports into which I connect USB disks various people
bring to me, it's convenient to call them "left" and "right", because
the serial number doesn't mean anything to me if I haven't seen the
device before. On the other hand, if I connect my own drives, it makes
sense to call them by their serial numbers or something like that.

I think that it's clear from all this, that device naming is a matter
of policy and that the best the OS can do is to give the users a way
how to specify their policy, which is what udev does.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
P.C.M.C.I.A. stands for `People Can't Memorize Computer Industry Acronyms'

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

[D. Hazelton]

On Tuesday 14 February 2006 04:20, Martin Mares wrote:
<snip>
> I think that it's clear from all this, that device naming is a matter
> of policy and that the best the OS can do is to give the users a way
> how to specify their policy, which is what udev does.
>
> 				Have a nice fortnight

True, and the point I was trying to make. Joerg has a policy that works well 
on some systems and doesn't on others. Rather than giving people a clear 
option to use the other system he has. In Linux udev provides a user 
configurable policy that works extremely well. Rather than change the 
software to accomodate udev/hald as he accomodates vold on Solaris Joerg 
insists on having *nearly* pointless warnings and insisting that his method 
is the only valid one.

That's the reason I asked him if he'd accept a patch that removed said warning 
and converted the device the user passed in (be it /dev/sr0 or /dev/cdrw) and 
internally converts it into his naming scheme. I have yet to see a response 
to this.

DRH

PS: Joerg my offer for that still stands, as does my offer to _attempt_ to fix 
the bugs you've reported in the ATAPI layer. Sadly I cannot offer to repair 
ide-scsi, as that is deprecated and scheduled for removal. However, with that 
being the case my offer to attempt to repair the noted problems with the 
mangling of commands by the ATAPI system remains. All I ask for is a detailed 
report including which model drives have the problem and debugging output so 
that I can attempt to repair the problem since I do not have the access to 
hardware that you do.

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> True, and the point I was trying to make. Joerg has a policy that works well 
> on some systems and doesn't on others. Rather than giving people a clear 
> option to use the other system he has. In Linux udev provides a user 
> configurable policy that works extremely well. Rather than change the 

If you believe this, then send a whitepaper on udev together with
devent documentation and a grant on how long Linux will support the related 
interfaces without breaking them.

Jörg

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

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

[Lennart Sorensen]

On Tue, Feb 14, 2006 at 10:20:30AM +0100, Martin Mares wrote:
> That's unfortunately not true -- many USB devices don't have a usable
> serial number.
> 
> Also, if I have a single device of its kind, let's say a USB mouse,
> I really want to call it "The Mouse" and I don't want to reconfigure
> anything if I plug it to a different port or replace it with a slightly
> different mouse. All mice are considered equivalent by the user
> as there is no reason to distinguish between them.

Unless you are trying to setup two mice, two keyboards and two screens
on one machine at the same time.  Some people do that.  Then which mouse
is which is relevant.

> The same applies to CD burners -- as long as I have only one (which is
> still the most common situation), I shouldn't have to think about how
> to call it. Let it be just /dev/cdrw.

Many people have a cd writer and then add a dvd writer.  Not that
unusual really.

> When I get multiple such devices, things start getting interesting, but
> there is no single naming strategy which fits all uses. For example,
> if I have two USB ports into which I connect USB disks various people
> bring to me, it's convenient to call them "left" and "right", because
> the serial number doesn't mean anything to me if I haven't seen the
> device before. On the other hand, if I connect my own drives, it makes
> sense to call them by their serial numbers or something like that.
> 
> I think that it's clear from all this, that device naming is a matter
> of policy and that the best the OS can do is to give the users a way
> how to specify their policy, which is what udev does.

Well udev is starting to look useful.  It no longer causes lots of
breakage when I install it on my system. :)

Len Sorensen

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

[jerome lacoste]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
[...]
> > My understanding of that is you say to not use dev=/dev/sgc because it
> > isn't stable. Now that you've said that bus,tgt,lun is not stable on
> > Linux (because of a "Linux bug") why is the b,t,l scheme preferred
> > over the /dev/sg* one ?
>
> b,t,l _is_ stable as long as the OS does a reasonable and orthogonal work.
>
> This was true until ~ 2001, when Linux introduced unstable USB handling.
> Note that this fact is not a failure from libscg but from Linux.

This is true if you assume that "stable b,t,l" was an advertised Linux
functionality.
I may be wrong, but I don't think that this was ever the case. It
might just have been a side-effect of the implementation. Anyway,
point #2 is much more important, so let's focus on that:


> > 2) design question:
> >
> > - cdrecord scans then maps the device to the b,t,l scheme.
> > - the libsg uses the b,t,l ids in its interface to perform the operations
> >
> > So now, if cdrecord could have a new option called -scanbusmap that
> > displays the mapping it performs in a way that people can parse the
> > output, I think that will solve most issues.
>
> The output of cdrecord -scanbus is already parsable,

But it doesn't show the OS specific mapping.

> so what is your point?

I am aiming for a compromise.

My point is that people want to use dev=/dev/hdc in their interface,
because that's what they are used to. That's a point that I think you
cannot deny.

If you want to still keep your dev=b,t,l command line interface, just
let the users know how your mapping is done. That will allow a
cdrecord wrapper to first query the mapping, then using this mapping
information and OS specific information (e.g. links) identify the
b,t,l expected by your interface.

That way you have mostly no code change to do. And you keep your b,t,l
naming. Everybody is happy.

I've added something like:

                fprintf(stdout, "%d,%d,%d <= /dev/%s\n",
				first_free_schilly_bus, t, l, token[ID_TOKEN_SUBSYSTEM] );

in scsi-linux-ata.c and it does what I want.

WDYT?

Cheers,

Jerome

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

[Joerg Schilling]

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

> > The output of cdrecord -scanbus is already parsable,
>
> But it doesn't show the OS specific mapping.
>
> > so what is your point?
>
> I am aiming for a compromise.
>
> My point is that people want to use dev=/dev/hdc in their interface,
> because that's what they are used to. That's a point that I think you
> cannot deny.
>
> If you want to still keep your dev=b,t,l command line interface, just
> let the users know how your mapping is done. That will allow a
> cdrecord wrapper to first query the mapping, then using this mapping
> information and OS specific information (e.g. links) identify the
> b,t,l expected by your interface.
>
> That way you have mostly no code change to do. And you keep your b,t,l
> naming. Everybody is happy.
>
> I've added something like:
>
>                 fprintf(stdout, "%d,%d,%d <= /dev/%s\n",
> 				first_free_schilly_bus, t, l, token[ID_TOKEN_SUBSYSTEM] );
>
> in scsi-linux-ata.c and it does what I want.

The scanbus code was taken from "sformat".

Sformat already includes such a mapping if you are on Solaris.
Unfortunately this does cleanly work on Linux and for this
reason is did not make it into cdrecord.

Jörg

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

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

[jerome lacoste]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
>
> > > The output of cdrecord -scanbus is already parsable,
> >
> > But it doesn't show the OS specific mapping.
> >
> > > so what is your point?
> >
> > I am aiming for a compromise.
> >
> > My point is that people want to use dev=/dev/hdc in their interface,
> > because that's what they are used to. That's a point that I think you
> > cannot deny.
> >
> > If you want to still keep your dev=b,t,l command line interface, just
> > let the users know how your mapping is done. That will allow a
> > cdrecord wrapper to first query the mapping, then using this mapping
> > information and OS specific information (e.g. links) identify the
> > b,t,l expected by your interface.
> >
> > That way you have mostly no code change to do. And you keep your b,t,l
> > naming. Everybody is happy.
> >
> > I've added something like:
> >
> >                 fprintf(stdout, "%d,%d,%d <= /dev/%s\n",
> >                               first_free_schilly_bus, t, l, token[ID_TOKEN_SUBSYSTEM] );
> >
> > in scsi-linux-ata.c and it does what I want.
>
> The scanbus code was taken from "sformat".
>
> Sformat already includes such a mapping if you are on Solaris.
> Unfortunately this does cleanly work on Linux and for this
> reason is did not make it into cdrecord.

Jorg,

thanks for your answer.

I fail to understand how it is connected to my proposal. Maybe we
misunderstood each other.

I assume that you refer to the sformat/fmt.c implementation (sformat
3.5) being reproduced in cdrecord/scsi_scan.c (latest cdrtools).

Could you please elaborate on:
- what does the sformat scanbus code has to do with my proposal, whose
changes would mostly be located in the libscg modules, not in the
cdrecord module

- why 'it' doesn't clearly work on Linux. cdrecord clearly creates
this os specific to b,t,l mapping (e.g. in scsi-linux-ata.c,
scsi-wnt.c etc..). Why this mapping cannot be publicised in a
parseable format?

Jerome, still looking for a compromise.

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

[Joerg Schilling]

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

> > Sformat already includes such a mapping if you are on Solaris.
> > Unfortunately this does cleanly work on Linux and for this
> > reason is did not make it into cdrecord.
>
> Jorg,
>
> thanks for your answer.
>
> I fail to understand how it is connected to my proposal. Maybe we
> misunderstood each other.
>
> I assume that you refer to the sformat/fmt.c implementation (sformat
> 3.5) being reproduced in cdrecord/scsi_scan.c (latest cdrtools).
>
> Could you please elaborate on:
> - what does the sformat scanbus code has to do with my proposal, whose
> changes would mostly be located in the libscg modules, not in the
> cdrecord module

What has your proposal to do with libscg and how would you like to implement
it OS independent?

> - why 'it' doesn't clearly work on Linux. cdrecord clearly creates
> this os specific to b,t,l mapping (e.g. in scsi-linux-ata.c,
> scsi-wnt.c etc..). Why this mapping cannot be publicised in a
> parseable format?

Name a method that would work for anhy type of devices and any of the
supported 21 OS.



Jörg

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

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

[jerome lacoste]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
>
> > > Sformat already includes such a mapping if you are on Solaris.
> > > Unfortunately this does cleanly work on Linux and for this
> > > reason is did not make it into cdrecord.
> >
> > Jorg,
> >
> > thanks for your answer.
> >
> > I fail to understand how it is connected to my proposal. Maybe we
> > misunderstood each other.
> >
> > I assume that you refer to the sformat/fmt.c implementation (sformat
> > 3.5) being reproduced in cdrecord/scsi_scan.c (latest cdrtools).
> >
> > Could you please elaborate on:
> > - what does the sformat scanbus code has to do with my proposal, whose
> > changes would mostly be located in the libscg modules, not in the
> > cdrecord module
>
> What has your proposal to do with libscg

The mapping I am talking about is currently done inside libscg (inside
the scsi-*.c files). Hence libscg is the one capable of exposing this
information to higher levels.

> and how would you like to implement it OS independent?

The information printed will be printed in a format such as:

b,t,l <= os_specific_name

This information is obviously not completely OS dependent (the
os_specifc_name is OS specific). But it is exactly this information
that would make your program integrable with OS specific user
interfaces. And this information would only be outputted.

Think about it in term of high level interface:

struct mapping {
  btl btl;
  char* name;
}

mapping* get_drives();
void burn(btl, ....)

To use your b,t,l naming effectively, we need to have a way to
identify it correctly. and no scanbus is not sufficient because what
is needed is the btl to os specific name.


> > - why 'it' doesn't clearly work on Linux. cdrecord clearly creates
> > this os specific to b,t,l mapping (e.g. in scsi-linux-ata.c,
> > scsi-wnt.c etc..). Why this mapping cannot be publicised in a
> > parseable format?
>
> Name a method that would work for anhy type of devices and any of the
> supported 21 OS.

I don't want to change anything cdrecord does. wrapper programs will
still use your dev=b,t,l on all platforms. The publicised mapping
would allow program to identify the correct b,t,l value.

How does that sound?

Jerome

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

[Joerg Schilling]

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

> The mapping I am talking about is currently done inside libscg (inside
> the scsi-*.c files). Hence libscg is the one capable of exposing this
> information to higher levels.
>
> > and how would you like to implement it OS independent?
>
> The information printed will be printed in a format such as:
>
> b,t,l <= os_specific_name

Why do you believe that this kind of mapping is needed?

Jörg

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

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

[Jan Engelhardt]

>> The information printed will be printed in a format such as:
>>
>> b,t,l <= os_specific_name
>
>Why do you believe that this kind of mapping is needed?
>

Assume the user has a /dev/white_dvd and a /dev/black_dvd, both of being 
the same brand. `cdrecord -scanbus` would return sth like

scsibus0:
        0,0,0     0) *
        0,1,0     1) 'HL-DT-ST' 'DVDRAM GSA-4160B' 'A301' Removable CD-ROM
        0,2,0     2) *
        0,3,0     3) *
        0,4,0     4) *
        0,5,0     5) *
        0,6,0     6) *
        0,7,0     7) *
scsibus1:
        1,0,0     0) *
        1,1,0     1) 'HL-DT-ST' 'DVDRAM GSA-4160B' 'A301' Removable CD-ROM
        1,2,0     2) *
        1,3,0     3) *
        1,4,0     4) *
        1,5,0     5) *
        1,6,0     6) *
        1,7,0     7) *

probably. But how to find out from the btl which one is the black and which 
one is the white one?


Jan Engelhardt
-- 

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

[Joerg Schilling]

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

> >> The information printed will be printed in a format such as:
> >>
> >> b,t,l <= os_specific_name
> >
> >Why do you believe that this kind of mapping is needed?
> >
>
> Assume the user has a /dev/white_dvd and a /dev/black_dvd, both of being 
> the same brand. `cdrecord -scanbus` would return sth like
>
> scsibus0:
>         0,0,0     0) *
>         0,1,0     1) 'HL-DT-ST' 'DVDRAM GSA-4160B' 'A301' Removable CD-ROM
>         0,2,0     2) *
>         0,3,0     3) *
>         0,4,0     4) *
>         0,5,0     5) *
>         0,6,0     6) *
>         0,7,0     7) *
> scsibus1:
>         1,0,0     0) *
>         1,1,0     1) 'HL-DT-ST' 'DVDRAM GSA-4160B' 'A301' Removable CD-ROM
>         1,2,0     2) *
>         1,3,0     3) *
>         1,4,0     4) *
>         1,5,0     5) *
>         1,6,0     6) *
>         1,7,0     7) *
>
> probably. But how to find out from the btl which one is the black and which 
> one is the white one?

A user has a bigger chance to do that from b,t,l than a program has when
trying possible aliases....

And if you have a working vold on Solaris, libscg accepts the vold aliases.

Jörg

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

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

[Valdis.Kletnieks]

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

On Mon, 13 Feb 2006 17:37:18 +0100, Joerg Schilling said:

> And if you have a working vold on Solaris, libscg accepts the vold aliases.

And if you have a working hald on Linux, libscg should therefor accept hald aliases.

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

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

[Joerg Schilling]

Valdis.Kletnieks@vt.edu wrote:

> On Mon, 13 Feb 2006 17:37:18 +0100, Joerg Schilling said:
>
> > And if you have a working vold on Solaris, libscg accepts the vold aliases.
>
> And if you have a working hald on Linux, libscg should therefor accept hald aliases.

How about pointing to _useful_ documentation:

-	How to find _any_ device that talks SCSI?

-	How does HAL allow one cdrecord instance to work
	without being interrupted by HAL?

-	How to send non disturbing SCSI commands from another
	cdrecord process in case one or more are already running?

Jörg

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

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

[D. Hazelton]

On Tuesday 14 February 2006 06:48, Joerg Schilling wrote:
> Valdis.Kletnieks@vt.edu wrote:
> > On Mon, 13 Feb 2006 17:37:18 +0100, Joerg Schilling said:
> > > And if you have a working vold on Solaris, libscg accepts the vold
> > > aliases.
> >
> > And if you have a working hald on Linux, libscg should therefor accept
> > hald aliases.
>
> How about pointing to _useful_ documentation:
>
> -	How to find _any_ device that talks SCSI?
>
> -	How does HAL allow one cdrecord instance to work
> 	without being interrupted by HAL?
>
> -	How to send non disturbing SCSI commands from another
> 	cdrecord process in case one or more are already running?
>
> Jörg

Documentation?

Didn't even take me two minutes to find the entire specification for hald on 
the net.

http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only_with_tag=HEAD

theres a link. if I wasn't half asleep I'd actually dig through it and find 
the information you're asking about.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > How about pointing to _useful_ documentation:
> >
> > -	How to find _any_ device that talks SCSI?
> >
> > -	How does HAL allow one cdrecord instance to work
> > 	without being interrupted by HAL?
> >
> > -	How to send non disturbing SCSI commands from another
> > 	cdrecord process in case one or more are already running?
> >
> > Jörg
>
> Documentation?
>
> Didn't even take me two minutes to find the entire specification for hald on 
> the net.
>
> http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only_with_tag=HEAD
>

????
Did yoiu try to read this?

I like to see a whitepaper first that allows me to get an overview in less than 
10 minutes. If this is not available, I suspect you just try another attempt to 
waste my time.

Jörg

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

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

[grundig]

El Tue, 14 Feb 2006 17:42:27 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:


> I like to see a whitepaper first that allows me to get an overview in less than 
> 10 minutes. If this is not available, I suspect you just try another attempt to 
> waste my time.

A "overview"? And "I'll only waste 10 minutes of my life to look at this"? Strange
way to handle design decisions for a software developer - there're people who
will not just read that paper, but read aswell the code to take such decisions.

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

[Joerg Schilling]

<grundig@teleline.es> wrote:

> El Tue, 14 Feb 2006 17:42:27 +0100,
> Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:
>
>
> > I like to see a whitepaper first that allows me to get an overview in less than 
> > 10 minutes. If this is not available, I suspect you just try another attempt to 
> > waste my time.
>
> A "overview"? And "I'll only waste 10 minutes of my life to look at this"? Strange
> way to handle design decisions for a software developer - there're people who
> will not just read that paper, but read aswell the code to take such decisions.

If _you_ did not watste so much from my time, there was a chance.....

Jörg

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

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

[D. Hazelton]

On Tuesday 14 February 2006 11:42, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > How about pointing to _useful_ documentation:
> > >
> > > -	How to find _any_ device that talks SCSI?
> > >
> > > -	How does HAL allow one cdrecord instance to work
> > > 	without being interrupted by HAL?
> > >
> > > -	How to send non disturbing SCSI commands from another
> > > 	cdrecord process in case one or more are already running?
> > >
> > > Jörg
> >
> > Documentation?
> >
> > Didn't even take me two minutes to find the entire specification for hald
> > on the net.
> >
> > http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only
> >_with_tag=HEAD
>
> ????
> Did yoiu try to read this?

Did you notice my comment? When I sent that message I'd been awake for nearly 
24 hours helping a friend through depression and was ready to fall asleep 
while checking my email. I have since read it and I understand your problem. 
That documentation does state, however, that the HAL system is normally 
accessed via the dbus system message bus. In order to help you with that 
facet of things here is a link to the dbus documentation: 
http://dbus.freedesktop.org/doc/dbus-specification.html

And I will look into the HAL source code and provided headers to see if I 
cannot find you a direct interface such as dbus has with HAL. But not at the 
current moment, as I am limited in my available time.

> I like to see a whitepaper first that allows me to get an overview in less
> than 10 minutes. If this is not available, I suspect you just try another
> attempt to waste my time.

Huh? I understood HAL in less than ten minutes from that specification. But 
then, any competant programmer would spend a great deal more time on learning 
an interface. I have been studying the ATAPI, SCSI and MMC specs for more 
than six months now and, while I have a firm grasp of the concepts, could not 
sit down and write a piece of software that spoke those protocols. (This is 
mainly because I haven't been focusing on them, but rather referencing in 
passing after having read them in their entirety at least once)

DRH

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-14:

> -	How does HAL allow one cdrecord instance to work
> 	without being interrupted by HAL?

That is not the duty of an external system such as HAL and its daemons,
hald*.

There is ongoing research WRT HAL interruptions, and the final word on
HAL, O_EXCL and everything has not yet been spoken IMO.

Indulge yourself, I'm quite sure this will have been sorted out before
Equinoxe.

> -	How to send non disturbing SCSI commands from another
> 	cdrecord process in case one or more are already running?

Open the device node you obtained and
send non-disturbing commands through it.

No special treatment required.

-- 
Matthias Andree

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

[Rob Landley]

On Tuesday 14 February 2006 7:23 am, Matthias Andree wrote:
> > -	How to send non disturbing SCSI commands from another
> > 	cdrecord process in case one or more are already running?
>
> Open the device node you obtained and
> send non-disturbing commands through it.
>
> No special treatment required.

On a mostly unrelated note, I've pondered adding quick and dirty versions of 
mkisofs and cdrecord to busybox for a while.  (Low priority, back burner 
thing.)  I actually poked at the cdrecord source once or twice, but it's 
unintellgible and disgusting.*

With mkisofs I can just start from the spec, reverse engineer a few existing 
ISOs, or grab the really old code from before Joerg got ahold of it (back 
when it was still readable).  That's no problem.  But for cdrecord, I can't 
find documentation on what the kernel expects.

I'm only interested in supporting ATA cd burners under a 2.6 or newer kernel, 
using the DMA method.  (SCSI is dead, I honestly don't care.)  I was hoping I 
could just open the /dev/cdrom and call the appropriate ioctls on it, but 
reading the cdrecord source proved enough of an exercise in masochism that I 
always give up after the first hour and put it back on the todo list.

I suppose I should say "screw the source code" and just run the cdrecord 
binary under strace to see what it's doing, but I thought I'd ask: is there a 
good starting place, somewhere?  (Or is there already a simple "cdrecord 
file.iso /dev/cdrom" someplace?)  I expect I'll wind up buying a 50-pack of 
coasters anyway, and I doubt I'll damage my laptop's burner too badly...

Rob

* How bad?  Random example of ignoring how the rest of the world works is that 
it runs autoconf from within make, meaning there's no obvious way to specify 
"./configure --prefix=/mypath", so the last time I played with it (which was 
a while ago), I wound up doing this:

cd /sources &&
tar xvjf buildtools/cdrtools-2.00.3.tar.bz2 &&
cd cdrtools-2.00.3 &&
make &&
cp mkisofs/OBJ/*/mkisofs cdrecord/OBJ/*/cdrecord \ 
cdda2wav/OBJ/*/cdda2wav /usr/bin &&
cp mkisofs/mkisofs.8 /usr/man/man8 &&
cp cdrecord/cdrecord.1 cdda2wav/cdda2wav.1 /usr/man/man1 &&
cd .. &&
rm -rf cdrtools-2.00.3

if [ $? -ne 0 ]; then exit 1; fi

I could understand if it didn't use autoconf at all, but having autoconf but 
_not_ a configure step is deeply into control freak territory...

Rob
-- 
Never bet against the cheap plastic solution.

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

[Olivier Galibert]

On Tue, Feb 14, 2006 at 05:51:01PM -0500, Rob Landley wrote:
> I'm only interested in supporting ATA cd burners under a 2.6 or newer kernel, 
> using the DMA method.  (SCSI is dead, I honestly don't care.)  I was hoping I 
> could just open the /dev/cdrom and call the appropriate ioctls on it, but 
> reading the cdrecord source proved enough of an exercise in masochism that I 
> always give up after the first hour and put it back on the todo list.

There may be a chance that cdrdao provides a better starting point,
readability-wise.  It seems to be simpler in what it does, and I've
tended to have a better success rate with it than with cdrecord on
"normal" usage.  Of course, it does not (or did not) include the
advanced usage cdrecord supports (various writing modes, multisession,
who knows what else).

  OG.

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

[Rob Landley]

On Tuesday 14 February 2006 6:24 pm, Olivier Galibert wrote:
> There may be a chance that cdrdao provides a better starting point,
> readability-wise.  It seems to be simpler in what it does, and I've
> tended to have a better success rate with it than with cdrecord on
> "normal" usage.  Of course, it does not (or did not) include the
> advanced usage cdrecord supports (various writing modes, multisession,
> who knows what else).

I wanna go:

./busybox cdwrite filename.iso /dev/cdrom

And:

./busybox cdwrite -e

To blank a rewriteable.

Anything else is gravy, pretty much...

>   OG.

Rob
-- 
Never bet against the cheap plastic solution.

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

[D. Hazelton]

On Tuesday 14 February 2006 18:24, Olivier Galibert wrote:
> On Tue, Feb 14, 2006 at 05:51:01PM -0500, Rob Landley wrote:
> > I'm only interested in supporting ATA cd burners under a 2.6 or newer
> > kernel, using the DMA method.  (SCSI is dead, I honestly don't care.)  I
> > was hoping I could just open the /dev/cdrom and call the appropriate
> > ioctls on it, but reading the cdrecord source proved enough of an
> > exercise in masochism that I always give up after the first hour and put
> > it back on the todo list.
>
> There may be a chance that cdrdao provides a better starting point,
> readability-wise.  It seems to be simpler in what it does, and I've
> tended to have a better success rate with it than with cdrecord on
> "normal" usage.  Of course, it does not (or did not) include the
> advanced usage cdrecord supports (various writing modes, multisession,
> who knows what else).
>
>   OG.

However it is a C++ application, and I don't know about other people, but for 
various historic reasons I'd rather use C for a command-line application. And 
it isn't free of the masochism related to cdrecord as, the last time I 
checked, cdrdao used libscg.

Now, with that out of the way... cdrdao, in my experience, supports all the 
features, but the last time I used it the documentation for the layout files 
format was scarce and I was unable to figure out how to use it to write an 
ISO file to a disc.

DRH

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

[grundig]

El Tue, 14 Feb 2006 21:19:42 -0500,
"D. Hazelton" <dhazelton@enter.net> escribió:

> However it is a C++ application, and I don't know about other people, but for 
> various historic reasons I'd rather use C for a command-line application. And 

This doesn't have any sense at all, there's no reason why C++ is not a valid
language for command line apps (like C is perfect...hint: python/perl/etc
are famous languages to write command line scripts because of a reason). There's
lot of serious software written in C++ (dpkg, for one).

C in fact was created to write a operative system in a time when writting things
in asm was the rule. Looking back at the history and learning the lesson from
C, common sense tells me that there're lots of problems that can be solved in a
much easier way with C++ just like C vs asm in the 60-70's....

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

[Matthias Andree]

On Tue, 14 Feb 2006, Rob Landley wrote:

> With mkisofs I can just start from the spec, reverse engineer a few existing 
> ISOs, or grab the really old code from before Joerg got ahold of it (back 
> when it was still readable).  That's no problem.  But for cdrecord, I can't 
> find documentation on what the kernel expects.

That's mostly the sg <http://sg.torque.net/sg/p/sg_v3_ho.html> interface
that matters, and of that mostly the open and SG_IO parts. cdrecord is
severely bound to talking SCSI.

> I'm only interested in supporting ATA cd burners under a 2.6 or newer kernel, 
> using the DMA method.  (SCSI is dead, I honestly don't care.)

SCSI being dead for writing is actually a pity because SCSI was all in
all so much smoother. More devices on the same cable (which was a real
bus), no hassles with b0rked "IDE" interfaces that only work for hard
disks but not ATAPI devices and more. Everything SCSI has had for more
than a decade is slowly retrofitted into ATA(PI), removed if not good
enough (TCQ), and reinvented (NCQ) when in fact SCSI had it right for
aeons.

The good thing is ATAPI via ide-cd vs. SCSI does not matter any more,
and SCSI vs. parallel matters very little (but that's just as dead as
SCSI for CD writing). If you don't care to enumerate devices or obtain
b,t,l, you just take the device name, open it and do some sanity checks
to see if you're talking to a CD-ROM.

The downside is, and here an abstraction layer has a point, just this
simple won't be portable. SG_IO is Linux-specific.

Jörg's complaints about ide-cd being different, layer violations and
else are entirely artificially constructed complaints, at least he
hasn't been able to document real bugs in ide-cd in the course of this
thread, but holding on to ide-scsi which is known to have severe bugs.
He was under some miscomprehension of the Linux internals and split
ATA: and SCSI namespaces and added some more artificial complaints about
non-existent problems.

One question I do have is if SG_IO would work on /dev/sr* as well. I
don't know the answer and don't have time to dig through the relevant
code now.

> I was hoping I could just open the /dev/cdrom and call the appropriate
> ioctls on it, but reading the cdrecord source proved enough of an
> exercise in masochism that I always give up after the first hour and
> put it back on the todo list.

Perhaps reading a late MMC draft from t10.org is more useful as a
starting point, if you want the real thing, you'll have to get an
official standard. And perhaps retrofitting CD support into growisofs
(from the dvd+rw-tools) might be another idea.

> I suppose I should say "screw the source code" and just run the cdrecord 
> binary under strace to see what it's doing,

You'd have to enable strace to actually unravel SG_IO contents, else
you're only getting a useless pointer - unless you trust cdrecord -V.

> * How bad?  Random example of ignoring how the rest of the world works is that 
> it runs autoconf from within make, meaning there's no obvious way to specify 
> "./configure --prefix=/mypath", so the last time I played with it (which was 
> a while ago), I wound up doing this:

To be fair, installation into specific paths is documented in 2.01 and
newer alphas. Quoting INSTALL, section "Using a different installation
directory[...]":

  "If your make program supports to propagate make macros to sub make
  programs which is the case for recent smake releases as well as for a
  recent gnumake:

        smake INS_BASE=/usr/local install
  or
        gmake INS_BASE=/usr/local install"

-- 
Matthias Andree

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

[Rob Landley]

On Tuesday 14 February 2006 7:04 pm, Matthias Andree wrote:
> On Tue, 14 Feb 2006, Rob Landley wrote:
> > With mkisofs I can just start from the spec, reverse engineer a few
> > existing ISOs, or grab the really old code from before Joerg got ahold of
> > it (back when it was still readable).  That's no problem.  But for
> > cdrecord, I can't find documentation on what the kernel expects.
>
> That's mostly the sg <http://sg.torque.net/sg/p/sg_v3_ho.html> interface
> that matters, and of that mostly the open and SG_IO parts. cdrecord is
> severely bound to talking SCSI.

Cool.  Thanks.

> > I'm only interested in supporting ATA cd burners under a 2.6 or newer
> > kernel, using the DMA method.  (SCSI is dead, I honestly don't care.)
>
> SCSI being dead for writing is actually a pity because SCSI was all in
> all so much smoother. More devices on the same cable (which was a real
> bus), no hassles with b0rked "IDE" interfaces that only work for hard
> disks but not ATAPI devices and more. Everything SCSI has had for more
> than a decade is slowly retrofitted into ATA(PI), removed if not good
> enough (TCQ), and reinvented (NCQ) when in fact SCSI had it right for
> aeons.

My tagline, "Never bet against the cheap plastic solution", has been a saying 
of mine for many years.

That said, ATA is as much IDE as PCI is ISA.  And SATA is neither, it's 
gigabit eithernet.  (The gigabit ethernet guys had a really hard problem 
blasting high speed data over the cheap copper wire already in the walls, but 
once the MII transceiver was replaced with the PHY and they started shipping 
in volume and became cheap and reliable, it made sense to use it everywhere.  
Do you hook up peripherals with gigabit ethernet?  USB2 is based on the PHY 
chip.  Hook up hard drives with gigabit ethernet?  SATA and SAS are based on 
PHYs.  And it makes a certain amount of sense that when speeds get high 
enough clocking the hell out of a single wire is easier than keeping 80 of 
them exactly in sync.  The only reason they can keep the hundreds of pins on 
a modern CPU in sync is the signal only travels about three inches, and even 
then it's not _easy_...)

The last gasp of the SCSI bigots is Serial Attached Scsi.  It's hilarious.  
Electrically it's identical (they just gold-plate the connectors and such so 
they can charge more for it).  The giveaway is that you can plug a SATA drive 
into a SAS controller and it works on "dual standard" controller firmware.  
Which one's going to have the unit volume to be cheap and sell through its 
inventory to bring out new generations faster?  And which one is exactly the 
same technology with buckets of hype, slightly different firmware, and a huge 
markup for the people who still think that because ISA sucked, its designated 
successor PCI can't be trusted?

Buying the exact same technology for way more money, based on a two-decade old 
bias in an industry where a given generation of hardware becomes obsolete 
every 3 years.  Funny to me, anyway...

> The good thing is ATAPI via ide-cd vs. SCSI does not matter any more,
> and SCSI vs. parallel matters very little (but that's just as dead as
> SCSI for CD writing). If you don't care to enumerate devices or obtain
> b,t,l, you just take the device name, open it and do some sanity checks
> to see if you're talking to a CD-ROM.

Yup.  They specify the device node they want to talk to on the command line.  
Finding it is not my problem. :)

(And the enumerating the cd burner built into my laptop ain't brain surgery.)

> The downside is, and here an abstraction layer has a point, just this
> simple won't be portable. SG_IO is Linux-specific.

I'm entirely ok with that. :)

> Jörg's complaints about ide-cd being different, layer violations and
> else are entirely artificially constructed complaints, at least he
> hasn't been able to document real bugs in ide-cd in the course of this
> thread, but holding on to ide-scsi which is known to have severe bugs.
> He was under some miscomprehension of the Linux internals and split
> ATA: and SCSI namespaces and added some more artificial complaints about
> non-existent problems.

Back around 2000 I noticed that the README for cdrecord contained prominent 
warnings about bugs the Linux kernel had fixed literally years earlier, and 
tried to play them up as fundamental design flaws.  But a few paragraphs 
later it treated workarounds for then-current Solaris bugs as a trivial 
matter of course, an inline "do this next" in the step by step instructions.

Easy to spot the bias.  Everybody's got something.  (My bias is towards cheap 
plastic solutions.  I'm the kind of guy who would turn a linksys router into 
a heart monitor.  I probably wouldn't _deploy_ it, but when somebody uses a 
$100,000 piece of computing equipement to do _anything_ I wince and wonder 
how to make a 3 year old laptop accomplish the same thing...)

Time will take care of Solaris.  Currently it seems to be making all its money 
due to the fact that government contracts can only charge 10% over the cost 
of their components, so big government contractors use the most expensive 
stuff they can find (and never re-use anything) to make that 10% as big as 
humanly possible.  Use Linux in an aircraft carrier and you get a 10% markup 
on $100.  Use Solaris in the same aircraft carrier and you get a 10% markup 
on whatever insanely inflated figure Sun cares to charge...

The law of unintended consequences is alive and well...

> > I was hoping I could just open the /dev/cdrom and call the appropriate
> > ioctls on it, but reading the cdrecord source proved enough of an
> > exercise in masochism that I always give up after the first hour and
> > put it back on the todo list.
>
> Perhaps reading a late MMC draft from t10.org is more useful as a
> starting point, if you want the real thing, you'll have to get an
> official standard. And perhaps retrofitting CD support into growisofs
> (from the dvd+rw-tools) might be another idea.

Could be...

> > I suppose I should say "screw the source code" and just run the cdrecord
> > binary under strace to see what it's doing,
>
> You'd have to enable strace to actually unravel SG_IO contents, else
> you're only getting a useless pointer - unless you trust cdrecord -V.

*shrug*  Or stick printfs in the source code.  Coasters are cheap and cd 
rewriteables last a while if you don't scratch them up...

> > * How bad?  Random example of ignoring how the rest of the world works is
> > that it runs autoconf from within make, meaning there's no obvious way to
> > specify "./configure --prefix=/mypath", so the last time I played with it
> > (which was a while ago), I wound up doing this:
>
> To be fair, installation into specific paths is documented in 2.01 and
> newer alphas. Quoting INSTALL, section "Using a different installation
> directory[...]":
>
>   "If your make program supports to propagate make macros to sub make
>   programs which is the case for recent smake releases as well as for a
>   recent gnumake:
>
>         smake INS_BASE=/usr/local install
>   or
>         gmake INS_BASE=/usr/local install"

I was doing this several years ago.  I upgraded my build _to_ 2.00.3 from some 
a 1.?? version. A quick glance at the INSTALL file from the 2.00.3 tarball I 
have in my backup pile brings up this entirely typical segment:

        You **need** either my "smake" program, the SunPRO make
        from /usr/bin/make (SunOS 4.x) or /usr/ccs/bin/make (SunOS 5.x)
        or GNU make to compile this program. Read README.gmake for
        more information on gmake and a list of the most annoying bugs in
        gmake.

        All other make programs are either not smart enough or have bugs.

        My "smake" source is at:

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

        It is easy to compile and doesn't need a working make program
        on your machine. If you don't have a working "make" program on the
        machine where you like to compile "smake" read the file "BOOTSTRAP".

        If you have the choice between all three make programs, the
        preference would be

                1)      smake           (preferred)
                2)      SunPRO make
                3)      GNU make        (this is the last resort)

        Important notice: "smake" that comes with SGI/IRIX will not work!!!
        This is not the Schily "smake" but a dumb make program from SGI.

        ***** If you are on a platform that is not yet known by the      *****
        ***** Schily makefilesystem you cannot use GNU make.             *****
        ***** In this case, the automake features of smake are required. *****

And yes, that _is_ entirely typical...

Rob
-- 
Never bet against the cheap plastic solution.

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

[Anders Karlsson]

On Wed, 15 Feb 2006 02:55:03 -0000, Rob Landley <rob@landley.net> wrote:

[snip]
> The last gasp of the SCSI bigots is Serial Attached Scsi.  It's  
> hilarious. Electrically it's identical (they just gold-plate the
> connectors and such so they can charge more for it).  The
> giveaway is that you can plug a SATA drive into a SAS controller
> and it works on "dual standard" controller firmware.
> Which one's going to have the unit volume to be cheap and sell
> through its inventory to bring out new generations faster?  And
> which one is exactly the same technology with buckets of hype,
> slightly different firmware, and a huge markup for the people who
> still think that because ISA sucked, its designated successor PCI
> can't be trusted?
>
> Buying the exact same technology for way more money, based on a  
> two-decade old bias in an industry where a given generation of
> hardware becomes obsolete every 3 years.  Funny to me, anyway...
[snip]

SAS will have the old SCSI advantage of multiple devices per
chain though. That is something that is very off-putting about
SATA actually that you need as many interfaces as you have
disks.

For commercial reasons, you'll probably find that the more
expensive SAS disks will be the ones with the lower seek-times,
the better warranties etc. We may not like it, but it ain't
going to change in a hurry.

Regards,

-- 
Anders Karlsson <anders@trudheim.com>
QA Engineer | GnuPG Key ID - 0x4B20601A

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

[Matthias Andree]

On Tue, 14 Feb 2006, Rob Landley wrote:

> The last gasp of the SCSI bigots is Serial Attached Scsi.  It's hilarious.  
> Electrically it's identical (they just gold-plate the connectors and such so 
> they can charge more for it).

Gold plating contacts is nothing fancy that would have relevance for the
price elsewhere - but it is a way against corrosion, and been used for
decades with success. And contact problems make for nearly one half of
the issues I have here with older computers. In newer computers, having
components with moving parts that are too cheap (IOW they were saving
pennies from the wrong end) is a problem because it causes downtime
again.

> > You'd have to enable strace to actually unravel SG_IO contents, else
> > you're only getting a useless pointer - unless you trust cdrecord -V.
> 
> *shrug*  Or stick printfs in the source code.  Coasters are cheap and cd 
> rewriteables last a while if you don't scratch them up...

I'm not exactly a friend of empiric programming if I can help it.
Sometimes, when working with closed-source firmware, there's no other
choice, but that doesn't imply everything needs to be done that way.

>         All other make programs are either not smart enough or have bugs.

The bug in GNU make that Jörg complains so loudly is about is purely
cosmetic with no adverse effect on the stability of the build. It's just
spewing a few messages about non-existant .d files it is trying to
include, because of the way it works. The dependency on these files is
fully functional, it spews the warning, generates the file, and that's
it. If you feel uncomfortable with that, filter them.

GNU make is rock solid in projects much larger than Jörg can imagine,
and with more complex dependencies than he might oversee.

>         ***** If you are on a platform that is not yet known by the      *****
>         ***** Schily makefilesystem you cannot use GNU make.             *****
>         ***** In this case, the automake features of smake are required. *****
> 
> And yes, that _is_ entirely typical...

Reusing existing terms in different context is one of his hobbies, yes.

-- 
Matthias Andree

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

[Lennart Sorensen]

On Tue, Feb 14, 2006 at 09:55:03PM -0500, Rob Landley wrote:
> The last gasp of the SCSI bigots is Serial Attached Scsi.  It's hilarious.  
> Electrically it's identical (they just gold-plate the connectors and such so 
> they can charge more for it).  The giveaway is that you can plug a SATA drive 
> into a SAS controller and it works on "dual standard" controller firmware.  
> Which one's going to have the unit volume to be cheap and sell through its 
> inventory to bring out new generations faster?  And which one is exactly the 
> same technology with buckets of hype, slightly different firmware, and a huge 
> markup for the people who still think that because ISA sucked, its designated 
> successor PCI can't be trusted?

SAS is actually a lot more complex than SATA.  SAS drives are dual
ported, so you can connect them to two controllers at once.  Makes
redundant systems much simpler to build if you can connect each physical
drive to two places at once.  They support port expanders (which SATA
seems to be starting to support although more limited).  You can run
SATA drives on an SAS controller, but of course you don't get dual port.
You can not run SAS drives on an SATA controller however.  SATA is
essentially a subset of SAS.

Len Sorensen

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

[Rob Landley]

On Wednesday 15 February 2006 1:31 pm, Lennart Sorensen wrote:
> On Tue, Feb 14, 2006 at 09:55:03PM -0500, Rob Landley wrote:
> > The last gasp of the SCSI bigots is Serial Attached Scsi.  It's
> > hilarious. Electrically it's identical (they just gold-plate the
> > connectors and such so they can charge more for it).  The giveaway is
> > that you can plug a SATA drive into a SAS controller and it works on
> > "dual standard" controller firmware. Which one's going to have the unit
> > volume to be cheap and sell through its inventory to bring out new
> > generations faster?  And which one is exactly the same technology with
> > buckets of hype, slightly different firmware, and a huge markup for the
> > people who still think that because ISA sucked, its designated successor
> > PCI can't be trusted?
>
> SAS is actually a lot more complex than SATA.

This is a good thing?

> SAS drives are dual ported, so you can connect them to two controllers at
> once.

Yup.  Apparently with SAS, the controllers are far more likely to fail than 
the drives.

> Makes  
> redundant systems much simpler to build if you can connect each physical
> drive to two places at once.

Or you could use raid and get complete redundancy rather than two paths to the 
same single point of failure.  Your choice.

> They support port expanders (which SATA 
> seems to be starting to support although more limited).

If it uses a PHY then it's gig ethernet under the covers.  Each hop is a point 
to point connection, but throwing switches in there isn't exactly a new 
problem.  When demand arrives, I expect supply will catch up.

> You can run SATA drives on an SAS controller, but of course you don't get
> dual port.

I still don't see why drives are expected to be more reliable than 
controllers.

I think the most paranoid setup I've seen was six disks holding two disks 
worth of information.  A three way raid-5, mirrored.  It could lose any three 
disks out of the group, and several 4 disk combinations.  If six SATA drives 
are cheaper than two SAS drives.  (Yeah, the CRC calculation eats CPU and 
flushes your cache.  So what?)

I keep thinking there should be something more useful you could do than "hot 
spare" with extra disks in simple RAID 5, some way of dynamically scaling 
more parity info.  But it's not an area I play in much...

> You can not run SAS drives on an SATA controller however.

Only because the firmware doesn't support it.  (I.E. It's an intentional lack 
of support.)

> SATA is essentially a subset of SAS.

I was under the impression that SATA came first and SAS surrounded it with 
unnecessary extensions so they could charge more money.  But then I've 
largely ignored SAS (as has everyone else I know outside of Dell), so I can't 
claim to be an expert here...

> Len Sorensen

Rob
-- 
Never bet against the cheap plastic solution.

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

[Doug McNaught]

Rob Landley <rob@landley.net> writes:

> On Wednesday 15 February 2006 1:31 pm, Lennart Sorensen wrote:
>> once.
>
> Yup.  Apparently with SAS, the controllers are far more likely to fail than 
> the drives.

I think the actual idea (or one of them) is to have two machines
connected to each drive, in a hot-standby configuration.  This has
been done for a long time with parallel SCSI, where both machines have
controllers on the bus.

-Doug

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

[Rob Landley]

On Wednesday 15 February 2006 2:16 pm, Doug McNaught wrote:
> Rob Landley <rob@landley.net> writes:
> > On Wednesday 15 February 2006 1:31 pm, Lennart Sorensen wrote:
> >> once.
> >
> > Yup.  Apparently with SAS, the controllers are far more likely to fail
> > than the drives.
>
> I think the actual idea (or one of them) is to have two machines
> connected to each drive, in a hot-standby configuration.  This has
> been done for a long time with parallel SCSI, where both machines have
> controllers on the bus.

Ah.  I'm used to projects doing that through ethernet instead, in various 
hand-rolled implementations.  A generic solution for staying in sync through 
the network would be nice.

A potentially interesting project might be hooking into the journaling stuff 
to update a network block device as data gets flushed out of the journal.  
It'd need some kind of heartbeat mechanism (if the network block device 
doesn't confirm receipt of the data within X seconds, don't hold up flushing 
the journal to the filesystem and moving on with life).  And some mechanism 
to get back in sync after getting out of sync, which could be done a number 
of ways.

I wonder if there's already something like this?  (Probably...)

> -Doug

Rob
-- 
Never bet against the cheap plastic solution.

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

[Lennart Sorensen]

On Wed, Feb 15, 2006 at 02:09:41PM -0500, Rob Landley wrote:
> This is a good thing?

If you need the added features, then I suppose so.  I certainly don't
have a need for scsi on my machine at home.  Nor do I need SAS.  SATA on
the other hand suits me just fine.

> Yup.  Apparently with SAS, the controllers are far more likely to fail than 
> the drives.

Don't know, but it sure is easier to setup two complete systems sharing
drives if they have two ports.  And cables can fail too.  That is not
that unusual.  And just because drives are more likely to fail doesn't
mean you shouldn't consider that a controller can fail.

> Or you could use raid and get complete redundancy rather than two paths to the 
> same single point of failure.  Your choice.

How do you share a raid between two systems?  I know you probably can't
make every redundant, but you can try. :)

I would expect a raid of drives handled by different systems being a
possible setup.  I remember systems setup that way with scsi in the
past, although they had the major flaw that the raid had a single scsi
bus connected to two machines at once.  If the bus went wrong you still
lost everything.  With SAS that isn't a problem anymore.

> If it uses a PHY then it's gig ethernet under the covers.  Each hop is a point 
> to point connection, but throwing switches in there isn't exactly a new 
> problem.  When demand arrives, I expect supply will catch up.

So they are 1.5 and 3 Gbit ethernet?  Well I guess if you consider
anything that runs a serial stream at a certain speed to be gigabit.  Of
course gigabit ethernet on twisted pair runs much lower clock rates and
uses 4 parallel streams.

> I still don't see why drives are expected to be more reliable than 
> controllers.

They are not, that is why you have raid.  But controllers can fail too,
as can cables.  So you want two cables per drive and two controllers
too.

> I think the most paranoid setup I've seen was six disks holding two disks 
> worth of information.  A three way raid-5, mirrored.  It could lose any three 
> disks out of the group, and several 4 disk combinations.  If six SATA drives 
> are cheaper than two SAS drives.  (Yeah, the CRC calculation eats CPU and 
> flushes your cache.  So what?)
> 
> I keep thinking there should be something more useful you could do than "hot 
> spare" with extra disks in simple RAID 5, some way of dynamically scaling 
> more parity info.  But it's not an area I play in much...

It is not an alternative to raid.  It is redundancy for different parts
of the system.

> Only because the firmware doesn't support it.  (I.E. It's an intentional lack 
> of support.)

Well maybe you can convince the sata controller makers to add whatever
they are missing.  Although then it would be an SAS controller I guess.
And sure I guess you could dumb down the firmware on the SAS drive, but
why pay more for it to use it as SATA?

> I was under the impression that SATA came first and SAS surrounded it with 
> unnecessary extensions so they could charge more money.  But then I've 
> largely ignored SAS (as has everyone else I know outside of Dell), so I can't 
> claim to be an expert here...

Looks like adaptec, LSI, buslogic, and a few others are taking SAS
seriously.  Even just having a standard for external connections is
something large raid setups require that SATA doesn't have.

Len Sorensen

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

[Rob Landley]

On Wednesday 15 February 2006 2:50 pm, Lennart Sorensen wrote:
> > Or you could use raid and get complete redundancy rather than two paths
> > to the same single point of failure.  Your choice.
>
> How do you share a raid between two systems?  I know you probably can't
> make every redundant, but you can try. :)
>
> I would expect a raid of drives handled by different systems being a
> possible setup.  I remember systems setup that way with scsi in the
> past, although they had the major flaw that the raid had a single scsi
> bus connected to two machines at once.  If the bus went wrong you still
> lost everything.  With SAS that isn't a problem anymore.

In the previous six-drive thing, there was discussion about whether or not it 
made sense to do mirroring on top of raid 5 in one system, or have two 
separate systems each with a three drive raid 5 and the whole 
heartbeat/failover thing HP was so proud of at the time.  (Which if they're 
in the same room are still vulnerable to the same backhoe/flood...)

I don't remember what actually got implemented, it was years ago and I wasn't 
involved in the actual implementation...

> > If it uses a PHY then it's gig ethernet under the covers.  Each hop is a
> > point to point connection, but throwing switches in there isn't exactly a
> > new problem.  When demand arrives, I expect supply will catch up.
>
> So they are 1.5 and 3 Gbit ethernet?

More or less.  The driving factor is economies of scale in belting out 
millions of identical high speed transceivers, but I doubt anyone's using 
Intel part #82544 in hard drives:
http://www.intel.com/design/network/products/lan/controllers/82544.htm

No, they're using Intel part #31244:
http://www.intel.com/design/storage/serialata/gd31244.htm

Which is, of course, entirely different.

The general design of something that sends a gigabit signal over all the 
unshielded twisted pair already in people's walls was a hard problem.  But 
once it was solved it meant that you could use cheap unshielded cables for 
SATA too.  That lack of shielding seems to seriously freak out all the 
old-school electrical engineers, who keep predicting doom and gloom for data 
that goes over them:

http://www.ata-atapi.com/sata.htm

> Well I guess if you consider 
> anything that runs a serial stream at a certain speed to be gigabit.

Considering that USB 1.0 used a shielded cable, it seems unlikely that SATA 
_wouldn't_ unless they were leveraging PHY development that had as one of its 
initial design constraints "we have all this installed cat 5, it's not 
shielded, and you will use it". 

> Of  course gigabit ethernet on twisted pair runs much lower clock rates and
> uses 4 parallel streams.

Quoting from the above "doom and gloom" link:

> SATA uses a 7 wire interface. Three of the wires are ground signals. The
> other 4 are two pairs of differential signals - one pair in each direction.
...
> Today's hardware runs at 1.5GHz and should be at 3GHz soon. ATA commands,
> status and data are transmitted in packets on this interface.

Sound familiar?

> > I still don't see why drives are expected to be more reliable than
> > controllers.
>
> They are not, that is why you have raid.  But controllers can fail too,
> as can cables.  So you want two cables per drive and two controllers
> too.

And if you use SATA instead of SAS then for about the same price you can 
spring for two drives so you can mirror the data.

> > Only because the firmware doesn't support it.  (I.E. It's an intentional
> > lack of support.)
>
> Well maybe you can convince the sata controller makers to add whatever
> they are missing.

Why would they?  If you expect to be 90% of the market, the other 10% can go 
hang.

> Although then it would be an SAS controller I guess. 
> And sure I guess you could dumb down the firmware on the SAS drive, but
> why pay more for it to use it as SATA?

Why pay more for it at all?

> > I was under the impression that SATA came first and SAS surrounded it
> > with unnecessary extensions so they could charge more money.  But then
> > I've largely ignored SAS (as has everyone else I know outside of Dell),
> > so I can't claim to be an expert here...
>
> Looks like adaptec, LSI, buslogic, and a few others are taking SAS
> seriously.

Of course. They've been making egregious margins off of SCSI bigots for years 
(often for different interface electronics on the exact same drive), and 
would hate to see that profit center go away.

SATA is a brand new technology that obsoletes ATA.  It uses the same data 
protocol, but that's sort of like moving from Token Ring to Ethernet but 
still talking TCP/IP over it.  The ATA guys went "ok", and gracefully 
designated SATA as the successor to ATA.  And the SCSI bigots went "Ew, it's 
the successor to ATA, it can't _possibly_ be reliable, give us a SCSI version 
of this brand new technology".

The manufacturers did not go "Which part of 'brand new technology' did you not 
understand?  Do you want a SCSI version of DRAM while you're at it?  How 
about a SCSI monitor?"

The manufacturers did not go "Why are you still carrying forward biases formed 
back when Token Ring networking actually mattered?  That's like saying 
gigabit ethernet sucks because you dislike BNC connectors."

No, the manufactures went "You're offering to pay us twice as much for a 
trivial variant of the same technology?  Cool!  Yeah, the cheap stuff stucks, 
buy the premium version.  We'll throw in undercoating and bucket seats!"

> Even just having a standard for external connections is 
> something large raid setups require that SATA doesn't have.

*shrug*.  The spec allows SATA cables to be a meter long.  You run out of 
controllers and power connectors before you run out of space to put drives.

As for adding switches and longer cables in there, google brings up...

http://www.3ware.com/products/serial_ata.asp
http://www.addonics.com/products/host_controller/

And of course every time you search adeptec for "sata switch" they redirect 
you to pages on SAS, which is just their way of saying "Would you like fries 
with that?"  Upsell, gotta love it.  Push the high-margin stuff...

But we're getting deep enough into matters of opinion I think I'm going to 
tail off here...

> Len Sorensen

Rob
-- 
Never bet against the cheap plastic solution.

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

[Helge Hafting]

Rob Landley wrote:

>The general design of something that sends a gigabit signal over all the 
>unshielded twisted pair already in people's walls was a hard problem.  But 
>once it was solved it meant that you could use cheap unshielded cables for 
>SATA too.  That lack of shielding seems to seriously freak out all the 
>old-school electrical engineers, who keep predicting doom and gloom for data 
>that goes over them:
>
>http://www.ata-atapi.com/sata.htm
>  
>
Now that was funny.  Complaining about unshielded SATA while
praising the equally unshielded PATA cables. :-/

Helge Hafting

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

[Matthias Andree]

On Fri, 17 Feb 2006, Helge Hafting wrote:

> Now that was funny.  Complaining about unshielded SATA while
> praising the equally unshielded PATA cables. :-/

33 MHz or even 133 MHz aren't 1.5 GHz you know.

-- 
Matthias Andree

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

[Jan Engelhardt]

>
>How do you share a raid between two systems?  I know you probably can't
>make every redundant, but you can try. :)
>
Make a mirror /dev/md0 out of /dev/nb0 and /dev/nb1.
Of course, you should only mount the filesystem once (to avoid 
corruptions), so the only "software" way of sharing is nfs, etc.
Or stuff like ocfs, whatever.


Jan Engelhardt
-- 

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

[John Stoffel]

>>>>> "Rob" == Rob Landley <rob@landley.net> writes:

Rob> Yup.  Apparently with SAS, the controllers are far more likely to
Rob> fail than the drives.

While a single drive is more likely to fail when compared to a single
controller, for a truly redundant system you want no single point of
failure, which means redundant controllers is a requirement.

>> Makes redundant systems much simpler to build if you can connect
>> each physical drive to two places at once.

Rob> Or you could use raid and get complete redundancy rather than two
Rob> paths to the same single point of failure.  Your choice.

Excuse me?  Think about what you just wrote here and what you're
implying.  

Of course you would use RAID here, along with two controllers and two
paths to the single disk.  But you'd also have multiple disks here as
well.  Not a single disk and two controllers and consider that
reliable.  

>> They support port expanders (which SATA seems to be starting to
>> support although more limited).

Rob> I still don't see why drives are expected to be more reliable
Rob> than controllers.

He never said they were. 

Rob> I think the most paranoid setup I've seen was six disks holding
Rob> two disks worth of information.  A three way raid-5, mirrored.
Rob> It could lose any three disks out of the group, and several 4
Rob> disk combinations.  If six SATA drives are cheaper than two SAS
Rob> drives.  (Yeah, the CRC calculation eats CPU and flushes your
Rob> cache.  So what?)

And how many controllers could that setup lose?  You need to think of
the whole path, not just the disks at the ends, when you are planning
for reliability (and performance as well).  

Also, with dual ports on a drive, it becomes much easier to build two
machine clusters which both can see all the drives shared between the
clusters.  Just like SCSI (old, original 5MB/S scsi) where you changed
hte ID of one of the initiators.  Not done frequently, but certainly
done alot with VMS/VAX clusters.

Rob> I keep thinking there should be something more useful you could
Rob> do than "hot spare" with extra disks in simple RAID 5, some way
Rob> of dynamically scaling more parity info.  But it's not an area I
Rob> play in much...

RAID6, or as NetApp calls it, Dual Parity.  You can lose any TWO disks
in a raid group and still be working.  It covers to more common single
disk fails, and then you still have full parity coverage if another
disk fails during the re-build of the parity info onto the spare
drive.  

With 250Gb disks, that run a 50MB/S, it takes a LONG time to actually
sweep though all the data and rebuild the parity.  24 hours or more.
So to cover your butt, you'd like to have even more redundancy.

I've run fully mirrored servers, where I had redundant paths to each
disk from each controller.  When I lost a controller, which certainly
happened, I didn't lose any data, nor disk I lose mirroring either.
Very nice.

In the situtations where I only had one controller per set of disks,
and mirrored between controlles, losing a controller meant I had to
re-mirror things once they got running again, but I didn't lose data.
Very nice.

Building reliable disk storage is not cheap.  Fast, reliable, cheap.
Pick any two.  :]

John

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

[Rob Landley]

On Wednesday 15 February 2006 10:06 pm, John Stoffel wrote:
> Building reliable disk storage is not cheap.  Fast, reliable, cheap.
> Pick any two.  :]

Nah, I start by picking cheap anyway, and apparently if I want reliable that 
just means it'd be slow by your formula. :)

> John

Rob
-- 
Never bet against the cheap plastic solution.

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

[Alexander Samad]

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

On Wed, Feb 15, 2006 at 10:32:54PM -0500, Rob Landley wrote:
> On Wednesday 15 February 2006 10:06 pm, John Stoffel wrote:
> > Building reliable disk storage is not cheap.  Fast, reliable, cheap.
> > Pick any two.  :]
> 
> Nah, I start by picking cheap anyway, and apparently if I want reliable that 
> just means it'd be slow by your formula. :)

any particular reason we haven't talked about SAN's 

> 
> > John
> 
> Rob
> -- 
> Never bet against the cheap plastic solution.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

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

[Helge Hafting]

Rob Landley wrote:

>Time will take care of Solaris.  Currently it seems to be making all its money 
>due to the fact that government contracts can only charge 10% over the cost 
>of their components, so big government contractors use the most expensive 
>stuff they can find (and never re-use anything) to make that 10% as big as 
>humanly possible.  Use Linux in an aircraft carrier and you get a 10% markup 
>on $100.  Use Solaris in the same aircraft carrier and you get a 10% markup 
>on whatever insanely inflated figure Sun cares to charge...
>  
>
Hm, I can sell linux at insanely inflated prices to whoever needs that. :-)

Helge Hafting

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

[Joerg Schilling]

Anders Karlsson <trudheim@gmail.com> wrote:

> On 2/14/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> [snip]
> > -       How does HAL allow one cdrecord instance to work
> >         without being interrupted by HAL?
>
> Uuh, if the writer unit is plugged in via USB and HAL detects it going
> away, as in getting disconnected from the system, don't you think it
> would be a smart move for cdrecord to pay attention to such an alert?
>
> I am sure you can explain to me if there are overwhelming technical
> reason to continue dumping data to a non-existant device.

It seems that you did not loisten to this discussion before, why doyou come in 
now not knowing the topcis?

Try to get hand on the deleted bug entries on Debian and you will see how
cdrecord is interrupted.

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-14:

> Try to get hand on the deleted bug entries on Debian and you will see how
> cdrecord is interrupted.

How about you offer a few "deleted bug" numbers?

Or have you been so sloppy not to record the bugs of interest in
external packages?

-- 
Matthias Andree

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

[Jan Engelhardt]

>
>> Try to get hand on the deleted bug entries on Debian and you will see how
>> cdrecord is interrupted.
>
>How about you offer a few "deleted bug" numbers?
>
why does debian delete bugs after all? this sounds like aggregativing 
searches for it.


Jan Engelhardt
-- 

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

[Lennart Sorensen]

On Tue, Feb 14, 2006 at 05:47:55PM +0100, Joerg Schilling wrote:
> It seems that you did not loisten to this discussion before, why doyou come in 
> now not knowing the topcis?
> 
> Try to get hand on the deleted bug entries on Debian and you will see how
> cdrecord is interrupted.

Debian archives old closed bugs.  They can still be found by searching the
archived bugs.  I have never seen them delete bugs, although maybe they
do and I just missed it.

Len Sorensen

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

[Jim Crilly]

On 02/14/06 05:47:55PM +0100, Joerg Schilling wrote:
> Anders Karlsson <trudheim@gmail.com> wrote:
> 
> > On 2/14/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > [snip]
> > > -       How does HAL allow one cdrecord instance to work
> > >         without being interrupted by HAL?
> >
> > Uuh, if the writer unit is plugged in via USB and HAL detects it going
> > away, as in getting disconnected from the system, don't you think it
> > would be a smart move for cdrecord to pay attention to such an alert?
> >
> > I am sure you can explain to me if there are overwhelming technical
> > reason to continue dumping data to a non-existant device.
> 
> It seems that you did not loisten to this discussion before, why doyou come in 
> now not knowing the topcis?
> 
> Try to get hand on the deleted bug entries on Debian and you will see how
> cdrecord is interrupted.
> 
> Jörg

Apparently you're the one not paying attention, the so-called bugs you were
talking about haven't been deleted and I even mentioned that I found them
in this 'discussion' days ago.

Jim.

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

[Carlo J. Calica]

Joerg Schilling wrote:
> 
> And if you have a working vold on Solaris, libscg accepts the vold
> aliases.
> 

But vold isn't supported on all cdrecord platforms?  Why do you support that
but not Linux equivalents?

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

[Xavier Bestel]

On Mon, 2006-02-13 at 17:24, Joerg Schilling wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
> > b,t,l <= os_specific_name
> 
> Why do you believe that this kind of mapping is needed?

Eh .. because b,t,l mapping isn't stable under linux !

	Xav

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

[jerome lacoste]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
>
> > The mapping I am talking about is currently done inside libscg (inside
> > the scsi-*.c files). Hence libscg is the one capable of exposing this
> > information to higher levels.
> >
> > > and how would you like to implement it OS independent?
> >
> > The information printed will be printed in a format such as:
> >
> > b,t,l <= os_specific_name
>
> Why do you believe that this kind of mapping is needed?

To make it so that:

- cdrecord keeps its dev=b,t,l command line interface

- a cdrecord wrapper program lets a user specify the os specific name
to access the drive. The wrapper program would identify the b,t,l name
and feed it correctly to cdrecord. This can also be used to correctly
identify 2 identical drives using their OS specific names.

-scanbus displays:
1,0,0: DRIVE MODEL XYZ
2,0,0: DRIVE MODEL XYZ

but thank to that proposal, one would also have:

1,0,0 <= /dev/hdc
2,0,0 <= /dev/hdd

I think it's a good compromise between what the users want and what you want.

So, WDYT?

Jerome

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

[Joerg Schilling]

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

> To make it so that:
>
> - cdrecord keeps its dev=b,t,l command line interface
>
> - a cdrecord wrapper program lets a user specify the os specific name
> to access the drive. The wrapper program would identify the b,t,l name
> and feed it correctly to cdrecord. This can also be used to correctly
> identify 2 identical drives using their OS specific names.
>
> -scanbus displays:
> 1,0,0: DRIVE MODEL XYZ
> 2,0,0: DRIVE MODEL XYZ
>
> but thank to that proposal, one would also have:
>
> 1,0,0 <= /dev/hdc
> 2,0,0 <= /dev/hdd
>
> I think it's a good compromise between what the users want and what you want.
>
> So, WDYT?

If this would not be Linux only, go ahead.

Note that you would have to do real hard work as it is not trivial to prove your
patch on all supported OS....


Jörg

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

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

[Joerg Schilling]

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

> jerome lacoste <jerome.lacoste@gmail.com> wrote:
> > but thank to that proposal, one would also have:
> >
> > 1,0,0 <= /dev/hdc
> > 2,0,0 <= /dev/hdd
> >
> > I think it's a good compromise between what the users want and what you want.
> >
> > So, WDYT?
>
> If this would not be Linux only, go ahead.
>
> Note that you would have to do real hard work as it is not trivial to prove your
> patch on all supported OS....

I did get no reply.

Does this mean that you are no longer interested because I request real work
instead of a cheap hack?

Jörg

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

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

[D. Hazelton]

On Tuesday 14 February 2006 06:31, Joerg Schilling wrote:
> Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > jerome lacoste <jerome.lacoste@gmail.com> wrote:
> > > but thank to that proposal, one would also have:
> > >
> > > 1,0,0 <= /dev/hdc
> > > 2,0,0 <= /dev/hdd
> > >
> > > I think it's a good compromise between what the users want and what you
> > > want.
> > >
> > > So, WDYT?
> >
> > If this would not be Linux only, go ahead.
> >
> > Note that you would have to do real hard work as it is not trivial to
> > prove your patch on all supported OS....
>
> I did get no reply.
>
> Does this mean that you are no longer interested because I request real
> work instead of a cheap hack?


Joerg, enough with the personal attacks. That you didn't see the reply is just 
proof that you don't read the entirety of messages posted or sent to you 
directly. 

here is both responses:

in one he posts the contents of a single line of code that he added to the 
linux wrapper code in libscg.

In the second he asks for a guarantee that you will stand behind your 
(somewhat sketchy) posted guidelines for patches.

And what follows from here out is the relevant portions of the messages, 
complete with the "Message ID" field from the headers in case you want to dig 
through you inbox or wherever you misfiled these responses to read the 
entirety of them.

DRH

Message-ID: <5a2cf1f60602130407j79805b8al55fe999426d90b97@mail.gmail.com>

<snip>
I am aiming for a compromise.

My point is that people want to use dev=/dev/hdc in their interface,
because that's what they are used to. That's a point that I think you
cannot deny.

If you want to still keep your dev=b,t,l command line interface, just
let the users know how your mapping is done. That will allow a
cdrecord wrapper to first query the mapping, then using this mapping
information and OS specific information (e.g. links) identify the
b,t,l expected by your interface.

That way you have mostly no code change to do. And you keep your b,t,l
naming. Everybody is happy.

I've added something like:

                fprintf(stdout, "%d,%d,%d <= /dev/%s\n",
                                first_free_schilly_bus, t, l, 
token[ID_TOKEN_SUBSYSTEM] );

in scsi-linux-ata.c and it does what I want.

WDYT?

Cheers,

Jerome

Message-ID: <5a2cf1f60602130608qf6a2575ucbd57615eb32cc67@mail.gmail.com>

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
>
> > > Are you accepting such a patch?
> >
> > If his response to the last patch someone provided is any example the 
answer
> > is going to be no. And I firmly believe the old adage that a leopard can't
> > change it's spots.
>
> Any patch that
>
> -       does not break things
>
> -       fits into the spirit of the currnt implementation
>
> -       offers useful new features
>
> -       conforms to coding style standards
>
> -       does not need more time to integrate than I would need to
>         write this from scratch
>
> Unfortunately, many people who send patches to me do not follow
> these simple rules.

I am still waiting for an answer as to whether such a patch would be
accepted. We will take on the practical details later on.

Jerome

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > > > I think it's a good compromise between what the users want and what you
> > > > want.
> > > >
> > > > So, WDYT?
> > >
> > > If this would not be Linux only, go ahead.
> > >
> > > Note that you would have to do real hard work as it is not trivial to
> > > prove your patch on all supported OS....
> >
> > I did get no reply.
> >
> > Does this mean that you are no longer interested because I request real
> > work instead of a cheap hack?
>
>
> Joerg, enough with the personal attacks. That you didn't see the reply is just 
> proof that you don't read the entirety of messages posted or sent to you 
> directly. 
>
> here is both responses:

It seems that you still not understand that you cannot demand things from me 
that Linux does not offer at all.

The person who had problem with the fact that I like a patch to fit into
the spirit of the current implementation obviously does not know that he tries 
to demand things that he will not get from any known project.

Jörg

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

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

[D. Hazelton]

On Tuesday 14 February 2006 11:40, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > > > I think it's a good compromise between what the users want and what
> > > > > you want.
> > > > >
> > > > > So, WDYT?
> > > >
> > > > If this would not be Linux only, go ahead.
> > > >
> > > > Note that you would have to do real hard work as it is not trivial to
> > > > prove your patch on all supported OS....
> > >
> > > I did get no reply.
> > >
> > > Does this mean that you are no longer interested because I request real
> > > work instead of a cheap hack?
> >
> > Joerg, enough with the personal attacks. That you didn't see the reply is
> > just proof that you don't read the entirety of messages posted or sent to
> > you directly.
> >
> > here is both responses:
>
> It seems that you still not understand that you cannot demand things from
> me that Linux does not offer at all.
>
> The person who had problem with the fact that I like a patch to fit into
> the spirit of the current implementation obviously does not know that he
> tries to demand things that he will not get from any known project.
>
> Jörg

And what was demanded?

He asked for an assurance that you would look at the patch and at least 
consider including it rather than debying it sight unseen as you did with 
Matthias' patch.

Furthermore, he provided a sample of what he was doing to achieve the goal he 
posted of having cdrecord print useful data for those people who have 
multiple devices and to whom the btl addresses and vendor strings mean 
little.

DRH

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

[jerome lacoste]

On 2/14/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
>
> > jerome lacoste <jerome.lacoste@gmail.com> wrote:
> > > but thank to that proposal, one would also have:
> > >
> > > 1,0,0 <= /dev/hdc
> > > 2,0,0 <= /dev/hdd
> > >
> > > I think it's a good compromise between what the users want and what you want.
> > >
> > > So, WDYT?
> >
> > If this would not be Linux only, go ahead.
> >
> > Note that you would have to do real hard work as it is not trivial to prove your
> > patch on all supported OS....
>
> I did get no reply.

Nothin I read above give me the impression that you expected an answer.

> Does this mean that you are no longer interested because I request real work
> instead of a cheap hack?

...

Jerome

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

[Joerg Schilling]

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

> > > > 1,0,0 <= /dev/hdc
> > > > 2,0,0 <= /dev/hdd
> > > >
> > > > I think it's a good compromise between what the users want and what you want.
> > > >
> > > > So, WDYT?
> > >
> > > If this would not be Linux only, go ahead.
> > >
> > > Note that you would have to do real hard work as it is not trivial to prove your
> > > patch on all supported OS....
> >
> > I did get no reply.
>
> Nothin I read above give me the impression that you expected an answer.

Isn't a reply an act of politeness?

Jörg

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

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

[D. Hazelton]

On Monday 13 February 2006 05:40, Joerg Schilling wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
> > On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > > "D. Hazelton" <dhazelton@enter.net> wrote:
> > > > And does cdrecord even need libscg anymore? From having actually gone
> > > > through your code, Joerg, I can tell you that it does serve a larger
> > > > purpose. But at this point I have to ask - besides cdrecord and a few
> > > > other _COMPACT_ _DISC_ writing programs, does _ANYONE_ use libscg? Is
> > > > it ever used to access any other devices that are either SCSI or use
> > > > a SCSI command protocol (like ATAPI)?  My point there is that you
> > > > have a wonderful library, but despite your wishes, there is no proof
> > > > that it is ever used for anything except writing/ripping CD's.
> > >
> > > Name a single program (not using libscg) that implements user space
> > > SCSI and runs on as many platforms as cdrecord/libscg does.
> >
> > I have 2 technical questions, and I hope that you will take the time
> > to answer them.
> >
> > 1) extract from the README of the latest stable cdrtools package:
> >
> >         Linux driver design oddities
> > ****************************************** Although cdrecord supports to
> > use dev=/dev/sgc, it is not recommended and it is unsupported.
> >
> >         The /dev/sg* device mapping in Linux is not stable! Using
> > dev=/dev/sgc in a shell script may fail after a reboot because the device
> > you want to talk to has moved to /dev/sgd. For the proper and OS
> > independent dev=<bus>,<tgt>,<lun> syntax read the man page of cdrecord.
> >
> > My understanding of that is you say to not use dev=/dev/sgc because it
> > isn't stable. Now that you've said that bus,tgt,lun is not stable on
> > Linux (because of a "Linux bug") why is the b,t,l scheme preferred
> > over the /dev/sg* one ?
>
> b,t,l _is_ stable as long as the OS does a reasonable and orthogonal work.
>
> This was true until ~ 2001, when Linux introduced unstable USB handling.
> Note that this fact is not a failure from libscg but from Linux.

Isn't that also when the USB system underwent a massive rewrite to fully 
support hotplugging and to fix a lot of bugs that were present in the 
original implementation?

Still, the question I posed in my earlier post remains - why can't you have 
your program do the BTL mappings behind the scenes? You can easily allow it 
from the command line and also allow pointing to a /dev entry... If you want 
I'll actually put together a patch based on whatever version of cdrecord I 
have here on my system and send it to you.

DRH

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

[Alexander Samad]

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

On Fri, Feb 10, 2006 at 02:03:30PM +0100, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> 
> > And does cdrecord even need libscg anymore? From having actually gone through 
> > your code, Joerg, I can tell you that it does serve a larger purpose. But at 
> > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_ 
> > writing programs, does _ANYONE_ use libscg? Is it ever used to access any 
> > other devices that are either SCSI or use a SCSI command protocol (like 
> > ATAPI)?  My point there is that you have a wonderful library, but despite 
> > your wishes, there is no proof that it is ever used for anything except 
> > writing/ripping CD's.
> 
> Name a single program (not using libscg) that implements user space SCSI and runs 
> on as many platforms as cdrecord/libscg does.

Isnt this like saying why do we need windows server software when we
have Novell running most of the worlds server and again why do we need
linux when we have Microsoft running a majourity of the worlds servers.

Why cause we evolve we try to make things better, natural evolution


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

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

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

[jerome lacoste]

On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
>
> > And does cdrecord even need libscg anymore? From having actually gone through
> > your code, Joerg, I can tell you that it does serve a larger purpose. But at
> > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_
> > writing programs, does _ANYONE_ use libscg? Is it ever used to access any
> > other devices that are either SCSI or use a SCSI command protocol (like
> > ATAPI)?  My point there is that you have a wonderful library, but despite
> > your wishes, there is no proof that it is ever used for anything except
> > writing/ripping CD's.
>
> Name a single program (not using libscg) that implements user space SCSI and runs
> on as many platforms as cdrecord/libscg does.

As an application developer, I would focus on the following questions:

* what is the percentage of Windows users using a CD burning/ripping
program based on libscg?

* what is the percentage of cdrecord Linux users out of the total
number of cdrecord users?

* what are your expectations with regard to those numbers in the future?

Jerome

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

[Martin Mares]

Hello!

> Well, this is a deficit of the Linux kernel - not libscg.

This is exactly what I have written -- extra effort is needed to get
a stable numbering (which Solaris does), but you can use a very similar
extra care to get stable names (which Linux with udev does).

So I really se no advantage in preferring the numeric addresses over
device names, while device names have the obvious advantage of working
for all devices, not only SCSI.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Light-year? One-third less calories than a regular year.

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> Hello!
>
> > Well, this is a deficit of the Linux kernel - not libscg.
>
> This is exactly what I have written -- extra effort is needed to get
> a stable numbering (which Solaris does), but you can use a very similar
> extra care to get stable names (which Linux with udev does).

As this conceptional deficite in Linux causes Linux to break POSIX
compliance e.g. for stat(2) with hot plugged devices, people with 
sufficient background knowledge should know that Linux tried to fix a 
low level bug at a high level ignoring that the mid-level is still broken.

Jörg

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

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

[Jan Engelhardt]

>> > Well, this is a deficit of the Linux kernel - not libscg.
>>
>> This is exactly what I have written -- extra effort is needed to get
>> a stable numbering (which Solaris does), but you can use a very similar
>> extra care to get stable names (which Linux with udev does).
>
>As this conceptional deficite in Linux causes Linux to break POSIX
>compliance e.g. for stat(2) with hot plugged devices, people with 

The struct stat->st_rdev field need to be stable too to comply to POSIX?

>sufficient background knowledge should know that Linux tried to fix a 
>low level bug at a high level ignoring that the mid-level is still broken.


Jan Engelhardt
-- 

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

[Joerg Schilling]

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

> >> > Well, this is a deficit of the Linux kernel - not libscg.
> >>
> >> This is exactly what I have written -- extra effort is needed to get
> >> a stable numbering (which Solaris does), but you can use a very similar
> >> extra care to get stable names (which Linux with udev does).
> >
> >As this conceptional deficite in Linux causes Linux to break POSIX
> >compliance e.g. for stat(2) with hot plugged devices, people with 
>
> The struct stat->st_rdev field need to be stable too to comply to POSIX?

Correct.

Jörg

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

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

[Theodore Ts'o]

On Fri, Feb 10, 2006 at 02:22:42PM +0100, Joerg Schilling wrote:
> >
> > The struct stat->st_rdev field need to be stable too to comply to POSIX?
> 
> Correct.
> 

Chapter and verse, please?  

Can you please list the POSIX standard, section, and line number which
states that a particular device must always have the same st_rdev
across reboots, and hot plugs/unplugs?

Regards,

						- Ted

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

[Joerg Schilling]

"Theodore Ts'o" <tytso@mit.edu> wrote:

> On Fri, Feb 10, 2006 at 02:22:42PM +0100, Joerg Schilling wrote:
> > >
> > > The struct stat->st_rdev field need to be stable too to comply to POSIX?
> > 
> > Correct.
> > 
>
> Chapter and verse, please?  
>
> Can you please list the POSIX standard, section, and line number which
> states that a particular device must always have the same st_rdev
> across reboots, and hot plugs/unplugs?

A particular file on the system must not change st_dev while the system
is running.

http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html

Jörg

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

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

[Christopher Friesen]

Joerg Schilling wrote:
> "Theodore Ts'o" <tytso@mit.edu> wrote:

>>Can you please list the POSIX standard, section, and line number which
>>states that a particular device must always have the same st_rdev
>>across reboots, and hot plugs/unplugs?
> 
> 
> A particular file on the system must not change st_dev while the system
> is running.
> 
> http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html


I don't actually see that requirement listed there. It says that st_dev 
must be unique, and that all files are uniquely identified by st_ino and 
st_dev.

There's nothing there that says the mapping cannot change with 
time...just that it has to be unique.

Chris

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

[Joerg Schilling]

"Christopher Friesen" <cfriesen@nortel.com> wrote:

> > A particular file on the system must not change st_dev while the system
> > is running.
> > 
> > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html
>
>
> I don't actually see that requirement listed there. It says that st_dev 
> must be unique, and that all files are uniquely identified by st_ino and 
> st_dev.
>
> There's nothing there that says the mapping cannot change with 
> time...just that it has to be unique.

If it changes over the runtime of a program, it is not unique from the
view of that program.

Jörg

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

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

[Christopher Friesen]

Joerg Schilling wrote:
> "Christopher Friesen" <cfriesen@nortel.com> wrote:

>>There's nothing there that says the mapping cannot change with 
>>time...just that it has to be unique.
> 
> 
> If it changes over the runtime of a program, it is not unique from the
> view of that program.

That depends on what "uniquely identified" actually means.

One possible definition is that at any time, a particular path maps to a 
single unique st_ino/st_dev tuple.

The other possibility (and this is what you seem to be advocating) is 
that a st_ino/st_dev tuple always maps to the same file over the entire 
runtime of the system.

This second possibility seems easily disproved.  If you delete and 
recreate files on a filesystem (assuming nobody has open files in the 
filesystem), at some point a new file will end up with the same inode as 
an old (deleted) file.  The two files are different, but have the same 
st_ino/st_dev tuple.

This leaves the first possibility as the only choice...

Chris

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

[Chris Shoemaker]

On Fri, Feb 10, 2006 at 09:13:44AM -0600, Christopher Friesen wrote:
> Joerg Schilling wrote:
> >"Christopher Friesen" <cfriesen@nortel.com> wrote:
> 
> >>There's nothing there that says the mapping cannot change with 
> >>time...just that it has to be unique.
> >
> >
> >If it changes over the runtime of a program, it is not unique from the
> >view of that program.
> 
> That depends on what "uniquely identified" actually means.

"The st_ino and st_dev fields taken together uniquely identify the
file within the system."

> One possible definition is that at any time, a particular path maps to a 
> single unique st_ino/st_dev tuple.

The quoted sentence certainly implies _at_least_ that much.

> The other possibility (and this is what you seem to be advocating) is 
> that a st_ino/st_dev tuple always maps to the same file over the entire 
> runtime of the system.

However, I don't think this is a reasonable interpretation, and it's
clearly _not_ the one that Joerg is implying.

Joerg is claiming that the quoted sentence also implies that
_different_ st_ino/st_dev pairs will _always_ identify different
files.  Taken in just the immediate context of stat.h, this is a
very reasonable interpretation.

> This second possibility seems easily disproved.  If you delete and 
> recreate files on a filesystem (assuming nobody has open files in the 
> filesystem), at some point a new file will end up with the same inode as 
> an old (deleted) file.  The two files are different, but have the same 
> st_ino/st_dev tuple.
> 
> This leaves the first possibility as the only choice...

If you want to show that his interpretation is incorrent (which it
may be for all I know), you need a better argument than this.

-chris

> 
> Chris

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

[Christopher Friesen]

Chris Shoemaker wrote:
> On Fri, Feb 10, 2006 at 09:13:44AM -0600, Christopher Friesen wrote:

>>That depends on what "uniquely identified" actually means.
> 
> 
> "The st_ino and st_dev fields taken together uniquely identify the
> file within the system."

>>The other possibility (and this is what you seem to be advocating) is 
>>that a st_ino/st_dev tuple always maps to the same file over the entire 
>>runtime of the system.

> However, I don't think this is a reasonable interpretation, and it's
> clearly _not_ the one that Joerg is implying.
> 
> Joerg is claiming that the quoted sentence also implies that
> _different_ st_ino/st_dev pairs will _always_ identify different
> files.  Taken in just the immediate context of stat.h, this is a
> very reasonable interpretation.

It seems to me that "st_ino/st_dev tuple always maps to the same file" 
is equivalent to "different st_ino/st_dev pairs will always identify 
different files".  What is the distinction between the two statements?

As I see it, the main question is whether it is a unique mapping *at one 
specific point in time*, or is it a unique mapping *for the duration of 
the system*?  Note that in this case "system" includes "parts of the 
tree that may be remotely mounted from other machines on the network".

I would suggest that the spec doesn't specify the duration of the unique 
mapping, and thus as long as there is a unique mapping *at any 
particular point in time*, then there is no conflict.

If we read it as requiring a unique mapping for the duration of the 
system, consider a hypothetical "system" that includes all the devices 
of all the computers on the planet, and they are all dynamically 
appearing and disappearing continuously.  Consider the technical 
challenge in ensuring that each file on this hypothetical system is 
permanently and uniquely identified by a device/inode pair.

Chris

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

[Chris Shoemaker]

On Fri, Feb 10, 2006 at 09:53:37AM -0600, Christopher Friesen wrote:
> Chris Shoemaker wrote:
> >On Fri, Feb 10, 2006 at 09:13:44AM -0600, Christopher Friesen wrote:
> 
> >>That depends on what "uniquely identified" actually means.
> >
> >
> >"The st_ino and st_dev fields taken together uniquely identify the
> >file within the system."
> 
> >>The other possibility (and this is what you seem to be advocating) is 
> >>that a st_ino/st_dev tuple always maps to the same file over the entire 
> >>runtime of the system.
> 
> >However, I don't think this is a reasonable interpretation, and it's
> >clearly _not_ the one that Joerg is implying.
> >
> >Joerg is claiming that the quoted sentence also implies that
> >_different_ st_ino/st_dev pairs will _always_ identify different
> >files.  Taken in just the immediate context of stat.h, this is a
> >very reasonable interpretation.
> 
> It seems to me that "st_ino/st_dev tuple always maps to the same file" 
> is equivalent to "different st_ino/st_dev pairs will always identify 
> different files".  What is the distinction between the two statements?

This distinction is probably quite important.  

The first assertion is that this is an injective mapping from the
domain of files to the range of st_Ito/st_dev pairs.

The second assertion is that this is an injective mapping from the
domain of st_Ito/st_dev pairs to the range of files.

The first may be true even when the second is false.

I'm no expert on SUS, but if a spec says "X uniquely identifies Y"
it's almost certainly asserting that there's an injective mapping from
the domain of X into the domain of Y, and it's probably also
reasonable to infer that the mapping in the other direction is also
injective.

> As I see it, the main question is whether it is a unique mapping *at one 
> specific point in time*, or is it a unique mapping *for the duration of 
> the system*?  Note that in this case "system" includes "parts of the 
> tree that may be remotely mounted from other machines on the network".
> 
> I would suggest that the spec doesn't specify the duration of the unique 
> mapping, and thus as long as there is a unique mapping *at any 
> particular point in time*, then there is no conflict.

In the absense of a specified duration for which the property must
hold, it's unfortunately necessary (albeit, somewhat dangerous) to
*infer* the duration based on the intended *use* of the property
(e.g. equality testing).  Two parties which intend to employ the
property for different purposes may infer two different durations - a
typical spec deficiency.

> If we read it as requiring a unique mapping for the duration of the 
> system, consider a hypothetical "system" that includes all the devices 
> of all the computers on the planet, and they are all dynamically 
> appearing and disappearing continuously.  Consider the technical 
> challenge in ensuring that each file on this hypothetical system is 
> permanently and uniquely identified by a device/nod pair.

It seems this example only presents a challenge to ensuring the
*inferred* requirement of the injective mapping from files to pairs,
not for ensuring *only* the explicit requirement that pairs uniquely
identify a file (but not necessarily that they uniquely identify *one*
file).

-chris

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

[Joerg Schilling]

Chris Shoemaker <c.shoemaker@cox.net> wrote:

> However, I don't think this is a reasonable interpretation, and it's
> clearly _not_ the one that Joerg is implying.
>
> Joerg is claiming that the quoted sentence also implies that
> _different_ st_ino/st_dev pairs will _always_ identify different
> files.  Taken in just the immediate context of stat.h, this is a
> very reasonable interpretation.

Correct, as a st_ino/st_dev pair uniquely identifies a file, the reverse
needs to be true in addition.

Jörg

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

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

[Joerg Schilling]

"Christopher Friesen" <cfriesen@nortel.com> wrote:

> Joerg Schilling wrote:
> > "Christopher Friesen" <cfriesen@nortel.com> wrote:
>
> >>There's nothing there that says the mapping cannot change with 
> >>time...just that it has to be unique.
> > 
> > 
> > If it changes over the runtime of a program, it is not unique from the
> > view of that program.
>
> That depends on what "uniquely identified" actually means.
>
> One possible definition is that at any time, a particular path maps to a 
> single unique st_ino/st_dev tuple.
>
> The other possibility (and this is what you seem to be advocating) is 
> that a st_ino/st_dev tuple always maps to the same file over the entire 
> runtime of the system.

Well it is obvious that this is a requirement.

If Linux does device name mapping at high level but leaves the low level part
unstable, then the following coul happen:

Just think about a program that checks a file that is on a removable media.

This media is mounted via a vold service and someone removes the USB cable
and reinserts it a second later. The filesystem on the device will be mounted
on the same mount point but the device ID inside the system did change.

As a result, the file unique identification st_ino/st_dev is not retained 
and the program is confused.

Jörg

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

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

[Martin Mares]

Hello!

> Just think about a program that checks a file that is on a removable media.
> 
> This media is mounted via a vold service and someone removes the USB cable
> and reinserts it a second later. The filesystem on the device will be mounted
> on the same mount point but the device ID inside the system did change.
> 
> As a result, the file unique identification st_ino/st_dev is not retained 
> and the program is confused.

And it would be equally confused if I inserted a different media instead.

Relying on stability of anything across mounts/umounts does not make any
sense.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
The number of UNIX installations has grown to 10, with more expected.  (6/72)

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:

> Well it is obvious that this is a requirement.
> 
> If Linux does device name mapping at high level but leaves the low level part
> unstable, then the following coul happen:
> 
> Just think about a program that checks a file that is on a removable media.
> 
> This media is mounted via a vold service and someone removes the USB cable
> and reinserts it a second later. The filesystem on the device will be mounted
> on the same mount point but the device ID inside the system did change.
> 
> As a result, the file unique identification st_ino/st_dev is not retained 
> and the program is confused.

How does $OS know the storage device wasn't plugged into another system
during that second and changed in that time? This doesn't even seem
far-fetched, just think of USB-capable KVM switches.

Changing st_dev and returning I/O error or stale FS error or whatever is
adequate makes perfect sense. Once the device is unplugged, the mount is
dead. st_dev stability (that is not demanded by POSIX) doesn't help a
iota in making it usable again.

You're barking up the wrong tree anyways. You're holding on to a
non-workable b,t,l approach because it's convenient on BSD and some
other systems, but it cannot be stable. The only stable identifiers I
conceive are brand,model,serial - and this is the way to get rid of the
ugly race between cdrecord -scanbus and cdrecord dev=b,t,l.

Yes, it requires you to change the interface. It doesn't even matter you
need to do that, because hotplug was probably not an issue when libscg
saw the first light on SunOS. Changes in the environment require some
lifeforms to adjust to the new conditions. If they don't change, they'll
die out. This is just natural.

And to make the brand,model,serial approach bullet-proof, the kernel
should detect if this triple is duplicated at some time and refuse to
talk to ANY of these until all but one have been unplugged, just in case
no serial number is provided by a particular device of which two
specimen are plugged.

-- 
Matthias Andree

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

[Marcin Dalecki]

On 2006-02-13, at 13:01, Matthias Andree wrote:
>
> You're barking up the wrong tree anyways. You're holding on to a
> non-workable b,t,l approach because it's convenient on BSD and some
> other systems, but it cannot be stable. The only stable identifiers I
> conceive are brand,model,serial - and this is the way to get rid of  
> the
> ugly race between cdrecord -scanbus and cdrecord dev=b,t,l.

Right with the exception that it's the UID (unique id) *standard*  
that is
addressing this issue for other operating systems in a very reliable and
already successfull way. No need to invent something different here  
in particular
in the storage area.

vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)]

[Xavier Bestel]

On Mon, 2006-02-13 at 11:30, Joerg Schilling wrote:

> This media is mounted via a vold service and someone removes the USB cable
> and reinserts it a second later. The filesystem on the device will be mounted
> on the same mount point but the device ID inside the system did change.

BTW, is there a vold-like implementation for linux somewhere ?

Thanks,
	Xav

forget this maim (vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)])

[Xavier Bestel]

On Mon, 2006-02-13 at 13:14, Xavier Bestel wrote:

> BTW, is there a vold-like implementation for linux somewhere ?

Yes, there is.

Re: forget this maim (vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)])

[Jan Engelhardt]

>> BTW, is there a vold-like implementation for linux somewhere ?
>
>Yes, there is.
>
automount I suppose. There are also more and less kludgy things, 
supermount, subfs, etc.


Jan Engelhardt
-- 

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

[D. Hazelton]

On Monday 13 February 2006 05:30, Joerg Schilling wrote:
> "Christopher Friesen" <cfriesen@nortel.com> wrote:
> > Joerg Schilling wrote:
> > > "Christopher Friesen" <cfriesen@nortel.com> wrote:
> > >>There's nothing there that says the mapping cannot change with
> > >>time...just that it has to be unique.
> > >
> > > If it changes over the runtime of a program, it is not unique from the
> > > view of that program.
> >
> > That depends on what "uniquely identified" actually means.
> >
> > One possible definition is that at any time, a particular path maps to a
> > single unique st_ino/st_dev tuple.
> >
> > The other possibility (and this is what you seem to be advocating) is
> > that a st_ino/st_dev tuple always maps to the same file over the entire
> > runtime of the system.
>
> Well it is obvious that this is a requirement.
>
> If Linux does device name mapping at high level but leaves the low level
> part unstable, then the following coul happen:
>
> Just think about a program that checks a file that is on a removable media.
>
> This media is mounted via a vold service and someone removes the USB cable
> and reinserts it a second later. The filesystem on the device will be
> mounted on the same mount point but the device ID inside the system did
> change.

Joerg, I think you've got your OS's mixed up here. AFAIK, Linux does not have 
a "vold" system.

> As a result, the file unique identification st_ino/st_dev is not retained
> and the program is confused.

I have to agree that you are correct, but then, most removable media in the 
Linux world do not actually have physical inodes. AFAIK, DVD's use the UDF 
filesystem, a lot of CDRW's are formatted the same, CD's/CDR's generally use 
the ISO9660 filesystem and other removable media, such as any floppy disc and 
the now ubiquitous "zip disk's" use FAT16. I'm not current on UDF, but from 
prior experience, I'd be willing to bet it doesn't have indoes, and the 
ISO9660 filesystem doesn't have them, even if you use the RR extensions. What 
is referred to in the Linux kernel as inodes for those systems are generally 
block indexes, and for the FAT filesystem what it calls an "inode" is just 
the name and a few other bits - and in the case of an LFN being used on said 
volume, the name is spread across several "special blocks"... invalidating 
the concept of an INODE for said filesystems.


In any case, the hypothetical case you present here seems more in tune with 
Solaris as you present it, since with UDEV the device node created for said 
removable media would stay the same, and hence st_dev would also (IIRC) 
remain the same.

DRH

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

[Theodore Ts'o]

On Fri, Feb 10, 2006 at 03:32:28PM +0100, Joerg Schilling wrote:
> > Chapter and verse, please?  
> >
> > Can you please list the POSIX standard, section, and line number which
> > states that a particular device must always have the same st_rdev
> > across reboots, and hot plugs/unplugs?
> 
> A particular file on the system must not change st_dev while the system
> is running.
> 
> http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html

1)  File != device.

2)  st_dev != st_rdev

3) The reference you specified says nothing about st_dev (or st_rdev)
being invariant while the system is runnning.  Line number, please?

4) POSIX/SUS is very careful not to define what dev_t.  Use of mknod to
create block/chracter devices, and depending on any properties of
dev_t is likely to get you into trouble.

5) The st_rdev of a particular file, like /dev/hda *does* remain
invariant.  The device which it points to may change, but that's a
different matter --- and POSIX/SUS is very deliberately silent on your
subject.

THEREFORE, your claim that Linux's behaviour violates POSIX/SUS is
demonstrably false.  Quod erat demonstratum.

						- Ted

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

[Joerg Schilling]

"Theodore Ts'o" <tytso@mit.edu> wrote:

> On Fri, Feb 10, 2006 at 03:32:28PM +0100, Joerg Schilling wrote:
> > > Chapter and verse, please?  
> > >
> > > Can you please list the POSIX standard, section, and line number which
> > > states that a particular device must always have the same st_rdev
> > > across reboots, and hot plugs/unplugs?
> > 
> > A particular file on the system must not change st_dev while the system
> > is running.
> > 
> > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html
>
> 1)  File != device.

I am sorry, but it turns out that you did not understand the problem.

Try to inform yourself about the relevence (and content) of st_dev before
replying again.

Jörg

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

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

[Erik Mouw]

On Fri, Feb 10, 2006 at 03:54:44PM +0100, Joerg Schilling wrote:
> "Theodore Ts'o" <tytso@mit.edu> wrote:
> > On Fri, Feb 10, 2006 at 03:32:28PM +0100, Joerg Schilling wrote:
> > > A particular file on the system must not change st_dev while the system
> > > is running.
> > > 
> > > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html
> >
> > 1)  File != device.
> 
> I am sorry, but it turns out that you did not understand the problem.

Why do you start an ad hominem attack every time somebody shows you're
wrong for technical reasons?

> Try to inform yourself about the relevence (and content) of st_dev before
> replying again.

It has no relevance. st_dev holds the device number of the device
containing the file. That means that if /dev/hda (3,01) is on /dev, it
contains the device number of filesystem of /dev, 0x0b in my case (udev
using tmpfs):

  root@arthur:/home # stat /dev/hda
    File: `/dev/hda'
    Size: 0               Blocks: 0          IO Block: 4096   block special file
  Device: bh/11d  Inode: 548         Links: 1     Device type: 3,0
  [...]

If I create that same special file "hda" in /home, I get:

  root@arthur:/home # mknod hda b 3 0
  root@arthur:/home # stat hda
    File: `hda'
    Size: 0               Blocks: 0          IO Block: 4096   block special file
  Device: 308h/776d       Inode: 3026        Links: 1     Device type: 3,0
  [...]

It's the same device because st_rdev is the same in both cases, it just
lives on a different filesystem. You can use either device to operate
on.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

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

[Marc Koschewski]

* Erik Mouw <erik@harddisk-recovery.com> [2006-02-10 16:42:56 +0100]:

> On Fri, Feb 10, 2006 at 03:54:44PM +0100, Joerg Schilling wrote:
> > "Theodore Ts'o" <tytso@mit.edu> wrote:
> > > On Fri, Feb 10, 2006 at 03:32:28PM +0100, Joerg Schilling wrote:
> > > > A particular file on the system must not change st_dev while the system
> > > > is running.
> > > > 
> > > > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html
> > >
> > > 1)  File != device.
> > 
> > I am sorry, but it turns out that you did not understand the problem.
> 
> Why do you start an ad hominem attack every time somebody shows you're
> wrong for technical reasons?

Duuude ... could you all calm down and get the facts together? What if you'd all
be in the same room with a knife by the hand every one of you?!

I suggest Joerg summarizes the facts from his point of view _in detail_ and
people are going to respond to it. I think it pretty useless to get people
respond to you, Joerg, where you just drop a two-liner where one line is that
someone is stupid or not as good at something and the other line is a quick
statement that just always leaves place for people to ask more questions and
proceed arguing.

Please clarify. Summarize. This whole thing turns into some totally useles infitine
state machine...

Thanks anyone for your eyes. :)

Marc

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

[Theodore Ts'o]

On Fri, Feb 10, 2006 at 03:54:44PM +0100, Joerg Schilling wrote:
> >
> > 1)  File != device.
> 
> I am sorry, but it turns out that you did not understand the problem.
> 
> Try to inform yourself about the relevence (and content) of st_dev before
> replying again.

st_dev is irrelevant in the context of CD burning.

In the context of mounted files, the only guarantee given by POSIX is
that st_dev and st_ino for a particular file is unique.  But that
clearly is true while the containing filesystem is mounted.  Even with
Solaris, if a particular removable filesystem is unmounted and removed
from one device (say one Jazz/Zip drive) and inserted into another
device (say another Jazz/Zip drive), st_dev will change --- while the
system is running.

So your claim is __still__ false.

Please try again and give a fully formed argument, and assume that
your discussion partners might know what they are talk about in the
future.

						- Ted

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

[Joerg Schilling]

"Theodore Ts'o" <tytso@mit.edu> wrote:

> On Fri, Feb 10, 2006 at 03:54:44PM +0100, Joerg Schilling wrote:
> > >
> > > 1)  File != device.
> > 
> > I am sorry, but it turns out that you did not understand the problem.
> > 
> > Try to inform yourself about the relevence (and content) of st_dev before
> > replying again.
>
> st_dev is irrelevant in the context of CD burning.

If you did try to understand the reason why I did introduce the POSIX
claim, you would know that if Linux did try to follow the POSIX rule,
a side effect would be that removable devices need to have a stable 
mapping in the kernel


> In the context of mounted files, the only guarantee given by POSIX is
> that st_dev and st_ino for a particular file is unique.  But that
> clearly is true while the containing filesystem is mounted.  Even with
> Solaris, if a particular removable filesystem is unmounted and removed
> from one device (say one Jazz/Zip drive) and inserted into another
> device (say another Jazz/Zip drive), st_dev will change --- while the
> system is running.

Please don't confuse the fact that you will _always_ be able to find
ways to confuse a system with the fact that this needs to happen in all cases.

Jörg

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

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

[Theodore Ts'o]

On Mon, Feb 13, 2006 at 11:45:32AM +0100, Joerg Schilling wrote:
> If you did try to understand the reason why I did introduce the POSIX
> claim, you would know that if Linux did try to follow the POSIX rule,
> a side effect would be that removable devices need to have a stable 
> mapping in the kernel

It is _not_ a POSIX rule, as I and others have shown.  You claimed it
was required by POSIX, but you are quite clearly incorrect.  It has
never worked that way with Unix systems, and POSIX was always designed
to codify existing practice.  On Unix systems fixed disks would and
did have their devices numbering schemes move around under a number of
conditions.

> > In the context of mounted files, the only guarantee given by POSIX is
> > that st_dev and st_ino for a particular file is unique.  But that
> > clearly is true while the containing filesystem is mounted.  Even with
> > Solaris, if a particular removable filesystem is unmounted and removed
> > from one device (say one Jazz/Zip drive) and inserted into another
> > device (say another Jazz/Zip drive), st_dev will change --- while the
> > system is running.
> 
> Please don't confuse the fact that you will _always_ be able to find
> ways to confuse a system with the fact that this needs to happen in 
> all cases.

_Needs to happen_?  According to whom?

And by your definition, if it _needs_ to happen "in all cases", then
clearly since Solaris can be confused in this particular way, your
favorite operating system is also "broken", yes?  And if you still
claim that it is a "Posix rule", then by your reasoning Solaris must
not be Posix compliant either.  Go ahead and tell your OpenSolaris
friends that, and see what they say.  :-)

						- Ted

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

[Joerg Schilling]

"Theodore Ts'o" <tytso@mit.edu> wrote:

> On Mon, Feb 13, 2006 at 11:45:32AM +0100, Joerg Schilling wrote:
> > If you did try to understand the reason why I did introduce the POSIX
> > claim, you would know that if Linux did try to follow the POSIX rule,
> > a side effect would be that removable devices need to have a stable 
> > mapping in the kernel
>
> It is _not_ a POSIX rule, as I and others have shown.  You claimed it
> was required by POSIX, but you are quite clearly incorrect.  It has
> never worked that way with Unix systems, and POSIX was always designed
> to codify existing practice.  On Unix systems fixed disks would and
> did have their devices numbering schemes move around under a number of
> conditions.

If you believe this, pleace give evidence.

I was quoting POSIX documents which prove my claims......
Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:

> "Theodore Ts'o" <tytso@mit.edu> wrote:
> 
> > On Mon, Feb 13, 2006 at 11:45:32AM +0100, Joerg Schilling wrote:
> > > If you did try to understand the reason why I did introduce the POSIX
> > > claim, you would know that if Linux did try to follow the POSIX rule,
> > > a side effect would be that removable devices need to have a stable 
> > > mapping in the kernel
> >
> > It is _not_ a POSIX rule, as I and others have shown.  You claimed it
> > was required by POSIX, but you are quite clearly incorrect.  It has
> > never worked that way with Unix systems, and POSIX was always designed
> > to codify existing practice.  On Unix systems fixed disks would and
> > did have their devices numbering schemes move around under a number of
> > conditions.
> 
> If you believe this, pleace give evidence.
> 
> I was quoting POSIX documents which prove my claims......

The source you quoted neither contained the quoted material
nor did it support your view in any other way.
This was shown by several people, you have been Cc:d.

You are beyond help.

EOD.

-- 
Matthias Andree

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

[Jan Engelhardt]

>> It is _not_ a POSIX rule, as I and others have shown.  You claimed it
>> was required by POSIX, but you are quite clearly incorrect.  It has
>> never worked that way with Unix systems, and POSIX was always designed
>> to codify existing practice.  On Unix systems fixed disks would and
>> did have their devices numbering schemes move around under a number of
>> conditions.
>
>If you believe this, pleace give evidence.
>
>I was quoting POSIX documents which prove my claims......
>

I suppose the world needs a POSIX subcommitte solely devoted for clarifying 
all the claims of all sides :->


Jan Engelhardt
-- 

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

[Diego Calleja]

El Fri, 10 Feb 2006 15:54:44 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:

> I am sorry, but it turns out that you did not understand the problem.


Could you explain why stat->st_dev / stat->st_ino POSIX semantics forces
POSIX implementations to have a stable stat->st_rdev number? 

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

[Joerg Schilling]

Diego Calleja <diegocg@gmail.com> wrote:

> El Fri, 10 Feb 2006 15:54:44 +0100,
> Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:
>
> > I am sorry, but it turns out that you did not understand the problem.
>
>
> Could you explain why stat->st_dev / stat->st_ino POSIX semantics forces
> POSIX implementations to have a stable stat->st_rdev number? 

I was never talking about stat->st_rdev 

see: http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html


Jörg

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

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

[Florin Malita]

Joerg Schilling wrote:

>>Could you explain why stat->st_dev / stat->st_ino POSIX semantics forces
>>POSIX implementations to have a stable stat->st_rdev number? 
>>    
>>
>
>I was never talking about stat->st_rdev 
>  
>
This is blatantly incorrect. You *were* talking about stat->st_rdev:
http://lkml.org/lkml/2006/2/10/143

On 2/10/06, *Joerg Schilling* <schilling@fokus.fraunhofer.de> wrote:

    Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
    > The struct stat->st_rdev field need to be stable too to comply to
    POSIX?

    Correct.

    Jörg


You may claim you *never meant to* or you *never realized* you were
talking about, but you can't say you never talked about it - that's an
outright lie.

--
fm

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

[Joerg Schilling]

Florin Malita <fmalita@gmail.com> wrote:

> Joerg Schilling wrote:
>
> >>Could you explain why stat->st_dev / stat->st_ino POSIX semantics forces
> >>POSIX implementations to have a stable stat->st_rdev number? 
> >>    
> >>
> >
> >I was never talking about stat->st_rdev 
> >  
> >
> This is blatantly incorrect. You *were* talking about stat->st_rdev:
> http://lkml.org/lkml/2006/2/10/143
>
> On 2/10/06, *Joerg Schilling* <schilling@fokus.fraunhofer.de> wrote:
>
>     Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>     > The struct stat->st_rdev field need to be stable too to comply to
>     POSIX?
>
>     Correct.
>
>     Jörg
>
>
> You may claim you *never meant to* or you *never realized* you were
> talking about, but you can't say you never talked about it - that's an
> outright lie.

You are lying here.

I did not write st_rdev and from my previous mail it was obvioys that 
I was referring to st_dev.



Jörg

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

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

[Diego Calleja]

El Mon, 13 Feb 2006 16:56:18 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:

> I did not write st_rdev and from my previous mail it was obvioys that 
> I was referring to st_dev.


Well, and everbody else was referring to st_rdev, including the email
you answered....

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

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 794 bytes --]

>> This is blatantly incorrect. You *were* talking about stat->st_rdev:
>> http://lkml.org/lkml/2006/2/10/143
>>
>> On 2/10/06, *Joerg Schilling* <schilling@fokus.fraunhofer.de> wrote:
>>
>>     Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>>     > The struct stat->st_rdev field need to be stable too to comply to
>>     > POSIX?
>>
>>     Correct.
>>
>>     Jörg
>>
>>
>> You may claim you *never meant to* or you *never realized* you were
>> talking about, but you can't say you never talked about it - that's an
>> outright lie.
>
>You are lying here.
>
>I did not write st_rdev and from my previous mail it was obvioys that 
>I was referring to st_dev.
>
Exactly. But I asked specifically about Rdev... see "stable too"
(=German: "Muss st_rdev auch stabil sein?")



Jan Engelhardt
-- 

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

[Florin Malita]

Joerg Schilling wrote:

>Florin Malita <fmalita@gmail.com> wrote:
>
>>On 2/10/06, *Joerg Schilling* <schilling@fokus.fraunhofer.de> wrote:
>>
>>    Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>>    > The struct stat->st_rdev field need to be stable too to comply to
>>    POSIX?
>>
>>    Correct.
>>
>>    Jörg
>>
>>
>>You may claim you *never meant to* or you *never realized* you were
>>talking about, but you can't say you never talked about it - that's an
>>outright lie.
>>    
>>
>I did not write st_rdev and from my previous mail it was obvioys that 
>I was referring to st_dev.
>  
>
I never said you *wrote* st_rdev, did I?

You confirmed a statement about st_rdev - that's called "talking about
it". The fact that you didn't intend to or how obvious that is is
irrelevant in this context: you *did talk* about st_rdev and there's no
way you can deny or erase that.

But here comes the classic twist: instead of acknowledging your mistake,
you place the blame on everybody else for not guessing you were talking
about something else. This is not a rational behavior, please stop.

--
fm

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

[Joerg Schilling]

It seems that this "discussion" is missong new ideas and I believe it's
best to stop any conversation that does not introduce new ideas.

I mentioned the two most important Linux Bugs to fix.

Let us continue after there is at least a hint that leads to a possible
fix for these bugs.

It makes no sense to waste my time while it is obvious that the Linux
kernel folks are completely missing any will to fix their bugs.

Jörg

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

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

[Luke-Jr]

On Monday 13 February 2006 16:43, Joerg Schilling wrote:
> It seems that this "discussion" is missong new ideas and I believe it's
> best to stop any conversation that does not introduce new ideas.
>
> I mentioned the two most important Linux Bugs to fix.
>
> Let us continue after there is at least a hint that leads to a possible
> fix for these bugs.
>
> It makes no sense to waste my time while it is obvious that the Linux
> kernel folks are completely missing any will to fix their bugs.

I think the general consensus from kernel developers and cdrecord users alike 
is that the only logical way to refer to devices in Linux is via /dev/* and 
any other method is broken and illogical.

If you want stable b,t,l junk, submit a clean patch for Linux yourself. Either 
way, 99.99% of cdrecord *users* want to use /dev/cdrom whether b,t,ls are 
stable or not. The code to do the latter is already written, working, and 
well-tested-- you just need to drop an artificial warning.

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

[Nikita Danilov]

Joerg Schilling writes:
 > "Theodore Ts'o" <tytso@mit.edu> wrote:
 > 
 > > On Fri, Feb 10, 2006 at 02:22:42PM +0100, Joerg Schilling wrote:
 > > > >
 > > > > The struct stat->st_rdev field need to be stable too to comply to POSIX?
 > > > 
 > > > Correct.
 > > > 
 > >
 > > Chapter and verse, please?  
 > >
 > > Can you please list the POSIX standard, section, and line number which
 > > states that a particular device must always have the same st_rdev
 > > across reboots, and hot plugs/unplugs?
 > 
 > A particular file on the system must not change st_dev while the system
 > is running.

Where is that from?

 > 
 > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html

This text doesn't seem to support your claim.

 > 
 > JЖrg

Nikita.

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

[Jan Engelhardt]

>> > > The struct stat->st_rdev field need to be stable too to comply to POSIX?
>> > Correct.
>A particular file on the system must not change st_dev while the system
>is running.
>

Attention, I asked for st_rdev (=major/minor as presented in ls -l),
not st_dev (major/minor of the disk /dev is on).


Jan Engelhardt
-- 

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

[Joerg Schilling]

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

> >> > > The struct stat->st_rdev field need to be stable too to comply to POSIX?
> >> > Correct.
> >A particular file on the system must not change st_dev while the system
> >is running.
> >
>
> Attention, I asked for st_rdev (=major/minor as presented in ls -l),
> not st_dev (major/minor of the disk /dev is on).

I was of course talking about st_dev

But as a note: st_rdev from the device carrying the FS becomes st_dev
for all files inside a particular FS.

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:

> But as a note: st_rdev from the device carrying the FS becomes st_dev
> for all files inside a particular FS.

This doesn't yield any further guarantees, and beyond that is utterly
irrelevant as the device in question is not mounted at all, so this
connection remains invisible.

This is just the usual Schily Distraction Maneuvre.

-- 
Matthias Andree

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

[Jan Engelhardt]

>> But as a note: st_rdev from the device carrying the FS becomes st_dev
>> for all files inside a particular FS.
>
>[...]
>This is just the usual Schily Distraction Maneuvre.

You are getting nontechnical.


Jan Engelhardt
-- 

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

[Joerg Schilling]

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

> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
> > >> > Well, this is a deficit of the Linux kernel - not libscg.
> > >>
> > >> This is exactly what I have written -- extra effort is needed to get
> > >> a stable numbering (which Solaris does), but you can use a very similar
> > >> extra care to get stable names (which Linux with udev does).
> > >
> > >As this conceptional deficite in Linux causes Linux to break POSIX
> > >compliance e.g. for stat(2) with hot plugged devices, people with 
> >
> > The struct stat->st_rdev field need to be stable too to comply to POSIX?
>
> Correct.

Mmmm, it looks like I did oversee that you did change the subject.....

I did say that stat->st_dev needs to be stable

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:

> I did say that stat->st_dev needs to be stable

Yeah right. And Earth turns into a tetrahedron at your command.
Dream on... but keep it for yourself.

And to shut this subthread for good, I searched the whole IEEE Std
1003.1, 2004 Edition - nothing states any stability for st_dev.

All you get with this standards are two uniqueness guarantees (i. e. no
duplicates at a certain point in time -- this does not imply any kind of
stability), namely:

1. st_dev changes across mounts (definitions) and

2. (st_dev,st_ino) tuples are unique (<sys/stat.h>)

Ready-made query:
<http://www.opengroup.org/cgi-bin/susv3search.pl?KEYWORDS=st_dev&CONTEXT=>

Please don't respond. You're wasting time.

-- 
Matthias Andree

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-10:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports
> > > 
> > > Dou you like to verify that you have no clue on SCSI?
> >
> > How does, for instance, libscg make sure that the b,t,l mappings are
> > hotplug invariant?
> >
> > How does libscg make sure that two external writers, say USB, retain
> > their b,t,l mappings if both are unplugged and then replugged in reverse
> > order, perhaps into different USB hubs?
> 
> Well, this is a deficit of the Linux kernel - not libscg.

I wrote this before, but to fresh up your memory, here again, different
wording:

Unless Solaris's behavior is mandated by a commonly accepted standard,
comparable in relevance to IEEE or IETF standards, it is not relevant
for Linux.

It is YOU who has to make that decision: support your cdrtools users who
chose Linux (which means: accepting its decisions and adjusting YOUR
code to work properly, and either file detailed, traceable and
comprehensible bug reports, or work around the bugs), or leave the Linux
users standing in the rain.

-- 
Matthias Andree

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

[DervishD]

    Hi Joerg :)

 * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> Martin Mares <mj@ucw.cz> wrote:
> > > This is why the mapping engine is in the Linux adoption part of
> > > libscg. It maps the non-stable device <-> /dev/sg* relation to a
> > > stable b,t,l address.
> >
> > Nonsense. The b,t,l addresses are NOT stable (at least for transports
> 
> Dou you like to verify that you have no clue on SCSI?

    My system is clueless, too! If I write a CD before plugging my
USB storage device, my CD writer is on 0,0,0. If I plug my USB
storage device *before* doing any access, my cdwriter is on 1,0,0.
Pretty stable.

    But of course, I could made all of the above stable by using
udev. But then the /dev/sg mapping will be stable, too. I can't see
why the three random numbers are more stable than /dev/sg. By the
way, I don't have any SCSI host adapter in my system.

    And please, Joerg, be more respectful when answering. It doesn't
cost money and people will likely respect you, too.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

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

[Matthias Andree]

DervishD schrieb am 2006-02-10:

>     Hi Joerg :)
> 
>  * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> > Martin Mares <mj@ucw.cz> wrote:
> > > > This is why the mapping engine is in the Linux adoption part of
> > > > libscg. It maps the non-stable device <-> /dev/sg* relation to a
> > > > stable b,t,l address.
> > >
> > > Nonsense. The b,t,l addresses are NOT stable (at least for transports
> > 
> > Dou you like to verify that you have no clue on SCSI?
> 
>     My system is clueless, too! If I write a CD before plugging my
> USB storage device, my CD writer is on 0,0,0. If I plug my USB
> storage device *before* doing any access, my cdwriter is on 1,0,0.
> Pretty stable.

Thanks for answering the question I directed towards Jörg, which proves
Martin Mares's point that b,t,l is not stable.

I think, Martin, too deserves Jörg's apology, and Jörg shouldn't only be
more respectful, but listen to those who know their system better than
he does. (Of course this'll turn into a flame feast how stupid Linux
is.)

-- 
Matthias Andree

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

[DervishD]

    Hi Matthias :)

 * Matthias Andree <matthias.andree@gmx.de> dixit:
> > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports
> > > 
> > > Dou you like to verify that you have no clue on SCSI?
> > 
> >     My system is clueless, too! If I write a CD before plugging my
> > USB storage device, my CD writer is on 0,0,0. If I plug my USB
> > storage device *before* doing any access, my cdwriter is on 1,0,0.
> > Pretty stable.
> 
> Thanks for answering the question I directed towards Jörg, which proves
> Martin Mares's point that b,t,l is not stable.

    This is a typical problem with the BTL numbering that any 2.4.x
modular Linux kernel running without hotplug or udev has. And, at
least to my knowledge and in /dev/sg side, it can be fixed using
hotplug or udev (in 2.6.x). The BTL problem cannot.
 
> I think, Martin, too deserves Jörg's apology

    I think so. Martin was being very respectuf.

> and Jörg shouldn't only be more respectful, but listen to those who
> know their system better than he does. (Of course this'll turn into
> a flame feast how stupid Linux is.)

    And that's a pity, because it is a waste of human resources. And
the bigger problem is that I still don't know why BTL is better than
/dev/sg, and I've tried to understand it from the thread. I would be
glad to hear Jörg explanations, but he thinks I'm trying to FUD :(

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

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

[Joerg Schilling]

DervishD <lkml@dervishd.net> wrote:

>     My system is clueless, too! If I write a CD before plugging my
> USB storage device, my CD writer is on 0,0,0. If I plug my USB
> storage device *before* doing any access, my cdwriter is on 1,0,0.
> Pretty stable.

You are referring to a conceptional problem in the Linux kernel.
If you are unhappy with this, send a bug report to the related
people.

This does not belong to libscg.

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-10:

> DervishD <lkml@dervishd.net> wrote:
> 
> >     My system is clueless, too! If I write a CD before plugging my
> > USB storage device, my CD writer is on 0,0,0. If I plug my USB
> > storage device *before* doing any access, my cdwriter is on 1,0,0.
> > Pretty stable.
> 
> You are referring to a conceptional problem in the Linux kernel.
> If you are unhappy with this, send a bug report to the related
> people.
> 
> This does not belong to libscg.

No. You're shifting the blame, and this won't work here. You claim b,t,l
were more stable than device node naming (which is untrue, as proven),
and if it isn't because the assumptions in libscg don't hold, it's
still someone else's fault. In doubt, everything that isn't Solaris or
SchilliX is badly designed, a bug, or whatever.

That's a pretty egocentric view.

-- 
Matthias Andree

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

[Sam Vilain]

Joerg Schilling wrote:
>>    My system is clueless, too! If I write a CD before plugging my
>>USB storage device, my CD writer is on 0,0,0. If I plug my USB
>>storage device *before* doing any access, my cdwriter is on 1,0,0.
>>Pretty stable.
> You are referring to a conceptional problem in the Linux kernel.
> If you are unhappy with this, send a bug report to the related
> people.
> This does not belong to libscg.

Jörg,

Technically, you may have a point[*1*].

However, no matter how correct someone is, if they act like a complete
dork, they're not going to be listened to.

This is a shame, because you appear to have some good experience to
relate.  If only you could keep your social interaction problems in
check, you might be able to harbour and attract less hate, and perhaps
even get some of your suggestions implemented.

Until you do that, you will continue to find yourself getting caught out
on the details in the discussions while insulted people simply pick out
your mistakes; you cannot possibly fight the community and win.

Dave S. Miller gave an excellent talk on this subject at Linux.conf.au;
when the video is available I'll send you a link to it.

Sam.

*1*  Linux doesn't use the Solaris style of a connection-oriented /sys
that /dev is all symlinks to, that scandevices et al update.  This leads
to a more stable /dev filesystem, such that even adding controllers in
lower numbered slots will not reorder the devices, as the /dev
filesystem state remembers them.

This was a no-brainer design decision, as the hardware platform was
under strict control, and the builds more regulated.  Linux has never
really seen this type of integration fascism available that this kind of
approach requires, and so this kind of solution is inappropriate.

However, Solaris is not immune to the root problem being discussed, for
connection types that give dynamically assigned IDs (like USB) rather
than statically defined (like SCSI).  You simply might not be able to
recognise the device after a system change.

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

[Joerg Schilling]

Sam Vilain <sam@vilain.net> wrote:

> Joerg Schilling wrote:
> >>    My system is clueless, too! If I write a CD before plugging my
> >>USB storage device, my CD writer is on 0,0,0. If I plug my USB
> >>storage device *before* doing any access, my cdwriter is on 1,0,0.
> >>Pretty stable.
> > You are referring to a conceptional problem in the Linux kernel.
> > If you are unhappy with this, send a bug report to the related
> > people.
> > This does not belong to libscg.
>
> Jörg,
>
> Technically, you may have a point[*1*].
>
> However, no matter how correct someone is, if they act like a complete
> dork, they're not going to be listened to.

This is why I have less and less intrest in listening to most of the
people who are around here.

They are either technically uninformed, personal offensive or obviously
not interested in a solution.
 

> This is a shame, because you appear to have some good experience to
> relate.  If only you could keep your social interaction problems in
> check, you might be able to harbour and attract less hate, and perhaps
> even get some of your suggestions implemented.

Well, once the people here express real interest, things may change.

As for now, it looks like I may make the following conclusions:

-	Linux was helpful and interesting between 1996 and ~ 2001

-	Since ~ 2001, Linux seems to be bejond it's climax as I cannot
	see any intrest in even fixing obvious bugs known for a long time.

When looking at the current discussion, it seems to me that most people
here are still not interested in a fix.


Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:

> When looking at the current discussion, it seems to me that most people
> here are still not interested in a fix.

This includes yourself, for not providing the list of items my patch
breaks.

-- 
Matthias Andree

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

[sean]

On Mon, 13 Feb 2006 15:29:02 +0100
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> When looking at the current discussion, it seems to me that most people
> here are still not interested in a fix.

Most people don't see a problem to fix.   Your arguments have been roundly
refuted.   On top of which, cdrecord works on Linux just fine already when
you pass the device node on the command line.   There just isn't much 
motivation to pursue a fix for some theoretical problem that doesn't affect
real users in practice.  Since you are the only one who sees this as a huge
problem you should invest in providing a patch that can be reviewed for 
inclusion.

Sean

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

[Joerg Schilling]

sean <seanlkml@sympatico.ca> wrote:

> On Mon, 13 Feb 2006 15:29:02 +0100
> Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
>
> > When looking at the current discussion, it seems to me that most people
> > here are still not interested in a fix.
>
> Most people don't see a problem to fix.   Your arguments have been roundly
> refuted.   On top of which, cdrecord works on Linux just fine already when
> you pass the device node on the command line.   There just isn't much 
> motivation to pursue a fix for some theoretical problem that doesn't affect
> real users in practice.  Since you are the only one who sees this as a huge
> problem you should invest in providing a patch that can be reviewed for 
> inclusion.

So you like to prove that it makes not sense to talk to LKML people?

If there is no interest to fox well known bugs in Linux, I would need to warn
people from using Linux.


Jörg

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

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

[sean]

On Mon, 13 Feb 2006 16:36:17 +0100
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> > Most people don't see a problem to fix.   Your arguments have been roundly
> > refuted.   On top of which, cdrecord works on Linux just fine already when
> > you pass the device node on the command line.   There just isn't much 
> > motivation to pursue a fix for some theoretical problem that doesn't affect
> > real users in practice.  Since you are the only one who sees this as a huge
> > problem you should invest in providing a patch that can be reviewed for 
> > inclusion.
> 
> So you like to prove that it makes not sense to talk to LKML people?

This is a non sequitur.

> If there is no interest to fox well known bugs in Linux, I would need to warn
> people from using Linux.

People have a lot of interest to fix well known bugs in Linux, it happens every
day.   The point is nobody but you classifies this as a bug.   Since you are
alone in classifying this as a bug, you will be alone in submitting patches for
it.   Good luck.

Sean

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

[Martin Mares]

Hello!

> If there is no interest to fox well known bugs in Linux, I would need to warn
> people from using Linux.

Except for mentioning some DMA related problems at the beginning of this
monstrous thread, you haven't shown anything which even remotely qualifies
as a bug.

You are only endlessly complaining about Linux not following the same
model of SCSI access as you love, which might be a little incovenient
for you, but that certainly doesn't make it a bug.

You tried to juggle with dubious POSIX references, but so far nobody has
found any place in POSIX or SuS saying that anything has to be stable
across mounts/umounts.

So what damned bugs are you speaking about?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"One single semicolon. A perfect drop of perliness. The rest is padding." -- S. Manandhar

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> Hello!
>
> > If there is no interest to fox well known bugs in Linux, I would need to warn
> > people from using Linux.
>
> Except for mentioning some DMA related problems at the beginning of this
> monstrous thread, you haven't shown anything which even remotely qualifies
> as a bug.

If you forget these things, then please forget about this thread.

I mentioned:

-	ide-scsi does not do DMA correctly

-	SCSI commands are bastardized on ATAPI 

If you like, I can give you many other Linux related bugs but it does
not make sense unless the two bugs above are 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 (stirring up a hornets' nest)

[Joerg Schilling]

Anders Karlsson <trudheim@gmail.com> wrote:

> On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> [snip]
> > If you forget these things, then please forget about this thread.
> >
> > I mentioned:
> >
> > -       ide-scsi does not do DMA correctly
> >
> > -       SCSI commands are bastardized on ATAPI
> >
> > If you like, I can give you many other Linux related bugs but it does
> > not make sense unless the two bugs above are fixed.
>
> Perhaps libata is more to your liking and that seems to be the
> direction things are heading in. Perhaps that can make this flamefest
> go away?

???

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:

> Martin Mares <mj@ucw.cz> wrote:
> 
> > Hello!
> >
> > > If there is no interest to fox well known bugs in Linux, I would need to warn
> > > people from using Linux.
> >
> > Except for mentioning some DMA related problems at the beginning of this
> > monstrous thread, you haven't shown anything which even remotely qualifies
> > as a bug.
> 
> If you forget these things, then please forget about this thread.
> 
> I mentioned:
> 
> -	ide-scsi does not do DMA correctly

Apparently no-one bothers to fix this with ide-cd supporting SG_IO, and
nobody produced any use case for other ide-*.c devices.

You'll either have to fix this yourself or wait until the day the cows
coime home.

> -	SCSI commands are bastardized on ATAPI 

You were asked for a proof but didn't provide one. If you think
otherwise, post URL or Message-ID. We're all sooooooooooooooo terrible
forgetful we don't recall your reports from 2001.

-- 
Matthias Andree

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

[Martin Mares]

Hello!

> -	SCSI commands are bastardized on ATAPI 

One more question before this thread hopefully dies out:

What do you mean by "bastardized"?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Don't take life too seriously -- you'll never get out of it alive.

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> Hello!
>
> > -	SCSI commands are bastardized on ATAPI 
>
> One more question before this thread hopefully dies out:
>
> What do you mean by "bastardized"?

I did describe this in detail before:

some drives complain about "illegal field in cdb"
with "read full toc" and "blank" while the same HW booted
with Solaris or SCO UnixWare has no problems.


Let me write a final remark:

cdrecord currently has no known Linux specific bug.

Let us comtinue to talk after the Linux kernel bugs that
prevent cdrecord from working 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 (stirring up a hornets' nest)

[Martin Mares]

Hello!

> Let me write a final remark:
> 
> cdrecord currently has no known Linux specific bug.
> 
> Let us comtinue to talk after the Linux kernel bugs that
> prevent cdrecord from working have been fixed.

OK. And in the meantime you can remove the silly warnings about
device names being unsupported.

					MM

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> Hello!
>
> > Let me write a final remark:
> > 
> > cdrecord currently has no known Linux specific bug.
> > 
> > Let us comtinue to talk after the Linux kernel bugs that
> > prevent cdrecord from working have been fixed.
>
> OK. And in the meantime you can remove the silly warnings about
> device names being unsupported.

The warnings are not silly. They could have been removed long ago
if the icd-scsi DMA bug was fixed.

So take it as it is: Linux first fixes the icd-scsi DMA bug and
then it makes sense to remove the related warning.

Jörg

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

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

[Martin Mares]

Hello!

> The warnings are not silly. They could have been removed long ago
> if the icd-scsi DMA bug was fixed.

This doesn't make sense, the usual case when the warning is printed,
that is referring to /dev/hd* directly, doesn't use ide-scsi at all.
Hence the only logical warning would be exactly the opposite: warn the
user if he uses ide-scsi, because you know it's broken.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
The number of UNIX installations has grown to 10, with more expected.  (6/72)

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:

> The warnings are not silly. They could have been removed long ago
> if the icd-scsi DMA bug was fixed.

The warnings are way off track, because

1. /dev/hd* means ide-cd which has never had the incriminated bugs,
   no matter if badly designed or not

2. you can't tell from looking at /dev/sg* or the b,t,l if the device
   node is operated by the ide-scsi or sg drivers. Both use the unified
   /dev/sg* namespace.

In fact, it makes sense to suppress the warning for /dev/hd* and ATA:
which are known good.

-- 
Matthias Andree

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

[Jan Engelhardt]

>
>The warnings are not silly. They could have been removed long ago
>if the icd-scsi DMA bug was fixed.
>
...if someone cared to fix it. This is the opensource world, and if 
someone's out for a fix, they either have to write it themselves or pay 
someone to do so.


Jan Engelhardt
-- 

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

[Luke-Jr]

On Monday 13 February 2006 16:26, Joerg Schilling wrote:
> Martin Mares <mj@ucw.cz> wrote:
> > > If there is no interest to fox well known bugs in Linux, I would need
> > > to warn people from using Linux.
> >
> > Except for mentioning some DMA related problems at the beginning of this
> > monstrous thread, you haven't shown anything which even remotely
> > qualifies as a bug.
>
> If you forget these things, then please forget about this thread.
>
> I mentioned:
>
> -	ide-scsi does not do DMA correctly

IIRC, ide-scsi is deprecated and would be removed as a fix for this bug. Note 
that ide-scsi is known to be broken in more ways than just this-- for 
example, unloading the module causes a kernel panic.

> -	SCSI commands are bastardized on ATAPI

I'm not a kernel developer, but my understanding is that they're basically 
passed through the ATAPI layer.

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

[Joerg Schilling]

Luke-Jr <luke@dashjr.org> wrote:

> > I mentioned:
> >
> > -	ide-scsi does not do DMA correctly
>
> IIRC, ide-scsi is deprecated and would be removed as a fix for this bug. Note 
> that ide-scsi is known to be broken in more ways than just this-- for 
> example, unloading the module causes a kernel panic.

A last word on that:

-	this bug is known for more than 2 years.

-	time to fix: less than 3 hours for the right person

-	I therefore expect a fix in less than a month or
	I must asume that Linux is not longer actively maintained.

Jörg

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

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

[newbiz]

Joerg Schilling a ecrit le 13.02.2006 18:40 :

> -	I therefore expect a fix in less than a month or
> 	I must asume that Linux is not longer actively maintained.

so is your brain, obviously

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

[Luke-Jr]

On Monday 13 February 2006 17:40, Joerg Schilling wrote:
> Luke-Jr <luke@dashjr.org> wrote:
> > > I mentioned:
> > >
> > > -	ide-scsi does not do DMA correctly
> >
> > IIRC, ide-scsi is deprecated and would be removed as a fix for this bug.
> > Note that ide-scsi is known to be broken in more ways than just this--
> > for example, unloading the module causes a kernel panic.
>
> A last word on that:
>
> -	this bug is known for more than 2 years.
>
> -	time to fix: less than 3 hours for the right person
>
> -	I therefore expect a fix in less than a month or
> 	I must asume that Linux is not longer actively maintained.

What does it do "wrong" anyway? IIRC, DMA in general works...
Also note that since SCSI does not support DMA, I wouldn't consider lack of 
DMA for ide-scsi a bug. Just because the underlying device is IDE and has DMA 
support doesn't mean that the SCSI layer (which has no reason for DMA) should 
use it.

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

[Joerg Schilling]

Luke-Jr <luke@dashjr.org> wrote:

> What does it do "wrong" anyway? IIRC, DMA in general works...

If you really believe that it is good practice to implement DMA in
a way so it works at some places as expected but on others not....

... then you like the Linux kernel be a junk yard :-(

Good practice is to fix _all_ related code in a project in case a bug
is identified and fixed at some place. Unfortunately this is not true
for Linux and for this reason, Linux cannot yet be called mature.


Jörg

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

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

[D. Hazelton]

On Tuesday 14 February 2006 06:13, Joerg Schilling wrote:
> Luke-Jr <luke@dashjr.org> wrote:
> > What does it do "wrong" anyway? IIRC, DMA in general works...
>
> If you really believe that it is good practice to implement DMA in
> a way so it works at some places as expected but on others not....
>
> ... then you like the Linux kernel be a junk yard :-(
>
> Good practice is to fix _all_ related code in a project in case a bug
> is identified and fixed at some place. Unfortunately this is not true
> for Linux and for this reason, Linux cannot yet be called mature.

Joerg, I think you misunderstand the problem here. The block layer itself 
supports DMA unilaterally. Some of the extended drivers that provide support 
for older hardware or, in the case of the (need I remind you) deprecated 
ide-scsi system, for an abstraction layer do not for various reasons. Whether 
that is because the device itself doesn't support DMA or if it's because the 
added complexity (in the ide-scsi case) of providing DMA for an abstraction 
layer made it nearly impossible. As the problems with ide-scsi are soon to be 
gone from main-line up-to-date kernels, I have trouble seeing why you still 
harp on this problem.

As I'm sure you know, Linux is an Open Source operating system. If you need it 
to support DMA in the ide-scsi system, then you are free to add said support. 
If you do not have the time or the skill to do so, you are also free to pay 
someone to do it for you. But as the kernel progresses through 2.6 you will 
find that most of your "bugs" are being dealt with. As a matter of fact I 
have offered to attempt to fix the problems you have with the ATAPI layer 
munging packets. As I said before, if you can provide me with the details of 
which hardware is affected and what exactly is occurring I can probably work 
on this. (And from the contents of a recent post, you can be certain I am not 
the only one interested in fixing this problem of yours)

However, if the problem is non-existant with a _modern_ kernel, then may I 
make one suggestion: remove your constant reporting of the problem.

Furthermore I have been quiet until now regarding the comments you have made 
in the source to cdrecord and libscg regarding Linux. While I appreciate that 
your software has been functional for twenty years now, I would suggest that 
you question your own motives, as it appears that your problems with Linux 
are more of a personal nature and not a technical one. Moreover I find that 
you make constant reference to "how things should have been done" but in 
looking through the Linux sources, I can find no hint that you ever touched 
the portions of the OS in question. Therefore I have to wonder if your 
abrasive manner and repeated personal attacks were not occurring even as the 
block device layer was undergoing it's last sets of rewrites and managed to 
alienate the entire crew of people working on it.

Up to this point I have attempted to be calm and civil, if not polite. However 
you preach about "good practice" and claim you will accept patches, yet in 
your stated policy you reserve the right to reject any patch on non-technical 
grounds. What's more is that you _have_ shown this to be your most common 
mode of operation, to the point of refusing to actually look at patches that 
meet the rest of the standards you provide.

I have no wish for this discussion to devolve any further, and have been 
attempting to turn it around and make it productive. Patience is something 
that I do not have in infinite quantities, however. My offers to attempt to 
fix the second of the two "major" bugs you reported stands, as does my offer 
to patch cdrecord so that it uniformly uses the b,t,l addressing scheme 
internally while allowing users to select a device node. I will let them 
stand for one week. If, at the end of that week, you have either 1) not 
provided me with the documentation I need to attempt to fix the bugs in the 
linux kernel or 2) not provided me with a written standards document on how 
code should be formatted for cdrecord patches either or both of the offers 
will be withdrawn and I will neither read nor respond to further mail from 
you.

Did I make myself clear, or should I attempt to restate that in my very rusty 
and beleagured german?

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:


> As I'm sure you know, Linux is an Open Source operating system. If you need it 
> to support DMA in the ide-scsi system, then you are free to add said support. 

It seems that you did missunderstand Linux:

I did send a fix for an important bug in 1997 and it was NOT integraded by
the Linux kernel people.

As long as the Linux project proves that Linux is not yet mature enough for 
being able to _really_ do what you propose, it makes no sense to waste time
on LKML.

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-14:

> "D. Hazelton" <dhazelton@enter.net> wrote:
> 
> 
> > As I'm sure you know, Linux is an Open Source operating system. If you need it 
> > to support DMA in the ide-scsi system, then you are free to add said support. 
> 
> It seems that you did missunderstand Linux:
> 
> I did send a fix for an important bug in 1997 and it was NOT integraded by
> the Linux kernel people.

Wow, 9 years ago. Was it for 2.0 already or still 1.2?

Does the bug persist in 2.6.16-rc3? If so, resend your fix.

> As long as the Linux project proves that Linux is not yet mature enough for 
> being able to _really_ do what you propose, it makes no sense to waste time
> on LKML.

An action speaks louder than 1000 words. When are you leaving?

-- 
Matthias Andree

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

[grundig]

El Tue, 14 Feb 2006 17:35:32 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:

> I did send a fix for an important bug in 1997 and it was NOT integraded by
> the Linux kernel people.

Many patches are rejected. Looking at the way you handle cross-platform design
for libscg is not something that surprises me....

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

[Jan Engelhardt]

>
>I did send a fix for an important bug in 1997 and it was NOT integraded by
>the Linux kernel people.
>
Resend it. I also see that some of my patches/compilefixes don't make it 
into the main tree at first time.



Jan Engelhardt
-- 

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:

> -	this bug is known for more than 2 years.
> 
> -	time to fix: less than 3 hours for the right person
> 
> -	I therefore expect a fix in less than a month or
> 	I must asume that Linux is not longer actively maintained.

The kernel jumps at Jörg's command. Film at eleven.
Where's my popcorn?

You were told that ide-scsi fixes are not a priority item,
you were shown that ide-cd works,
you were shown that /dev/hd* and /dev/sg* can share the same namespace
(see my proof-of-concept patch), so there's nothing left for you to
want.

Either fix ide-scsi yourself, or fork a few 50 € bills and contract
somebody to do it.

-- 
Matthias Andree

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

[D. Hazelton]

On Monday 13 February 2006 11:26, Joerg Schilling wrote:
> Martin Mares <mj@ucw.cz> wrote:
> > Hello!
> >
> > > If there is no interest to fox well known bugs in Linux, I would need
> > > to warn people from using Linux.
> >
> > Except for mentioning some DMA related problems at the beginning of this
> > monstrous thread, you haven't shown anything which even remotely
> > qualifies as a bug.
>
> If you forget these things, then please forget about this thread.
>
> I mentioned:
>
> -	ide-scsi does not do DMA correctly


ide-scsi is deprecated and will be removed at a later date. Any program 
relying on ide-scsi will have to be rewritten.

> -	SCSI commands are bastardized on ATAPI

identify the problem - provide a test case or two and I'll get off my lazy ass 
and see if I can't figure out what's causing the problem.

> If you like, I can give you many other Linux related bugs but it does
> not make sense unless the two bugs above are fixed.

Only one bug needs fixed. ide-scsi is not going to be in the kernel much 
longer. Although someone might find the time to fix the bugs for those people 
dependant on older kernels.

DRH

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

[Jan Engelhardt]

>
>> -	SCSI commands are bastardized on ATAPI
>
>identify the problem - provide a test case or two and I'll get off my lazy ass 
>and see if I can't figure out what's causing the problem.
>

Maybe we can put a testsuite together that sends all sorts of commands to a 
cd drive and then see with 1. which Linuxes 2. which models it happens.


Jan Engelhardt
-- 

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

[D. Hazelton]

On Tuesday 14 February 2006 03:04, Jan Engelhardt wrote:
> >> -	SCSI commands are bastardized on ATAPI
> >
> >identify the problem - provide a test case or two and I'll get off my lazy
> > ass and see if I can't figure out what's causing the problem.
>
> Maybe we can put a testsuite together that sends all sorts of commands to a
> cd drive and then see with 1. which Linuxes 2. which models it happens.
>
>
> Jan Engelhardt

Excellent idea, but since Joerg probably has all the information already I 
don't see why he can't provide it. At least that way there is some time saved 
and I won't wind up seeing my aging CDRW drive get any excessive wear.

DRH

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

[Joerg Schilling]

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

> >
> >> -	SCSI commands are bastardized on ATAPI
> >
> >identify the problem - provide a test case or two and I'll get off my lazy ass 
> >and see if I can't figure out what's causing the problem.
> >
>
> Maybe we can put a testsuite together that sends all sorts of commands to a 
> cd drive and then see with 1. which Linuxes 2. which models it happens.

You need to ask around for people with problems....
Debian had some relevent data but removed it the day I was referring to it :-(

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-14:

> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > >
> > >> -	SCSI commands are bastardized on ATAPI
> > >
> > >identify the problem - provide a test case or two and I'll get off my lazy ass 
> > >and see if I can't figure out what's causing the problem.
> > >
> >
> > Maybe we can put a testsuite together that sends all sorts of commands to a 
> > cd drive and then see with 1. which Linuxes 2. which models it happens.
> 
> You need to ask around for people with problems....
> Debian had some relevent data but removed it the day I was referring to it :-(

In other words: you cannot provide details or even prove the asserted
bug, and you are trying to shift the blame on Debian. If they no longer
have the reports, chances are the bugs have been fixed since through
Debian patches, that's their workflow.

And if you want Debian bugs, look here:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=cdrecord&archive=no&version=&dist=unstable&pend-exc=fixed&pend-exc=done&sev-exc=wishlist&sev-exc=fixed

But keep in mind only the "forwarded" or "upstream" bugs are your
business.

Besides that, I wouldn't exactly call it quality standard if you lose
important bug reports about the environment.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-14:
>
> > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> > 
> > > >
> > > >> -	SCSI commands are bastardized on ATAPI
> > > >
> > > >identify the problem - provide a test case or two and I'll get off my lazy ass 
> > > >and see if I can't figure out what's causing the problem.
> > > >
> > >
> > > Maybe we can put a testsuite together that sends all sorts of commands to a 
> > > cd drive and then see with 1. which Linuxes 2. which models it happens.
> > 
> > You need to ask around for people with problems....
> > Debian had some relevent data but removed it the day I was referring to it :-(
>
> In other words: you cannot provide details or even prove the asserted
> bug, and you are trying to shift the blame on Debian. If they no longer
> have the reports, chances are the bugs have been fixed since through
> Debian patches, that's their workflow.

In other words, you are still only trying to create voilence but 
unable/unwilling to cooperate?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-14:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> In other words, you are still only trying to create voilence but 
> unable/unwilling to cooperate?

Amusing question, isn't it you who dropped the patch (= quit
cooperation) without looking at it?

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099

So Debian didn't delete your bugs? Hm... and tomorrow you'll tell us you
never insinuated Debian deleted bugs.

Quote "This seems to be a general problem with QSI-drives, see e.g.
http://lists.debian.org/debian-user-german/2004/debian-user-german-200402/msg05143.html
which shows testimonials about failed blanking of cd-rws for QSI
CD-RW/DVD-ROM SBW-241, cdrdao succeeds."

"If you are unwilling to remove a non cdrecord related bug from the list
or if you unable to understand the background, you should ask for help
or leave the cdrecord project."
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099;msg=84

Uncle Jörg the Dictator, commander in charge of earth motion.
Fails to mention libscg code paths for Solaris and Linux differ.

I've filed a 186099 amendment to prevent fallacies there...

-- 
Matthias Andree

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

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-14:
>
> > Matthias Andree <matthias.andree@gmx.de> wrote:
> > 
> > In other words, you are still only trying to create voilence but 
> > unable/unwilling to cooperate?
>
> Amusing question, isn't it you who dropped the patch (= quit
> cooperation) without looking at it?
>
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099
>
> So Debian didn't delete your bugs? Hm... and tomorrow you'll tell us you
> never insinuated Debian deleted bugs.
>
> Quote "This seems to be a general problem with QSI-drives, see e.g.
> http://lists.debian.org/debian-user-german/2004/debian-user-german-200402/msg05143.html
> which shows testimonials about failed blanking of cd-rws for QSI
> CD-RW/DVD-ROM SBW-241, cdrdao succeeds."
>
> "If you are unwilling to remove a non cdrecord related bug from the list
> or if you unable to understand the background, you should ask for help
> or leave the cdrecord project."
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099;msg=84

If you don't know the background, stay quiet!

This bug has been moved away from Linux kernel bugs several times.
I was requesting to put the bug where it belongs....

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-14:

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

> > "If you are unwilling to remove a non cdrecord related bug from the list
> > or if you unable to understand the background, you should ask for help
> > or leave the cdrecord project."
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099;msg=84
> 
> If you don't know the background, stay quiet!

Right, hello everyone, jump at Jörg's command. One, two, ...

> This bug has been moved away from Linux kernel bugs several times.

False. It had never been assigned to the kernel.

> I was requesting to put the bug where it belongs....

I can read, thank you, and the bugreport lacks any evidence as to the
nature of the bug. "where it belongs" are typical fallacies, unless
someone invokes "in dubio pro reo", concludes it's a firmware bug and
closes it.

-- 
Matthias Andree

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

[D. Hazelton]

On Tuesday 14 February 2006 10:04, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> > >> -	SCSI commands are bastardized on ATAPI
> > >
> > >identify the problem - provide a test case or two and I'll get off my
> > > lazy ass and see if I can't figure out what's causing the problem.
> >
> > Maybe we can put a testsuite together that sends all sorts of commands to
> > a cd drive and then see with 1. which Linuxes 2. which models it happens.
>
> You need to ask around for people with problems....
> Debian had some relevent data but removed it the day I was referring to it
> :-(

As the maintainer of the cdrtools package and the author of both libscg and 
cdrecord I find it hard to believe that you do not have a log of these 
somewhere. If Debian had relevant data and removed it, then it is quite 
probable that they fixed the problem already. If that is the case, then all 
it should take to find out is making an enquiry or searching among their 
distribution specific kernel patches.

However, in the spirit of making this discussion bear useful fruit, I will 
take it upon myself to search the Debian archived bugs and see if I can find 
out the relevant data myself.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> As the maintainer of the cdrtools package and the author of both libscg and 
> cdrecord I find it hard to believe that you do not have a log of these 
> somewhere. If Debian had relevant data and removed it, then it is quite 
> probable that they fixed the problem already. If that is the case, then all 
> it should take to find out is making an enquiry or searching among their 
> distribution specific kernel patches.

I usually fix real bugs immediately after I know them.

I don't see that it makes sense to archive Linux bugs as long ad the Linux 
kernel folks are obviously not willing to fix them.

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-16:

> "D. Hazelton" <dhazelton@enter.net> wrote:
> 
> > As the maintainer of the cdrtools package and the author of both libscg and 
> > cdrecord I find it hard to believe that you do not have a log of these 
> > somewhere. If Debian had relevant data and removed it, then it is quite 
> > probable that they fixed the problem already. If that is the case, then all 
> > it should take to find out is making an enquiry or searching among their 
> > distribution specific kernel patches.
> 
> I usually fix real bugs immediately after I know them.

"Usually" is the key here. Sometimes, you refuse to fix real bugs
forever even if you're made aware of them, and rather shift the blame
on somebody else.

> I don't see that it makes sense to archive Linux bugs as long ad the Linux 
> kernel folks are obviously not willing to fix them.

Then the bugs can't have been important to you.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> > I usually fix real bugs immediately after I know them.
>
> "Usually" is the key here. Sometimes, you refuse to fix real bugs
> forever even if you're made aware of them, and rather shift the blame
> on somebody else.

Show me a single real bug that I did not fix.

> > I don't see that it makes sense to archive Linux bugs as long ad the Linux 
> > kernel folks are obviously not willing to fix them.
>
> Then the bugs can't have been important to you.

??? Id the Linux kernel is not fixed, the importance is irrelevent
unfortunately.

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-16:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > > I usually fix real bugs immediately after I know them.
> >
> > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > forever even if you're made aware of them, and rather shift the blame
> > on somebody else.
> 
> Show me a single real bug that I did not fix.

Namespace split ATA/SCSI is unfixed in 2.01.01a06.

Bogus warnings about Linux are unfixed in said version.

Bogus warnings about /dev/* are unfixed in said version.

Linux uname() detection code is broken since 2.6.10 because it assumes
fixed-width fields.

That makes four.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-16:
>
> > Matthias Andree <matthias.andree@gmx.de> wrote:
> > 
> > > > I usually fix real bugs immediately after I know them.
> > >
> > > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > > forever even if you're made aware of them, and rather shift the blame
> > > on somebody else.
> > 
> > Show me a single real bug that I did not fix.
>
> Namespace split ATA/SCSI is unfixed in 2.01.01a06.

The namne space split is a Linux kernel bug

> Bogus warnings about Linux are unfixed in said version.

Warnings related to Linux kernel bugs

> Bogus warnings about /dev/* are unfixed in said version.

Warnings related to Linux kernel bugs

> Linux uname() detection code is broken since 2.6.10 because it assumes
> fixed-width fields.

Warnings related to Linux kernel bugs


Jörg

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

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

[Martin Mares]

Hello!

> > Namespace split ATA/SCSI is unfixed in 2.01.01a06.
> 
> The namne space split is a Linux kernel bug

You are getting ridiculous. A bug against what? Against your wishes?

> > Bogus warnings about /dev/* are unfixed in said version.
> 
> Warnings related to Linux kernel bugs

Rubbish. The Linux bugs you have pointed to are in ide-scsi and opening
/dev/hd* directly is guaranteed to avoid them. The only warning which would
make sense would be if somebody USES ide-scsi, not if he avoids it.

> > Linux uname() detection code is broken since 2.6.10 because it assumes
> > fixed-width fields.
> 
> Warnings related to Linux kernel bugs

Stop parroting and read what you are replying to.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
My Wife Says I Never Listen, Or Something Like That...

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-17:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > Namespace split ATA/SCSI is unfixed in 2.01.01a06.
> 
> The namne space split is a Linux kernel bug

Define: name space := cdrecord/libscg device identifier,
specified as [transport:]bus,target,lun

It is a libscg bug, as proven before in
<http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html>

(Just so you don't get the last word.)

> > Linux uname() detection code is broken since 2.6.10 because it assumes
> > fixed-width fields.
> 
> Warnings related to Linux kernel bugs

OK. Since the bug is actually beneficial to Linux >= 2.6.10 users, I'm
not detailing. You don't need to fix it.

-- 
Matthias Andree

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

[D. Hazelton]

On Friday 17 February 2006 05:29, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> > Joerg Schilling schrieb am 2006-02-16:
> > > Matthias Andree <matthias.andree@gmx.de> wrote:
> > > > > I usually fix real bugs immediately after I know them.
> > > >
> > > > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > > > forever even if you're made aware of them, and rather shift the blame
> > > > on somebody else.
> > >
> > > Show me a single real bug that I did not fix.
> >
> > Namespace split ATA/SCSI is unfixed in 2.01.01a06.
>
> The namne space split is a Linux kernel bug

Then why have I been talking about a unification with you?

I would quote your comments on it, but since that was a private mail I will 
not do so.

> > Bogus warnings about Linux are unfixed in said version.
>
> Warnings related to Linux kernel bugs

>From what I can tell a lot of the warnings are bogus. You even go to great 
lengths to "scare" people into only using "official" versions of cdrtools.

As to that, you have sections in the code marked "Do Not Change" and "Do Not 
Remove" - I checked the GPLv2 today (the one shipped with all versions of 
cdrecord I can find) and there is nothing in that which gives you the right 
to restrict what someone else does to your code.

Call it people being polite that nobody has removed that stuff from the 
existing primary port of cdrtools.

> > Bogus warnings about /dev/* are unfixed in said version.
>
> Warnings related to Linux kernel bugs

No. There is no Kernel bug in the SG_IO via /dev/hd* implementation.
While I can gloss over most other warnings, the following seem to be scare 
tactics to me:

cdrecord: Warning: Running on Linux-2.6.12-gentoo-r6
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.

Warning: Using badly designed ATAPI via /dev/hd* interface.

> > Linux uname() detection code is broken since 2.6.10 because it assumes
> > fixed-width fields.
>
> Warnings related to Linux kernel bugs

Since when is a function that doesn't handle a value returned not the source 
of a bug?

Show me the POSIX rules that say all fields returned by uname() have to have a 
certain fixed size.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > The namne space split is a Linux kernel bug
>
> Then why have I been talking about a unification with you?
>
> I would quote your comments on it, but since that was a private mail I will 
> not do so.

????

I did not get any proposal for working on making ide-scsi work nor did 
I get a useful proposal that would explain how it might be done without
ide-scsi.


> > > Bogus warnings about Linux are unfixed in said version.
> >
> > Warnings related to Linux kernel bugs
>
> From what I can tell a lot of the warnings are bogus. You even go to great 
> lengths to "scare" people into only using "official" versions of cdrtools.

They are related to serious problems.

Jörg

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

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

[D. Hazelton]

On Monday 20 February 2006 09:59, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > The namne space split is a Linux kernel bug
> >
> > Then why have I been talking about a unification with you?
> >
> > I would quote your comments on it, but since that was a private mail I
> > will not do so.
>
> ????
>
> I did not get any proposal for working on making ide-scsi work nor did
> I get a useful proposal that would explain how it might be done without
> ide-scsi.

Don't even start. In a private exchange you stated that you had been thinking 
of mapping ATA/ATAPI devices into a "middle" bus slot to remove the need for 
the "ATA" and "ATAPI" host identifiers and to allow libscg to scan the 
ATA/ATAPI bus at the same time it scans the SCSI bus on Linux systems.

I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0 - and 
you said it was wrong and not useful. I've since asked you in another private 
mail if you have another solution I could code into the patch and don't 
expect a reply until tomorrow.

For the record, I am trying to work with you to resolve these problems, but at 
the moment the problem of unifying the scannign of the SCSI and ATA/ATAPI 
busses inside libscg in order to workaround the Kernel not providing access 
to ATA/ATAPI devices via /dev/sg* is stopped because of the problem of how to 
uniquely identify said devices and the problem with the kernel munging SCSI 
CDB's for certain devices is stopped because I don't have access to the 
hardware to see exactly what gets munged.

And since you've stated that the machine on which you could reproduce the 
problem died 3 years ago, I have to assume that the problem may have been 
fixed in the ensuing time period.

> > > > Bogus warnings about Linux are unfixed in said version.
> > >
> > > Warnings related to Linux kernel bugs
> >
> > From what I can tell a lot of the warnings are bogus. You even go to
> > great lengths to "scare" people into only using "official" versions of
> > cdrtools.
>
> They are related to serious problems.

Really? From what I've seen you mark sections "You cannot change this" to stop 
people from removing those warnings. In fact, there is code in cdrecord that 
relates to "bugs" in distribution patched versions that most likely do not 
exist anymore. "Serious problems", though? Seems you just love SCSI, fell in 
love with ide-scsi and can't let it go. I've been using cdrecord for more 
than six years now, the last two on a system without _ide-scsi_ and have yet 
to have a problem - so either the problems you call serious are not serious 
enough or I was lucky to build a system from spare parts that managed to 
dodge all those problems. By applying Occams razor, I find that the first is 
likely true.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

>
> Don't even start. In a private exchange you stated that you had been thinking 
> of mapping ATA/ATAPI devices into a "middle" bus slot to remove the need for 
> the "ATA" and "ATAPI" host identifiers and to allow libscg to scan the 
> ATA/ATAPI bus at the same time it scans the SCSI bus on Linux systems.
>
> I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0 - and 
> you said it was wrong and not useful. I've since asked you in another private 
> mail if you have another solution I could code into the patch and don't 
> expect a reply until tomorrow.

And I explained you why this is inapropriate. So what is your peoblem?

Jörg

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

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

[D. Hazelton]

On Tuesday 21 February 2006 04:55, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > Don't even start. In a private exchange you stated that you had been
> > thinking of mapping ATA/ATAPI devices into a "middle" bus slot to remove
> > the need for the "ATA" and "ATAPI" host identifiers and to allow libscg
> > to scan the ATA/ATAPI bus at the same time it scans the SCSI bus on Linux
> > systems.
> >
> > I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0
> > - and you said it was wrong and not useful. I've since asked you in
> > another private mail if you have another solution I could code into the
> > patch and don't expect a reply until tomorrow.
>
> And I explained you why this is inapropriate. So what is your peoblem?

And I asked if _you_ had a solution that I could then implement. Apparently 
you are no intelligent enough, or have your head too far up your ass, to 
understand a simple question. Goodbye, Joerg - you are now in my killfile.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> On Tuesday 21 February 2006 04:55, Joerg Schilling wrote:
> > "D. Hazelton" <dhazelton@enter.net> wrote:
> > > Don't even start. In a private exchange you stated that you had been
> > > thinking of mapping ATA/ATAPI devices into a "middle" bus slot to remove
> > > the need for the "ATA" and "ATAPI" host identifiers and to allow libscg
> > > to scan the ATA/ATAPI bus at the same time it scans the SCSI bus on Linux
> > > systems.
> > >
> > > I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0
> > > - and you said it was wrong and not useful. I've since asked you in
> > > another private mail if you have another solution I could code into the
> > > patch and don't expect a reply until tomorrow.
> >
> > And I explained you why this is inapropriate. So what is your peoblem?
>
> And I asked if _you_ had a solution that I could then implement. Apparently 

And I did tell you what I was thinking off, so where is your problem?

Don't you remember anymore that I did reply on 30th January to a mail 
from Albert Cahalan that the dirty cheap mapping is not useful?


> you are no intelligent enough, or have your head too far up your ass, to 
> understand a simple question. Goodbye, Joerg - you are now in my killfile.

So even you are just one of these trolls that are unable to have a tachical 
based discussion and at some time start with personal infrimngements?

Tell me why I did spend so much time replying to your mail if you are not able
to to what you did promise before?

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-20:

> I did not get any proposal for working on making ide-scsi work

The suggestion was not to insist on it.

> nor did I get a useful proposal that would explain how it might be
> done without ide-scsi.

The existing code works good enough for the cdrecord "consumer" of your
libscg library when the scary warnings are dropped.

Problems with new hardware can be fixed as use cases and hardware appear
and real problems show up. Given that the Linux device layering is
documented as passing unknown ioctls to lower layers to see if they can
deal with them, there shouldn't be many issues.

If you're unware of problems with new hardware or inventions, nobody can
seriously blame you, just stuff "last found working with Linux 2.6.y"
into some readme file and that's it.

> > From what I can tell a lot of the warnings are bogus. You even go to great 
> > lengths to "scare" people into only using "official" versions of cdrtools.
> 
> They are related to serious problems.

They are related to problems that you encountered with a SUSE version
ages ago, else your commentary in the code is insufficient.

You ought to check once a year or once every two years if the problems
you are so heftily complain about persist in supported versions; for
instance, any SUSE warnings related to 8.X versions can be removed and
replaced by a note that you don't intend to support operating systems
that are no longer supported by their respective vendor. You don't have
support contracts with distributors, so they aren't obliged to tell you
"hey we fixed that bug" -- and if you asked, you'd probably get a useful
answers.

I'm applying the same policy to my software (no support on unsupported
distributions) and it hasn't caused a single complaint yet, the only
comments I received were apologies for having to use obsolete systems
for some reasons, with people being rather modest and cooperative, like
offering testing, accounts on those systems and so on. Pretty reasonable
all in all IMO.

-- 
Matthias Andree

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

[Edgar Toernig]

Joerg Schilling wrote:
>
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > > I usually fix real bugs immediately after I know them.
> >
> > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > forever even if you're made aware of them, and rather shift the blame
> > on somebody else.
> 
> Show me a single real bug that I did not fix.

Well, the kill(getppid(), SIG_INT)s in cdda2wav still cause system
reboots when run as root.

Ciao, ET.

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

[Joerg Schilling]

Edgar Toernig <froese@gmx.de> wrote:

> Joerg Schilling wrote:
> >
> > Matthias Andree <matthias.andree@gmx.de> wrote:
> > 
> > > > I usually fix real bugs immediately after I know them.
> > >
> > > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > > forever even if you're made aware of them, and rather shift the blame
> > > on somebody else.
> > 
> > Show me a single real bug that I did not fix.
>
> Well, the kill(getppid(), SIG_INT)s in cdda2wav still cause system
> reboots when run as root.

Isn't this unfair?

Heiko did not work on cdda2wav since ~ 2.5 years.

You may have luck in the future as I received the SCCS history for cdda2wav
3 days ago, but there are other more important things to do first......

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-17:

> > Well, the kill(getppid(), SIG_INT)s in cdda2wav still cause system
> > reboots when run as root.
> 
> Isn't this unfair?

No. You asked for bugs, you got bugs.
You ship cdda2wav, you take the blame.

> Heiko did not work on cdda2wav since ~ 2.5 years.

Does that alleviate the bug? No.

-- 
Matthias Andree

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

[D. Hazelton]

On Thursday 16 February 2006 13:06, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> > > I usually fix real bugs immediately after I know them.
> >
> > "Usually" is the key here. Sometimes, you refuse to fix real bugs
> > forever even if you're made aware of them, and rather shift the blame
> > on somebody else.
>
> Show me a single real bug that I did not fix.

At this point I, personally, am not aware of any.  However, after a careful 
review of libscg in preparation for the patch I promised you, I can see that 
it would be possible for the code to be rewritten so that just the linux 
section contains the various workarounds that might be needed.

With your refusal to even consider doing that I can see where some people get 
this idea (I myself was under this exact same belief until I began my code 
review in preparation for the proposed patch).

I am unsure if you refused to provide OS specific workarounds for known bugs 
in order to keep the code orthogonal,  or if you had another reason. But with 
the division of the various operating system specific pieces of libscg into 
seperate source files it doesn't make sense.

> > > I don't see that it makes sense to archive Linux bugs as long ad the
> > > Linux kernel folks are obviously not willing to fix them.
> >
> > Then the bugs can't have been important to you.
>
> ??? Id the Linux kernel is not fixed, the importance is irrelevent
> unfortunately.

Of the two bugs you've reported, one only exists in a deprecated and soon to 
be removed module. I will try to fix the other one as soon as you can provide 
me with enough data that I can see exactly what is getting messed up where.

As to you wanting to be able to read the SCSI status byte and the actual size 
of the completed DMA... Those parts of the kernel are as close to a blackbox 
to me as any code gets. Perhaps you could provide information or ideas on how 
it could be managed?

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> At this point I, personally, am not aware of any.  However, after a careful 
> review of libscg in preparation for the patch I promised you, I can see that 
> it would be possible for the code to be rewritten so that just the linux 
> section contains the various workarounds that might be needed.
>
> With your refusal to even consider doing that I can see where some people get 
> this idea (I myself was under this exact same belief until I began my code 
> review in preparation for the proposed patch).

I am not refusing useful changes but I of course refuse to apply changes that
will or even may cause problems in the future.

cdrtools and libscg are a serious project and are maintained in a way that tries
to _plan_ all interfaces in a way that allows to upgrade interfaces for at 
least 10 years without a need for incompatible changes.


> I am unsure if you refused to provide OS specific workarounds for known bugs 
> in order to keep the code orthogonal,  or if you had another reason. But with 
> the division of the various operating system specific pieces of libscg into 
> seperate source files it doesn't make sense.

I like to have things orthogonal, but it seems that most people in LKML
do not understand implicit constraints from requiring orthogobality.


> Of the two bugs you've reported, one only exists in a deprecated and soon to 
> be removed module. I will try to fix the other one as soon as you can provide 
> me with enough data that I can see exactly what is getting messed up where.

Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If ide-scsi
ir removed, then a clean and orthogonal way of accessing SCSI in a generic
way is removed from Linux. If Linux does nto care about orthogonality of 
interfaces, this is a problem of the people who are responbile for the related
interfaces.


> As to you wanting to be able to read the SCSI status byte and the actual size 
> of the completed DMA... Those parts of the kernel are as close to a blackbox 
> to me as any code gets. Perhaps you could provide information or ideas on how 
> it could be managed?

This is another construction side in Linux.

In 1997, I did cleanly write dowen what exact features are missing to allow 
Linux to be used to _develop_ SCSI user space programs. I did even send a patch
for sg.c to the Linux folks. This patch extends the sg SCSI Generic interface
in a source AND binary, up AND downwards compatible way.

This patch has been rejected for unknown reasons and the fact that the source 
code fond in official Linux release has been changed in an incompatible way, it 
is impossible to apply it now.


My patch did enable sg.c to return more error/status information back to the 
user (e.g. the SCSI status byte) _and_ it defined a way to return DMA residual
counts to the user. If Linux still does not even have the DMA residual count 
internally available, this is a proof that nobody with sufficient SCSI know how
is willing to work on the Linux SCSI layer.

Jörg

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

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

[Martin Mares]

Hello!

> Sorry, the way to access SCSI generic via /dev/hd* is deprecated.

By whom?

> ir removed, then a clean and orthogonal way of accessing SCSI in a generic
> way is removed from Linux. If Linux does nto care about orthogonality of 
> interfaces, this is a problem of the people who are responbile for the related
> interfaces.

You open any SCSI device, you do SG_IO on it. What is non-orthogonal in that?

Yes, I agree with you that it's hard to do device discovery, but discovering
devices is completely orthogonal to doing I/O in them and it's also not
a problem specific to SCSI devices at all. Hence we want to find a general
solution suitable for *all* devices and that's what sysfs, udev and HAL are
for. They might have some rough edges yet, but they definitely solve the
right problem.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"In theory, practice and theory are the same, but in practice they are different." -- Larry McVoy

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

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> > ir removed, then a clean and orthogonal way of accessing SCSI in a generic
> > way is removed from Linux. If Linux does nto care about orthogonality of 
> > interfaces, this is a problem of the people who are responbile for the related
> > interfaces.
>
> You open any SCSI device, you do SG_IO on it. What is non-orthogonal in that?

I encourage you to read the previous mails, this has been explained for more 
than ten times now.....

Jörg

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

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

[Martin Mares]

Hello!

> I encourage you to read the previous mails, this has been explained for more 
> than ten times now.....

Maybe the problem lies in nobody except you considering it an explanation.

E.g., your theory about Linux breaking POSIX has been disproved pretty quickly.

Feel free to consider the Linux interface silly or badly designed, that's
everybody's right, but please keep in mind that as long as you are unable to point
to any *real* problems with it, it's just your opinion not shared by most of
the other people, including the maintainers of the said subsystems, so it's
hardly a reason for changing the interface.

Sorry, but although I value your experience with CD writing very much,
I don't think you are the right person to decide on what the naming of devices
in Linux will look like, exactly because it's a problem with much broader
context than just SCSI devices.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"God doesn't play dice."   -- Albert Einstein

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

[sean]

On Fri, 17 Feb 2006 12:41:58 +0100
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> In 1997, I did cleanly write dowen what exact features are missing to allow 
> Linux to be used to _develop_ SCSI user space programs. I did even send a patch
> for sg.c to the Linux folks. This patch extends the sg SCSI Generic interface
> in a source AND binary, up AND downwards compatible way.
> 
> This patch has been rejected for unknown reasons and the fact that the source 
> code fond in official Linux release has been changed in an incompatible way, it 
> is impossible to apply it now.

Shock!  1997 patch no longer applies cleanly in 2006!  Alert the media!

Seriously though, this is exactly why I think Linux should start accepting
patches from crazy people without question or review.   It's much easier to
deal with whatever cruft is applied by the patch than it is to endure the 
multi year manic tirades of such individuals who have their egos bruised as
a result of rejection.

Sean

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

[Jan Engelhardt]

>> Of the two bugs you've reported, one only exists in a deprecated and soon to 
>> be removed module. I will try to fix the other one as soon as you can provide 
>> me with enough data that I can see exactly what is getting messed up where.
>
>Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If ide-scsi
>ir removed, then a clean and orthogonal way of accessing SCSI in a generic
>way is removed from Linux. If Linux does nto care about orthogonality of 
>interfaces, this is a problem of the people who are responbile for the related
>interfaces.
>

So what you want is to be able to use write() on a <sg-compatible> device 
rather than doing SG_IO ioctl() on <any> device?


Jan Engelhardt
-- 

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

[Joerg Schilling]

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

> >Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If ide-scsi
> >ir removed, then a clean and orthogonal way of accessing SCSI in a generic
> >way is removed from Linux. If Linux does nto care about orthogonality of 
> >interfaces, this is a problem of the people who are responbile for the related
> >interfaces.
> >
>
> So what you want is to be able to use write() on a <sg-compatible> device 
> rather than doing SG_IO ioctl() on <any> device?

This kind of disinformation is what constantly puts fuel into the fire....

Are you a victim of the firebugs in this list?

Jörg

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

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

[D. Hazelton]

On Friday 17 February 2006 16:52, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> > >Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If
> > > ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI
> > > in a generic way is removed from Linux. If Linux does nto care about
> > > orthogonality of interfaces, this is a problem of the people who are
> > > responbile for the related interfaces.
> >
> > So what you want is to be able to use write() on a <sg-compatible> device
> > rather than doing SG_IO ioctl() on <any> device?
>
> This kind of disinformation is what constantly puts fuel into the fire....
>
> Are you a victim of the firebugs in this list?

Joerg, it may not be perfect, but it does work. If you're still worried about 
how a few of the currently unmaintained devices still don't support SG_IO 
then I suggest you find someone to take maintainership.

I have neither the skill nor the want to do it or I would, just to see if it 
quieted you down any.

BTW, make it more than a couple of weeks for the patch I mentioned for libscg 
- I still need a response about my suggestion to use the BTL addresses Linux 
provides as the addresses passed around from libscg to cdrecord.

DRH

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

[D. Hazelton]

On Friday 17 February 2006 06:41, you wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > At this point I, personally, am not aware of any.  However, after a
> > careful review of libscg in preparation for the patch I promised you, I
> > can see that it would be possible for the code to be rewritten so that
> > just the linux section contains the various workarounds that might be
> > needed.
> >
> > With your refusal to even consider doing that I can see where some people
> > get this idea (I myself was under this exact same belief until I began my
> > code review in preparation for the proposed patch).
>
> I am not refusing useful changes but I of course refuse to apply changes
> that will or even may cause problems in the future.

sysfs is in the kernel and I doubt the contents of /sys/block will change any. 
By reading that directory you can find _all_ existing ATA/ATAPI devices as 
well as all existing SCSI devices.

As a useful change I could patch your ATA/ATAPI scanning code in libscg to do 
that - it would certainly clean up the code. Furthermore, as was pointed out 
by Albert Cahalan, Linux does provide b,t,l addresses for ATA/ATAPI devices - 
available from a simple stat of the device node.

With him having checked a quick hack of code I tossed together to check the 
idea I can even provide code to you that proves this point. 

If you are amenable to a patch that does nothing more than fix the ATA/ATAPI 
scanning code on Linux so it functions properly then I will go ahead and 
create such.

> cdrtools and libscg are a serious project and are maintained in a way that
> tries to _plan_ all interfaces in a way that allows to upgrade interfaces
> for at least 10 years without a need for incompatible changes.

Noted. However even if I do create said patch, I'm more than 90% certain you 
won't even take a look at it.

And if you are worried about the future of your code...

Why do you use the autoconf system in such a nonstandard way? It's scripts are 
portable to all POSIX compliant systems. From what I have seen they would 
remove most of the problems you have and would allow for the code to be 
ported to other operating systems even faster.

(Yes, I'm aware of the DOS/Windows case - but I did say all POSIX compliant 
systems, didn't I? Most packages provide prebuilt stuff for compiling for 
DOS/Windows anyway.)
 
> > I am unsure if you refused to provide OS specific workarounds for known
> > bugs in order to keep the code orthogonal,  or if you had another reason.
> > But with the division of the various operating system specific pieces of
> > libscg into seperate source files it doesn't make sense.
>
> I like to have things orthogonal, but it seems that most people in LKML
> do not understand implicit constraints from requiring orthogobality.

This is why I'm asking why you don't include such workarounds. As far as I can 
see all you do in your code is complain about things with somewhat pointless 
warnings and do minimal work to get around the flaws you complain about.

> > Of the two bugs you've reported, one only exists in a deprecated and soon
> > to be removed module. I will try to fix the other one as soon as you can
> > provide me with enough data that I can see exactly what is getting messed
> > up where.
>
> Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If
> ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI in a
> generic way is removed from Linux. If Linux does nto care about
> orthogonality of interfaces, this is a problem of the people who are
> responbile for the related interfaces.

Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5 
series kernel - at the same time ide-scsi was deprecated access via SG_IO 
on /dev/hd* is the new method and not deprecated.

I do agree that it would be _easier_ if Linux had tied the ATA/ATAPI transport 
layer into the SCSI bus code for generic SCSI access, but in Linux there is a 
clear distinction that exists because the IDE/ATA/ATAPI drivers can exist on 
the system entirely without the SCSI system even being built.

The reason for this, at least to me, is to allow people building Linux kernels 
for embedded devices to turn off everything that isn't needed.

> > As to you wanting to be able to read the SCSI status byte and the actual
> > size of the completed DMA... Those parts of the kernel are as close to a
> > blackbox to me as any code gets. Perhaps you could provide information or
> > ideas on how it could be managed?
>
> This is another construction side in Linux.
>
> In 1997, I did cleanly write dowen what exact features are missing to allow
> Linux to be used to _develop_ SCSI user space programs. I did even send a
> patch for sg.c to the Linux folks. This patch extends the sg SCSI Generic
> interface in a source AND binary, up AND downwards compatible way.

Okay. I haven't gone through the mailing list archives to look at this patch. 
There are any number of reasons for it being rejected. One of them is that it 
got lost in the traffic on LKML.

>
> My patch did enable sg.c to return more error/status information back to
> the user (e.g. the SCSI status byte) _and_ it defined a way to return DMA
> residual counts to the user. If Linux still does not even have the DMA
> residual count internally available, this is a proof that nobody with
> sufficient SCSI know how is willing to work on the Linux SCSI layer.

I can see how the residual DMA count information might be impossible to get at 
- the Linux memory allocator has been changed quite a bit over the course of 
the past nine years.

However reading the SCSI status byte should still be possible. I have 
absolutely _no_ familiarity with that section of the kernel so I wont even 
attempt to create such a patch but you should be familiar enough with whats 
going on to create said patch.

So, in the end, I have to ask - why don't you create that patch?

DRH

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

[Matthias Andree]

On Fri, 17 Feb 2006, D. Hazelton wrote:

> Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5 
> series kernel - at the same time ide-scsi was deprecated access via SG_IO 
> on /dev/hd* is the new method and not deprecated.

This is all information that libscg does not need to know. There are
only two models:

1. the old sg2 model before SG_IO was available, was to use write() and
read() on a /dev/sg* node.

2. the new sg3 model is do SG_IO on any device node no matter if /dev/hd,
/dev/sg or perhaps /dev/foobaz42 next year. /dev/sg* happened to be the
first to implement this, others followed suit, and more to come.

-- 
Matthias Andree

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > cdrtools and libscg are a serious project and are maintained in a way that
> > tries to _plan_ all interfaces in a way that allows to upgrade interfaces
> > for at least 10 years without a need for incompatible changes.
>
> Noted. However even if I do create said patch, I'm more than 90% certain you 
> won't even take a look at it.

If your code will have similar relevence than the code from Matthias, you are 
obviously true.


> Why do you use the autoconf system in such a nonstandard way? It's scripts are 
> portable to all POSIX compliant systems. From what I have seen they would 
> remove most of the problems you have and would allow for the code to be 
> ported to other operating systems even faster.

I do use autoconf in the only senseful way.

And if you did have a look at the schily makefile system you would know that
it provides protability to more plaforms than you get from using an GNU
autoconf the way the GNU people tell you.

If you like best portability, you need to use my version of autoconf inside the
schily makefile system and you need to use my smake instead of GNU make.

So my conclusion is that you did not understand portability. All my software is 
using layered portability and if you did take a closer look at the few FSF people 
who know what they are talking about, you would find that e.g. Paul Eggert 
recently started to silently imitate my portability methods.....


> (Yes, I'm aware of the DOS/Windows case - but I did say all POSIX compliant 
> systems, didn't I? Most packages provide prebuilt stuff for compiling for 
> DOS/Windows anyway.)

???? There are many problems with portability.

One problem is that GNU make is not working in a useful way on many patforms
that are listed to be working. GNU make is unmaintained since many years and
a serious bug I reported in 1999 still has not been fixed.

So for portability, I was forced to make my smake more portable than any other
open source make program. The automake features (don't confuse this with the
ill designed and wrongly named "automake" program from the FSF) of smake
allow to compile my software on nearly any unknown platform.


> > I like to have things orthogonal, but it seems that most people in LKML
> > do not understand implicit constraints from requiring orthogobality.
>
> This is why I'm asking why you don't include such workarounds. As far as I can 
> see all you do in your code is complain about things with somewhat pointless 
> warnings and do minimal work to get around the flaws you complain about.

Well what I did first was to try to have a discussion with the Linux people in 
order to avoid the problems introduced by Linux.

When it turned out that the related people are not interested, all I could do
was to print warnings.


> > Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If
> > ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI in a
> > generic way is removed from Linux. If Linux does nto care about
> > orthogonality of interfaces, this is a problem of the people who are
> > responbile for the related interfaces.
>
> Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5 
> series kernel - at the same time ide-scsi was deprecated access via SG_IO 
> on /dev/hd* is the new method and not deprecated.

Any system that is worse than another one is deprecated.

If people on LKML believe it is OK not to abide promises and if they don't have 
the vision that /dev/hd* only serves some limited applications but not the need
of generic applications like libscg, this is a LKML problem.


> I do agree that it would be _easier_ if Linux had tied the ATA/ATAPI transport 
> layer into the SCSI bus code for generic SCSI access, but in Linux there is a 
> clear distinction that exists because the IDE/ATA/ATAPI drivers can exist on 
> the system entirely without the SCSI system even being built.

The SCSI glue layer on Solaris is less than 50 kB. I did mention more than once 
that a uniquely layered system could save a lot of code by avoiding to 
implement things more than once.

> The reason for this, at least to me, is to allow people building Linux kernels 
> for embedded devices to turn off everything that isn't needed.

Well, on such a system, a /dev/hd driver is not needed for the CD-ROM.
A SCSI disk driver would be sufficient.


> > My patch did enable sg.c to return more error/status information back to
> > the user (e.g. the SCSI status byte) _and_ it defined a way to return DMA
> > residual counts to the user. If Linux still does not even have the DMA
> > residual count internally available, this is a proof that nobody with
> > sufficient SCSI know how is willing to work on the Linux SCSI layer.
>
> I can see how the residual DMA count information might be impossible to get at 
> - the Linux memory allocator has been changed quite a bit over the course of 
> the past nine years.

Most other OS provide this information.

Is Linux really that underdeveloped for not being able to provide DMA residual 
counts?


Jörg

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

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

[Martin Mares]

Hello!

> The SCSI glue layer on Solaris is less than 50 kB. I did mention more than once 
> that a uniquely layered system could save a lot of code by avoiding to 
> implement things more than once.

Could you please stop parrotting this again and again, at least as long as you
are unable to point to any duplicated code?

> Is Linux really that underdeveloped for not being able to provide DMA residual 
> counts?

How is it related to the discussion about interfaces?

So far, whenever you were asked to support your assertions (dynamic device
naming violating POSIX, duplicated code, your warning which is printed when
not using ide-scsi while the bugs you were speaking about occur only _with_
ide-scsi and so on), you have ignored the request and started either repeating
the same or diverting the attention to completely unrelated problems (like
above).

Unless you wish to stop spreading your demagogy and write facts instead,
I recommend you to shut up and this is my last mail in this discussion.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"This quote has been selected randomly. Really." -- M. Ulrichs

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-20:

> > Noted. However even if I do create said patch, I'm more than 90% certain you 
> > won't even take a look at it.
> 
> If your code will have similar relevence than the code from Matthias, you are 
> obviously true.

Well, it is irrelevant to _you_ because it proves you're wrong. At
least, not a single objective argument WRT bugs in side the code have
surfaced.

> One problem is that GNU make is not working in a useful way on many patforms
> that are listed to be working. GNU make is unmaintained since many years and
> a serious bug I reported in 1999 still has not been fixed.

The so-called "serious" bug is a purely cosmetic complaint about
non-existant .d files.

> > Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5 
> > series kernel - at the same time ide-scsi was deprecated access via SG_IO 
> > on /dev/hd* is the new method and not deprecated.
> 
> Any system that is worse than another one is deprecated.

Hm. Schilling's applications are worse than others by printing
meaningless warnings...

> If people on LKML believe it is OK not to abide promises and if they don't have 

Your delusions about who "promise"d something to you...

> Well, on such a system, a /dev/hd driver is not needed for the CD-ROM.
> A SCSI disk driver would be sufficient.

Not your business.

-- 
Matthias Andree

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

[D. Hazelton]

On Monday 20 February 2006 09:51, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > cdrtools and libscg are a serious project and are maintained in a way
> > > that tries to _plan_ all interfaces in a way that allows to upgrade
> > > interfaces for at least 10 years without a need for incompatible
> > > changes.
> >
> > Noted. However even if I do create said patch, I'm more than 90% certain
> > you won't even take a look at it.
>
> If your code will have similar relevence than the code from Matthias, you
> are obviously true.
>
> > Why do you use the autoconf system in such a nonstandard way? It's
> > scripts are portable to all POSIX compliant systems. From what I have
> > seen they would remove most of the problems you have and would allow for
> > the code to be ported to other operating systems even faster.
>
> I do use autoconf in the only senseful way.
>
> And if you did have a look at the schily makefile system you would know
> that it provides protability to more plaforms than you get from using an
> GNU autoconf the way the GNU people tell you.
>
> If you like best portability, you need to use my version of autoconf inside
> the schily makefile system and you need to use my smake instead of GNU
> make.
>
> So my conclusion is that you did not understand portability. All my
> software is using layered portability and if you did take a closer look at
> the few FSF people who know what they are talking about, you would find
> that e.g. Paul Eggert recently started to silently imitate my portability
> methods.....

I have taken a second look and it does appear that you are correct. But I 
still have some doubts (none that I can quantify) - would it not make sense 
to also use automake?

> > (Yes, I'm aware of the DOS/Windows case - but I did say all POSIX
> > compliant systems, didn't I? Most packages provide prebuilt stuff for
> > compiling for DOS/Windows anyway.)
>
> ???? There are many problems with portability.
>
> One problem is that GNU make is not working in a useful way on many
> patforms that are listed to be working. GNU make is unmaintained since many
> years and a serious bug I reported in 1999 still has not been fixed.

Apparently true - the version of gmake I use is four years old. Too bad almost 
everything on my system relies on the quirks and features of gmake...

<snip>
> > > I like to have things orthogonal, but it seems that most people in LKML
> > > do not understand implicit constraints from requiring orthogobality.
> >
> > This is why I'm asking why you don't include such workarounds. As far as
> > I can see all you do in your code is complain about things with somewhat
> > pointless warnings and do minimal work to get around the flaws you
> > complain about.
>
> Well what I did first was to try to have a discussion with the Linux people
> in order to avoid the problems introduced by Linux.
>
> When it turned out that the related people are not interested, all I could
> do was to print warnings.

Dodged the question there, didn't you? My question here goes unanswered. 
Rather than putting workarounds in your code for the bugs you complain about 
you've just put warnings in the code. Seems that that breaks orthagonality in 
favor of complaining.

> > > Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If
> > > ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI
> > > in a generic way is removed from Linux. If Linux does nto care about
> > > orthogonality of interfaces, this is a problem of the people who are
> > > responbile for the related interfaces.
> >
> > Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the
> > 2.5 series kernel - at the same time ide-scsi was deprecated access via
> > SG_IO on /dev/hd* is the new method and not deprecated.
>
> Any system that is worse than another one is deprecated.

It seems we have different definitions of deprecated. The definition you are 
using is incompatable with the definition of the word as used in software 
development. In software development the word means "Old and in the process 
of being removed from use".

<snip>

> > I do agree that it would be _easier_ if Linux had tied the ATA/ATAPI
> > transport layer into the SCSI bus code for generic SCSI access, but in
> > Linux there is a clear distinction that exists because the IDE/ATA/ATAPI
> > drivers can exist on the system entirely without the SCSI system even
> > being built.
>
> The SCSI glue layer on Solaris is less than 50 kB. I did mention more than
> once that a uniquely layered system could save a lot of code by avoiding to
> implement things more than once.

Does that glue code comprise the proposed SATL system? Recently I've come 
across those whitepapers and opened a discussion about it on LKML.

> > The reason for this, at least to me, is to allow people building Linux
> > kernels for embedded devices to turn off everything that isn't needed.
>
> Well, on such a system, a /dev/hd driver is not needed for the CD-ROM.
> A SCSI disk driver would be sufficient.

and? The ATA/IDE drivers are more compact that requiring the _entire_ SCSI 
transport code and the specific SCSI driver for a device.

> > > My patch did enable sg.c to return more error/status information back
> > > to the user (e.g. the SCSI status byte) _and_ it defined a way to
> > > return DMA residual counts to the user. If Linux still does not even
> > > have the DMA residual count internally available, this is a proof that
> > > nobody with sufficient SCSI know how is willing to work on the Linux
> > > SCSI layer.
> >
> > I can see how the residual DMA count information might be impossible to
> > get at - the Linux memory allocator has been changed quite a bit over the
> > course of the past nine years.
>
> Most other OS provide this information.
>
> Is Linux really that underdeveloped for not being able to provide DMA
> residual counts?

No idea. All I said was that with the changes to how the memory allocator 
works I can see where it might be impossible to get such information. I don't 
think it is, though. What I think is that the developers of the allocator and 
the DMA systems just forgot to include such a capability.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > I do use autoconf in the only senseful way.
> >
> > And if you did have a look at the schily makefile system you would know
> > that it provides protability to more plaforms than you get from using an
> > GNU autoconf the way the GNU people tell you.
> >
> > If you like best portability, you need to use my version of autoconf inside
> > the schily makefile system and you need to use my smake instead of GNU
> > make.
> >
> > So my conclusion is that you did not understand portability. All my
> > software is using layered portability and if you did take a closer look at
> > the few FSF people who know what they are talking about, you would find
> > that e.g. Paul Eggert recently started to silently imitate my portability
> > methods.....
>
> I have taken a second look and it does appear that you are correct. But I 
> still have some doubts (none that I can quantify) - would it not make sense 
> to also use automake?

The way autoconf should be used acording to the autoconf manual is already
wrong and the creation of just another makefile generator, that even is 
incorrectly called "automake", is definitely a step into the wrong direction.

David Korn recently discovered that my makefile system basically does the same 
as his system. But while he need to write a "make successor" "nmake", I was able 
to do the same using "make".

The ideas that I am sucessfully using since more than 12 years is what researchers
did start around 1985. 

GNU autoconf (used the documented way) or "automake" is trying to do things in 
a way that did look apropriate in the 1970s. 

People should look at better solutions (like my makefile system) that do not 
need to modify makefiles in place but rather implement object oriented design
that depend on a "table like" master makefile and for this reason allow to 
concurrently compile on _all_ supported platforms on the same source tree
in case that the tree is mounted via NFS.


> > One problem is that GNU make is not working in a useful way on many
> > patforms that are listed to be working. GNU make is unmaintained since many
> > years and a serious bug I reported in 1999 still has not been fixed.
>
> Apparently true - the version of gmake I use is four years old. Too bad almost 
> everything on my system relies on the quirks and features of gmake...

Try to use my smake to find out whether you use non-portable constructs.
Smake warns you about the most common problems in makefiles.


> > When it turned out that the related people are not interested, all I could
> > do was to print warnings.
>
> Dodged the question there, didn't you? My question here goes unanswered. 
> Rather than putting workarounds in your code for the bugs you complain about 
> you've just put warnings in the code. Seems that that breaks orthagonality in 
> favor of complaining.

The more rotten Linux interfaces become, the harder it is to implement work
arounds.





> > The SCSI glue layer on Solaris is less than 50 kB. I did mention more than
> > once that a uniquely layered system could save a lot of code by avoiding to
> > implement things more than once.
>
> Does that glue code comprise the proposed SATL system? Recently I've come 
> across those whitepapers and opened a discussion about it on LKML.

??? Solaris supports SAS decives, is this your question?


> > Well, on such a system, a /dev/hd driver is not needed for the CD-ROM.
> > A SCSI disk driver would be sufficient.
>
> and? The ATA/IDE drivers are more compact that requiring the _entire_ SCSI 
> transport code and the specific SCSI driver for a device.

This is an unproven statement.


> > > I can see how the residual DMA count information might be impossible to
> > > get at - the Linux memory allocator has been changed quite a bit over the
> > > course of the past nine years.
> >
> > Most other OS provide this information.
> >
> > Is Linux really that underdeveloped for not being able to provide DMA
> > residual counts?
>
> No idea. All I said was that with the changes to how the memory allocator 
> works I can see where it might be impossible to get such information. I don't 
> think it is, though. What I think is that the developers of the allocator and 
> the DMA systems just forgot to include such a capability.

It seems that Linux is not used for developing SCSI applications, otherwise
I would not be the only person complaining about this missing feature.

I am using SunOS/Solaris for my SCSI programs since 1985, so I don't have 
problem. It seems that Linux users don't like to know if their software fails.



Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-21:

> Try to use my smake to find out whether you use non-portable constructs.
> Smake warns you about the most common problems in makefiles.

To complement this, running Solaris' /usr/{ccs,xpg4}/bin/make and BSD's
portable make (just bootstrap www.pkgsrc.org to obtain "bmake" on Linux)
is probably a much better approach since it tests real-world make
implementations rather than an artificial and not widely available local
flavor.

> > and? The ATA/IDE drivers are more compact that requiring the _entire_ SCSI 
> > transport code and the specific SCSI driver for a device.
> 
> This is an unproven statement.

Proof sketch: Compile Linux without SCSI subsystem and see if
cdrecord dev=/dev/hdc still works.

> It seems that Linux is not used for developing SCSI applications, otherwise
> I would not be the only person complaining about this missing feature.

The other scenario is that nobody but you has problems
developing/porting SCSI applications to Linux, or nobody but you has
problems formulating useful bug reports. Holding on to 1999 bug reports
that you cannot dig up doesn't work without paid support contract,
as you've seen.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-21:
>
> > Try to use my smake to find out whether you use non-portable constructs.
> > Smake warns you about the most common problems in makefiles.
>
> To complement this, running Solaris' /usr/{ccs,xpg4}/bin/make and BSD's
> portable make (just bootstrap www.pkgsrc.org to obtain "bmake" on Linux)
> is probably a much better approach since it tests real-world make
> implementations rather than an artificial and not widely available local
> flavor.

Thank you for proving that you are completely uninformed!

Smake is able to compile a _lot_ more real world applications than BSD make.

This is because smake is POSIX compliant while BSD make is not.

Smake is even able to compile more free software that depends on non-portable
GNU make extensions than Sun make does.

And smake warns about makefiles that only work because they depend on Bugs
found in Sun make or GNU make (e.g. because they try to expand '$*' or '$<'
in explicit target rules).

Jörg

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

[OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-21:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > Joerg Schilling schrieb am 2006-02-21:
> >
> > > Try to use my smake to find out whether you use non-portable constructs.
> > > Smake warns you about the most common problems in makefiles.
> >
> > To complement this, running Solaris' /usr/{ccs,xpg4}/bin/make and BSD's
> > portable make (just bootstrap www.pkgsrc.org to obtain "bmake" on Linux)
> > is probably a much better approach since it tests real-world make
> > implementations rather than an artificial and not widely available local
> > flavor.
> 
> Thank you for proving that you are completely uninformed!

You just proved your incapability to extract the meaning of five simple
lines. If you're incapable to understand simple statements like these,
shut your head.

The meaning is, just especially for you so you can excuse yourself, and
in PowerPoint style to be easy on your time:

- run Solaris' /usr/{ccs,xpg4}/bin/make
  to find out if your Makefile is portable

- run BSD's portable make (that's a proper name)
  to find out if your Makefile is portable

- testing real-world make programs with Makefiles will find out much
  more reliably if non-portable constructs are used.

Examples: smake -W -posix (version 1.2a34, the newest available) doesn't
warn of include foo.d (works with said make tools, but isn't POSIX
compliant), and doesn't warn of -include foo.d (works with smake, GNU
make, BSD make, but not SUN make).

This is pretty strong evidence that smake is insufficient as
Makefile portability validator, which substantiates my recommendation to
test real-world make(1) programs rather than smake to find out the
portability characteristics.

And now repeat your insult I were uninformed again,
that's your quickest way to criminal prosecution.
You said good-bye to factual discussion long ago.

-- 
Matthias Andree

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

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

> > Thank you for proving that you are completely uninformed!
>
> You just proved your incapability to extract the meaning of five simple
> lines. If you're incapable to understand simple statements like these,
> shut your head.

You just did strengthen the impression you gave with your mail before....
although - after a long time - you at least did again make yourself busy
with the topic in a mail....

> The meaning is, just especially for you so you can excuse yourself, and
> in PowerPoint style to be easy on your time:
>
> - run Solaris' /usr/{ccs,xpg4}/bin/make
>   to find out if your Makefile is portable

Solaris make does not write useful error messages in case of non-portable 
makefiles.

> - run BSD's portable make (that's a proper name)
>   to find out if your Makefile is portable

BSD make may be portable (although I am sure that smake comppiles/runs
on much more platforms) but it is not POSIX compliant. The fact that a
makefile does not work with BSD make does not prove anything as only simpile
makefiles are handeled the same way as POSIX based make programs do.

After we fixed the bug with pattern macro expansions in FreeBSDs make,
it turned out that cc -o some/dir/to/file.o file.c is handled completely
different from UNIX make programs. This makes it impossible to use FreeBSD
make for e.g. the Schily makefilesystem.


> - testing real-world make programs with Makefiles will find out much
>   more reliably if non-portable constructs are used.

??? smake _is_ a real world make program and if you rate POSIX compliance
and portability, it will outstrip all other known make programs.


> Examples: smake -W -posix (version 1.2a34, the newest available) doesn't
> warn of include foo.d (works with said make tools, but isn't POSIX
> compliant), and doesn't warn of -include foo.d (works with smake, GNU
> make, BSD make, but not SUN make).

While smake is much closer to POSIX than e.g. GNU make (proof by looking at
#ifdefs related to DOS like OS <CR/NL> instead of just <NL> in the source code
and find that smake has no single exception for DOS in the parser while GNU
make still does not work correctly with all makefiles). But in a single point, 
the GNU make maintainers are correct:

	A POSIX make is not able to compile portable applications, so we
	need to make the make program portable and add features.

Smake does exactly this. It adds the needed features (see "man makefiles" &
"man makerules") from Sun ideas in 1986 and implements them in a portable way.
The needed features are pattern matching expansion and "include".

> This is pretty strong evidence that smake is insufficient as
> Makefile portability validator, which substantiates my recommendation to
> test real-world make(1) programs rather than smake to find out the
> portability characteristics.

The other make programs I know are worse then smake and they are usually not
portable themself. Note that I don't like to use the technology from the 1970s
as GNU "automake" does.

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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-22:

> > - run Solaris' /usr/{ccs,xpg4}/bin/make
> >   to find out if your Makefile is portable
> 
> Solaris make does not write useful error messages in case of non-portable 
> makefiles.

Sun Microsystems do not advertise their make tool as Makefile
portability validator.  Note the difference: each tool is held to its
own standards.

> > - run BSD's portable make (that's a proper name)
> >   to find out if your Makefile is portable
> 
> BSD make may be portable (although I am sure that smake comppiles/runs
> on much more platforms) but it is not POSIX compliant.

Please look up the term "proper name" before continuing. BSD make does
not mention "POSIX" a single time in its documentation.

> After we fixed the bug with pattern macro expansions in FreeBSDs make,
> it turned out that cc -o some/dir/to/file.o file.c is handled completely
> different from UNIX make programs. This makes it impossible to use FreeBSD
> make for e.g. the Schily makefilesystem.

If BSD make is not UNIX make, then what is?

That FreeBSD's /usr/bin/make doesn't like your Makefiles doesn't matter,
GNU and Schily make are available in the ports collection, either is fine.

> > - testing real-world make programs with Makefiles will find out much
> >   more reliably if non-portable constructs are used.
> 
> ??? smake _is_ a real world make program and if you rate POSIX compliance
> and portability, it will outstrip all other known make programs.

You still haven't got my point. Last attempt to explain:

smake isn't sufficient to judge if a "Makefile" is portable to all
widespread make programs, particularly does it not warn about non-POSIX
syntax that SUN make or BSD make reject, as shown in my previous message.

> > This is pretty strong evidence that smake is insufficient as
> > Makefile portability validator, which substantiates my recommendation to
> > test real-world make(1) programs rather than smake to find out the
> > portability characteristics.
> 
> The other make programs I know are worse then smake and they are usually not
> portable themself. Note that I don't like to use the technology from the 1970s
> as GNU "automake" does.

Your dislike for GNU make is widely documented, yet only based on
cosmetic bugs. Try if the "remake" guys fix the concerns you have had
about GNU make. remake is a GNU make spinoff with usability
improvements, getting rid of meaningless "Makefile:5: foo.d: No such
file or directory" should be well within reach. Dig through your
sent-mail folder for the explanation you sent me a year or two ago.
See <http://bashdb.sourceforge.net/remake/>

I'm redirecting answers off-list.
This isn't linux-kernel stuff any more.

BTW, your Message-ID is nonconformant (it doesn't use a qualified domain
name, "burner" isn't appropriate), please fix your mailer.

-- 
Matthias Andree

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-22:
>
> > > - run Solaris' /usr/{ccs,xpg4}/bin/make
> > >   to find out if your Makefile is portable
> > 
> > Solaris make does not write useful error messages in case of non-portable 
> > makefiles.
>
> Sun Microsystems do not advertise their make tool as Makefile
> portability validator.  Note the difference: each tool is held to its
> own standards.

I do not advertize smake as makefile validator either.

It would help a lot, if people on LKML would not repeatedly impute me things I 
never said....


Smake helps to find non-portable code, this is something completely different!

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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-23:

> I do not advertize smake as makefile validator either.

In your message from Monday 10:44 Central European Time you advertise
smake as warning about most non-portable constructs...

-- 
Matthias Andree

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-23:
>
> > I do not advertize smake as makefile validator either.
>
> In your message from Monday 10:44 Central European Time you advertise
> smake as warning about most non-portable constructs...

So you read the correct text and still try to reverse it?

Jörg

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

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-23:

> So you read the correct text and still try to reverse it?

No. You advertised smake in spite of my recommendation to test Makefiles
with real-world make implementations, and now you're ranting about a
particular make implementation.

1. Stick to the topic please.

2. Stop Cc:ing me on this topic, I'm not interested in discussing make
   programs beyond showing that smake isn't up to its own standards, and
   that I already did.

-- 
Matthias Andree

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-23:
>
> > So you read the correct text and still try to reverse it?
>
> No. You advertised smake in spite of my recommendation to test Makefiles
> with real-world make implementations, and now you're ranting about a
> particular make implementation.

So you still read the correct text and try to reverse it?

Jörg

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

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[D. Hazelton]

On Thursday 23 February 2006 07:15, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> > Joerg Schilling schrieb am 2006-02-22:
> > > > - run Solaris' /usr/{ccs,xpg4}/bin/make
> > > >   to find out if your Makefile is portable
> > >
> > > Solaris make does not write useful error messages in case of
> > > non-portable makefiles.
> >
> > Sun Microsystems do not advertise their make tool as Makefile
> > portability validator.  Note the difference: each tool is held to its
> > own standards.
>
> I do not advertize smake as makefile validator either.
>
> It would help a lot, if people on LKML would not repeatedly impute me
> things I never said....
>
>
> Smake helps to find non-portable code, this is something completely
> different!

Umm - Joerg, you just stepped on your own toes there. A makefile validator 
does exactly that - helps people find non-portable code. You're fighting a 
losing battle when you claim one thing then say something that proves it 
false.

DRH

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > Smake helps to find non-portable code, this is something completely
> > different!
>
> Umm - Joerg, you just stepped on your own toes there. A makefile validator 
> does exactly that - helps people find non-portable code. You're fighting a 
> losing battle when you claim one thing then say something that proves it 
> false.

Wrong: a CD box with Suse or Redhat Linux may act as a door stop.

Does this make it a doorstop?

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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[D. Hazelton]

On Thursday 23 February 2006 11:56, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > Smake helps to find non-portable code, this is something completely
> > > different!
> >
> > Umm - Joerg, you just stepped on your own toes there. A makefile
> > validator does exactly that - helps people find non-portable code. You're
> > fighting a losing battle when you claim one thing then say something that
> > proves it false.
>
> Wrong: a CD box with Suse or Redhat Linux may act as a door stop.
>
> Does this make it a doorstop?

If you decide to use it as such, yes. I have actually done such in the past, 
since I needed to find some use for the box once the media was removed.

And anyway, you did state, as pointed out by someone else, that "smake may be 
used as a Makefile validator" Since you advertise such a fact - that it works 
as a Makefile validator - does that not make it such?

I realize you'll just deny it and don't know why I bother even looking in the 
folder your mails get sorted into. Maybe I just have a masochistic streak...

DRH

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Herbert Poetzl]

On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote:
> ??? smake _is_ a real world make program and if you rate POSIX compliance
> and portability, it will outstrip all other known make programs.

does anybody (except for the author, of course) use
smake for building their stuff? just curious ..

best,
Herbert

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[linux-os (Dick Johnson)]

On Thu, 23 Feb 2006, Herbert Poetzl wrote:

> On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote:
>> ??? smake _is_ a real world make program and if you rate POSIX compliance
>> and portability, it will outstrip all other known make programs.
>
> does anybody (except for the author, of course) use
> smake for building their stuff? just curious ..
>
> best,
> Herbert

The author wrote it so he is likely to use it. It claims to
have compatible make-files so the source-code tree should
be just fine.

I don't know who would waste their time making another 'make'
program, but I guess the author of smake has lots of time
on his hands!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
\x1a\x04

****************************************************************
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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

"linux-os \(Dick Johnson\)" <linux-os@analogic.com> wrote:

>
> I don't know who would waste their time making another 'make'
> program, but I guess the author of smake has lots of time
> on his hands!

Who would waste his time with something like GNU make that is unmaintained
since more than 6 years?

If I need a bugfix in smake, I can do this in a few hours.
This is impossible with GNU make....

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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Herbert Poetzl]

On Thu, Feb 23, 2006 at 05:35:07PM +0100, Joerg Schilling wrote:
> "linux-os \(Dick Johnson\)" <linux-os@analogic.com> wrote:
> 
> >
> > I don't know who would waste their time making another 'make'
> > program, but I guess the author of smake has lots of time
> > on his hands!
> 
> Who would waste his time with something like GNU make that is
> unmaintained since more than 6 years?
> 
> If I need a bugfix in smake, I can do this in a few hours.
> This is impossible with GNU make....

just tried with GNU make, did work here within minutes :)

best,
Herbert

> 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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

Herbert Poetzl <herbert@13thfloor.at> wrote:

> > Who would waste his time with something like GNU make that is
> > unmaintained since more than 6 years?
> > 
> > If I need a bugfix in smake, I can do this in a few hours.
> > This is impossible with GNU make....
>
> just tried with GNU make, did work here within minutes :)

If you can fix things in GNU make within minutes, please fix the
bug that causes GNU make to complain about missing include files.

This is a self non-compliance as GNU make applies all so far known rules
on any other object before trying to use them (e.g. try to check out Makefile
from SCCS before complaining that Makefiles is missing).

If you need the correct algorithm, look into the smake source...

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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

Herbert Poetzl <herbert@13thfloor.at> wrote:

> On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote:
> > ??? smake _is_ a real world make program and if you rate POSIX compliance
> > and portability, it will outstrip all other known make programs.
>
> does anybody (except for the author, of course) use
> smake for building their stuff? just curious ..

Many people use smake on platforms where there is no other
sufficiently compliant make program.

As GNU make incorrectly states to run on many plaforms, there are 
a lot of people who suffer from the fact that GNU make is not maintained
since > 6 years.

Note that I did make bug reports against GNU make that have been accepted as 
bugs but never 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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Tim Walberg]

On 02/23/2006 16:48 +0100, Joerg Schilling wrote:
>>	Herbert Poetzl <herbert@13thfloor.at> wrote:
>>	
>>	> On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote:
>>	> > ??? smake _is_ a real world make program and if you rate POSIX compliance
>>	> > and portability, it will outstrip all other known make programs.
>>	>
>>	> does anybody (except for the author, of course) use
>>	> smake for building their stuff? just curious ..
>>	
>>	Many people use smake on platforms where there is no other
>>	sufficiently compliant make program.
>>	
>>	As GNU make incorrectly states to run on many plaforms, there are 
>>	a lot of people who suffer from the fact that GNU make is not maintained
>>	since > 6 years.
>>	

Hmmm... from the GNU Make web page:

	Version 3.80 (stable) released on 2002-10-04 00:00:00.000

Seems to me that's slightly less than 6 years, but then I was never
that great at math... Maybe I missed something....



-- 
twalberg@mindspring.com

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

Tim Walberg <twalberg@mindspring.com> wrote:

>
> Hmmm... from the GNU Make web page:
>
> 	Version 3.80 (stable) released on 2002-10-04 00:00:00.000
>
> Seems to me that's slightly less than 6 years, but then I was never
> that great at math... Maybe I missed something....

And why are the accepted bugs from 1999 not yet 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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Tim Walberg]

On 02/23/2006 17:57 +0100, Joerg Schilling wrote:
>>	Tim Walberg <twalberg@mindspring.com> wrote:
>>	
>>	>
>>	> Hmmm... from the GNU Make web page:
>>	>
>>	> 	Version 3.80 (stable) released on 2002-10-04 00:00:00.000
>>	>
>>	> Seems to me that's slightly less than 6 years, but then I was never
>>	> that great at math... Maybe I missed something....
>>	
>>	And why are the accepted bugs from 1999 not yet fixed?
>>	

'accepted "bugs" not being fixed' is not equivalent to 'package is
not being maintained'... at least not in my admittedly meager grasp
of logic...



-- 
twalberg@mindspring.com

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

Tim Walberg <twalberg@mindspring.com> wrote:

> >>	> Hmmm... from the GNU Make web page:
> >>	>
> >>	> 	Version 3.80 (stable) released on 2002-10-04 00:00:00.000
> >>	>
> >>	> Seems to me that's slightly less than 6 years, but then I was never
> >>	> that great at math... Maybe I missed something....
> >>	
> >>	And why are the accepted bugs from 1999 not yet fixed?
> >>	
>
> 'accepted "bugs" not being fixed' is not equivalent to 'package is
> not being maintained'... at least not in my admittedly meager grasp
> of logic...

They told me that fixing would take "a while". If you believe that
"a while" is 20 years, then you seem to live in a different universe then I do.

A

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Tim Walberg]

On 02/23/2006 18:32 +0100, Joerg Schilling wrote:
>>	Tim Walberg <twalberg@mindspring.com> wrote:
>>	
>>	> >>	> Hmmm... from the GNU Make web page:
>>	> >>	>
>>	> >>	> 	Version 3.80 (stable) released on 2002-10-04 00:00:00.000
>>	> >>	>
>>	> >>	> Seems to me that's slightly less than 6 years, but then I was never
>>	> >>	> that great at math... Maybe I missed something....
>>	> >>	
>>	> >>	And why are the accepted bugs from 1999 not yet fixed?
>>	> >>	
>>	>
>>	> 'accepted "bugs" not being fixed' is not equivalent to 'package is
>>	> not being maintained'... at least not in my admittedly meager grasp
>>	> of logic...
>>	
>>	They told me that fixing would take "a while". If you believe that
>>	"a while" is 20 years, then you seem to live in a different universe then I do.
>>	

Indeed... I had already concluded that. It now seems that in
your universe, the time span between 1999 and 2006 is on
the order of 20 years, which seems to be a factor of nearly
3 over what it is in my universe (either that, or it's not
2006 where you are, but rather 2019...).


-- 
twalberg@mindspring.com

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Jan Engelhardt]

>>>	They told me that fixing would take "a while". If you believe that
>>>	"a while" is 20 years, then you seem to live in a different universe then I do.
>
>Indeed... I had already concluded that. It now seems that in
>your universe, the time span between 1999 and 2006 is on
>the order of 20 years, which seems to be a factor of nearly
>3 over what it is in my universe (either that, or it's not
>2006 where you are, but rather 2019...).
>

<sarcasm>That explains why Solaris is so much better.</sarcasm>

But when Linux gets to 2019, it will rule compared to the current
Solaris 2019.



Jan Engelhardt
-- 

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

Tim Walberg <twalberg@mindspring.com> wrote:

> >>	> 'accepted "bugs" not being fixed' is not equivalent to 'package is
> >>	> not being maintained'... at least not in my admittedly meager grasp
> >>	> of logic...
> >>	
> >>	They told me that fixing would take "a while". If you believe that
> >>	"a while" is 20 years, then you seem to live in a different universe then I do.
> >>	
>
> Indeed... I had already concluded that. It now seems that in
> your universe, the time span between 1999 and 2006 is on
> the order of 20 years, which seems to be a factor of nearly
> 3 over what it is in my universe (either that, or it's not
> 2006 where you are, but rather 2019...).

I don't know in which universe you live, but in my universe software that does 
not fix severe bugs after 7 years or does not publish a new version at least every 
2-3 years is called deas and unmaintained. Both applies to GNU make.

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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[David Weinehall]

On Fri, Feb 24, 2006 at 11:09:39AM +0100, Joerg Schilling wrote:
> Tim Walberg <twalberg@mindspring.com> wrote:
> 
> > >>	> 'accepted "bugs" not being fixed' is not equivalent to 'package is
> > >>	> not being maintained'... at least not in my admittedly meager grasp
> > >>	> of logic...
> > >>	
> > >>	They told me that fixing would take "a while". If you believe that
> > >>	"a while" is 20 years, then you seem to live in a different universe then I do.
> > >>	
> >
> > Indeed... I had already concluded that. It now seems that in
> > your universe, the time span between 1999 and 2006 is on
> > the order of 20 years, which seems to be a factor of nearly
> > 3 over what it is in my universe (either that, or it's not
> > 2006 where you are, but rather 2019...).
> 
> I don't know in which universe you live, but in my universe software
> that does not fix severe bugs after 7 years or does not publish a new
> version at least every 2-3 years is called deas and unmaintained. Both
> applies to GNU make.

Uhm, the version of GNU make in Debian (3.81beta4) was released
12 December 2005; I wouldn't call that dead (or unmaintained).


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[David Weinehall]

On Sat, Feb 25, 2006 at 06:44:10PM +0100, David Weinehall wrote:
> On Fri, Feb 24, 2006 at 11:09:39AM +0100, Joerg Schilling wrote:
> > Tim Walberg <twalberg@mindspring.com> wrote:
> > 
> > > >>	> 'accepted "bugs" not being fixed' is not equivalent to 'package is
> > > >>	> not being maintained'... at least not in my admittedly meager grasp
> > > >>	> of logic...
> > > >>	
> > > >>	They told me that fixing would take "a while". If you believe that
> > > >>	"a while" is 20 years, then you seem to live in a different universe then I do.
> > > >>	
> > >
> > > Indeed... I had already concluded that. It now seems that in
> > > your universe, the time span between 1999 and 2006 is on
> > > the order of 20 years, which seems to be a factor of nearly
> > > 3 over what it is in my universe (either that, or it's not
> > > 2006 where you are, but rather 2019...).
> > 
> > I don't know in which universe you live, but in my universe software
> > that does not fix severe bugs after 7 years or does not publish a new
> > version at least every 2-3 years is called deas and unmaintained. Both
> > applies to GNU make.
> 
> Uhm, the version of GNU make in Debian (3.81beta4) was released
> 12 December 2005; I wouldn't call that dead (or unmaintained).

Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.

Yeah, very unmaintained and dead upstream...


Regards: David
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

David Weinehall <tao@acc.umu.se> wrote:

> > Uhm, the version of GNU make in Debian (3.81beta4) was released
> > 12 December 2005; I wouldn't call that dead (or unmaintained).
>
> Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
>
> Yeah, very unmaintained and dead upstream...

None of the bugs I did report has 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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Sam Vilain]

Joerg Schilling wrote:
>>>Uhm, the version of GNU make in Debian (3.81beta4) was released
>>>12 December 2005; I wouldn't call that dead (or unmaintained).
>>Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
>>Yeah, very unmaintained and dead upstream...
> None of the bugs I did report has been fixed.

Just because a project doesn't fix every bug does not mean it is dead.

That aside, are your bugs listed on

   http://savannah.gnu.org/bugs/?group=make

?

Sam.

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[David Weinehall]

On Tue, Feb 28, 2006 at 07:47:58PM +0100, Joerg Schilling wrote:
> David Weinehall <tao@acc.umu.se> wrote:
> 
> > > Uhm, the version of GNU make in Debian (3.81beta4) was released
> > > 12 December 2005; I wouldn't call that dead (or unmaintained).
> >
> > Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
> >
> > Yeah, very unmaintained and dead upstream...
> 
> None of the bugs I did report has been fixed.

Well, the bug you complain most about is about spewing of some
warnings for something completely harmless.  I know of another
certain set of software that spews unnecessary and annoying
warnings.  Those haven't been removed for despite complaints for
several years either.  Does this mean that cdrecord is an unmaintained
piece of software that's dead upstream?


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Sam Vilain]

David Weinehall wrote:
>>>>12 December 2005; I wouldn't call that dead (or unmaintained).
>>>Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
>>>Yeah, very unmaintained and dead upstream...
>>None of the bugs I did report has been fixed.
> Well, the bug you complain most about is about spewing of some
> warnings for something completely harmless.  I know of another
> certain set of software that spews unnecessary and annoying
> warnings.  Those haven't been removed for despite complaints for
> several years either.  Does this mean that cdrecord is an unmaintained
> piece of software that's dead upstream?

This "cdrecord" package doesn't even support recording DVDs!  DVD 
writers have been around for so long, and the technology is so similar 
you would think that the author would implement the feature.  The users 
sure must be asking for it.

However it still seems to be being updated but not co-operating with the 
community or releasing new important features ... looks like we've got a 
piece of software that's UNdead upstream.

Sam.

Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Joerg Schilling]

David Weinehall <tao@acc.umu.se> wrote:

> On Tue, Feb 28, 2006 at 07:47:58PM +0100, Joerg Schilling wrote:
> > David Weinehall <tao@acc.umu.se> wrote:
> > 
> > > > Uhm, the version of GNU make in Debian (3.81beta4) was released
> > > > 12 December 2005; I wouldn't call that dead (or unmaintained).
> > >
> > > Oh, and as an update, 3.81rc1 was release on the 19th of February 2006.
> > >
> > > Yeah, very unmaintained and dead upstream...
> > 
> > None of the bugs I did report has been fixed.
>
> Well, the bug you complain most about is about spewing of some
> warnings for something completely harmless.  I know of another
> certain set of software that spews unnecessary and annoying
> warnings.  Those haven't been removed for despite complaints for
> several years either.  Does this mean that cdrecord is an unmaintained
> piece of software that's dead upstream?

If you do not understand the diffeence between a useful warning (as with 
cdrecord) and a warning that is a result of a severe bug caused by incorrect
make file handling (as in GNU make) you are obviously  wrong here.

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: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest))

[Matthias Andree]

Joerg Schilling schrieb am 2006-03-01:

> If you do not understand the diffeence between a useful warning (as with 
> cdrecord) and a warning that is a result of a severe bug caused by incorrect
> make file handling (as in GNU make) you are obviously  wrong here.

Continued offenses, rather than substantiating your claims.

This cosmetic GNU make bug that you've been ranting about for years,
which isn't a warning, has not, to my knowledge, caused any code to be
miscompiled. If you think otherwise, then you'll need to provide the GNU
make maintainers with such information so they are aware of the
severity.

However, until you can substantiate your claims, it's just Schilling's
usually offensive ranting and not a make "bug". Besides that, you can
just use "-include" to suppress the message. It even works in smake and
BSD make ...

-- 
Matthias Andree

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

[D. Hazelton]

On Tuesday 21 February 2006 04:44, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > I do use autoconf in the only senseful way.
> > >
<snip>
> > > The SCSI glue layer on Solaris is less than 50 kB. I did mention more
> > > than once that a uniquely layered system could save a lot of code by
> > > avoiding to implement things more than once.
> >
> > Does that glue code comprise the proposed SATL system? Recently I've come
> > across those whitepapers and opened a discussion about it on LKML.
>
> ??? Solaris supports SAS decives, is this your question?

SAS? No. To quote you quite frequently - RTFM. SATL is an entire system, 
similar to the old ide-scsi module, that sits on top of the SCSI and ATA 
interfaces and provides the capacity to access any disk device on the system 
using SCSI commands.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > > Does that glue code comprise the proposed SATL system? Recently I've come
> > > across those whitepapers and opened a discussion about it on LKML.
> >
> > ??? Solaris supports SAS decives, is this your question?
>
> SAS? No. To quote you quite frequently - RTFM. SATL is an entire system, 

Please read again your text I was responding to..... It was Solaris related 
and you did not mention Linux here.

> similar to the old ide-scsi module, that sits on top of the SCSI and ATA 
> interfaces and provides the capacity to access any disk device on the system 
> using SCSI commands.

If this is a ide-scsi replacement, everything would be fine.

When is it available?


Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-22:

> "D. Hazelton" <dhazelton@enter.net> wrote:

> > similar to the old ide-scsi module, that sits on top of the SCSI and ATA 
> > interfaces and provides the capacity to access any disk device on the system 
> > using SCSI commands.
> 
> If this is a ide-scsi replacement, everything would be fine.

That doesn't matter: your policy is to support older kernels, and by the
time it will become available there will still be 2.6.13, .14, .15
kernels around that don't have SAT, so you will need to have code that
works well with 2.6.15 anyhow if you are to comply with your own
intentions.

-- 
Matthias Andree

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-13:

> So you like to prove that it makes not sense to talk to LKML people?

Wrong. It does not make sense to keep talking about issues that were
refused, such as providing stable b,t,l device mapping, or violating
layering requirements that you are so fond of.

Such a violation might be making libscg the core and arranging the
kernel around it.

-- 
Matthias Andree

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

[D. Hazelton]

On Monday 13 February 2006 09:29, Joerg Schilling wrote:
> Sam Vilain <sam@vilain.net> wrote:
> > Joerg Schilling wrote:
> > >>    My system is clueless, too! If I write a CD before plugging my
> > >>USB storage device, my CD writer is on 0,0,0. If I plug my USB
> > >>storage device *before* doing any access, my cdwriter is on 1,0,0.
> > >>Pretty stable.
> > >
> > > You are referring to a conceptional problem in the Linux kernel.
> > > If you are unhappy with this, send a bug report to the related
> > > people.
> > > This does not belong to libscg.
> >
> > Jörg,
> >
> > Technically, you may have a point[*1*].
> >
> > However, no matter how correct someone is, if they act like a complete
> > dork, they're not going to be listened to.
>
> This is why I have less and less intrest in listening to most of the
> people who are around here.
>
> They are either technically uninformed, personal offensive or obviously
> not interested in a solution.

Joerg, if anyone involved in this entire discussion can be accused of being 
personally offensive, it's you.  As to "technically uninformed" remember, you 
are still human and there is always someone smarter. I've seen that 
"technically uninformed" line used by to many people who didn't want to 
change their viewpoint.

And you seem to have missed the point here - he was giving you a hint that you 
should at least try to be civil. I have limited capacity for that myself when 
dealing with people that have offended me, but I am trying to keep a civil 
tone in these communications nonetheless.

DRH

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

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> And you seem to have missed the point here - he was giving you a hint that you 
> should at least try to be civil. I have limited capacity for that myself when 
> dealing with people that have offended me, but I am trying to keep a civil 
> tone in these communications nonetheless.

I am just trying to follow the "rules" on this list, this is _not_
a civilized list :-(

Jörg

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

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

[Alexander Samad]

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

On Fri, Feb 10, 2006 at 12:49:30PM +0100, DervishD wrote:
>     Hi Joerg :)
> 
>  * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> > Martin Mares <mj@ucw.cz> wrote:
> > > > This is why the mapping engine is in the Linux adoption part of
> > > > libscg. It maps the non-stable device <-> /dev/sg* relation to a
> > > > stable b,t,l address.
> > >
> > > Nonsense. The b,t,l addresses are NOT stable (at least for transports
> > 
> > Dou you like to verify that you have no clue on SCSI?
> 
>     My system is clueless, too! If I write a CD before plugging my
> USB storage device, my CD writer is on 0,0,0. If I plug my USB
> storage device *before* doing any access, my cdwriter is on 1,0,0.
> Pretty stable.

Had exactly the same problem with firewire and usb devices, depending on
the order of the loading of the kernel modules it all changes!

> 
>     But of course, I could made all of the above stable by using
> udev. But then the /dev/sg mapping will be stable, too. I can't see
> why the three random numbers are more stable than /dev/sg. By the
> way, I don't have any SCSI host adapter in my system.
> 
>     And please, Joerg, be more respectful when answering. It doesn't
> cost money and people will likely respect you, too.
> 
>     Ra?l N??ez de Arenas Coronado
> 
> -- 
> Linux Registered User 88736 | http://www.dervishd.net
> http://www.pleyades.net & http://www.gotesdelluna.net
> It's my PC and I'll cry if I want to... RAmen!
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

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

[Joerg Schilling]

Alexander Samad <alex@samad.com.au> wrote:

> On Fri, Feb 10, 2006 at 12:49:30PM +0100, DervishD wrote:
> >     Hi Joerg :)
> > 
> >  * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> > > Martin Mares <mj@ucw.cz> wrote:
> > > > > This is why the mapping engine is in the Linux adoption part of
> > > > > libscg. It maps the non-stable device <-> /dev/sg* relation to a
> > > > > stable b,t,l address.
> > > >
> > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports
> > > 
> > > Dou you like to verify that you have no clue on SCSI?
> > 
> >     My system is clueless, too! If I write a CD before plugging my
> > USB storage device, my CD writer is on 0,0,0. If I plug my USB
> > storage device *before* doing any access, my cdwriter is on 1,0,0.
> > Pretty stable.
>
> Had exactly the same problem with firewire and usb devices, depending on
> the order of the loading of the kernel modules it all changes!

This is a deficite of the Linux kernel model. You don't have similar
problems on Solaris.

Jörg

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

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

[Lennart Sorensen]

On Mon, Feb 13, 2006 at 03:33:06PM +0100, Joerg Schilling wrote:
> This is a deficite of the Linux kernel model. You don't have similar
> problems on Solaris.

Here is something I have wondered about:

If solaris assigns consistent device entries to a device that is
hotplugged each time it is connected, which is certainly something that
can be implemented, then how many such devices can it handle before it
runs out of room for new devices?

After all I could theoretically have 100000 usb and firewire cd-rw
drives.  What if I was to plug each one in one at a time in turn.  Would
it deal with that?  What kind of references would I end up with for them
by the time I hit number 99999?  Do I end up with device 99999,0,0 in
cdrecord/libscg?

At some point you have to give up on old devices or you could end up
having to keep an index the whole universe.

Len Sorensen

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

[D. Hazelton]

On Monday 13 February 2006 09:33, Joerg Schilling wrote:
<snip>
> > >     My system is clueless, too! If I write a CD before plugging my
> > > USB storage device, my CD writer is on 0,0,0. If I plug my USB
> > > storage device *before* doing any access, my cdwriter is on 1,0,0.
> > > Pretty stable.
> >
> > Had exactly the same problem with firewire and usb devices, depending on
> > the order of the loading of the kernel modules it all changes!
>
> This is a deficite of the Linux kernel model. You don't have similar
> problems on Solaris.

Joerg, there is no doubt that you are a talented programmer, but you seem 
lacking in some social graces. I don't believe I am alone in finding it 
personally offensive that you insist on preaching about how wonderful Solaris 
is on a mailing list dedicated to another operating system.

I am asking nicely this one time, but will you please stop preaching about how 
great Solaris is?

DRH

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

[Jan Engelhardt]

>> >     My system is clueless, too! If I write a CD before plugging my
>> > USB storage device, my CD writer is on 0,0,0. If I plug my USB
>> > storage device *before* doing any access, my cdwriter is on 1,0,0.
>> > Pretty stable.
>>
>> Had exactly the same problem with firewire and usb devices, depending on
>> the order of the loading of the kernel modules it all changes!
>
>This is a deficite of the Linux kernel model. You don't have similar
>problems on Solaris.
>
Hm, did not you just outline that on Solaris, new devices always get a new 
ID?


Jan Engelhardt
-- 

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

[Jan Engelhardt]

>> >> >Please explain me:
>> >> >
>> >> >-	how to use /dev/hd* in order to scan an image from a scanner
>> >> >-	how to use /dev/hd* in order to talk to a CPU device
>> >> >-	how to use /dev/hd* in order to talk to a tape device
>> >> >-	how to use /dev/hd* in order to talk to a printer
>> >> >-	how to use /dev/hd* in order to talk to a jukebox
>> >> >-	how to use /dev/hd* in order to talk to a graphical device
>> >> >
>> >> With /dev/sg, this was possible?
>> >
>> >Of course!
>> >
>> But you need to open the correct /dev/sg[0-9] too, don't you?
>> (otherwise cdrecord would set the jukebox on fire)
>
>This is why the mapping engine is in the Linux adoption part of
>libscg. It maps the non-stable device <-> /dev/sg* relation to a
>stable b,t,l address.
>
Right. The question was rather like this:
Say we have our non-stable /dev/sr0 mapping to /dev/sg0, and it has got BTL 
1,1,0. Now, if the user starts `cdrecord -dev=1,1,0`,
`ls -l /proc/$(pidof -s cdrecord)/fd/` should show (and in fact did when I 
used ide-scsi back then) /dev/sg0, right?

If so, what's wrong with just opening /dev/sg0 directly (as per user 
request, i.e. cdrecord -dev=/dev/sg0) and sending the scsi commands down 
the fd?


Jan Engelhardt
-- 

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

[Joerg Schilling]

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


> Right. The question was rather like this:
> Say we have our non-stable /dev/sr0 mapping to /dev/sg0, and it has got BTL 
> 1,1,0. Now, if the user starts `cdrecord -dev=1,1,0`,
> `ls -l /proc/$(pidof -s cdrecord)/fd/` should show (and in fact did when I 
> used ide-scsi back then) /dev/sg0, right?
>
> If so, what's wrong with just opening /dev/sg0 directly (as per user 
> request, i.e. cdrecord -dev=/dev/sg0) and sending the scsi commands down 
> the fd?

As I did write _many_ times, this was done by the program "cdwrite" on Linux
in 1995 and as cdwrite did not check whether if actually got a CD writer,
cdwrite did destroy many hard disk drives just _because_ the /dev/sg* 
is non-stable.

People did not believe this and did write shell scripts with e.g. /dev/sg0 
inside and later suffered from the non-stable /dev/sg* <-> device relation.


Jörg

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

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

[Jan Engelhardt]

>> Right. The question was rather like this:
>> Say we have our non-stable /dev/sr0 mapping to /dev/sg0, and it has got BTL 
>> 1,1,0. Now, if the user starts `cdrecord -dev=1,1,0`,
>> `ls -l /proc/$(pidof -s cdrecord)/fd/` should show (and in fact did when I 
>> used ide-scsi back then) /dev/sg0, right?
>>
>> If so, what's wrong with just opening /dev/sg0 directly (as per user 
>> request, i.e. cdrecord -dev=/dev/sg0) and sending the scsi commands down 
>> the fd?
>
>As I did write _many_ times, this was done by the program "cdwrite" on Linux
>in 1995 and as cdwrite did not check whether if actually got a CD writer,
>cdwrite did destroy many hard disk drives just _because_ the /dev/sg* 
>is non-stable.
>
>People did not believe this and did write shell scripts with e.g. /dev/sg0 
>inside and later suffered from the non-stable /dev/sg* <-> device relation.
>
Exactly. But, if I now say -dev=1,1,0 instead of e.g. -dev=/dev/sg0, who or 
what makes sure that 1,1,0 {is not | does not map to} a harddisk?


Jan Engelhardt
-- 

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

[Michael Buesch]

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

On Friday 10 February 2006 12:02, you wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> 
> > Right. The question was rather like this:
> > Say we have our non-stable /dev/sr0 mapping to /dev/sg0, and it has got BTL 
> > 1,1,0. Now, if the user starts `cdrecord -dev=1,1,0`,
> > `ls -l /proc/$(pidof -s cdrecord)/fd/` should show (and in fact did when I 
> > used ide-scsi back then) /dev/sg0, right?
> >
> > If so, what's wrong with just opening /dev/sg0 directly (as per user 
> > request, i.e. cdrecord -dev=/dev/sg0) and sending the scsi commands down 
> > the fd?
> 
> As I did write _many_ times, this was done by the program "cdwrite" on Linux
> in 1995 and as cdwrite did not check whether if actually got a CD writer,
> cdwrite did destroy many hard disk drives just _because_ the /dev/sg* 
> is non-stable.
> 
> People did not believe this and did write shell scripts with e.g. /dev/sg0 
> inside and later suffered from the non-stable /dev/sg* <-> device relation.

I am sure they used udev, back in 1995...

-- 
Greetings Michael.

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

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

[Matthias Andree]

Jan Engelhardt wrote:
>> Please explain me:
>>
>> -	how to use /dev/hd* in order to scan an image from a scanner
>> -	how to use /dev/hd* in order to talk to a CPU device
>> -	how to use /dev/hd* in order to talk to a tape device
>> -	how to use /dev/hd* in order to talk to a printer
>> -	how to use /dev/hd* in order to talk to a jukebox
>> -	how to use /dev/hd* in order to talk to a graphical device

> With /dev/sg, this was possible?

Theoretically, yes, provided there was an application talking raw SCSI to
the device in question. /dev/sg is a generic SCSI device that allows the
sending of commands. It does not implement higher-level device models such
as direct access (/dev/sd*), CD-ROM (/dev/sr*), sequential access
(/dev/[n]st*) or similar. It's kind of "raw SCSI".

OTOH, there is, according to kernel developers, no difference between
/dev/sg and /dev/hd for SCSI command access via the SG_IO ioctl, so unless
someone documents /dev/hd* bugs that /dev/sg* doesn't share, it appears as
though the user space would have to live with a /dev/hd* that unifies the
mid-level "raw SCSI command" and the high-level (block device) access.

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

[Alexander Samad]

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

On Thu, Feb 09, 2006 at 10:39:55AM +0100, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > > You just verify that you don't listen...
> >  
> > Yes, I have been listening and I haven't seen you list one reason why
> > cdrecord absolutely has to use SCSI IDs when fsck can get away with using
> > /dev/blah just fine.
> 
> Are you _really_ missing basic know how to understand that fsck is using the
> block layer of a virtual "block device" emulated by UNIX while libscg is
> offering _direct_ acces to _any_ type of device allowing you to send _commands_
> understood by the device?
> 
> fsck is just sending abstract instructions to a virtual device and does 
> not care about 
> 
> Please explain me:
> 
> -	how to use /dev/hd* in order to scan an image from a scanner
> 
> -	how to use /dev/hd* in order to talk to a CPU device
> 
> -	how to use /dev/hd* in order to talk to a tape device
> 
> -	how to use /dev/hd* in order to talk to a printer
> 
> -	how to use /dev/hd* in order to talk to a jukebox
> 
> -	how to use /dev/hd* in order to talk to a graphical device

Hi 

I have been following this thread for quite a while, would just like to
point out that you are quick pedantic about accuracy.  

so even though it might be a bit of a pain to create a file called
/dev/hd*, I believe with mknod you could assign this name to any device
you wanted to or even symlink it to any device so you could use you
/dev/hd* the same way as you used /dev/sda etc

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

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

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

[Martin Mares]

> I did answer this many times and I will not repeat it another time.

So just point to the Message-ID.

					Martin

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-09:

> Linux does not offer a UNIX style interface in this case as it breaks
> layering rules.

Where is that standard that stipulates said layering rules?

Quote standard and name, issuer, publisher, edition (year) and section
or page number.  And don't dare answer unless you can prove the standard
applies to the device at hand, again, with standard, edition, and
section/page number.

> Do you _really_ want me to start a discussion conderning the content
> of your junk patch?

I demand that you revoke and post a public excuse for that offense.

The deadline ends tomorrow, Friday February 10th at 12:00 (noon) German
official time.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> Joerg Schilling schrieb am 2006-02-09:
>
> > Linux does not offer a UNIX style interface in this case as it breaks
> > layering rules.
>
> Where is that standard that stipulates said layering rules?


You still try to deviate from the problem by sending relationless remarks.

You should _read_ my mail before sending unrelated replies.


> > Do you _really_ want me to start a discussion conderning the content
> > of your junk patch?
>
> I demand that you revoke and post a public excuse for that offense.
>
> The deadline ends tomorrow, Friday February 10th at 12:00 (noon) German
> official time.

Do you like to out yourself as a troll?

You send completely useless things just in order to personally affront me.

Note that is was _you_ who said that you like to discuss this useless code.
I was ging to ignore it. You like to discuss is, you receive a reply
that you might not expect. 



Jörg

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

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

[DervishD]

    Hi Joerg :)

 * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> > > Do you _really_ want me to start a discussion conderning the content
> > > of your junk patch?
> >
> > I demand that you revoke and post a public excuse for that offense.
> >
> > The deadline ends tomorrow, Friday February 10th at 12:00 (noon) German
> > official time.
> 
> Do you like to out yourself as a troll?
> 
> You send completely useless things just in order to personally affront me.

    Joerg, it's really sad to see a person as talented and clever as
you resorting to personal offences. Matthias sent you a patch, hoping
to be useful; IMHO, you took it bad because he insisted on you
honoring the same kind of things you force people to honor when it
comes to the GPL. IMHO, that made his patch "junk" for you. The patch
is not junk, at least to me, but even if it was junk, it was the only
sane thing in this whole thread: code to proof things and fix things
that someone (many of us, as a matter of fact) thinks is a cdrecord
problem.

    He wanted to discuss the patch: if it is junk, that's the
opportunity to fix it and make it good, and avoid new bugs, why not?.
But instead of discussing the code (no matter if you just think that
it is crap) you offended Matthias (who, BTW, has been very respectful
in this thread, probably the most respectful one).

    You've been very unpolite, Joerg, and it is a pity, because
you're very intelligent but nonetheless sometimes you look like...
well, both know.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

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

[Joerg Schilling]

DervishD <lkml@dervishd.net> wrote:

>     Joerg, it's really sad to see a person as talented and clever as
> you resorting to personal offences. Matthias sent you a patch, hoping

I am not sure whether Matthias is telented, but he was unfortunately
starting personal offenses....

Jörg

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

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

[Jan Engelhardt]

>>     Joerg, it's really sad to see a person as talented and clever as
>> you resorting to personal offences. Matthias sent you a patch, hoping
>
>I am not sure whether Matthias is telented, but he was unfortunately
>starting personal offenses....
>
With a patch?


Jan Engelhardt
-- 

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

[DervishD]

    Hi Joerg :)

 * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> > The people replying here are your users, if you don't want to listen to
> > them pretty much any conversation with you will be a waste of time.
> 
> Sorry, but from reading the mail from _real_ cdrecord users, it is
> obvious that the people here are either not my users or users with
> a stange way of thinking.

    Joerg, I know you're going to ignore this email just as you
ignored other emails I sent you in the past regarding cdrecord, the
annoying numbering scheme and the stupid "your DMA speed is too slow,
you cannot write at more than 12x" (fortunately, my CD writer doesn't
know that and writes correctly at 50x and even more). Anyway, I want
to tell you that I've been a cdrecord _real_ user for more than 5
years, and while I consider your work valuable and clever, you have
NO respect for anybody who doesn't think the same as you. I know many
cdrecord users (_real_ ones, IMHO), and ALL of them think that the
numbering scheme to access their writers is CRAP: crappy design,
crappy coding and crappy user interface.

    I'm going to be a bit more respectful: I don't consider it crap.
I just consider it bad. Bad because cdrecord is the only program in
my system that forces me to think what the heck is the correct number
for my CD writer (which is /dev/cdrw in my system) or which number do
I have to use to READ a CD image using "readcd" (instead of /dev/cdrw
or /dev/dvd, or even the ugly /dev/hdc). I end up using "-scanbus"
everytime I use a system which is not mine, and that's bad, because
most of those systems have /dev/cdrw, or /dev/cdrecorder, or
something like that.

    Joerg, the problem is that you never listen to things you don't
like. I understand, because I sometimes do exactly the same, but I
don't maintain a program with thousand of users...

    cdrecord is GPL, so in the end nobody has the right to ask you to
modify it in ways you don't like or you don't want it to. That goes
with free software: you don't pay, you don't have the right to ask
for things. But, how about trying to listen to third parties? I mean,
you are probably OK ignoring my suggestions, I am probably a mediocre
programmer, but... do you _really_ think that you are more clever
than ALL the programmers in this mailing list? Do you _really_ think
that you have the correct answer and that ALL of them are plainly
wrong? Do you _REALLY_ think that EVERYBODY is wrong *except* you in
this issue about the user interface?

    C'mon, Joerg, you're more clever than that. You probably know
that a program where half the options have a leading "-" and the
other half doesn't have it probably has a bad user interface. You
know that if a program uses a naming convention different from ALL
the rest of programs is because the program has a problem. You know
that if the only UNIX program out there that doesn't use /dev entries
to talk to devices is cdrecord, the problem *probably* is in
cdrecord, and not in UNIX...

    Well, I will stop here. I don't want to argue with you about this
because I'm not sure if I'm right or not. I just happen to like more
the "/dev" approach that a set of three numbers to locate a unit in a
SCSI bus that I DON'T HAVE in my box...

    Believe me: I consider you a very good programmer and a very
clever person, but your attitude is...

    My best wishes, Joerg.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

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

[Lennart Sorensen]

On Wed, Feb 08, 2006 at 10:02:19PM +0100, DervishD wrote:
>     Joerg, I know you're going to ignore this email just as you
> ignored other emails I sent you in the past regarding cdrecord, the
> annoying numbering scheme and the stupid "your DMA speed is too slow,
> you cannot write at more than 12x" (fortunately, my CD writer doesn't
> know that and writes correctly at 50x and even more). Anyway, I want
> to tell you that I've been a cdrecord _real_ user for more than 5
> years, and while I consider your work valuable and clever, you have
> NO respect for anybody who doesn't think the same as you. I know many
> cdrecord users (_real_ ones, IMHO), and ALL of them think that the
> numbering scheme to access their writers is CRAP: crappy design,
> crappy coding and crappy user interface.
> 
>     I'm going to be a bit more respectful: I don't consider it crap.
> I just consider it bad. Bad because cdrecord is the only program in
> my system that forces me to think what the heck is the correct number
> for my CD writer (which is /dev/cdrw in my system) or which number do
> I have to use to READ a CD image using "readcd" (instead of /dev/cdrw
> or /dev/dvd, or even the ugly /dev/hdc). I end up using "-scanbus"
> everytime I use a system which is not mine, and that's bad, because
> most of those systems have /dev/cdrw, or /dev/cdrecorder, or
> something like that.
> 
>     Joerg, the problem is that you never listen to things you don't
> like. I understand, because I sometimes do exactly the same, but I
> don't maintain a program with thousand of users...

I agree entirely and wish I could have put it that well.

>     cdrecord is GPL, so in the end nobody has the right to ask you to
> modify it in ways you don't like or you don't want it to. That goes
> with free software: you don't pay, you don't have the right to ask
> for things. But, how about trying to listen to third parties? I mean,
> you are probably OK ignoring my suggestions, I am probably a mediocre
> programmer, but... do you _really_ think that you are more clever
> than ALL the programmers in this mailing list? Do you _really_ think
> that you have the correct answer and that ALL of them are plainly
> wrong? Do you _REALLY_ think that EVERYBODY is wrong *except* you in
> this issue about the user interface?

Hmm, perhaps what should be done is that someone needs to write and
maintain a patch that linux users can apply to cdrecord (since other OSs
are different and hence have no reason to use such a patch), to make it
behave in a manner which is sane on linux.  It should of course be
clearly marked as having been changed in such a way.  It should use udev
if available and HAL and whatever else is appropriate on a modern linux
system, and if on an old system it should at least not break the
interfaces that already worked on those systems in cdrecord.

cdrecord does a wonderful job writing CDs, once you get the silly
command line syntax right and figure out which device option it wants
you to tell it to access your write.  I still find the syntax of
driveropts=option=value is a bit odd, although the linux kernel does the
same thing for some kernel boot arguments as far as I recall, so who am
I to argue.

growisofs has a lovely simple interface, although it probably only has
about 1% as many options as cdrecord.  Perhaps there are just a lot
fewer weird variations on DVDs so far so less options are needed, or
perhaps there are a lot more options but they are all secret and in the
source code.  I haven't needed to use them at least.

Len Sorensen

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

[Matthias Andree]

On Wed, 08 Feb 2006, Lennart Sorensen wrote:

> Hmm, perhaps what should be done is that someone needs to write and
> maintain a patch that linux users can apply to cdrecord (since other OSs
> are different and hence have no reason to use such a patch), to make it
> behave in a manner which is sane on linux.  It should of course be

In case you missed it, I wrote a patch for libscg and posted it here
last week, and as it actually shrinks the code, it would benefit other
systems as well - albeit only by reducing their download size.

> clearly marked as having been changed in such a way.  It should use udev
> if available and HAL and whatever else is appropriate on a modern linux

That my patch doesn't do, but it unifies /dev/sg* and /dev/hd* into one
view (no more ATA:1,2,3, just 1,2,3 will do, as will /dev/hdc or
/dev/sg3).

-- 
Matthias Andree

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

[Lennart Sorensen]

On Wed, Feb 08, 2006 at 10:26:29PM +0100, Matthias Andree wrote:
> In case you missed it, I wrote a patch for libscg and posted it here
> last week, and as it actually shrinks the code, it would benefit other
> systems as well - albeit only by reducing their download size.

Yes I saw that.  Of course it has to be maintained so it applies to new
versions of cdrecord, since apparently fixes for such things are not
going to be accepted upstream.

> That my patch doesn't do, but it unifies /dev/sg* and /dev/hd* into one
> view (no more ATA:1,2,3, just 1,2,3 will do, as will /dev/hdc or
> /dev/sg3).

Well that certainly does fix some of the issues.

Len Sorensen

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

[DervishD]

    Hi Lennart :)

 * Lennart Sorensen <lsorense@csclub.uwaterloo.ca> dixit:
> On Wed, Feb 08, 2006 at 10:02:19PM +0100, DervishD wrote:
> >     cdrecord is GPL, so in the end nobody has the right to ask you to
> > modify it in ways you don't like or you don't want it to. That goes
> > with free software: you don't pay, you don't have the right to ask
> > for things. But, how about trying to listen to third parties? I mean,
> > you are probably OK ignoring my suggestions, I am probably a mediocre
> > programmer, but... do you _really_ think that you are more clever
> > than ALL the programmers in this mailing list? Do you _really_ think
> > that you have the correct answer and that ALL of them are plainly
> > wrong? Do you _REALLY_ think that EVERYBODY is wrong *except* you in
> > this issue about the user interface?
> 
> Hmm, perhaps what should be done is that someone needs to write and
> maintain a patch that linux users can apply to cdrecord (since other OSs
> are different and hence have no reason to use such a patch), to make it
> behave in a manner which is sane on linux.  It should of course be
> clearly marked as having been changed in such a way.  It should use udev
> if available and HAL and whatever else is appropriate on a modern linux
> system, and if on an old system it should at least not break the
> interfaces that already worked on those systems in cdrecord.

    Matthias Andree posted such a patch last week, and he was ignored
by Joerg. In fact, he got an answer of "I haven't looked at it and I
never will" or something like that (check the list archives).

    Joerg was offered help to maintain a bit of code he doesn't want
to maintain and rejected it.
 
> cdrecord does a wonderful job writing CDs, once you get the silly
> command line syntax right and figure out which device option it
> wants you to tell it to access your write.  I still find the syntax
> of driveropts=option=value is a bit odd, although the linux kernel
> does the same thing for some kernel boot arguments as far as I
> recall, so who am I to argue.

    cdrecord is a good tool, no doubt about that. IMHO it can be
improved by changing the user interface and getting rid of useless
warnings, but nonetheless it is a good tool. The problem is Joerg
attitude...
 
    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

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

[Joerg Schilling]

DervishD <lkml@dervishd.net> wrote:

>     Matthias Andree posted such a patch last week, and he was ignored
> by Joerg. In fact, he got an answer of "I haven't looked at it and I
> never will" or something like that (check the list archives).

If you like to look at the junk he send, do it....

>     Joerg was offered help to maintain a bit of code he doesn't want
> to maintain and rejected it.

Sorry this cannot be called help, in contrary it is an attempt to waste 
my time.

w
Jörg

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

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

[DervishD]

    Hi Joerg :)

 * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> DervishD <lkml@dervishd.net> wrote:
> >     Matthias Andree posted such a patch last week, and he was ignored
> > by Joerg. In fact, he got an answer of "I haven't looked at it and I
> > never will" or something like that (check the list archives).
> 
> If you like to look at the junk he send, do it....

    I've already done it. Doesn't seem to be junk. It works for me,
and the patch was well prepared (at least it looks good to me).
 
    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

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

[Joerg Schilling]

DervishD <lkml@dervishd.net> wrote:

>     I've already done it. Doesn't seem to be junk. It works for me,
> and the patch was well prepared (at least it looks good to me).

If this is thew way you write software.... it will not have the quality
I am  loking for.


Jörg

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

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

[Jim Crilly]

On 02/09/06 04:45:07PM +0100, Joerg Schilling wrote:
> DervishD <lkml@dervishd.net> wrote:
> 
> >     I've already done it. Doesn't seem to be junk. It works for me,
> > and the patch was well prepared (at least it looks good to me).
> 
> If this is thew way you write software.... it will not have the quality
> I am  loking for.
> 
> 
> Jörg

At least he's willing to read people's contributions and listen to their
ideas and criticisms.

Jim.

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

[Alexander Samad]

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

On Thu, Feb 09, 2006 at 04:45:07PM +0100, Joerg Schilling wrote:
> DervishD <lkml@dervishd.net> wrote:
> 
> >     I've already done it. Doesn't seem to be junk. It works for me,
> > and the patch was well prepared (at least it looks good to me).
> 
> If this is thew way you write software.... it will not have the quality
> I am  loking for.

How would you know if you don't read it, seems pretty presumptious and
very narrow minded, but I haven't read it either

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

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

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

[Joerg Schilling]

lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote:

> Hmm, perhaps what should be done is that someone needs to write and
> maintain a patch that linux users can apply to cdrecord (since other OSs
> are different and hence have no reason to use such a patch), to make it
> behave in a manner which is sane on linux.  It should of course be
> clearly marked as having been changed in such a way.  It should use udev
> if available and HAL and whatever else is appropriate on a modern linux
> system, and if on an old system it should at least not break the
> interfaces that already worked on those systems in cdrecord.

Unfortunately is it a matter oif facts that all known patches for cdrecord
break more things than they claim to fix.

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-09:

> lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> 
> > Hmm, perhaps what should be done is that someone needs to write and
> > maintain a patch that linux users can apply to cdrecord (since other OSs
> > are different and hence have no reason to use such a patch), to make it
> > behave in a manner which is sane on linux.  It should of course be
> > clearly marked as having been changed in such a way.  It should use udev
> > if available and HAL and whatever else is appropriate on a modern linux
> > system, and if on an old system it should at least not break the
> > interfaces that already worked on those systems in cdrecord.
> 
> Unfortunately is it a matter oif facts that all known patches for cdrecord
> break more things than they claim to fix.

So prove my patch is wrong, and give a detailed report what it breaks,
unless you wish to fix it yourself.

-- 
Matthias Andree

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

[Joerg Schilling]

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

> > Unfortunately is it a matter oif facts that all known patches for cdrecord
> > break more things than they claim to fix.
>
> So prove my patch is wrong, and give a detailed report what it breaks,
> unless you wish to fix it yourself.

Give a detailed report on what it fixes. It does not make sense to discuss
useless code that introduces more bugs than it pretends to fix.

Jörg

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

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

[Matthias Andree]

Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
>>> Unfortunately is it a matter oif facts that all known patches for cdrecord
>>> break more things than they claim to fix.
>> So prove my patch is wrong, and give a detailed report what it breaks,
>> unless you wish to fix it yourself.
> 
> Give a detailed report on what it fixes. It does not make sense to discuss
> useless code that introduces more bugs than it pretends to fix.

That was contained in the message you blatantly ignored. I'm not going to
repost, see <http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html>

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

[DervishD]

    Hi Joerg :)

 * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> > Hmm, perhaps what should be done is that someone needs to write and
> > maintain a patch that linux users can apply to cdrecord (since other OSs
> > are different and hence have no reason to use such a patch), to make it
> > behave in a manner which is sane on linux.  It should of course be
> > clearly marked as having been changed in such a way.  It should use udev
> > if available and HAL and whatever else is appropriate on a modern linux
> > system, and if on an old system it should at least not break the
> > interfaces that already worked on those systems in cdrecord.
> 
> Unfortunately is it a matter oif facts that all known patches for
> cdrecord break more things than they claim to fix.

    Could you please clarify which things are broken by Matthias
patch? This way he (or other developer) can prepare a better patch
and maintain it. BTW, I patched my cdrecord with Matthias patch and
nothing seems to be broken :? Maybe am I missing something?

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

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

[Joerg Schilling]

DervishD <lkml@dervishd.net> wrote:

>     Could you please clarify which things are broken by Matthias
> patch? This way he (or other developer) can prepare a better patch
> and maintain it. BTW, I patched my cdrecord with Matthias patch and
> nothing seems to be broken :? Maybe am I missing something?

It is completely broken and thus makes no sense at all.

As I did write it looks lie a dentist drills a hole into an aking tooth
and then claims to be complete with the whole treatment.

Jörg

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

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

[Matthias Andree]

Joerg Schilling wrote:
> DervishD <lkml@dervishd.net> wrote:
> 
>>     Could you please clarify which things are broken by Matthias
>> patch? This way he (or other developer) can prepare a better patch
>> and maintain it. BTW, I patched my cdrecord with Matthias patch and
>> nothing seems to be broken :? Maybe am I missing something?
> 
> It is completely broken and thus makes no sense at all.

"Completely broken" is not a proper description that might become the basis
of a technical discussion.

It looks like the quick way of not having to look at it, at least there is
no hint you could provide specific information as to what the patch breaks.

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

[DervishD]

    Hi Joerg :)

 * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> >     Could you please clarify which things are broken by Matthias
> > patch? This way he (or other developer) can prepare a better patch
> > and maintain it. BTW, I patched my cdrecord with Matthias patch and
> > nothing seems to be broken :? Maybe am I missing something?
> 
> It is completely broken and thus makes no sense at all.

    OK, I understand now... Completely broken... Have you any actual
proof or should I use my faith and just believe it is completely
broken?

    Anyway, forget about it. As you suggest in other message, my way
of writing software is so poor ('cause I think that the junk Matthias
wrote is good for me) that probably I won't understand your
explanation. You know, that's the problem with stupid people like me,
that we don't understand what people say to us, so there's not point
in explaining. You do the right think and don't provide facts,
because nobody is clever or talented enough to understand them.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

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

[Joerg Schilling]

DervishD <lkml@dervishd.net> wrote:

>  * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> > >     Could you please clarify which things are broken by Matthias
> > > patch? This way he (or other developer) can prepare a better patch
> > > and maintain it. BTW, I patched my cdrecord with Matthias patch and
> > > nothing seems to be broken :? Maybe am I missing something?
> > 
> > It is completely broken and thus makes no sense at all.
>
>     OK, I understand now... Completely broken... Have you any actual
> proof or should I use my faith and just believe it is completely
> broken?

What is your intent for writing this?

FUD?

Jörg

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

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

[DervishD]

    Hi Joerg :)

 * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> DervishD <lkml@dervishd.net> wrote:
> >  * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> > > >     Could you please clarify which things are broken by Matthias
> > > > patch? This way he (or other developer) can prepare a better patch
> > > > and maintain it. BTW, I patched my cdrecord with Matthias patch and
> > > > nothing seems to be broken :? Maybe am I missing something?
> > > 
> > > It is completely broken and thus makes no sense at all.
> >
> >     OK, I understand now... Completely broken... Have you any actual
> > proof or should I use my faith and just believe it is completely
> > broken?
> 
> What is your intent for writing this?

    My intention is to get real proofs about the "brokenness" of the
patch, not just an "It is completely broken". That's not technical.
That's the same than saying "Windows sucks". Now, tell why it sucks,
in technical terms.

    A better example: it is like saying that the numbering scheme
that cdrecord uses is crap. That's nontechnical. A technical approach
is "UNIX userspace programs doesn't use three numbers to talk to
devices, they use /dev nodes, so cdrecord is breaking the UNIX way of
doing things". Or "Windows uses letters to refer to storage devices
and cdrecorders and not three numbers, so cdrecord is breaking the
way of doing things on Windows". I don't even ask for a deep
technical discussion, anything more technical than "It is completely
broken" will do.
 
> FUD?

    Why do you think that? Have I offended you? Have I attacked
you personally? Up to this point I have:

    - Asked for technical reasons about a patch rejection.
    - Tell my *opinion*, as a cdrecord user, about the user
interface.

    I can't see fear, my only uncertainty is about the technical
(un)correctness of the patch, which you haven't clarified yet, and my
only doubt is if there are programs, apart from cdrecord and libscg
users, which uses your numbering scheme instead of /dev entries :?
That makes (at worst) UD, but not FUD.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

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

[Joerg Schilling]

DervishD <lkml@dervishd.net> wrote:

> > What is your intent for writing this?
>
>     My intention is to get real proofs about the "brokenness" of the
> patch, not just an "It is completely broken". That's not technical.
> That's the same than saying "Windows sucks". Now, tell why it sucks,
> in technical terms.
>

So why don't you look at the patch then?

Jörg

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

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

[DervishD]

    Hi Joerg :)

 * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> DervishD <lkml@dervishd.net> wrote:
> > > What is your intent for writing this?
> >
> >     My intention is to get real proofs about the "brokenness" of the
> > patch, not just an "It is completely broken". That's not technical.
> > That's the same than saying "Windows sucks". Now, tell why it sucks,
> > in technical terms.
> >
> 
> So why don't you look at the patch then?

    I've done it. I told in my first message. Have you done it?

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

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

[Jim Crilly]

On 02/09/06 11:29:28AM +0100, Joerg Schilling wrote:
> lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> 
> > Hmm, perhaps what should be done is that someone needs to write and
> > maintain a patch that linux users can apply to cdrecord (since other OSs
> > are different and hence have no reason to use such a patch), to make it
> > behave in a manner which is sane on linux.  It should of course be
> > clearly marked as having been changed in such a way.  It should use udev
> > if available and HAL and whatever else is appropriate on a modern linux
> > system, and if on an old system it should at least not break the
> > interfaces that already worked on those systems in cdrecord.
> 
> Unfortunately is it a matter oif facts that all known patches for cdrecord
> break more things than they claim to fix.
> 
> Jörg

I've been using the cdrecord packaged by Debian for years without a single
problem and it has 35 patches included in the source package. Please
enlighten me as to what they've broken because obviously none of it has
affected me.

Jim.

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

[Joerg Schilling]

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

> I've been using the cdrecord packaged by Debian for years without a single
> problem and it has 35 patches included in the source package. Please
> enlighten me as to what they've broken because obviously none of it has
> affected me.

Are you unwilling to reead critisism?

Just read my comments on the Debian bug tracking system

Jörg

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

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

[Jim Crilly]

On 02/09/06 05:01:50PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > I've been using the cdrecord packaged by Debian for years without a single
> > problem and it has 35 patches included in the source package. Please
> > enlighten me as to what they've broken because obviously none of it has
> > affected me.
> 
> Are you unwilling to reead critisism?
> 
> Just read my comments on the Debian bug tracking system
> 
> Jörg

To which bugs are you referring? Looking at the bugs for the cdrtools
package, I only see 1 functionality bug. All of the rest are policy
violations, copyright updates, translation updates, etc. And ironically
in that 1 real bug the entire thread degenerated into you pointing
fingers and slinging mud at the Linux kernel maintainers again, just
like this one.

Jim.

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

[Joerg Schilling]

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

> > Just read my comments on the Debian bug tracking system
> > 
> > Jörg
>
> To which bugs are you referring? Looking at the bugs for the cdrtools
> package, I only see 1 functionality bug. All of the rest are policy
> violations, copyright updates, translation updates, etc. And ironically
> in that 1 real bug the entire thread degenerated into you pointing
> fingers and slinging mud at the Linux kernel maintainers again, just
> like this one.

It's not me who proablty did delete unwanted information on Debian.org.....

A few weeks ago, there have been aprox. 100 "bug" entries.

Jörg

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

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

[Matthias Andree]

Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
>>> Just read my comments on the Debian bug tracking system
>>>
>>> Jörg
>> To which bugs are you referring? Looking at the bugs for the cdrtools
>> package, I only see 1 functionality bug. All of the rest are policy
>> violations, copyright updates, translation updates, etc. And ironically
>> in that 1 real bug the entire thread degenerated into you pointing
>> fingers and slinging mud at the Linux kernel maintainers again, just
>> like this one.
> 
> It's not me who proablty did delete unwanted information on Debian.org.....
> 
> A few weeks ago, there have been aprox. 100 "bug" entries.

You need not care about the Debian bugs, except the few the Debian package
maintainers have forwarded to you. Every other bug is Debian specific. The
idea is they will pass bug reports through a triage process, filter support
requests, filter bug reports that are related to their local changes, and
forward what they deem upstream bugs to you.

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

[Jim Crilly]

On 02/09/06 05:13:08PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > > Just read my comments on the Debian bug tracking system
> > > 
> > > Jörg
> >
> > To which bugs are you referring? Looking at the bugs for the cdrtools
> > package, I only see 1 functionality bug. All of the rest are policy
> > violations, copyright updates, translation updates, etc. And ironically
> > in that 1 real bug the entire thread degenerated into you pointing
> > fingers and slinging mud at the Linux kernel maintainers again, just
> > like this one.
> 
> It's not me who proablty did delete unwanted information on Debian.org.....
> 
> A few weeks ago, there have been aprox. 100 "bug" entries.
> 
> Jörg

Nevermind, I found them. They're rightfully attributed to the cdrecord
binary package and not the cdrtools source package. So far I've looked
through two dozen or so bugs and found only like 3 comments from you,
1 was telling someone that they had a hardware problem and the others
were finger pointing at the Linux kernel devs.

Jim.

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

[Joerg Schilling]

DervishD <lkml@dervishd.net> wrote:


> other half doesn't have it probably has a bad user interface. You
> know that if a program uses a naming convention different from ALL
> the rest of programs is because the program has a problem. You know
> that if the only UNIX program out there that doesn't use /dev entries
> to talk to devices is cdrecord, the problem *probably* is in
> cdrecord, and not in UNIX...

So why do you like to introduce a different naming scheme?

Look into the real world and you will find that most SCSI related programs
use a namischscheme that is either identical to what cdrecord does
or a very similar one.

Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-09:

> DervishD <lkml@dervishd.net> wrote:
> 
> 
> > other half doesn't have it probably has a bad user interface. You
> > know that if a program uses a naming convention different from ALL
> > the rest of programs is because the program has a problem. You know
> > that if the only UNIX program out there that doesn't use /dev entries
> > to talk to devices is cdrecord, the problem *probably* is in
> > cdrecord, and not in UNIX...
> 
> So why do you like to introduce a different naming scheme?

It is striking that Jörg Schilling's code alone uses this naming scheme,
and nothing else appears to be. If there is, perhaps naming a few
typical real-world applications could enlighten us. You haven't
mentioned examples yet, so there isn't even a faint hint cdrecord is
consistent with the so-called real-world.

-- 
Matthias Andree

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

[DervishD]

    Hi Joerg :)

 * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit:
> DervishD <lkml@dervishd.net> wrote:
> > other half doesn't have it probably has a bad user interface. You
> > know that if a program uses a naming convention different from ALL
> > the rest of programs is because the program has a problem. You know
> > that if the only UNIX program out there that doesn't use /dev entries
> > to talk to devices is cdrecord, the problem *probably* is in
> > cdrecord, and not in UNIX...
> 
> So why do you like to introduce a different naming scheme?

    Exactly, Joerg, why do YOU like to introduce a different naming
scheme? UNIX uses /dev/whatever, Win32 uses <UNIT>:, etc. Why do you
want to break those names, which are familiar to the user?
 
> Look into the real world and you will find that most SCSI related
> programs use a namischscheme that is either identical to what
> cdrecord does or a very similar one.

    I don't know any program, except cdrecord and family, which uses
your naming scheme, but I will more than happy to hear examples, look
at them and change my mind if I finally get convinced that the naming
scheme you're using is finally better. But instead of telling me to
look into the real world, tell me examples, please. I don't have at
home any SCSI bus and so I don't use SCSI related programs.

    Thanks in advance :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

Peter Read <peter.read@gmail.com> wrote:

> I'm confused about where software has inherited a sense of morality from?
>
> Equally, as I can't see any restriction of the GPL in that link I
> don't get the reference.  What it's essentially saying to me is 'if
> you don't want it under the GPL licence terms, talk to the copyright
> holder(s) or their authorised representative about alternatives'.

Please read again carefully. It says that it is not allowed to be shipped
together with commercial software unless the publisher did pay money.

Jörg

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-06:

> Peter Read <peter.read@gmail.com> wrote:
> 
> > I'm confused about where software has inherited a sense of morality from?
> >
> > Equally, as I can't see any restriction of the GPL in that link I
> > don't get the reference.  What it's essentially saying to me is 'if
> > you don't want it under the GPL licence terms, talk to the copyright
> > holder(s) or their authorised representative about alternatives'.
> 
> Please read again carefully. It says that it is not allowed to be shipped
> together with commercial software unless the publisher did pay money.

The topic is still cdrecord with Linux, growisofs and dvd+rw-tools
discussion is a matter for a separate thread.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Luke-Jr]

On Monday 06 February 2006 13:51, Joerg Schilling wrote:
> Luke-Jr <luke@dashjr.org> wrote:
> > ProDVD is immoral software. I use growisofs.
>
> growisofs is immoral, see
>
> 	http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html
>
> Either this, or the GPL applies, but not both as intended by the author....

You can dual license any work. Someone who receives growisofs under this 
license would not be allowed to redistribute it without permission granted 
therein. However, if that same person receives growisofs under the GPL 
license, the GPL terms apply. A GPL license only applies if the person has 
received the software under those terms. While most GPL'd software is 
available online under the GPL license, making it effectively everyone to 
receive the license, it is not necessary.

On Monday 06 February 2006 17:25, you wrote:
> Peter Read <peter.read@gmail.com> wrote:
> > I'm confused about where software has inherited a sense of morality from?
> >
> > Equally, as I can't see any restriction of the GPL in that link I
> > don't get the reference.  What it's essentially saying to me is 'if
> > you don't want it under the GPL licence terms, talk to the copyright
> > holder(s) or their authorised representative about alternatives'.
>
> Please read again carefully. It says that it is not allowed to be shipped
> together with commercial software unless the publisher did pay money.

However, that applies only for that particular license. If the publisher 
obtains the rights elsewhere (eg, the GPL licensed version), then they may do 
so provided they comply with the rest of the GPL terms. Note that the GPL 
prohibits distributing growisofs linked to non-GPL-compatible software. Thus, 
if Solaris is not under a GPL-compatible license, the GPL prohibits 
distributing growisofs with it.

Re: Rationale for RLIMIT_MEMLOCK?

[Joerg Schilling]

Lee Revell <rlrevell@joe-job.com> wrote:

> > In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later 
> > ignores this contract. This bug should be fixed.
>
> Joerg,
>
> You will be happy to know that in future Linux distros, cdrecord will
> not require setuid to mlock() and get SCHED_FIFO - both are now
> controlled by rlimits, so if the distro ships with a sane PAM/group
> configuration, all you will need to do is add cdrecord users to the
> "realtime" or "cdrecord" or "audio" group.
>
> This will take a while to make it into distros as it requires changes to
> PAM and glibc in addition to the kernel.

Well, on Solaris running cdrecord root-less is possible since 2 years.

What you do is to add a line

joerg::::profiles=CD RW

to /etc/user_attr

and a line:

CD RW:solaris:cmd:::/opt/schily/bin/cdrecord: privs=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr

to /etc/security/exec_attr

or to just a line

All:solaris:cmd:::/opt/schily/bin/cdrecord: privs=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr

to /etc/security/exec_attr

the command then is executed via /usr/vin/pfexec and gets the listed fine 
grained privileges in addition to the basic privileges.

We plan to break sys_devices into more fine grained privs that
include several levels of SCSI rights in the near future.

If Linux manages to do something similar, I would be happy.
It is obvious that this is someting that could only be used if there
is not only kernel code to support fine grained privs but there is a need
for a user space infrastructure that allows to use a seamless integration.

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: Rationale for RLIMIT_MEMLOCK?

[Lee Revell]

On Mon, 2006-01-23 at 19:55 +0100, Matthias Andree wrote:
> I'm asking the Bcc'd gentleman to reconsider mlockall() and perhaps
> use explicit mlock() instead. 

Probably good advice, I have found mlockall() to be especially
problematic with multithreaded programs and NPTL, as glibc eats
RLIMIT_STACK of unswappable memory for each thread stack which defaults
to 8MB here - you go OOM really quick like this.  Most people don't seem
to realize the need to set a sane value with pthread_attr_setstack().

(Even when not mlock'ed, insanely huge thread stack defaults seem to
account for a lot of the visible bloat on the desktop - decreasing
RLIMIT_STACK to 512KB reduces the footprint of Gnome 2.12 by 100+ MB.)

Lee

Re: Rationale for RLIMIT_MEMLOCK?

[Theodore Ts'o]

On Mon, Jan 23, 2006 at 07:55:49PM +0100, Matthias Andree wrote:
> The question that's open is one for the libc guys: malloc(), valloc()
> and others seem to use mmap() on some occasions (for some allocation
> sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and
> if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc
> is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and
> then drops privileges.

Maybe mlockall(MLC_FUTURE) when run with privileges should
automatically adjust the RLIMIT_MEMLOCK resource limit?

					- Ted

Re: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

On Mon, 23 Jan 2006, Theodore Ts'o wrote:

> On Mon, Jan 23, 2006 at 07:55:49PM +0100, Matthias Andree wrote:
> > The question that's open is one for the libc guys: malloc(), valloc()
> > and others seem to use mmap() on some occasions (for some allocation
> > sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and
> > if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc
> > is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and
> > then drops privileges.
> 
> Maybe mlockall(MLC_FUTURE) when run with privileges should
> automatically adjust the RLIMIT_MEMLOCK resource limit?

Adding special cases to no end.
Is this really sensible?

How about leaving RLIMIT_MEMLOCK alone (and at RLIM_INFINITY) for root
processes altogether? At least that wouldn't add a new special case but
just change the existing one to remove an inconsistency, and the effect
will be the same, only that it is inherited across seteuid().

I doubt that the kernel is the right place to implement policies that
belong into user space.  As long as the kernel is meant to be universal,
any default will collide with an application's requirement sooner or
later.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Bodo Eggert]

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

[...]
> On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
> that calls getexecuser() in order to find whether there is a specific
> treatment needed. If this specific treatment is needed, then the shell calls
> execve(/usr/bin/pfexec cmd <args>)
> else it calls  execve(cmd <args>)
> 
> I did recently voted to require all shells to be profile enabled by default.

Why? I asume there will only be few programs requiring to be run by a
wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo;
echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo;
chmod 755 /usr/bin/foo
should be easier than patching e.g. all callers of cdrecord, and it won't
slow down starting non-profiled applications.

Possibly the pfexec can tell the application to be run by the basename (like
su1), in this case you'd add something like
"alias cdrecord /opt/schily/bin/cdrecord" to it's configuration and link it
to /usr/bin/cdrecord.

> With the future plans for extending fine grained privs on Solaris, sending
> SCSI commands will become more than one priv.
> 
> I proposed to have a low priv right to send commands like inquiry and test
> unit ready. These commands may e.g. be send without interfering a concurrent
> CD/DVD write operation.
> 
> The next priv could be the permission for sending simple SCSI commands that
> allow reading from the device.
> 
> The next priv could be the permission for sending simple SCSI Commands that
> allow writing.
> 
> The final priv would allow even vendor specific commands: this is what
> cdrecord needs.

That sounds reasonable, but I wonder how you can get access to a device
file descriptor in order to do unprivileged access.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:

> Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
>
> [...]
> > On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
> > that calls getexecuser() in order to find whether there is a specific
> > treatment needed. If this specific treatment is needed, then the shell calls
> > execve(/usr/bin/pfexec cmd <args>)
> > else it calls  execve(cmd <args>)
> > 
> > I did recently voted to require all shells to be profile enabled by default.
>
> Why? I asume there will only be few programs requiring to be run by a
> wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo;
> echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo;
> chmod 755 /usr/bin/foo
> should be easier than patching e.g. all callers of cdrecord, and it won't
> slow down starting non-profiled applications.

Because the architecture review commitee decided this would be the right way.

Note that we are on a migration from the classical root/non-root UNIX to a fine 
grained privileges handling. The current documentation says that you need to 
have a profile enabled shell as your SHELL in order to be able to use a 
root-less Solaris.

> Possibly the pfexec can tell the application to be run by the basename (like
> su1), in this case you'd add something like
> "alias cdrecord /opt/schily/bin/cdrecord" to it's configuration and link it
> to /usr/bin/cdrecord.

But you are right that another way would be to use something like "isaexec"

> > The final priv would allow even vendor specific commands: this is what
> > cdrecord needs.
>
> That sounds reasonable, but I wonder how you can get access to a device
> file descriptor in order to do unprivileged access.

This is something that needs to be discussed. Last night, I found that there 
should be a way to run cdrecord without the need to have the "file_dac_read"
provilege. I'll discuss this with the security group.



Jörg

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

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

[Bodo Eggert]

On Tue, 24 Jan 2006, Joerg Schilling wrote:
> Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:
> > Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > [...]
> > > On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
> > > that calls getexecuser() in order to find whether there is a specific
> > > treatment needed. If this specific treatment is needed, then the shell calls
> > > execve(/usr/bin/pfexec cmd <args>)
> > > else it calls  execve(cmd <args>)
> > > 
> > > I did recently voted to require all shells to be profile enabled by default.
> >
> > Why? I asume there will only be few programs requiring to be run by a
> > wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo;
> > echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo;
> > chmod 755 /usr/bin/foo
> > should be easier than patching e.g. all callers of cdrecord, and it won't
> > slow down starting non-profiled applications.
> 
> Because the architecture review commitee decided this would be the right way.
> 
> Note that we are on a migration from the classical root/non-root UNIX to a fine 
> grained privileges handling. The current documentation says that you need to 
> have a profile enabled shell as your SHELL in order to be able to use a 
> root-less Solaris.

If the shell was the only program calling cdrecord, this would work out as 
expected.
-- 
My mail reader can beat up your mail reader. 

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

[Albert Cahalan]

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

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

**sigh**

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

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

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

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

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

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

[Joerg Schilling]

Albert Cahalan <acahalan@gmail.com> wrote:

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

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


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

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

libscg includes 22 different SCSI low level transport implementations.

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

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

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

Conclusion:

17 Platforms _need_ the addressing scheme libscg offers

5  Platforms _may_ use a different access method too.

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


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



Jörg

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

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

[Kyle Moffett]

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

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

> libscg includes...

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

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

No, you have this wrong:

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

- Only 4 others allow /dev/hd*

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

> [irrelevant discussion of other platforms]

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

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

You are perfectly free to adjust your compatibility layer accordingly.

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

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

Cheers,
Kyle Moffett

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

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

[Matthias Andree]

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

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

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

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

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

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

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

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

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

[Joerg Schilling]

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

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

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


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

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

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

Jörg

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

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

[Matthias Andree]

Joerg Schilling wrote:

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

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

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

[Joerg Schilling]

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

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

This is the main point.

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

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

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

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

Jörg

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

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

[jerome lacoste]

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

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

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

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

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

Jerome

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

[Joerg Schilling]

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


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

On the vast majority of OS this does not work.

Jörg

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

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

[Gene Heskett]

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

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

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

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

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

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

[jerome lacoste]

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

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

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

Sorry but I don't buy any of that.

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

Jerome

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

[Valdis.Kletnieks]

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

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

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

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

.. What does WinXP call the CD writer device?

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

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

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


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

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

[Joerg Schilling]

Valdis.Kletnieks@vt.edu wrote:

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

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

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

Jörg

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

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

[Kyle Moffett]

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

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

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

Cheers,
Kyle Moffett

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

[Matthias Andree]

On Fri, 27 Jan 2006, Joerg Schilling wrote:

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

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

-- 
Matthias Andree

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-26:

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

So there is no real reason.

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

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

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

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

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

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

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

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

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

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

-- 
Matthias Andree

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

[Jens Axboe]

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

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

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

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

-- 
Jens Axboe

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

[Joerg Schilling]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

> > [irrelevant discussion of other platforms]

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


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

Your last line is wrong 

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

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


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

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

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

Jörg

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

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

[Kyle Moffett]

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

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

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

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

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

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

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

Because I didn't see them.

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

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

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

Cheers,
Kyle Moffett

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

[Joerg Schilling]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

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

Looks like you missunderstood /dev/* here.

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




Jörg

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

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-26:

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

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

-- 
Matthias Andree

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

[Joerg Schilling]

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

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

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

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

Jörg

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

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

[sean]

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

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

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

Sean

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

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-25:

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

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

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

Because ignoring attacks is more efficient.

-- 
Matthias Andree

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

[Joerg Schilling]

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

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

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

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

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

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

Jörg

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

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

[Vojtech Pavlik]

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

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

So can you now stop repeating this question, please?

It has no relevance to CD burning. 

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

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

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


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

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

[Olivier Galibert]

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

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

  OG.

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

[Vojtech Pavlik]

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

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

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

HAL interfaces the above and implements the desktop interface.

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

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[Olivier Galibert]

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

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

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

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


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

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


> HAL interfaces the above and implements the desktop interface.

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

  OG.

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

[Jan Engelhardt]

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

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


Jan Engelhardt
-- 

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

[Dmitry Torokhov]

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

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

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

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

--
Dmitry

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

[Vojtech Pavlik]

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

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[Jan Engelhardt]

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

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


Jan Engelhardt
-- 

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

[Vojtech Pavlik]

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

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[Vojtech Pavlik]

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

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

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

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

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

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

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

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

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

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

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


-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[Diego Calleja]

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

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

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

You can get the info even with a fancy output:

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

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

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

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



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

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

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

(yes, that "udi" path sucks)


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

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

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

[Olivier Galibert]

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

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

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


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

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


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

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

  OG.

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

[Diego Calleja]

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

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

2.6.16-rc1 here

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

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

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

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

(IOW: /sys/block/hdc)

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

[Joerg Schilling]

Vojtech Pavlik <vojtech@suse.cz> wrote:

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

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

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

This are the three most important Linux kernel bugs:

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

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

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

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

Jörg

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

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

[James Courtier-Dutton]

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

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

James

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

[Jan Engelhardt]

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

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

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

Now you're talking shop ;-)

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

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

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

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

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


Jan Engelhardt
-- 

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

[Joerg Schilling]

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

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

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

> >> -	/dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
> >> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
> >> As long as this bug is present, there is no way to see SG_IO via
> >> /dev/hd* as integral part of the Linux SCSI transport concept.
>
> Now you're talking shop ;-)
>
> Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
> curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
> for bus number, id or lun - independent of OS and/or cdrecord?

The drive does not return this information, but the SCSI subsystem creates
these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
be known to the SCSI sub-system and thus needs to have a SCSI subsystem
related instance number.


> >> -	If sending SCSI sia ATAPI, Linux under certain unknown conditions
> >> bastardizes the content of SCSI commands. A possible reason may be
> >> that it sends random data in the remainder between the actual SCSI
> >> cdb size and the ATAPI SCSI cdb size.
>
> Not so good (the content freakup). IMO, if one can play around with the 
> scsi tunnel (SG_IO) from userspace, commands should get through unmodified.
> If it's not cdrecord/libscg making my writer do coffee, it must be this 
> modification step.

????

> > I think it might also be useful to make a list of all the SCSI commands that
> > cdrecord uses. Including all the vendor specific ones. One could then verify
> > that the Linux kernel is passing them onto the device correctly.
>
> Or not, for that matter. There is surely a reason for the OS to do 
> something to userspace-provided SG_IO packets to prevent the worst.

Cdrecord is a program that needs to be able to send any SCSI command as 
it needs to be able to add new vendor unique commands for new drive/feature
support.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-30:

> > >> -	/dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
> > >> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
> > >> As long as this bug is present, there is no way to see SG_IO via
> > >> /dev/hd* as integral part of the Linux SCSI transport concept.
> >
> > Now you're talking shop ;-)
> >
> > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
> > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
> > for bus number, id or lun - independent of OS and/or cdrecord?
> 
> The drive does not return this information, but the SCSI subsystem creates
> these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
> be known to the SCSI sub-system and thus needs to have a SCSI subsystem
> related instance number.

We are talking about ATA and ATAPI drives here. They may use SCSI
commands, but the transport is different. My take is: the Kernel guys
have been refusing to invent a non-native enumeration scheme for
non-SCSI transports, and you have not provided evidence why this is
indispensable.

Why is it a *kernel* task to invent SCSI identifier for a non-SCSI
transport that does not have such identifiers, in addition to the device
name? libscg is already doing it for /dev/hd* and /dev/pg*.
How about USB or Firewire or SATA? Do they have ID or LUN?

Why isn't libscg simply scanning all transports exhaustively (i. e. not
stopping at EPERM) and inventing this itself? You're failing to answer
this questions for week now, even though you agreed resmgr or similar
setups were safe.

How is a user going to tell apart two devices of the same make and model
from -scanbus output? The answer is (s)he cannot.

Sounds unrealistic? Well, some orchestras sell fresh recordings half an
hour after the final chord, with some dozen CD writers...

> Cdrecord is a program that needs to be able to send any SCSI command as 
> it needs to be able to add new vendor unique commands for new drive/feature
> support.

Right, but evidently it does not need the kernel to invent numbering.
dev=/dev/hdc works today.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Christoph Hellwig]

On Mon, Jan 30, 2006 at 01:04:08PM +0100, Matthias Andree wrote:
> Why is it a *kernel* task to invent SCSI identifier for a non-SCSI
> transport that does not have such identifiers, in addition to the device
> name? libscg is already doing it for /dev/hd* and /dev/pg*.
> How about USB or Firewire or SATA? Do they have ID or LUN?

Nothing but SPI (parallel scsi) has a target id.  Everything that broadly
falls under SAM has luns.  Because SPI is dying transport the scsi
midlayer will get rid of having a mandatory target id mid-term.  Relying
on the target id to have any useful meaning is dangerous, it doesn't
have a really useful meaning on anything but SPI.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Jan 30, 2006 at 01:04:08PM +0100, Matthias Andree wrote:
> > Why is it a *kernel* task to invent SCSI identifier for a non-SCSI
> > transport that does not have such identifiers, in addition to the device
> > name? libscg is already doing it for /dev/hd* and /dev/pg*.
> > How about USB or Firewire or SATA? Do they have ID or LUN?
>
> Nothing but SPI (parallel scsi) has a target id.  Everything that broadly
> falls under SAM has luns.  Because SPI is dying transport the scsi
> midlayer will get rid of having a mandatory target id mid-term.  Relying
> on the target id to have any useful meaning is dangerous, it doesn't
> have a really useful meaning on anything but SPI.

And now please tell me how you believe this will be inplemented.....

Every kernel implementation I am aware of uses device instance numbers
and BTW: I am open for any non-dogmatic discussion.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Christoph Hellwig]

On Mon, Jan 30, 2006 at 05:15:20PM +0100, Joerg Schilling wrote:
> > Nothing but SPI (parallel scsi) has a target id.  Everything that broadly
> > falls under SAM has luns.  Because SPI is dying transport the scsi
> > midlayer will get rid of having a mandatory target id mid-term.  Relying
> > on the target id to have any useful meaning is dangerous, it doesn't
> > have a really useful meaning on anything but SPI.
> 
> And now please tell me how you believe this will be inplemented.....

There's very little places left that need to know about the target id.
A few month ago we had a detailed list on linux-scsi, but off my head these
are:

 - sdev_printk prints the device identifier which right now includes the
   target id.  this will become a transport class callout so the transport
   can print transport-specific information
 - various scanning interfaces (scsi_scan_host_selected, scsi_scan_target,
   scsi_add_device) require a channel id.  scsi_scan_target will lose the
   id parameter because it doesn't even need it, the others will move out
   of the core into the spi transport class or another module for all spi-like
   drivers, as lots of RAID HBAs want SPI-like scanning
 - starget_for_each_device does id comparims currently, but it can be changed
   to iterate the targets parent devices list easily.

with those smaller bits the scsi core doesn't need to know about the
target id anymore.

now all this is rather pointless as you really love your scheme and don't
want to change anyway, so let's stop this discussion ;-)

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> > Cdrecord is a program that needs to be able to send any SCSI command as 
> > it needs to be able to add new vendor unique commands for new drive/feature
> > support.
>
> Right, but evidently it does not need the kernel to invent numbering.
> dev=/dev/hdc works today.

Maybe, I will need to enforce to use official libscg device names in future....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-30:

> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > > Cdrecord is a program that needs to be able to send any SCSI command as 
> > > it needs to be able to add new vendor unique commands for new drive/feature
> > > support.
> >
> > Right, but evidently it does not need the kernel to invent numbering.
> > dev=/dev/hdc works today.
> 
> Maybe, I will need to enforce to use official libscg device names in future....

If you deem fighting your own user base the appropriate behavior to
enforce your distorted view on groups that outnumber you by at least
five orders of magnitude, go right ahead.

But don't complain if you're losing control that way because Albert or
somebody else really forks cdrecord then and the fork becomes more
popular than the original.

cdrecord wouldn't be the first package to see such things happen.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> > > Right, but evidently it does not need the kernel to invent numbering.
> > > dev=/dev/hdc works today.
> > 
> > Maybe, I will need to enforce to use official libscg device names in future....
>
> If you deem fighting your own user base the appropriate behavior to
> enforce your distorted view on groups that outnumber you by at least
> five orders of magnitude, go right ahead.
>
> But don't complain if you're losing control that way because Albert or
> somebody else really forks cdrecord then and the fork becomes more
> popular than the original.

Many people announced forks in the past, nobody so far did contribute real 
work... 

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-30:

> Many people announced forks in the past, nobody so far did contribute real 
> work... 

Only the DVD patches...

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> Many people announced forks in the past, nobody so far did contribute real 
>> work... 
>
>Only the DVD patches...
>
Which don't always work. I remember SUSE Linux's pomped-up cdrecord-blahdvd 
thing can't even do DVD-Plus-*, not to mention DVD-DL (some sort of 
DVD-Plus).




Jan Engelhardt
-- 
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jeff Garzik]

Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> 
>>>Cdrecord is a program that needs to be able to send any SCSI command as 
>>>it needs to be able to add new vendor unique commands for new drive/feature
>>>support.
>>
>>Right, but evidently it does not need the kernel to invent numbering.
>>dev=/dev/hdc works today.
> 
> 
> Maybe, I will need to enforce to use official libscg device names in future....

To burden users with yet another naming policy?

	Jeff

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Jeff Garzik <jgarzik@pobox.com> wrote:

> >>>Cdrecord is a program that needs to be able to send any SCSI command as 
> >>>it needs to be able to add new vendor unique commands for new drive/feature
> >>>support.
> >>
> >>Right, but evidently it does not need the kernel to invent numbering.
> >>dev=/dev/hdc works today.
> > 
> > 
> > Maybe, I will need to enforce to use official libscg device names in future....
>
> To burden users with yet another naming policy?

Well, I am open to have an unbiased discussion that may have any result but 
the parties should allow each other to convince by arguments.

The main problem currently is that changes in the Linux kernel did burden
cdrecord users and did not cause real benefit.

The longer this discussion lasts, the more I lose the hope that it may end
in useful results. If you believe that there is still a chance, let us start
with a useful discussion or stop it now.

I am just tired to see that none of the Linux kernel bugs that cause problems
for the cdrecord users have been fixed within the last ~ 3 years. Please 
understand that I really could use my time for better things than wasting
it with useless discussions with people that don't even understand the problems.

If you have a proposal that could help, you are welcome. But if there is
no way to have an unbiased discussion, just let os stop now.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> >>>Cdrecord is a program that needs to be able to send any SCSI command as 
>> >>>it needs to be able to add new vendor unique commands for new drive/feature
>> >>>support.
>> >>
>> >>Right, but evidently it does not need the kernel to invent numbering.
>> >>dev=/dev/hdc works today.
>> > 
>> > Maybe, I will need to enforce to use official libscg device names in future....
>>
>> To burden users with yet another naming policy?
>
>Well, I am open to have an unbiased discussion that may have any result but 
>the parties should allow each other to convince by arguments.
>
The user should use what the OS uses. Cdrecord, or libscg, respectively, 
can invent any numbers it wants. IOW, "we" (read: I) would like to see
  cdrecord -dev=/dev/hdc on Linux

I am not sure if I understood your other mail on the cdrecord ML, but if 
the proper syntax would be
  cdrecord -dev=/dev/hdc:@
then
  /dev/hdc
could just be transparently turned into
  /dev/hdc:@
somewhere within the getopt part.

for other OS:
  cdrecord -dev=/dev/acd0 on FreeBSD
  cdrecord -dev=E: on Win32
    cdrecord -dev=\\cdrom0 if someone really wants for Win32
  cdrecord -dev=/dev/c0t0s0d0 on Solaris
(Don't shoot me. I unfortunately have to make a guess, since I have 
not done yet any cdrecord'ing[1] on OS other than Linux.)

[1] Well with Nero, but that's not cdrecord, as in "cdrecord'ing". :)


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> The user should use what the OS uses. Cdrecord, or libscg, respectively, 
> can invent any numbers it wants. IOW, "we" (read: I) would like to see
>   cdrecord -dev=/dev/hdc on Linux

Unsupported

> I am not sure if I understood your other mail on the cdrecord ML, but if 
> the proper syntax would be
>   cdrecord -dev=/dev/hdc:@
> then
>   /dev/hdc
> could just be transparently turned into
>   /dev/hdc:@
> somewhere within the getopt part.

See complete description, the :@ is not just for fun....

> for other OS:
>   cdrecord -dev=/dev/acd0 on FreeBSD

Will not work

>   cdrecord -dev=E: on Win32

Will only wbe doable with mapping effort in a few cases.

>     cdrecord -dev=\\cdrom0 if someone really wants for Win32

	cdrecord dev=cdrom0 	works on Solaris because "cdrom0"
				is a valid nick name for the drive.

>   cdrecord -dev=/dev/c0t0s0d0 on Solaris

May work sometimes.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 949 bytes --]

>
>> I am not sure if I understood your other mail on the cdrecord ML, but if 
>> the proper syntax would be
>>   cdrecord -dev=/dev/hdc:@
>> then
>>   /dev/hdc
>> could just be transparently turned into
>>   /dev/hdc:@
>> somewhere within the getopt part.
>
>See complete description, the :@ is not just for fun....
>

       "If  the name of the device node that has been speci■
       fied on such a system refers to exactly one SCSI device, a shorthand in
       the form dev= devicename:@ or dev= devicename:@,lun may be used instead
       of dev= devicename:scsibus,target,lun."

So @ is equal to 0,0,0 or 0,0?


Threads indicated that every device under linux is "exactly one SCSI device",
which is why I was asking for this behind-the-scenes translation of /dev/hdc
into /dev/hdc:@.

>> for other OS:
>>   cdrecord -dev=/dev/acd0 on FreeBSD
>
>Will not work
>
I think mount uses this syntax (`mount /dev/acd0 /mnt`).



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >
> >> I am not sure if I understood your other mail on the cdrecord ML, but if 
> >> the proper syntax would be
> >>   cdrecord -dev=/dev/hdc:@
> >> then
> >>   /dev/hdc
> >> could just be transparently turned into
> >>   /dev/hdc:@
> >> somewhere within the getopt part.
> >
> >See complete description, the :@ is not just for fun....
> >
>
>        "If  the name of the device node that has been speciâ? 
>        fied on such a system refers to exactly one SCSI device, a shorthand in
>        the form dev= devicename:@ or dev= devicename:@,lun may be used instead
>        of dev= devicename:scsibus,target,lun."
>
> So @ is equal to 0,0,0 or 0,0?

":@" is a shorthand for ":@,0" which is a shorthand for ":@0,0" 

There are cases where you may like to use e.g. ":@,3"

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>>
>> So @ is equal to 0,0,0 or 0,0?
>
>":@" is a shorthand for ":@,0" which is a shorthand for ":@0,0" 
>
>There are cases where you may like to use e.g. ":@,3"
>

So, since Linux currently does not have anything but ":@,0" per device 
(device file)...


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jürg Billeter]

Hi Jörg

On Mon, 2006-01-30 at 12:43 +0100, Joerg Schilling wrote:
> > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
> > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
> > for bus number, id or lun - independent of OS and/or cdrecord?
> 
> The drive does not return this information, but the SCSI subsystem creates
> these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
> be known to the SCSI sub-system and thus needs to have a SCSI subsystem
> related instance number.

Whenever someone talks about ATAPI drives, you respond with
s/ATAPI/SCSI/. Why do you insist that every transport should be used as
it was a SCSI bus? ATAPI drives use the same SCSI command set as SCSI
drives do, but that won't change the fact that ATAPI drives are not
connected to a SCSI bus.

It makes sense to address parallel SCSI devices via target id. If an
operating system likes to simulate virtual SCSI buses for other bus
types as well, ok, I have no objections. But if the operating system
doesn't like to simulate virtual SCSI buses and allows applications to
address devices by a filename, you should have no objections, too.

You and the linux developers just look at the same thing from two
perspectives. You seem to like SCSI buses, so you want to look at every
bus as it is was a SCSI bus. The linux developers seem to like the
principle of looking at single devices without obvious connection to a
physical or virtual bus from the application. There is no right or
wrong, here, that are just two different perspectives. As the linux
developers seem to like their approach - I do as well -, they won't
change their system and recommend application developers to use SG_IO on
device nodes and ignore the physical bus the devices are connected with.

Whatever the interface between cdrecord and libscg is, is obviously your
choice. But the libscg backend for linux should follow the
recommendations of the linux kernel developers and they recommend to use
SG_IO on device nodes, AFAICT. The command line interface of cdrecord is
obviously your choice again but IMO it should integrate in the system it
currently runs on and as linux command line users know how to deal with
device nodes, they want to use them.

As you were having the SCSI-only perspective in mind when writing the
scanbus functionality, it obviously doesn't fit well in the scheme of
the device-based perspective of linux. As there is no virtual parent of
all real and virtual SCSI buses in linux, libscg shouldn't try to find
one. The linux backend of libscg should just use HAL to enumerate the
devices.

It would be nice to get a comment whether this makes sense or which
statements you don't agree with.

Schönen Abend

Jürg
-- 
Jürg Billeter <j@bitron.ch>

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Jürg Billeter <j@bitron.ch> wrote:

> Hi Jörg
>
> On Mon, 2006-01-30 at 12:43 +0100, Joerg Schilling wrote:
> > > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of 
> > > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked 
> > > for bus number, id or lun - independent of OS and/or cdrecord?
> > 
> > The drive does not return this information, but the SCSI subsystem creates
> > these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
> > be known to the SCSI sub-system and thus needs to have a SCSI subsystem
> > related instance number.
>
> Whenever someone talks about ATAPI drives, you respond with
> s/ATAPI/SCSI/. Why do you insist that every transport should be used as
> it was a SCSI bus? ATAPI drives use the same SCSI command set as SCSI
> drives do, but that won't change the fact that ATAPI drives are not
> connected to a SCSI bus.

Well, this is simple: it is SCSI.

When SCSI started from modifying the SASI (Shugart Asociated System Interface)
system around 1984 and at that time come with it's own transport only
(a 50 wire cable), this did change soon (around 1986) by introducing
transports that use one or two 68 wire cable(s) (16 resp. 32 Bit SCSI).

Around 1990, even this did change while ATAPI (ATA Packet Interface) was
introduced. 

Around 1995, the T10 standard group (SCSI) did split up the SCSI standard
into a transport specific part and a protocol specific part. SCSI is now using
many different transport mechanisms.

This is a list of some known SCSI transports: 
 
	-	Good old Parallel SCSI 50/68 pin (what most people call SCSI) 
	-	SCSI over fiber optics (e.g. FACL - there are others too) 
	-	SCSI over a copper variant of FCAL (used in modern servers) 
	-	SCSI over IEEE 1394 (Fire Wire) 
	-	SCSI over USB 
	-	SCSI over IDE/ATA (ATAPI) 
	-	SCSI over TCI/IP (iSCSI)
	-	SCSI over SSCSI (see below)

SCSI over Serial SCSI cabling uses the same transport (cable type) as SATA uses.
If you buy a SATA HBA card for your PC, you may connect SSCSI & SATA
disks to this HBA using the same cables and connectors.

So the circle is closing again....


> It makes sense to address parallel SCSI devices via target id. If an
> operating system likes to simulate virtual SCSI buses for other bus
> types as well, ok, I have no objections. But if the operating system
> doesn't like to simulate virtual SCSI buses and allows applications to
> address devices by a filename, you should have no objections, too.

It seems that you missunderstand this. No operating system uses file names
internally. OS instead typically handle SCSI devices that are not connected
via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system
by asuming they are all on separate SCSI busses that only have one single drive 
conected each.

What Linux does is to artificially prevent this view to been seen from outside the
Linux kernel, or to avoid integrating a particular device into a unique SCSI
driver system although it would be apropriate.

Users like to be able to get a list of posible targets for a single protocol.
Nobody would ever think about trying to prevent people from getting a unified
view on the list possible hosts that talk TCP/IP. What cdrecord does with
-scanbus is nothing really different. 

In addition, nobody would ever think about implementing a separate TCP/IP stack 
for network interfaces that are PPP connections via a modem vs. network 
interfaces that go via a Ethernet adaptor. Nobody would ever try to convince
me that you could save code in the kernel by avoiding the usual network stack 
as a specific machine may not have Ethernet but a Modem connection only.

So why do people try to convince me that there is a need to avoid the standard 
SCSI protocol stack because a PC might have only ATAPI? 

Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, 
...). Why do people believe that Linux needs to be different? What does it buy 
you to go this way?


*] MS-WIN-NT even includes SCSI emulation (it allows you to connect to the
SCSI subsystem, set the Address and use SCSI commands from a limited list
to read/write sector from ATA only hard disks).

If the Linux folks could give technical based explanations for the questions 
from above and if they would create a new completely orthogonal view on SCSI [*]
I had no problem. But up to now, the only answer was: "We do it this 
way because we do it this way". 

*] Note that this would need to implement SCSI Generic support for drives that
have no native driver in the system.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello Jörg!

> It seems that you missunderstand this. No operating system uses file names
> internally.

That's right. OS kernels usually use pointers for that, which are surely
not a reasonable user-space API. On Linux, the user-space API is to address
devices by their names.

> OS instead typically handle SCSI devices that are not connected
> via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system
> by asuming they are all on separate SCSI busses that only have one single drive 
> conected each.
> 
> What Linux does is to artificially prevent this view to been seen from outside the
> Linux kernel, or to avoid integrating a particular device into a unique SCSI
> driver system although it would be apropriate.

How exactly does Linux prevent this???

The devices _are_ integrated in a single driver system, at least from the user-space
point of view. You can call open() on the device name and then send the appropriate
ioctl's. The device names are just strings you shouldn't assume anything about.

Feel free to imagine that every device is on its own bus, nothing in the
kernel steps in your way.

> Users like to be able to get a list of posible targets for a single protocol.
> Nobody would ever think about trying to prevent people from getting a unified
> view on the list possible hosts that talk TCP/IP.

How do you perform -scanbus for TCP/IP? :-)

> In addition, nobody would ever think about implementing a separate TCP/IP stack 
> for network interfaces that are PPP connections via a modem vs. network 
> interfaces that go via a Ethernet adaptor. Nobody would ever try to convince
> me that you could save code in the kernel by avoiding the usual network stack 
> as a specific machine may not have Ethernet but a Modem connection only.

There is an interesting similarity: in the TCP/IP stack, you also shouldn't
assume anything about names of network interfaces, they are just opaque
identifiers (in many times assigned by the administrator, not by the kernel).
The right way of addressing is by IP addresses or DNS names, which is
pretty similar to the addressing of SCSI devices on Linux, isn't it?

> If the Linux folks could give technical based explanations for the questions 
> from above and if they would create a new completely orthogonal view on SCSI [*]
> I had no problem. But up to now, the only answer was: "We do it this 
> way because we do it this way". 

We do it this way, because we see no sense in fabricating virtual SCSI
buses, which do not exist in reality.

Also, I don't see a single reason why should I refer to my CD drive by
different names depending on whether I am mounting a CDROM and if I am
burning a CD. The device is still the same and so should be its name.

Scanning for all available CD burners is of course a nice feature, but
I don't think it should be implemented by asking all existing SCSI-like
devices if they are a CD burner (for example because there can be an
almost infinite number of them, given that you can do SCSI-over-IP
and other similar tricks). The problem of presenting devices to the
users is in no way limited to CD burners or SCSI devices, it's a general
problem and I think we should try to find a complete solution. However,
the approach libscg uses is clearly not applicable to other domains.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> > What Linux does is to artificially prevent this view to been seen from outside the
> > Linux kernel, or to avoid integrating a particular device into a unique SCSI
> > driver system although it would be apropriate.
>
> How exactly does Linux prevent this???

By not treating ATAPI the same as all other SCSI devices.


> > Users like to be able to get a list of posible targets for a single protocol.
> > Nobody would ever think about trying to prevent people from getting a unified
> > view on the list possible hosts that talk TCP/IP.
>
> How do you perform -scanbus for TCP/IP? :-)

There are various programs that do that for you.
You could e.g. send a ping to the broadcast address in order to find hosts
that are on the local network.


> > In addition, nobody would ever think about implementing a separate TCP/IP stack 
> > for network interfaces that are PPP connections via a modem vs. network 
> > interfaces that go via a Ethernet adaptor. Nobody would ever try to convince
> > me that you could save code in the kernel by avoiding the usual network stack 
> > as a specific machine may not have Ethernet but a Modem connection only.
>
> There is an interesting similarity: in the TCP/IP stack, you also shouldn't
> assume anything about names of network interfaces, they are just opaque
> identifiers (in many times assigned by the administrator, not by the kernel).
> The right way of addressing is by IP addresses or DNS names, which is
> pretty similar to the addressing of SCSI devices on Linux, isn't it?

If you understand this, why then insists other people in using names like 
/dev/hd*?



> Scanning for all available CD burners is of course a nice feature, but
> I don't think it should be implemented by asking all existing SCSI-like
> devices if they are a CD burner (for example because there can be an
> almost infinite number of them, given that you can do SCSI-over-IP
> and other similar tricks). The problem of presenting devices to the

And while this kind of scanning works in case that you have all devices 
integrated inside a single SCSI implementation, it does not work for ATAPI
because someont artificially decided to exclude one single SCSI transport 
from the global view.

And regarding iSCSI, If you like to talk to such a device, you need to 
authentificate first. This is typically done by the kernel that in turn
trnaferres the remote iSCSI device into a virtual local SCSI device.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

[stripping Cc: list]

Joerg Schilling schrieb am 2006-01-31:

> Martin Mares <mj@ucw.cz> wrote:
> 
> > > What Linux does is to artificially prevent this view to been seen from outside the
> > > Linux kernel, or to avoid integrating a particular device into a unique SCSI
> > > driver system although it would be apropriate.
> >
> > How exactly does Linux prevent this???
> 
> By not treating ATAPI the same as all other SCSI devices.

Nonsense. cdrecord can access ATAPI devices, fix your libscg device
enumeration.

> > How do you perform -scanbus for TCP/IP? :-)
> 
> There are various programs that do that for you.
> You could e.g. send a ping to the broadcast address in order to find hosts
> that are on the local network.

Responding to broadcast ping, at least when outside the LAN, is
considered a security issue.

> > Scanning for all available CD burners is of course a nice feature, but
> > I don't think it should be implemented by asking all existing SCSI-like
> > devices if they are a CD burner (for example because there can be an
> > almost infinite number of them, given that you can do SCSI-over-IP
> > and other similar tricks). The problem of presenting devices to the
> 
> And while this kind of scanning works in case that you have all devices 
> integrated inside a single SCSI implementation, it does not work for ATAPI
> because someont artificially decided to exclude one single SCSI transport 
> from the global view.

You need to work around this anyhow because the already-released 2.6
kernels will not be going away in the next 2 - 3 years even if 2.6
were fixed today.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello!

> > How exactly does Linux prevent this???
> 
> By not treating ATAPI the same as all other SCSI devices.

Sorry, but that's false. Not treating ATAPI the same can at most
complicate it, but in no way prevent.

> > How do you perform -scanbus for TCP/IP? :-)
> 
> There are various programs that do that for you.
> You could e.g. send a ping to the broadcast address in order to find hosts
> that are on the local network.

Eh, so you are just going to treate the local network differently? ;-)

> If you understand this, why then insists other people in using names like 
> /dev/hd*?

Because at least on Linux, the NAMES are the primary identifier for user
space, not numbers of some virtual SCSI buses which don't exist in the
real world anyway.

For everything else (well, except network interfaces, but that's a different
story), we refer by names. Even when using the SCSI devices for other
purposes, we refer to them by names. Why should burning a CD be different?

I believe that this is the crucial question and the one you should
answer first, before trying to force others to share your view of the world.

> And while this kind of scanning works in case that you have all devices 
> integrated inside a single SCSI implementation, it does not work for ATAPI
> because someont artificially decided to exclude one single SCSI transport 
> from the global view.

No, you are just wrongly considering something to be a global view,
which it in fact isn't.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
How do I type 'for i in *.dvi ; do xdvi $i ; done' in a GUI?

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> > Users like to be able to get a list of posible targets for a single protocol.
>> > Nobody would ever think about trying to prevent people from getting a unified
>> > view on the list possible hosts that talk TCP/IP.
>>
>> How do you perform -scanbus for TCP/IP? :-)
>
>There are various programs that do that for you.
>You could e.g. send a ping to the broadcast address in order to find hosts
>that are on the local network.

ping is ICMP/IP, therefore is not relevant to the question ;)
`nmap -sT` would probably do more TCP.

>If you understand this, why then insists other people in using names like 
>/dev/hd*?

It's shorter than /dev/c0t0d0s0? Well, I think it's because people think 
in terms of connectors (my drive is IDE therefore it must be hdc) rather 
than protocol (my drive does ATAPI therefore it must be 
/dev/scsi/c0t0d0s0).


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Ian Kester-Haney]

Shouldn't actively developed applications use the current methods for
accessing ddevices on target operating systems.  It seems to me that
linux/gnu users are moving away from cdrecord and it ilk because of
the artificial limitations imposed by its libscg counterpart. 
Backward compatibility is being phased out in the linux kernel to
allow for better ways to access and use devices in the system.  While
the technical nature of transport specifications might be tracked down
to an underlying SCSI mechanism, it is by no means an exclusive deal. 
Perhaps linux doesn't need cdrecord and this whole mess will go away.
Real users don't care as long as it works, even the old kernel used
/dev/* names.
Give it up.

---------------------------------------------
Only morons respond to flames
guilty as charged
----------------------------------------------

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> It's shorter than /dev/c0t0d0s0? Well, I think it's because people think 
> in terms of connectors (my drive is IDE therefore it must be hdc) rather 
> than protocol (my drive does ATAPI therefore it must be 
> /dev/scsi/c0t0d0s0).

Is there any reason why the people with small PCs should dominate the 
people with big machines?

If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks.

The systematical attempt is easy to remember even with a big amount of 
external hardware.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello!

> Is there any reason why the people with small PCs should dominate the 
> people with big machines?
> 
> If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks.

And this is why the current Linux naming scheme (udev etc.) gives you
the possibility to use both types of names.

When I have a single CD writer, it's silly to have to think about where
exactly it is connected. I refer to it as /dev/cdrw and everything is easy.

When I have multiple writers, I start to care about more -- but usually
it's still better to avoid using bus addresses (they are not too stable
-- after changing disks, I often end up with connecting my 2 CDWR's
to different controllers) and use udev to maintain stable naming.
I use /dev/cdrom-upper and /dev/cdrom-lower, which are assigned based
on manufacturer and serial number.

This is even easier to remember with a big amount of hardware :-)

And, which is more important, this scheme works for everything --
drives, mice, network interfaces and so on.

I don't see any reason why cdrecord on Linux should invent a different
naming scheme, especially as nobody has so far demonstrated any of its
advantages.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
MIPS: Meaningless Indicator of Processor Speed.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-02:

> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > It's shorter than /dev/c0t0d0s0? Well, I think it's because people think 
> > in terms of connectors (my drive is IDE therefore it must be hdc) rather 
> > than protocol (my drive does ATAPI therefore it must be 
> > /dev/scsi/c0t0d0s0).
> 
> Is there any reason why the people with small PCs should dominate the 
> people with big machines?

No side should dominate.

> If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks.

I don't see how a letter such as /dev/hdo /dev/hdp /dev/hdq is much
different than an opaque number tuple as 1,15,0 1,16,0 1,17,0... either
is a string with systematic generation, and that's about it.

I'm still wondering why mtst (mid-layer access to control tape drives)
is happy with /dev/nst0 nst1 ... (device name) and cdrecord (or its
author) isn't. cdrecord or libscg should be agnostic of these schemas
and take any opaque string that works properly for the given system
without complaining. It can invent any numbering scheme it likes, but
requesting that the kernel does it if it has no further use for it is
barking up the wrong tree.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bartlomiej Zolnierkiewicz]

On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Jürg Billeter <j@bitron.ch> wrote:
>
> > Hi Jörg
> >
> > On Mon, 2006-01-30 at 12:43 +0100, Joerg Schilling wrote:
> > > > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of
> > > > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked
> > > > for bus number, id or lun - independent of OS and/or cdrecord?
> > >
> > > The drive does not return this information, but the SCSI subsystem creates
> > > these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
> > > be known to the SCSI sub-system and thus needs to have a SCSI subsystem
> > > related instance number.
> >
> > Whenever someone talks about ATAPI drives, you respond with
> > s/ATAPI/SCSI/. Why do you insist that every transport should be used as
> > it was a SCSI bus? ATAPI drives use the same SCSI command set as SCSI
> > drives do, but that won't change the fact that ATAPI drives are not
> > connected to a SCSI bus.
>
> Well, this is simple: it is SCSI.
>
> When SCSI started from modifying the SASI (Shugart Asociated System Interface)
> system around 1984 and at that time come with it's own transport only
> (a 50 wire cable), this did change soon (around 1986) by introducing
> transports that use one or two 68 wire cable(s) (16 resp. 32 Bit SCSI).
>
> Around 1990, even this did change while ATAPI (ATA Packet Interface) was
> introduced.
>
> Around 1995, the T10 standard group (SCSI) did split up the SCSI standard
> into a transport specific part and a protocol specific part. SCSI is now using
> many different transport mechanisms.
>
> This is a list of some known SCSI transports:
>
>         -       Good old Parallel SCSI 50/68 pin (what most people call SCSI)
>         -       SCSI over fiber optics (e.g. FACL - there are others too)
>         -       SCSI over a copper variant of FCAL (used in modern servers)
>         -       SCSI over IEEE 1394 (Fire Wire)
>         -       SCSI over USB
>         -       SCSI over IDE/ATA (ATAPI)
>         -       SCSI over TCI/IP (iSCSI)
>         -       SCSI over SSCSI (see below)
>
> SCSI over Serial SCSI cabling uses the same transport (cable type) as SATA uses.
> If you buy a SATA HBA card for your PC, you may connect SSCSI & SATA
> disks to this HBA using the same cables and connectors.
>
> So the circle is closing again....
>
>
> > It makes sense to address parallel SCSI devices via target id. If an
> > operating system likes to simulate virtual SCSI buses for other bus
> > types as well, ok, I have no objections. But if the operating system
> > doesn't like to simulate virtual SCSI buses and allows applications to
> > address devices by a filename, you should have no objections, too.
>
> It seems that you missunderstand this. No operating system uses file names
> internally. OS instead typically handle SCSI devices that are not connected
> via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system
> by asuming they are all on separate SCSI busses that only have one single drive
> conected each.
>
> What Linux does is to artificially prevent this view to been seen from outside the
> Linux kernel, or to avoid integrating a particular device into a unique SCSI
> driver system although it would be apropriate.
>
> Users like to be able to get a list of posible targets for a single protocol.
> Nobody would ever think about trying to prevent people from getting a unified
> view on the list possible hosts that talk TCP/IP. What cdrecord does with
> -scanbus is nothing really different.

Yes and it is Linux limitation (lets face it).   There are 2 problems:

* no generic block layer transport infrastructure so that you cannot
  specify in the low-level driver which transport types your device does
  support (this information would be exported to the applications).

  Jens, maybe sysfs attribute "transports" will be sufficient so that
  application  can use libsysfs to get full list of devices supporting "SCSI"
  transport (/dev/hd* is fine with this scheme).  Does it make sense?
  Having block layer sysfs attributes for device type (disk, tape, cd etc)
  would have additional bonus of not needing to inquire wrong device
  types.  This would probably simplify other applications (HAL?).
  [ These are just quick ideas... ]

  Joerg, I don't see any sense in providing users with fake SCSI
  lun and bus numbers for ATAPI devices.  I think that what users
  would like is the list of devices consisting of "fd" and actual vendor
  name of device (+ optionally serial no + optionally "x:y:z" for real
  SCSI).  Nobody wants to see some artificial "x:y:z" for her/his
  ATAPI device (it has always annoyed me in Windows), not to say
  that the majority of desktop users have absolutely no idea of meaning
  of these numbers.

* ide-* drivers for ATAPI devices are needed (some devices just doesn't
  work with ide-scsi ATM) so please accept this fact that we cannot just
  now simply switch over everything to using ide-scsi and we have to use
  SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add
  support for it).  I'm not saying this won't change in future but this requires
  doing actual work and people seem to be more interested in discussing
  stupid naming issues than doing it so...

> In addition, nobody would ever think about implementing a separate TCP/IP stack
> for network interfaces that are PPP connections via a modem vs. network
> interfaces that go via a Ethernet adaptor. Nobody would ever try to convince
> me that you could save code in the kernel by avoiding the usual network stack
> as a specific machine may not have Ethernet but a Modem connection only.
>
> So why do people try to convince me that there is a need to avoid the standard
> SCSI protocol stack because a PC might have only ATAPI?

SCSI protocol stack is far too Parallel SCSI centric (vide SAS flamewar).
Once again this is Linux problem which will get fixed with time or will fix
itself if we switch to libata for PATA.

> Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris,
> ...). Why do people believe that Linux needs to be different? What does it buy
> you to go this way?

Linux needs to be better, no? ;-)

> *] MS-WIN-NT even includes SCSI emulation (it allows you to connect to the
> SCSI subsystem, set the Address and use SCSI commands from a limited list
> to read/write sector from ATA only hard disks).
>
> If the Linux folks could give technical based explanations for the questions
> from above and if they would create a new completely orthogonal view on SCSI [*]
> I had no problem. But up to now, the only answer was: "We do it this
> way because we do it this way".

The answer is - we do this this way because of historical reasons and we
simply lack resources to change it immediately (be it your "everything is
SCSI" or mine "block layer devices claiming supported transport types").

Please also note things don't change because you say so - they require
somebody doing actual work and work/time is not free (despite what some
people think).  If you think that badmouthing Linux will motivate people to
work, you are wrong (it has the opposite effect of time wasting flamewars).

I would like you to ask to remove warnings from about /dev/hd* interface
from cdrecored - they are just confusing users.  This is the current way
of doing things in Linux and applications have to deal with it for now.

Thanks,
Bartlomiej

> *] Note that this would need to implement SCSI Generic support for drives that
> have no native driver in the system.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

>   Joerg, I don't see any sense in providing users with fake SCSI
>   lun and bus numbers for ATAPI devices.  I think that what users
>   would like is the list of devices consisting of "fd" and actual vendor
>   name of device (+ optionally serial no + optionally "x:y:z" for real
>   SCSI).  Nobody wants to see some artificial "x:y:z" for her/his
>   ATAPI device (it has always annoyed me in Windows), not to say
>   that the majority of desktop users have absolutely no idea of meaning
>   of these numbers.

This is called integration and it is done by Linux e.g. for 1394 and USB SCSI 
devices. So why not for ATAPI?


> * ide-* drivers for ATAPI devices are needed (some devices just doesn't
>   work with ide-scsi ATM) so please accept this fact that we cannot just
>   now simply switch over everything to using ide-scsi and we have to use
>   SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add
>   support for it).  I'm not saying this won't change in future but this requires
>   doing actual work and people seem to be more interested in discussing
>   stupid naming issues than doing it so...

Well, the problem with ide-scsi is not a general one but caused by a simple
bug that needs to be fixed.


> > So why do people try to convince me that there is a need to avoid the standard
> > SCSI protocol stack because a PC might have only ATAPI?
>
> SCSI protocol stack is far too Parallel SCSI centric (vide SAS flamewar).
> Once again this is Linux problem which will get fixed with time or will fix
> itself if we switch to libata for PATA.

If this is true for Linux, it should be fixed. But this is not a general 
problem.

> > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris,
> > ...). Why do people believe that Linux needs to be different? What does it buy
> > you to go this way?
>
> Linux needs to be better, no? ;-)

In case that Linux would offer better methods, I would not complain.


> > If the Linux folks could give technical based explanations for the questions
> > from above and if they would create a new completely orthogonal view on SCSI [*]
> > I had no problem. But up to now, the only answer was: "We do it this
> > way because we do it this way".
>
> The answer is - we do this this way because of historical reasons and we
> simply lack resources to change it immediately (be it your "everything is
> SCSI" or mine "block layer devices claiming supported transport types").

This is obviously not true: There _was_ (and still is) a useful implementation 
with minor bugs. But instead of fixing the minor bugs, a lot of work has been 
done to introduce a new and unneded new interface.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-01-31:

> > Linux needs to be better, no? ;-)
> 
> In case that Linux would offer better methods, I would not complain.

Well, you are closing your eyes before these methods. I'm not going to
repeat that.

I suggest that the discussion end here because you are evidently
unwilling to look at the pointers you were given.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello!

> This is obviously not true: There _was_ (and still is) a useful implementation 
> with minor bugs. But instead of fixing the minor bugs, a lot of work has been 
> done to introduce a new and unneded new interface.

Some would say that ide-scsi is the thing which was new and unneeded.
The ide-cd driver was there first.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Even nostalgia isn't what it used to be.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bartlomiej Zolnierkiewicz]

On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> >   Joerg, I don't see any sense in providing users with fake SCSI
> >   lun and bus numbers for ATAPI devices.  I think that what users
> >   would like is the list of devices consisting of "fd" and actual vendor
> >   name of device (+ optionally serial no + optionally "x:y:z" for real
> >   SCSI).  Nobody wants to see some artificial "x:y:z" for her/his
> >   ATAPI device (it has always annoyed me in Windows), not to say
> >   that the majority of desktop users have absolutely no idea of meaning
> >   of these numbers.
>
> This is called integration and it is done by Linux e.g. for 1394 and USB SCSI
> devices. So why not for ATAPI?

Because we have native drivers which do not require SCSI stack et all.

> > * ide-* drivers for ATAPI devices are needed (some devices just doesn't
> >   work with ide-scsi ATM) so please accept this fact that we cannot just
> >   now simply switch over everything to using ide-scsi and we have to use
> >   SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add
> >   support for it).  I'm not saying this won't change in future but this requires
> >   doing actual work and people seem to be more interested in discussing
> >   stupid naming issues than doing it so...
>
> Well, the problem with ide-scsi is not a general one but caused by a simple
> bug that needs to be fixed.

Please _reread_ this paragraph:
* some devices (not cd-writers) doesn't work with ide-scsi
* they require quirks which are in ide-cd so it ide-cd needs to stay as a driver
* if is very useful if cd-writing can be done with ide-cd and without SCSI stack
  (a hack but very useful one)

[ more below ]

> > > If the Linux folks could give technical based explanations for the questions
> > > from above and if they would create a new completely orthogonal view on SCSI [*]
> > > I had no problem. But up to now, the only answer was: "We do it this
> > > way because we do it this way".
> >
> > The answer is - we do this this way because of historical reasons and we
> > simply lack resources to change it immediately (be it your "everything is
> > SCSI" or mine "block layer devices claiming supported transport types").
>
> This is obviously not true: There _was_ (and still is) a useful implementation
> with minor bugs. But instead of fixing the minor bugs, a lot of work has been
> done to introduce a new and unneded new interface.

>From technical point of view:

pros:
* you don't need SCSI stack (a lot of code saved!)
* you use subsystem native driver (a lot of complexity with locking
etc avoided!)
* you don't need to provide users with fake data (SCSI lun and bus)

cons:
* user-space applications need to support it

What are the _technical_ problems with SG_IO interface besides
issue with enumaration of devices available in the system?

I know that you don't like SG_IO but it is hardly technical argument.

Thanks,
Bartlomiej

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>>
>> This is called integration and it is done by Linux e.g. for 1394 and USB SCSI
>> devices. So why not for ATAPI?
>
>Because we have native drivers which do not require SCSI stack et all.
>
>* if [ED: it] is very useful if cd-writing can be done with ide-cd and without
>  SCSI stack (a hack but very useful one)
>* you don't need SCSI stack (a lot of code saved!)


Which unfortunately leads us back to one of the early questions.

If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
floating around?



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bartlomiej Zolnierkiewicz]

On 2/1/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >>
> >> This is called integration and it is done by Linux e.g. for 1394 and USB SCSI
> >> devices. So why not for ATAPI?
> >
> >Because we have native drivers which do not require SCSI stack et all.
> >
> >* if [ED: it] is very useful if cd-writing can be done with ide-cd and without
> >  SCSI stack (a hack but very useful one)
> >* you don't need SCSI stack (a lot of code saved!)
>
>
> Which unfortunately leads us back to one of the early questions.
>
> If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
> without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
> floating around?

No, because this code belongs to the block layer (scsi_ioctl.c)
and is shared between SCSI and IDE drivers.

BTW This was already at least once explained in this thread.

Bartlomiej

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> Which unfortunately leads us back to one of the early questions.
>
> If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
> without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
> floating around?

CONFIG_SCSI???

Why not using fully dynamical loadable kernel modules as done with Solaris 
since 1992? Since that time nobody cares because what you need is auto-loaded 
on demand and there is absolutely no need for a manual configuration.

BTW: Introducing an orthogonal SCSI based implementation would save a lot of
code. The model currently used on Linux is duplicating a lot of unneeded code 
in target drivers and the SCSI glue code is only a few KB (less than 30k on 
Solaris). 

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-02:

> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > Which unfortunately leads us back to one of the early questions.
> >
> > If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
> > without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
> > floating around?
> 
> CONFIG_SCSI???
> 
> Why not using fully dynamical loadable kernel modules as done with Solaris 
> since 1992? Since that time nobody cares because what you need is auto-loaded 
> on demand and there is absolutely no need for a manual configuration.

You mean:

Module                  Size  Used by
...
scsi_transport_spi     20864  1 sym53c8xx
scsi_mod              131304  7 st,sr_mod,sg,sym53c8xx,scsi_transport_spi,libata,sd_mod
...

autoloaded on boot, and scsi_mod has verbose sense strings built in
(call it bloat, but on a Peeceeh a few kB don't hurt).

libata is Linux's SATA driver, still under development but quite solid
for some chips, such as via 82*. Chances are that adding PATA to libata
(which is planned or in the works) obsoletes your whole ATAPI ide-* module
arguments, sym53c8xx - no surprise - the host adaptor driver, sr/sd_mod
the CD-ROM and disk block drivers, st and sg tape and generic drivers.

> BTW: Introducing an orthogonal SCSI based implementation would save a lot of
> code. The model currently used on Linux is duplicating a lot of unneeded code 
> in target drivers and the SCSI glue code is only a few KB (less than 30k on 
> Solaris). 

You've been stating this oft enough now. It won't change in a day even
if you post this every hour. Please cease posting the same stuff over
and over again.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> > BTW: Introducing an orthogonal SCSI based implementation would save a lot of
> > code. The model currently used on Linux is duplicating a lot of unneeded code 
> > in target drivers and the SCSI glue code is only a few KB (less than 30k on 
> > Solaris). 
>
> You've been stating this oft enough now. It won't change in a day even
> if you post this every hour. Please cease posting the same stuff over
> and over again.

Why do you repeat posting false claims over and over?

May be we should really stop this thread.

Unless I see any move towards a more realistic way of looking at things
it does not make sense to repeat things and short time later I will see
the same unadequate replies as I did see days before.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello Joerg!

> > > BTW: Introducing an orthogonal SCSI based implementation would save a lot of
> > > code. The model currently used on Linux is duplicating a lot of unneeded code 
> > > in target drivers and the SCSI glue code is only a few KB (less than 30k on 
> > > Solaris). 
> >
> > You've been stating this oft enough now. It won't change in a day even
> > if you post this every hour. Please cease posting the same stuff over
> > and over again.
> 
> Why do you repeat posting false claims over and over?

This is getting ridiculous. Point to a single false claim in the mail
you were replying to.

The only claim there was that you are posting the same stuff again and
again, and it is obviously true, as can be demostrated by anybody who
can use grep.

> Unless I see any move towards a more realistic way of looking at things
> it does not make sense to repeat things and short time later I will see
> the same unadequate replies as I did see days before.

Yes. You have been repeatedly asked to produce any sound arguments why the
current interface is bad.

So far, you have produced none. You have only written about Linux not
following your personal model of virtual SCSI buses, which is maybe
a good argument for supporting your dislike for Linux, but nothing else.

Also, you mentioned several phantoms like IDE tapes, which nobody seems
to care about, a couple of bugs which the driver developers were willing
to fix if you tell how to reproduce them.

Finally, you mentioned problems with scanning and you were told that:
(1) the current scanning code in libscg works at least for all currently
existing transports, if a trivial bug is fixed,
(2) for a complete view of the available HW, you should use the HAL,
(3) most people prefer either using a GUI interface which converges to
using HAL anyway, or refer to devices by their names.

The rest was just hand-waving.

The interface preferred by Linux has changed for very good reasons,
and a number of such reasons has been demonstrated. Also, it's not
changing daily, the switchover from emulating SCSI to performing SG_IO
directly on /dev/hd* was the only big change in last 10 years.

So unless anybody has any new arguments for either approach, let's end
this thread.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Outside of a dog, a book is man's best friend. Inside a dog, it's too dark to read.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello!

> Why not using fully dynamical loadable kernel modules as done with Solaris 
> since 1992? Since that time nobody cares because what you need is auto-loaded 
> on demand and there is absolutely no need for a manual configuration.

Yes, but it still eats the memory if loaded.

> BTW: Introducing an orthogonal SCSI based implementation would save a lot of
> code. The model currently used on Linux is duplicating a lot of unneeded code 
> in target drivers and the SCSI glue code is only a few KB (less than 30k on 
> Solaris). 

Please stop beating a dead horse and diverting this discussion to irrelevant
implementation details.

What we were (and should be) discussing are the interfaces. If you have
any sound arguments against the current interface, speak up.

Whether the interface leads to code duplication is neither yours nor
mine to judge -- the only people who should care are the maintainers
of the drivers and they seem to be happy with the current approach
and they are willing to improve it to simplify scanning.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Beware of bugs in the above code; I have only proved it correct, not tried it." -- D.E.K.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jens Axboe]

On Thu, Feb 02 2006, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > Which unfortunately leads us back to one of the early questions.
> >
> > If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
> > without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
> > floating around?
> 
> CONFIG_SCSI???
> 
> Why not using fully dynamical loadable kernel modules as done with
> Solaris since 1992? Since that time nobody cares because what you need
> is auto-loaded on demand and there is absolutely no need for a manual
> configuration.
> 
> BTW: Introducing an orthogonal SCSI based implementation would save a
> lot of code. The model currently used on Linux is duplicating a lot of
> unneeded code in target drivers and the SCSI glue code is only a few
> KB (less than 30k on Solaris). 

I have to comment on that... Your original gripe was the we should not
have so much duplicated code - which of course was shot down, we don't
have much duplicated code, basically a few hundred lines at most. And
that solely remains because /dev/sg* still exists and isn't fully
integrated with bsg (the block layer sg, which is probably misnamed as
it could be used char devices as well).

So this mail from you basically shoots huge holes in your original
gripe. The whole SCSI stack is redundant code in this scheme. A quick
check over my current tree shows over 23 _thousand_ lines of code (SCSI
stack + ide-scsi)! Auto-loading modules has _nothing_ to do with it,
it's still redundant code.

I could go on, but the point should be crystal clear already so I'll
stop. Joerg, unless you have any technical arguments please stop this
thread. And here I do mean ones that are correct. You repeatedly either
ignore mails asking you to backup your claims - or you reply to them
saying "Please stop making false claims!". Honestly, I have no idea why
you are doing that.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> Which unfortunately leads us back to one of the early questions.
>>
>> If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used
>> without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code
>> floating around?
>
>CONFIG_SCSI???
>

What else?

>Why not using fully dynamical loadable kernel modules as done with Solaris 

Do you think I have scsi built-in? Not at all.

lsmod::
sg                     20120  0
sd_mod                 12304  0
usb_storage            73408  0
usbcore               108256  5 uhci_hcd,ohci_hcd,ehci_hcd,usb_storage
scsi_mod              103496  3 sg,sd_mod,usb_storage

/proc/config.gz:
CONFIG_SCSI=m
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_CONSTANTS=y

that's about all.

>since 1992? Since that time nobody cares because what you need is auto-loaded 
>on demand and there is absolutely no need for a manual configuration.


Jan Engelhardt
-- 
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: CD writing in future Linux (stirring up a hornets' nest)

[jerome lacoste]

On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Jürg Billeter <j@bitron.ch> wrote:
[...]
> Users like to be able to get a list of posible targets for a single protocol.

The Linux users (I know of) like to be able to reference their drives
the way their Operating System names them.

If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'.

Should we make a poll ?

Jerome

Re: CD writing in future Linux (stirring up a hornets' nest)

[Oliver Neukum]

Am Dienstag, 31. Januar 2006 13:24 schrieb jerome lacoste:
> On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > Jürg Billeter <j@bitron.ch> wrote:
> [...]
> > Users like to be able to get a list of posible targets for a single protocol.
> 
> The Linux users (I know of) like to be able to reference their drives
> the way their Operating System names them.
> 
> If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'.
> 
> Should we make a poll ?

It is entirely possible that the people you know are far from a representative
sample. Most people likely prefer clicking on a description in a GUI. There
needs to be a way to get this list and if possible it should not be specific
to Linux.

	Regards
		Oliver

Re: CD writing in future Linux (stirring up a hornets' nest)

[Denis Vlasenko]

On Tuesday 31 January 2006 14:33, Oliver Neukum wrote:
> Am Dienstag, 31. Januar 2006 13:24 schrieb jerome lacoste:
> > On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > > Jürg Billeter <j@bitron.ch> wrote:
> > [...]
> > > Users like to be able to get a list of posible targets for a single protocol.
> > 
> > The Linux users (I know of) like to be able to reference their drives
> > the way their Operating System names them.
> > 
> > If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'.
> > 
> > Should we make a poll ?
> 
> It is entirely possible that the people you know are far from a representative
> sample. Most people likely prefer clicking on a description in a GUI. There
> needs to be a way to get this list and if possible it should not be specific
> to Linux.

Do we need to expose IDE master/slave, primary/secondary concepts in Linux?

So far I was perfectly happy with just /dev/hd[a-z][0-9]*
--
vda

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> > If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'.
>> > 
>> > Should we make a poll ?

select(), poll(), epoll(), anyone? (SCNR)

>Do we need to expose IDE master/slave, primary/secondary concepts in Linux?
>
AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's
(surprisingly) the other way round, sda just happens to be the first disk
inserted (SCA, USB, etc.)


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bernd Petrovitsch]

On Wed, 2006-02-01 at 16:37 +0100, Jan Engelhardt wrote:
[...]
> >Do we need to expose IDE master/slave, primary/secondary concepts in Linux?
> >
> AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's
> (surprisingly) the other way round, sda just happens to be the first disk
> inserted (SCA, USB, etc.)

The (historical) reason was: There were not enough major/minor numbers
(IIRC 8 bit for each of them) for a sane (and static) SCSI device number
mapping (similar to IDE) - just multiply the possible # of partitions *
# of LUNs * # IDs for a few controllers.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: CD writing in future Linux (stirring up a hornets' nest)

[Albert Cahalan]

On 2/1/06, Bernd Petrovitsch <bernd@firmix.at> wrote:
> On Wed, 2006-02-01 at 16:37 +0100, Jan Engelhardt wrote:
> [...]
> > >Do we need to expose IDE master/slave, primary/secondary concepts in Linux?
> > >
> > AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's
> > (surprisingly) the other way round, sda just happens to be the first disk
> > inserted (SCA, USB, etc.)
>
> The (historical) reason was: There were not enough major/minor numbers
> (IIRC 8 bit for each of them) for a sane (and static) SCSI device number
> mapping (similar to IDE) - just multiply the possible # of partitions *
> # of LUNs * # IDs for a few controllers.

It's a hashing problem, and should have originally been seen as such.
The constraints are that you'd like some stability as devices come
and go. Splitting /dev into fields could have worked nicely:

1. the partition
2. dev type: disk, CD-ROM, built-in (ramdisk,loop), other
3. physical: master/slave, SCSI target, IDE 1/2/other, "is USB"...
4. volatile+rare stuff: PCI slot, ISA address, USB position, LUN

(needlessly crammed into 16 bits: 5:2:4:5 or 5:2:5:4)

For the physical stuff, per-driver values are assigned explicitly
in the source code. Collisions are determined by humans. We make
USB collide with something old, like XT disks and Atari disks.
Collisions are chosen so that normal machines are unlikely to
suffer from them.

Note that I use "IDE 1/2/other". Only an x86 PC can have a primary
or secondary controller, as determined by IO port location. Macs
just have "other", as a single value. (they differentiate based on
the rare and volatile stuff as needed) USB is distinguished from SCSI,
FireWire, and IDE unless delibrately made to collide because of a bit
shortage.

Collisions found at run-time are resolved by mucking with the field
for volatile and rare stuff. Adding a new USB device can will probably
not mess up a different USB device, because the hashing is not too
likely to pick the same number. Adding a new USB device will certainly
not mess up a non-USB device unless the non-USB device is in a class
of physical devices that was delibrately made to collide with USB.
Adding a SCSI device with target ID 4 will only stand a chance of
messing up other SCSI devices with target ID 4, on other busses or
with other LUNs. It wouldn't mess up SCSI target ID 3, FireWire, USB,
or anything else UNLESS those share the "physical" field ID.

Not that Joerg would like this: LUN values and bus numbers get tossed
into a hash function. You can't recover the individual numbers.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bartlomiej Zolnierkiewicz]

On 2/1/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >> > If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'.
> >> >
> >> > Should we make a poll ?
>
> select(), poll(), epoll(), anyone? (SCNR)
>
> >Do we need to expose IDE master/slave, primary/secondary concepts in Linux?
> >
> AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's

Ehm, primary master and it is not true if you are using host drivers as modules.

Moreover providing ordering by IDE driver has been nightmare to maintain
and can't be done correctly for 100% weird cases.

> (surprisingly) the other way round, sda just happens to be the first disk
> inserted (SCA, USB, etc.)

Which is much saner approach from developers' POV.

Bartlomiej

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> >Do we need to expose IDE master/slave, primary/secondary concepts in Linux?
>> >
>> AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's
>
>Ehm, primary master and it is not true if you are using host drivers as modules.
>
Whoops, you are right. However, even with, say, an extra PCI IDE controller,
the ordering of the drives within that controller is "as usual", e.g. the order
is "pri ma","pri sl","sec ma","sec sl", of course relative to the start of the
respective controller.

>Moreover providing ordering by IDE driver has been nightmare to maintain
>and can't be done correctly for 100% weird cases.

So how much weird cases do we have?

>> (surprisingly) the other way round, sda just happens to be the first disk
>> inserted (SCA, USB, etc.)
>
>Which is much saner approach from developers' POV.
>
Developer... and about the user/admin? With a sparcbox (ran suse linux 7.3 the
last time it was powered on - 2.4 kernel, no udev - don't complain :),
replugging disks in put them at the end of the 'sd*' naming
chain, effectively killing the features of hotplug the machine itself offered.
(Oh, that OS starting with S.. managed it with the help of the behated/-loved
c?d?t?s? scheme, but that's OT.)



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Kyle Moffett]

On Feb 01, 2006, at 11:28, Jan Engelhardt wrote:
>> Moreover providing ordering by IDE driver has been nightmare to  
>> maintain and can't be done correctly for 100% weird cases.
>
> So how much weird cases do we have?

Speaking from personal experience, _waay_ too many.  On my old G4  
which now serves as a fileserver, I have 5 IDE busses out of 3  
controllers (Onboard ATA-66 with 2 busses, onboard ATA-33 with one  
bus, add-in PCI ATA-100 with 2 busses)  There's a _config_ option to  
control probe order specific to the two Apple onboard interfaces, and  
it used to be (before udev) that option was a nightmare to ensure  
that my new kernel has the same probe order as the old one.  Once you  
throw PCI hotplug into the mix, reliable probing order is impossible,  
and you should just use udev to dynamically assign names.


>>> (surprisingly) the other way round, sda just happens to be the  
>>> first disk
>>> inserted (SCA, USB, etc.)
>>
>> Which is much saner approach from developers' POV.
>
> Developer... and about the user/admin? With a sparcbox (ran suse  
> linux 7.3 the last time it was powered on - 2.4 kernel, no udev -  
> don't complain :), replugging disks in put them at the end of the  
> 'sd*' naming chain, effectively killing the features of hotplug the  
> machine itself offered. (Oh, that OS starting with S.. managed it  
> with the help of the behated/-loved c?d?t?s? scheme, but that's OT.)

Yeah, 2.4 was bad at hotplug, everybody knows that already.  This is  
why the changes were made for 2.6 to add udev and hal and make it  
much saner.

Cheers,
Kyle Moffett

--
I lost interest in "blade servers" when I found they didn't throw  
knives at people who weren't supposed to be in your machine room.
   -- Anthony de Boer

Re: CD writing in future Linux (stirring up a hornets' nest)

[Xavier Bestel]

On Tue, 2006-01-31 at 13:33, Oliver Neukum wrote:
> It is entirely possible that the people you know are far from a representative
> sample. Most people likely prefer clicking on a description in a GUI. There
> needs to be a way to get this list and if possible it should not be specific
> to Linux.

As repeated over and over here, there is such a way, it's called HAL and
it is cross-platform. And it's what's used by some GUIs out there (e.g.
nautilus-cd-burner).

	Xav

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Xavier Bestel <xavier.bestel@free.fr> wrote:

> On Tue, 2006-01-31 at 13:33, Oliver Neukum wrote:
> > It is entirely possible that the people you know are far from a representative
> > sample. Most people likely prefer clicking on a description in a GUI. There
> > needs to be a way to get this list and if possible it should not be specific
> > to Linux.
>
> As repeated over and over here, there is such a way, it's called HAL and
> it is cross-platform. And it's what's used by some GUIs out there (e.g.
> nautilus-cd-burner).

The fact that people here repeat unadquate proposals forces me to repeat my 
proposals. Name a list fo OS that implement HAL and then look at the list
of crecord supported platforms 
Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Xavier Bestel]

On Thu, 2006-02-02 at 12:19, Joerg Schilling wrote:
> Xavier Bestel <xavier.bestel@free.fr> wrote:
> 
> > On Tue, 2006-01-31 at 13:33, Oliver Neukum wrote:
> > > It is entirely possible that the people you know are far from a representative
> > > sample. Most people likely prefer clicking on a description in a GUI. There
> > > needs to be a way to get this list and if possible it should not be specific
> > > to Linux.
> >
> > As repeated over and over here, there is such a way, it's called HAL and
> > it is cross-platform. And it's what's used by some GUIs out there (e.g.
> > nautilus-cd-burner).
> 
> The fact that people here repeat unadquate proposals forces me to repeat my 
> proposals. Name a list fo OS that implement HAL and then look at the list
> of crecord supported platforms 

Well ... from your sayings it seems Linux is supported by HAL but not by
libscg. 

	Xav

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Xavier Bestel <xavier.bestel@free.fr> wrote:

> > > As repeated over and over here, there is such a way, it's called HAL and
> > > it is cross-platform. And it's what's used by some GUIs out there (e.g.
> > > nautilus-cd-burner).
> > 
> > The fact that people here repeat unadquate proposals forces me to repeat my 
> > proposals. Name a list fo OS that implement HAL and then look at the list
> > of crecord supported platforms 
>
> Well ... from your sayings it seems Linux is supported by HAL but not by
> libscg. 

Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since
10 years.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Xavier Bestel]

Hi Jörg,

On Thu, 2006-02-02 at 13:51, Joerg Schilling wrote:
> Xavier Bestel <xavier.bestel@free.fr> wrote:
> > Well ... from your sayings it seems Linux is supported by HAL but not by
> > libscg. 
> 
> Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since
> 10 years.

I understand your point, but believe me, *nobody* wants one HAL per
application. There need to be only one HAL for all, and as freedesktop's
HAL has the functionnality necessary for cdrecord (minus perhaps a few
fixable bugs), but libscg is SCSI-only (and for the matter, can't work
with Linux IDE devices), cdrecord would better move to HAL for its CD
writer discovery.

Of course, the perfect outcome of this would be you turning cdrecord
into a shared library which could be used by apps as they see fit, using
their own means of selecting a CD writer and reporting errors and
completion.

Regards,
	Xav

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Xavier Bestel <xavier.bestel@free.fr> wrote:

> On Thu, 2006-02-02 at 13:51, Joerg Schilling wrote:
> > Xavier Bestel <xavier.bestel@free.fr> wrote:
> > > Well ... from your sayings it seems Linux is supported by HAL but not by
> > > libscg. 
> > 
> > Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since
> > 10 years.
>
> I understand your point, but believe me, *nobody* wants one HAL per
> application. There need to be only one HAL for all, and as freedesktop's
> HAL has the functionnality necessary for cdrecord (minus perhaps a few

If people don't want this confusion, why do they start with a new system?

libscg & cdrecord have been available long before Linux HAL was there.

And the most important argument here is that it is extremely unlikely that
this Linux HAL will handle all oddities of all CD/DVD-writers, do it is 
unapropriate to use this interface in case that you like to get more 
information than just "the drive is there".

Note that UNIX people usually believe that is is best practice to have this 
kind of software intergrated in the kernel (or at leat in the system). This is 
what FreeBSD did try for some years, and FreeBSD has failed with this attempt.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-03:

> libscg & cdrecord have been available long before Linux HAL was there.

Perhaps libscg was too arcane and too badly integrated into Linux?

> And the most important argument here is that it is extremely unlikely that
> this Linux HAL will handle all oddities of all CD/DVD-writers, do it is 
> unapropriate to use this interface in case that you like to get more 
> information than just "the drive is there".
> 
> Note that UNIX people usually believe that is is best practice to have this 
> kind of software intergrated in the kernel (or at leat in the system). This is 
> what FreeBSD did try for some years, and FreeBSD has failed with this attempt.

So why would Linux want to have it in the kernel if it hasn't worked for
FreeBSD either? Thanks for proving it doesn't belong there BTW.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> 
>> Note that UNIX people usually believe that is is best practice to have this 
>> kind of software intergrated in the kernel (or at leat in the system). This is 
>> what FreeBSD did try for some years, and FreeBSD has failed with this attempt.
>
>So why would Linux want to have it in the kernel if it hasn't worked for
>FreeBSD either? Thanks for proving it doesn't belong there BTW.
>
There's also something in the FreeBSD kernel that does work there, but has 
not worked out as good for Linux ;-) [devfs]

Therefore I would not generalize it and say "if it did not work on <x>, we 
don't need to implement it for our <y>".


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> Joerg Schilling schrieb am 2006-02-03:
>
> > libscg & cdrecord have been available long before Linux HAL was there.
>
> Perhaps libscg was too arcane and too badly integrated into Linux?

>From a cdrecord point of view, this seems to rather apply to Linux HAL.


> > Note that UNIX people usually believe that is is best practice to have this 
> > kind of software intergrated in the kernel (or at leat in the system). This is 
> > what FreeBSD did try for some years, and FreeBSD has failed with this attempt.
>
> So why would Linux want to have it in the kernel if it hasn't worked for
> FreeBSD either? Thanks for proving it doesn't belong there BTW.

Please try to understand my text before answering.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Xavier Bestel]

On Fri, 2006-02-03 at 10:55, Joerg Schilling wrote:
> Xavier Bestel <xavier.bestel@free.fr> wrote:
> > I understand your point, but believe me, *nobody* wants one HAL per
> > application. There need to be only one HAL for all, and as freedesktop's
> > HAL has the functionnality necessary for cdrecord (minus perhaps a few
> 
> If people don't want this confusion, why do they start with a new system?
> 
> libscg & cdrecord have been available long before Linux HAL was there.

Because libscg handles only SCSI, whereas HAL does work for all disk
types, floppies, serial ports, PCI buses, graphics cards, processors,
etc. Imagine there was one library per peripheral type - oh the pain.

> And the most important argument here is that it is extremely unlikely that
> this Linux HAL will handle all oddities of all CD/DVD-writers, do it is 
> unapropriate to use this interface in case that you like to get more 
> information than just "the drive is there".

For now, it sure doesn't equal cdrecord in that area. But give it time
and it will progress. After all, there's no reason HAL can't gain from
your expertise on the matter.

> Note that UNIX people usually believe that is is best practice to have this 
> kind of software intergrated in the kernel (or at leat in the system). This is 
> what FreeBSD did try for some years, and FreeBSD has failed with this attempt.

AFAIR this was deemed too complex to live in kernelspace. Maybe
FreeBSD's failure is a good indication it's true.

	Xav

Re: CD writing in future Linux (stirring up a hornets' nest)

[grundig]

El Thu, 02 Feb 2006 13:51:19 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:

> Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since
> 10 years.


libscg being there for 10 years doesn't means that it's the right or the
better way of doing things.

Hal is _the_ HAL for linux, in fact HAL is targetted to become _the_
"standard" (freedesktop standard) HAL for open operative systems. HAL
should be already available on solaris, at least there's a @sun.com guy
who created a hald/solaris/ directory (gnome is already using HAL and
sun is interested in gnome). It doesn't seem to do nothing today but I
bet that sun is interested in getting HAL working in solaris (there're
at least people in the opensolaris mailing lists interested). I guess
the BSD guys will end up implementing BSD support some day aswell - desktop
is not as important for them as it is for linux.

So the fact is that HAL is quickly becoming _the_ HAL for unix systems.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

<grundig@teleline.es> wrote:

> El Thu, 02 Feb 2006 13:51:19 +0100,
> Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:
>
> > Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since
> > 10 years.
>
>
> libscg being there for 10 years doesn't means that it's the right or the
> better way of doing things.

Any new implementation first needs to prove that it is durable and (more 
important) that it is actively maintained. I am sure that this kind of software 
will never handle all oddities in drive firmware we know from CD/DVD-writers.


> Hal is _the_ HAL for linux, in fact HAL is targetted to become _the_
> "standard" (freedesktop standard) HAL for open operative systems. HAL
> should be already available on solaris, at least there's a @sun.com guy
> who created a hald/solaris/ directory (gnome is already using HAL and
> sun is interested in gnome). It doesn't seem to do nothing today but I

I know this person, but Sun is creating reliable software for customers and for 
this reason, it is most unlikely that an incompatible change like this will 
be intregrated before Solaris 11 GA is available to the end of 2007.
It may appear earlier in Solaris 11 beta's, but this is a different thing.

> bet that sun is interested in getting HAL working in solaris (there're
> at least people in the opensolaris mailing lists interested). I guess
> the BSD guys will end up implementing BSD support some day aswell - desktop
> is not as important for them as it is for linux.
>
> So the fact is that HAL is quickly becoming _the_ HAL for unix systems.

I hope that Sun will not base Sun's implementations on ideas on the Linux 
implementaion which is known to be an "unfriendly" program as it causes 
problems with CD/DVD-writing.

Since 1992, Sun has vold and vold is rock solid. Vold nicely coexists with 
cdrecord in the right way: It does not send inapropriate SCSI commnds to the 
drives and it does not send too many of them in a certain period of time.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-03:

> Any new implementation first needs to prove that it is durable and (more 
> important) that it is actively maintained. I am sure that this kind of software 
> will never handle all oddities in drive firmware we know from CD/DVD-writers.

The suggestion was to use it for device enumeration and then talking
ioctl(...SG_IO...) to the device so obtained.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> >
>> > As repeated over and over here, there is such a way, it's called HAL and
>> > it is cross-platform. And it's what's used by some GUIs out there (e.g.
>> > nautilus-cd-burner).
>> 
>> The fact that people here repeat unadquate proposals forces me to repeat my 
>> proposals. Name a list fo OS that implement HAL and then look at the list
>> of crecord supported platforms 
>
>Well ... from your sayings it seems Linux is supported by HAL but not by
>libscg. 
>
But sounds like freedesktop-hal is not available for all platforms libscg
currently works on!


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On Thu, Feb 02, 2006 at 05:20:13PM +0100, Jan Engelhardt wrote:
> >> >
> >> > As repeated over and over here, there is such a way, it's called HAL and
> >> > it is cross-platform. And it's what's used by some GUIs out there (e.g.
> >> > nautilus-cd-burner).
> >> 
> >> The fact that people here repeat unadquate proposals forces me to repeat my 
> >> proposals. Name a list fo OS that implement HAL and then look at the list
> >> of crecord supported platforms 
> >
> >Well ... from your sayings it seems Linux is supported by HAL but not by
> >libscg. 
> >
> But sounds like freedesktop-hal is not available for all platforms libscg
> currently works on!

I presume that the system api are not the same between OS either, so why
can't there be different methods of interacting with the
cdburners/cddrives!

> 
> 
> Jan Engelhardt
> -- 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: CD writing in future Linux (stirring up a hornets' nest)

[Juerg Billeter]

Thanks for your detailed response.

On Die, 2006-01-31 at 11:30 +0100, Joerg Schilling wrote:
> Jürg Billeter <j@bitron.ch> wrote:
> > It makes sense to address parallel SCSI devices via target id. If an
> > operating system likes to simulate virtual SCSI buses for other bus
> > types as well, ok, I have no objections. But if the operating system
> > doesn't like to simulate virtual SCSI buses and allows applications to
> > address devices by a filename, you should have no objections, too.
> 
> It seems that you missunderstand this. No operating system uses file names
> internally. OS instead typically handle SCSI devices that are not connected
> via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system
> by asuming they are all on separate SCSI busses that only have one single drive 
> conected each.

Are you sure about that? I don't doubt that many operating systems
handle all devices, that are able to understand the SCSI command set,
exactly as you describe it, but Linux doesn't assume such separate
virtual SCSI buses for non good old Parallel SCSI drives, not even
internally, as far as I understand it. Of course it doesn't use file
names internally, it uses major and minor numbers, but that shouldn't
matter, the major and minor numbers get exported to userspace via sysfs.

> 
> What Linux does is to artificially prevent this view to been seen from outside the
> Linux kernel, or to avoid integrating a particular device into a unique SCSI
> driver system although it would be apropriate.

That's the point where you're not quite right, if I understand it
correctly. The Linux kernel does not artificially prevent userspace
applications viewing virtual SCSI buses, these virtual SCSI buses don't
exist internally in the Linux kernel at all. So Linux doesn't
artificially prevent anything, it just doesn't artificially _create_
virtual SCSI buses.


> Users like to be able to get a list of posible targets for a single protocol.
> Nobody would ever think about trying to prevent people from getting a unified
> view on the list possible hosts that talk TCP/IP. What cdrecord does with
> -scanbus is nothing really different. 

Well, please show me how to get the list of all possible hosts that talk
TCP/IP and are directly or indirectly connected to my computer. As my
computer is attached to the internet, the list would get pretty long...
And even if only considering hosts in the local network, how do you get
a unified view of all TCP/IP hosts conected to any of my two network
adapters?


> So why do people try to convince me that there is a need to avoid the standard 
> SCSI protocol stack because a PC might have only ATAPI? 
> 
> Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, 
> ...). Why do people believe that Linux needs to be different? What does it buy 
> you to go this way?

Why do you believe that Linux needs to do the same as every other OS?
I'd agree with you if Linux would violate a standard but AFAIK the bus
view with target ids is not part of the ATAPI or a dependant standard.
Please correct me if I'm wrong but the bus/target/lun combination is
only a standard for some SCSI transports, at least it is for good old
Parallel SCSI, yes, but SCSI over ATA doesn't define target-based
addressing.

> *] MS-WIN-NT even includes SCSI emulation (it allows you to connect to the
> SCSI subsystem, set the Address and use SCSI commands from a limited list
> to read/write sector from ATA only hard disks).

Great, I have no objections but you shouldn't mandate the Linux kernel
developers to implement a copy of implementations other operating
systems provide. If the virtual SCSI bus and/or full SCSI emulation
would be part of POSIX or an other standard Linux tries to follow, Linux
should implement it, of course, but last time I checked, it's not in
POSIX.

> 
> If the Linux folks could give technical based explanations for the questions 
> from above and if they would create a new completely orthogonal view on SCSI [*]
> I had no problem. But up to now, the only answer was: "We do it this 
> way because we do it this way". 

Linux' device nodes is such an orthogonal view that should include all
devices able to speak SCSI among others. Enumeration is possible via
sysfs (low-level) or much easier via the userspace HAL library from
freedesktop.org.

> 
> *] Note that this would need to implement SCSI Generic support for drives that
> have no native driver in the system.

If there is a device that supports the SCSI command set and the device
can't be accessed with SG_IO in linux, I'd call this a Linux kernel bug.
You mentioned ATAPI tapes before; if that's really the case, it's a
Linux bug, yes, but it seems that nobody cares about speaking SCSI with
these device types. That happens in projects with limited resources.

My point is that this shouldn't matter to cdrecord. It does matter to
tape drive applications that use libscg, of course. File a bug in
bugzilla about that and if ATAPI tapes are important to a Linux
developer, he will probably implement it. But a Linux bug affecting some
device or bus types doesn't automatically mean that the whole Linux
kernel device addressing is broken by design.

Jürg

-- 
Juerg Billeter <j@bitron.ch>

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Juerg Billeter <j@bitron.ch> wrote:

> > So why do people try to convince me that there is a need to avoid the standard 
> > SCSI protocol stack because a PC might have only ATAPI? 
> > 
> > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, 
> > ...). Why do people believe that Linux needs to be different? What does it buy 
> > you to go this way?
>
> Why do you believe that Linux needs to do the same as every other OS?

Why do you believe that Linux needs to be worse than other OS?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello!

> > Why do you believe that Linux needs to do the same as every other OS?
> 
> Why do you believe that Linux needs to be worse than other OS?

Sorry, but so far you have failed to produce a single plausible argument
why the way chosen by Linux is worse.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
The number of UNIX installations has grown to 10, with more expected.  (6/72)

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jim Crilly]

On 01/31/06 02:37:22PM +0100, Joerg Schilling wrote:
> Juerg Billeter <j@bitron.ch> wrote:
> 
> > > So why do people try to convince me that there is a need to avoid the standard 
> > > SCSI protocol stack because a PC might have only ATAPI? 
> > > 
> > > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, 
> > > ...). Why do people believe that Linux needs to be different? What does it buy 
> > > you to go this way?
> >
> > Why do you believe that Linux needs to do the same as every other OS?
> 
> Why do you believe that Linux needs to be worse than other OS?
> 

Every other method to access those devices uses the device name, i.e.
mount, fsck, etc, so why should cdrecord be different?

> Jörg


Jim.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Jim Crilly <jim@why.dont.jablowme.net> wrote:

> Every other method to access those devices uses the device name, i.e.
> mount, fsck, etc, so why should cdrecord be different?

inadequateness on Linux did force libscg to go this way.

The current method used by libscg is well established since 10 years.

Now Linux likes to confuse people by trying to enforce a completely 
incompatible access method.

Note that I need to avoid unneeded efforts and for this reason, I need to wait
5 years until is is forseable that a recent incompatible change in Linux will
survive long enough to spent time on it.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[grundig]

El Thu, 02 Feb 2006 12:17:09 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:

> Note that I need to avoid unneeded efforts and for this reason, I need to wait
> 5 years until is is forseable that a recent incompatible change in Linux will
> survive long enough to spent time on it.


Woah. No comments.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello!

> Now Linux likes to confuse people by trying to enforce a completely 
> incompatible access method.

Completely incompatible? For years, cdrecord works with it and it only
prints an utterly silly warning and also has a trivial bug in the scanning
code, causing it to stop too early.

> Note that I need to avoid unneeded efforts and for this reason, I need to wait
> 5 years until is is forseable that a recent incompatible change in Linux will
> survive long enough to spent time on it.

If this is reason, I will send you a patch fixing the trivial bugs and
annoyances, sparing you the work.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"I don't give a damn for a man that can only spell a word one way." -- M. Twain

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-02:

> Jim Crilly <jim@why.dont.jablowme.net> wrote:
> 
> > Every other method to access those devices uses the device name, i.e.
> > mount, fsck, etc, so why should cdrecord be different?
> 
> inadequateness on Linux did force libscg to go this way.
> 
> The current method used by libscg is well established since 10 years.
> 
> Now Linux likes to confuse people by trying to enforce a completely 
> incompatible access method.
> 
> Note that I need to avoid unneeded efforts and for this reason, I need to wait
> 5 years until is is forseable that a recent incompatible change in Linux will
> survive long enough to spent time on it.

It is incompatible? Looks like the code is already implemented and ATA:
is in the regular device name space (where RSCSI and the other options
reside as well).

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jim Crilly]

On 02/02/06 12:17:09PM +0100, Joerg Schilling wrote:
> Jim Crilly <jim@why.dont.jablowme.net> wrote:
> 
> > Every other method to access those devices uses the device name, i.e.
> > mount, fsck, etc, so why should cdrecord be different?
> 
> inadequateness on Linux did force libscg to go this way.
> 

And inadequacies are what's causing libscg and 'cdrecord -scanbus' to fail
to list all IDE devices on Linux. Unless the comments about it stopping the
scan after getting -EPERM on one device are wrong.

> The current method used by libscg is well established since 10 years.

So? Change isn't always a bad thing.

> Now Linux likes to confuse people by trying to enforce a completely 
> incompatible access method.

>From my point of view it's cdrecord that's confusing Linux users by trying
to force a completely different device naming method on users for no good
reason.

> Note that I need to avoid unneeded efforts and for this reason, I need to wait
> 5 years until is is forseable that a recent incompatible change in Linux will
> survive long enough to spent time on it.

I could be wrong, but don't all of the other OSes that cdrecord and
libscg support access the device via the device node? When I mount
a device on Solaris I use /dev/c0t0d0s0 (or whatever it is)and not
0:0:0, right? So it would be safe to assume that users are used to
using that form of names for their devices, so why should cdrecord
be the odd man out?

Jim.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Albert Cahalan]

On 2/2/06, Jim Crilly <jim@why.dont.jablowme.net> wrote:
> On 02/02/06 12:17:09PM +0100, Joerg Schilling wrote:
> > Jim Crilly <jim@why.dont.jablowme.net> wrote:
> >
> > > Every other method to access those devices uses the device name, i.e.
> > > mount, fsck, etc, so why should cdrecord be different?
> >
> > inadequateness on Linux did force libscg to go this way.
> >
>
> And inadequacies are what's causing libscg and 'cdrecord -scanbus' to fail
> to list all IDE devices on Linux. Unless the comments about it stopping the
> scan after getting -EPERM on one device are wrong.

I'm seeing even worse behavior. Since /dev/hda is a disk with mounted
filesystems, my kernel refuses access even for root. Thus, even root
is unable to scan the /dev/hd* devices!

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>
>I'm seeing even worse behavior. Since /dev/hda is a disk with mounted
>filesystems, my kernel refuses access even for root. Thus, even root
>is unable to scan the /dev/hd* devices!
>
What sort of kernel patch do you have turned on? I'd be scared if I could 
not even do a (read-only!) hexdump of my drive while mounted.


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jim Crilly]

On 02/02/06 09:39:02PM +0100, Jan Engelhardt wrote:
> >
> >I'm seeing even worse behavior. Since /dev/hda is a disk with mounted
> >filesystems, my kernel refuses access even for root. Thus, even root
> >is unable to scan the /dev/hd* devices!
> >
> What sort of kernel patch do you have turned on? I'd be scared if I could 
> not even do a (read-only!) hexdump of my drive while mounted.
> 

I see the same thing with, the only external kernel patch I have
applied is Suspend2. The ATA scanbus code tries to 
open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
the scanning code stops once one device fails to open the whole scan
aborts. Apparently O_EXCL was added by Ubuntu and Debian to stop
burns being corrupted by hald polling the device while a disc is
being burned. If you want to read the entire thread it's bug #262678
in Debian.

Jim.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> I see the same thing with, the only external kernel patch I have
> applied is Suspend2. The ATA scanbus code tries to 
> open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since

This is not cdrecord but a bastardized version......

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jim Crilly]

On 02/02/06 10:20:18PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > I see the same thing with, the only external kernel patch I have
> > applied is Suspend2. The ATA scanbus code tries to 
> > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> 
> This is not cdrecord but a bastardized version......
> 
> Jörg

I know it's not your official version, I was merely pointing out where the
'problem' was coming from.

Jim.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> > 
> > This is not cdrecord but a bastardized version......

> I know it's not your official version, I was merely pointing out where the
> 'problem' was coming from.

This was only a short reply.... see also my longer reply from today.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Albert Cahalan]

On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
>
> > I see the same thing with, the only external kernel patch I have
> > applied is Suspend2. The ATA scanbus code tries to
> > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
>
> This is not cdrecord but a bastardized version......

True enough, but it would work great if you'd fix that bug
that makes cdrecord give up while scanning. I guess
that's one more patch Debian will be applying.

Using O_EXCL is kind of broken, because you'll need to
retry any failures, but that's life. You hacked cdrecord to
properly interact with the Solaris volume manager. You
can do the same for HAL.

Giving up while scanning is a problem for other reasons.
Let me introduce you to SE Linux. One can have RAWIO
capability, RT capability, mlock() capability, and still not
have the right to access all devices. You might not even
be able to get stat() to succeed, but you could burn a CD
if you use the correct device file.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>Giving up while scanning is a problem for other reasons.
>Let me introduce you to SE Linux. One can have RAWIO
>capability, RT capability, mlock() capability, and still not
>have the right to access all devices. You might not even
>be able to get stat() to succeed, but you could burn a CD
>if you use the correct device file.
>
Unfortunately, setting up SELinux is currently not easy.

Jan Engelhardt
-- 
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Albert Cahalan <acahalan@gmail.com> wrote:

> On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> >
> > > I see the same thing with, the only external kernel patch I have
> > > applied is Suspend2. The ATA scanbus code tries to
> > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> >
> > This is not cdrecord but a bastardized version......
>
> True enough, but it would work great if you'd fix that bug
> that makes cdrecord give up while scanning. I guess
> that's one more patch Debian will be applying.

As including O_EXCL would disallow to use more than one cdrecord
program at the same time, there is no chance for the mains stream source.

> Using O_EXCL is kind of broken, because you'll need to
> retry any failures, but that's life. You hacked cdrecord to
> properly interact with the Solaris volume manager. You
> can do the same for HAL.

Well the big difference with Solaris is that several modifications have been 
applied by Sun to the vold sub-system on Solaris in order to decently 
support cdrecord.

The last change was done with Nevada Build 21 in August 2005.

It makes sense for Linux not to ignore CD/DVD writing. Solaris also did
chose not to ignore cdrecord.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jim Crilly]

On 02/03/06 04:20:47PM +0100, Joerg Schilling wrote:
> Albert Cahalan <acahalan@gmail.com> wrote:
> 
> > On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > > "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> > >
> > > > I see the same thing with, the only external kernel patch I have
> > > > applied is Suspend2. The ATA scanbus code tries to
> > > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> > >
> > > This is not cdrecord but a bastardized version......
> >
> > True enough, but it would work great if you'd fix that bug
> > that makes cdrecord give up while scanning. I guess
> > that's one more patch Debian will be applying.
> 
> As including O_EXCL would disallow to use more than one cdrecord
> program at the same time, there is no chance for the mains stream source.

Maybe I'm just being thick, but wouldn't that only prevent you from using
cdrecord on the same device multiple times? The only thing I can see being
opened with O_EXCL is the target device.

> > Using O_EXCL is kind of broken, because you'll need to
> > retry any failures, but that's life. You hacked cdrecord to
> > properly interact with the Solaris volume manager. You
> > can do the same for HAL.
> 
> Well the big difference with Solaris is that several modifications have been 
> applied by Sun to the vold sub-system on Solaris in order to decently 
> support cdrecord.
> 
> The last change was done with Nevada Build 21 in August 2005.
> 
> It makes sense for Linux not to ignore CD/DVD writing. Solaris also did
> chose not to ignore cdrecord.
> 
> Jörg

A bug in HAL is not a bug in Linux. If the HAL people need to make some
changes to their daemon to make it play nice with cdrecord and the like
that's fine, but telling people here makes no sense.

Jim.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> A bug in HAL is not a bug in Linux. If the HAL people need to make some
> changes to their daemon to make it play nice with cdrecord and the like
> that's fine, but telling people here makes no sense.

Please let us either asume that it is in or not....

If you tell me it is not in, then cdrecord definitely needs everything
it currently does just because Linux is missing any needed feature.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Krzysztof Halasa]

"Jim Crilly" <jim@why.dont.jablowme.net> writes:

> A bug in HAL is not a bug in Linux. If the HAL people need to make some
> changes to their daemon to make it play nice with cdrecord and the like
> that's fine, but telling people here makes no sense.

Does that mean that hald doesn't actually play nice with cdrecord?
-- 
Krzysztof Halasa

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jim Crilly]

On 02/03/06 06:49:21PM +0100, Krzysztof Halasa wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> writes:
> 
> > A bug in HAL is not a bug in Linux. If the HAL people need to make some
> > changes to their daemon to make it play nice with cdrecord and the like
> > that's fine, but telling people here makes no sense.
> 
> Does that mean that hald doesn't actually play nice with cdrecord?
> -- 
> Krzysztof Halasa
> -

That's what the bug reports in Debian and Ubuntu say, the periodic polling
that hald does on the CD devices causes interruptions in the burning
process.

Jim.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Krzysztof Halasa <khc@pm.waw.pl> wrote:

> "Jim Crilly" <jim@why.dont.jablowme.net> writes:
>
> > A bug in HAL is not a bug in Linux. If the HAL people need to make some
> > changes to their daemon to make it play nice with cdrecord and the like
> > that's fine, but telling people here makes no sense.
>
> Does that mean that hald doesn't actually play nice with cdrecord?

I cannot speak from own experiences on Linux here, but this is what I see:

-	If you check Linux distributions for related bug reports,
	you find many problems with hald.

-	If you try to find similar bug reports for Solaris vold, there is
	no report I am aware of.

Trying to rate this would make me asume that hald could be changed to play
better with cdrecord.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Fri, Feb 03, 2006 at 10:53:50AM -0500, Jim Crilly wrote:
> A bug in HAL is not a bug in Linux. If the HAL people need to make some
> changes to their daemon to make it play nice with cdrecord and the like
> that's fine, but telling people here makes no sense.

Actually, since at that point in time HAL is the only way to do device
discovery with the linux kernel, problems in HAL are problems in
linux.  There is *no* other way than HAL to do the mapping between a
point in the sysfs tree and a device node in /dev[1].

  OG.

[1] Unless you consider stating every node in /dev acceptable just to
find the correct major/minor.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Kay Sievers]

On Fri, Feb 03, 2006 at 07:04:21PM +0100, Olivier Galibert wrote:
> On Fri, Feb 03, 2006 at 10:53:50AM -0500, Jim Crilly wrote:
> > A bug in HAL is not a bug in Linux. If the HAL people need to make some
> > changes to their daemon to make it play nice with cdrecord and the like
> > that's fine, but telling people here makes no sense.
> 
> Actually, since at that point in time HAL is the only way to do device
> discovery with the linux kernel, problems in HAL are problems in
> linux.  There is *no* other way than HAL to do the mapping between a
> point in the sysfs tree and a device node in /dev[1].

That's all nonsense!

  $ udevinfo -r -q name -p /block/sr0
  /dev/sr0

  $ udevinfo -q path -n /dev/sr0
  /block/sr0

  $ udevinfo -q all -p /block/sr0
  P: /block/sr0
  N: sr0
  S: disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0
  S: cdrecorder
  S: cdrom
  E: ID_VENDOR=MATSHITA
  E: ID_MODEL=DVD-RAM_UJ-822S
  E: ID_REVISION=1.61
  E: ID_SERIAL=
  E: ID_TYPE=cd
  E: ID_BUS=scsi
  E: ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0

Kay

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Fri, Feb 03, 2006 at 07:13:14PM +0100, Kay Sievers wrote:
> That's all nonsense!
> 
>   $ udevinfo -r -q name -p /block/sr0
>   /dev/sr0

Ok, I couldn't find it for love or money.  But it's exactly what's
needed.

I see all the useful information is in /dev/.udev.tdb.  I need to have
a look at that TDB format, but exporting the database to other
programs works.

  OG.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jim Crilly]

On 02/03/06 07:04:21PM +0100, Olivier Galibert wrote:
> On Fri, Feb 03, 2006 at 10:53:50AM -0500, Jim Crilly wrote:
> > A bug in HAL is not a bug in Linux. If the HAL people need to make some
> > changes to their daemon to make it play nice with cdrecord and the like
> > that's fine, but telling people here makes no sense.
> 
> Actually, since at that point in time HAL is the only way to do device
> discovery with the linux kernel, problems in HAL are problems in
> linux.  There is *no* other way than HAL to do the mapping between a
> point in the sysfs tree and a device node in /dev[1].
> 
>   OG.
> 
> [1] Unless you consider stating every node in /dev acceptable just to
> find the correct major/minor.

It's not about device discovery, hald is polling removable devices every 2s
to see if new media was inserted and when it polls a CD drive that's
currently burning a disc it causes problems. It's documented in Debian bug
#262678.

Jim.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Krzysztof Halasa]

"Jim Crilly" <jim@why.dont.jablowme.net> writes:

> It's not about device discovery, hald is polling removable devices every 2s
> to see if new media was inserted and when it polls a CD drive that's
> currently burning a disc it causes problems. It's documented in Debian bug
> #262678.

Ok. So what's wrong with cdrecord using O_EXCL (and maybe retrying
for few seconds) so no other program (hald or, say, a user mistaking
a device) can interrupt it?

And, if we are here, what's wrong with hald using O_EXCL to not
interrupt any other program (does hald need to check the media
if it's in use)? I assume the problem wouldn't exist with hald
using O_EXCL and cdrecord not (yet) using it, would it?
-- 
Krzysztof Halasa

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

On Sat, 04 Feb 2006, Krzysztof Halasa wrote:

> And, if we are here, what's wrong with hald using O_EXCL to not
> interrupt any other program (does hald need to check the media
> if it's in use)? I assume the problem wouldn't exist with hald
> using O_EXCL and cdrecord not (yet) using it, would it?

Let me throw in a stupid question: Is O_EXCL cooperative, in that other
access is only blocked if both tasks use open(...O_EXCL...)?

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>
>> And, if we are here, what's wrong with hald using O_EXCL to not
>> interrupt any other program (does hald need to check the media
>> if it's in use)? I assume the problem wouldn't exist with hald
>> using O_EXCL and cdrecord not (yet) using it, would it?
>
>Let me throw in a stupid question: Is O_EXCL cooperative, in that other
>access is only blocked if both tasks use open(...O_EXCL...)?
>
That would be some sort of "shared" what you describe.

O_EXCL basically means that there may only be one file descriptor open on 
it across the whole kernel. "if both tasks" already includes multiple file 
descriptors. (Note that dup() does not really make a new filedescriptor.)


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> It's not about device discovery, hald is polling removable devices every 2s
>> to see if new media was inserted and when it polls a CD drive that's
>> currently burning a disc it causes problems. It's documented in Debian bug
>> #262678.
>
>Ok. So what's wrong with cdrecord using O_EXCL (and maybe retrying
>for few seconds) so no other program (hald or, say, a user mistaking
>a device) can interrupt it?
>
I would say we all forgot to RTFM. Because O_EXCL does nothing *unless* 
O_CREAT is specified, which probably *is not* specified in cdrecord or 
hal. There is no reason to have hal or cdrecord create a device node - 
which you can't do with open() anyway.


Jan Engelhardt
-- 
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: CD writing in future Linux (stirring up a hornets' nest)

[Krzysztof Halasa]

Jan Engelhardt <jengelh@linux01.gwdg.de> writes:

> I would say we all forgot to RTFM. Because O_EXCL does nothing *unless* 
> O_CREAT is specified, which probably *is not* specified in cdrecord or 
> hal.

That would be the case if the CD writter wasn't a block device.

For a block device fs/block_dev.c:

static int blkdev_open(struct inode * inode, struct file * filp)
{
...

        if (!(filp->f_flags & O_EXCL) )
                return 0;

        if (!(res = bd_claim(bdev, filp)))
                return 0;

        blkdev_put(bdev);
        return res;
-- 
Krzysztof Halasa

Re: CD writing in future Linux (stirring up a hornets' nest)

[Phillip Susi]

Jan Engelhardt wrote:
> I would say we all forgot to RTFM. Because O_EXCL does nothing *unless* 
> O_CREAT is specified, which probably *is not* specified in cdrecord or 
> hal. There is no reason to have hal or cdrecord create a device node - 
> which you can't do with open() anyway.
> 

I think you are misinterpreting the man page, because it isn't worded 
very clearly.  It should not even mention O_CREAT because it has nothing 
to do with O_EXCL; it is just repeating the semantics of O_CREAT ( if 
the file already exists, the call fails ) which would of course, apply 
if you do use O_CREAT in conjunction with any other flag including 
O_EXCL.  It does not say that you must use O_EXCL with O_CREAT.  The 
rest of the description talks about using lockfiles as an alternative to 
ensure exclusive access to the file on NFS where O_EXCL is broken.  The 
intent of O_EXCL is clearly to provide the caller with exclusive access 
to the file.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Kyle Moffett]

On Feb 05, 2006, at 11:15, Phillip Susi wrote:
> Jan Engelhardt wrote:
>> I would say we all forgot to RTFM. Because O_EXCL does nothing  
>> *unless* O_CREAT is specified, which probably *is not* specified  
>> in cdrecord or hal. There is no reason to have hal or cdrecord  
>> create a device node - which you can't do with open() anyway.
>
> I think you are misinterpreting the man page, because it isn't  
> worded very clearly.  It should not even mention O_CREAT because it  
> has nothing to do with O_EXCL; it is just repeating the semantics  
> of O_CREAT ( if the file already exists, the call fails ) which  
> would of course, apply if you do use O_CREAT in conjunction with  
> any other flag including O_EXCL.  It does not say that you must use  
> O_EXCL with O_CREAT.  The rest of the description talks about using  
> lockfiles as an alternative to ensure exclusive access to the file  
> on NFS where O_EXCL is broken.  The intent of O_EXCL is clearly to  
> provide the caller with exclusive access to the file.

You don't have this right either.  The way open() works:

If you specify O_CREAT (and not O_EXCL), it will create the file if  
it does not exist, and open the existing file otherwise.

If you specify O_EXCL (and not O_CREAT), it is implementation defined  
what will happen (in the Linux case, this opens a block device for  
exclusive access).

If you specify O_CREAT|O_EXCL, it will atomically create the file if  
it does not exist, otherwise it will return the error -EEXIST.

Cheers,
Kyle Moffett

--
Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>
> If you specify O_EXCL (and not O_CREAT), it is implementation defined what will
> happen (in the Linux case, this opens a block device for exclusive access).
>
And with plain files, I supose it's free-for-all, right? 'Cause that's what 
my testcase yielded. :/


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Neil Brown]

On Sunday February 5, mrmacman_g4@mac.com wrote:
> 
> If you specify O_EXCL (and not O_CREAT), it is implementation defined  
> what will happen (in the Linux case, this opens a block device for  
> exclusive access).

With Linux, O_EXCL on a block devices isn't *exactly* exclusive
access.
It only provided you exclusive access against other people who ask for
exclusive access, which includes in-kernel usage like mount, md, dm,
and swap.

So if you open a block device O_EXCL, it will fail if the block device
is already open O_EXCL or is mounted, or in use by the kernel in some
other way (including if a partition is open O_EXCL).  An if you
succeed in getting an O_EXCL open, then no-one else will be able to
get an O_EXCL open, or mount the filesystem etc.
Bit on open without O_EXCL will always succeed no matter whether
someone has it O_EXCL or not.

So it is a lot like an advisory exclusive lock on the whole block
device.

NeilBrown

Re: CD writing in future Linux (stirring up a hornets' nest)

[Krzysztof Halasa]

Neil Brown <neilb@suse.de> writes:

> Bit on open without O_EXCL will always succeed no matter whether
> someone has it O_EXCL or not.

Ok. That means hald has no use for it, but cdrecord and similar
programs could use it.
-- 
Krzysztof Halasa

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>
>> Bit on open without O_EXCL will always succeed no matter whether
>> someone has it O_EXCL or not.
>
>Ok. That means hald has no use for it, but cdrecord and similar
>programs could use it.

But that again sounds like hald won't use O_EXCL, therefore could always be 
able to open the device and potentially send commands which interrupt cd 
writing.


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Krzysztof Halasa]

Jan Engelhardt <jengelh@linux01.gwdg.de> writes:

> But that again sounds like hald won't use O_EXCL, therefore could always be 
> able to open the device and potentially send commands which interrupt cd 
> writing.

Yep. Both need that. And I need some coffee to recover from
non-logical thinking.
-- 
Krzysztof Halasa

Re: CD writing in future Linux (stirring up a hornets' nest)

[Phillip Susi]

Out of curiosity, what commands does hal send the drive that can 
interrupt burning?  I've been reading the MMC-5 standard lately and it 
looks like while the drive is burning, attempts to send it other 
commands that would interfere with the burn are supposed to be failed 
with an error code indicating that a burn is in progress, and thus, 
avoid making a coaster. 

Krzysztof Halasa wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> writes:
>
>   
>> But that again sounds like hald won't use O_EXCL, therefore could always be 
>> able to open the device and potentially send commands which interrupt cd 
>> writing.
>>     
>
> Yep. Both need that. And I need some coffee to recover from
> non-logical thinking.
>   

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>
> Out of curiosity, what commands does hal send the drive that can interrupt
> burning?  I've been reading the MMC-5 standard lately and it looks like while
> the drive is burning, attempts to send it other commands that would interfere
> with the burn are supposed to be failed with an error code indicating that a
> burn is in progress, and thus, avoid making a coaster. 
>
At least there needs to be a command that is not ignored to stop a burn.
Though, hald would not be /that/ evil.


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Phillip Susi]

Olivier Galibert wrote:
> Actually, since at that point in time HAL is the only way to do device
> discovery with the linux kernel, problems in HAL are problems in
> linux.  There is *no* other way than HAL to do the mapping between a
> point in the sysfs tree and a device node in /dev[1].

That information is available in /sys, which is how HAL discovers it.  
If you wanted to, you could bypass HAL and go directly to /sys to 
perform your own discovery.  Also HAL is not a part of the linux kernel, 
therefore a problem in HAL is NOT a problem in linux, even if there were 
no other way to get the information as you ( wrongly ) asserted. 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Fri, Feb 03, 2006 at 02:50:11PM -0500, Phillip Susi wrote:
> Olivier Galibert wrote:
> >Actually, since at that point in time HAL is the only way to do device
> >discovery with the linux kernel, problems in HAL are problems in
> >linux.  There is *no* other way than HAL to do the mapping between a
> >point in the sysfs tree and a device node in /dev[1].
> 
> That information is available in /sys, which is how HAL discovers it.  

No, it isn't.  OTOH, udev maintains it, so I guess that's good enough.
It makes udev the kernel interface though.  I hope they now care about
compatibility (/dev/.udev.pdb vs. /dev/.udev/db/* anyone?).


> If you wanted to, you could bypass HAL and go directly to /sys to 
> perform your own discovery.  Also HAL is not a part of the linux kernel, 
> therefore a problem in HAL is NOT a problem in linux, even if there were 
> no other way to get the information as you ( wrongly ) asserted. 

Bullshit.  If <x> is the only interface available to a kernel service,
then <x> is part of the kernel whether you like it or not.  Case in
point, the ALSA library.

  OG.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Phillip Susi]

Olivier Galibert wrote:
> No, it isn't.  OTOH, udev maintains it, so I guess that's good enough.
> It makes udev the kernel interface though.  I hope they now care about
> compatibility (/dev/.udev.pdb vs. /dev/.udev/db/* anyone?).
> 

Yes, it is, where do you think udev gets it's information from?  That's 
right, from /sys.  Sysfs is the kernel interface, not udev; the 'u' in 
udev is for 'user', as in NOT part of the kernel.

>
> Bullshit.  If <x> is the only interface available to a kernel service,
> then <x> is part of the kernel whether you like it or not.  Case in
> point, the ALSA library.

Bullshit yourself.  If cdrecord is the only application for burning cds, 
that does not make it the kernel interface for cds, and certainly does 
not make it part of the kernel.  The kernel interface is the point of 
interaction between user and kernel code, which is sysfs.

Udev and HAL are two user mode ( NOT parts of the kernel ) components 
built to put the information from sysfs to use in user space, and other 
applications are encouraged to utilize the services those daemons 
provide.  By no stretch of the imagination does that make them part of 
the kernel.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Fri, Feb 03, 2006 at 04:06:13PM -0500, Phillip Susi wrote:
> Olivier Galibert wrote:
> >No, it isn't.  OTOH, udev maintains it, so I guess that's good enough.
> >It makes udev the kernel interface though.  I hope they now care about
> >compatibility (/dev/.udev.pdb vs. /dev/.udev/db/* anyone?).
> >
> 
> Yes, it is, where do you think udev gets it's information from?

The device node name?  From the rules in /etc/udev/rules.d/*.  Udev is
the one which creates it in the first place, deriving it in a
user-defined way from the sysfs information.  It does _not_ give back
that information to the kernel.  Maybe it should.


> >Bullshit.  If <x> is the only interface available to a kernel service,
> >then <x> is part of the kernel whether you like it or not.  Case in
> >point, the ALSA library.
> 
> Bullshit yourself.  If cdrecord is the only application for burning cds, 
> that does not make it the kernel interface for cds, and certainly does 
> not make it part of the kernel.  The kernel interface is the point of 
> interaction between user and kernel code, which is sysfs.

The kernel does not provide a cd burning service, only a scsi packet
transport service called SG_IO.

The kernel *does* provide a device enumeration service, only it does
it at this point through udev for reasons that are 50% technical and
50% political.  If you want to be able to use a 2.6 kernel with
hotplug devices udev[1] is mandatory.  As such, from an engineering
point of view, udev is part of the kernel even if it isn't in the
source tarball on kernel.org.  And for now it is the lowest level
interface to device enumeration.

  OG.

[1] Or hotplug, maybe.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Phillip Susi]

Olivier Galibert wrote:
> The device node name?  From the rules in /etc/udev/rules.d/*.  Udev is
> the one which creates it in the first place, deriving it in a
> user-defined way from the sysfs information.  It does _not_ give back
> that information to the kernel.  Maybe it should.
>
>   
Ohh, I see what you are saying now.  Yes, it is up to udev to create the 
device nodes, and the kernel does not know or care about the nodes.  If 
an application wants to find existing nodes it can open it needs to 
query udev or hal.  If it wants to find out what devices the kernel 
exports, it can look in /sys and make its own devnode to access them. 

> The kernel does not provide a cd burning service, only a scsi packet
> transport service called SG_IO.
>
> The kernel *does* provide a device enumeration service, only it does
> it at this point through udev for reasons that are 50% technical and
>   
What part of the user/kernel separation don't you understand?  udev is 
user mode code which interfaces with the kernel via sysfs.  Other user 
mode code is free to do that as well, or just use udev.  Either way, the 
only kernel interface involved is sysfs.  The kernel does not know or 
care about udev or what it does,  only sysfs.  The kernel provides 
enumeration through sysfs, and that is all. 
> 50% political.  If you want to be able to use a 2.6 kernel with
> hotplug devices udev[1] is mandatory.  As such, from an engineering
> point of view, udev is part of the kernel even if it isn't in the
> source tarball on kernel.org.  And for now it is the lowest level
> interface to device enumeration.
>
>   

Your logic is flawed.  X + Y = Z does NOT mean that X ( linux ) and Y ( 
udev ) are one and the same even if Z ( a usable GNU/Linux system with 
hotplug support ) is desirable.  The kernel provides sysfs as it's 
interface, and udev and hal provide higher level interfaces.  In much 
the same way, the kernel frame buffer driver provides one interface, and 
Xorg provides higher level interface built on top of the kernel 
interface.  By no stretch of the imagination is Xorg the kernel 
interface to the video card, which is what you are arguing. 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Phillip Susi]

Joerg Schilling wrote:
> As including O_EXCL would disallow to use more than one cdrecord
> program at the same time, there is no chance for the mains stream source.
>
>   

You CAN'T have multiple cdrecord processes burning the same disc at the 
same time; the very idea makes no sense.  The O_EXCL just prevents you 
from trying such foolishness and creating a coaster. 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Phillip Susi <psusi@cfl.rr.com> wrote:

> You CAN'T have multiple cdrecord processes burning the same disc at the 
> same time; the very idea makes no sense.  The O_EXCL just prevents you 
> from trying such foolishness and creating a coaster. 

It does not prevent you from creatig a coaster in case you connect e.g.
two ATAPI writers to the same ATA cable.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>
>> You CAN'T have multiple cdrecord processes burning the same disc at the 
>> same time; the very idea makes no sense.  The O_EXCL just prevents you 
>> from trying such foolishness and creating a coaster. 
>
>It does not prevent you from creatig a coaster in case you connect e.g.
>two ATAPI writers to the same ATA cable.
>
Apart from transfer speed issues and potential buffer underruns coming 
along with that, is there anything technically impossible with writing to 
two ATAPI drives at the same time?



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >
> >> You CAN'T have multiple cdrecord processes burning the same disc at the 
> >> same time; the very idea makes no sense.  The O_EXCL just prevents you 
> >> from trying such foolishness and creating a coaster. 
> >
> >It does not prevent you from creatig a coaster in case you connect e.g.
> >two ATAPI writers to the same ATA cable.
> >
> Apart from transfer speed issues and potential buffer underruns coming 
> along with that, is there anything technically impossible with writing to 
> two ATAPI drives at the same time?

It depends on what type of drive you use.

If you chose a drive that blocks the ATA cable while processing a 
START/STOP/UNIT, you are out of luck.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> >It does not prevent you from creatig a coaster in case you connect e.g.
>> >two ATAPI writers to the same ATA cable.
>> >
>> Apart from transfer speed issues and potential buffer underruns coming 
>> along with that, is there anything technically impossible with writing to 
>> two ATAPI drives at the same time?
>
>It depends on what type of drive you use.
>
>If you chose a drive that blocks the ATA cable while processing a 
>START/STOP/UNIT, you are out of luck.
>
That may be what I experienced with that aopen writer.



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Jan Engelhardt schrieb am 2006-02-03:

> >
> >> You CAN'T have multiple cdrecord processes burning the same disc at the 
> >> same time; the very idea makes no sense.  The O_EXCL just prevents you 
> >> from trying such foolishness and creating a coaster. 
> >
> >It does not prevent you from creatig a coaster in case you connect e.g.
> >two ATAPI writers to the same ATA cable.
> >
> Apart from transfer speed issues and potential buffer underruns coming 
> along with that, is there anything technically impossible with writing to 
> two ATAPI drives at the same time?

Bus locking while waiting for command completion. If you start a
long-lasting operation on one device, the other device on the same cable
is blocked so you cannot feed the other.

Same holds for SCSI if one of the devices involved doesn't disconnect
from the bus for that long-lasting command.

Try for instance "eject /dev/hdc" while writing to /dev/hdd, or same
stuff with sr0 and sr1. Been there, done that, got a coaster.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Phillip Susi]

Joerg Schilling wrote:
>> You CAN'T have multiple cdrecord processes burning the same disc at the 
>> same time; the very idea makes no sense.  The O_EXCL just prevents you 
>> from trying such foolishness and creating a coaster. 
>>     
>
> It does not prevent you from creatig a coaster in case you connect e.g.
> two ATAPI writers to the same ATA cable.

So what?  What does that have to do with my rebutting your statement 
that O_EXCL prevents multiple cdrecords?  O_EXCL also does not prevent 
you from kicking the plug out of the wall while burning, but it DOES 
prevent another process from trying to mess with the drive while 
cdrecord is and clobbering things up, which is a good thing.  It does 
not prevent you from using cdrecord at the same time on different drives. 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Lee Revell]

On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> Apparently O_EXCL was added by Ubuntu and Debian to stop
> burns being corrupted by hald polling the device while a disc is
> being burned. 

IO priorities are the correct solution...

Lee

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jim Crilly]

On 02/02/06 04:25:50PM -0500, Lee Revell wrote:
> On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> > Apparently O_EXCL was added by Ubuntu and Debian to stop
> > burns being corrupted by hald polling the device while a disc is
> > being burned. 
> 
> IO priorities are the correct solution...
> 
> Lee

Is this something that's available now?

Jim.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Lee Revell]

On Thu, 2006-02-02 at 16:49 -0500, Jim Crilly wrote:
> On 02/02/06 04:25:50PM -0500, Lee Revell wrote:
> > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> > > Apparently O_EXCL was added by Ubuntu and Debian to stop
> > > burns being corrupted by hald polling the device while a disc is
> > > being burned. 
> > 
> > IO priorities are the correct solution...
> > 
> > Lee
> 
> Is this something that's available now?
> 

Yes but only in the CFQ IO scheduler, and a pre-release util-linux is
required to get the docs and command line utils.

Lee

Re: CD writing in future Linux (stirring up a hornets' nest)

[Lee Revell]

On Thu, 2006-02-02 at 16:49 -0500, Jim Crilly wrote:
> On 02/02/06 04:25:50PM -0500, Lee Revell wrote:
> > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> > > Apparently O_EXCL was added by Ubuntu and Debian to stop
> > > burns being corrupted by hald polling the device while a disc is
> > > being burned. 
> > 
> > IO priorities are the correct solution...
> > 
> > Lee
> 
> Is this something that's available now?
> 

Hmm, actually I'm not sure it would make a difference, as I don't think
CD writing goes through the regular IO scheduler.

Lee

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jens Axboe]

On Thu, Feb 02 2006, Lee Revell wrote:
> On Thu, 2006-02-02 at 16:49 -0500, Jim Crilly wrote:
> > On 02/02/06 04:25:50PM -0500, Lee Revell wrote:
> > > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> > > > Apparently O_EXCL was added by Ubuntu and Debian to stop
> > > > burns being corrupted by hald polling the device while a disc is
> > > > being burned. 
> > > 
> > > IO priorities are the correct solution...
> > > 
> > > Lee
> > 
> > Is this something that's available now?
> > 
> 
> Hmm, actually I'm not sure it would make a difference, as I don't think
> CD writing goes through the regular IO scheduler.

Right, you can only prioritize "regular" io, not stuff sent with SG_IO.
So it'll help burning only for the case of getting the data required to
the buffer, not in getting that data out to the burner. The latter is
usually not a problem though, as these requests take a 'short cut'
directly to the dispatch queue.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote:
> > Apparently O_EXCL was added by Ubuntu and Debian to stop
> > burns being corrupted by hald polling the device while a disc is
> > being burned. 
>
> IO priorities are the correct solution...

No, they are not. 

The correct solution is to implement "hald" in a _cooperative_ way 
like e.g. vold on Solaris.

The main point is not to poll to frequent (Solaris does once everz 3 seconds)
and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>
>The main point is not to poll to frequent (Solaris does once everz 3 seconds)
>and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing.
>

I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although 
hal [seems to] probes more often than once/3sec, it did not interrupt any 
of my cd writing processes. Maybe that's already a feature of cdrecord*, I 
don't know.
(With an older drive (AOpen CRW1232), the whole IDE bus was even 
blocked when blanking, leaving no option but to wait.)


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Kay Sievers]

On Fri, Feb 03, 2006 at 02:51:10PM +0100, Jan Engelhardt wrote:
> >
> >The main point is not to poll to frequent (Solaris does once everz 3 seconds)
> >and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing.
> >
> 
> I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although 
> hal [seems to] probes more often than once/3sec,

It polls every 2 seconds.

> it did not interrupt any 
> of my cd writing processes. Maybe that's already a feature of cdrecord*, I 
> don't know.

I don't know of any problem in that area and almost every modern Linux
desktop has HAL running these days, so I'm sure somebody would have
complained.

Kay

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Fri, Feb 03, 2006 at 02:51:10PM +0100, Jan Engelhardt wrote:
> > >
> > >The main point is not to poll to frequent (Solaris does once everz 3 seconds)
> > >and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing.
> > >
> > 
> > I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although 
> > hal [seems to] probes more often than once/3sec,
>
> It polls every 2 seconds.

What SCSI commands does it use?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >
> >The main point is not to poll to frequent (Solaris does once everz 3 seconds)
> >and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing.
> >
>
> I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although 
> hal [seems to] probes more often than once/3sec, it did not interrupt any 
> of my cd writing processes. Maybe that's already a feature of cdrecord*, I 
> don't know.
> (With an older drive (AOpen CRW1232), the whole IDE bus was even 
> blocked when blanking, leaving no option but to wait.)

If you like to investigate on this, you would need to e.g. use cdrecord to 
write a DVD on a Pioneer DVD writer of check a notebook with only one ATA cable 
for both HDD and DVD-writer.

The fact that it does work for you does not prove that there is no problem.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> I see the same thing with, the only external kernel patch I have
> applied is Suspend2. The ATA scanbus code tries to 
> open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since
> the scanning code stops once one device fails to open the whole scan
> aborts. Apparently O_EXCL was added by Ubuntu and Debian to stop
> burns being corrupted by hald polling the device while a disc is
> being burned. If you want to read the entire thread it's bug #262678
> in Debian.

This is an excellent example to verify how bad Linux distribution developent
is done.....

Note that the main problem here is an applicaion unfriendly service 
on Linux that disturbes other applications like cdrecord.

As there is a bug in this service, I would expect that this bug should be fixed.
Instead of doing this or at least trying to get help from experienced people 
like me, some people did prefer to change cdrecord in a way that caused more
problems than it pretends to fix.

Note that the "requirement" for O_EXCL is a bad idea and needs fixing.
If you believe that this is impossible, just have a look at the OpenSolaris vold
and volfs subsystem.....

Note that Linux distributors apply other changes to cdrecord that causes 
problems in the same area: patching cdrecord to allow a grace time < 3 seconds
of course disallows a useful solution in this area.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Paul Jakma]

On Tue, 31 Jan 2006, Joerg Schilling wrote:

> What Linux does is to artificially prevent this view to been seen 
> from outside the Linux kernel, or to avoid integrating a particular 
> device into a unique SCSI driver system although it would be 
> apropriate.

So let's get this straight: Linux is artificially limiting userspace 
from viewing devices in terms of parallel SCSI address (B/T/L) 
because it does not create such B/T/L addresses, ones which would 
hence be *artificial* themselves, for non-parallel-SCSI devices?

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
zeal, n.:
 	Quality seen in new graduates -- if you're quick.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Albert Cahalan]

On 1/31/06, Paul Jakma <paul@clubi.ie> wrote:
> On Tue, 31 Jan 2006, Joerg Schilling wrote:
>
> > What Linux does is to artificially prevent this view to been seen
> > from outside the Linux kernel, or to avoid integrating a particular
> > device into a unique SCSI driver system although it would be
> > apropriate.
>
> So let's get this straight: Linux is artificially limiting userspace
> from viewing devices in terms of parallel SCSI address (B/T/L)
> because it does not create such B/T/L addresses, ones which would
> hence be *artificial* themselves, for non-parallel-SCSI devices?

There is a slim chance that Joerg might really believe that
Linux has an internal B/T/L view of everything. That would
be odd to us of course. He has clearly been spending time
with the Solaris kernel. If his only kernel experience comes
from systems that do make up a phony B/T/L view, then he might
just assume that all operating systems are designed this way.

For Joerg's reference, open() goes like this:

1. the /dev name
2. the inode
3. the device number
4. pointers to structs full of function pointers

Nowhere is it in B/T/L form.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Paul Jakma]

On Wed, 1 Feb 2006, Albert Cahalan wrote:

> For Joerg's reference, open() goes like this:
>
> 1. the /dev name
> 2. the inode
> 3. the device number
> 4. pointers to structs full of function pointers
>
> Nowhere is it in B/T/L form.

And, for whatever it's worth, TTBOMK Solaris does not arrange SCSI 
into a B/T/L address hierarchy internally either.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Mystics always hope that science will some day overtake them.
 		-- Booth Tarkington

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

> Cdrecord is a program that needs to be able to send any SCSI command as 
> it needs to be able to add new vendor unique commands for new drive/feature
> support.

On this we do agree, drive vendors seem to add every new feature with a 
vendor code. Some are NOT required to write CD, but some are needed to 
write "better" CDs, for some definition of better which could mean 
faster, more reliable, special modes, etc.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

James Courtier-Dutton <James@superbug.co.uk> wrote:

> Would you be able to add the appropriate kernel bugzilla numbers?

As before people from LKML did not like to even talk about these bugs, 
I did stop after sending bug reports to LKML.

> I think it might also be useful to make a list of all the SCSI commands 
> that cdrecord uses. Including all the vendor specific ones. One could 
> then verify that the Linux kernel is passing them onto the device correctly.


It is simple to find the SCSI commands that cdrecord by scanning the source (*),
but this is something that is subject to frequent change in case cdrecord needs
to add new MMC-4711 commands or in case that I need to add a new vendor unique
command in order to support special features.


*) Just grep for "cdb.cmd"


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Albert Cahalan]

On 1/25/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Albert Cahalan <acahalan@gmail.com> wrote:

> > BTW, before Joerg mentions portability, I'd like to remind
> > everyone that all modern OSes support the use of normal device
> > names for SCSI. The most awkward is FreeBSD, where you have
> > to do a syscall or two to translate the name to Joerg's very
> > non-hotplug non-iSCSI way of thinking. Windows, MacOS X, and
> > even Solaris all manage to handle device names just fine. In
> > numerous cases, not just Linux, cdrecord is inventing crap out
> > of thin air to satisfy a pre-hotplug worldview.
>
> Looks like you are badly informed, so I encourage you to get yourself informed
> properly before sending your next postig....
>
> libscg includes 22 different SCSI low level transport implementations.
>
> -       Only 5 of them allow a /dev/hd* device name related access.
>
> -       11 of them use file descriptors as handles for sending SCSI
>         commands but do not have a name <-> fs relation and thus
>         _need_ a SCSI device naming scheme as libscg offers.
>         This is because there is no 1:1 relation between SCSI addressing
>         and a fd retrieved from a /dev/* entry.
>
> -       6 of them not even allow to get a file descriptors as handles for
>         sending SCSI commands. These platforms of course need the SCSI device
>         naming scheme as libscg offers.
>
> Conclusion:
>
> 17 Platforms _need_ the addressing scheme libscg offers
>
> 5  Platforms _may_ use a different access method too.
>
> NOTE: Amongst the 6 plaforms that do not allow to even get a file descriptor
> there is a modern OS like MacOS X

You can't fool me, because I looked at the cdrecord source
code and at the documented APIs for various OSes.

It's misleading to say that MacOS doesn't allow a file
descriptor. MacOS has something similar to what Linux
has, but not in the normal filesystem namespace. You
specify a name to get a handle. Of course, on MacOS,
Joerg also uses -scanbus to create nonsense.

Names can be handled by Windows, FreeBSD, MacOS X,
Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX.
That's everything that isn't end-of-lifed.

The rest of your 22 platforms are dead and dying things
that are unlikely to be upgrading to the latest software or
hardware, assuming they survived the Y2K bug. It's old
stuff like the Amiga, the NeXT, etc.

Using numbers for CD burners is like trying to send email
to the IP address of the recipient, which half-way worked
until DHCP was invented. Wait, we could have all email
clients offer a -scannet option. :-)

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

On Wed, 25 Jan 2006, Albert Cahalan wrote:

> It's misleading to say that MacOS doesn't allow a file
> descriptor. MacOS has something similar to what Linux
> has, but not in the normal filesystem namespace. You
> specify a name to get a handle. Of course, on MacOS,
> Joerg also uses -scanbus to create nonsense.

OK, so Jörg created this "nonsense", i. e. a triple of stupid numbers,
and claims he's using them to provide device lists to applications.

What prevents any of these GUIs from treating the "name" as an opaque
string? How would ATA:4,0,0 be different from 2,2,0 or /dev/hdc?

And how is the phantom GUI application obtaining the data? It needs to
scan all buses anyhow, and run -scanbus for each and every "transport
identifier" to get a grip of all devices, because cdrecord-with-libscg
is too stupid to do that by itself and unlist inferior (in its view, or
in the public view) identifiers (such as the PIO-only ATAPI:).

Here's an idea:

recognizing cdrecord may be portable, I wonder if it (or libscg for that
matter) is extensible or made decisions where it can decouple its
devices from the GUI application. Stating that the device ID no matter
how it looks today would be an opaque string not to be processed by the
GUI might be a first step to gain the necessary degrees of freedom to
change to ATA:/dev/hdc or just /dev/hdc (I don't mind which).

> Using numbers for CD burners is like trying to send email
> to the IP address of the recipient, which half-way worked
> until DHCP was invented. Wait, we could have all email
> clients offer a -scannet option. :-)

Well, in PeeCees, the BIOS presents that list of primary/secondary
master/slave, so there's /some/ point in it. Once hotplug comes into
play, it's all vain though.

(removing Lee from the Cc: list)

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> On Wed, 25 Jan 2006, Albert Cahalan wrote:
>
> > It's misleading to say that MacOS doesn't allow a file
> > descriptor. MacOS has something similar to what Linux
> > has, but not in the normal filesystem namespace. You
> > specify a name to get a handle. Of course, on MacOS,
> > Joerg also uses -scanbus to create nonsense.
>
> OK, so Jörg created this "nonsense", i. e. a triple of stupid numbers,
> and claims he's using them to provide device lists to applications.

More than 2/3 of all current OS use this way of adressing and it is 
a standard: (CAM).

> Well, in PeeCees, the BIOS presents that list of primary/secondary
> master/slave, so there's /some/ point in it. Once hotplug comes into
> play, it's all vain though.

Hotplug is only a problem when implemented in a sub-optimal way.
Please have a look at Solaris for hot plug support with stable interface 
names.... 

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Albert Cahalan <acahalan@gmail.com> wrote:

> > Conclusion:
> >
> > 17 Platforms _need_ the addressing scheme libscg offers
> >
> > 5  Platforms _may_ use a different access method too.
> >
> > NOTE: Amongst the 6 plaforms that do not allow to even get a file descriptor
> > there is a modern OS like MacOS X
>
> You can't fool me, because I looked at the cdrecord source
> code and at the documented APIs for various OSes.

I am sorry to see that you did not look close enough...


> It's misleading to say that MacOS doesn't allow a file
> descriptor. MacOS has something similar to what Linux
> has, but not in the normal filesystem namespace. You
> specify a name to get a handle. Of course, on MacOS,
> Joerg also uses -scanbus to create nonsense.
>
> Names can be handled by Windows, FreeBSD, MacOS X,
> Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX.
> That's everything that isn't end-of-lifed.

Aha, so you like to state that MS-WIN is end-of-lifed?
Is this secret new information from Microsoft?

Solaris is not on this list, because the only way to send SCSI commands to any 
kind of SCSI target is by using my /dev/scg driver.

AIX is not on this list because the only way to send SCSI commands to any
target is by using the /dev/gsc driver from Mathew Jacob who is a former
Sun employee and who did get the idea for this driver from a talk with me 
during a visit at Sun in 1987.

FreeBSD is not on the list as it uses CAM, similar to BeOS (Zeta), 
OSF1 (True 64) and QNX.

IRIX is not on this list because it uses the same kind of interface as
e.g. HP-UX does

	snprintf(devname, sizeof (devname),
			"/dev/scsi/sc%dd%dl%d", busno, tgt, tlun);


Next try please....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matan Peled]

Joerg Schilling wrote:
> Albert Cahalan <acahalan@gmail.com> wrote:
>> Names can be handled by Windows, FreeBSD, MacOS X,
>> Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX.
>> That's everything that isn't end-of-lifed.
> Aha, so you like to state that MS-WIN is end-of-lifed?
> Is this secret new information from Microsoft?

I'm not an expert in SCSI implementation quirks across varying platfroms, but 
you made a mistake here, Joerg.

Albert put Windows (==MS-WIN) in that list. First one, even.

-- 
[Name      ]   ::  [Matan I. Peled    ]
[Location  ]   ::  [Israel            ]
[Public Key]   ::  [0xD6F42CA5        ]
[Keyserver ]   ::  [keyserver.kjsl.com]
encrypted/signed  plain text  preferred

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matan Peled <chaosite@gmail.com> wrote:

> Joerg Schilling wrote:
> > Albert Cahalan <acahalan@gmail.com> wrote:
> >> Names can be handled by Windows, FreeBSD, MacOS X,
> >> Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX.
> >> That's everything that isn't end-of-lifed.
> > Aha, so you like to state that MS-WIN is end-of-lifed?
> > Is this secret new information from Microsoft?
>
> I'm not an expert in SCSI implementation quirks across varying platfroms, but 
> you made a mistake here, Joerg.
>
> Albert put Windows (==MS-WIN) in that list. First one, even.

I encourage you to inform yourself about MS-WIN and to find you that
you are wrong.

Under MS-WIN, you use either ASPI -> no open fd at all
or you use something that is very similar to my /dev/scg* device 
on Solaris which uses/defines abstract SCSI transport devices instead of 
possibly unknown high level devices like a disk driver.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>IRIX is not on this list because it uses the same kind of interface as
>e.g. HP-UX does
>
>	snprintf(devname, sizeof (devname),
>			"/dev/scsi/sc%dd%dl%d", busno, tgt, tlun);

So, would you want something like (free format string imagination)
   "/dev/sg-%d-%d-%d", busno, tgt, lun
on Linux?


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Albert Cahalan]

On 1/26/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Albert Cahalan <acahalan@gmail.com> wrote:

> > You can't fool me, because I looked at the cdrecord source
> > code and at the documented APIs for various OSes.
>
> I am sorry to see that you did not look close enough...
...
> > Names can be handled by Windows, FreeBSD, MacOS X,
> > Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX.
> > That's everything that isn't end-of-lifed.

OK, this is getting silly and downright offensive. I encourage
everyone else to look over the code to see that I am right.

I may just be crazy enough to fork this project. I very nearly
did about 18 months ago. I can't very well do this alone,
because I don't have all the hardware. (It's either cdrecord
or Asterisk -- I'm not sure which one pisses me off the most)

Me:

* was an RTOS developer
* day job is all about secure software
* the procps maintainer
* running Linux 2.6.xx only
* using FireWire, which is totally hot-plug

Perhaps the first thing to do would be to find a list of all the
apps that depend on cdrecord. Their interface to cdrecord
needs to be documented so that a compatibility script can
be made.

Matthias, can you give me a hand with this? I'll need a way
to sort and publish incoming patches, letting them sit for a
while. (like what Andrew Morton does for the kernel) This
can't work like procps because the hardware varies too much.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Kyle Moffett]

On Jan 26, 2006, at 19:19, Albert Cahalan wrote:
> I may just be crazy enough to fork this project. I very nearly did  
> about 18 months ago. I can't very well do this alone, because I  
> don't have all the hardware

I will gladly test your fork on my various hardware here.  I have a  
desktop with Apple CD/RW+DVDROM and generic DVD+/-RW DL drive, and a  
laptop with Apple DVD+/-RW drive.  Just send or post patches  
somewhere and I'll take a look.  I suggest starting by looking at  
some of the various distro patches, IIRC some of them have already  
make significant cleanups.

> Matthias, can you give me a hand with this? I'll need a way to sort  
> and publish incoming patches, letting them sit for a while. (like  
> what Andrew Morton does for the kernel) This can't work like procps  
> because the hardware varies too much.

Might I suggest quilt or stgit?  Both allow you to maintain an  
unstable and highly variable stack of patches based off a more stable  
branch, from which some patches percolate down into stable occasionally.

Good luck with this!

Cheers,
Kyle Moffett

--
Simple things should be simple and complex things should be possible
   -- Alan Kay

Re: CD writing in future Linux (stirring up a hornets' nest)

[Xavier Bestel]

On Fri, 2006-01-27 at 01:19, Albert Cahalan wrote:
> I may just be crazy enough to fork this project. I very nearly
> did about 18 months ago. I can't very well do this alone,
> because I don't have all the hardware.

Then contribute code to libburn: <http://icculus.org/burn/>

	Xav

Re: CD writing in future Linux (stirring up a hornets' nest)

[DervishD]

    Hi Albert :)

 * Albert Cahalan <acahalan@gmail.com> dixit:
> I may just be crazy enough to fork this project. I very nearly
> did about 18 months ago. I can't very well do this alone,
> because I don't have all the hardware.

    You can count on a Plextor Premium and a AOpen 1616ARR here. I
also have another Plextor DVD708 but it no longer writes CDs :((
I will gladly test your fork here.

    And of course, you can count on any writer I can put my hands on.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

Albert Cahalan wrote:

> OK, this is getting silly and downright offensive. I encourage
> everyone else to look over the code to see that I am right.
> 
> I may just be crazy enough to fork this project. I very nearly
> did about 18 months ago. I can't very well do this alone,
> because I don't have all the hardware. (It's either cdrecord
> or Asterisk -- I'm not sure which one pisses me off the most)

I can test on various 2.6 kernel ATAPI CD and DVD burners, and on 2.4 
kernel even a real SCSI CD burner as long as it lasts. I would love to 
see some mutual cooperation, but I doubt it's going to happen.

Just to be clear, Joerg is not the only one I think has been a problem 
here, he pissed off some of the developers who don't seem overly eager 
to do things which would be helpful for any burner software. From here 
it looks like a pissing content, with users well within splash range.
> 
> * was an RTOS developer
> * day job is all about secure software
> * the procps maintainer
> * running Linux 2.6.xx only
> * using FireWire, which is totally hot-plug
> 
> Perhaps the first thing to do would be to find a list of all the
> apps that depend on cdrecord. Their interface to cdrecord
> needs to be documented so that a compatibility script can
> be made.

Do you plan on changing the interface, then? Removing the SCSI stuff 
completely? Do bear in mind that there are still SCSI burners and people 
using them, and cdrecord is currently portable to many operating systems.
> 
> Matthias, can you give me a hand with this? I'll need a way
> to sort and publish incoming patches, letting them sit for a
> while. (like what Andrew Morton does for the kernel) This
> can't work like procps because the hardware varies too much.

Look a year down the road, when we have have two (or more) new 25GB 
optical formats coming out, probably with new features and commands and 
several vendors building drives for them. Both formats have DRM stuff in 
them, and GPL 3 forbids implementing DRM (simplification).

Better you than me, but it will be exciting. To the extent that I have 
the hardware I'll be glad to test.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

On Mon, 30 Jan 2006, Bill Davidsen wrote:

> Just to be clear, Joerg is not the only one I think has been a problem 
> here, he pissed off some of the developers who don't seem overly eager 
> to do things which would be helpful for any burner software. From here 
> it looks like a pissing content, with users well within splash range.

Well, Jörg is not giving us answers to the extent that might convince a
Linux kernel hacker to change things, except for a few handrails besides
the staircase, such as Ted's suggestion WRT RLIMIT_MEMLOCK, or people
offering to fix ide-tape to talk SG_IO - Jörg however has not yet
documented how ide-tape fixes are relevant for the CD writing
application (no doubt that a SCSI /GENERAL/ interface library has
interest in such, it does not matter to the CD writing topic).

> Look a year down the road, when we have have two (or more) new 25GB 
> optical formats coming out, probably with new features and commands and 
> several vendors building drives for them. Both formats have DRM stuff in 
> them, and GPL 3 forbids implementing DRM (simplification).

I find it fascinating that everyone talks about the first public GPL v3
draft as though it were the final version. Now is the time to express
concerns, for instance, the GPL's incompatibility, to the FSF.

And no, I do not have current plans to work on a cdrecord fork as it is.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Lee Revell]

On Mon, 2006-01-30 at 16:49 -0500, Bill Davidsen wrote:
> Look a year down the road, when we have have two (or more) new 25GB 
> optical formats coming out, probably with new features and commands
> and several vendors building drives for them. Both formats have DRM
> stuff in them, and GPL 3 forbids implementing DRM (simplification). 

Who cares what GPL 3 says, the kernel is GPL2.

Lee

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

Lee Revell wrote:

>On Mon, 2006-01-30 at 16:49 -0500, Bill Davidsen wrote:
>  
>
>>Look a year down the road, when we have have two (or more) new 25GB 
>>optical formats coming out, probably with new features and commands
>>and several vendors building drives for them. Both formats have DRM
>>stuff in them, and GPL 3 forbids implementing DRM (simplification). 
>>    
>>
>
>Who cares what GPL 3 says, the kernel is GPL2.
>

Did you miss the subject? My reply was to a suggestion that cdrecord 
(it's not the kernel!) be forked, and discussion of what license MIGHT 
apply. I was making an information point about an application which is 
very important to a lot of people.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: CD writing in future Linux (stirring up a hornets' nest)

[Albert Cahalan]

Jan Engelhardt writes:

> Where is the difference between SG_IO-on-hdx and sg0?

It's like the /dev/ttyS* and /dev/cua* situation, where
we also ended up with multiple device files. This is bad.

SG_IO-on-hdx is modern. It properly associates everything
with one device, which you may name as desired.

sg0 is useful for devices that are not disk, tape, or CD.
A decade ago, it was also the proper way to send raw SCSI
commands to other devices. For nasty compatibility reasons,
Linux still assigns /dev/sg* devices for disk, tape, and CD.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> Where is the difference between SG_IO-on-hdx and sg0?
>
>It's like the /dev/ttyS* and /dev/cua* situation, where
>we also ended up with multiple device files. This is bad.
>
>SG_IO-on-hdx is modern. It properly associates everything
>with one device, which you may name as desired.

Let's analyze a case:
if /dev/sg0 would always be associated with /dev/hda,
/dev/sg1 always with /dev/hdb, no matter if there was actually a
hda/sg0 device present in the system - would that simplify
the problem?


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jens Axboe]

On Wed, Jan 25 2006, Jan Engelhardt wrote:
> 
> >> Where is the difference between SG_IO-on-hdx and sg0?
> >
> >It's like the /dev/ttyS* and /dev/cua* situation, where
> >we also ended up with multiple device files. This is bad.
> >
> >SG_IO-on-hdx is modern. It properly associates everything
> >with one device, which you may name as desired.
> 
> Let's analyze a case:
> if /dev/sg0 would always be associated with /dev/hda,
> /dev/sg1 always with /dev/hdb, no matter if there was actually a
> hda/sg0 device present in the system - would that simplify
> the problem?

Forget /dev/sg0, it's meaningless and confusing to try and bind two
unrelated names to each other. You want to talk to /dev/hda, use
/dev/hda. Don't try and create a pseudo mapping between the two. That's
also where cdrecord gets it wrong on Linux - you don't need -scanbus. If
users think they do, it's either because Joerg brain washed them or
because they have been used to that bad interface since years ago when
it was unfortunately needed.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>
>- you don't need -scanbus. If
>users think they do, it's either because Joerg brain washed them or
>because they have been used to that bad interface since years ago when
>it was unfortunately needed.

Now you're unfair.
-scanbus does a nice output of what cdwriters (and other capable devices) 
are present. For me, that lists the cd writer and a CF slot from the 
multitype usb flash reader.

There's one kind of not-so-advanced linux newbies that just go to walmart, 
buy a computer and whack a linux system on it for fun, and they still don't 
know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is 
usually a nightmare for them, and apart that -scanbus lists scsi 
host,id,lun instead of /dev/hd* (don't comment on this kthx), it is 
convenient for this sort of users to find out what's available.

So, and what about that compactflash reader? It is subject to dynamic 
usb->scsi device association (depending on when you connect it, it may 
either become sda, or sdb, or sdc, etc.), and -scanbus yet again provides 
some way (albeit not useful, because it lists scsi,id,lun rather than 
/dev/sd* - don't comment either) to see where it actually is.



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jens Axboe]

On Wed, Jan 25 2006, Jan Engelhardt wrote:
> 
> >
> >- you don't need -scanbus. If
> >users think they do, it's either because Joerg brain washed them or
> >because they have been used to that bad interface since years ago when
> >it was unfortunately needed.
> 
> Now you're unfair.
> -scanbus does a nice output of what cdwriters (and other capable devices) 
> are present. For me, that lists the cd writer and a CF slot from the 
> multitype usb flash reader.
> 
> There's one kind of not-so-advanced linux newbies that just go to walmart, 
> buy a computer and whack a linux system on it for fun, and they still don't 
> know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is 
> usually a nightmare for them, and apart that -scanbus lists scsi 
> host,id,lun instead of /dev/hd* (don't comment on this kthx), it is 
> convenient for this sort of users to find out what's available.
> 
> So, and what about that compactflash reader? It is subject to dynamic 
> usb->scsi device association (depending on when you connect it, it may 
> either become sda, or sdb, or sdc, etc.), and -scanbus yet again provides 
> some way (albeit not useful, because it lists scsi,id,lun rather than 
> /dev/sd* - don't comment either) to see where it actually is.

You just want the device naming to reflect that. The user should not
need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
likely be using k3b or something graphical though, and just click on his
Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
help do this dynamically even.

If you are using cdrecord on the command line, you are by definition an
advanced user and know how to find out where that writer is.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Jens Axboe <axboe@suse.de> wrote:

> You just want the device naming to reflect that. The user should not
> need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> likely be using k3b or something graphical though, and just click on his
> Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> help do this dynamically even.

Guess why cdrecord -scanbus is needed.

It serves the need of GUI programs for cdrercord and allows them to retrieve 
and list possible drives of interest in a platform independent way.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling wrote:
> Jens Axboe <axboe@suse.de> wrote:
> 
>> You just want the device naming to reflect that. The user should not
>> need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
>> likely be using k3b or something graphical though, and just click on his
>> Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
>> help do this dynamically even.
> 
> Guess why cdrecord -scanbus is needed.
> 
> It serves the need of GUI programs for cdrercord and allows them to retrieve 
> and list possible drives of interest in a platform independent way.

There are bugs in the implementation that prevent -scanbus from working
properly, and they are not Linux bugs. Once -scanbus really scans all
devices and skips those it cannot access (rather than quitting), you might
have a point.

Re: CD writing in future Linux (stirring up a hornets' nest)

[grundig]

El Wed, 25 Jan 2006 18:03:18 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:

> Guess why cdrecord -scanbus is needed.
> 
> It serves the need of GUI programs for cdrercord and allows them to retrieve 
> and list possible drives of interest in a platform independent way.

But this is not neccesary at all, since linux platform already provides ways to
retrieve and list possible drives....

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jens Axboe]

On Wed, Jan 25 2006, grundig@teleline.es wrote:
> El Wed, 25 Jan 2006 18:03:18 +0100,
> Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:
> 
> > Guess why cdrecord -scanbus is needed.
> > 
> > It serves the need of GUI programs for cdrercord and allows them to retrieve 
> > and list possible drives of interest in a platform independent way.
> 
> But this is not neccesary at all, since linux platform already
> provides ways to retrieve and list possible drives....

In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
on potentially useful devices.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Jens Axboe wrote:

> In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
> on potentially useful devices.

Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather
complicated and non-portable. I understand that applications that can just
open every device and send SCSI INQUIRY might want to do that on Linux, too.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jens Axboe]

On Wed, Jan 25 2006, Matthias Andree wrote:
> Jens Axboe wrote:
> 
> > In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
> > on potentially useful devices.
> 
> Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather
> complicated and non-portable. I understand that applications that can just
> open every device and send SCSI INQUIRY might want to do that on Linux, too.

Certainly, I'm just suggesting a better way to do it on Linux.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

(stripped Lee from the Cc: list)

Jens Axboe schrieb am 2006-01-25:

> > Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather
> > complicated and non-portable. I understand that applications that can just
> > open every device and send SCSI INQUIRY might want to do that on Linux, too.
> 
> Certainly, I'm just suggesting a better way to do it on Linux.

Great. There's a better way, but it is not necessary. Let Linux-specific
applications use it for their benefit, but a portable application isn't
going that way because it's too much effort. If a simpler interface that
can be shared with half a dozen other system exists, the portable
application will use that and ignore better interfaces.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[grundig]

El Thu, 26 Jan 2006 00:14:22 +0100,
Matthias Andree <matthias.andree@gmx.de> escribió:

> Great. There's a better way, but it is not necessary. Let Linux-specific
> applications use it for their benefit, but a portable application isn't
> going that way because it's too much effort. If a simpler interface that
> can be shared with half a dozen other system exists, the portable
> application will use that and ignore better interfaces.

It's too "much effort"? Basically, what linux is asking is that cdrecord
stop wasting efforts trying to implement its own solution. Linux is 
asking cdrecord to use SG_IO and leave device discovery and data transport
issues to the platform.

Linux doesn't even need -scanbus for example. You could compile out that
code. Device discovery is done by the platform - I find _scary_ that other
"modern" operative systems don't have a way of providing device discovery
services in 2006 and that a external app is needed but hey, people is free
to design their operative system as they like. Linux provides it and leaves
Schilling time to focus in other things. In my book, that's not "too much
effort", is "less effort". If someone bugs you because SG_IO doesn't work
just tell him to report the problem here - in fact cdrecord already has a
"friendly" warning about "linux-2.5 and newer". The cdrecord low level
scsi driver for SG_IO should be much simpler than all the others...

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

On Thu, 26 Jan 2006, grundig@teleline.es wrote:

> It's too "much effort"? Basically, what linux is asking is that cdrecord
> stop wasting efforts trying to implement its own solution. Linux is 
> asking cdrecord to use SG_IO and leave device discovery and data transport
> issues to the platform.
> 
> Linux doesn't even need -scanbus for example. You could compile out that
> code. Device discovery is done by the platform - I find _scary_ that other
> "modern" operative systems don't have a way of providing device discovery
> services in 2006 and that a external app is needed but hey, people is free
> to design their operative system as they like. Linux provides it and leaves
> Schilling time to focus in other things. In my book, that's not "too much
> effort", is "less effort". If someone bugs you because SG_IO doesn't work
> just tell him to report the problem here - in fact cdrecord already has a
> "friendly" warning about "linux-2.5 and newer". The cdrecord low level
> scsi driver for SG_IO should be much simpler than all the others...

Well, you need to implement 30 (or so) platform-specific ways to get a
list of devices, and portable applications aren't going to do that. To
make it explicit: no way. It is a maintenance nightmare, 30 lowly-tested
pieces of code, too.

This sounds like a huge difference, but I don't believe it actually is.
Jörg is trying to fight the system rather than stop complaining to users
about their using /dev/hd*. The scanning code is there and can be made
working with little effort probably.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> Well, you need to implement 30 (or so) platform-specific ways to get a
> list of devices, and portable applications aren't going to do that. To
> make it explicit: no way. It is a maintenance nightmare, 30 lowly-tested
> pieces of code, too.

It already works in libscg since nearly 10 years.

> This sounds like a huge difference, but I don't believe it actually is.
> Jörg is trying to fight the system rather than stop complaining to users
> about their using /dev/hd*. The scanning code is there and can be made
> working with little effort probably.

Talking about /dev/hd* ignore the basic problem. Show me a way how to
send SCSI commands to a ATAPI tape drive on Linux. 

Please do not forget that libscg is OS _and_ device independent.
Implementing /dev/hd* support at all is already a concession that did go to far.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 824 bytes --]

>> This sounds like a huge difference, but I don't believe it actually is.
>> Jörg is trying to fight the system rather than stop complaining to users
>> about their using /dev/hd*. The scanning code is there and can be made
>> working with little effort probably.
>
>Talking about /dev/hd* ignore the basic problem. Show me a way how to
>send SCSI commands to a ATAPI tape drive on Linux. 

ATAPI tapes writing CDs (or tapes for that amtter). It may seem possible if 
the scsi command is the same.
Feels like making tea in a coffee machine, but hey, it's possible,
and sounds like Someone want's to have it. :)

>Please do not forget that libscg is OS _and_ device independent.

If so, how much effort is there in having libscg building an enumeration 
out of all (related to cd writing) sysfs drives?


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> 
>>Well, you need to implement 30 (or so) platform-specific ways to get a
>>list of devices, and portable applications aren't going to do that. To
>>make it explicit: no way. It is a maintenance nightmare, 30 lowly-tested
>>pieces of code, too.
> 
> 
> It already works in libscg since nearly 10 years.
> 
> 
>>This sounds like a huge difference, but I don't believe it actually is.
>>Jörg is trying to fight the system rather than stop complaining to users
>>about their using /dev/hd*. The scanning code is there and can be made
>>working with little effort probably.
> 
> 
> Talking about /dev/hd* ignore the basic problem. Show me a way how to
> send SCSI commands to a ATAPI tape drive on Linux. 
> 
> Please do not forget that libscg is OS _and_ device independent.
> Implementing /dev/hd* support at all is already a concession that did go to far.

You added the feature, and a message that it was accidental and 
unsupported. In truth is was neither, and your little message pisses off 
developers and scares casual users.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

<grundig@teleline.es> wrote:

> It's too "much effort"? Basically, what linux is asking is that cdrecord
> stop wasting efforts trying to implement its own solution. Linux is 
> asking cdrecord to use SG_IO and leave device discovery and data transport
> issues to the platform.

Cddrecord does not use SG_IO, cdrecord uses the platform independent libscg.

If you like to talk on cdrecord, you are talking about the wrong thing.

libscg is the target of interest.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Nix]

On 25 Jan 2006, Matthias Andree prattled cheerily:
> Jens Axboe wrote:
> 
>> In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
>> on potentially useful devices.
> 
> Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather
> complicated and non-portable. I understand that applications that can just
> open every device and send SCSI INQUIRY might want to do that on Linux, too.

Applications (already) do this by asking HAL, which can be informed of
new devices in a variety of ways: the up-and-coming one is for the
kernel to notify udevd, following which a udev rule sends a dbus message
to HAL. Everything from the dbus message on up is cross-OS portable.
-scanbus is *totally* unnecessary.

(Furthermore, it fails to work in a quite laughable fashion in the
presence of hotpluggable storage media. udev handles giving hotpluggable
storage media consistent device names with extreme ease, and tells HAL
about them so that users see the new devices appear even if they don't
have a clue that /dev even exists.

The change that J. Random Nontechnical User will ever run `cdrecord
-scanbus' is *nil*, and applications don't run it either because they
can't judge between all the devices that are listed to pick the one
which is a CD recorder (consider the consequences should they guess
wrong!). Instead, they invariably ask for a device name, or, in more
recent versions get the info from HAL. HAL knows if something is a CD
recorder because its backend, e.g. udev, told it.)

-- 
`Everyone has skeletons in the closet.  The US has the skeletons
 driving living folks into the closet.' --- Rebecca Ore

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Nix <nix@esperi.org.uk> wrote:

> Applications (already) do this by asking HAL, which can be informed of
> new devices in a variety of ways: the up-and-coming one is for the
> kernel to notify udevd, following which a udev rule sends a dbus message
> to HAL. Everything from the dbus message on up is cross-OS portable.
> -scanbus is *totally* unnecessary.

Interesting theory.... unfortunately this makes assumptions that cannot be 
proved. Where is this HAL available and more impportant: how is it related
to generis transport and device independent 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 (stirring up a hornets' nest)

[Bill Davidsen]

red brick + atlantaNix wrote:
> On 25 Jan 2006, Matthias Andree prattled cheerily:
> 
>>Jens Axboe wrote:


>>Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather
>>complicated and non-portable. I understand that applications that can just
>>open every device and send SCSI INQUIRY might want to do that on Linux, too.
> 
> 
> Applications (already) do this by asking HAL, which can be informed of
> new devices in a variety of ways: the up-and-coming one is for the
> kernel to notify udevd, following which a udev rule sends a dbus message
> to HAL. Everything from the dbus message on up is cross-OS portable.
> -scanbus is *totally* unnecessary.

I notice that the first thing people suggest is to make things like 
udev, hal and sysfs required instead of optional to do something as 
simple as burn a CD. As I mentioned before, if the kernel provided a 
list of devices then applications wouldn't break every time a new kernel 
came out which needs a new this, and new that, and a few new other 
support things.

The kernel could provide a list of devices by category. It doesn't have 
to name them, run scripts, give descriptions, or paint them blue. Just a 
list of all block devices, tapes, by major/minor and category (ie. 
block, optical, floppy) would give the application layer a chance to do 
it's own interpretation. HAL is great, but because it's not part of the 
kernel it's also going to suffer from "tracking error" for some changes. 
I find it easier to teach someone to use -scanbus than to explain how to 
make rules for udev.
> 
> (Furthermore, it fails to work in a quite laughable fashion in the
> presence of hotpluggable storage media. udev handles giving hotpluggable
> storage media consistent device names with extreme ease, and tells HAL
> about them so that users see the new devices appear even if they don't
> have a clue that /dev even exists.
> 
> The change that J. Random Nontechnical User will ever run `cdrecord
> -scanbus' is *nil*, and applications don't run it either because they
> can't judge between all the devices that are listed to pick the one
> which is a CD recorder (consider the consequences should they guess
> wrong!). Instead, they invariably ask for a device name, or, in more
> recent versions get the info from HAL. HAL knows if something is a CD
> recorder because its backend, e.g. udev, told it.)
> 
Worth repeating: I find it easier to teach someone to use -scanbus than 
to explain how to make rules for udev. HAL is the right answer, but *in* 
the kernel, where it will track changes. Since -scanbus tells you a 
device is a CDrecorder, or something else, *any user* is likely to be 
able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices...

Note: my example of major/minor is just that, almost any presentation 
which showed all devices user applications would normally use, in a well 
defined way, would address the identifications issue.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: CD writing in future Linux (stirring up a hornets' nest)

[sean]

On Fri, 10 Feb 2006 16:06:39 -0500
Bill Davidsen <davidsen@tmr.com> wrote:


> I notice that the first thing people suggest is to make things like 
> udev, hal and sysfs required instead of optional to do something as 
> simple as burn a CD. 
> [snip]

All that is required is a proper device node in /dev; is this really
so much of a burden?   This device node can be created statically
at install time or via udev or any other method.   In fact if you're 
using udev and a device node isn't automatically created for all 
of your cd burners, you can file a bug report and get it fixed.   So in 
the end all you ever have to teach a user is to pick the device they
want from /dev.

Sean

Re: CD writing in future Linux (stirring up a hornets' nest)

[Christian Neumair]

Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen:
> The kernel could provide a list of devices by category. It doesn't have 
> to name them, run scripts, give descriptions, or paint them blue. Just a 
> list of all block devices, tapes, by major/minor and category (ie. 
> block, optical, floppy) would give the application layer a chance to do 
> it's own interpretation.

Introducing more than interface for doing the same thing can be very
confusing and counter-productive. You'll create new, undocumented or
semi-documented interfaces which will lead to a dependency chaos.

Some random script will work with kernel 2.6.11, 2.6.12 and 2.6.13, but
not 2.6.14 and later because a new device class was introduced and two
typos were fixed. Especially considering that the new linux development
model makes it likely that major changes go into micro releases,
stability and reliability will be a huge problem.

> HAL is great, but because it's not part of the 
> kernel it's also going to suffer from "tracking error" for some changes. 
> I find it easier to teach someone to use -scanbus than to explain how to 
> make rules for udev.

Tastes are different. I think the HAL semantics are perfectly OK for
doing what you want, i.e. you can use hal-find-by-capability together
with hal-get-property to get the block device paths of the installed
mass storage and for distinguishing them.

Distributors should ship sane udev rules applicable for 99.5% of the
people out there. They do, actually.

> > [...]
> Worth repeating: I find it easier to teach someone to use -scanbus than 
> to explain how to make rules for udev.

> HAL is the right answer,

Nice that we agree on that.

> but *in* the kernel, where it will track changes.

Oh, and BSDs and other target systems of interest for higher-level
libraries and applications don't need libhal? What do we gain by pushing
more and more functionality down the stack right into the kernel,
without guaranteeing ABI/API stability? HAL was developed with
portability in mind, why should one give it up for solving hypothetical
problems, depending on release cycles and patch review by external
projects? I thought the original plan was rather to break the kernel
down and not to make it a melting pot for all kinds of specialized
functionality, which to my impression was originally done because of the
lack of vendor support.

> Since -scanbus tells you a 
> device is a CDrecorder, or something else, *any user* is likely to be 
> able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices...

Well, "any user" just opens his Windows Explorer and takes a look at the
icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
interesting to see professional programmers often argue that a
particular solution they like is appropriate for all users without
giving proof. I can't think of a single reason why a user wants to dump
all his devices without knowing the grep semantics, which in turn makes
it very likely that he will write some wrapper code around any of the
currently perfectly working solutions.

-- 
Christian Neumair <chris@gnome-de.org>

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Christian Neumair <chris@gnome-de.org> wrote:

> Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen:
> > The kernel could provide a list of devices by category. It doesn't have 
> > to name them, run scripts, give descriptions, or paint them blue. Just a 
> > list of all block devices, tapes, by major/minor and category (ie. 
> > block, optical, floppy) would give the application layer a chance to do 
> > it's own interpretation.
>
> Introducing more than interface for doing the same thing can be very
> confusing and counter-productive. You'll create new, undocumented or
> semi-documented interfaces which will lead to a dependency chaos.

So you concur with me that the fact that Linux introduced another interface
for SCSI was onfusing and counter-productive.


> Some random script will work with kernel 2.6.11, 2.6.12 and 2.6.13, but
> not 2.6.14 and later because a new device class was introduced and two
> typos were fixed. Especially considering that the new linux development
> model makes it likely that major changes go into micro releases,
> stability and reliability will be a huge problem.

The main problem is that there is no grant that a new model will survive
a time frame that makes sense to implement support.

> > Since -scanbus tells you a 
> > device is a CDrecorder, or something else, *any user* is likely to be 
> > able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices...
>
> Well, "any user" just opens his Windows Explorer and takes a look at the
> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> interesting to see professional programmers often argue that a

This is not true: a drive letter mapping does not need to exist on MS-WIN
in order to be able to access it via ASPI or SPTI.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello!

> The main problem is that there is no grant that a new model will survive
> a time frame that makes sense to implement support.

I bet that it would take less time to implement this support than what
you spend here by arguing and trying to prove you are the only sane
person in the world. Unsuccessfully, of course.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"#define QUESTION ((bb) || !(bb))"  -- Shakespeare

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> Hello!
>
> > The main problem is that there is no grant that a new model will survive
> > a time frame that makes sense to implement support.
>
> I bet that it would take less time to implement this support than what
> you spend here by arguing and trying to prove you are the only sane
> person in the world. Unsuccessfully, of course.

If memory serves me correctly, the current model is the 3rd incompatible one
offerend within less than 5 years.

If you did ever try to write reliable code that has to deal with this kind of
oddities, you would understand that it is sometimes better to wait and to inform
related people about the problems they caused.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

Joerg Schilling wrote:

>Martin Mares <mj@ucw.cz> wrote:
>
>  
>
>>Hello!
>>
>>    
>>
>>>The main problem is that there is no grant that a new model will survive
>>>a time frame that makes sense to implement support.
>>>      
>>>
>>I bet that it would take less time to implement this support than what
>>you spend here by arguing and trying to prove you are the only sane
>>person in the world. Unsuccessfully, of course.
>>    
>>
>
>If memory serves me correctly, the current model is the 3rd incompatible one
>offerend within less than 5 years.
>  
>
With that I agree. Not only does the interface change, the details 
within a given interface must change.

>If you did ever try to write reliable code that has to deal with this kind of
>oddities, you would understand that it is sometimes better to wait and to inform
>related people about the problems they caused.
>  
>
This ground has been covered. And at least in the case of filtering 
commands, that had to be done quickly and you know it.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Saturday 18 February 2006 08:47, Bill Davidsen wrote:
> Joerg Schilling wrote:
> >Martin Mares <mj@ucw.cz> wrote:
> >>Hello!
> >>
> >>>The main problem is that there is no grant that a new model will survive
> >>>a time frame that makes sense to implement support.
> >>
> >>I bet that it would take less time to implement this support than what
> >>you spend here by arguing and trying to prove you are the only sane
> >>person in the world. Unsuccessfully, of course.
> >
> >If memory serves me correctly, the current model is the 3rd incompatible
> > one offerend within less than 5 years.
>
> With that I agree. Not only does the interface change, the details
> within a given interface must change.


At this point I seem to have stumbled across a document that has what Joerg 
might be looking for Linux to introduce. It's available at t10.org and is a 
translation layer specification for OS's to use if they want to access ATA 
devices like SCSI ones.

Seems to me this wouldn't be a good or bad thing to add to the kernel. The 
problem is that introducing the layer and thereby unifying the SCSI and ATA 
busses into one namespace is a big task. I know I couldn't manage it, and 
don't think there are any people willing to take it on.

Introducing it would provide a standard interface, however.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

On Sat, 18 Feb 2006, D. Hazelton wrote:

> At this point I seem to have stumbled across a document that has what Joerg 
> might be looking for Linux to introduce. It's available at t10.org and is a 
> translation layer specification for OS's to use if they want to access ATA 
> devices like SCSI ones.

Is that something other than CAM? If so, please mention the exact
document name.

> Seems to me this wouldn't be a good or bad thing to add to the kernel. The 

Well, such an integration must avoid:

- breaking existing conformant applications, where conformant here would
  apply to existing interface documentation such as the SCSI General
  Programming HOWTO from torque.net.

  This means that int fd = open("/dev/foo", O_RDWR, 0);
                  int e = ioctl(fd, SG_IO, &cmd_block);
  needs to remain functional.

- duplicating code which would cause immediate bit-rot...

> problem is that introducing the layer and thereby unifying the SCSI and ATA 
> busses into one namespace is a big task.

...so it could really only be an interface layer on top of existing
interfaces to avoid that. (Any other opinions?)

And then that interface would only be sensible if it actually improves
the situation, for instance, if applications gain source-level
compatibility with NetBSD or FreeBSD.

I think libata's integration of parallel ATA is already going a way that
leads to unifiying all the layers. For disks, the sd driver is used with
libata. I'd be surprised if it wouldn't work for CD/DVD drives, too, at
least in the long run.

Part of the problem is Jörg's expecting a solution the day before yesterday.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Sunday 19 February 2006 04:20, Matthias Andree wrote:
> On Sat, 18 Feb 2006, D. Hazelton wrote:
> > At this point I seem to have stumbled across a document that has what
> > Joerg might be looking for Linux to introduce. It's available at t10.org
> > and is a translation layer specification for OS's to use if they want to
> > access ATA devices like SCSI ones.
>
> Is that something other than CAM? If so, please mention the exact
> document name.


The documents title is: "Information Technology - SCSI / ATA translation (SAT)

The revision I'm looking at is R08 - the most current I could find. I'll have 
to dig, but it doesn't appear to just be a rewrite of CAM from the quick once 
over I gave it.

> > Seems to me this wouldn't be a good or bad thing to add to the kernel.
> > The
>
> Well, such an integration must avoid:
>
> - breaking existing conformant applications, where conformant here would
>   apply to existing interface documentation such as the SCSI General
>   Programming HOWTO from torque.net.
>
>   This means that int fd = open("/dev/foo", O_RDWR, 0);
>                   int e = ioctl(fd, SG_IO, &cmd_block);
>   needs to remain functional.
>
> - duplicating code which would cause immediate bit-rot...

Yes, true. After all Linus has said that there is to be no more breaking of 
userspace interfaces. In this case I think what the layer would do is allow 
the people that want to to use /dev/sg* to access all SCSI and ATA devices on 
a given system.

It's purpose, from the blurb on t10.org, is to provide a SCSI interface to ATA 
disks for people that want to access them that way.

> > problem is that introducing the layer and thereby unifying the SCSI and
> > ATA busses into one namespace is a big task.
>
> ...so it could really only be an interface layer on top of existing
> interfaces to avoid that. (Any other opinions?)
>

Right. Which is one reason why I did say that I thought it might be a good 
idea, but didn't think that anyone would bother. I also don't think it's 
really necessary. SG_IO happens to work great and the amount of work 
involved...

Anyway, to me it seems like it'd just be resurrecting a deprecated module and 
expanding it so it has a wider scope. Only real difference would be that it 
wouldn't take devices from their driver, just provide a second interface to 
it - which also means that all the ATA drivers would need to have hooks that 
it could call into. (Or am I over thinking it here?)

> And then that interface would only be sensible if it actually improves
> the situation, for instance, if applications gain source-level
> compatibility with NetBSD or FreeBSD.

Well, FreeBSD implements CAM, so if someone implemented CAM that'd provide 
source-level compatability. In this case what it would do is hard to say - 
the only thing I can think it _might_ do is quiet a couple of people down a 
bit.

> I think libata's integration of parallel ATA is already going a way that
> leads to unifiying all the layers. For disks, the sd driver is used with
> libata. I'd be surprised if it wouldn't work for CD/DVD drives, too, at
> least in the long run.

Ah, yes. I was under the impression that libata only handled PATA and SATA - 
is it going to be expanded to encompass the entire ATA bus?

> Part of the problem is Jörg's expecting a solution the day before
> yesterday.

Well, from some comments he made in private mails he seems to think he was 
promised (by Linus, no less) that the DMA problems in ide-scsi were going to 
be fixed. Instead the module was deprecated and SG_IO was introduced - this 
seems to be one of the things he's been angry about.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > Part of the problem is Jörg's expecting a solution the day before
> > yesterday.
>
> Well, from some comments he made in private mails he seems to think he was 
> promised (by Linus, no less) that the DMA problems in ide-scsi were going to 
> be fixed. Instead the module was deprecated and SG_IO was introduced - this 
> seems to be one of the things he's been angry about.

Even you have become a victim of the trolls :-(

SG_IO was used in ide-scsi a long time before it was needlessly introduced 
on top of /dev/hd*

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Monday 20 February 2006 11:41, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > Part of the problem is Jörg's expecting a solution the day before
> > > yesterday.
> >
> > Well, from some comments he made in private mails he seems to think he
> > was promised (by Linus, no less) that the DMA problems in ide-scsi were
> > going to be fixed. Instead the module was deprecated and SG_IO was
> > introduced - this seems to be one of the things he's been angry about.
>
> Even you have become a victim of the trolls :-(

Never a victim. I stick my nose where I choose - in this case I stuck it in 
here because I had hoped to turn a discussion I saw descending into a 
flamewar into something productive.

> SG_IO was used in ide-scsi a long time before it was needlessly introduced
> on top of /dev/hd*

Needlessly? Not true. It was missing from the layer, as all modern ATA devices 
do support some form of ATAPI, which is, as you've so frequently pointed out, 
a form of SCSI. So why is an unneeded thing to introduce the ability to use 
that full capacity?

And here I must parrot Martin Mares - you complain about problems when not 
using ide-scsi but almost all the bugs you've mentioned only occur when using 
ide-scsi. Now, I'll go and finish replying to all the other mails that have 
come into my inbox (on this thread) and not been sorted down because they 
were directly to me.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > SG_IO was used in ide-scsi a long time before it was needlessly introduced
> > on top of /dev/hd*
>
> Needlessly? Not true. It was missing from the layer, as all modern ATA devices 
> do support some form of ATAPI, which is, as you've so frequently pointed out, 
> a form of SCSI. So why is an unneeded thing to introduce the ability to use 
> that full capacity?

There used to be generic support, so this way of support is unneeded.

The fact that people did make ide-scsi (the generic way) impossible to use
is a bug that needs to be fixed.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-21:

> There used to be generic support, so this way of support is unneeded.

It is not your business to decide what is unneeded in Linux and what
isn't, and CD writing (still the Subject line!) doesn't require
ide-scsi. Evidently the additional SG_IO support in ide-cd doesn't break
your applications.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

Joerg, I've been thinking about your report about Linux munging CDB's sent to 
certian ATAPI devices. While reading the MMC-5 spec again today (my memory of 
it was starting to fail and I felt I had best be on top of it in this 
discussion) a statement made about sending SCSI commands to ATAPI devices 
caught me.

ATAPI command packets are fixed at a 12 byte size. Is it possible you tried to 
send a CDB in excess of that fixed size re: those drives that get a munged 
CDB?

Just a thought...

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> Joerg, I've been thinking about your report about Linux munging CDB's sent to 
> certian ATAPI devices. While reading the MMC-5 spec again today (my memory of 
> it was starting to fail and I felt I had best be on top of it in this 
> discussion) a statement made about sending SCSI commands to ATAPI devices 
> caught me.
>
> ATAPI command packets are fixed at a 12 byte size. Is it possible you tried to 
> send a CDB in excess of that fixed size re: those drives that get a munged 
> CDB?

I did write some time ago that the most probable cause for the Linux bug is that
Linux is sending uninitialized data for the amount of bytes that pad to 12 byte.

Libscg is the first application ever, that always correctly deals with CDB size
as it started to do so in August 1986 which is before any other SCSI generic 
transport has been available.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Christian Neumair]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

Am Dienstag, den 21.02.2006, 11:36 +0100 schrieb Joerg Schilling:
> I did write some time ago that the most probable cause for the Linux
> bug is that
> Linux is sending uninitialized data for the amount of bytes that pad
> to 12 byte.

How are they supposed to be filled? I don't have a clue on the low-level
stuff involved, but isn't this as simple as initializing the rest of the
c array in idescsi_pc_t to 0?

-- 
Christian Neumair <chris@gnome-de.org>

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Christian Neumair <chris@gnome-de.org> wrote:

> Am Dienstag, den 21.02.2006, 11:36 +0100 schrieb Joerg Schilling:
> > I did write some time ago that the most probable cause for the Linux
> > bug is that
> > Linux is sending uninitialized data for the amount of bytes that pad
> > to 12 byte.
>
> How are they supposed to be filled? I don't have a clue on the low-level
> stuff involved, but isn't this as simple as initializing the rest of the
> c array in idescsi_pc_t to 0?

They are supposed to be filled with null chars.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Bill Davidsen <davidsen@tmr.com> wrote:

> >If you did ever try to write reliable code that has to deal with this kind of
> >oddities, you would understand that it is sometimes better to wait and to inform
> >related people about the problems they caused.
> >  
> >
> This ground has been covered. And at least in the case of filtering 
> commands, that had to be done quickly and you know it.

We all know that filtering is not needeed to fix a bug. It could have been
implemented completely relaxed and without any time pressure as the bug
that needed fixing could have been fixed by just requiring a R/W FD to allow
SG_IO. 

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Monday 20 February 2006 11:05, Joerg Schilling wrote:
> Bill Davidsen <davidsen@tmr.com> wrote:
> > >If you did ever try to write reliable code that has to deal with this
> > > kind of oddities, you would understand that it is sometimes better to
> > > wait and to inform related people about the problems they caused.
> >
> > This ground has been covered. And at least in the case of filtering
> > commands, that had to be done quickly and you know it.
>
> We all know that filtering is not needeed to fix a bug. It could have been
> implemented completely relaxed and without any time pressure as the bug
> that needed fixing could have been fixed by just requiring a R/W FD to
> allow SG_IO.

In one post you complain that SG_IO is unneeded on /dev/hd* and related 
devices and in this one you say that it's all that would have been needed to 
fix a bug!

Joerg, I think it's time you stop dodging questions, shifting blame and all 
the tactics you've been using and admit that you just don't like Linux. After 
all, every time you are asked to provide a technical basis for an argument 
you have three main tactics - Dodge it entirely, misquote POSIX or say "But 
Solaris does it this way".

As you well know I've asked you for quality information I could use to try and 
fix the bug in the kernel where it munges the CDB for certain drives and am 
trying to work with you to develop a patch that will let libscg scan both the 
SCSI and ATA/ATAPI bus on Linux. I realize I'm an unknown factor here, since 
I've never found any place where my skills would come in useful on a major 
project like cdrecord or Linux, but now I have.

If you do not want the help just say such. If you just want to complain about 
problems and preach about how great Solaris is, then you are nothing but a 
feigen schweinhund and deserve to receive no more of my time.

(and yes, my German is probably quite bad. It's been a very long time since 
I've used any of it on a regular basis)

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]

On Mon, 2006-02-20 at 13:53 -0500, D. Hazelton wrote:
> On Monday 20 February 2006 11:05, Joerg Schilling wrote:
> > Bill Davidsen <davidsen@tmr.com> wrote:
> > > >If you did ever try to write reliable code that has to deal with this
> > > > kind of oddities, you would understand that it is sometimes better to
> > > > wait and to inform related people about the problems they caused.
> > >
> > > This ground has been covered. And at least in the case of filtering
> > > commands, that had to be done quickly and you know it.
> >
> > We all know that filtering is not needeed to fix a bug. It could have been
> > implemented completely relaxed and without any time pressure as the bug
> > that needed fixing could have been fixed by just requiring a R/W FD to
> > allow SG_IO.
> 

Pretty sure it was not to fix a bug, but to plug a possible security
issue with non-root users being able to do whatever they wanted on a R/W
FD.

> In one post you complain that SG_IO is unneeded on /dev/hd* and related 
> devices and in this one you say that it's all that would have been needed to 
> fix a bug!
> 
> Joerg, I think it's time you stop dodging questions, shifting blame and all 
> the tactics you've been using and admit that you just don't like Linux. After 
> all, every time you are asked to provide a technical basis for an argument 
> you have three main tactics - Dodge it entirely, misquote POSIX or say "But 
> Solaris does it this way".
> 
> As you well know I've asked you for quality information I could use to try and 
> fix the bug in the kernel where it munges the CDB for certain drives and am 
> trying to work with you to develop a patch that will let libscg scan both the 
> SCSI and ATA/ATAPI bus on Linux. I realize I'm an unknown factor here, since 
> I've never found any place where my skills would come in useful on a major 
> project like cdrecord or Linux, but now I have.
> 
> If you do not want the help just say such. If you just want to complain about 
> problems and preach about how great Solaris is, then you are nothing but a 
> feigen schweinhund and deserve to receive no more of my time.
> 
> (and yes, my German is probably quite bad. It's been a very long time since 
> I've used any of it on a regular basis)
> 

No need to waste your time .. he did not want it to work properly on
Linux for years now, and the only reason Linux support have not been
removed yet, is because then it will break his 'O so wonderful and only
proper "schily" way for "protability to more plaforms than you get from
using an GNU autoconf the way the GNU people tell you"'.  Oh, and then
he looses his favourite "plaform" to rant about.

PS: quoted spelling mistakes are not a pun, its just to make sure I do
not get accused of being a liar ...


Still Amused,

-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jens Axboe]

On Mon, Feb 20 2006, D. Hazelton wrote:
> On Monday 20 February 2006 11:05, Joerg Schilling wrote:
> > Bill Davidsen <davidsen@tmr.com> wrote:
> > > >If you did ever try to write reliable code that has to deal with this
> > > > kind of oddities, you would understand that it is sometimes better to
> > > > wait and to inform related people about the problems they caused.
> > >
> > > This ground has been covered. And at least in the case of filtering
> > > commands, that had to be done quickly and you know it.
> >
> > We all know that filtering is not needeed to fix a bug. It could have been
> > implemented completely relaxed and without any time pressure as the bug
> > that needed fixing could have been fixed by just requiring a R/W FD to
> > allow SG_IO.
> 
> In one post you complain that SG_IO is unneeded on /dev/hd* and related 
> devices and in this one you say that it's all that would have been needed to 
> fix a bug!
> 
> Joerg, I think it's time you stop dodging questions, shifting blame and all 
> the tactics you've been using and admit that you just don't like Linux. After 
> all, every time you are asked to provide a technical basis for an argument 
> you have three main tactics - Dodge it entirely, misquote POSIX or say "But 
> Solaris does it this way".

Please stop CC'ing me on this pointless thread! Dunno who put me back,
but I have absolutely ZERO interesting in reading any of it anymore. I'd
rather get a root canal while listening to Michael Bolton and getting my
right leg sawed off.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> Joerg, I think it's time you stop dodging questions, shifting blame and all 
> the tactics you've been using and admit that you just don't like Linux. After 
> all, every time you are asked to provide a technical basis for an argument 
> you have three main tactics - Dodge it entirely, misquote POSIX or say "But 
> Solaris does it this way".

I did provide the details, but it is obvious that you need some basic knowledge
in order to contribute useful work.

You did look different than the trolls on this list, but now it seemd that
you also start parroting the FUD from the trolls on this list.
Note that this discussion did take many hours and it may be that it is more 
efficient for me to immediately stop replying because ther is no hope that this
discussion would result in any result that is worh the effort.


> As you well know I've asked you for quality information I could use to try and 
> fix the bug in the kernel where it munges the CDB for certain drives and am 
> trying to work with you to develop a patch that will let libscg scan both the 
> SCSI and ATA/ATAPI bus on Linux. I realize I'm an unknown factor here, since 
> I've never found any place where my skills would come in useful on a major 
> project like cdrecord or Linux, but now I have.

Sorry, I will not fix code that is maintained by people who have mo clean and 
forseable rules for integration. This discussion has become a waste of time
and any time I spend working on Linux is definitely a waste of time as long 
as decisions are comming from the belly instead of the head.

Write down a constitution for Linux, create clean rules, start making is 
possible to have useful discussions on LKML and it may become different. 
For now, Linux is scaring off people who know what they are doing.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jens Axboe]

On Tue, Feb 21 2006, Joerg Schilling wrote:
> Write down a constitution for Linux, create clean rules, start making is 
> possible to have useful discussions on LKML and it may become different. 
> For now, Linux is scaring off people who know what they are doing.

Everyone else has fruitful discussion on lkml, except you. Clearly the
problem is with lkml and the people there, not you.

Now either stop writing here or at least stop cc'ing me like I asked you
to.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest)

[jerome lacoste]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
[...]
> > > Since -scanbus tells you a
> > > device is a CDrecorder, or something else, *any user* is likely to be
> > > able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices...
> >
> > Well, "any user" just opens his Windows Explorer and takes a look at the
> > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> > interesting to see professional programmers often argue that a
>
> This is not true: a drive letter mapping does not need to exist on MS-WIN
> in order to be able to access it via ASPI or SPTI.

But from a user perspective, how one is supposed to identify between 2
identical burners named D: and E: on their system if cdrecord only
provides b,t,l naming and "b,t,l to cd burner name" mapping?

The "OS specific to b,t,l" mapping is clearly lacking although
cdrecord knows it there as well. Cf. scsi-wnt.c:

#ifdef _DEBUG_SCSIPT
        js_fprintf(scgp_errfile,  "SPTI: Adding drive %c: (%d:%d:%d)\n", 'A'+i,
                                        pDrive->ha, pDrive->tgt, pDrive->lun);
#endif

Jerome

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

jerome lacoste <jerome.lacoste@gmail.com> wrote:

> On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> [...]
> > > > Since -scanbus tells you a
> > > > device is a CDrecorder, or something else, *any user* is likely to be
> > > > able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices...
> > >
> > > Well, "any user" just opens his Windows Explorer and takes a look at the
> > > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> > > interesting to see professional programmers often argue that a
> >
> > This is not true: a drive letter mapping does not need to exist on MS-WIN
> > in order to be able to access it via ASPI or SPTI.
>
> But from a user perspective, how one is supposed to identify between 2
> identical burners named D: and E: on their system if cdrecord only
> provides b,t,l naming and "b,t,l to cd burner name" mapping?

Drive letters do not have real relevence from a OS view if talking about MS-WIN

> The "OS specific to b,t,l" mapping is clearly lacking although
> cdrecord knows it there as well. Cf. scsi-wnt.c:
>
> #ifdef _DEBUG_SCSIPT
>         js_fprintf(scgp_errfile,  "SPTI: Adding drive %c: (%d:%d:%d)\n", 'A'+i,
>                                         pDrive->ha, pDrive->tgt, pDrive->lun);
> #endif

The is no mapping, libscg just let's the user use the addressing used inside 
the MS-WIN kernel.

The drive letter related code was contributed by a russion guy who did
try to find a way to lock a drive in use by cdrecord, preventing 
automount/autoexec. This is unfortunately a bit brain-dead and caused by 
MS-WIN oddities.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[jerome lacoste]

On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> jerome lacoste <jerome.lacoste@gmail.com> wrote:
>
> > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > [...]
> > > > > Since -scanbus tells you a
> > > > > device is a CDrecorder, or something else, *any user* is likely to be
> > > > > able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices...
> > > >
> > > > Well, "any user" just opens his Windows Explorer and takes a look at the
> > > > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> > > > interesting to see professional programmers often argue that a
> > >
> > > This is not true: a drive letter mapping does not need to exist on MS-WIN
> > > in order to be able to access it via ASPI or SPTI.
> >
> > But from a user perspective, how one is supposed to identify between 2
> > identical burners named D: and E: on their system if cdrecord only
> > provides b,t,l naming and "b,t,l to cd burner name" mapping?
>
> Drive letters do not have real relevence from a OS view if talking about MS-WIN

Most complaints about cdrecord are to try to make it fit with the user
perspective, not the OS one.
Mostly nobody complain about the results of cdrecord job (otherwise it
would have been rewritten). People just complain on its command line
interface.


> > The "OS specific to b,t,l" mapping is clearly lacking although
> > cdrecord knows it there as well. Cf. scsi-wnt.c:
> >
> > #ifdef _DEBUG_SCSIPT
> >         js_fprintf(scgp_errfile,  "SPTI: Adding drive %c: (%d:%d:%d)\n", 'A'+i,
> >                                         pDrive->ha, pDrive->tgt, pDrive->lun);
> > #endif
>
> The is no mapping,

Maybe we disagree on the word "mapping".
Didn't this code print out the mapping between a drive letter and a
b,t,l number ?

> libscg just let's the user use the addressing used inside
> the MS-WIN kernel.
>
> The drive letter related code was contributed by a russion guy who did
> try to find a way to lock a drive in use by cdrecord, preventing
> automount/autoexec. This is unfortunately a bit brain-dead and caused by
> MS-WIN oddities.

Quote from scsi-wnt.c where I took the code extract from:

/*
 * Initialization of SCSI Pass Through Interface code.  Responsible for
 * setting up the array of SCSI devices.  This code will be a little
 * different from the normal code -- it will query each drive letter from
 * C: through Z: to see if it is  a CD.  When we identify a CD, we then
 * send CDB with the INQUIRY command to it -- NT will automagically fill in
 * the PathId, TargetId, and Lun for us.
 */

The code I am pointing at just maps the various OS specific drives to
SCSI b,t,l, like it is done on Linux.

This mapping is done in every single scsi-*.c file I had a look at.

E.g. openserver:

	if (scgp->debug > 0) {
		for (l = 0; l < nlm; l++)
		js_fprintf((FILE *)scgp->errfile,
			"%-4s = %5s(%d,%d,%d,%d) -> %s\n",
			cmtbl[l].typ,
			cmtbl[l].drv,
			cmtbl[l].hba,
			cmtbl[l].bus,
			cmtbl[l].tgt,
			cmtbl[l].lun,
			cmtbl[l].dev);
		js_fprintf((FILE *)scgp->errfile, "-------------------- \n");
	}

So can you make this 'mapping' available to wrapper applications in a
parsable format?

Jerome

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> Well, "any user" just opens his Windows Explorer and takes a look at the
>> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
>> interesting to see professional programmers often argue that a
>
>This is not true: a drive letter mapping does not need to exist on MS-WIN
>in order to be able to access it via ASPI or SPTI.
>
I have to support this view. Linux filesystems do not show up in Windows 
Explorer (because there's obviously an fs driver lacking), but there's 
always a way to damage your Linux from within Windows.



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Luke-Jr]

On Monday 13 February 2006 16:43, Jan Engelhardt wrote:
> >> Well, "any user" just opens his Windows Explorer and takes a look at the
> >> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> >> interesting to see professional programmers often argue that a
> >
> >This is not true: a drive letter mapping does not need to exist on MS-WIN
> >in order to be able to access it via ASPI or SPTI.
>
> I have to support this view. Linux filesystems do not show up in Windows
> Explorer (because there's obviously an fs driver lacking), but there's
> always a way to damage your Linux from within Windows.

Really? My Windows-using friend has all his Linux partitions fully visible and 
usable in Windows Explorer...

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> >> Well, "any user" just opens his Windows Explorer and takes a look at the
>> >> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
>> >> interesting to see professional programmers often argue that a
>> >
>> >This is not true: a drive letter mapping does not need to exist on MS-WIN
>> >in order to be able to access it via ASPI or SPTI.
>>
>> I have to support this view. Linux filesystems do not show up in Windows
>> Explorer (because there's obviously an fs driver lacking), but there's
>> always a way to damage your Linux from within Windows.
>
>Really? My Windows-using friend has all his Linux partitions fully visible and 
>usable in Windows Explorer...
>
Might depend! On DOS and Win98, there is no indication in either 
DOS or Explorer that there is a second harddisk (got an xfs on it) at all. 
Only partition entries with Win* type get a drive letter (which does not 
imply reading is also possible).
Might be different on your Windows.



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Monday 13 February 2006 08:24, Joerg Schilling wrote:
> Christian Neumair <chris@gnome-de.org> wrote:
> > Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen:
> > > The kernel could provide a list of devices by category. It doesn't have
> > > to name them, run scripts, give descriptions, or paint them blue. Just
> > > a list of all block devices, tapes, by major/minor and category (ie.
> > > block, optical, floppy) would give the application layer a chance to do
> > > it's own interpretation.
> >
> > Introducing more than interface for doing the same thing can be very
> > confusing and counter-productive. You'll create new, undocumented or
> > semi-documented interfaces which will lead to a dependency chaos.
>
> So you concur with me that the fact that Linux introduced another interface
> for SCSI was onfusing and counter-productive.

And look - ide-scsi is going away. So that "new" interface is disappearing.

<snip>
> > > Since -scanbus tells you a
> > > device is a CDrecorder, or something else, *any user* is likely to be
> > > able to tell it from DCD, CD-ROM, etc. Nice like of text for most
> > > devices...
> >
> > Well, "any user" just opens his Windows Explorer and takes a look at the
> > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
> > interesting to see professional programmers often argue that a
>
> This is not true: a drive letter mapping does not need to exist on MS-WIN
> in order to be able to access it via ASPI or SPTI.

And only true in those cases, although I have seen (thanks to necessity, not 
choice) that NT (and therefore Win32) does do btl mappings internally at 
least at boot. But if you claim that SPTI or ASPI is necessary to burn CD's 
on windows you are sadly mistaken. There are a number of programs which 
_might_ do ASPI internally, but never export the interface, so how does 
Windows use it? And with XP, again, thanks to necessity (making money in both 
cases) I can easily state that Windows does burning _internally_ without 
ASPI. (which I know doesn't exist because of complaints form WinAmp about the 
same)

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> On Monday 13 February 2006 08:24, Joerg Schilling wrote:
> > Christian Neumair <chris@gnome-de.org> wrote:
> > > Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen:
> > > > The kernel could provide a list of devices by category. It doesn't have
> > > > to name them, run scripts, give descriptions, or paint them blue. Just
> > > > a list of all block devices, tapes, by major/minor and category (ie.
> > > > block, optical, floppy) would give the application layer a chance to do
> > > > it's own interpretation.
> > >
> > > Introducing more than interface for doing the same thing can be very
> > > confusing and counter-productive. You'll create new, undocumented or
> > > semi-documented interfaces which will lead to a dependency chaos.
> >
> > So you concur with me that the fact that Linux introduced another interface
> > for SCSI was onfusing and counter-productive.
>
> And look - ide-scsi is going away. So that "new" interface is disappearing.

Try to find out what's new and what's old.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> 
> The kernel could provide a list of devices by category. It doesn't have 
> to name them, run scripts, give descriptions, or paint them blue. Just a 
> list of all block devices, tapes, by major/minor and category (ie. 
> block, optical, floppy) would give the application layer a chance to do 
> it's own interpretation.

It does so today in sysfs, that is what it is there for.

thanks,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Fri, Feb 10, 2006 at 03:56:54PM -0800, Greg KH wrote:
> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > 
> > The kernel could provide a list of devices by category. It doesn't have 
> > to name them, run scripts, give descriptions, or paint them blue. Just a 
> > list of all block devices, tapes, by major/minor and category (ie. 
> > block, optical, floppy) would give the application layer a chance to do 
> > it's own interpretation.
> 
> It does so today in sysfs, that is what it is there for.

Except it does not provide the path to the device nodes themselves.
You need to call udevinfo for that, or parse /dev/.udev/*.  Do you
think it would be possible to have hotplug/udev/whatever exists in the
future to give that information back in the kernel and have it appear
in sysfs?

  OG.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote:
> On Fri, Feb 10, 2006 at 03:56:54PM -0800, Greg KH wrote:
> > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > 
> > > The kernel could provide a list of devices by category. It doesn't have 
> > > to name them, run scripts, give descriptions, or paint them blue. Just a 
> > > list of all block devices, tapes, by major/minor and category (ie. 
> > > block, optical, floppy) would give the application layer a chance to do 
> > > it's own interpretation.
> > 
> > It does so today in sysfs, that is what it is there for.
> 
> Except it does not provide the path to the device nodes themselves.

That is not what Bill asked for.  So there is no "except" here :)

> You need to call udevinfo for that, or parse /dev/.udev/*.  Do you
> think it would be possible to have hotplug/udev/whatever exists in the
> future to give that information back in the kernel and have it appear
> in sysfs?

No.  Why would it when it is very simple to query udevinfo for that?

thanks,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote:
> On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote:
> > You need to call udevinfo for that, or parse /dev/.udev/*.  Do you
> > think it would be possible to have hotplug/udev/whatever exists in the
> > future to give that information back in the kernel and have it appear
> > in sysfs?
> 
> No.  Why would it when it is very simple to query udevinfo for that?

In order not to depend on a userland package for the kernel service of
device enumeration?  It's udevinfo now, what will it be in two years?

  OG.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Krzysztof Halasa]

Olivier Galibert <galibert@pobox.com> writes:

>> No.  Why would it when it is very simple to query udevinfo for that?
>
> In order not to depend on a userland package for the kernel service of
> device enumeration?  It's udevinfo now, what will it be in two years?

Come on, kernel does not need that info at all. In fact, cdrecord
doesn't need it either. Some frontends, maybe, though hal may be
better source if running.

In fact udev isn't mandatory either. We have it because it's handy,
it saves us from megatons of /dev files and keeps /dev/black-dvd in
sync with black dvd.

Personally I think the whole "cdrecord -scanbus" is bogus - command
line utils should do what they are asked to do (e.g., write to
/dev/hda1 or /dev/microcode if so requested).
-- 
Krzysztof Halasa

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Sun, Feb 12, 2006 at 10:14:06PM +0100, Olivier Galibert wrote:
> On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote:
> > On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote:
> > > You need to call udevinfo for that, or parse /dev/.udev/*.  Do you
> > > think it would be possible to have hotplug/udev/whatever exists in the
> > > future to give that information back in the kernel and have it appear
> > > in sysfs?
> > 
> > No.  Why would it when it is very simple to query udevinfo for that?
> 
> In order not to depend on a userland package for the kernel service of
> device enumeration?  It's udevinfo now, what will it be in two years?

WTF?  You are depending on that same program to create your device
nodes.  If you don't want to use that program to do it, then use
something else, or use a static device tree, which works like always.

sysfs exports everything that userspace needs to know, if it wants to
create a device node to talk to that specific device.  udev used it to
create your /dev tree, while other programs use it to create temporary
device nodes to do other things to your devices.  Either way, the kernel
doesn't know, or care what you call those device nodes.

thanks,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Sun, Feb 12, 2006 at 10:24:12PM -0800, Greg KH wrote:
> On Sun, Feb 12, 2006 at 10:14:06PM +0100, Olivier Galibert wrote:
> > On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote:
> > > On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote:
> > > > You need to call udevinfo for that, or parse /dev/.udev/*.  Do you
> > > > think it would be possible to have hotplug/udev/whatever exists in the
> > > > future to give that information back in the kernel and have it appear
> > > > in sysfs?
> > > 
> > > No.  Why would it when it is very simple to query udevinfo for that?
> > 
> > In order not to depend on a userland package for the kernel service of
> > device enumeration?  It's udevinfo now, what will it be in two years?
> 
> WTF?  You are depending on that same program to create your device
> nodes.  If you don't want to use that program to do it, then use
> something else, or use a static device tree, which works like always.

Funnily enough, my, say, mp3 usb key sync system would like to run as
non-root and does not want to know or care about what program creates
the device nodes.  Too bad this otherwise beautiful and useful sysfs
is crippled by design.


> sysfs exports everything that userspace needs to know, if it wants to
> create a device node to talk to that specific device.  udev used it to
> create your /dev tree, while other programs use it to create temporary
> device nodes to do other things to your devices.  Either way, the kernel
> doesn't know, or care what you call those device nodes.

You mean root is mandatory to talk with devices, whatever they are?

  OG.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Mon, Feb 13, 2006 at 05:49:11PM +0100, Olivier Galibert wrote:
> On Sun, Feb 12, 2006 at 10:24:12PM -0800, Greg KH wrote:
> > On Sun, Feb 12, 2006 at 10:14:06PM +0100, Olivier Galibert wrote:
> > > On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote:
> > > > On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote:
> > > > > You need to call udevinfo for that, or parse /dev/.udev/*.  Do you
> > > > > think it would be possible to have hotplug/udev/whatever exists in the
> > > > > future to give that information back in the kernel and have it appear
> > > > > in sysfs?
> > > > 
> > > > No.  Why would it when it is very simple to query udevinfo for that?
> > > 
> > > In order not to depend on a userland package for the kernel service of
> > > device enumeration?  It's udevinfo now, what will it be in two years?
> > 
> > WTF?  You are depending on that same program to create your device
> > nodes.  If you don't want to use that program to do it, then use
> > something else, or use a static device tree, which works like always.
> 
> Funnily enough, my, say, mp3 usb key sync system would like to run as
> non-root and does not want to know or care about what program creates
> the device nodes.  Too bad this otherwise beautiful and useful sysfs
> is crippled by design.

Huh?  What sysfs design flaw is that?

You can run your mp3 usb ksy sync system as non-root just fine, I do
just that.  When my device is plugged in, a udev rule runs a script that
changes users and resyncs my device.

But that has nothing to do with sysfs at all.

> > sysfs exports everything that userspace needs to know, if it wants to
> > create a device node to talk to that specific device.  udev used it to
> > create your /dev tree, while other programs use it to create temporary
> > device nodes to do other things to your devices.  Either way, the kernel
> > doesn't know, or care what you call those device nodes.
> 
> You mean root is mandatory to talk with devices, whatever they are?

Not at all.  You only have to be root to create a device node, nothing
new there.

thanks,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Daniel Barkalow]

On Fri, 10 Feb 2006, Greg KH wrote:

> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > 
> > The kernel could provide a list of devices by category. It doesn't have 
> > to name them, run scripts, give descriptions, or paint them blue. Just a 
> > list of all block devices, tapes, by major/minor and category (ie. 
> > block, optical, floppy) would give the application layer a chance to do 
> > it's own interpretation.
> 
> It does so today in sysfs, that is what it is there for.

sysfs doesn't do quite that level of categorization; if it did, cdrom_id 
would be unnecessary. It would be nice if you could do 
"grep 1 /sys/block/*/burns_cds" and get a list of all the block devices in 
your system that burn cds. (You can currently get a list of all of the 
removable block devices in your system, but not much else.)

The kernel must know a bunch of this sort of stuff, and it would be nice 
if the information available. (In fact, there's a lot that's in /proc/ide 
that isn't in /sys, which is a bit annoying, since it would be useful in 
/sys, especially if it would mean that you could ignore details of what 
kind of bus things were on.)

	-Daniel

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote:
> On Fri, 10 Feb 2006, Greg KH wrote:
> 
> > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > 
> > > The kernel could provide a list of devices by category. It doesn't have 
> > > to name them, run scripts, give descriptions, or paint them blue. Just a 
> > > list of all block devices, tapes, by major/minor and category (ie. 
> > > block, optical, floppy) would give the application layer a chance to do 
> > > it's own interpretation.
> > 
> > It does so today in sysfs, that is what it is there for.
> 
> sysfs doesn't do quite that level of categorization; if it did, cdrom_id 
> would be unnecessary.

What?  cdrom_id queries the device directly to get some specific
information about the device, much like any other type of device query
(lspci, lsusb, etc.)

And yes, it would be nice if some of that information was also exported
through sysfs, and as always, patches are gladly accpeted.

> It would be nice if you could do 
> "grep 1 /sys/block/*/burns_cds" and get a list of all the block devices in 
> your system that burn cds. (You can currently get a list of all of the 
> removable block devices in your system, but not much else.)

Well, I can see if they are disks or cdroms through sysfs quite easily,
removable or not, so you do get more information than you expect.

> The kernel must know a bunch of this sort of stuff, and it would be nice 
> if the information available. (In fact, there's a lot that's in /proc/ide 
> that isn't in /sys, which is a bit annoying, since it would be useful in 
> /sys, especially if it would mean that you could ignore details of what 
> kind of bus things were on.)

I agree, again, feel free to submit patches.

thanks,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Daniel Barkalow]

On Sun, 12 Feb 2006, Greg KH wrote:

> On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote:
> > sysfs doesn't do quite that level of categorization; if it did, cdrom_id 
> > would be unnecessary.
> 
> What?  cdrom_id queries the device directly to get some specific
> information about the device, much like any other type of device query
> (lspci, lsusb, etc.)
> 
> And yes, it would be nice if some of that information was also exported
> through sysfs, and as always, patches are gladly accpeted.

Are there guidelines on having a generic cdrom export information from its 
block interface, rather than through its bus? I'm not finding any 
documentation of sys/block/, aside from that it exists.

> > It would be nice if you could do 
> > "grep 1 /sys/block/*/burns_cds" and get a list of all the block devices in 
> > your system that burn cds. (You can currently get a list of all of the 
> > removable block devices in your system, but not much else.)
> 
> Well, I can see if they are disks or cdroms through sysfs quite easily,
> removable or not, so you do get more information than you expect.

Ah, okay, this is in the current -rcs. I was only looking at 2.6.15 (and 
before), which is too old.

	-Daniel
*This .sig left intentionally blank*

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Mon, Feb 13, 2006 at 03:05:49AM -0500, Daniel Barkalow wrote:
> On Sun, 12 Feb 2006, Greg KH wrote:
> 
> > On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote:
> > > sysfs doesn't do quite that level of categorization; if it did, cdrom_id 
> > > would be unnecessary.
> > 
> > What?  cdrom_id queries the device directly to get some specific
> > information about the device, much like any other type of device query
> > (lspci, lsusb, etc.)
> > 
> > And yes, it would be nice if some of that information was also exported
> > through sysfs, and as always, patches are gladly accpeted.
> 
> Are there guidelines on having a generic cdrom export information from its 
> block interface, rather than through its bus? I'm not finding any 
> documentation of sys/block/, aside from that it exists.

That information should go into the device directory, not the sys/block
directory (as it referrs to the device attributes, not the block gendev
attributes.)

thanks,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Dmitry Torokhov]

On 2/13/06, Greg KH <greg@kroah.com> wrote:
> On Mon, Feb 13, 2006 at 03:05:49AM -0500, Daniel Barkalow wrote:
> > On Sun, 12 Feb 2006, Greg KH wrote:
> >
> > > On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote:
> > > > sysfs doesn't do quite that level of categorization; if it did, cdrom_id
> > > > would be unnecessary.
> > >
> > > What?  cdrom_id queries the device directly to get some specific
> > > information about the device, much like any other type of device query
> > > (lspci, lsusb, etc.)
> > >
> > > And yes, it would be nice if some of that information was also exported
> > > through sysfs, and as always, patches are gladly accpeted.
> >
> > Are there guidelines on having a generic cdrom export information from its
> > block interface, rather than through its bus? I'm not finding any
> > documentation of sys/block/, aside from that it exists.
>
> That information should go into the device directory, not the sys/block
> directory (as it referrs to the device attributes, not the block gendev
> attributes.)
>

Not necessarily - it would be easier for userspace programs if we had
a separate class in sysfs - /sys/class/cdrom. The problem with this
approach is that we do not allow a device belong o several classes
without introducing intermediate class devices (I mean a DVD+RW shoudl
probably belong to classes cdrom, dvdrom, cdwriter and dvdwriter).

--
Dmitry

Re: CD writing in future Linux (stirring up a hornets' nest)

[Daniel Barkalow]

On Mon, 13 Feb 2006, Dmitry Torokhov wrote:

> On 2/13/06, Greg KH <greg@kroah.com> wrote:
> > On Mon, Feb 13, 2006 at 03:05:49AM -0500, Daniel Barkalow wrote:
> > > Are there guidelines on having a generic cdrom export information from its
> > > block interface, rather than through its bus? I'm not finding any
> > > documentation of sys/block/, aside from that it exists.
> >
> > That information should go into the device directory, not the sys/block
> > directory (as it referrs to the device attributes, not the block gendev
> > attributes.)
> >
> 
> Not necessarily - it would be easier for userspace programs if we had
> a separate class in sysfs - /sys/class/cdrom. The problem with this
> approach is that we do not allow a device belong o several classes
> without introducing intermediate class devices (I mean a DVD+RW shoudl
> probably belong to classes cdrom, dvdrom, cdwriter and dvdwriter).

I don't think it needs to be a class, but I think that there should be a 
single place with a directory for each device that could be what you want, 
with a file that tells you if it is. That's why I was looking at block/; 
these things must be block devices, and there aren't an huge number of 
block devices.

I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I hadn't 
dug far enough in to realize that the reason I wasn't seeing anything 
informative in /sys/block/*/device/ was that I didn't have any devices 
with informative drivers, not that it was actually supposed to only have 
links to other things.

	-Daniel
*This .sig left intentionally blank*

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

Daniel Barkalow wrote:

> I don't think it needs to be a class, but I think that there should be a 
> single place with a directory for each device that could be what you want, 
> with a file that tells you if it is. That's why I was looking at block/; 
> these things must be block devices, and there aren't an huge number of 
> block devices.
> 
> I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I hadn't 
> dug far enough in to realize that the reason I wasn't seeing anything 
> informative in /sys/block/*/device/ was that I didn't have any devices 
> with informative drivers, not that it was actually supposed to only have 
> links to other things.

It would be nice to have one place to go to find burners, and to have 
the model information in that place. I would logically think that place 
is sysfs, and I know the kernel has the information because if I root 
through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can 
eventually find out what the system has connected.

I not entirely sure about having classes other than cdrom, just because 
we already have CD, DVD, DVD-DL, and are about to add blue-ray and 
HD-DVD, so if I can tell that it's a removable device which can read 
CDs, the applications have a fighting chance to looking at the device to 
see what it is. As a human I would like the model information because 
the kernel has done the work, why should people have to chase it when it 
could be in one place?

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Friday 17 February 2006 16:35, Bill Davidsen wrote:
> Daniel Barkalow wrote:
> > I don't think it needs to be a class, but I think that there should be a
> > single place with a directory for each device that could be what you
> > want, with a file that tells you if it is. That's why I was looking at
> > block/; these things must be block devices, and there aren't an huge
> > number of block devices.
> >
> > I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I
> > hadn't dug far enough in to realize that the reason I wasn't seeing
> > anything informative in /sys/block/*/device/ was that I didn't have any
> > devices with informative drivers, not that it was actually supposed to
> > only have links to other things.
>
> It would be nice to have one place to go to find burners, and to have
> the model information in that place. I would logically think that place
> is sysfs, and I know the kernel has the information because if I root
> through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can
> eventually find out what the system has connected.
>
> I not entirely sure about having classes other than cdrom, just because
> we already have CD, DVD, DVD-DL, and are about to add blue-ray and
> HD-DVD, so if I can tell that it's a removable device which can read
> CDs, the applications have a fighting chance to looking at the device to
> see what it is. As a human I would like the model information because
> the kernel has done the work, why should people have to chase it when it
> could be in one place?

The problem is that drives don't always cleanly report what they are in a 
simple to access format. All SCSI and ATAPI drives provide a model, 
manufacturer and serial number but usually the type of drive is buried within 
the Model field, and that has a lot of variations.

(I have personally seen CD/CDRW, CD-ROM, CD-RW, CDR, CDRW and DVD/CDROM)

Now what could be done is that said information could be exported to sysfs. 
Given the time I could probably manage the patch myself, but I'm currently 
overextended with the number of projects I have underway.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

D. Hazelton wrote:

>On Friday 17 February 2006 16:35, Bill Davidsen wrote:
>  
>
>>Daniel Barkalow wrote:
>>    
>>
>>>I don't think it needs to be a class, but I think that there should be a
>>>single place with a directory for each device that could be what you
>>>want, with a file that tells you if it is. That's why I was looking at
>>>block/; these things must be block devices, and there aren't an huge
>>>number of block devices.
>>>
>>>I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I
>>>hadn't dug far enough in to realize that the reason I wasn't seeing
>>>anything informative in /sys/block/*/device/ was that I didn't have any
>>>devices with informative drivers, not that it was actually supposed to
>>>only have links to other things.
>>>      
>>>
>>It would be nice to have one place to go to find burners, and to have
>>the model information in that place. I would logically think that place
>>is sysfs, and I know the kernel has the information because if I root
>>through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can
>>eventually find out what the system has connected.
>>
>>I not entirely sure about having classes other than cdrom, just because
>>we already have CD, DVD, DVD-DL, and are about to add blue-ray and
>>HD-DVD, so if I can tell that it's a removable device which can read
>>CDs, the applications have a fighting chance to looking at the device to
>>see what it is. As a human I would like the model information because
>>the kernel has done the work, why should people have to chase it when it
>>could be in one place?
>>    
>>
>
>The problem is that drives don't always cleanly report what they are in a 
>simple to access format. All SCSI and ATAPI drives provide a model, 
>manufacturer and serial number but usually the type of drive is buried within 
>the Model field, and that has a lot of variations.
>
>(I have personally seen CD/CDRW, CD-ROM, CD-RW, CDR, CDRW and DVD/CDROM)
>
>Now what could be done is that said information could be exported to sysfs. 
>Given the time I could probably manage the patch myself, but I'm currently 
>overextended with the number of projects I have underway.
>
I would think that the model, manufacturer and serial would be useful, 
and just the indication that the device was CD capable would be a huge 
gain. There are at least two more type of drive coming soon in the 25GB 
media race, so identification could legitimately be left to the 
application as long as all CD-like devices can easily be identified for 
examination.

Does that fit with your level of available time (and interest in 
resolving this issue)?

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Saturday 18 February 2006 11:56, Bill Davidsen wrote:
> D. Hazelton wrote:
> >On Friday 17 February 2006 16:35, Bill Davidsen wrote:
> >>Daniel Barkalow wrote:
> >>>I don't think it needs to be a class, but I think that there should be a
> >>>single place with a directory for each device that could be what you
> >>>want, with a file that tells you if it is. That's why I was looking at
> >>>block/; these things must be block devices, and there aren't an huge
> >>>number of block devices.
> >>>
> >>>I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I
> >>>hadn't dug far enough in to realize that the reason I wasn't seeing
> >>>anything informative in /sys/block/*/device/ was that I didn't have any
> >>>devices with informative drivers, not that it was actually supposed to
> >>>only have links to other things.
> >>
> >>It would be nice to have one place to go to find burners, and to have
> >>the model information in that place. I would logically think that place
> >>is sysfs, and I know the kernel has the information because if I root
> >>through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can
> >>eventually find out what the system has connected.
> >>
> >>I not entirely sure about having classes other than cdrom, just because
> >>we already have CD, DVD, DVD-DL, and are about to add blue-ray and
> >>HD-DVD, so if I can tell that it's a removable device which can read
> >>CDs, the applications have a fighting chance to looking at the device to
> >>see what it is. As a human I would like the model information because
> >>the kernel has done the work, why should people have to chase it when it
> >>could be in one place?
> >
> >The problem is that drives don't always cleanly report what they are in a
> >simple to access format. All SCSI and ATAPI drives provide a model,
> >manufacturer and serial number but usually the type of drive is buried
> > within the Model field, and that has a lot of variations.
> >
> >(I have personally seen CD/CDRW, CD-ROM, CD-RW, CDR, CDRW and DVD/CDROM)
> >
> >Now what could be done is that said information could be exported to
> > sysfs. Given the time I could probably manage the patch myself, but I'm
> > currently overextended with the number of projects I have underway.
>
> I would think that the model, manufacturer and serial would be useful,
> and just the indication that the device was CD capable would be a huge
> gain. There are at least two more type of drive coming soon in the 25GB
> media race, so identification could legitimately be left to the
> application as long as all CD-like devices can easily be identified for
> examination.
>
> Does that fit with your level of available time (and interest in
> resolving this issue)?

seems straightforward enough. May take me a bit, since I'll need to see what 
has to be done in order to make the information necessary, but I think it 
could all be resolved with calls to the routines the ioctl's normally access.

DRH

(and I think that theres even more information available, from the 
capabilities mode page, but I'm unsure as to how to access that)

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote:
> I not entirely sure about having classes other than cdrom, just because 
> we already have CD, DVD, DVD-DL, and are about to add blue-ray and 
> HD-DVD, so if I can tell that it's a removable device which can read 
> CDs, the applications have a fighting chance to looking at the device to 
> see what it is. As a human I would like the model information because 
> the kernel has done the work, why should people have to chase it when it 
> could be in one place?

Sure, I don't object to that at all, as long as you can detect this kind
of information easily from within the kernel.

thanks,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Christoph Hellwig]

On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote:
> It would be nice to have one place to go to find burners, and to have 
> the model information in that place.

/proc/sys/dev/cdrom/info

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Michlmayr]

* Christoph Hellwig <hch@infradead.org> [2006-02-18 12:06]:
> > It would be nice to have one place to go to find burners, and to have
> > the model information in that place.
> /proc/sys/dev/cdrom/info

Nice.  Is that a stable interface people can rely on (seems this me it
should rather be in sys)?  I maintain a tool in Debian to rip/encode
audio CDs with one command and we could use this file to find the CD
interface if it's not specified by the user.
-- 
Martin Michlmayr
tbm@cyrius.com

Re: CD writing in future Linux (stirring up a hornets' nest)

[Christoph Hellwig]

On Sat, Feb 18, 2006 at 01:37:15PM +0000, Martin Michlmayr wrote:
> * Christoph Hellwig <hch@infradead.org> [2006-02-18 12:06]:
> > > It would be nice to have one place to go to find burners, and to have
> > > the model information in that place.
> > /proc/sys/dev/cdrom/info
> 
> Nice.  Is that a stable interface people can rely on (seems this me it
> should rather be in sys)?  I maintain a tool in Debian to rip/encode
> audio CDs with one command and we could use this file to find the CD
> interface if it's not specified by the user.

I think it's pretty stable.  Except for adding new capabilities it's been
unchanged since the 2.2.x days.

Maybe Jens can comment more on it?

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jens Axboe]

On Sat, Feb 18 2006, Christoph Hellwig wrote:
> On Sat, Feb 18, 2006 at 01:37:15PM +0000, Martin Michlmayr wrote:
> > * Christoph Hellwig <hch@infradead.org> [2006-02-18 12:06]:
> > > > It would be nice to have one place to go to find burners, and to have
> > > > the model information in that place.
> > > /proc/sys/dev/cdrom/info
> > 
> > Nice.  Is that a stable interface people can rely on (seems this me it
> > should rather be in sys)?  I maintain a tool in Debian to rip/encode
> > audio CDs with one command and we could use this file to find the CD
> > interface if it's not specified by the user.
> 
> I think it's pretty stable.  Except for adding new capabilities it's been
> unchanged since the 2.2.x days.
> 
> Maybe Jens can comment more on it?

Yeah it's stable, new entries have been added at the end if necessary. I
don't necessarily think it's a super way to find these things out,
sometimes older SCSI drives fail some of the mode sense / capability
probing and don't show correct values. So one could do better in user
space.

But at least it's a generic way to see which devices have been
registered as CDROM's, if that is the goal.

-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest)

[Gene Heskett]

On Saturday 18 February 2006 07:06, Christoph Hellwig wrote:

cat /proc/sys/dev/cdrom/info
CD-ROM information, Id: cdrom.c 3.20 2003/12/17

drive name:             hdc
drive speed:            48
drive # of slots:       1
Can close tray:         1
Can open tray:          1
Can lock tray:          1
Can change speed:       1
Can select disk:        0
Can read multisession:  1
Can read MCN:           1
Reports media changed:  1
Can play audio:         1
Can write CD-R:         1
Can write CD-RW:        1
Can read DVD:           1
Can write DVD-R:        1
Can write DVD-RAM:      0
Can read MRW:           1
Can write MRW:          1
Can write RAM:          1

But I fail to see where this would help to 'find' the right device to 
write to, other than the obvious prefixing of '/dev/' to $drive name.  
We already knew that, and in fact it works very well. Please explain to 
Joerg in one syllable words he might, if he wanted to, understand.

Also, I'm fuzzy about the last 3, so defining those might help me 
understand.

-- 
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 writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Saturday 18 February 2006 12:15, Gene Heskett wrote:
> On Saturday 18 February 2006 07:06, Christoph Hellwig wrote:
>
> cat /proc/sys/dev/cdrom/info
> CD-ROM information, Id: cdrom.c 3.20 2003/12/17
>
> drive name:             hdc
> drive speed:            48
> drive # of slots:       1
> Can close tray:         1
> Can open tray:          1
> Can lock tray:          1
> Can change speed:       1
> Can select disk:        0
> Can read multisession:  1
> Can read MCN:           1
> Reports media changed:  1
> Can play audio:         1
> Can write CD-R:         1
> Can write CD-RW:        1
> Can read DVD:           1
> Can write DVD-R:        1
> Can write DVD-RAM:      0
> Can read MRW:           1
> Can write MRW:          1
> Can write RAM:          1

Ah, so it does already exist. Only thing left might be to stick the 
manufacturer, serial and misc. data into sysfs

> But I fail to see where this would help to 'find' the right device to
> write to, other than the obvious prefixing of '/dev/' to $drive name.
> We already knew that, and in fact it works very well. Please explain to
> Joerg in one syllable words he might, if he wanted to, understand.

Well, in this case I'm actually trying to work with Joerg to produce a patch 
that unifies the ATAPI and SCSI busses inside his program. One thing this 
does is help to locate available drives. Negates the need to scan the entire 
ATA/ATAPI bus for drives. However, since, as Joerg has pointed out, libscg is 
a generic SCSI system, it doesn't negate it's need to scan the entire SCSI 
bus. It's use as a backend to cdrecord is incidental in this case.

> Also, I'm fuzzy about the last 3, so defining those might help me
> understand.

I've seen the "MRW" stuff in some of the specs, but had to check the net to 
find out what it was. MRW is the Mt. Rainier format - basic support was added 
by Jens back in 2.4.19 according to the archives. 
(http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html)

I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM type 
discs

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Gene Heskett]

On Saturday 18 February 2006 19:41, D. Hazelton wrote:
>On Saturday 18 February 2006 12:15, Gene Heskett wrote:
>> On Saturday 18 February 2006 07:06, Christoph Hellwig wrote:
>>
>> cat /proc/sys/dev/cdrom/info
>> CD-ROM information, Id: cdrom.c 3.20 2003/12/17
>>
>> drive name:             hdc
>> drive speed:            48
>> drive # of slots:       1
>> Can close tray:         1
>> Can open tray:          1
>> Can lock tray:          1
>> Can change speed:       1
>> Can select disk:        0
>> Can read multisession:  1
>> Can read MCN:           1
>> Reports media changed:  1
>> Can play audio:         1
>> Can write CD-R:         1
>> Can write CD-RW:        1
>> Can read DVD:           1
>> Can write DVD-R:        1
>> Can write DVD-RAM:      0
>> Can read MRW:           1
>> Can write MRW:          1
>> Can write RAM:          1
>
>Ah, so it does already exist. Only thing left might be to stick the
>manufacturer, serial and misc. data into sysfs
>
>> But I fail to see where this would help to 'find' the right device
>> to write to, other than the obvious prefixing of '/dev/' to $drive
>> name. We already knew that, and in fact it works very well. Please
>> explain to Joerg in one syllable words he might, if he wanted to,
>> understand.
>
>Well, in this case I'm actually trying to work with Joerg to produce a
> patch that unifies the ATAPI and SCSI busses inside his program. One
> thing this does is help to locate available drives. Negates the need
> to scan the entire ATA/ATAPI bus for drives. However, since, as Joerg
> has pointed out, libscg is a generic SCSI system, it doesn't negate
> it's need to scan the entire SCSI bus. It's use as a backend to
> cdrecord is incidental in this case.

Working with Joerg?  sigh

>> Also, I'm fuzzy about the last 3, so defining those might help me
>> understand.
>
>I've seen the "MRW" stuff in some of the specs, but had to check the
> net to find out what it was. MRW is the Mt. Rainier format - basic
> support was added by Jens back in 2.4.19 according to the archives.
>(http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html)
>
>I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM
> type discs

That sounds like it makes sense, thanks.  I bought a spindle of 
rewritable dvd's, thinking about doing backups, but a 200GB drive and 
vtapes got in the way and its beaucoupe more convienient and speedy 
that the dvd's will ever be.  Once setup, it Just Works(TM).

That drive has since went belly up & been replaced with another that 
seems even more solid, liteon of course.

>DRH

Thanks

-- 
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 writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

On Sat, 18 Feb 2006, D. Hazelton wrote:

> Well, in this case I'm actually trying to work with Joerg to produce a patch 
> that unifies the ATAPI and SCSI busses inside his program.

This patch already exists, see:
<http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html>

It's a proof of concept and needs to be polished (I'll look into that
again in March).

Only it still probes all /dev/hd and /dev/sg and /dev/pg in a dumb way,
rather than looking at sysfs or reading through /dev/.

> I've seen the "MRW" stuff in some of the specs, but had to check the net to 
> find out what it was. MRW is the Mt. Rainier format - basic support was added 
> by Jens back in 2.4.19 according to the archives. 
> (http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html)
> 
> I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM type 
> discs

That's probably not it, since there's a separate DVD-RAM line here:

CD-ROM information, Id: cdrom.c 3.20 2003/12/17

drive name:             hdd     hdc     sr0
drive speed:            40      48      1
drive # of slots:       1       1       1
Can close tray:         1       1       1
Can open tray:          1       1       1
Can lock tray:          1       1       1
Can change speed:       1       1       0
Can select disk:        0       0       0
Can read multisession:  1       1       1
Can read MCN:           1       1       1
Reports media changed:  1       1       1
Can play audio:         1       1       1
Can write CD-R:         1       1       0
Can write CD-RW:        1       1       0
Can read DVD:           0       1       0
Can write DVD-R:        0       1       0
Can write DVD-RAM:      0       1       0
Can read MRW:           1       1       1
Can write MRW:          1       1       1
Can write RAM:          1       1       1

hdd = Plextor PX-W4824TA
hdc = NEC ND-4550A
sr0 = Plextor PX-32TS

(Now NEC only needs to teach their drives to be more error tolerant when
reading and adjust their read speed to the actual sustained transfer
rate as Toshiba drives have been doing for ages...)

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

Matthias Andree wrote:
> On Sat, 18 Feb 2006, D. Hazelton wrote:
> 
>> Well, in this case I'm actually trying to work with Joerg to produce a patch 
>> that unifies the ATAPI and SCSI busses inside his program.
> 
> This patch already exists, see:
> <http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html>
> 
> It's a proof of concept and needs to be polished (I'll look into that
> again in March).
> 
> Only it still probes all /dev/hd and /dev/sg and /dev/pg in a dumb way,
> rather than looking at sysfs or reading through /dev/.
> 
>> I've seen the "MRW" stuff in some of the specs, but had to check the net to 
>> find out what it was. MRW is the Mt. Rainier format - basic support was added 
>> by Jens back in 2.4.19 according to the archives. 
>> (http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html)
>>
>> I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM type 
>> discs
> 
> That's probably not it, since there's a separate DVD-RAM line here:
> 
> CD-ROM information, Id: cdrom.c 3.20 2003/12/17
> 
> drive name:             hdd     hdc     sr0
> drive speed:            40      48      1
> drive # of slots:       1       1       1
> Can close tray:         1       1       1
> Can open tray:          1       1       1
> Can lock tray:          1       1       1
> Can change speed:       1       1       0
> Can select disk:        0       0       0
> Can read multisession:  1       1       1
> Can read MCN:           1       1       1
> Reports media changed:  1       1       1
> Can play audio:         1       1       1
> Can write CD-R:         1       1       0
> Can write CD-RW:        1       1       0
> Can read DVD:           0       1       0
> Can write DVD-R:        0       1       0
> Can write DVD-RAM:      0       1       0
> Can read MRW:           1       1       1
> Can write MRW:          1       1       1
> Can write RAM:          1       1       1
> 
> hdd = Plextor PX-W4824TA
> hdc = NEC ND-4550A
> sr0 = Plextor PX-32TS

Other than my 2.6.15 not producing those last three lines, looks good.
The names are those in /sys, which of course many distros change in udev
to make things hard for the user. Hard t write an app portably to cope
with /dev/scd0, /dev/sr0, /dev/cdroms/sr0, etc.

I am NOT suggesting changing a stable interface, but this really should
be in /sys I would think. It would be nice to have the major/minor and
model info, so programs could find the "better" named in /dev or just
mknod their own.
> 
> (Now NEC only needs to teach their drives to be more error tolerant when
> reading and adjust their read speed to the actual sustained transfer
> rate as Toshiba drives have been doing for ages...)
> 

This would appear to be almost all the user needs to at least find the
devices. I don't know why no one mentioned it several years ago.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: CD writing in future Linux (stirring up a hornets' nest)

[Daniel Barkalow]

On Sat, 18 Feb 2006, Gene Heskett wrote:

> But I fail to see where this would help to 'find' the right device to 
> write to, other than the obvious prefixing of '/dev/' to $drive name.  
> We already knew that, and in fact it works very well. Please explain to 
> Joerg in one syllable words he might, if he wanted to, understand.

Honestly, the right thing for Joerg is /dev/cdrom or /dev/cdroms/*. The 
principle ought to be that something in userspace will talk to the kernel 
and produce a /dev structure containing names the user will recognize. 
(FWIW, /dev/cdrom has worked on every Linux machine I've had since my 
first system 10 years ago, but I've heard of people having multiple 
drives.)

Probably the right thing for getting the user to really know which thing 
is which is to have a configuration program that configures udev by 
listing all the devices that go through cdrom.c, giving some info about 
them, letting the user open the tray on them (to distinguish identical 
devices), and having the user give each a name, which then appears in 
/dev/cdroms (by reconfiguring udev). All of the detailed info from the 
kernel should go to the system configuration utility, not to cdrecord, 
which shouldn't need it, because either the default drive (/dev/cdrom) or 
the drive from /dev/cdroms that the user specifies will be right.

	-Daniel
*This .sig left intentionally blank*

Re: CD writing in future Linux (stirring up a hornets' nest)

[Chris Adams]

Once upon a time, Christoph Hellwig  <hch@infradead.org> said:
>On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote:
>> It would be nice to have one place to go to find burners, and to have 
>> the model information in that place.
>
>/proc/sys/dev/cdrom/info

Which is bad, as it is incomplete and requires the kernel be updated to
know about every format just to document them.

Problems with that file:

- What is "drive speed" (no units); also most drives do different speeds
  for different modes/media.

- CD-RW really covers a range of different formats ("high speed" CD-RW
  is different and IIRC there's also "ultra high speed" CD-RW).

- Several formats are missing: DVD-RW DVD+R DVD+RW DVD-DL DVD+DL (at
  least).

- What is the "RAM" format (not "DVD-RAM")?  I haven't heard of that.

The kernel really only needs to know:

- how the drive can control the tray (open/close/lock/change disc)

- if the drive can handle rewritable formats (for UDF support)

Alternately, every known format needs to be added to that file (both
read and write support).  It also needs to note read and write speeds
for each available format.

Also, that is an annoying to parse format.  What if there's a really
long text column field like "Can write Blu-Ray HD dual layer v2"?
Something under /sys would be better with one value per file, so if you
want to burn a DVD-R, you look for /sys/block/*/cdinfo/write/dvd-r;
maybe that file contains a space separated list of available speeds (so
"1 2 4 8").  Also, right now as far as I can see, /sys doesn't present
manufacturer, model, and/or serial number info.
-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Saturday 18 February 2006 13:36, Chris Adams wrote:
> Once upon a time, Christoph Hellwig  <hch@infradead.org> said:
> >On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote:
> >> It would be nice to have one place to go to find burners, and to have
> >> the model information in that place.
> >
> >/proc/sys/dev/cdrom/info
>
> Which is bad, as it is incomplete and requires the kernel be updated to
> know about every format just to document them.
>
> Problems with that file:
>
> - What is "drive speed" (no units); also most drives do different speeds
>   for different modes/media.
>
> - CD-RW really covers a range of different formats ("high speed" CD-RW
>   is different and IIRC there's also "ultra high speed" CD-RW).
>
> - Several formats are missing: DVD-RW DVD+R DVD+RW DVD-DL DVD+DL (at
>   least).
>
> - What is the "RAM" format (not "DVD-RAM")?  I haven't heard of that.
>
> The kernel really only needs to know:
>
> - how the drive can control the tray (open/close/lock/change disc)
>
> - if the drive can handle rewritable formats (for UDF support)
>
> Alternately, every known format needs to be added to that file (both
> read and write support).  It also needs to note read and write speeds
> for each available format.
>
> Also, that is an annoying to parse format.  What if there's a really
> long text column field like "Can write Blu-Ray HD dual layer v2"?
> Something under /sys would be better with one value per file, so if you
> want to burn a DVD-R, you look for /sys/block/*/cdinfo/write/dvd-r;
> maybe that file contains a space separated list of available speeds (so
> "1 2 4 8").  Also, right now as far as I can see, /sys doesn't present
> manufacturer, model, and/or serial number info.


Agreed. Which is why I'll use that file as a basis for the minor bit of work 
I'll do in adding the capabilities and other information to sysfs. Though I 
was under the impression that a lot of the device specific information was 
being moved into sysfs anyway...

The reason it just says RAM is because, contrary to my statement in an earlier 
mail it doesn't mean DVD-RAM, since my CD-RW also has that listed. (and 
DVD-RAM has it's own slot in the file) I wasn't able to locate information on 
what that is in the MMC docs, but in this case it might refer to the UDF 
format. AFAICT the names used there are what are presented by the drive in 
the capabilities mode page.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

Chris Adams wrote:
> Once upon a time, Christoph Hellwig  <hch@infradead.org> said:
>> On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote:
>>> It would be nice to have one place to go to find burners, and to have 
>>> the model information in that place.
>> /proc/sys/dev/cdrom/info
> 
> Which is bad, as it is incomplete and requires the kernel be updated to
> know about every format just to document them.

Document them where? In the kernel Documentation directory? I believe
those strings come back from the drive, as long as the human or
application can parse them the kernel operationally needs only what you
mentioned below.
> 
> Problems with that file:

The main problem with that file is that it wasn't mentioned several
years ago... and I hope you aren't even thinking of suggesting any
changes to something which has been around for years and which
applications are undoubtedly quietly using.

A changed version of the same information in /sys would be a better
solution if changes other than some additions are needed.
> 
> - What is "drive speed" (no units); also most drives do different speeds
>   for different modes/media.

Presumably the max speed mechanically possible, in the units of "x"
which are used to identify both media and burners and have been since
"2x" was the fast burner.
> 
> - CD-RW really covers a range of different formats ("high speed" CD-RW
>   is different and IIRC there's also "ultra high speed" CD-RW).
> 
> - Several formats are missing: DVD-RW DVD+R DVD+RW DVD-DL DVD+DL (at
>   least).
> 
> - What is the "RAM" format (not "DVD-RAM")?  I haven't heard of that.
> 
> The kernel really only needs to know:
> 
> - how the drive can control the tray (open/close/lock/change disc)
> 
> - if the drive can handle rewritable formats (for UDF support)

CD-RW seems to cover that.
> 
> Alternately, every known format needs to be added to that file (both
> read and write support).  It also needs to note read and write speeds
> for each available format.

Why? The mmc/scsi commands work or don't, the device returns the info in
the capabilities page if the application can use it, so it doesn't seem
that the kernel cares, other than the cases you mentioned.
> 
> Also, that is an annoying to parse format.  What if there's a really
> long text column field like "Can write Blu-Ray HD dual layer v2"?
> Something under /sys would be better with one value per file, so if you
> want to burn a DVD-R, you look for /sys/block/*/cdinfo/write/dvd-r;

Isn't there a problem with having the same device in multiple places?
Someone posted that there was, but I didn't really get into the details.
In any case, why is opening dozens of files better than opening one file
with all of the info. Long names can be abbreviated, complexity in the
kernel to avoid complexity in the application is bad, particularly when
humans parse the existing format nicely.

> maybe that file contains a space separated list of available speeds (so
> "1 2 4 8").  Also, right now as far as I can see, /sys doesn't present
> manufacturer, model, and/or serial number info.

The only applications which care about speeds other than max are already
reading the capabilities page. Use cdrecord with the "-prcap" options,
there is a boatload of stuff there. I agree the the three text items are
  useful, and major/minor to map the device to the name actually used in
/dev, but that data doesn't fit the format well, and might be better
presented in /sys. Preferably in a human readable format, like
/proc/scsi/scsi rather than multiple file per device.


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: CD writing in future Linux (stirring up a hornets' nest)

[Chris Adams]

Once upon a time, Bill Davidsen  <davidsen@tmr.com> said:
>> Which is bad, as it is incomplete and requires the kernel be updated to
>> know about every format just to document them.
>
>Document them where? In the kernel Documentation directory? I believe
>those strings come back from the drive, as long as the human or
>application can parse them the kernel operationally needs only what you
>mentioned below.

I wasn't aware those strings actually came from the devices.  What I
meant was if that file is to be the documentation of the drive
capabilities, it needs to be updated to list all known capabilities (and
be updated promptly when new capabilities are created).  It currently
has many missing formats.

>> - What is "drive speed" (no units); also most drives do different speeds
>>   for different modes/media.
>
>Presumably the max speed mechanically possible, in the units of "x"
>which are used to identify both media and burners and have been since
>"2x" was the fast burner.

I've got a burner that has the following burn speeds (from memory): 16x
DVD+/-R, 8x DVD+RW, 6x DVD-RW, 4x DVD+/-R DL, 48x CD-R, and 24x CD-RW.
I don't even remember what the max read speeds are.  Which is the "max"?
The 16x DVD speed or the 48x CD speed?  Why?

The "x" unit is only meaningful with an associated format (since "1x" is
different for different formats) and with "read" or "write" specified.

Without units, the number is meaningless.

>> - if the drive can handle rewritable formats (for UDF support)
>
>CD-RW seems to cover that.

Not for DVD+RW, DVD-RW, and DVD-RAM (which is the only one there).
Sometime down the road, HD-DVD and Blu-Ray versions of rewritable will
also exist.

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Monday 27 February 2006 16:21, Chris Adams wrote:
> Once upon a time, Bill Davidsen  <davidsen@tmr.com> said:
> >> Which is bad, as it is incomplete and requires the kernel be updated to
> >> know about every format just to document them.
> >
> >Document them where? In the kernel Documentation directory? I believe
> >those strings come back from the drive, as long as the human or
> >application can parse them the kernel operationally needs only what you
> >mentioned below.
>
> I wasn't aware those strings actually came from the devices.  What I
> meant was if that file is to be the documentation of the drive
> capabilities, it needs to be updated to list all known capabilities (and
> be updated promptly when new capabilities are created).  It currently
> has many missing formats.

No, the strings do not come from the drive. Those capabilities, IIRC, are 
presented as a series of bitflags packed into a 32 bit integer. This is 
described in the MMC spec for the "capabilities mode page". The drive _does_ 
supply the information as to what formats it understands, but in this case 
the kernel translates it into a human readable format.

> >> - What is "drive speed" (no units); also most drives do different speeds
> >>   for different modes/media.
> >
> >Presumably the max speed mechanically possible, in the units of "x"
> >which are used to identify both media and burners and have been since
> >"2x" was the fast burner.
>
> I've got a burner that has the following burn speeds (from memory): 16x
> DVD+/-R, 8x DVD+RW, 6x DVD-RW, 4x DVD+/-R DL, 48x CD-R, and 24x CD-RW.
> I don't even remember what the max read speeds are.  Which is the "max"?
> The 16x DVD speed or the 48x CD speed?  Why?

This value is also reported by the drive. I don't know about DVD drives, but 
for CD drives it is a multiplier. 1x == 256K/sec transfer off the disc, 52x 
is 13M/sec transfer off the disc. However, in the case of all discs, all 
speeds beyond a certain cut-off value (I forget what the number is) the 
number is "Maximum/Variable" because the polycarbonate the discs are made 
from will deform and shatter from the centrifugal forces above a certain RPM.

(And this I have witness three times myself with a 52x drive and old discs. 
It's a real bitch to have to take apart a CD drive and clean out the 
fragments of the disc.)

> The "x" unit is only meaningful with an associated format (since "1x" is
> different for different formats) and with "read" or "write" specified.
>
> Without units, the number is meaningless.

It's in units as specified by the specification. The redbook spec for CDROM 
drives states the minimum spin speed for stable reading and that roughly 
translates to a 256K/sec read rate.

I haven't had time to look into the DVD specification, but I'm guessing that 
the DVD speed is about 3x what the CDROM speed is.

> >> - if the drive can handle rewritable formats (for UDF support)
> >
> >CD-RW seems to cover that.
>
> Not for DVD+RW, DVD-RW, and DVD-RAM (which is the only one there).
> Sometime down the road, HD-DVD and Blu-Ray versions of rewritable will
> also exist.

Exactly. And these are all covered in the file. And as more formats are added 
the currently unused bits in the capabilities mode page will come into use. 
It will, at some point, be used up - and then I have a feeling a new mode 
page will be introduced so that the current one isn't changed in a way that 
would break legacy applications.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Peter Gordon]

On 2/27/06, D. Hazelton <dhazelton@enter.net> wrote:
> This value is also reported by the drive. I don't know about DVD drives, but
> for CD drives it is a multiplier. 1x == 256K/sec transfer off the disc [...]
For CDs, 1x is actually 150 KByte/sec.

> I haven't had time to look into the DVD specification, but I'm guessing that
> the DVD speed is about 3x what the CDROM speed is.

According to WikiPedia, the DVD speed rating is almost 9 times that of
CD speeds. I.e., 1x DVD is about 1.32 MByte/sec.


Just to make sure that we're all on the same page. :)
~~Peter

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Monday 27 February 2006 17:30, Peter Gordon wrote:
> On 2/27/06, D. Hazelton <dhazelton@enter.net> wrote:
> > This value is also reported by the drive. I don't know about DVD drives,
> > but for CD drives it is a multiplier. 1x == 256K/sec transfer off the
> > disc [...]
>
> For CDs, 1x is actually 150 KByte/sec.

Well, I've been known to be wrong before, and this number was more based on 
the fact that I once measured a sustained transfer rate of 1M/sec on a 4x 
CDROM

> > I haven't had time to look into the DVD specification, but I'm guessing
> > that the DVD speed is about 3x what the CDROM speed is.
>
> According to WikiPedia, the DVD speed rating is almost 9 times that of
> CD speeds. I.e., 1x DVD is about 1.32 MByte/sec.

This was based on DVDx16 == CDx48 - I'm guessing someone is doing some monkey 
work if a DVD is 9x a CD and a 16x DVD can't hit that mystical 52x of my 
favorite CDRW drive in pure CD read mode.

>
> Just to make sure that we're all on the same page. :)
> ~~Peter

Thanks. Was just trying to dispel a few mis-statements and made some myself. 
I'm grateful for the update to my poor memory.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Sam Vilain]

D. Hazelton wrote:
>>>This value is also reported by the drive. I don't know about DVD drives,
>>>but for CD drives it is a multiplier. 1x == 256K/sec transfer off the
>>>disc [...]
>>For CDs, 1x is actually 150 KByte/sec.
> Well, I've been known to be wrong before, and this number was more based on 
> the fact that I once measured a sustained transfer rate of 1M/sec on a 4x 
> CDROM

Think about audio.  Single speed = 75 frames of 2352 bytes per second, 
or 176kB/s.  However with data tracks you only get 2k per frame/sector, 
so that works out to be 153kB/s.

Due to the CLV nature of CD-ROMs you may find the drive is faster 
reading some parts of the disc than others.

>>According to WikiPedia, the DVD speed rating is almost 9 times that of
>>CD speeds. I.e., 1x DVD is about 1.32 MByte/sec.
> This was based on DVDx16 == CDx48 - I'm guessing someone is doing some monkey 
> work if a DVD is 9x a CD and a 16x DVD can't hit that mystical 52x of my 
> favorite CDRW drive in pure CD read mode.

You can do a similar calculation with DVDs.  While I can't find a 
reference for the maximum DVD total bitrate of ~10Mbit/s, this at 1.25 
MByte/s this roughly agrees with the 1.32 quoted.

Sam.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Greg KH <greg@kroah.com> wrote:

> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > 
> > The kernel could provide a list of devices by category. It doesn't have 
> > to name them, run scripts, give descriptions, or paint them blue. Just a 
> > list of all block devices, tapes, by major/minor and category (ie. 
> > block, optical, floppy) would give the application layer a chance to do 
> > it's own interpretation.
>
> It does so today in sysfs, that is what it is there for.

Do you really whant libscg to open _every_ non-directory file under /sys?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> Greg KH <greg@kroah.com> wrote:
> 
> > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > 
> > > The kernel could provide a list of devices by category. It doesn't have 
> > > to name them, run scripts, give descriptions, or paint them blue. Just a 
> > > list of all block devices, tapes, by major/minor and category (ie. 
> > > block, optical, floppy) would give the application layer a chance to do 
> > > it's own interpretation.
> >
> > It does so today in sysfs, that is what it is there for.
> 
> Do you really whant libscg to open _every_ non-directory file under /sys?

Of course not.  Here's one line of bash that gets you the major:minor
file of every block device in the system:
	block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"

The block devices are all in a specific location.

And here's a way to get the cdroms of the system:
	media="$(echo /sys/block/*/device/media)"
	for i in $media; do
		type="$(cat $i)"
		if [ "${type}" == "cdrom" ]
		then
			# we have a cdrom here, at $media block device
		fi
	done

If you want to do this in C, there is a libsysfs, which should help you
out a bit on intregrating sysfs support into your program (although udev
has recently ripped it out and replaced it with 200 lines of code that
is way smaller and much faster...)

Hope this helps,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Greg KH <greg@kroah.com> wrote:

> On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > Greg KH <greg@kroah.com> wrote:
> > 
> > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > > 
> > > > The kernel could provide a list of devices by category. It doesn't have 
> > > > to name them, run scripts, give descriptions, or paint them blue. Just a 
> > > > list of all block devices, tapes, by major/minor and category (ie. 
> > > > block, optical, floppy) would give the application layer a chance to do 
> > > > it's own interpretation.
> > >
> > > It does so today in sysfs, that is what it is there for.
> > 
> > Do you really whant libscg to open _every_ non-directory file under /sys?
>
> Of course not.  Here's one line of bash that gets you the major:minor
> file of every block device in the system:
> 	block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
>
> The block devices are all in a specific location.

Are you sure you understand the problem?

It isd most unlikely that all SCSI devices are there.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-14:

> It isd most unlikely that all SCSI devices are there.

Mind the topic: "CD writing"

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> Joerg Schilling schrieb am 2006-02-14:
>
> > It isd most unlikely that all SCSI devices are there.
>
> Mind the topic: "CD writing"

You don't need to repoeat this  again, I already know that you are unteachable.

For the others: the topic is the device and OS independent libscg.
Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-14:

> You don't need to repoeat this  again, I already know that you are unteachable.

Yet another insult.

> For the others: the topic is the device and OS independent libscg.

Check the subject line, and check the destination address.

This is CD writing on Linux, and it you who is still failing to provide
information about non-CD-related bugs.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Tuesday 14 February 2006 14:58, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> > Joerg Schilling schrieb am 2006-02-14:
> > > It isd most unlikely that all SCSI devices are there.
> >
> > Mind the topic: "CD writing"
>
> You don't need to repoeat this  again, I already know that you are
> unteachable.
>
> For the others: the topic is the device and OS independent libscg.
> Jörg

In your mind only

This thread started out as "CD writing future in Linux" and that's where it 
has been. We all know that you claim all the problems cdrecord has with Linux 
are in libscg, but that doesn't excuse you from ignoring the posted topic and 
trying to change it so you can rant about how bad the SCSI subsystem in Linux 
was designed.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Tuesday 14 February 2006 13:59, Joerg Schilling wrote:
> Greg KH <greg@kroah.com> wrote:
> > On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > > Greg KH <greg@kroah.com> wrote:
> > > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > > > The kernel could provide a list of devices by category. It doesn't
> > > > > have to name them, run scripts, give descriptions, or paint them
> > > > > blue. Just a list of all block devices, tapes, by major/minor and
> > > > > category (ie. block, optical, floppy) would give the application
> > > > > layer a chance to do it's own interpretation.
> > > >
> > > > It does so today in sysfs, that is what it is there for.
> > >
> > > Do you really whant libscg to open _every_ non-directory file under
> > > /sys?
> >
> > Of course not.  Here's one line of bash that gets you the major:minor
> > file of every block device in the system:
> > 	block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
> >
> > The block devices are all in a specific location.
>
> Are you sure you understand the problem?
>
> It isd most unlikely that all SCSI devices are there.
>
> Jörg

Which is why there is also /sys/class/scsi_host and /sys/class/scsi_device
those two, together with the block device data available via /sys/block should 
be enough to enumerate every ATAPI and SCSI device on the system.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Mon, Feb 13, 2006 at 07:49:21AM -0800, Greg KH wrote:
> On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > Greg KH <greg@kroah.com> wrote:
> > 
> > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > > 
> > > > The kernel could provide a list of devices by category. It doesn't have 
> > > > to name them, run scripts, give descriptions, or paint them blue. Just a 
> > > > list of all block devices, tapes, by major/minor and category (ie. 
> > > > block, optical, floppy) would give the application layer a chance to do 
> > > > it's own interpretation.
> > >
> > > It does so today in sysfs, that is what it is there for.
> > 
> > Do you really whant libscg to open _every_ non-directory file under /sys?
> 
> Of course not.  Here's one line of bash that gets you the major:minor
> file of every block device in the system:
> 	block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"

Of course, that's entirely useless if you're not root.

So what you _really_ have to do is to call udevinfo -e.  If that
fails, call udevinfo -d, that's the old name for the option which got
changed along the way.  The result is blocks of text lines separated
by blank lines, text lines of the form:

I: value

Where I is a one-letter uppercase identifier, and value a value.

If you get E: entries, you're lucky.  All cdroms have a E: ID_CDROM=1
entry, but these entries appeared late.  Otherwise, the best bet is to
scan the S: entries for something matching /cdrom/.  When you have a
bloc of lines, get the N: entry, that's the node name, and prepend it
with the result of udevinfo -r (usually /dev/, but that's not
mandatory).  That will give you the device node path to open (don't
forget O_EXCL to avoid Hal stomping all over you), which you can then
use SG_IO with.

If udevinfo is not available, you'll have to try opening all /dev/hd*,
/dev/sr*, /dev/scd*, /dev/sg*, /dev/cdr* and /dev/dvd* (don't stop at
the first -EANYTHING though, otherwise you'll miss some).  Then you
can poke the device carefully with SG_IO.

  OG.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

On Mon, 13 Feb 2006, Greg KH wrote:

> On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote:
> > Greg KH <greg@kroah.com> wrote:
> > 
> > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> > > > 
> > > > The kernel could provide a list of devices by category. It doesn't have 
> > > > to name them, run scripts, give descriptions, or paint them blue. Just a 
> > > > list of all block devices, tapes, by major/minor and category (ie. 
> > > > block, optical, floppy) would give the application layer a chance to do 
> > > > it's own interpretation.
> > >
> > > It does so today in sysfs, that is what it is there for.
> > 
> > Do you really whant libscg to open _every_ non-directory file under /sys?
> 
> Of course not.  Here's one line of bash that gets you the major:minor
> file of every block device in the system:
> 	block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
> 
> The block devices are all in a specific location.
> 
> And here's a way to get the cdroms of the system:
	[snip]
> 
> If you want to do this in C, there is a libsysfs, which should help you
> out a bit on intregrating sysfs support into your program (although udev
> has recently ripped it out and replaced it with 200 lines of code that
> is way smaller and much faster...)
> 
> Hope this helps,

Just determined that at least in FC4 the udev stuff doesn't seem to create 
the sg devices, cdrecord doesn't work with devices which use the scsi 
interface AFAIK, fails with USB, Firewire, and real SCSI devices.

I'm still looking at this, trying w/o udev.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
Doing interesting things with little computers since 1979

Re: CD writing in future Linux (stirring up a hornets' nest)

[Nix]

On Tue, 14 Feb 2006, Bill Davidsen stated:
> Just determined that at least in FC4 the udev stuff doesn't seem to create 
> the sg devices,

It has done so for as long as I've been using udev (since 058).

What kernel are you using?

-- 
`... follow the bouncing internment camps.' --- Peter da Silva

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>
>Of course not.  Here's one line of bash that gets you the major:minor
>file of every block device in the system:
>	block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
>
When was that added? /sys/block/hdc/device/ only has "power", "block", 
"bus" and "driver" here on a 2.6.13-rc3.


Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Wed, Feb 15, 2006 at 04:44:38PM +0100, Jan Engelhardt wrote:
> >
> >Of course not.  Here's one line of bash that gets you the major:minor
> >file of every block device in the system:
> >	block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
> >
> When was that added? /sys/block/hdc/device/ only has "power", "block", 
> "bus" and "driver" here on a 2.6.13-rc3.

No, it's /sys/block/hdc/dev (22:0 here on 2.6.12).  Makes sense to
have it there if you have multiple driver-generated device node
entries for the same physical device.  I'm thinking of usb
multi-function devices here in particular (disk+bluetooth, video+hid
[dvb+remote control that is]).

  OG.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Wed, Feb 15, 2006 at 04:44:38PM +0100, Jan Engelhardt wrote:
> >
> >Of course not.  Here's one line of bash that gets you the major:minor
> >file of every block device in the system:
> >	block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)"
> >
> When was that added? /sys/block/hdc/device/ only has "power", "block", 
> "bus" and "driver" here on a 2.6.13-rc3.

True, that's why my above "echo" didn't point to "device" but "dev".
"device" is a symlink to the device that the block device is attached
to.  "dev" is the major:minor number of this specific block device.

Hope this helps,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Nix]

On Mon, 13 Feb 2006, Joerg Schilling stated:
> Greg KH <greg@kroah.com> wrote:
> 
>> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
>> > 
>> > The kernel could provide a list of devices by category. It doesn't have 
>> > to name them, run scripts, give descriptions, or paint them blue. Just a 
>> > list of all block devices, tapes, by major/minor and category (ie. 
>> > block, optical, floppy) would give the application layer a chance to do 
>> > it's own interpretation.
>>
>> It does so today in sysfs, that is what it is there for.
> 
> Do you really whant libscg to open _every_ non-directory file under /sys?

Well, that would be overkill, but iterating across, say,
/sys/class/scsi_device seems like it would be a good idea.

(I doubt libscg would ever be interested in the stuff in most of the
other directories: things like /dev/mem are not SCSI devices and never
will be, and /sys/class/scsi_device contains *everything* Linux
considers a SCSI device, no matter what transport it is on, SATA and
all. However, I don't know if it handles IDE devices that you can SG_IO
to because I don't have any such here. Anyone know?)

-- 
`... follow the bouncing internment camps.' --- Peter da Silva

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Monday 13 February 2006 17:14, Nix wrote:
> On Mon, 13 Feb 2006, Joerg Schilling stated:
> > Greg KH <greg@kroah.com> wrote:
> >> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote:
> >> > The kernel could provide a list of devices by category. It doesn't
> >> > have to name them, run scripts, give descriptions, or paint them blue.
> >> > Just a list of all block devices, tapes, by major/minor and category
> >> > (ie. block, optical, floppy) would give the application layer a chance
> >> > to do it's own interpretation.
> >>
> >> It does so today in sysfs, that is what it is there for.
> >
> > Do you really whant libscg to open _every_ non-directory file under /sys?
>
> Well, that would be overkill, but iterating across, say,
> /sys/class/scsi_device seems like it would be a good idea.
>
> (I doubt libscg would ever be interested in the stuff in most of the
> other directories: things like /dev/mem are not SCSI devices and never
> will be, and /sys/class/scsi_device contains *everything* Linux
> considers a SCSI device, no matter what transport it is on, SATA and
> all. However, I don't know if it handles IDE devices that you can SG_IO
> to because I don't have any such here. Anyone know?)

Not on my system, and I have a DVD-ROM and a CDRW drive attached, both of 
which are capable of SG_IO.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Nix]

On Mon, 13 Feb 2006, D. Hazelton whispered secretively:
> On Monday 13 February 2006 17:14, Nix wrote:
>> (I doubt libscg would ever be interested in the stuff in most of the
>> other directories: things like /dev/mem are not SCSI devices and never
>> will be, and /sys/class/scsi_device contains *everything* Linux
>> considers a SCSI device, no matter what transport it is on, SATA and
>> all. However, I don't know if it handles IDE devices that you can SG_IO
>> to because I don't have any such here. Anyone know?)
> 
> Not on my system, and I have a DVD-ROM and a CDRW drive attached, both of 
> which are capable of SG_IO.

Blast. Well, all these SCSI-like things *should* appear in one place
in /sys, dammit. Even if they don't right now. :/

-- 
`... follow the bouncing internment camps.' --- Peter da Silva

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

On Mon, 13 Feb 2006, Nix wrote:

> (I doubt libscg would ever be interested in the stuff in most of the
> other directories: things like /dev/mem are not SCSI devices and never
> will be, and /sys/class/scsi_device contains *everything* Linux
> considers a SCSI device, no matter what transport it is on, SATA and
> all. However, I don't know if it handles IDE devices that you can SG_IO
> to because I don't have any such here. Anyone know?)

My ATAPI DVD and CD writers are not listed in /sys/class/scsi_device.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>
>> (I doubt libscg would ever be interested in the stuff in most of the
>> other directories: things like /dev/mem are not SCSI devices and never
>> will be, and /sys/class/scsi_device contains *everything* Linux
>> considers a SCSI device, no matter what transport it is on, SATA and
>> all. However, I don't know if it handles IDE devices that you can SG_IO
>> to because I don't have any such here. Anyone know?)
>
>My ATAPI DVD and CD writers are not listed in /sys/class/scsi_device.
>
My IDE one is neither nowhere in /sys/class. (Maybe I did not try looking 
hard enough, though.)



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Tue, Feb 14, 2006 at 07:09:19PM +0100, Jan Engelhardt wrote:
> My IDE one is neither nowhere in /sys/class. (Maybe I did not try looking 
> hard enough, though.)

Why care, official policy is that you should do device discovery
through udevinfo and not touch sysfs.

  OG.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> My IDE one is neither nowhere in /sys/class. (Maybe I did not try looking 
>> hard enough, though.)
>
>Why care, official policy is that you should do device discovery
>through udevinfo and not touch sysfs.
>
Hm, it's in /sys/block/hdb.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Nix <nix@esperi.org.uk> wrote:

> > Do you really whant libscg to open _every_ non-directory file under /sys?
>
> Well, that would be overkill, but iterating across, say,
> /sys/class/scsi_device seems like it would be a good idea.
>
> (I doubt libscg would ever be interested in the stuff in most of the
> other directories: things like /dev/mem are not SCSI devices and never
> will be, and /sys/class/scsi_device contains *everything* Linux
> considers a SCSI device, no matter what transport it is on, SATA and
> all. However, I don't know if it handles IDE devices that you can SG_IO
> to because I don't have any such here. Anyone know?)

This statement is obviously not true :-(

Let us start in a way that makes sense:

Please send me the whitepaper that was used to define the interfaces
and functionality of the /sys device

Please send me the other documentation (e.g. man pages) on the /sys
device

Please send me a statement on how long this interface will be maintained
inside Linux without breaking interfaces.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Tue, Feb 14, 2006 at 12:27:18PM +0100, Joerg Schilling wrote:
> 
> Please send me the whitepaper that was used to define the interfaces
> and functionality of the /sys device

I was not aware that there is now a rule that we must write whitepapers
describing as to what the interface looks like in complete detail that
we want to add to the Linux kernel.  Will you please point me to the
proper authorities that will be enforcing this newly created rule?

> Please send me the other documentation (e.g. man pages) on the /sys
> device

What "/sys device"?  sysfs is a file system, and there have been many
magazine articles, and conference papers written, and talks given on the
topic.

If you have specific questions as to how it is structured, please let
the current sysfs maintainer know.

> Please send me a statement on how long this interface will be maintained
> inside Linux without breaking interfaces.

It will be stable and maintained until a major program depends on its
structure.  Then it will change in new and interesting ways and break
everything :)

Seriously, it isn't going away, and new information is being added all
the time to it.  Due to the structure of sysfs, changes in it is very
easy to accomidate.

thanks,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

On Tue, 14 Feb 2006, Greg KH wrote:

> On Tue, Feb 14, 2006 at 12:27:18PM +0100, Joerg Schilling wrote:
> > 
> > Please send me the whitepaper that was used to define the interfaces
> > and functionality of the /sys device
> 
> I was not aware that there is now a rule that we must write whitepapers
> describing as to what the interface looks like in complete detail that
> we want to add to the Linux kernel.  Will you please point me to the
> proper authorities that will be enforcing this newly created rule?

Well, Jörg's questions, although ridiculously exaggerated and quixotic,
show a general problem in Linux: documentation is constantly outdated,
missing, and not part of the kernel package.

If Linux were based in Utopia, it would ship with a complete set of
kernel-related manual pages and HOWTOs.

I appreciate the efforts of the old and new man-pages maintainers, and I
know the problems in motivation when writing documentation and keeping
it up to date distracts people from writing code -- but those people
know their code best.

> > Please send me the other documentation (e.g. man pages) on the /sys
> > device
> 
> What "/sys device"?  sysfs is a file system, and there have been many
> magazine articles, and conference papers written, and talks given on the
> topic.

And that is the key problem. magazine here, conference there, talk
(perhaps only slides available) somewhere else -- a manual that was in
/usr/src/linux/Documentation might make a real difference. Even a
commented link list in Documentation/* might be a good starting point.

Patrick Mochel added some bits three years ago, but they were internals
and thus a bit less interesting.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Wed, Feb 15, 2006 at 01:43:20AM +0100, Matthias Andree wrote:
> > > Please send me the other documentation (e.g. man pages) on the /sys
> > > device
> > 
> > What "/sys device"?  sysfs is a file system, and there have been many
> > magazine articles, and conference papers written, and talks given on the
> > topic.
> 
> And that is the key problem. magazine here, conference there, talk
> (perhaps only slides available) somewhere else -- a manual that was in
> /usr/src/linux/Documentation might make a real difference. Even a
> commented link list in Documentation/* might be a good starting point.
> 
> Patrick Mochel added some bits three years ago, but they were internals
> and thus a bit less interesting.

What would be "interesting"?  The sysfs and driver model chapter of the
Linux Device Driver book from Oreilly, third edition?  Or something
oriented toward users of sysfs, not developers using it?

thanks,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

On Tue, 14 Feb 2006, Greg KH wrote:

> > And that is the key problem. magazine here, conference there, talk
> > (perhaps only slides available) somewhere else -- a manual that was in
> > /usr/src/linux/Documentation might make a real difference. Even a
> > commented link list in Documentation/* might be a good starting point.
> > 
> > Patrick Mochel added some bits three years ago, but they were internals
> > and thus a bit less interesting.
> 
> What would be "interesting"?  The sysfs and driver model chapter of the
> Linux Device Driver book from Oreilly, third edition?  Or something
> oriented toward users of sysfs, not developers using it?

Integrating documentation with the kernel. Documentation/* is constantly
out of date and incomplete, and sometimes has non-intuitive names.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Randy.Dunlap]

On Thu, 16 Feb 2006, Matthias Andree wrote:

> On Tue, 14 Feb 2006, Greg KH wrote:
>
> > > And that is the key problem. magazine here, conference there, talk
> > > (perhaps only slides available) somewhere else -- a manual that was in
> > > /usr/src/linux/Documentation might make a real difference. Even a
> > > commented link list in Documentation/* might be a good starting point.
> > >
> > > Patrick Mochel added some bits three years ago, but they were internals
> > > and thus a bit less interesting.
> >
> > What would be "interesting"?  The sysfs and driver model chapter of the
> > Linux Device Driver book from Oreilly, third edition?  Or something
> > oriented toward users of sysfs, not developers using it?
>
> Integrating documentation with the kernel. Documentation/* is constantly
> out of date and incomplete, and sometimes has non-intuitive names.

I mostly agree and I'm trying to update it -- in my spare time.

Help is accepted.  8:)

-- 
~Randy

Re: CD writing in future Linux (stirring up a hornets' nest)

[Greg KH]

On Thu, Feb 16, 2006 at 01:01:29PM +0100, Matthias Andree wrote:
> On Tue, 14 Feb 2006, Greg KH wrote:
> 
> > > And that is the key problem. magazine here, conference there, talk
> > > (perhaps only slides available) somewhere else -- a manual that was in
> > > /usr/src/linux/Documentation might make a real difference. Even a
> > > commented link list in Documentation/* might be a good starting point.
> > > 
> > > Patrick Mochel added some bits three years ago, but they were internals
> > > and thus a bit less interesting.
> > 
> > What would be "interesting"?  The sysfs and driver model chapter of the
> > Linux Device Driver book from Oreilly, third edition?  Or something
> > oriented toward users of sysfs, not developers using it?
> 
> Integrating documentation with the kernel.

What kind of documentation?  user oriented documentation like how to
find specific stuff in sysfs?  Or developer oriented documentation, like
we have there now.

> Documentation/* is constantly out of date and incomplete, and
> sometimes has non-intuitive names.

It's not always out of date.  And patches are always gladly accepted.

Also, what non-intuitive names are you referring to?

thanks,

greg k-h

Re: CD writing in future Linux (stirring up a hornets' nest)

[Nix]

On Tue, 14 Feb 2006, Joerg Schilling wrote:
> Please send me the whitepaper that was used to define the interfaces
> and functionality of the /sys device

If you seriously think that development of *anything* in the free
software world happens by means of whitepapers preceding definition, or
indeed that anything major in the Unix world has ever worked that way,
you're seriously deluded.

> Please send me the other documentation (e.g. man pages) on the /sys
> device

Oh, I thought you had *access* to the kernel source. A trivial grep
under the Documentation directory would find it (hint:
Documentation/filesystems/ is a good place to start.)

If you actually wanted to *fix* your program --- if you cared more about
users than being proved right no matter what --- then you'd have been
able to determine that for yourself in seconds.

(But then we all know that's not what you're actually after.)

> Please send me a statement on how long this interface will be maintained
> inside Linux without breaking interfaces.

What a ridiculous request. If people use it, it won't be broken. If it
proves unusable due to flaws, it will change. Sheesh.

(It is not as robust as the syscall interface, but it is still subject
to some degree of change. A trivial google would have made this clear.)

You appear not to understand the difference between development
roadmapped for years in advance by a sclerotic corporation and free
software development. Or perhaps you do understand, and are just being
pointlessly contrary. (I expect the latter is true. You're not stupid.
Just nasty.)

-- 
`... follow the bouncing internment camps.' --- Peter da Silva

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Nix <nix@esperi.org.uk> wrote:

> > Please send me a statement on how long this interface will be maintained
> > inside Linux without breaking interfaces.
>
> What a ridiculous request. If people use it, it won't be broken. If it
> proves unusable due to flaws, it will change. Sheesh.

Looks like you are a Linux newby and did not yet relize how Linux
is maintained :-(

ide-scsi is used and needed but made unsusable.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello!

> ide-scsi is used and needed but made unsusable.

Used maybe, but needed by whom?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Top ten reasons to procrastinate: 1.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Nix]

On Thu, 16 Feb 2006, Martin Mares noted:
> Hello!
> 
>> ide-scsi is used and needed but made unsusable.
> 
> Used maybe, but needed by whom?

Why, by Joerg of course, with his magic telepathy helmet which enables
him to tell exactly how long people he doesn't know have been using
Linux, and lets him determine exactly how broken all patches written by
other people are without even looking at them, and his great genius
which enables him to tell exactly how Linux must work (i.e., exactly
like Solaris), regardless of what any of those fools who actually
*wrote* it may think.

How could you possibly think anything else? Nothing else would be
*rational*. You of course should not respond until you agree with Joerg
in all matters.

(I was wondering how Joerg managed to unilaterally impose new licensing
terms on cdrecord without going through lots of trouble asking all the
other contributors. I guess I know now: there *are* no other
contributors, because nobody else can bear to work with him.)

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello!

> MO, WORM, {ZIP,ls120} drives if you are using the full capabilities, IDE 
> tape drives, etc.
> 
> Sorry, I don't remember what capability the ls120 was using, but as of 
> 2.6.12 it didn't work through the ide-floppy interface.

Then it's a bug in ide-floppy which should be fixed.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Immanuel doesn't pun, he Kant.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Ondrej Zary]

Martin Mares wrote:
> Hello!
> 
>> MO, WORM, {ZIP,ls120} drives if you are using the full capabilities, IDE 
>> tape drives, etc.
>>
>> Sorry, I don't remember what capability the ls120 was using, but as of 
>> 2.6.12 it didn't work through the ide-floppy interface.
> 
> Then it's a bug in ide-floppy which should be fixed.
> 
I fixed something in ide-floppy some time ago - when I bought LS-120 
drive and software eject did not work. See http://lkml.org/lkml/2005/9/4/83

-- 
Ondrej Zary

Re: CD writing in future Linux (stirring up a hornets' nest)

[Marc Koschewski]

* Joerg Schilling <schilling@fokus.fraunhofer.de> [2006-02-16 13:09:53 +0100]:

> Nix <nix@esperi.org.uk> wrote:
> 
> > > Please send me a statement on how long this interface will be maintained
> > > inside Linux without breaking interfaces.
> >
> > What a ridiculous request. If people use it, it won't be broken. If it
> > proves unusable due to flaws, it will change. Sheesh.
> 
> Looks like you are a Linux newby and did not yet relize how Linux
> is maintained :-(
> 
> ide-scsi is used and needed but made unsusable.

I remember a time when I used it in order to be able to burn CDs. Nowadays it
works, however, without the module. Don't know who is using it. Or what for..

Marc

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Bill Davidsen <davidsen@tmr.com> wrote:


> I notice that the first thing people suggest is to make things like 
> udev, hal and sysfs required instead of optional to do something as 
> simple as burn a CD. As I mentioned before, if the kernel provided a 
> list of devices then applications wouldn't break every time a new kernel 
> came out which needs a new this, and new that, and a few new other 
> support things.

This would make sense in case that a useful definition with a granted lifetime 
of at least 10 years would be implemented.


> The kernel could provide a list of devices by category. It doesn't have 

What if the kernel does not understand the cetegory?

Common oddities:

-	Mac OS X tries to distinct between CD/DVD writers and CD/DVD-ROM
	although there is only one device class.

-	Older CD-writers identified as WORM although a CD-R is not a WORM.

> to name them, run scripts, give descriptions, or paint them blue. Just a 
> list of all block devices, tapes, by major/minor and category (ie. 
> block, optical, floppy) would give the application layer a chance to do 
> it's own interpretation. HAL is great, but because it's not part of the 
> kernel it's also going to suffer from "tracking error" for some changes. 
> I find it easier to teach someone to use -scanbus than to explain how to 
> make rules for udev.

As this categorisation does not work, we need a way to find all devices 
that talk SCSI and let the application decicde what device is supported.


> Worth repeating: I find it easier to teach someone to use -scanbus than 
> to explain how to make rules for udev. HAL is the right answer, but *in* 
> the kernel, where it will track changes. Since -scanbus tells you a 
> device is a CDrecorder, or something else, *any user* is likely to be 
> able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices...

So you seem to agree with me.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Anders Karlsson <trudheim@gmail.com> wrote:

> On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> [snip]
> > -       Older CD-writers identified as WORM although a CD-R is not a WORM.
>
> Nitpicking I know, but technically, CD-R is WORM in the case of single
> session write. And as long as the writer works, who cares if it is
> labled WORM, CD-R or Earthworm..

If you did know what a worm is, you would know that you are not correct:

A WORM allows you to randomly write any sector once.

A CD-R does not allows you to do this.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>> Nitpicking I know, but technically, CD-R is WORM in the case of single
>> session write. And as long as the writer works, who cares if it is
>> labled WORM, CD-R or Earthworm..
>
>If you did know what a worm is, you would know that you are not correct:
>
>A WORM allows you to randomly write any sector once.
>A CD-R does not allows you to do this.
>
Nitpicking2, the CD-R case is a limitation of the cd writer ;)
Sadly there is no packet mode for CDRs. It would outbeat multisession.



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Monday 13 February 2006 10:12, Joerg Schilling wrote:
> Anders Karlsson <trudheim@gmail.com> wrote:
> > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > [snip]
> >
> > > -       Older CD-writers identified as WORM although a CD-R is not a
> > > WORM.
> >
> > Nitpicking I know, but technically, CD-R is WORM in the case of single
> > session write. And as long as the writer works, who cares if it is
> > labled WORM, CD-R or Earthworm..
>
> If you did know what a worm is, you would know that you are not correct:
>
> A WORM allows you to randomly write any sector once.
>
> A CD-R does not allows you to do this.

Joerg, the practical definition of WORM is "Write Once, Read Many" - whether 
or not it supports writes to random sectors is a moot point, a CDR does seem 
to fit the bill of a "write once, read many" medium.

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

"D. Hazelton" <dhazelton@enter.net> wrote:

> > If you did know what a worm is, you would know that you are not correct:
> >
> > A WORM allows you to randomly write any sector once.
> >
> > A CD-R does not allows you to do this.
>
> Joerg, the practical definition of WORM is "Write Once, Read Many" - whether 
> or not it supports writes to random sectors is a moot point, a CDR does seem 
> to fit the bill of a "write once, read many" medium.

What you believe is irrelevent as long as it does not match the WORM device
definition.

See www.t10.org

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[D. Hazelton]

On Tuesday 14 February 2006 08:55, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > If you did know what a worm is, you would know that you are not
> > > correct:
> > >
> > > A WORM allows you to randomly write any sector once.
> > >
> > > A CD-R does not allows you to do this.
> >
> > Joerg, the practical definition of WORM is "Write Once, Read Many" -
> > whether or not it supports writes to random sectors is a moot point, a
> > CDR does seem to fit the bill of a "write once, read many" medium.
>
> What you believe is irrelevent as long as it does not match the WORM device
> definition.
>
> See www.t10.org
>
> Jörg

Joerg, I didn't say it was what _I_ believed. What I said was "WORM" means 
"Wrint One, Read Many" - since a CDR can be described in that fashion, it 
does match the description. Since it matches the description, most people 
lump the CDR medium in with all "WORM" medium. Is that clear enough?

DRH

Re: CD writing in future Linux (stirring up a hornets' nest)

[Nix]

On Sat, 18 Feb 2006, Bill Davidsen gibbered uncontrollably:
> There was a time when packet writing on CD-RW worked on Linux and
> people stopped using WORM for the most part. I haven't tried since
> udev became standard on most distros, I don't know if it still works
> or not.

If it doesn't work then the backup I'm now running is a mirage,
but I'm so thick with cold that it might well be illusory ;}

-- 
`... follow the bouncing internment camps.' --- Peter da Silva

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> Jens Axboe wrote:
>
> > In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
> > on potentially useful devices.
>
> Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather
> complicated and non-portable. I understand that applications that can just
> open every device and send SCSI INQUIRY might want to do that on Linux, too.

Another problem is that it is hard to find whether a new feature in Linux will 
still be present some time later.

If I would try to immediately add support for every new feature, I would have a 
lot of dead code in my sources and would need to put a lot of effort in this 
kind of coding. It seems that it makes sense to wait untill all major Linux 
distributions made a new feature their default for some time.....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Wed, Jan 25, 2006 at 06:31:27PM +0100, Jens Axboe wrote:
> In fact it would be a _lot_ easier to just scan sysfs and do an inquiry
> on potentially useful devices.

Serious question, what and how?  If I scan /sys/block for example for
potential candidates, that won't give me the devices or tell me the
name udev decided to use for it in /dev.

And I'm not sure how to know if something is cdrom-ish and SG_IO able
from sysfs.  Should I filter on driver name?  But then, I don't know
which names are acceptable (*cdrom* ?)...

Or maybe I should go through the fad-of-the-day, hal/dbus?

  OG.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

<grundig@teleline.es> wrote:

> El Wed, 25 Jan 2006 18:03:18 +0100,
> Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:
>
> > Guess why cdrecord -scanbus is needed.
> > 
> > It serves the need of GUI programs for cdrercord and allows them to retrieve 
> > and list possible drives of interest in a platform independent way.
>
> But this is not neccesary at all, since linux platform already provides ways to
> retrieve and list possible drives....

Interesting: You claim that the Linux platform provides ways to retrieve 
the needed information on FreeBSD, MS-WIN, ....?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Lee Revell]

On Thu, 2006-01-26 at 10:38 +0100, Joerg Schilling wrote:
> <grundig@teleline.es> wrote:
> 
> > El Wed, 25 Jan 2006 18:03:18 +0100,
> > Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:
> >
> > > Guess why cdrecord -scanbus is needed.
> > > 
> > > It serves the need of GUI programs for cdrercord and allows them to retrieve 
> > > and list possible drives of interest in a platform independent way.
> >
> > But this is not neccesary at all, since linux platform already provides ways to
> > retrieve and list possible drives....
> 
> Interesting: You claim that the Linux platform provides ways to retrieve 
> the needed information on FreeBSD, MS-WIN, ....?
> 

What do FreeBSD and MS-WIN have to do with Linux?

Lee

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Lee Revell <rlrevell@joe-job.com> wrote:

> > Interesting: You claim that the Linux platform provides ways to retrieve 
> > the needed information on FreeBSD, MS-WIN, ....?
> > 
>
> What do FreeBSD and MS-WIN have to do with Linux?

What is the relevence of /dev/hd* for a device independent library like libscg?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Nick Piggin]

Joerg Schilling wrote:
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> 
>>>Interesting: You claim that the Linux platform provides ways to retrieve 
>>>the needed information on FreeBSD, MS-WIN, ....?
>>>
>>
>>What do FreeBSD and MS-WIN have to do with Linux?
> 
> 
> What is the relevence of /dev/hd* for a device independent library like libscg?
> 

Isn't it good practice to adhere to the naming conventions
of the system to which a program is ported to? (even if 100
of them do it one way and 1 does it another)

I don't claim to be an expert in the area at all, but it seems
like the best way to do it IMHO.

Thanks,
Nick
--
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Joerg Schilling wrote:
> > Lee Revell <rlrevell@joe-job.com> wrote:
> > 
> > 
> >>>Interesting: You claim that the Linux platform provides ways to retrieve 
> >>>the needed information on FreeBSD, MS-WIN, ....?
> >>>
> >>
> >>What do FreeBSD and MS-WIN have to do with Linux?
> > 
> > 
> > What is the relevence of /dev/hd* for a device independent library like libscg?
> > 
>
> Isn't it good practice to adhere to the naming conventions
> of the system to which a program is ported to? (even if 100
> of them do it one way and 1 does it another)

Well, the problem is that (in special if you include the ATAPI tape drives)
Linux likes to enforce inapropriate naming conventions.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Nick Piggin]

Joerg Schilling wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 

>>Isn't it good practice to adhere to the naming conventions
>>of the system to which a program is ported to? (even if 100
>>of them do it one way and 1 does it another)
> 
> 
> Well, the problem is that (in special if you include the ATAPI tape drives)
> Linux likes to enforce inapropriate naming conventions.
> 

But making up a new naming scheme which you happen to consider
more appropriate doesn't sound to me like a good solution. Not
even if you have good reasons for your likes/dislikes.

If I ported some Linux program to Windows I would not ask
the user if they wanted to save to /dev/hda5, or /mnt/c_drive
because I consider C: bad naming.

-- 
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
>> Joerg Schilling wrote:
>>> Lee Revell <rlrevell@joe-job.com> wrote:
>>>
>>>
>>>>> Interesting: You claim that the Linux platform provides ways to retrieve 
>>>>> the needed information on FreeBSD, MS-WIN, ....?
>>>>>
>>>> What do FreeBSD and MS-WIN have to do with Linux?
>>>
>>> What is the relevence of /dev/hd* for a device independent library like libscg?
>>>
>> Isn't it good practice to adhere to the naming conventions
>> of the system to which a program is ported to? (even if 100
>> of them do it one way and 1 does it another)
> 
> Well, the problem is that (in special if you include the ATAPI tape drives)
> Linux likes to enforce inapropriate naming conventions.

Nope. Naming conventions are not subject here.

What OTHER libscg operations do not work for a particular ATAPI tape drive?
-scanbus does NOT count, don't mention it.
What is the drive manufacturer and type?
What is the failing or inaccessible operation?

Please remember to remove Jens Axboe and Lee Revell from the Cc: list!

Re: CD writing in future Linux (stirring up a hornets' nest)

[grundig]

El Thu, 26 Jan 2006 10:38:23 +0100,
Joerg Schilling <schilling@fokus.fraunhofer.de> escribió:

> > > It serves the need of GUI programs for cdrercord and allows them to retrieve 
> > > and list possible drives of interest in a platform independent way.
> >
> > But this is not neccesary at all, since linux platform already provides ways to
> > retrieve and list possible drives....
> 
> Interesting: You claim that the Linux platform provides ways to retrieve 
> the needed information on FreeBSD, MS-WIN, ....?


No. I claim that linux does have ways of retrieving the needed information.

You can keep providing your own solution on freebsd, win & friends if
you want, but _why_ do you want to do it in linux when linux can do it
by itself?? There's no reason why cdrecord should care about duplicating
existing functionality when the platform can provide that functionality
for free. Let cdrecord (name it libscg) use SG_IO and let users use
the /dev/hd*.

The case of cdrecord remembers me of X.org, which used/is poking /dev/mem
directly to discover PCI devices and/or play with framebuffers instead of
using the available APIs in linux. Except that the X.org people wants to
solve (or has already solved) such problems using the native available
APIS instead of keeping their own solutions. Well-written cross-platform
software implements all the features when needed by all the platforms as
a whole but only uses such features when a particular platform needs it,
unless using one of those features is a nightmare (which is not the
case of SG_IO IMHO)

Re: CD writing in future Linux (stirring up a hornets' nest)

[Tomasz Torcz]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Wed, Jan 25, 2006 at 06:03:18PM +0100, Joerg Schilling wrote:
> Jens Axboe <axboe@suse.de> wrote:
> 
> > You just want the device naming to reflect that. The user should not
> > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> > likely be using k3b or something graphical though, and just click on his
> > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> > help do this dynamically even.
> 
> Guess why cdrecord -scanbus is needed.
> 
> It serves the need of GUI programs for cdrercord and allows them to retrieve 
> and list possible drives of interest in a platform independent way.

  GUI programs tend to retrieve this kind of info form HAL
(http://freedesktop.org/wiki/Software_2fhal)

-- 
Tomasz Torcz                "Funeral in the morning, IDE hacking
zdzichu@irc.-nie.spam-.pl    in the afternoon and evening." - Alan Cox


[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Tomasz Torcz <zdzichu@irc.pl> wrote:

> > > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> > > likely be using k3b or something graphical though, and just click on his
> > > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> > > help do this dynamically even.
> > 
> > Guess why cdrecord -scanbus is needed.
> > 
> > It serves the need of GUI programs for cdrercord and allows them to retrieve 
> > and list possible drives of interest in a platform independent way.
>
>   GUI programs tend to retrieve this kind of info form HAL
> (http://freedesktop.org/wiki/Software_2fhal)

I am not sure what you like to tell with this.

Programs that depend on specific Linux behavior tend to be non-portable (see 
e.g. nautilus on GNOME). Nautilus tries to get e.g. the drive write speeds
by reading /prov/scsi/******. Besides the fact that this is not available 
elsewhere, it gives incorrect results because there are a lot of DVD writers 
with broken firmware.

Cdrecord implements workarounds for this kind of problems and for this reason, 
the most portable solution for a GUI is to use cdrecord to retrieve the 
information.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Tomasz Torcz]

On Thu, Jan 26, 2006 at 11:25:49AM +0100, Joerg Schilling wrote:
> Tomasz Torcz <zdzichu@irc.pl> wrote:
> 
> > > > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> > > > likely be using k3b or something graphical though, and just click on his
> > > > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> > > > help do this dynamically even.
> > > 
> > > Guess why cdrecord -scanbus is needed.
> > > 
> > > It serves the need of GUI programs for cdrercord and allows them to retrieve 
> > > and list possible drives of interest in a platform independent way.
> >
> >   GUI programs tend to retrieve this kind of info form HAL
> > (http://freedesktop.org/wiki/Software_2fhal)
> 
> I am not sure what you like to tell with this.
> 
> Programs that depend on specific Linux behavior tend to be non-portable (see 
> e.g. nautilus on GNOME). Nautilus tries to get e.g. the drive write speeds
> by reading /prov/scsi/******. Besides the fact that this is not available 
> elsewhere, it gives incorrect results because there are a lot of DVD writers 
> with broken firmware.

  This is a fallback if HAL isn't available.  Normally this is done by:

drive->max_speed_write = libhal_device_get_property_int
                                (ctx, device_names [i],
                                 "storage.cdrom.write_speed",
                                 NULL)
                                / CD_ROM_SPEED;

 (natilus-burn-drive.c:1368 from version 2.12.0).

> Cdrecord implements workarounds for this kind of problems and for this reason, 
> the most portable solution for a GUI is to use cdrecord to retrieve the 
> information.

  Yeah, sure.
                  /* FIXME we don't have any way to guess the real device
                   * from the info we get from CDRecord */

 (the only FIXME in above mentioned file).

-- 
Tomasz Torcz                                                       72->|   80->|
zdzichu@irc.-nie.spam-.pl                                          72->|   80->|

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Tomasz Torcz <zdzichu@irc.pl> wrote:

>   This is a fallback if HAL isn't available.  Normally this is done by:
>
> drive->max_speed_write = libhal_device_get_property_int
>                                 (ctx, device_names [i],
>                                  "storage.cdrom.write_speed",
>                                  NULL)
>                                 / CD_ROM_SPEED;
>
>  (natilus-burn-drive.c:1368 from version 2.12.0).

Even if this works under good conditions, it will fail in many cases 
because the related software is not up to date with recent device formware bugs.
Cdrecord is kept up to date as it either deals with a new drive or not.

Delegating things to other instances only works ar long as there are clean ans 
stable interfaces. This unfortunately does not apply to CD/DVD/HD-DVD.

> > Cdrecord implements workarounds for this kind of problems and for this reason, 
> > the most portable solution for a GUI is to use cdrecord to retrieve the 
> > information.
>
>   Yeah, sure.
>                   /* FIXME we don't have any way to guess the real device
>                    * from the info we get from CDRecord */
>
>  (the only FIXME in above mentioned file).

And guess why Sun is currently working on a work around this nautilus problem.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[jerome lacoste]

On 1/25/06, Jens Axboe <axboe@suse.de> wrote:
> On Wed, Jan 25 2006, Jan Engelhardt wrote:
> >
> > >
> > >- you don't need -scanbus. If
> > >users think they do, it's either because Joerg brain washed them or
> > >because they have been used to that bad interface since years ago when
> > >it was unfortunately needed.
> >
> > Now you're unfair.
> > -scanbus does a nice output of what cdwriters (and other capable devices)
> > are present. For me, that lists the cd writer and a CF slot from the
> > multitype usb flash reader.
> >
> > There's one kind of not-so-advanced linux newbies that just go to walmart,
> > buy a computer and whack a linux system on it for fun, and they still don't
> > know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is
> > usually a nightmare for them, and apart that -scanbus lists scsi
> > host,id,lun instead of /dev/hd* (don't comment on this kthx), it is
> > convenient for this sort of users to find out what's available.
> >
> > So, and what about that compactflash reader? It is subject to dynamic
> > usb->scsi device association (depending on when you connect it, it may
> > either become sda, or sdb, or sdc, etc.), and -scanbus yet again provides
> > some way (albeit not useful, because it lists scsi,id,lun rather than
> > /dev/sd* - don't comment either) to see where it actually is.
>
> You just want the device naming to reflect that. The user should not
> need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> likely be using k3b or something graphical though, and just click on his
> Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> help do this dynamically even.
>
> If you are using cdrecord on the command line, you are by definition an
> advanced user and know how to find out where that writer is.
>
> --
> Jens Axboe

As an non expert who just wants his boxes to work out of the box, I
feel that the above message best represents the issue at end.



Joerg seems to be concerned by 2 things:
- the portability of his application accross various platforms
- provide an end-to-end application for writing CDs from both the
command line and to various 3rd party front ends.

Providing a cross platform way to reference the devices seems to help
him achieve that goal.


Linux developers seem to see the world in a different way. Their main
requirements:
- compliance with the linux way of doing things
- ultimately a front end should hide all the dirty details. That
doesn't mean a command line version has to hide them as well, nor that
cdrecord should be the interface to ask things the operating system
can provide

So it looks like:
- from a cdrecord point ov view, Linux is broken.
- from a Linux developers point of view, cdrecord is doing too much
and forces things up.



<very naively>

As a developper with absolutely no competence in this area, I wonder
something: I don't see why the way to refer to a device affects the
ability to perform the functionality (write to it).

Isn't it possible to reorganize the code in such a way that the
burning part can be independent of the way the devices are referred
to?

I downloaded the code and quickly looked at it. If I am looking at the
right version, it seems that the cdrecord code that relates to both cd
burning + the Linux specific part is not that big (and very readable,
thanks Joerg). So I really don't understand why this issue doesn't get
fixed.

</very naively>



As with the communication problems between Joerg and the Linux
developers, if someone was stepping up to be the bridge betweem the 2
parties, couldn't that minimize the risk of flame wars?

cdrecord, how important is Linux to you?
Linux, how important is cdrecord to you?

If you 2 can't get along, just divorce! It's 2006 after all. And the
code is open.
Otherwise, talk together or use a counsellor and make this relationship work.

Jerome

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

jerome lacoste <jerome.lacoste@gmail.com> wrote:


> Joerg seems to be concerned by 2 things:
> - the portability of his application accross various platforms
> - provide an end-to-end application for writing CDs from both the
> command line and to various 3rd party front ends.

> Providing a cross platform way to reference the devices seems to help
> him achieve that goal.

Correct.



> Linux developers seem to see the world in a different way. Their main
> requirements:
> - compliance with the linux way of doing things

Which is unfortunately (in contrary to what cdrecord does) a moving target.

> - ultimately a front end should hide all the dirty details. That
> doesn't mean a command line version has to hide them as well, nor that
> cdrecord should be the interface to ask things the operating system
> can provide

The best way of making a GUI portable is by making the underlying command line 
application portable and using the same CLI for every OS.


> So it looks like:
> - from a cdrecord point ov view, Linux is broken.
> - from a Linux developers point of view, cdrecord is doing too much
> and forces things up.

BTW: There are still many people who run Linux-2.2 and many people told me that
they will probably never upgrade from 2.4 to 2.6.

On Linux-2.4, cdrecord's abstraction is the only way to hide the security 
relevent non-stable /dev/sg* <-> device relation.


> <very naively>
>
> As a developper with absolutely no competence in this area, I wonder
> something: I don't see why the way to refer to a device affects the
> ability to perform the functionality (write to it).
>
> Isn't it possible to reorganize the code in such a way that the
> burning part can be independent of the way the devices are referred
> to?

This is what cdrecord does!

Cdrecord uses the OS and transport independent libscg/

> I downloaded the code and quickly looked at it. If I am looking at the
> right version, it seems that the cdrecord code that relates to both cd
> burning + the Linux specific part is not that big (and very readable,
> thanks Joerg). So I really don't understand why this issue doesn't get
> fixed.
>
> </very naively>

I was never talking about cdrecord in special here but rather talkign about
libscg which does not only deal with CD/DVD-writers but with any (even unknown) 
kind of SCSI devices.

The real problen with many people on this list is that they ague in a way that 
might be correct in case that cdrecord would not use a anstracting library as 
libscg. In that case, some of the arguments may ne right....but we need to talk 
abut a generic SCSI transport - independent from the SCSI device type and from 
the SCSI transport that is used for that device.


> cdrecord, how important is Linux to you?

Linux was important between 1996 and ~ 2000. In that time, I got a lot of 
really exciting and valuable feedback from various kernel developers and 
in that time, Linux was the only way to use CD/DVD-writers with strange exotic 
transport interfaces.

But the times are changing. During the past few years, some Linux kernel 
developers started a rather aggressive campaign against crecord and Linux did 
become less usable for CD/DVD writing than it has been before.

Meanwhile other OS did step into the right direction. FreeBSD and Solaris added 
support for other SCSI transports and I now recommend to use FreeBSd or Solaris 
because things are a lot smoother on these OS.

As an example: USB on Solaris is a lot more stable than on Linux. Timeout 
problems to not appear, I have been able to connect and mount my Nikon D70
out of the box on Solaris 9 (from November 2002) while Linux does not even see 
the camera on USB. Solaris has a device cache for removable media and offers 
stable /dev/* entries and stable major/minor numbers for hot plugged USB and 
other devices while Linux happyli creates new device entries for every reconnect. 

Discussions with FreeBSD and Solaris people are always friutful because these 
discussions stay technical. Solaris did fix all remaining issues with CD/DVD 
writing during the past 2 years and Solaris now is the free OS where CD/DVD 
writing works most smoothly.

It seems that cdrecord does not need Linux anymore. Does Linux need cdrecord?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares]

Hello!

> > Linux developers seem to see the world in a different way. Their main
> > requirements:
> > - compliance with the linux way of doing things
> 
> Which is unfortunately (in contrary to what cdrecord does) a moving target.

Which is *fortunately* a moving target, because what served well 20 years
ago is unlikely to serve equally well *now*.

Having a stable naming of devices is a good goal, but in no way restricted
to SCSI-like devices. What you suggest works only there, what Linux currently
uses (udev etc.) works for all devices. Guess which is better for most users.

> BTW: There are still many people who run Linux-2.2 and many people told me that
> they will probably never upgrade from 2.4 to 2.6.

Fine, so feel free consider Linux <2.6 and Linux 2.6 two completely
separate operating systems. I did the same with the IP stack interface
in the BIRD project and I consider it a very good step -- the old
interface provided by Linux 2.0 and cluttered with BSD compatibility is
almost unusable when compared to Netlink, but for sake of users who
don't want to upgrade their kernel, BIRD is able to use the old one,
though with limited functionality.

> On Linux-2.4, cdrecord's abstraction is the only way to hide the security 
> relevent non-stable /dev/sg* <-> device relation.

OK. So welcome to year 2006. And to Linux 2.6.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
How do I type 'for i in *.dvi ; do xdvi $i ; done' in a GUI?

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Martin Mares <mj@ucw.cz> wrote:

> > On Linux-2.4, cdrecord's abstraction is the only way to hide the security 
> > relevent non-stable /dev/sg* <-> device relation.
>
> OK. So welcome to year 2006. And to Linux 2.6.

When will Linux arrive in 2006 and support ATAPI and SCSI in general, not just 
ATAPI for hard disk drives and CD-ROMS?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jan Engelhardt]

>You just want the device naming to reflect that. The user should not
>need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
>likely be using k3b or something graphical though, and just click on his
>Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
>help do this dynamically even.

And if you have multiple cdwriters? Then (cf. other posts) one has 
/dev/cdrecorder0 /dev/cdrecrder1, etc. To me, that's just as bad as having 
/dev/sg0 and /dev/sg1, because you don't have a clue at first sight what it 
maps to.

"ls -l"? Sure, if cdrecorder0 was a symlink, but it does not work when it's 
not (= a block device in essence then).
And I'm sure there's an analog program to "ls" to find what sg0 maps to.


>If you are using cdrecord on the command line, you are by definition an
>advanced user and know how to find out where that writer is.

And GUIs could use arbitrary names like S:I:L. Ugly, but as long as it 
works... sigh.



Jan Engelhardt
-- 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Jens Axboe]

On Thu, Jan 26 2006, Jan Engelhardt wrote:
> 
> >You just want the device naming to reflect that. The user should not
> >need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
> >likely be using k3b or something graphical though, and just click on his
> >Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
> >help do this dynamically even.
> 
> And if you have multiple cdwriters? Then (cf. other posts) one has 
> /dev/cdrecorder0 /dev/cdrecrder1, etc. To me, that's just as bad as having 
> /dev/sg0 and /dev/sg1, because you don't have a clue at first sight what it 
> maps to.

/dev/plextorwriter and /dev/hpwriter or whatever, it's just naming.

> "ls -l"? Sure, if cdrecorder0 was a symlink, but it does not work when it's 
> not (= a block device in essence then).
> And I'm sure there's an analog program to "ls" to find what sg0 maps to.

You expect the gui user to follow symlinks to find out?


-- 
Jens Axboe

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

Jens Axboe wrote:
> On Thu, Jan 26 2006, Jan Engelhardt wrote:
> 
>>>You just want the device naming to reflect that. The user should not
>>>need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
>>>likely be using k3b or something graphical though, and just click on his
>>>Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
>>>help do this dynamically even.
>>
>>And if you have multiple cdwriters? Then (cf. other posts) one has 
>>/dev/cdrecorder0 /dev/cdrecrder1, etc. To me, that's just as bad as having 
>>/dev/sg0 and /dev/sg1, because you don't have a clue at first sight what it 
>>maps to.
> 
> 
> /dev/plextorwriter and /dev/hpwriter or whatever, it's just naming.
> 
> 
>>"ls -l"? Sure, if cdrecorder0 was a symlink, but it does not work when it's 
>>not (= a block device in essence then).
>>And I'm sure there's an analog program to "ls" to find what sg0 maps to.
> 
> 
> You expect the gui user to follow symlinks to find out?
> 
As opposed to? That's not a rhetorical question, please don't blow it 
off, what is the way for a user to go from /dev/sg0 to find out what 
device is really there?

What is not easily available in Linux is a nice single place to find out 
what mass storage (disk/optical/floppy/ZIP/LS120/tape) devices are on 
the system, and what the system calls them. Because for low tech users 
udev is the problem, not the solution. The user doesn't want to tell the 
system what to call the device, he wants to see what's there, and that 
includes serial numbers of drives (where available) because if a user 
has several drives it's likely that they are identical.

Telling the users to "cat /proc/scsi/scsi" and
  for n in /proc/ide/hd?; do echo -n "$n: "; cat $n/model; done
is not a substitute for a presentation useful to programs and people 
alike. It could be in /proc or /sys or wherever is flavor of the day, 
but it would sure make things easier for the users. And before someone 
suggests that a program could generate this, a program would constantly 
chase the changing presentation of the information, a documented "file" 
in /proc or /sys would allow all applications to look in one place for 
the information.

Instead of having the user tell the system what to call a device, let 
the system tell the user what it is called. Then the kernel could change 
without breaking anything in application land.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: CD writing in future Linux (stirring up a hornets' nest)

[Kyle Moffett]

On Jan 30, 2006, at 17:52, Bill Davidsen wrote:
> What is not easily available in Linux is a nice single place to  
> find out what mass storage (disk/optical/floppy/ZIP/LS120/tape)  
> devices are on the system, and what the system calls them.

Yes it is available, and a whole slew of GUI applications use it.   
It's called "hal", or Hardware Abstraction Layer, and it has small  
hooks into udev and a bit of sysfs code so that it has a list of all  
devices of various types and knows what their associated udev-created  
device nodes are.  This means that I can configure udev to put my CD  
drive on /dev/burner and correctly written GUI programs will just  
find it and work.

> Because for low tech users udev is the problem, not the solution.  
> The user doesn't want to tell the system what to call the device,  
> he wants to see what's there, and that includes serial numbers of  
> drives (where available) because if a user has several drives it's  
> likely that they are identical.

Your average low-tech user installing stock Debian (Not even  
something targeted at user-friendliness like Ubuntu), will end up  
with udev/hal installed.  When he plugs in his burner, it will get  
the name /dev/cdrom[0-9] behind the scenes, and hal will notice.   
When he starts up k3b, it will use hal and automatically notice his  
drive, showing him brand, serial number, etc.

> Instead of having the user tell the system what to call a device,  
> let the system tell the user what it is called.

Uhh, both happen.  The system tells userspace "I just got/have a  
device with brand 'foo', specs 'bar', serial 'baz', etc".  Userspace  
(behind the scenes, without your low-tech user caring) creates a  
device node "/dev/cdrom[0-9]" and alerts hal, which sends it to your  
application, which nicely alerts the user.  As an admin who does a  
lot on the command line, I can tie certain drive serial numbers to / 
dev/blue_burner and /dev/red_burner for my own ease-of-command-line- 
use without breaking the aforementioned hal system.

Cheers,
Kyle Moffett

--
I have yet to see any problem, however complicated, which, when you  
looked at it in the right way, did not become still more complicated.
   -- Poul Anderson

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bill Davidsen]

Kyle Moffett wrote:

> On Jan 30, 2006, at 17:52, Bill Davidsen wrote:
>
>> What is not easily available in Linux is a nice single place to  find 
>> out what mass storage (disk/optical/floppy/ZIP/LS120/tape)  devices 
>> are on the system, and what the system calls them.
>
>
> Yes it is available, and a whole slew of GUI applications use it.   
> It's called "hal", or Hardware Abstraction Layer, and it has small  
> hooks into udev and a bit of sysfs code so that it has a list of all  
> devices of various types and knows what their associated udev-created  
> device nodes are.  This means that I can configure udev to put my CD  
> drive on /dev/burner and correctly written GUI programs will just  
> find it and work.

I was really talking about something stable. HAL is an application, and 
as such has to be changed avery time some developer has a bad dream and 
changes the interface, moves a comtrol or report from /proc to /sys, or 
otherwise requires a new way of interpreting the data. If you will, HAL 
*in* the kernel where it must work.

> -- 
> I have yet to see any problem, however complicated, which, when you  
> looked at it in the right way, did not become still more complicated.
>   -- Poul Anderson

-- 

bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert]

On Thu, Feb 16, 2006 at 11:20:02AM -0500, Bill Davidsen wrote:
> I was really talking about something stable. HAL is an application, and 
> as such has to be changed avery time some developer has a bad dream and 
> changes the interface, moves a comtrol or report from /proc to /sys, or 
> otherwise requires a new way of interpreting the data. If you will, HAL 
> *in* the kernel where it must work.

Sorry, the era of stability is over.  Anything older than a year and
half or so is obsolete and should be upgraded.  To their honor Linus,
Andrew and a small minority of others tried to keep stability as
important, but given that the vast majority of the other developpers
don't care they lost.

For the kernel that means syscalls are stable, but everything
filesystem isn't (proc and sysfs in particular) and change on a whim,
and also ioctls, especially on vonluntarily undocumented kernel
interfaces, are rather unstable.

  OG.

Re: CD writing in future Linux (stirring up a hornets' nest)

[are added/removed - which]

El Wed, 25 Jan 2006 16:13:46 +0100 (MET),
Jan Engelhardt <jengelh@linux01.gwdg.de> escribió:

> There's one kind of not-so-advanced linux newbies that just go to walmart, 
> buy a computer and whack a linux system on it for fun, and they still don't 
> know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is 
> usually a nightmare for them, and apart that -scanbus lists scsi 
> host,id,lun instead of /dev/hd* (don't comment on this kthx), it is 
> convenient for this sort of users to find out what's available.

Wait - Looking at dmesg is a nightmare for newbies, but cdrecord -scanbus
is not?

Users should be show the available devices in a pretty GUI and for that to
be possible, the kernel needs to provide a unified way to show userspace
the available devices and notify them when they are added/removed - which
happens to be sysfs + udev etc.

libscg seems to want to replace the operative system for some tasks
in the name of cross-platform compatibility. Sorry, but libscg is
not the center of the world. It's fine that cdrecord does what
it does for the apps for all those platforms where -scanbus and friends
has sense, but linux just has SG_IO. libscg wanting to offer access
to the "transport layer below /dev/hd*" looks like a  layering design
violation in operative systems like linux, but it is fine that cdrecord
has it because it _is_ neccesary in other operative system which do
things differently. 

Using the native features of a platform is a Good Thing when writing
cross-platform software, ie: glib provides a "threading emulation" where
threads are not available, but it uses the native pthreads if it's
available. libscg wants to do everything everywhere, and that'd have
sense if SG_IO weren't able to do what cdrecord needs, but AFAIK from the
multiple flamewars I've seen, SG_IO does everything that cdrecord
needs. I've not had a problem with SG_IO in years...

Re: CD writing in future Linux (stirring up a hornets' nest)

[Heikki Orsila]

Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> People like to run cdrecord -scanbus in order to find a list of usable 
> devices. People like to see all SCSI devices in a single name space as 
> they are all using the same protocol for communication.

Not me. I would just like to see a list of /dev/name entries, rather 
than know anything about scsi. Better yet, I wouldn't want to know 
anything about the devices. It should just work.

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: CD writing in future Linux (stirring up a hornets' nest)

[Robert Hancock]

Joerg Schilling wrote:
> People like to run cdrecord -scanbus in order to find a list of usable devices.
> People like to see all SCSI devices in a single name space as they are all 
> using the same protocol for communication.

Except that the majority of CD writers today are NOT SCSI devices. They 
may use the MMC command set from SCSI for interface purposes, but they 
are on an ATA or USB bus. cdrecord tries to fabricate some kind of 
device numbering assigning SCSI-like bus and LUN numbers for the devices 
when such a numbering has no basis in any kind of reality.

We have all SCSI devices in a single namespace, that is what /dev is 
for. That is the name that the system/kernel provides for applications 
to use, and that is what the application should use, not some kind of 
bizarre invented numbering scheme built on top of that.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bodo Eggert]

Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

>> It's shorter than /dev/c0t0d0s0? Well, I think it's because people think
>> in terms of connectors (my drive is IDE therefore it must be hdc) rather
>> than protocol (my drive does ATAPI therefore it must be
>> /dev/scsi/c0t0d0s0).
> 
> Is there any reason why the people with small PCs should dominate the
> people with big machines?
> 
> If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks.

So you'll create a symlink. (If you're Ingvar Kamprad, it will be named bjørn.)

> The systematical attempt is easy to remember even with a big amount of
> external hardware.

If you
- add a SCSI controler
- add an USB burner
- connect to an aoe/iscsi-device(?),
it will get a random ID. If you reboot (or just plug out/plug in), it will
be randomly different. The same thing may happen after a system upgrade,
possibly depending on the linker.

In these cases, there is nothing you can remember, and you'll have to run
-scanbus in order to find out if your burner is 0.8.15 or maybe 32.16.8
_each_ time you want to burn a CD. But you _can_ remember (or write into
your config files) that it will be named /udev/cdr/LITE-ON_LTR-48246K.

Having to find out the magic number of the day is usurally worse than
using the very same name you usurally use to identify an object. If you
see an advantage, let the ATAPI bus be -3, translate -3,$n,0.0 to
"/dev/hd".chr(96+$n) and everybody will be happy.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:

> If you
> - add a SCSI controler
> - add an USB burner
> - connect to an aoe/iscsi-device(?),
> it will get a random ID. If you reboot (or just plug out/plug in), it will
> be randomly different. The same thing may happen after a system upgrade,
> possibly depending on the linker.

This is a limitation of the implementation used on Linux and not true for e.g. 
Solaris.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-03:

> This is a limitation of the implementation used on Linux and not true for e.g. 
> Solaris.

Linux is not Solaris.

Do you want your application to work with Linux,
because it brings customers?

If yes, listen to kernel developers if they say "you don't need that
feature". Note I do not consider myself kernel developer. I'm a
bystander who's trying to help out.

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> Joerg Schilling schrieb am 2006-02-03:
>
> > This is a limitation of the implementation used on Linux and not true for e.g. 
> > Solaris.
>
> Linux is not Solaris.
>
> Do you want your application to work with Linux,
> because it brings customers?
>
> If yes, listen to kernel developers if they say "you don't need that
> feature". Note I do not consider myself kernel developer. I'm a
> bystander who's trying to help out.

????

Kernel developers should listen to the right application developers
(in special when they may have more kernel skills) to find out
what's needed.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[René Rebe]

Hi,

On Monday 06 February 2006 15:46, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > Joerg Schilling schrieb am 2006-02-03:
> >
> > > This is a limitation of the implementation used on Linux and not true for e.g. 
> > > Solaris.
> >
> > Linux is not Solaris.
> >
> > Do you want your application to work with Linux,
> > because it brings customers?
> >
> > If yes, listen to kernel developers if they say "you don't need that
> > feature". Note I do not consider myself kernel developer. I'm a
> > bystander who's trying to help out.
> 
> ????
> 
> Kernel developers should listen to the right application developers

Yes, to the _right_ ones. You are soo right.

> (in special when they may have more kernel skills) to find out
> what's needed.

...

Have a nice day,

-- 
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 (stirring up a hornets' nest)

[Bodo Eggert]

On Mon, 6 Feb 2006, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> > Joerg Schilling schrieb am 2006-02-03:

> > > This is a limitation of the implementation used on Linux and not true for e.g. 
> > > Solaris.
> >
> > Linux is not Solaris.
> >
> > Do you want your application to work with Linux,
> > because it brings customers?
> >
> > If yes, listen to kernel developers if they say "you don't need that
> > feature". Note I do not consider myself kernel developer. I'm a
> > bystander who's trying to help out.
> 
> ????
> 
> Kernel developers should listen to the right application developers
> (in special when they may have more kernel skills) to find out
> what's needed.

>From what I read, you need a way to map a short ID (possibly formed like 
\mathbb{N}^4) to a (devicename, ID')-tupel, where ID' may be ID, a dummy 
value or something completely different.


With the old /dev/sg-scheme, you had a hard time assigning 
/dev/sg_num_of_the_day to a device, and you had to enqure each for the ID 
in order to at least give a stable name. Obviously this was bad, therefore 
it was superseded by the current method, making /dev/sg obsolete. It is 
still supported, but nobody will enheance it to include IDE.


With the current mechanism, you can assign a user-defined name like
/dev/scsi/host1/bus2/id3/lun4/cd, /dev/scsi/1.2.3.4, /dev/bjørn or
/dev/cdr/vendor_model. Obviously some are hard to type, and some are 
designed to be typed by the user. In the later case, the user should be 
allowed to use these names even if it isn't portable, and in the 
former cases, having a nice thing.

For systems using /dev/scsi/1.2.3.4 etc., you can enumerate all devices by
walking a list of paths and trying each device in turn, and you can find
the device node using a regular expression.

On systems using /dev/cdr/vendor_model or /dev/bjørn, you can't list all 
devices yourself, but maybe you can exec a user-defined program doing this 
work for you. In order to find the device again, you can either make the  
list be (device node, ID), or define a reverse switch giving you just the 
device node. I'd prefer the later, since that'd let you handle device 
names containing spaces.

I'd use a script for both cases, and since many systems will use the 
numeric scheme, maybe provide a default script for them. If the user or 
the distribution doesn't use numeric IDs, they can create their own 
script. (Off cause you'll still need the sg-scanning for 2.4 kernels).


Example for my system, obviously slightly untested:

---/etc/default/cdrecord:---
#aliases
toshiba TOSHIBA_XM-6201TA -1 -1
liteon  LITE-ON_LTR-48246K 40 16m
apple   MATSHITA_CR-8004 -1 -1

CDR_DEVICE      = LITE-ON_LTR-48246K
enumerate_devices_bin = /usr/lib/cdrecord-scandevices.sh
---

---/usr/lib/cdrecord-scandevices.sh---
#!/bin/sh
if [ "$1" == "-r" ]; then # reverse mapping
	exec /usr/bin/find /dev/cd{,r} -follow -name "$2"
else
	exec /usr/bin/find /dev/cd{,r} -follow -type b -printf "%f\n"
fi
---

---default script---
#!/bin/sh

if [ "$1" == "-r" ]; then # reverse mapping
	case "$2" in
	-1.* )  a="`echo "$2"|sed -e \
's,\(.*\)\.\(.*\)\.\(.*\)\.\(.*\),.*[^0-9]\2[^0-9]+\3[^0-9]*,'`"
		/usr/bin/find /dev/ide/ -regex "$a" -type b
	;;
	*)      a="`echo "$2"|sed -e \
's,\(.*\)\.\(.*\)\.\(.*\)\.\(.*\),.*[^0-9]\1[^0-9]+\2[^0-9]+\3[^0-9]+\4[^0-9]*,'`"
		/usr/bin/find /dev/scsi/ -regex "$a" -type b
	;;
	esac
else
	/usr/bin/find /dev/ide/ -type b \! -regex '.*part[0-9]+' \
	| sed -e \
's/[^0-9]/./g;s/\.\.*/\./g;s/^\.*//;s/\.*$//;s/^/-1./;s/$/.0/'

	/usr/bin/find /dev/scsi/ \! -regex '.*part[0-9]+' -type b \
	| sed -e 's/[^0-9]/./g;s/\.\.*/\./g;s/^\.*//;s/\.*$//'
fi
---

-- 
One enemy soldier is never enough, but two is entirely too many. 

Re: CD writing in future Linux (stirring up a hornets' nest)

[Matthias Andree]

Joerg Schilling schrieb am 2006-02-06:

> Kernel developers should listen to the right application developers
> (in special when they may have more kernel skills) to find out
> what's needed.

Your skills are misrepresenting facts, ignoring uncomfortable questions,
and shifting the blame you have to take on others. These are skills that
make you belong to the "wrong" application developers that a kernel
developer will not listen to. You demand cooperation, but you only see
it as cooperation if people do as _you_ say. You put up artificial
limits in your applications to "prove" some kernel is wrong.

Is there anyone who does not see this as some kind of campaign of yours?

-- 
Matthias Andree

Re: CD writing in future Linux (stirring up a hornets' nest)

[Zoltan Boszormenyi]

Hi!

>DervishD <lkml@dervishd.net> wrote:
>
>>     Could you please clarify which things are broken by Matthias
>> patch? This way he (or other developer) can prepare a better patch
>> and maintain it. BTW, I patched my cdrecord with Matthias patch and
>> nothing seems to be broken :? Maybe am I missing something?
>
>It is completely broken and thus makes no sense at all.
>
>As I did write it looks lie a dentist drills a hole into an aking tooth
>and then claims to be complete with the whole treatment.
>
>Jörg
>  
>

It is a nicely written metaphor but hardly qualifies as  a technical 
argument.
Sorry, -1 point for you for being such a bully. You obviously didn't look at
Matthias' patch, you even expressed unwillingness to look at it.
I would be _very_ surprised if at the end you actually read or
(oh, the horror!) test it.

I have followed every such threads that ended in a flamefest.

Folks, please, cdrecord is GPL, at least up to 2.01.01a06.
Take this version and ask for help from the wizards at forum.rpc1.org
in forking. They drink, eat and breath CD-R[W] and DVD+-R[W] firmwares,
they surely know vendor commands, they must be able to understand
Jörg's software and maybe improve upon it. They can validate the
ossdvd patch, and fix it if it's buggy. For those who don't know,
there even exists a firmware updater for Pioneer DVD+-RW
drives that work on Linux with /dev entries, on a live system,
without the need for a reboot... http://lasvegas.rpc1.org/
Look, Jörg, they don't need HOST/TARGET/LUN triplets for this task!

Best regards,
Zoltán Böszörményi

Re: CD writing in future Linux (stirring up a hornets' nest)

[Sam Vilain]

Zoltan Boszormenyi wrote:
> Folks, please, cdrecord is GPL, at least up to 2.01.01a06.
> Take this version and ask for help from the wizards at forum.rpc1.org
> in forking. They drink, eat and breath CD-R[W] and DVD+-R[W] firmwares,
> they surely know vendor commands, they must be able to understand
> Jörg's software and maybe improve upon it. They can validate the
> ossdvd patch, and fix it if it's buggy. For those who don't know,
> there even exists a firmware updater for Pioneer DVD+-RW
> drives that work on Linux with /dev entries, on a live system,
> without the need for a reboot... http://lasvegas.rpc1.org/

This sounds like a sensible idea.

I honestly don't understand why people let themselves get all worked up
and spend so much energy on someone who's clearly diverging in their
ideals from the spirit of the community.  I also don't know why they
think they have a right to demand things of a volunteer in the first
place.

The only difference between this troll and any other troll is that the
troll is the original author and copyright holder, but he appears to
have stepped down as a Free Software author.

Why spend effort on trolls when you can instead branch/fork the code
base and spend that effort productively?

Sam.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Sorry for crippled Cc I'm answering off web archive]

> Joerg Schilling schrieb am 2006-02-09:
> > DervishD <lkml@dervishd.net> wrote:
> > > other half doesn't have it probably has a bad user interface. You
> > > know that if a program uses a naming convention different from ALL
> > > the rest of programs is because the program has a problem. You know
> > > that if the only UNIX program out there that doesn't use /dev entries
> > > to talk to devices is cdrecord, the problem *probably* is in
> > > cdrecord, and not in UNIX...
> >
> > So why do you like to introduce a different naming scheme?
>
> It is striking that Jіrg Schilling's code alone uses this naming scheme,
> and nothing else appears to be. If there is, perhaps naming a few
> typical real-world applications could enlighten us. You haven't
> mentioned examples yet, so there isn't even a faint hint cdrecord is
> consistent with the so-called real-world.

Legato Networker (now belongs to EMC) is using the same enumeration scheme to 
access media changer (but not the drivers themselves). In this case I can 
speak for Solaris, Windows and Linux. I must admit I would have preferred to 
use something like /dev/sgen on Solaris because even Networker documentation 
warns that adapter number that is shown by configuration bears no relation to 
adapter instance numbers as can be seen by user. So almost the only way to 
make sure you are speaking to correct physical device is to use inquire 
command and check device type and may be even serial number. The only 
consolation is that you usually do not have dozens of media changers 
connected ;)

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD7aeNR6LMutpd94wRAguxAJ97zFNUyinXEc7yQwqP7pgU+ZHQaACgsbti
eu6TLSAFR7KHVgUErhjaIZc=
=8J0V
-----END PGP SIGNATURE-----

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bodo Eggert]

Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:

>> > > Nonsense. The b,t,l addresses are NOT stable (at least for transports
>> > 
>> > Dou you like to verify that you have no clue on SCSI?
>>
>> How does, for instance, libscg make sure that the b,t,l mappings are
>> hotplug invariant?
>>
>> How does libscg make sure that two external writers, say USB, retain
>> their b,t,l mappings if both are unplugged and then replugged in reverse
>> order, perhaps into different USB hubs?
> 
> Well, this is a deficit of the Linux kernel - not libscg.
> 
> If you are unhappy with Hot plug support on Linux, I recommend you to
> check Solaris.

I see only support for 16*16*8=2048 devices in scsi-sun.c. Therefore you need
at most 2049 devices to have no possibility for stable device<->b,t,l
relation. Asume 2048 devices had been plugged into USB, so that you have the
mapping 0,0,0 -> yellow burner .. 15,15,7 -> purple burner. If you reuse any
of these IDs, also plugging in the corresponding device would result in a
non-stable ID. (One broken device with serial number = `dd if=/dev/random`
will do the trick, too.)

So if you can't create a stable mapping using b,t,l, why should you bother
trying and mislead your users into asuming a stable mapping? And why should
you impose a btl mapping if it's possible to allow naming the device whatever
the user likes, causing the number of stable device names to be limited only
by it's lifetime?

The only things you need is a list of devices and a way to map a unique ID
to a device name. I posted scripts that will so that.

-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: CD writing in future Linux (stirring up a hornets' nest)

[Joerg Schilling]

Anders Karlsson <trudheim@gmail.com> wrote:

> It would appear that every time someone pose a question, you are
> deliberately rude and avoid answering the question, yet when you ask a
> question, the entire list is supposed to stand to attention and follow
> you every little whim. My mother taught me a very good thing, when
> everyone else appear to be wrong - they probably are right. Remember
> where you are debating the issue Jörg. You are not on a Solaris
> mailing list now.

What would you do if you write things and a few minutes later someone
replies with something that either does not aply at all or is wrong?

This happens since 2 weeks now and I cannot see any progress.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: CD writing in future Linux (stirring up a hornets' nest)

[Anders Karlsson]

On Tue, 14 Feb 2006 19:13:19 -0000, Joerg Schilling  
<schilling@fokus.fraunhofer.de> wrote:

> Anders Karlsson <trudheim@gmail.com> wrote:
>
>> It would appear that every time someone pose a question, you are
>> deliberately rude and avoid answering the question, yet when you ask a
>> question, the entire list is supposed to stand to attention and follow
>> you every little whim. My mother taught me a very good thing, when
>> everyone else appear to be wrong - they probably are right. Remember
>> where you are debating the issue Jörg. You are not on a Solaris
>> mailing list now.
>
> What would you do if you write things and a few minutes later someone
> replies with something that either does not aply at all or is wrong?

The code I have written has mainly been Perl or shell script,
and while it is not used by tens of thousands of people around
the globe I have a few users that ask why I do things this way
or that way. I explain why, I encourage them to look at the
code and I *want* them to come with suggestions - because
*I will learn things if they do*.

cdrecord is a very useful tool, I have used it before, I will
probably use it again. However, people are pointing out quirks
in the user interface, they have offered patches, they have
offered to work on problems in the Linux kernel and yet you
insist that cdrecord/libscg is right and Linux users are wrong.
What people have asked here is no more and no less than that
you consider altering the user interface of cdrecord to take
the device-name of a writer instead of the BTL address. They
have even offered to do the work.

I am sure you are as sick of this debate as everyone else is.
If you were to just consider the proposals that has been made,
for a minute ignoring the past two weeks aggravation, I am sure
that you can see the merits of them. No-one is asking you to
accept anything and everything patch-like thrown your way. What
we are saying is that in modern Linux distributions, users access
devices through /dev/devicename - that limits confusion. So far,
the _only_ programs I have encountered that does not use devices
in /dev is SANE - and cdrecord.

> This happens since 2 weeks now and I cannot see any progress.

To be fair, I have been more than a little sarcastic in this
discussion. I apologise if that has offended you or anyone else.
If you are fair to yourself, you will look back over the
discussion, see how you have responded to people and you may
understand their reactions as well. There has been far to much
pride and hot-headedness in this discussion. Are we not all
supposed to be on the same side? F/OSS vs Big Bad Corporations?

How about we all calm down, admit our own failings and look at
how we all can compromise and get a solution that all can agree
on - without letting our own pride and egos get in the way?

Kind regards,

PS, sorry about the essay.

-- 
Anders Karlsson <anders@trudheim.com>
QA Engineer | GnuPG Key ID - 0x4B20601A