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
`
>
> 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).
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
> > > 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?
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
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....
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
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????
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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
Joerg Schilling schrieb am 2006-01-23:
> Matthias Andree <[email protected]> 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
On Mon, 2006-01-23 at 20:38 +0100, Joerg Schilling wrote:
> Matthias Andree <[email protected]> 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
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
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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
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
Lee Revell <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Lee Revell <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Mon, 2006-01-23 at 22:45 +0100, Joerg Schilling wrote:
> Lee Revell <[email protected]> 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
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-01-23:
> Matthias Andree <[email protected]> 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
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
> 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 :(
Arjan van de Ven <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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.
Arjan van de Ven <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-01-24:
> Arjan van de Ven <[email protected]> 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
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
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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&¤t->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/
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&¤t->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
>> 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
--
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
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.
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
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
Jan Engelhardt <[email protected]> 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&¤t->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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Jan 25 2006, Joerg Schilling wrote:
> Jan Engelhardt <[email protected]> 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
>> 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
--
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
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
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"Theodore Ts'o" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Edgar Toernig <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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.
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Jens Axboe <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
> Jens Axboe <[email protected]> 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.
On Wed, Jan 25 2006, Joerg Schilling wrote:
> Jan Engelhardt <[email protected]> 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
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Jan 25 2006, Joerg Schilling wrote:
> Jens Axboe <[email protected]> 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
On Wed, Jan 25 2006, Matthias Andree wrote:
> Joerg Schilling wrote:
> > Jens Axboe <[email protected]> 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
On Wed, Jan 25 2006, Joerg Schilling wrote:
> Matthias Andree <[email protected]> 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
On Wed, 2006-01-25 at 17:57 +0100, Joerg Schilling wrote:
> Jan Engelhardt <[email protected]> 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
Joerg Schilling schrieb am 2006-01-25:
> Matthias Andree <[email protected]> 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
Joerg Schilling <[email protected]> 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.
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Thu, Jan 26 2006, Joerg Schilling wrote:
> Matthias Andree <[email protected]> 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
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
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!
Matthias Andree <[email protected]> wrote:
> Joerg Schilling schrieb am 2006-01-25:
>
> > Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-01-26:
> Matthias Andree <[email protected]> wrote:
>
> > Joerg Schilling schrieb am 2006-01-25:
> >
> > > Matthias Andree <[email protected]> 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
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>> 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
--
(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
--
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
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
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
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.
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&¤t->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?
>> >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
--
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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.
> > Matthias Andree <[email protected]> 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'.
Luke-Jr <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling schrieb am 2006-02-06:
> Luke-Jr <[email protected]> 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
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 <[email protected]> wrote:
> Luke-Jr <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
> [email protected] (uni)
> [email protected] (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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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.
Peter Read <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Monday 06 February 2006 13:51, Joerg Schilling wrote:
> Luke-Jr <[email protected]> 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 <[email protected]> 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.
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.
Joerg Schilling schrieb am 2006-02-06:
> Peter Read <[email protected]> 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
"Jim Crilly" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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 <[email protected]> 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'
Joerg Schilling schrieb am 2006-02-07:
> "Jim Crilly" <[email protected]> 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
On 02/07/06 02:06:30PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <[email protected]> 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.
"Jim Crilly" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Wed, 08 Feb 2006 14:27:41 +0100
Joerg Schilling <[email protected]> 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
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 <[email protected]> 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
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?
On 02/08/06 02:27:41PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <[email protected]> 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.
"Jim Crilly" <[email protected]> wrote:
> On 02/08/06 02:27:41PM +0100, Joerg Schilling wrote:
> > "Jim Crilly" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 02/08/06 05:32:38PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <[email protected]> wrote:
>
> > On 02/08/06 02:27:41PM +0100, Joerg Schilling wrote:
> > > "Jim Crilly" <[email protected]> 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.
Hi Joerg :)
* Joerg Schilling <[email protected]> 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!
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
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
> I did answer this many times and I will not repeat it another time.
So just point to the Message-ID.
Martin
Hi Lennart :)
* Lennart Sorensen <[email protected]> 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!
"Jim Crilly" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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 <[email protected]> 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.
DervishD <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
[email protected] (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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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
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.
Joerg Schilling schrieb am 2006-02-09:
> [email protected] (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
Joerg Schilling schrieb am 2006-02-09:
> DervishD <[email protected]> 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
DervishD <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hi Joerg,
Joerg Schilling wrote:
> Matthias Andree <[email protected]> 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
Hi Joerg :)
* Joerg Schilling <[email protected]> dixit:
> DervishD <[email protected]> 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!
Hi Joerg :)
* Joerg Schilling <[email protected]> dixit:
> [email protected] (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!
Hi Joerg :)
* Joerg Schilling <[email protected]> dixit:
> DervishD <[email protected]> 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!
Joerg Schilling wrote:
> Matthias Andree <[email protected]> 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>
DervishD <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
DervishD <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 02/09/06 04:45:07PM +0100, Joerg Schilling wrote:
> DervishD <[email protected]> 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.
On 02/09/06 11:29:28AM +0100, Joerg Schilling wrote:
> [email protected] (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.
"Jim Crilly" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 02/09/06 05:01:50PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <[email protected]> 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.
"Jim Crilly" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
> "Jim Crilly" <[email protected]> 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.
>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
--
On 02/09/06 05:13:08PM +0100, Joerg Schilling wrote:
> "Jim Crilly" <[email protected]> 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.
Joerg Schilling wrote:
> DervishD <[email protected]> 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.
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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.
>> >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/
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hi Joerg :)
* Joerg Schilling <[email protected]> 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!
Joerg Schilling wrote:
> Jan Engelhardt <[email protected]> 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.
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 <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
COBOL -- Compiles Only Because Of Luck
>> >> >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
--
>>>>
>>> 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
--
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
>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.
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
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.
On Thu, Feb 09, 2006 at 10:39:55AM +0100, Joerg Schilling wrote:
> "Jim Crilly" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
> [email protected] (uni)
> [email protected] (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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, Feb 09, 2006 at 04:45:07PM +0100, Joerg Schilling wrote:
> DervishD <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
> [email protected] (uni)
> [email protected] (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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
DervishD <[email protected]> wrote:
> * Joerg Schilling <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Martin Mares <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Hi Joerg :)
* Joerg Schilling <[email protected]> dixit:
> DervishD <[email protected]> wrote:
> > * Joerg Schilling <[email protected]> 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!
Joerg Schilling schrieb am 2006-02-10:
> Martin Mares <[email protected]> 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
Hi Joerg :)
* Joerg Schilling <[email protected]> dixit:
> Martin Mares <[email protected]> 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!
DervishD schrieb am 2006-02-10:
> Hi Joerg :)
>
> * Joerg Schilling <[email protected]> dixit:
> > Martin Mares <[email protected]> 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
Hi Matthias :)
* Matthias Andree <[email protected]> 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!
Kyle Moffett <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"Jim Crilly" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
DervishD <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
DervishD <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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 <[email protected]> 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.
On Friday 10 February 2006 07:15, Joerg Schilling wrote:
> Kyle Moffett <[email protected]> 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.
Hi Joerg :)
* Joerg Schilling <[email protected]> dixit:
> DervishD <[email protected]> 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!
Martin Mares <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Friday 10 February 2006 07:35, Joerg Schilling wrote:
> Matthias Andree <[email protected]> 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
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.
"D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>> > 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
--
>> 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
--
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 2/10/06, Joerg Schilling <[email protected]> wrote:
> "D. Hazelton" <[email protected]> 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
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
"Theodore Ts'o" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
> "Theodore Ts'o" <[email protected]> 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
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
"Christopher Friesen" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"Theodore Ts'o" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
> "Christopher Friesen" <[email protected]> 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
On Fri, Feb 10, 2006 at 09:13:44AM -0600, Christopher Friesen wrote:
> Joerg Schilling wrote:
> >"Christopher Friesen" <[email protected]> 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
On 2/10/06, Joerg Schilling <[email protected]> wrote:
> "D. Hazelton" <[email protected]> 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
On Fri, Feb 10, 2006 at 03:54:44PM +0100, Joerg Schilling wrote:
> "Theodore Ts'o" <[email protected]> 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 -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
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
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
On Friday 10 February 2006 10:38, jerome lacoste wrote:
>On 2/10/06, Joerg Schilling <[email protected]> wrote:
>> "D. Hazelton" <[email protected]> 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.
El Fri, 10 Feb 2006 15:54:44 +0100,
Joerg Schilling <[email protected]> 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?
On Friday 10 February 2006 12:15, Joerg Schilling wrote:
> Kyle Moffett <[email protected]> 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.
Joerg Schilling writes:
> "Theodore Ts'o" <[email protected]> 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.
On Friday 10 February 2006 12:02, you wrote:
> Jan Engelhardt <[email protected]> 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.
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
Joerg Schilling schrieb am 2006-02-10:
> Matthias Andree <[email protected]> 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
Joerg Schilling schrieb am 2006-02-10:
> DervishD <[email protected]> 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
* Erik Mouw <[email protected]> [2006-02-10 16:42:56 +0100]:
> On Fri, Feb 10, 2006 at 03:54:44PM +0100, Joerg Schilling wrote:
> > "Theodore Ts'o" <[email protected]> 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
On Friday 10 February 2006 08:03, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> 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
On Friday 10 February 2006 08:25, Dmitry Torokhov wrote:
> On 2/10/06, Joerg Schilling <[email protected]> wrote:
> > "D. Hazelton" <[email protected]> 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
On Friday 10 February 2006 10:38, jerome lacoste wrote:
> On 2/10/06, Joerg Schilling <[email protected]> wrote:
> > "D. Hazelton" <[email protected]> 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
>> > > 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
--
>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
--
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.
On Fri, Feb 10, 2006 at 02:03:30PM +0100, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
> [email protected] (uni)
> [email protected] (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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Fri, Feb 10, 2006 at 12:49:30PM +0100, DervishD wrote:
> Hi Joerg :)
>
> * Joerg Schilling <[email protected]> dixit:
> > Martin Mares <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Joerg Schilling <[email protected]> wrote:
> Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"Christopher Friesen" <[email protected]> wrote:
> Joerg Schilling wrote:
> > "Christopher Friesen" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Chris Shoemaker <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
jerome lacoste <[email protected]> wrote:
> On 2/10/06, Joerg Schilling <[email protected]> wrote:
> > "D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"Theodore Ts'o" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Diego Calleja <[email protected]> wrote:
> El Fri, 10 Feb 2006 15:54:44 +0100,
> Joerg Schilling <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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 <[email protected]> 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.
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
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 <[email protected]> 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)
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
On 2/13/06, Joerg Schilling <[email protected]> wrote:
> jerome lacoste <[email protected]> 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
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
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
On Mon, 2006-02-13 at 13:14, Xavier Bestel wrote:
> BTW, is there a vold-like implementation for linux somewhere ?
Yes, there is.
"D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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
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 <[email protected]> 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.
On 2/13/06, Joerg Schilling <[email protected]> wrote:
> "D. Hazelton" <[email protected]> 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
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 2/10/06, Joerg Schilling <[email protected]> wrote:
> "D. Hazelton" <[email protected]> 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
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
Sam Vilain <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Alexander Samad <[email protected]> wrote:
> On Fri, Feb 10, 2006 at 12:49:30PM +0100, DervishD wrote:
> > Hi Joerg :)
> >
> > * Joerg Schilling <[email protected]> dixit:
> > > Martin Mares <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Mon, 13 Feb 2006 15:29:02 +0100
Joerg Schilling <[email protected]> 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
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
Martin Mares <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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
jerome lacoste <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"Theodore Ts'o" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 2/13/06, Joerg Schilling <[email protected]> wrote:
> jerome lacoste <[email protected]> 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.
Joerg Schilling schrieb am 2006-02-13:
> "Theodore Ts'o" <[email protected]> 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
jerome lacoste <[email protected]> wrote:
> On 2/13/06, Joerg Schilling <[email protected]> wrote:
> > "D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Martin Mares <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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* <[email protected]> wrote:
Jan Engelhardt <[email protected]> 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
On 2/13/06, Joerg Schilling <[email protected]> wrote:
> jerome lacoste <[email protected]> wrote:
>
> > On 2/13/06, Joerg Schilling <[email protected]> wrote:
> > > "D. Hazelton" <[email protected]> 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
jerome lacoste <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Florin Malita <[email protected]> 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* <[email protected]> wrote:
>
> Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 2/13/06, Joerg Schilling <[email protected]> wrote:
> jerome lacoste <[email protected]> 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
On 02/13/06 04:29:37PM +0100, Joerg Schilling wrote:
> Martin Mares <[email protected]> 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.
jerome lacoste <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>> 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
--
jerome lacoste <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>> 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
--
El Mon, 13 Feb 2006 16:56:18 +0100,
Joerg Schilling <[email protected]> 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....
>
>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
--
>
>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?
>> 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
--
>> 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
--
On Mon, 2006-02-13 at 17:24, Joerg Schilling wrote:
> jerome lacoste <[email protected]> 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
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>> 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* <[email protected]> wrote:
>>
>> Jan Engelhardt <[email protected]> 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
--
Jan Engelhardt <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
>Florin Malita <[email protected]> wrote:
>
>>On 2/10/06, *Joerg Schilling* <[email protected]> wrote:
>>
>> Jan Engelhardt <[email protected]> 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
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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 2/13/06, Joerg Schilling <[email protected]> wrote:
> jerome lacoste <[email protected]> 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
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.
jerome lacoste <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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.
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
On Monday 13 February 2006 10:29, Joerg Schilling wrote:
> Martin Mares <[email protected]> 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
On Monday 13 February 2006 05:40, Joerg Schilling wrote:
> jerome lacoste <[email protected]> wrote:
> > On 2/10/06, Joerg Schilling <[email protected]> wrote:
> > > "D. Hazelton" <[email protected]> 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
On Monday 13 February 2006 08:44, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> 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
On Monday 13 February 2006 08:40, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> 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
On Monday 13 February 2006 09:29, Joerg Schilling wrote:
> Sam Vilain <[email protected]> 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
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
On Monday 13 February 2006 10:15, Joerg Schilling wrote:
> Matthias Andree <[email protected]> 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
On Monday 13 February 2006 05:30, Joerg Schilling wrote:
> "Christopher Friesen" <[email protected]> wrote:
> > Joerg Schilling wrote:
> > > "Christopher Friesen" <[email protected]> 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
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
On Mon, Feb 13, 2006 at 04:29:37PM +0100, Joerg Schilling wrote:
> Martin Mares <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
> [email protected] (uni)
> [email protected] (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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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.
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.
>> > 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
--
>> >
>> >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
--
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 <[email protected]> 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'
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.
Joerg Schilling <[email protected]> wrote:
> jerome lacoste <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
[email protected] 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Tuesday 14 February 2006 06:31, Joerg Schilling wrote:
> Joerg Schilling <[email protected]> wrote:
> > jerome lacoste <[email protected]> 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: <[email protected]>
<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: <[email protected]>
On 2/13/06, Joerg Schilling <[email protected]> wrote:
> "D. Hazelton" <[email protected]> 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
On Tuesday 14 February 2006 06:48, Joerg Schilling wrote:
> [email protected] 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
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
On 2/14/06, Joerg Schilling <[email protected]> wrote:
> Joerg Schilling <[email protected]> wrote:
>
> > jerome lacoste <[email protected]> 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
"D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
kernel <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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
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
"D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"D. Hazelton" <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
jerome lacoste <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
El Tue, 14 Feb 2006 17:42:27 +0100,
Joerg Schilling <[email protected]> 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.
<[email protected]> wrote:
> El Tue, 14 Feb 2006 17:42:27 +0100,
> Joerg Schilling <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 02/14/06 02:37:14PM +0100, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> 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.
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.
On Tuesday 14 February 2006 11:40, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> 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
On Tuesday 14 February 2006 08:37, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> 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
On Tuesday 14 February 2006 11:42, Joerg Schilling wrote:
> "D. Hazelton" <[email protected]> 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
On Tuesday 14 February 2006 11:55, Joerg Schilling wrote:
> Matthias Andree <[email protected]> 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
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.
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.
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
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.
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
El Tue, 14 Feb 2006 21:19:42 -0500,
"D. Hazelton" <[email protected]> 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....
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.
On Wed, 15 Feb 2006 02:55:03 -0000, Rob Landley <[email protected]> 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 <[email protected]>
QA Engineer | GnuPG Key ID - 0x4B20601A
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
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
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.
Rob Landley <[email protected]> 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
On Wednesday 15 February 2006 2:16 pm, Doug McNaught wrote:
> Rob Landley <[email protected]> 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.
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
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.
>>>>> "Rob" == Rob Landley <[email protected]> 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
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.
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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
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
>
>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
--
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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.
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 <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Sat, 18 Feb 2006 11:44:25 -0500
Bill Davidsen <[email protected]> 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