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?

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

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

[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: 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: 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?)

[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: 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?

[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: 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?)

[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: 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?

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

[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?)

[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: 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?

[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: 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)

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

[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: 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?

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

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: 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?)

[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) (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?)

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

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

[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) (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)

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

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

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

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

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

[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) (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?)

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

[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) (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?)

[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) (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?)

[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: 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) (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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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)

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

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

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

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

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

[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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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)

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

[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: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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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: 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)

[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: [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: 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)

[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: [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))

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

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

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

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

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]

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

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

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

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

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

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

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

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

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

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

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

[Michael Kerrisk]

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

[...]

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

[...]

A late follow-up to this thread. I've added the following text
to the mlockall() manual pag under BUGS:

    Since kernel 2.6.9, if a privileged process calls 
    mlockall(MCL_FUTURE) and later drops privileges
    (CAP_IPC_LOCK), then subsequent memory allocations
    (e.g., mmap(2), sbrk(2)) will fail if the 
    RLIMIT_MEMLOCK resource limit is encountered.
    
The change will be in man-pages 2.23.

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/, 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

Re: Rationale for RLIMIT_MEMLOCK?

[Bodo Eggert]

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

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

I think you should rather use the size you're going to mlock, or at least
the upper bound.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.