* Rationale for RLIMIT_MEMLOCK? @ 2006-01-23 10:56 Matthias Andree 2006-01-23 11:05 ` Arjan van de Ven 0 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-01-23 10:56 UTC (permalink / raw) To: Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 10:56 Rationale for RLIMIT_MEMLOCK? Matthias Andree @ 2006-01-23 11:05 ` Arjan van de Ven 2006-01-23 16:54 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Arjan van de Ven @ 2006-01-23 11:05 UTC (permalink / raw) To: Matthias Andree; +Cc: Linux-Kernel mailing list ` > > 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). ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 11:05 ` Arjan van de Ven @ 2006-01-23 16:54 ` Matthias Andree 2006-01-23 17:00 ` Arjan van de Ven 0 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-01-23 16:54 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Linux-Kernel mailing list, mtk-manpages 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 16:54 ` Matthias Andree @ 2006-01-23 17:00 ` Arjan van de Ven 2006-01-23 18:01 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Arjan van de Ven @ 2006-01-23 17:00 UTC (permalink / raw) To: Matthias Andree; +Cc: Linux-Kernel mailing list, mtk-manpages > > > 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? ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 17:00 ` Arjan van de Ven @ 2006-01-23 18:01 ` Matthias Andree 2006-01-23 18:13 ` Arjan van de Ven 0 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-01-23 18:01 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 18:01 ` Matthias Andree @ 2006-01-23 18:13 ` Arjan van de Ven 2006-01-23 18:55 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Arjan van de Ven @ 2006-01-23 18:13 UTC (permalink / raw) To: Matthias Andree; +Cc: Linux-Kernel mailing list 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.... ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 18:13 ` Arjan van de Ven @ 2006-01-23 18:55 ` Matthias Andree 2006-01-23 19:04 ` Arjan van de Ven ` (3 more replies) 0 siblings, 4 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-23 18:55 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 18:55 ` Matthias Andree @ 2006-01-23 19:04 ` Arjan van de Ven 2006-01-23 19:38 ` Joerg Schilling ` (2 subsequent siblings) 3 siblings, 0 replies; 439+ messages in thread From: Arjan van de Ven @ 2006-01-23 19:04 UTC (permalink / raw) To: Matthias Andree; +Cc: Linux-Kernel mailing list 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???? ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 18:55 ` Matthias Andree 2006-01-23 19:04 ` Arjan van de Ven @ 2006-01-23 19:38 ` Joerg Schilling 2006-01-23 20:30 ` Matthias Andree 2006-01-23 20:30 ` Lee Revell 2006-01-23 19:57 ` Lee Revell 2006-01-23 21:34 ` Theodore Ts'o 3 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-23 19:38 UTC (permalink / raw) To: matthias.andree, arjan; +Cc: linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > On Mon, 23 Jan 2006, Arjan van de Ven wrote: > > > hmm... curious that mlockall() succeeds with only a 32kb rlimit.... > > It's quite obvious with the seteuid() shuffling behind the scenes of the > app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0. > > Clearly the application should do both with the same privilege or raise > the RLIMIT_MEMLOCK while running with privileges. > > The question that's open is one for the libc guys: malloc(), valloc() > and others seem to use mmap() on some occasions (for some allocation > sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and > if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc > is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and > then drops privileges. If the behavior described by Matthias is true for current Linuc kernels, then there is a clean bug that needs fixing. If the Linux kernel is not willing to accept the contract by mlockall(MLC_FUTURE), then it should now accept the call at all. In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later ignores this contract. This bug should be fixed. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 19:38 ` Joerg Schilling @ 2006-01-23 20:30 ` Matthias Andree 2006-01-23 21:23 ` Joerg Schilling 2006-01-24 8:52 ` Arjan van de Ven 2006-01-23 20:30 ` Lee Revell 1 sibling, 2 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-23 20:30 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, arjan, linux-kernel Joerg Schilling schrieb am 2006-01-23: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > On Mon, 23 Jan 2006, Arjan van de Ven wrote: > > > > > hmm... curious that mlockall() succeeds with only a 32kb rlimit.... > > > > It's quite obvious with the seteuid() shuffling behind the scenes of the > > app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0. > > > > Clearly the application should do both with the same privilege or raise > > the RLIMIT_MEMLOCK while running with privileges. > > > > The question that's open is one for the libc guys: malloc(), valloc() > > and others seem to use mmap() on some occasions (for some allocation > > sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and > > if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc > > is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and > > then drops privileges. > > If the behavior described by Matthias is true for current Linuc kernels, > then there is a clean bug that needs fixing. Jörg elided my lines that said valloc() was the function in question. Jörg, if we're talking about valloc(), this hasn't much to do with the kernel, but is a library issue. There is _no_ documentation that says valloc() or memalign() or posix_memalign() is required to use mmap(). It works on some systems and for some allocation sizes as a side effect of the valloc() implementation. And because this requirement is not specified in the relevant standards, it is wrong to assume valloc() returns locked pages. You cannot rely on mmap() returning locked pages after mlockall() either, because you might be exceeding resource limits. > If the Linux kernel is not willing to accept the contract by > mlockall(MLC_FUTURE), then it should now accept the call at all. If the application wants locked pages, it either needs to call mmap() explicitly, or use mlock() on the valloc()ed region. Even then, allocation or mlock may fail due to resource constraints. I checked FreeBSD 6-STABLE i386, Solaris 8 FCS SPARC and SUSE Linux 10.0 i386 on this. > In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later > ignores this contract. This bug should be fixed. The complete story is, condensed, and with return values, for a setuid-root application: geteuid() == 0; mlockall(MLC_CURRENT|MLC_FUTURE) == (success); seteuid(500) == (success); valloc(64512 + pagesize) == NULL (failure); Jörg, correct me if the valloc() figure is wrong. valloc() called mmap() internally, tried to grab 1 MB, and failed with EAGAIN - as we were able to see from the strace. SuSE Linux 10.0, kernel 2.6.13-15.7-default #1 Tue Nov 29 14:32:29 UTC 2005 on i686 athlon i386 GNU/Linux -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 20:30 ` Matthias Andree @ 2006-01-23 21:23 ` Joerg Schilling 2006-01-23 22:05 ` Matthias Andree 2006-01-24 8:52 ` Arjan van de Ven 1 sibling, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-01-23 21:23 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: matthias.andree, linux-kernel, arjan Matthias Andree <matthias.andree@gmx.de> wrote: > > If the behavior described by Matthias is true for current Linuc kernels, > > then there is a clean bug that needs fixing. > > Jörg elided my lines that said valloc() was the function in question. > > Jörg, if we're talking about valloc(), this hasn't much to do with the > kernel, but is a library issue. >From my understanding, the problem is that Linux first grants the mlockall(MLC_FUTURE) call and later ignores this contract. The fact that valloc() works in a way that is not comprehensible seems to be another issue. Libscg calls valloc(size) where size is less than 64 KB. From the strace output from Matthias, it looks like valloc first calls brk() to extend the size of the data segment (probably to aproach the next pagesize aligned border) and later calls mmap() to get 1 MB or memory. Well first it seems that valloc() tries to get too much memory but this is another story. Inside the kernel handler for this call, the permission to lock the new memory _again_ checks for permission and this is wrong as the request for locking all future pages of the process already has been granted. This looks similar to when I open() a file that may only be opened as root and late switch my uid to some other id. If read() would be implemented the same way as Linux implements the locking, each read() call would again check whether the current uid would have permission to get access to the fd from a filename. This is obviously wrong. The _process_ has been granted the rights to mlock all future pages and this is something that needs to be nonored until the process dies. > There is _no_ documentation that says valloc() or memalign() or > posix_memalign() is required to use mmap(). It works on some systems and > for some allocation sizes as a side effect of the valloc() > implementation. The problem seems to be independend how valloc() is implemented. > And because this requirement is not specified in the relevant standards, > it is wrong to assume valloc() returns locked pages. You cannot rely on > mmap() returning locked pages after mlockall() either, because you might > be exceeding resource limits. If there were such resource limits, then they would need to be honored regardless of the privileges of the process. > > If the Linux kernel is not willing to accept the contract by > > mlockall(MLC_FUTURE), then it should now accept the call at all. > > If the application wants locked pages, it either needs to call mmap() > explicitly, or use mlock() on the valloc()ed region. Even then, > allocation or mlock may fail due to resource constraints. I checked > FreeBSD 6-STABLE i386, Solaris 8 FCS SPARC and SUSE Linux 10.0 i386 on > this. What did you check? Solaris does not check for any privileges whan calling mmap() Solaris implements mlockall() via memcntl which contains the only place where a check for secpolicy_lock_memory(CRED()) takes place. > > In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later > > ignores this contract. This bug should be fixed. > > The complete story is, condensed, and with return values, for a > setuid-root application: > > geteuid() == 0; > mlockall(MLC_CURRENT|MLC_FUTURE) == (success); > seteuid(500) == (success); > valloc(64512 + pagesize) == NULL (failure); > > Jörg, correct me if the valloc() figure is wrong. > > valloc() called mmap() internally, tried to grab 1 MB, and failed with > EAGAIN - as we were able to see from the strace. This is correct. Returning EAGAIN seems to be a result of missunderstanding the POSIX standard. The POSIX standard means real hardware resources when talking about EAGAIN] [ML] The mapping could not be locked in memory, if required by mlockall(), due to a lack of resources. If linux likes to ass a new RLIMIT_MEMLOCK resource, it would be needed to honor this resource independent from the user id in order to prevent being contradictory. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 21:23 ` Joerg Schilling @ 2006-01-23 22:05 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-23 22:05 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, arjan Joerg Schilling schrieb am 2006-01-23: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > If the behavior described by Matthias is true for current Linuc kernels, > > > then there is a clean bug that needs fixing. > > > > Jörg elided my lines that said valloc() was the function in question. > > > > Jörg, if we're talking about valloc(), this hasn't much to do with the > > kernel, but is a library issue. > > From my understanding, the problem is that Linux first grants the > mlockall(MLC_FUTURE) call and later ignores this contract. ... > Inside the kernel handler for this call, the permission to lock the new > memory _again_ checks for permission and this is wrong as the request > for locking all future pages of the process already has been granted. I *do* think that the kernel refused our mmap() request on grounds of the RLIMIT_MEMLOCK (32 kB) and not any other reason, because running the same allocation code as root succeeds, and Linux 2.6.13 is documented to ignore RLIMIT_MEMLOCK for the super-user. And I do believe Linux is entirely on IEEE Std 1003.1-2001 grounds here. > > There is _no_ documentation that says valloc() or memalign() or > > posix_memalign() is required to use mmap(). It works on some systems and > > for some allocation sizes as a side effect of the valloc() > > implementation. > > The problem seems to be independend how valloc() is implemented. As far as the kernel is concerned, yes. As far as your application is concerned, valloc() does not provide "mapped" or "locked" pages, but "allocated". > > And because this requirement is not specified in the relevant standards, > > it is wrong to assume valloc() returns locked pages. You cannot rely on > > mmap() returning locked pages after mlockall() either, because you might > > be exceeding resource limits. > > If there were such resource limits, then they would need to be honored > regardless of the privileges of the process. That's a different story. > > > If the Linux kernel is not willing to accept the contract by > > > mlockall(MLC_FUTURE), then it should now accept the call at all. > > > > If the application wants locked pages, it either needs to call mmap() > > explicitly, or use mlock() on the valloc()ed region. Even then, > > allocation or mlock may fail due to resource constraints. I checked > > FreeBSD 6-STABLE i386, Solaris 8 FCS SPARC and SUSE Linux 10.0 i386 on > > this. > > What did you check? The mlockall() documentation. Any OS allows later mappings to fail if they cannot be locked, and this is what happens. The only troublesome spot that remains is valloc() using mmap() internally, which inherits the mlockall()/mmap() failure modes and causes bogus "out of memory" returns by valloc(). 1. valloc is not required to lock pages 2. yet it can fail if it cannot lock pages This is a problem from the applications POV, albeit one that is in glibc's memory allocator. mlockall() does NOT make promises HOW MUCH memory may be allocated in the future, and that is the problem at hand. Linux allows us 32 kB (as unprivileged user even, we don't get that with Solaris or FreeBSD!), but we want 63 kB and Linux says "Sorry, you can't have that. EAGAIN" > Returning EAGAIN seems to be a result of missunderstanding the POSIX > standard. The POSIX standard means real hardware resources when talking about Well... mlockall() allows for, "other implementation-defined limit[s]", so POSIX is not supportive of your argument here. > EAGAIN] > [ML] The mapping could not be locked in memory, if required by > mlockall(), due to a lack of resources. > > If linux likes to ass a new RLIMIT_MEMLOCK resource, it would be needed to > honor this resource independent from the user id in order to prevent being > contradictory. This is irrelevant to cdrecord, because it does not trip over this contradiction. If I were the cdrecord maintainer, I'd forget about mlockall() altogether because it's just too broad and doesn't allow something like "no more auto locking" without unlocking all locked pages (see also Lee Revell's earlier post), lock the FIFO, command data buffers and everything explicitly through mlock(), set the scheduler, open the device and then call setuid() to get rid of the saved set-user-id as well. This may be narrow-minded, but given mlock() is present in the BSD world (FreeBSD, NetBSD), in the SysV world (Solaris) and Linux, there's reason to support it, as these constitute a large user base. If anything then still fails (command filter), I'd ask the kernel guys how the restriction can be lifted so that cdrecord can work without ANY root privileges, in the most portable way. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 20:30 ` Matthias Andree 2006-01-23 21:23 ` Joerg Schilling @ 2006-01-24 8:52 ` Arjan van de Ven 2006-01-24 9:08 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Arjan van de Ven @ 2006-01-24 8:52 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, linux-kernel > 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 :( ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-24 8:52 ` Arjan van de Ven @ 2006-01-24 9:08 ` Joerg Schilling 2006-01-24 9:15 ` Arjan van de Ven 2006-01-24 10:51 ` Matthias Andree 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-24 9:08 UTC (permalink / raw) To: matthias.andree, arjan; +Cc: schilling, linux-kernel Arjan van de Ven <arjan@infradead.org> wrote: > > And because this requirement is not specified in the relevant standards, > > it is wrong to assume valloc() returns locked pages. > > is it? I sort of doubt that (but I'm not a standards expert, but I'd > expect that "lock all in the future" applies to all memory, not just > mmap'd memory I concur: Locking pages into core is a property/duty of the VM subsystem. If you have an orthogonal VM subsystem, you cannot later tell how a page was mapped into the user's address space. Even more: you may map a file to a alocation in the data segment of the proces (that has been retrieved via malloc()/brk()) and replace the related mapping with a mapped file. On Solaris, there is no difference. > > > You cannot rely on > > mmap() returning locked pages after mlockall() either, because you might > > be exceeding resource limits. > > this is true and fully correct > > > > the situation is messy; I can see some value in the hack Ted proposed to > just bump the rlimit automatically at an mlockall-done-by-root.. but to > be fair it's a hack :( As all other rlimits are honored even if you are root, it looks not orthogonal to disregard an existing RLIMIT_MEMLOCK rlimit if you are root. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-24 9:08 ` Joerg Schilling @ 2006-01-24 9:15 ` Arjan van de Ven 2006-01-24 9:18 ` Joerg Schilling 2006-01-24 21:28 ` Theodore Ts'o 2006-01-24 10:51 ` Matthias Andree 1 sibling, 2 replies; 439+ messages in thread From: Arjan van de Ven @ 2006-01-24 9:15 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-24 9:15 ` Arjan van de Ven @ 2006-01-24 9:18 ` Joerg Schilling 2006-01-24 21:28 ` Theodore Ts'o 1 sibling, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-24 9:18 UTC (permalink / raw) To: schilling, arjan; +Cc: matthias.andree, linux-kernel Arjan van de Ven <arjan@infradead.org> wrote: > On Tue, 2006-01-24 at 10:08 +0100, Joerg Schilling wrote: > > > the situation is messy; I can see some value in the hack Ted proposed to > > > just bump the rlimit automatically at an mlockall-done-by-root.. but to > > > be fair it's a hack :( > > > > As all other rlimits are honored even if you are root, it looks not orthogonal > > to disregard an existing RLIMIT_MEMLOCK rlimit if you are root. > > that's another solution; give root a higher rlimit by default for this. > It's also a bit messy, but a not-unreasonable default behavior. This would only make sense in case that you bump up the limit for processes that are suid root and do not lower it in case someone calls seteuid(). Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-24 9:15 ` Arjan van de Ven 2006-01-24 9:18 ` Joerg Schilling @ 2006-01-24 21:28 ` Theodore Ts'o 2006-01-24 23:19 ` Edgar Toernig ` (2 more replies) 1 sibling, 3 replies; 439+ messages in thread From: Theodore Ts'o @ 2006-01-24 21:28 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Joerg Schilling, matthias.andree, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-24 21:28 ` Theodore Ts'o @ 2006-01-24 23:19 ` Edgar Toernig 2006-01-25 15:38 ` Joerg Schilling 2006-01-24 23:26 ` Matthias Andree 2006-01-25 15:33 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: Edgar Toernig @ 2006-01-24 23:19 UTC (permalink / raw) To: Theodore Ts'o Cc: Arjan van de Ven, Joerg Schilling, matthias.andree, linux-kernel 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-24 23:19 ` Edgar Toernig @ 2006-01-25 15:38 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-25 15:38 UTC (permalink / raw) To: tytso, froese; +Cc: schilling, matthias.andree, linux-kernel, arjan Edgar Toernig <froese@gmx.de> wrote: > Theodore Ts'o wrote: > > > > ... proposed a hack where mlockall() would adjust RLIMIT_MEMLOCK. > > Yes, no question it's a hack and a special case; the question is > > whether cure or the disease is worse. > > What about exec? The memory locks are removed on exec but with that > hack the raised limit would stay. Looks like a security bug. The RLIMIT_MEMLOCK feature itself may be a security bug implemented the way it currentlyy is. For me it would make sense to be able to lock everything in core and then be able to tell the system that at most 1MB of additional memory may be locked. In this case, there should be no general failure but the possibility to verify that the value is sufficient for usual cases. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-24 21:28 ` Theodore Ts'o 2006-01-24 23:19 ` Edgar Toernig @ 2006-01-24 23:26 ` Matthias Andree 2006-01-24 23:27 ` Matthias Andree 2006-01-25 15:33 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-01-24 23:26 UTC (permalink / raw) To: Theodore Ts'o, Arjan van de Ven, Joerg Schilling, matthias.andree, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-24 23:26 ` Matthias Andree @ 2006-01-24 23:27 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-24 23:27 UTC (permalink / raw) To: Theodore Ts'o, Arjan van de Ven, Joerg Schilling, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-24 21:28 ` Theodore Ts'o 2006-01-24 23:19 ` Edgar Toernig 2006-01-24 23:26 ` Matthias Andree @ 2006-01-25 15:33 ` Joerg Schilling 2006-01-25 16:01 ` Matthias Andree 2 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-01-25 15:33 UTC (permalink / raw) To: tytso, arjan; +Cc: schilling, matthias.andree, linux-kernel "Theodore Ts'o" <tytso@mit.edu> wrote: > I thought in the case we were talking about, the problem is that we > have a setuid program which calls mlockall() but then later drops its > privileges. So when it tries to allocate memories, RLIMIT_MEMLOCK > applies again, and so all future memory allocations would fail. > > What I proposed is a hack, but strictly speaking not necessary > according to the POSIX standards, but the problem is that a portable > program can't be expected to know that Linux has a RLIMIT_MEMLOCK > resource limit, such that a program which calls mlockall() and then > drops privileges will work under Solaris and fail under Linux. Hence > I why proposed a hack where mlockall() would adjust RLIMIT_MEMLOCK. > Yes, no question it's a hack and a special case; the question is > whether cure or the disease is worse. Maybe, I should give some hints... RLIMIT_MEMLOCK did first apear in BSD-4.4 around 1994. The iplementation is incomplete since then and partially disabled (size check for mmap() in the kernel) on FreeBSD as it has been 1994 on BSD-4.4 FreeBSD currently uses a default value of RLIMIT_INFINITY for users. I could add this piece of code to the euid == 0 part of cdrecord: LOCAL void raise_memlock() { #ifdef RLIMIT_MEMLOCK struct rlimit rlim; rlim.rlim_cur = rlim.rlim_max = RLIM_INFINITY; if (setrlimit(RLIMIT_MEMLOCK, &rlim) < 0) errmsg("Warning: Cannot raise RLIMIT_MEMLOCK limits."); #endif /* RLIMIT_NOFILE */ } Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-25 15:33 ` Joerg Schilling @ 2006-01-25 16:01 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-25 16:01 UTC (permalink / raw) To: Joerg Schilling; +Cc: tytso, arjan, linux-kernel 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-24 9:08 ` Joerg Schilling 2006-01-24 9:15 ` Arjan van de Ven @ 2006-01-24 10:51 ` Matthias Andree 1 sibling, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-24 10:51 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, arjan, linux-kernel Joerg Schilling schrieb am 2006-01-24: > Arjan van de Ven <arjan@infradead.org> wrote: > > > > And because this requirement is not specified in the relevant standards, > > > it is wrong to assume valloc() returns locked pages. > > > > is it? I sort of doubt that (but I'm not a standards expert, but I'd > > expect that "lock all in the future" applies to all memory, not just > > mmap'd memory > > I concur: > > Locking pages into core is a property/duty of the VM subsystem. But where is this laid down in the standard? There must be some part that defines this, else we cannot rely on it. The wording for malloc() and mmap() or mlock() is different. One talks about address space and mapping, whereas malloc() talks about "storage". Only I haven't got time to look for it now. Just that Solaris happens to do it doesn't make it a standard. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 19:38 ` Joerg Schilling 2006-01-23 20:30 ` Matthias Andree @ 2006-01-23 20:30 ` Lee Revell 2006-01-23 21:21 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree 2006-01-23 21:33 ` Rationale for RLIMIT_MEMLOCK? Joerg Schilling 1 sibling, 2 replies; 439+ messages in thread From: Lee Revell @ 2006-01-23 20:30 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, arjan, linux-kernel On Mon, 2006-01-23 at 20:38 +0100, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > On Mon, 23 Jan 2006, Arjan van de Ven wrote: > > > > > hmm... curious that mlockall() succeeds with only a 32kb rlimit.... > > > > It's quite obvious with the seteuid() shuffling behind the scenes of the > > app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0. > > > > Clearly the application should do both with the same privilege or raise > > the RLIMIT_MEMLOCK while running with privileges. > > > > The question that's open is one for the libc guys: malloc(), valloc() > > and others seem to use mmap() on some occasions (for some allocation > > sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and > > if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc > > is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and > > then drops privileges. > > If the behavior described by Matthias is true for current Linuc kernels, > then there is a clean bug that needs fixing. > > If the Linux kernel is not willing to accept the contract by > mlockall(MLC_FUTURE), then it should now accept the call at all. > > In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later > ignores this contract. This bug should be fixed. Joerg, You will be happy to know that in future Linux distros, cdrecord will not require setuid to mlock() and get SCHED_FIFO - both are now controlled by rlimits, so if the distro ships with a sane PAM/group configuration, all you will need to do is add cdrecord users to the "realtime" or "cdrecord" or "audio" group. This will take a while to make it into distros as it requires changes to PAM and glibc in addition to the kernel. Lee ^ permalink raw reply [flat|nested] 439+ messages in thread
* CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-23 20:30 ` Lee Revell @ 2006-01-23 21:21 ` Matthias Andree 2006-01-23 21:26 ` Lee Revell ` (4 more replies) 2006-01-23 21:33 ` Rationale for RLIMIT_MEMLOCK? Joerg Schilling 1 sibling, 5 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-23 21:21 UTC (permalink / raw) To: Lee Revell; +Cc: Joerg Schilling, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-23 21:21 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree @ 2006-01-23 21:26 ` Lee Revell 2006-01-23 21:45 ` Joerg Schilling 2006-01-23 21:30 ` Lee Revell ` (3 subsequent siblings) 4 siblings, 1 reply; 439+ messages in thread From: Lee Revell @ 2006-01-23 21:26 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-23 21:26 ` Lee Revell @ 2006-01-23 21:45 ` Joerg Schilling 2006-01-23 22:00 ` Lee Revell 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-01-23 21:45 UTC (permalink / raw) To: rlrevell, matthias.andree; +Cc: schilling, linux-kernel Lee Revell <rlrevell@joe-job.com> wrote: > On Mon, 2006-01-23 at 22:21 +0100, Matthias Andree wrote: > > Sounds really good. Can you give a pointer as to the detailed rlimit > > requirements? > > I don't want to touch the rest of the thread, but the best info on the > above can be found in the linux-audio-user list archives. It's still a > little unclear exactly which packages are required, but IIRC PAM 0.80 > supports it already. I believe this requires glibc changes eventually, > but programs like PAM and bash that deal with rlimits can work around it > if glibc is not aware of the new rlimit. Could you explain this more in depth? What you describe looks like you propose to add a line: joerg::::defaultpriv=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr to /etc/user_attr which would be honored by PAM during login. This is not what I like to see. What I like to see is that only specific programs like cdrecord would get the permissions to do more than joe user. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-23 21:45 ` Joerg Schilling @ 2006-01-23 22:00 ` Lee Revell 0 siblings, 0 replies; 439+ messages in thread From: Lee Revell @ 2006-01-23 22:00 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Mon, 2006-01-23 at 22:45 +0100, Joerg Schilling wrote: > Lee Revell <rlrevell@joe-job.com> wrote: > > > On Mon, 2006-01-23 at 22:21 +0100, Matthias Andree wrote: > > > Sounds really good. Can you give a pointer as to the detailed rlimit > > > requirements? > > > > I don't want to touch the rest of the thread, but the best info on the > > above can be found in the linux-audio-user list archives. It's still a > > little unclear exactly which packages are required, but IIRC PAM 0.80 > > supports it already. I believe this requires glibc changes eventually, > > but programs like PAM and bash that deal with rlimits can work around it > > if glibc is not aware of the new rlimit. > > Could you explain this more in depth? > > What you describe looks like you propose to add a line: > > joerg::::defaultpriv=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr > > to /etc/user_attr which would be honored by PAM during login. > > This is not what I like to see. > > What I like to see is that only specific programs like cdrecord > would get the permissions to do more than joe user. It's not that fine grained, it works at a user/group level. You would add a line like: @cdrecord hard rtprio 80 to /etc/security/limits.conf and add users to the cdrecord group. Lee ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-23 21:21 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree 2006-01-23 21:26 ` Lee Revell @ 2006-01-23 21:30 ` Lee Revell 2006-01-23 22:03 ` Joerg Schilling ` (2 subsequent siblings) 4 siblings, 0 replies; 439+ messages in thread From: Lee Revell @ 2006-01-23 21:30 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-23 21:21 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree 2006-01-23 21:26 ` Lee Revell 2006-01-23 21:30 ` Lee Revell @ 2006-01-23 22:03 ` Joerg Schilling 2006-01-24 13:58 ` Joerg Schilling 2006-01-24 17:42 ` Jan Engelhardt 4 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-23 22:03 UTC (permalink / raw) To: rlrevell, matthias.andree; +Cc: schilling, linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > S2 Jörg is concerned about the SCSI command filter being too > restrictive. I'm not sure if it still applies to 2.6.16-rc and what the > exact commands in question were. I'll let Jörg complete this list. I am tired today and I need to do other work, so let me parly reply: Iff there is a user space infrastructure for fine grained privileges, there is absolutely no problem with a planned and well known restriction. On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh) that calls getexecuser() in order to find whether there is a specific treatment needed. If this specific treatment is needed, then the shell calls execve(/usr/bin/pfexec cmd <args>) else it calls execve(cmd <args>) I did recently voted to require all shells to be profile enabled by default. With the future plans for extending fine grained privs on Solaris, sending SCSI commands will become more than one priv. I proposed to have a low priv right to send commands like inquiry and test unit ready. These commands may e.g. be send without interfering a concurrent CD/DVD write operation. The next priv could be the permission for sending simple SCSI commands that allow reading from the device. The next priv could be the permission for sending simple SCSI Commands that allow writing. The final priv would allow even vendor specific commands: this is what cdrecord needs. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-23 21:21 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree ` (2 preceding siblings ...) 2006-01-23 22:03 ` Joerg Schilling @ 2006-01-24 13:58 ` Joerg Schilling 2006-01-24 17:42 ` Jan Engelhardt 4 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-24 13:58 UTC (permalink / raw) To: rlrevell, matthias.andree; +Cc: schilling, linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > Of course, I think it's sensible to expect that Linux should adhere to > standards (POSIX) as far as possible, and if any precedent > implementations that are standards-conformant are found, I'd suggest > that Linux adheres to their interpretation, too, to reduce the clutter > and make applications more easily ported to Linux. We'll all benefit. With respect to SCSI transport, it would also make sense tolook at the implementations of various other platforms. > LIST 1 # REQUIREMENTS > > R1 I'll just say we all want cdrecord, dvd recording applications and > similar to work without setuid root flags or sudo or other excessive > privilege escalation. (This needs to be split up into I/O access > privileges, device enumeration, buffer allocation, real-time > requirements such as locking buffers into memory, scheduling and so on.) With fine grained privileges and a nice inherent user level framework, this kind of problems should not apear inside cdrecord at all. > LIST 2 # CURRENT STATE > > S1 Jörg is unhappy with /dev/hd* because he says that it is inferior to > the sg-access via ide-scsi. (I believe the original issues were > DMA-based, and I don't know the details.) I hope Jörg will fill in the > operations that ide-cd (/dev/hd*) lacks. (Jörg, please don't talk about > layer violations here). One original issue was that ide-scsi did cause a kernel panic in case it was used on top of PCMCIA based ATA. The other issue is that ide-scsi does not do DMA in case DMA-size is not a multiple of 512 while is is needed for any size % 4 == 0; or at least size % 8 == 0 > S2 Jörg is concerned about the SCSI command filter being too > restrictive. I'm not sure if it still applies to 2.6.16-rc and what the > exact commands in question were. I'll let Jörg complete this list. If this change had been announced early anough and if there was a workaround, there would be no problem. The problem was that someone has a bad dream and incompatibly changed the Linux kernel over night while cdrecord was in code freeze. Later I was called unflexible because I did follow the well known quality ensuring rules that are in effect short before a new stable/final released is published. > S3 Device enumeration/probing is a sore spot. Unprivileged "cdrecord > dev=ATA: -scandisk" doesn't work, and recent discussions on the cdwrite@ > list didn't make any progress. My observation is that cdrecord stops > probing /dev/hd* devices as soon as one yields EPERM, on the assumption > "if I cannot access /dev/hda, I will not have sufficient privilege to > write a CD anyways". I find this wrong, Jörg finds it correct and argues > "if you can access /dev/hdc as unprivileged user, that's a security > problem". This are two problems: - users of cdrecord like to run cdrecord -scanbus in order to find all SCSI devices. This no longer works since the non-orthogonal /dev/hd* SCSI transport has been added. As Linux already implements a Generic SCSI transport interface (/dev/sg*) people would asume to be able to talk to _all_ SCSI devices using this interface. To allows this, there is a need for a SCSI HBA driver that sends SCSI commands via a ATA interface. - some people seem to set the permissions of some of the /dev/hd* nodes to unsafe values and then complain that the other /dev/hd* nodes cannot be opened. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-23 21:21 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree ` (3 preceding siblings ...) 2006-01-24 13:58 ` Joerg Schilling @ 2006-01-24 17:42 ` Jan Engelhardt 2006-01-24 18:18 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree ` (2 more replies) 4 siblings, 3 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-01-24 17:42 UTC (permalink / raw) To: Matthias Andree; +Cc: Lee Revell, Joerg Schilling, linux-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 3094 bytes --] I'm joining in, > >1. compile a list of their requirements, Have as few code duplicated (e.g. ATAPI and SCSI may share some - after all, ATAPI is (to me) some sort of SCSI tunneled in ATA.) Make it, in accordance with the above, possible to have as few kernel modules loaded as possible and therefore reducing footprint - if I had not to load sd_mod for usb_storage fun, I would get an itch to load a 78564 byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.) Want to write CDs and DVDs "as usual" (see below). De-forest the SCSI subsystem for privilege checking (see below). >2. find out the current state of affairs, I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW, DVD-DL with no problems using cdrecord -dev=/dev/hdb it _currently_ works, no matter how ugly or not this is from either Jörg's or any other developer's POV - therefore it's fine from the end-user's POV. I can write DVDs at 8x speed (approx 10816 KB/sec) - which looks like DMA is working through the current mechanism, although I can't confirm it. There have been reports that cdrecord does not work when setuid, but only when you are "truly root". Not sure where this comes from, (current->euid==0&¤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/ ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-24 17:42 ` Jan Engelhardt @ 2006-01-24 18:18 ` Matthias Andree 2006-01-24 20:54 ` Jan Engelhardt 2006-01-25 15:13 ` Joerg Schilling 2006-01-25 14:04 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Joerg Schilling 2006-02-02 17:17 ` Luke-Jr 2 siblings, 2 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-24 18:18 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Matthias Andree, Lee Revell, Joerg Schilling, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-24 18:18 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree @ 2006-01-24 20:54 ` Jan Engelhardt 2006-01-25 15:26 ` Joerg Schilling 2006-01-25 15:13 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Jan Engelhardt @ 2006-01-24 20:54 UTC (permalink / raw) To: Matthias Andree; +Cc: Lee Revell, Joerg Schilling, linux-kernel >> 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-24 20:54 ` Jan Engelhardt @ 2006-01-25 15:26 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-25 15:26 UTC (permalink / raw) To: matthias.andree, jengelh; +Cc: schilling, rlrevell, linux-kernel Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > Where is the difference between SG_IO-on-hdx and sg0? - Accessing _all_ SCSI devices from a unique name space. - Using a driver that if located at the right layering level (just above the transport) but not at the block level where SCSI transport does not belong. - Cutting down kernel size by avoiding multiple implemenations of code for the same purpose. There are of course more.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-24 18:18 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 2006-01-24 20:54 ` Jan Engelhardt @ 2006-01-25 15:13 ` Joerg Schilling 1 sibling, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-25 15:13 UTC (permalink / raw) To: matthias.andree, jengelh Cc: schilling, rlrevell, matthias.andree, linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > cdrecord simply assumes that if you don't have access to /dev/hda, > scanning the other devices is pointless, on the assumption it were a > security risk. How this fits into user profiles that might allow access > to /dev/hdc, is unclear to me. Wrong: cdrecord asumes nothing. It is the SCSI Generic transport library libscg. Note that libscg does not offer access to a block layer device like /dev/hd* but rather to the transport layer _below_ /dev/hd*. If you ignore this fact you will have problems to understand the rules. > > If you can access a _harddisk_ as a normal user, you _do have_ a security > > problem. If you can access a cdrom as normal user, well, the opinions > > differ here. I think you _should not either_, because it might happen that > > you just left your presentation cd in a cdrom device in a public box. You > > would certainly not want to have everyone read that out. > > That's less of a problem than sending vendor-specific commands - one > might be "update firmware", which would allow the user to destroy the > drive. I am not sure whether you understood the problem here. Cdrtools need to deal with a lot of vendor specific commands. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-24 17:42 ` Jan Engelhardt 2006-01-24 18:18 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree @ 2006-01-25 14:04 ` Joerg Schilling 2006-01-25 14:21 ` Jens Axboe 2006-01-26 12:32 ` Pavel Machek 2006-02-02 17:17 ` Luke-Jr 2 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-25 14:04 UTC (permalink / raw) To: matthias.andree, jengelh; +Cc: schilling, rlrevell, linux-kernel Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >1. compile a list of their requirements, > > Have as few code duplicated (e.g. ATAPI and SCSI may share some - after > all, ATAPI is (to me) some sort of SCSI tunneled in ATA.) Thank you! This is a vote _pro_ a unified SCSI generic implementation for all types of devices. The current implementation unneccssarily duplicates a lot of code. > Make it, in accordance with the above, possible to have as few kernel > modules loaded as possible and therefore reducing footprint - if I had not > to load sd_mod for usb_storage fun, I would get an itch to load a 78564 > byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.) On Solaris, the SCSI glue code (between hostadaptor drivers and target drivers) is really small: /usr/ccs/bin/size /kernel/misc/scsi 28482 + 27042 + 2036 = 57560 And if you check the amount of completely unneeded code Linux currently has just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the kernel when converting to a clean SCSI based design. > Want to write CDs and DVDs "as usual" (see below). Be careful: libscg is a _generic_ SCSI transport library. Closing the eyes for anything but CD writing is not the right way. > De-forest the SCSI subsystem for privilege checking (see below). Sorry, I see nothing related below. > >2. find out the current state of affairs, > > I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW, > DVD-DL with no problems using > cdrecord -dev=/dev/hdb Maybe I should enforce the official libscg device syntax in order to prevent this from working in the future. Anyway: the fact that it may work is no proof for correctness. > I can write DVDs at 8x speed (approx 10816 KB/sec) - which looks like DMA > is working through the current mechanism, although I can't confirm it. In case you don't knw the story: Linus Torvalds once claimed that introducing SG_IO support for /dev/hd* would be acompanied with cleaning up DMA support in the kernel. At that moment it turned out that it did not help at all as /dev/hd* did not give DMA. Later this bug was fixed, but I am still waiting to see the proposed DMA fix for ide-scsi. > There have been reports that cdrecord does not work when setuid, but only > when you are "truly root". Not sure where this comes from, > (current->euid==0&¤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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 14:04 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Joerg Schilling @ 2006-01-25 14:21 ` Jens Axboe 2006-01-25 14:47 ` Jan Engelhardt 2006-01-26 12:32 ` Pavel Machek 1 sibling, 1 reply; 439+ messages in thread From: Jens Axboe @ 2006-01-25 14:21 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, jengelh, rlrevell, linux-kernel On Wed, Jan 25 2006, Joerg Schilling wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > >1. compile a list of their requirements, > > > > Have as few code duplicated (e.g. ATAPI and SCSI may share some - after > > all, ATAPI is (to me) some sort of SCSI tunneled in ATA.) > > Thank you! This is a vote _pro_ a unified SCSI generic implementation for all > types of devices. The current implementation unneccssarily duplicates a lot > of code. The block layer SG_IO is just that, it's completely transport agnostic. There's not a lot of duplicated code. In the future, perhaps sg will disappear and be replaced by bsg which is just the full block layer implementation of that (SG_IO can currently be considered a subset of that support). > > Make it, in accordance with the above, possible to have as few kernel > > modules loaded as possible and therefore reducing footprint - if I had not > > to load sd_mod for usb_storage fun, I would get an itch to load a 78564 > > byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.) > > On Solaris, the SCSI glue code (between hostadaptor drivers and target drivers) is > really small: > > /usr/ccs/bin/size /kernel/misc/scsi > 28482 + 27042 + 2036 = 57560 > > And if you check the amount of completely unneeded code Linux currently has > just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the > kernel when converting to a clean SCSI based design. Please point me at that huge amount of code. Hint: there is none. Deja vu, anyone? -- Jens Axboe ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 14:21 ` Jens Axboe @ 2006-01-25 14:47 ` Jan Engelhardt 2006-01-25 14:55 ` Jens Axboe 2006-01-25 16:57 ` Joerg Schilling 0 siblings, 2 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-01-25 14:47 UTC (permalink / raw) To: Jens Axboe; +Cc: Joerg Schilling, matthias.andree, rlrevell, linux-kernel >> 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 14:47 ` Jan Engelhardt @ 2006-01-25 14:55 ` Jens Axboe 2006-01-25 14:58 ` Jens Axboe 2006-01-25 17:00 ` Joerg Schilling 2006-01-25 16:57 ` Joerg Schilling 1 sibling, 2 replies; 439+ messages in thread From: Jens Axboe @ 2006-01-25 14:55 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Joerg Schilling, matthias.andree, rlrevell, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 14:55 ` Jens Axboe @ 2006-01-25 14:58 ` Jens Axboe 2006-01-25 17:00 ` Joerg Schilling 1 sibling, 0 replies; 439+ messages in thread From: Jens Axboe @ 2006-01-25 14:58 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Joerg Schilling, matthias.andree, rlrevell, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 14:55 ` Jens Axboe 2006-01-25 14:58 ` Jens Axboe @ 2006-01-25 17:00 ` Joerg Schilling 2006-01-25 17:10 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 2006-01-25 17:23 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Jens Axboe 1 sibling, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-25 17:00 UTC (permalink / raw) To: jengelh, axboe; +Cc: schilling, rlrevell, matthias.andree, linux-kernel Jens Axboe <axboe@suse.de> wrote: > It just looks like Joerg needs to do his homework, before spreading > false information on lkml. Then again, all his "arguments" are the same > as last time (and the time before, and before, and so on). Before spreading your false claims, please do your homework. We previously had mostly fruitful discussion before you did appear. Please either try to contribute useful ideas or stay out. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:00 ` Joerg Schilling @ 2006-01-25 17:10 ` Matthias Andree 2006-01-25 17:20 ` Joerg Schilling ` (2 more replies) 2006-01-25 17:23 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Jens Axboe 1 sibling, 3 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-25 17:10 UTC (permalink / raw) To: Joerg Schilling; +Cc: jengelh, axboe, rlrevell, linux-kernel Joerg Schilling wrote: > Jens Axboe <axboe@suse.de> wrote: > >> It just looks like Joerg needs to do his homework, before spreading >> false information on lkml. Then again, all his "arguments" are the same >> as last time (and the time before, and before, and so on). > > Before spreading your false claims, please do your homework. I think we'd better call the whole discussion off. In personal conversation with Jörg, I fell prey to the illusion he might have grown up last week-end, and Lee's promising post was the idea to start the whole thing and see if both sides get closer together, but it seems Jörg is unwilling to stick to a civilized discussion. Sorry for starting this noise. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:10 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree @ 2006-01-25 17:20 ` Joerg Schilling 2006-01-25 17:27 ` Jens Axboe 2006-01-25 23:19 ` Matthias Andree 2006-01-25 17:24 ` Jens Axboe 2006-01-26 9:35 ` Joerg Schilling 2 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-25 17:20 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: rlrevell, linux-kernel, jengelh, axboe Matthias Andree <matthias.andree@gmx.de> wrote: > I think we'd better call the whole discussion off. We could continue as long as people like Jens Axboe stay reasonable. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:20 ` Joerg Schilling @ 2006-01-25 17:27 ` Jens Axboe 2006-01-25 23:19 ` Matthias Andree 1 sibling, 0 replies; 439+ messages in thread From: Jens Axboe @ 2006-01-25 17:27 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, rlrevell, linux-kernel, jengelh On Wed, Jan 25 2006, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > I think we'd better call the whole discussion off. > > We could continue as long as people like Jens Axboe stay reasonable. I would have no problems if you weren't spreading your misguided information disguised as real info. I've had thousands of useful conversations on lkml in the past many years, but I fail to remember just one with you involved (whether I participated or not). I'll refrain from writing further mails in this thread, unless you actually "find some time" to back up your claims with real data. -- Jens Axboe ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:20 ` Joerg Schilling 2006-01-25 17:27 ` Jens Axboe @ 2006-01-25 23:19 ` Matthias Andree 2006-01-26 12:30 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-01-25 23:19 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, rlrevell, linux-kernel, jengelh, axboe Joerg Schilling schrieb am 2006-01-25: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > I think we'd better call the whole discussion off. > > We could continue as long as people like Jens Axboe stay reasonable. No. The deal was people stating their requirements, not mounting personal attacks against others. I posted the same question (what's lacking) several times, and your constant answer "device enumeration" makes me assume that it's the only thing you believe is missing. Since libscg scans all /dev/pg* and /dev/sg* (for transport indicator "" which means plain sg) and all /dev/hd* (for transport indicator ATA: which means /dev/hd*) and turns it into bus, host, lun anyways, there does not appear to be a need to move this code into the kernel. What *else* is missing? -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 23:19 ` Matthias Andree @ 2006-01-26 12:30 ` Joerg Schilling 2006-01-26 12:58 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-01-26 12:30 UTC (permalink / raw) To: schilling, matthias.andree Cc: rlrevell, matthias.andree, linux-kernel, jengelh, axboe Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-01-25: > > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > I think we'd better call the whole discussion off. > > > > We could continue as long as people like Jens Axboe stay reasonable. > > No. The deal was people stating their requirements, not mounting > personal attacks against others. I posted the same question (what's This is why we needed to omit Jens Axboe from this discusion. > lacking) several times, and your constant answer "device enumeration" > makes me assume that it's the only thing you believe is missing. You try to go into the wrong direction by ignoring all important issues. Tell me how to access a ATAPI tape drive via libscg. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 12:30 ` Joerg Schilling @ 2006-01-26 12:58 ` Matthias Andree 2006-01-26 14:19 ` Joerg Schilling 2006-01-26 21:02 ` Jan Engelhardt 0 siblings, 2 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-26 12:58 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel, jengelh Joerg Schilling schrieb am 2006-01-26: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > Joerg Schilling schrieb am 2006-01-25: > > > > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > > > I think we'd better call the whole discussion off. > > > > > > We could continue as long as people like Jens Axboe stay reasonable. > > > > No. The deal was people stating their requirements, not mounting > > personal attacks against others. I posted the same question (what's > > This is why we needed to omit Jens Axboe from this discusion. Hold it! Who is acquainted with Linux 2.6.15-rc*, Jens or you? This childish discussion who started bitching isn't going to take you anywhere. > Tell me how to access a ATAPI tape drive via libscg. It is *your* library, I have no interest in it as long as CD writing works at the moment. Either do your research or ask the public, I'm not going to answer or research this for you. It is not helpful that you are (1) talking about ATAPI tapes under the CD subject and (2) claim you know better than Linux (or Jens, for that matter) if you haven't researched this. If you want to talk about libscg's access methods to all kinds of devices besides CD/DVD, start a new discussion please. And it is about time that you stopped spamming people who explicitly stated "No Cc:" such as Jens Axboe and Lee Revell. Not minding these requests is rude. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 12:58 ` Matthias Andree @ 2006-01-26 14:19 ` Joerg Schilling 2006-01-26 21:02 ` Jan Engelhardt 1 sibling, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-26 14:19 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel, jengelh Matthias Andree <matthias.andree@gmx.de> wrote: > > Tell me how to access a ATAPI tape drive via libscg. > > It is *your* library, I have no interest in it as long as CD writing > works at the moment. Either do your research or ask the public, I'm not > going to answer or research this for you. If you like to cut off the main cause for the problems, it seems that we need to stop this discussion here as I cannot see that we will come to any useful result. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 12:58 ` Matthias Andree 2006-01-26 14:19 ` Joerg Schilling @ 2006-01-26 21:02 ` Jan Engelhardt 2006-01-26 21:40 ` Matthias Andree 1 sibling, 1 reply; 439+ messages in thread From: Jan Engelhardt @ 2006-01-26 21:02 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, linux-kernel >> 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 21:02 ` Jan Engelhardt @ 2006-01-26 21:40 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-26 21:40 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Matthias Andree, Joerg Schilling, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:10 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 2006-01-25 17:20 ` Joerg Schilling @ 2006-01-25 17:24 ` Jens Axboe 2006-01-26 9:35 ` Joerg Schilling 2 siblings, 0 replies; 439+ messages in thread From: Jens Axboe @ 2006-01-25 17:24 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, jengelh, rlrevell, linux-kernel On Wed, Jan 25 2006, Matthias Andree wrote: > Joerg Schilling wrote: > > Jens Axboe <axboe@suse.de> wrote: > > > >> It just looks like Joerg needs to do his homework, before spreading > >> false information on lkml. Then again, all his "arguments" are the same > >> as last time (and the time before, and before, and so on). > > > > Before spreading your false claims, please do your homework. > > I think we'd better call the whole discussion off. > > In personal conversation with Jörg, I fell prey to the illusion he might > have grown up last week-end, and Lee's promising post was the idea to start > the whole thing and see if both sides get closer together, but it seems Jörg > is unwilling to stick to a civilized discussion. > > Sorry for starting this noise. Agreed, it's the same thing that happens each and every time he posts here. -- Jens Axboe ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:10 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 2006-01-25 17:20 ` Joerg Schilling 2006-01-25 17:24 ` Jens Axboe @ 2006-01-26 9:35 ` Joerg Schilling 2006-01-26 9:48 ` Jens Axboe 2 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-01-26 9:35 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: rlrevell, linux-kernel, jengelh, axboe Matthias Andree <matthias.andree@gmx.de> wrote: > I think we'd better call the whole discussion off. Let me come back to this again and give an important statement... If this mailing list is not the place where to make architectural design decisions, then we really better should stop this discussion immediately as it then would be useless. Please inform me about this fact in case you know more as I really don't have time to waste with useless discussions. It seems also required to give some background information: Without Matthias, I would already never again answered any mail from LKML as all previous experiences on this list have been a desaster. It did usually take less than an hour until someone from the list did start personal attacks. The last two times, the discussion has been made impossible because Jens Axboe started with personal infringements and his obvious false claims. This time, it did look really promising until Jens Axboe again started with personal infringements. I have to admit that it would have been better to ignore him from the very beginning, but I was in false hope that he could have changed. Let me make a proposal: I try to answer mail from people who send useful contributions to the discussion and I will ignore anybody who starts with personal infringements. I will try to reply to mails with incorrect claims if they are not obvious but I will stop replying to the same person if he continues with things that are incorrect. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 9:35 ` Joerg Schilling @ 2006-01-26 9:48 ` Jens Axboe 2006-01-26 10:10 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Jens Axboe @ 2006-01-26 9:48 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, rlrevell, linux-kernel, jengelh On Thu, Jan 26 2006, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > I think we'd better call the whole discussion off. > > Let me come back to this again and give an important statement... > > If this mailing list is not the place where to > make architectural design decisions, then we really better > should stop this discussion immediately as it then would be useless. > > Please inform me about this fact in case you know more as I really > don't have time to waste with useless discussions. > > > It seems also required to give some background information: > > Without Matthias, I would already never again answered any mail from > LKML as all previous experiences on this list have been a desaster. It > did usually take less than an hour until someone from the list did > start personal attacks. The last two times, the discussion has been > made impossible because Jens Axboe started with personal infringements > and his obvious false claims. > > This time, it did look really promising until Jens Axboe again started > with personal infringements. I have to admit that it would have been > better to ignore him from the very beginning, but I was in false hope > that he could have changed. > > Let me make a proposal: I try to answer mail from people who send > useful contributions to the discussion and I will ignore anybody who > starts with personal infringements. I will try to reply to mails with > incorrect claims if they are not obvious but I will stop replying to > the same person if he continues with things that are incorrect. What is this, kindergarten? What false claims have I made? I pointed out several you made, to which you had no rebuttal. Then you start playing "Jens made obviously false claims", huh?? I've had more mature conversations with my 1 year old son. I'm sorry if you feel that me refuting your false statements are personal attacks. Clearly not a problem that can be fixed at my end. Ignoring facts and continuing to write the same wrong claims over and over again doesn't make them true in the end. Please take me off the cc list, thanks. -- Jens Axboe ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 9:48 ` Jens Axboe @ 2006-01-26 10:10 ` Matthias Andree 2006-01-26 14:01 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-01-26 10:10 UTC (permalink / raw) To: Joerg Schilling, matthias.andree, linux-kernel, jengelh 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 10:10 ` Matthias Andree @ 2006-01-26 14:01 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-26 14:01 UTC (permalink / raw) To: schilling, matthias.andree, linux-kernel, jengelh Matthias Andree <matthias.andree@gmx.de> wrote: > The problem appears to be that Jörg hasn't really looked at Linux in > some time, and he's used to systems that don't change architecture in > patchlevel releases, while Linux 2.6.N.M should actually have been > numbered 2.(6+2*N).M... > > Jörg, any chance you might be arguing on basis of really old 2.6.X > kernels? All statements I send have been verified by looking at the 2.6.15 source. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 17:00 ` Joerg Schilling 2006-01-25 17:10 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree @ 2006-01-25 17:23 ` Jens Axboe 1 sibling, 0 replies; 439+ messages in thread From: Jens Axboe @ 2006-01-25 17:23 UTC (permalink / raw) To: Joerg Schilling; +Cc: jengelh, rlrevell, matthias.andree, linux-kernel On Wed, Jan 25 2006, Joerg Schilling wrote: > Jens Axboe <axboe@suse.de> wrote: > > > It just looks like Joerg needs to do his homework, before spreading > > false information on lkml. Then again, all his "arguments" are the same > > as last time (and the time before, and before, and so on). > > Before spreading your false claims, please do your homework. Sorry Joerg, _you_ really are the one that has to do your homework as you aptly demonstrated. > We previously had mostly fruitful discussion before you did appear. > Please either try to contribute useful ideas or stay out. You are spreading blatently false claim about the code and repeating the same old suggestions on what _you_ think Linux design should be like. So I had to correct it, which I did. -- Jens Axboe ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 14:47 ` Jan Engelhardt 2006-01-25 14:55 ` Jens Axboe @ 2006-01-25 16:57 ` Joerg Schilling 2006-01-25 17:20 ` Jens Axboe ` (2 more replies) 1 sibling, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-25 16:57 UTC (permalink / raw) To: jengelh, axboe; +Cc: schilling, rlrevell, matthias.andree, linux-kernel Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > >> And if you check the amount of completely unneeded code Linux currently has > >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the > >> kernel when converting to a clean SCSI based design. > > > >Please point me at that huge amount of code. Hint: there is none. > > I'm getting a grin: > > 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO > (no results) > > Looks like it's already non-redundant :) everything in drivers/block/scsi_ioctl.c is duplicate code and I am sure I would find more if I take some time.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 16:57 ` Joerg Schilling @ 2006-01-25 17:20 ` Jens Axboe 2006-01-25 20:16 ` Lee Revell 2006-01-26 21:06 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: Jens Axboe @ 2006-01-25 17:20 UTC (permalink / raw) To: Joerg Schilling; +Cc: jengelh, rlrevell, matthias.andree, linux-kernel On Wed, Jan 25 2006, Joerg Schilling wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > > > >> And if you check the amount of completely unneeded code Linux currently has > > >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the > > >> kernel when converting to a clean SCSI based design. > > > > > >Please point me at that huge amount of code. Hint: there is none. > > > > I'm getting a grin: > > > > 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO > > (no results) > > > > Looks like it's already non-redundant :) > > everything in drivers/block/scsi_ioctl.c is duplicate code and I am sure I > would find more if I take some time.... axboe@nelson:[.]r/src/linux-2.6-block.git $ size block/scsi_ioctl.o text data bss dec hex filename 2844 256 0 3100 c1c block/scsi_ioctl.o And it's not everything that's duplicated, basically only the ioctl parsing is. So either admit that there isn't a a lot of duplicated code, or "take some time" and point me at it. Otherwise refrain from making obviously false statements in the future. -- Jens Axboe ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 16:57 ` Joerg Schilling 2006-01-25 17:20 ` Jens Axboe @ 2006-01-25 20:16 ` Lee Revell 2006-01-26 21:06 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: Lee Revell @ 2006-01-25 20:16 UTC (permalink / raw) To: Joerg Schilling; +Cc: jengelh, axboe, matthias.andree, linux-kernel On Wed, 2006-01-25 at 17:57 +0100, Joerg Schilling wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > > > >> And if you check the amount of completely unneeded code Linux currently has > > >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the > > >> kernel when converting to a clean SCSI based design. > > > > > >Please point me at that huge amount of code. Hint: there is none. > > > > I'm getting a grin: > > > > 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO > > (no results) > > > > Looks like it's already non-redundant :) > > everything in drivers/block/scsi_ioctl.c is duplicate code and I am sure I > would find more if I take some time.... PLEASE don't cc: me on this asinine thread anymore. Argh, I KNEW this would end with the same exact flame war. Lee ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 16:57 ` Joerg Schilling 2006-01-25 17:20 ` Jens Axboe 2006-01-25 20:16 ` Lee Revell @ 2006-01-26 21:06 ` Jan Engelhardt 2006-01-26 21:33 ` Vadim Lobanov 2006-01-26 21:34 ` Vadim Lobanov 2 siblings, 2 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-01-26 21:06 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, Linux Kernel Mailing List (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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-26 21:06 ` Jan Engelhardt @ 2006-01-26 21:33 ` Vadim Lobanov 2006-01-26 21:48 ` Gene Heskett 2006-01-26 21:34 ` Vadim Lobanov 1 sibling, 1 reply; 439+ messages in thread From: Vadim Lobanov @ 2006-01-26 21:33 UTC (permalink / raw) To: Jan Engelhardt Cc: Joerg Schilling, matthias.andree, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-26 21:33 ` Vadim Lobanov @ 2006-01-26 21:48 ` Gene Heskett 0 siblings, 0 replies; 439+ messages in thread From: Gene Heskett @ 2006-01-26 21:48 UTC (permalink / raw) To: linux-kernel 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-26 21:06 ` Jan Engelhardt 2006-01-26 21:33 ` Vadim Lobanov @ 2006-01-26 21:34 ` Vadim Lobanov 1 sibling, 0 replies; 439+ messages in thread From: Vadim Lobanov @ 2006-01-26 21:34 UTC (permalink / raw) To: Jan Engelhardt Cc: Joerg Schilling, matthias.andree, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-25 14:04 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Joerg Schilling 2006-01-25 14:21 ` Jens Axboe @ 2006-01-26 12:32 ` Pavel Machek 1 sibling, 0 replies; 439+ messages in thread From: Pavel Machek @ 2006-01-26 12:32 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, jengelh, rlrevell, linux-kernel 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! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-24 17:42 ` Jan Engelhardt 2006-01-24 18:18 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 2006-01-25 14:04 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Joerg Schilling @ 2006-02-02 17:17 ` Luke-Jr 2006-02-03 14:08 ` Jan Engelhardt 2 siblings, 1 reply; 439+ messages in thread From: Luke-Jr @ 2006-02-02 17:17 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Matthias Andree, Lee Revell, Joerg Schilling, linux-kernel 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? ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-02-02 17:17 ` Luke-Jr @ 2006-02-03 14:08 ` Jan Engelhardt 2006-02-03 16:50 ` Joerg Schilling 2006-02-03 17:24 ` Luke-Jr 0 siblings, 2 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-03 14:08 UTC (permalink / raw) To: Luke-Jr; +Cc: Matthias Andree, Lee Revell, Joerg Schilling, linux-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 2053 bytes --] >> >2. find out the current state of affairs, >> >> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW, >> DVD-DL with no problems using >> cdrecord -dev=/dev/hdb >> it _currently_ works, no matter how ugly or not this is from either Jörg's >> or any other developer's POV - therefore it's fine from the end-user's POV. > >How did you manage to burn a dual layer disc? I have been completely >unsuccessful at doing this at all. :( > You have to add -driver=mmc_dvdplusr , because the Dual Layer discs are not yet in the ProDVD database as it seems. >> I'm fine (=I agree) with the general possibility of having it setuid, >> though. > >Provided it doesn't allow burning files the real-user shouldn't be able to >access... But since cdrecord is commonly suid-root, I presume this has long >been taken into consideration. > Security-critical environments like data centers either have a Windows NT-style machine providing <enter whacky burning software here>, or they 've got a specialized machine that is marked "use for cd burning - note security implications". Usually there is no problem with that as in that case, you should remove your ISO you copied over for writing after writing. >> SUSE currently does it in A Nice Way: setfacl'ing the devices to include >> read access for currently logged-in users. (Well, if someone logs on tty1 >> after you, you're screwed anyway - he could have just ejected the cd when >> he's physically at the box.) > >Aren't user-groups per-session anyway? Why not simply have the login program >apply a 'localusers' group to all local sessions and set device permissions >for that group? userwhat? You mean supplemental groups as printed by id(1)? I find them ugly, because it's a real hassle to manage it with files. In the past, NGROUPS_MAX also was 32, being more of a limit than today. >To add to the security, perhaps there is a way to remove the >'localusers' permissions from all backgrounded processes (screen, etc) when >the user logs out? > Jan Engelhardt -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-02-03 14:08 ` Jan Engelhardt @ 2006-02-03 16:50 ` Joerg Schilling 2006-02-03 17:24 ` Luke-Jr 1 sibling, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-03 16:50 UTC (permalink / raw) To: luke, jengelh; +Cc: schilling, rlrevell, matthias.andree, linux-kernel Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >> >2. find out the current state of affairs, > >> > >> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW, > >> DVD-DL with no problems using > >> cdrecord -dev=/dev/hdb > >> it _currently_ works, no matter how ugly or not this is from either Jörg's > >> or any other developer's POV - therefore it's fine from the end-user's POV. > > > >How did you manage to burn a dual layer disc? I have been completely > >unsuccessful at doing this at all. :( > > > > You have to add -driver=mmc_dvdplusr , because the Dual Layer discs are > not yet in the ProDVD database as it seems. They are if you use a halfway recent cdrecord. > userwhat? You mean supplemental groups as printed by id(1)? I find them > ugly, because it's a real hassle to manage it with files. > > In the past, NGROUPS_MAX also was 32, being more of a limit than today. If you extend NGROUPS_MAX to be more than 16, NFS AUTH_UNIX will not work anymore. And BTW: using NGROUPS seems to be a bit outdated now, more than 10 years after ACLs have been introduced on UNIX. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-02-03 14:08 ` Jan Engelhardt 2006-02-03 16:50 ` Joerg Schilling @ 2006-02-03 17:24 ` Luke-Jr 2006-02-06 13:51 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Luke-Jr @ 2006-02-03 17:24 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Matthias Andree, Lee Revell, Joerg Schilling, linux-kernel 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-02-03 17:24 ` Luke-Jr @ 2006-02-06 13:51 ` Joerg Schilling 2006-02-06 14:01 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-06 13:51 UTC (permalink / raw) To: luke, jengelh; +Cc: schilling, rlrevell, matthias.andree, linux-kernel Luke-Jr <luke@dashjr.org> wrote: > ProDVD is immoral software. I use growisofs. growisofs is immoral, see http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html Either this, or the GPL applies, but not both as intended by the author.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-02-06 13:51 ` Joerg Schilling @ 2006-02-06 14:01 ` Matthias Andree 2006-02-06 15:06 ` Peter Read 2006-02-06 17:40 ` Luke-Jr 2 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-06 14:01 UTC (permalink / raw) To: Joerg Schilling; +Cc: luke, jengelh, rlrevell, matthias.andree, linux-kernel Joerg Schilling schrieb am 2006-02-06: > Luke-Jr <luke@dashjr.org> wrote: > > > ProDVD is immoral software. I use growisofs. > > growisofs is immoral, see > > http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html > > Either this, or the GPL applies, but not both as intended by the author.... Who cares. You start complaining even about GPL patches for the software you distributed under the terms of the GPL, without looking at patches... -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-02-06 13:51 ` Joerg Schilling 2006-02-06 14:01 ` Matthias Andree @ 2006-02-06 15:06 ` Peter Read 2006-02-06 15:15 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 2006-02-06 17:25 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Joerg Schilling 2006-02-06 17:40 ` Luke-Jr 2 siblings, 2 replies; 439+ messages in thread From: Peter Read @ 2006-02-06 15:06 UTC (permalink / raw) To: Joerg Schilling, luke; +Cc: rlrevell, matthias.andree, linux-kernel, jengelh I'm confused about where software has inherited a sense of morality from? Equally, as I can't see any restriction of the GPL in that link I don't get the reference. What it's essentially saying to me is 'if you don't want it under the GPL licence terms, talk to the copyright holder(s) or their authorised representative about alternatives'. Plenty of people are happy to dual licence their work, & TBH I'd rather see people do that and get something for their work than have it misappropriated into commercial software and have to look to the courts for a slim chance at compensation... Anyone else rather get back to the technical discussion or is it just me? On 06/02/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Luke-Jr <luke@dashjr.org> wrote: > > > ProDVD is immoral software. I use growisofs. > > growisofs is immoral, see > > http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html > > Either this, or the GPL applies, but not both as intended by the author.... > > Jörg > > -- > EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin > js@cs.tu-berlin.de (uni) > schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-06 15:06 ` Peter Read @ 2006-02-06 15:15 ` Matthias Andree 2006-02-06 20:54 ` Jim Crilly 2006-02-06 17:25 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-06 15:15 UTC (permalink / raw) To: Peter Read; +Cc: Joerg Schilling, linux-kernel 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-06 15:15 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree @ 2006-02-06 20:54 ` Jim Crilly 2006-02-07 13:06 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Jim Crilly @ 2006-02-06 20:54 UTC (permalink / raw) To: Matthias Andree; +Cc: Peter Read, Joerg Schilling, linux-kernel 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-06 20:54 ` Jim Crilly @ 2006-02-07 13:06 ` Joerg Schilling 2006-02-07 13:18 ` Martin Mares ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-07 13:06 UTC (permalink / raw) To: matthias.andree, jim; +Cc: schilling, peter.read, linux-kernel "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > You're not alone, I'm still waiting for an answer as to why cdrecord is > the only userland app on any OS to use his SCSI ID naming convention > and yet his is the correct way. I've asked twice and been blatantly > ignored both times. Well, while I did explain this many times (*), I am still waiting for an explanation why Linux tries to deviate from nearly all other OS. *) in case you like are on amnesia: without the mapping in libscg, cdrecord could not be used reliably on Linux. And yes, I _do_ care about people who run Linux-2.4 or older! It seems that we should stop this discussion. As long as the peeople who answer here are onlookers without the needed skills, it seems to be a waste of time. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-07 13:06 ` Joerg Schilling @ 2006-02-07 13:18 ` Martin Mares 2006-02-07 13:47 ` Matthias Andree 2006-02-07 18:37 ` Jim Crilly 2 siblings, 0 replies; 439+ messages in thread From: Martin Mares @ 2006-02-07 13:18 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, jim, peter.read, linux-kernel Hello Joerg! > Well, while I did explain this many times (*), I am still waiting > for an explanation why Linux tries to deviate from nearly all other OS. The explanation has been given several times: the solution used by Linux solves much more than just CD recorders. I intentionally say "CD recorders", not "SCSI devices" nor even "CD drives", because I don't think I can view as a consistent solution anything which calls the same drive differently depending on whether I want to read or write a CD. I repeatedly asked you why do you think we should call the device differently for different uses and there were no replies. > *) in case you like are on amnesia: without the mapping in libscg, > cdrecord could not be used reliably on Linux. And yes, I _do_ care > about people who run Linux-2.4 or older! As you were already told, you can do it by splitting the Linux port to two, one for Linux 2.4 and older, one for the newer kernels. Some people even offered help with maintaining the Linux parts of the libscg. Except for the compatibility problems, I haven't heard any argument why it "could not be used reliably on Linux". Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth P.C.M.C.I.A. stands for `People Can't Memorize Computer Industry Acronyms' ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-07 13:06 ` Joerg Schilling 2006-02-07 13:18 ` Martin Mares @ 2006-02-07 13:47 ` Matthias Andree 2006-02-07 18:37 ` Jim Crilly 2 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-07 13:47 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel Joerg Schilling schrieb am 2006-02-07: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > You're not alone, I'm still waiting for an answer as to why cdrecord is > > the only userland app on any OS to use his SCSI ID naming convention > > and yet his is the correct way. I've asked twice and been blatantly > > ignored both times. > > Well, while I did explain this many times (*), I am still waiting > for an explanation why Linux tries to deviate from nearly all other OS. You documented differences between FreeBSD that require you to jump hoops and Solaris yourself, and still your software supports FreeBSD? > *) in case you like are on amnesia: without the mapping in libscg, > cdrecord could not be used reliably on Linux. And yes, I _do_ care > about people who run Linux-2.4 or older! What about dev=/dev/sg1 (via ide-scsi) doesn't work on Linux 2.4, except DMA for 2352 byte blocks? > It seems that we should stop this discussion. There is no obligation for you to respond. But don't expect to be taken seriously or listened to if you fleet the discussion as soon as it has become uncomfortable for you. > As long as the peeople who answer here are onlookers without the > needed skills, it seems to be a waste of time. Yes indeed. You're asked the same things a dozen times and still ignore those questions rather than giving the answers that might someone investigate the issue. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-07 13:06 ` Joerg Schilling 2006-02-07 13:18 ` Martin Mares 2006-02-07 13:47 ` Matthias Andree @ 2006-02-07 18:37 ` Jim Crilly 2006-02-08 13:27 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: Jim Crilly @ 2006-02-07 18:37 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, peter.read, linux-kernel On 02/07/06 02:06:30PM +0100, Joerg Schilling wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > You're not alone, I'm still waiting for an answer as to why cdrecord is > > the only userland app on any OS to use his SCSI ID naming convention > > and yet his is the correct way. I've asked twice and been blatantly > > ignored both times. > > Well, while I did explain this many times (*), I am still waiting > for an explanation why Linux tries to deviate from nearly all other OS. > > *) in case you like are on amnesia: without the mapping in libscg, > cdrecord could not be used reliably on Linux. And yes, I _do_ care > about people who run Linux-2.4 or older! > > > It seems that we should stop this discussion. > > As long as the peeople who answer here are onlookers without the > needed skills, it seems to be a waste of time. > > Jörg All you've explained is that using SCSI ID for device names is the way you want cdrecord to work, not why it's infinitely better than using real device names like every other userland program on every OS in existance. And please name a case where 'cdrecord dev=/dev/cdrom file.iso' won't work reliably because I, and it would seem many others, haven't run into it. there was the case where recording audio doesn't do DMA, but that's a bug in ide-scsi and I AFAIK it doesn't matter whether you use dev=/scd0 or dev=1,0,0 to address the drive. And also, I believe dev=/dev/scd0 will work with ide-scsi in 2.4, but I don't have a machine to test that on. The people replying here are your users, if you don't want to listen to them pretty much any conversation with you will be a waste of time. Jim. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-07 18:37 ` Jim Crilly @ 2006-02-08 13:27 ` Joerg Schilling [not found] ` <20060208084501.7bee86b4.seanlkml@sympatico.ca> ` (4 more replies) 0 siblings, 5 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-08 13:27 UTC (permalink / raw) To: schilling, jim; +Cc: peter.read, matthias.andree, linux-kernel "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > All you've explained is that using SCSI ID for device names is the way > you want cdrecord to work, not why it's infinitely better than using real > device names like every other userland program on every OS in existance. I did many times, but people don't seem to listen. > The people replying here are your users, if you don't want to listen to > them pretty much any conversation with you will be a waste of time. Sorry, but from reading the mail from _real_ cdrecord users, it is obvious that the people here are either not my users or users with a stange way of thinking. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
[parent not found: <20060208084501.7bee86b4.seanlkml@sympatico.ca>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <20060208084501.7bee86b4.seanlkml@sympatico.ca> @ 2006-02-08 13:45 ` sean 0 siblings, 0 replies; 439+ messages in thread From: sean @ 2006-02-08 13:45 UTC (permalink / raw) To: Joerg Schilling; +Cc: schilling, jim, peter.read, matthias.andree, linux-kernel On Wed, 08 Feb 2006 14:27:41 +0100 Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > I did many times, but people don't seem to listen. Hello Pot? This is Kettle. > Sorry, but from reading the mail from _real_ cdrecord users, it is obvious > that the people here are either not my users or users with a stange way of > thinking. Wrong. Most people on this list have probably used cdrecord at one time or another and therefore are your users. The fact that you want to pretend that everyone who disagrees with you doesn't matter suggests that it's perhaps _you_ who has a strange way of thinking. Sean ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 13:27 ` Joerg Schilling [not found] ` <20060208084501.7bee86b4.seanlkml@sympatico.ca> @ 2006-02-08 13:51 ` Martin Mares 2006-02-08 14:12 ` Keith Duthie ` (2 subsequent siblings) 4 siblings, 0 replies; 439+ messages in thread From: Martin Mares @ 2006-02-08 13:51 UTC (permalink / raw) To: Joerg Schilling; +Cc: jim, peter.read, matthias.andree, linux-kernel Hello! > Sorry, but from reading the mail from _real_ cdrecord users, it is obvious > that the people here are either not my users or users with a stange way of > thinking. Then, probably, almost everybody has a strange way of thinking. Almost everybody around here (mostly experienced users, not programmers) considers the device numbering used by cdrecord extremely impractical. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth A Bash poem: time for echo in canyon; do echo $echo $echo; done ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 13:27 ` Joerg Schilling [not found] ` <20060208084501.7bee86b4.seanlkml@sympatico.ca> 2006-02-08 13:51 ` Martin Mares @ 2006-02-08 14:12 ` Keith Duthie 2006-02-08 16:28 ` Jim Crilly 2006-02-08 21:02 ` DervishD 4 siblings, 0 replies; 439+ messages in thread From: Keith Duthie @ 2006-02-08 14:12 UTC (permalink / raw) To: Joerg Schilling; +Cc: jim, peter.read, matthias.andree, linux-kernel 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? ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 13:27 ` Joerg Schilling ` (2 preceding siblings ...) 2006-02-08 14:12 ` Keith Duthie @ 2006-02-08 16:28 ` Jim Crilly 2006-02-08 16:32 ` Joerg Schilling 2006-02-08 21:02 ` DervishD 4 siblings, 1 reply; 439+ messages in thread From: Jim Crilly @ 2006-02-08 16:28 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, linux-kernel On 02/08/06 02:27:41PM +0100, Joerg Schilling wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > All you've explained is that using SCSI ID for device names is the way > > you want cdrecord to work, not why it's infinitely better than using real > > device names like every other userland program on every OS in existance. > > I did many times, but people don't seem to listen. But you've never answered the question as to why every other userland program on every OS uses device names when cdrecord insists on using SCSI IDs. Do you really think mount, fsck, tar, etc are broken because they let the user use device names that they're accustomed to like /dev/c0t0d0s0? If so, I look forward to the day that you try to patch OpenSolaris' userland to work like cdrecord. > > The people replying here are your users, if you don't want to listen to > > them pretty much any conversation with you will be a waste of time. > > Sorry, but from reading the mail from _real_ cdrecord users, it is obvious > that the people here are either not my users or users with a stange way of > thinking. I think it's safe to say that most Linux users are cdrecord users whether they want to be or not, there's just not any real viable alternatives except for dvd+rw-tools and they don't work with regular CDs AFAIK. And if you consider it strange to expect tools to accept normal device names for the devices they're interacting with, I guess there's not much hope of ever getting cdrecord fixed. Jim. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 16:28 ` Jim Crilly @ 2006-02-08 16:32 ` Joerg Schilling 2006-02-08 16:53 ` Jim Crilly ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-08 16:32 UTC (permalink / raw) To: schilling, jim; +Cc: peter.read, matthias.andree, linux-kernel "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > On 02/08/06 02:27:41PM +0100, Joerg Schilling wrote: > > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > > > All you've explained is that using SCSI ID for device names is the way > > > you want cdrecord to work, not why it's infinitely better than using real > > > device names like every other userland program on every OS in existance. > > > > I did many times, but people don't seem to listen. > > But you've never answered the question as to why every other userland > program on every OS uses device names when cdrecord insists on using SCSI > IDs. Do you really think mount, fsck, tar, etc are broken because they let > the user use device names that they're accustomed to like /dev/c0t0d0s0? If > so, I look forward to the day that you try to patch OpenSolaris' userland > to work like cdrecord. You just verify that you don't listen... I did answer this many times and I will not repeat it another time. Note that you are of course wrong with your statement on other CD/DVD writing software. What you like to see does not work at all on MS-WIN. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 16:32 ` Joerg Schilling @ 2006-02-08 16:53 ` Jim Crilly 2006-02-09 9:39 ` Joerg Schilling 2006-02-08 22:52 ` Martin Mares [not found] ` <43EA2A58.9070501@gmx.de> 2 siblings, 1 reply; 439+ messages in thread From: Jim Crilly @ 2006-02-08 16:53 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, linux-kernel On 02/08/06 05:32:38PM +0100, Joerg Schilling wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > On 02/08/06 02:27:41PM +0100, Joerg Schilling wrote: > > > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > > > > > All you've explained is that using SCSI ID for device names is the way > > > > you want cdrecord to work, not why it's infinitely better than using real > > > > device names like every other userland program on every OS in existance. > > > > > > I did many times, but people don't seem to listen. > > > > But you've never answered the question as to why every other userland > > program on every OS uses device names when cdrecord insists on using SCSI > > IDs. Do you really think mount, fsck, tar, etc are broken because they let > > the user use device names that they're accustomed to like /dev/c0t0d0s0? If > > so, I look forward to the day that you try to patch OpenSolaris' userland > > to work like cdrecord. > > You just verify that you don't listen... Yes, I have been listening and I haven't seen you list one reason why cdrecord absolutely has to use SCSI IDs when fsck can get away with using /dev/blah just fine. > I did answer this many times and I will not repeat it another time. > > Note that you are of course wrong with your statement on other CD/DVD writing > software. And of course you won't tell me exactly what I'm wrong about and/or point me to some proof because then you might actually come off as helpful. > What you like to see does not work at all on MS-WIN. That's not my problem, but I would assume that Windows users would also rather use a meaningful name like dev=D: instead of some random SCSI ID. Jim. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 16:53 ` Jim Crilly @ 2006-02-09 9:39 ` Joerg Schilling 2006-02-09 10:00 ` Martin Mares ` (4 more replies) 0 siblings, 5 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 9:39 UTC (permalink / raw) To: schilling, jim; +Cc: peter.read, matthias.andree, linux-kernel "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > You just verify that you don't listen... > > Yes, I have been listening and I haven't seen you list one reason why > cdrecord absolutely has to use SCSI IDs when fsck can get away with using > /dev/blah just fine. Are you _really_ missing basic know how to understand that fsck is using the block layer of a virtual "block device" emulated by UNIX while libscg is offering _direct_ acces to _any_ type of device allowing you to send _commands_ understood by the device? fsck is just sending abstract instructions to a virtual device and does not care about Please explain me: - how to use /dev/hd* in order to scan an image from a scanner - how to use /dev/hd* in order to talk to a CPU device - how to use /dev/hd* in order to talk to a tape device - how to use /dev/hd* in order to talk to a printer - how to use /dev/hd* in order to talk to a jukebox - how to use /dev/hd* in order to talk to a graphical device Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 9:39 ` Joerg Schilling @ 2006-02-09 10:00 ` Martin Mares 2006-02-09 23:14 ` Kyle Moffett 2006-02-09 10:41 ` Matthias Andree ` (3 subsequent siblings) 4 siblings, 1 reply; 439+ messages in thread From: Martin Mares @ 2006-02-09 10:00 UTC (permalink / raw) To: Joerg Schilling; +Cc: jim, peter.read, matthias.andree, linux-kernel Hello! > Please explain me: > > - how to use /dev/hd* in order to scan an image from a scanner > - how to use /dev/hd* in order to talk to a CPU device > - how to use /dev/hd* in order to talk to a tape device > - how to use /dev/hd* in order to talk to a printer > - how to use /dev/hd* in order to talk to a jukebox > - how to use /dev/hd* in order to talk to a graphical device Nobody speaks about using /dev/hd* for all that, just about that there always will be a /dev/something corresponding to the device. Also, as you have mentioned /dev/hd*, it seems that you consider all these devices connected over ATAPI. Again an exercise in mythical zoology as in the ATAPI tape example. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth For every complex problem, there's a solution that is simple, neat and wrong. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 10:00 ` Martin Mares @ 2006-02-09 23:14 ` Kyle Moffett 2006-02-10 1:52 ` Jim Crilly 2006-02-10 12:15 ` Joerg Schilling 0 siblings, 2 replies; 439+ messages in thread From: Kyle Moffett @ 2006-02-09 23:14 UTC (permalink / raw) To: Joerg Schilling Cc: Martin Mares, jim, peter.read, Matthias Andree, LKML Kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 23:14 ` Kyle Moffett @ 2006-02-10 1:52 ` Jim Crilly 2006-02-10 12:24 ` Joerg Schilling 2006-02-10 12:15 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Jim Crilly @ 2006-02-10 1:52 UTC (permalink / raw) To: Kyle Moffett Cc: Joerg Schilling, Martin Mares, peter.read, Matthias Andree, LKML Kernel 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 1:52 ` Jim Crilly @ 2006-02-10 12:24 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 12:24 UTC (permalink / raw) To: mrmacman_g4, jim; +Cc: schilling, peter.read, mj, matthias.andree, linux-kernel "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > On 02/09/06 06:14:40PM -0500, Kyle Moffett wrote: > > Does cdrecord talk to CPU devices? No! Why do you care? BTW: What > > the hell is a "CPU device" and why the hell would you think you could > > talk to it through a disk interface, let alone some other random SCSI > > interface? > > > > We have several fiber controllers and the controller itself does show up as > a SCSI device that sg can bind to, I believe the management software can > actually manage the storage via that node but we've never used it and I > highly doubt anyone uses cdrecord or libscg for that purpose. In fact, a "CPU device" (*) was it, that did give the initial push for my SCSI activities in January 1985 and that did lead to the first SCSI genric driver /dev/scg and libscg in August 1986. *) Really a scanner but Scanner devices had not been defined by the SCSI stabdard in 1985. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 23:14 ` Kyle Moffett 2006-02-10 1:52 ` Jim Crilly @ 2006-02-10 12:15 ` Joerg Schilling 2006-02-09 12:37 ` D. Hazelton 2006-02-10 16:32 ` Luke-Jr 1 sibling, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 12:15 UTC (permalink / raw) To: schilling, mrmacman_g4; +Cc: peter.read, mj, matthias.andree, linux-kernel, jim Kyle Moffett <mrmacman_g4@mac.com> wrote: > Joerg Schilling wrote: > > - how to use /dev/hd* in order to scan an image from a scanner > > - how to use /dev/hd* in order to talk to a printer > > - how to use /dev/hd* in order to talk to a jukebox > > - how to use /dev/hd* in order to talk to a graphical device > > Does cdrecord scan images, print files, or talk to SCSI graphical Are you _completely_ ingnoring the facts that have been discused here? This does not apply to cdrecord but to libscg. You either need to approach reality or stop this thread. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:15 ` Joerg Schilling @ 2006-02-09 12:37 ` D. Hazelton 2006-02-10 13:02 ` Christoph Hellwig 2006-02-10 16:32 ` Luke-Jr 1 sibling, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-09 12:37 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, peter.read, mj, matthias.andree, linux-kernel, jim On Friday 10 February 2006 07:15, Joerg Schilling wrote: > Kyle Moffett <mrmacman_g4@mac.com> wrote: > > Joerg Schilling wrote: > > > - how to use /dev/hd* in order to scan an image from a scanner > > > - how to use /dev/hd* in order to talk to a printer > > > - how to use /dev/hd* in order to talk to a jukebox > > > - how to use /dev/hd* in order to talk to a graphical device > > > > Does cdrecord scan images, print files, or talk to SCSI graphical > > Are you _completely_ ingnoring the facts that have been discused here? > > This does not apply to cdrecord but to libscg. > > You either need to approach reality or stop this thread. I've taken the time to look through the libscg code and I see only one reason why it needs to use the BTL mappings at all - Joerg has a clean interface that is consistent across all the platforms. Not that I'm going to defend him. I've kept quiet and tracked this thread from the beginning, hoping he would "see the light" as it were and realise that he can export a stable interface across almost all platforms with a few ifdefs and a bit of trickery to use various OS quirks to handle the work. I am no expert on Windows, so I cannot comment on that, but I can, have and do read relevant sections of the POSIX and SuS when looking at problems and know that the _proper_, _portable_ and _UNIX_ way of accessing devices is via the block device special file. For SCSI cd burners the only way (I know of) to access them for writing (as /dev/sr0 cannot be opened for "write") is via the "SCSI Generic" (/dev/sg*) nodes, and to find and cross-map which /dev/sr* is which /dev/sg* is by the BTL. Needless to say, that should all be transparent to the user. And, much to my surprise, Joerg's assertion that using /dev/hd* for accessing ATA/PI devices would require patching libscg is bunk. All he'd have to do is modify cdrecord to _internally_ (if it has to) perform the BTL mapping it wants. What's more, said interface code can be compiled out if it isn't a Linux system with a simple ifdef. But please note that libscg _is_ a generic SCSI access library. If needed it _can_ be used to access any SCSI device (and any ATA/PI device, at this point) via hand-crafted command packets. Not useful to the generic programmer, who is happy with the interfaces an OS provides, but for people doing things like data forensics... (No disrespect meant for anyone, but if my tone comes off a bit rant-like it's because I'm sick of seeing one developer (of a GPL'd program) drag so many people down.) DRH PS: If I thought I had the knowledge of SCSI/ATAPI protocol to do so, I'd fork the code myself. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 12:37 ` D. Hazelton @ 2006-02-10 13:02 ` Christoph Hellwig 2006-02-17 20:55 ` Bill Davidsen 0 siblings, 1 reply; 439+ messages in thread From: Christoph Hellwig @ 2006-02-10 13:02 UTC (permalink / raw) To: D. Hazelton Cc: mrmacman_g4, peter.read, mj, matthias.andree, linux-kernel, jim 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 13:02 ` Christoph Hellwig @ 2006-02-17 20:55 ` Bill Davidsen 2006-02-17 21:01 ` Christoph Hellwig 0 siblings, 1 reply; 439+ messages in thread From: Bill Davidsen @ 2006-02-17 20:55 UTC (permalink / raw) To: Christoph Hellwig, D. Hazelton, mrmacman_g4, peter.read, mj, matthias.andree, linux-kernel, jim Christoph Hellwig wrote: > You can access SCSI CDs using /dev/sr* for burning CDs. It's backed by the > same highlevel code as SG_IO on /dev/hd* while the lowerlevel handling is > done transparently by the scsi midlayer, the same code used by /dev/sg* for > the below-blocklayer handling. > This may be true if you create your own /dev entries, or are a udev guru and can get it to generate the right entries. And if you use ATAPI devices it works fine... But with Fedora and SuSE it appears that USB devices which appear as SCSI aren't functional. I tested the Fedora myself, and after killing udevd and making some entries by hand it worked once. Now if you can access SCSI burners more power to you, with FC4 up to recent updates, my one convenient real SCSI device most definitely doesn't work, and I havd to fall the system back to Slackware and 2.4 which was on it before. Because you know how to get around the problems doesn't really suggest that there aren't any. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 20:55 ` Bill Davidsen @ 2006-02-17 21:01 ` Christoph Hellwig 2006-02-18 16:44 ` Bill Davidsen 0 siblings, 1 reply; 439+ messages in thread From: Christoph Hellwig @ 2006-02-17 21:01 UTC (permalink / raw) To: Bill Davidsen Cc: Christoph Hellwig, D. Hazelton, mrmacman_g4, peter.read, mj, matthias.andree, linux-kernel, jim 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 21:01 ` Christoph Hellwig @ 2006-02-18 16:44 ` Bill Davidsen [not found] ` <20060218115802.739dc947.seanlkml@sympatico.ca> 0 siblings, 1 reply; 439+ messages in thread From: Bill Davidsen @ 2006-02-18 16:44 UTC (permalink / raw) To: Christoph Hellwig Cc: D. Hazelton, mrmacman_g4, peter.read, mj, matthias.andree, linux-kernel, jim Christoph Hellwig wrote: >On Fri, Feb 17, 2006 at 03:55:34PM -0500, Bill Davidsen wrote: > > >>Christoph Hellwig wrote: >> >> >> >>>You can access SCSI CDs using /dev/sr* for burning CDs. It's backed by >>>the >>>same highlevel code as SG_IO on /dev/hd* while the lowerlevel handling is >>>done transparently by the scsi midlayer, the same code used by /dev/sg* >>>for >>>the below-blocklayer handling. >>> >>> >>> >>This may be true if you create your own /dev entries, or are a udev guru >>and can get it to generate the right entries. And if you use ATAPI >>devices it works fine... But with Fedora and SuSE it appears that USB >>devices which appear as SCSI aren't functional. I tested the Fedora >>myself, and after killing udevd and making some entries by hand it >>worked once. >> >>Now if you can access SCSI burners more power to you, with FC4 up to >>recent updates, my one convenient real SCSI device most definitely >>doesn't work, and I havd to fall the system back to Slackware and 2.4 >>which was on it before. >> >>Because you know how to get around the problems doesn't really suggest >>that there aren't any. >> >> > >How are the dev entires related to CD burning? If the device entries >don't appear for you that's a problem, but you deserve what you get >for using a POS like udev. If you have a sd or sr node you can use >SG_IO on it, period. Whether you can actually burn a CD of course >depends on the capability of the device. I don't have a CD burner >connected through usb, but I couldn't think of a reason the usb <-> atapi >bridge would make problems with the scsi commands used to burn a CD. > > > I'm sorry if I didn't make that clear. Some developers are saying that the application shouldn't be finding devices because udev does that so it doesn't matter that doing device location in the application is complex and poorly defined because udev does it for you. I was making the point that in the most common distributions (Fedora and SuSE) pluggable burners don't get proper entries in /dev to make cdrecord work. Based on a single report sent directly to me that seems to be the case in ubuntu as well, but I haven't personally tried it. I was refuting the claim that applications no longer need to find their own devices; in many cases they do. Burning using the USB devices works fine if the right devices are found and created. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 ^ permalink raw reply [flat|nested] 439+ messages in thread
[parent not found: <20060218115802.739dc947.seanlkml@sympatico.ca>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <20060218115802.739dc947.seanlkml@sympatico.ca> @ 2006-02-18 16:58 ` sean 0 siblings, 0 replies; 439+ messages in thread From: sean @ 2006-02-18 16:58 UTC (permalink / raw) To: Bill Davidsen Cc: hch, dhazelton, mrmacman_g4, peter.read, mj, matthias.andree, linux-kernel, jim On Sat, 18 Feb 2006 11:44:25 -0500 Bill Davidsen <davidsen@tmr.com> wrote: > I'm sorry if I didn't make that clear. Some developers are saying that > the application shouldn't be finding devices because udev does that so > it doesn't matter that doing device location in the application is > complex and poorly defined because udev does it for you. I was making > the point that in the most common distributions (Fedora and SuSE) > pluggable burners don't get proper entries in /dev to make cdrecord > work. Based on a single report sent directly to me that seems to be the > case in ubuntu as well, but I haven't personally tried it. For whatever its worth, every burner i've ever tried on a Fedora box has just worked. But you misunderstand, people aren't saying udev is the only answer; they're just saying device nodes must exist. It's up to each distro to decide how that happens; and then for user space to decide how those device nodes are passed to each application. > I was refuting the claim that applications no longer need to find their > own devices; in many cases they do. As has been shown, everything needed for device enumeration is already available to user space. Completing the job of making device enumeration easy for applications remains for user space services such as HAL et. al. not the kernel. > Burning using the USB devices works fine if the right devices are found > and created. Yes, and if any device isn't found and created properly it's a bug that should be fixed, not something which can be used to support Joerg's archaic ideas. Sean ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:15 ` Joerg Schilling 2006-02-09 12:37 ` D. Hazelton @ 2006-02-10 16:32 ` Luke-Jr 1 sibling, 0 replies; 439+ messages in thread From: Luke-Jr @ 2006-02-10 16:32 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, peter.read, mj, matthias.andree, linux-kernel, jim On Friday 10 February 2006 12:15, Joerg Schilling wrote: > Kyle Moffett <mrmacman_g4@mac.com> wrote: > > Joerg Schilling wrote: > > > - how to use /dev/hd* in order to scan an image from a scanner > > > - how to use /dev/hd* in order to talk to a printer > > > - how to use /dev/hd* in order to talk to a jukebox > > > - how to use /dev/hd* in order to talk to a graphical device > > > > Does cdrecord scan images, print files, or talk to SCSI graphical > > Are you _completely_ ingnoring the facts that have been discused here? Are you completely ignoring that nobody in this thread cares about libscg's ability to work with other devices? The problem is in the user-interface, and underlying workings is really pretty irrelevant to the matter. > This does not apply to cdrecord but to libscg. cdrecord contains the UI, so it is the only program relevant to the problem. If libscg is impeding fixing the bug (I don't think it is, but you seem to), then maybe cdrecord should use transport.hxx from growisofs. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 9:39 ` Joerg Schilling 2006-02-09 10:00 ` Martin Mares @ 2006-02-09 10:41 ` Matthias Andree 2006-02-09 13:35 ` Joerg Schilling 2006-02-09 10:50 ` Ralf Müller ` (2 subsequent siblings) 4 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-09 10:41 UTC (permalink / raw) To: Joerg Schilling; +Cc: jim, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 10:41 ` Matthias Andree @ 2006-02-09 13:35 ` Joerg Schilling 2006-02-09 14:00 ` Nick Piggin 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 13:35 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel, jim Matthias Andree <matthias.andree@gmx.de> wrote: > This all only matters to you since you are trying to enforce the botched > view from some other OS (MS-Windows perhaps, although I'm not too sure > if it's really Windows or Jörg Schilling who is the problem in this > scenario either, and I'm a long way from defending Microsoft) onto > Linux, which you have been denied for 1½ years now, and from what I've > seen this year, with good reason. You look confused. It is not me but the Linux maintainers refuse to fix bugs since about 2 years. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 13:35 ` Joerg Schilling @ 2006-02-09 14:00 ` Nick Piggin 0 siblings, 0 replies; 439+ messages in thread From: Nick Piggin @ 2006-02-09 14:00 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, jim Hi Joerg, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > >>This all only matters to you since you are trying to enforce the botched >>view from some other OS (MS-Windows perhaps, although I'm not too sure >>if it's really Windows or Jörg Schilling who is the problem in this >>scenario either, and I'm a long way from defending Microsoft) onto >>Linux, which you have been denied for 1½ years now, and from what I've >>seen this year, with good reason. > > > You look confused. It is not me but the Linux maintainers refuse to fix > bugs since about 2 years. > Regardless of whether you consider it a bug or the naming wrong[1], you are not the Linux maintainer and Linux users have to put up with their choices of kernel architecture. So introducing your own naming scheme AFAIKS only serves to add more confusion to the picture -- it seems fairly unlikely that you'll get the kernel guys to change their minds. Goes along the same lines as my point about filesystem naming. I wouldn't write a portable program that asks users to save their files on /dev/hda or /c_drive/blah when on windows. I'd agree to disagree with wnidows, and use C:\ for the sake of everyone's sanity. [1] I don't want to argue *that* point with you and I don't pretend to know more about it than you or anyone else on this thread. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 9:39 ` Joerg Schilling 2006-02-09 10:00 ` Martin Mares 2006-02-09 10:41 ` Matthias Andree @ 2006-02-09 10:50 ` Ralf Müller 2006-02-09 16:30 ` Jan Engelhardt 2006-02-10 4:49 ` Alexander Samad 4 siblings, 0 replies; 439+ messages in thread From: Ralf Müller @ 2006-02-09 10:50 UTC (permalink / raw) To: linux-kernel; +Cc: Joerg Schilling [-- Attachment #1: Type: text/plain, Size: 2290 bytes --] On Donnerstag 09 Februar 2006 10:39, you wrote: > Are you _really_ missing basic know how to understand that fsck is > using the block layer of a virtual "block device" emulated by UNIX > while libscg is offering _direct_ acces to _any_ type of device > allowing you to send _commands_ understood by the device? You mix things up. As this thread is about writing CD's and cdrecord, nobody here really wants you to use libscg to do your IO. Nobody here wants cdrecord to be able to access any type of device - all of the users of cdrecord just care about CD writers (and maybe DVD writers). That is because you call your program cdrecord and not scanimage oder cpuinfo. Actually none of the users of cdrecord even cares about how it is able to talk to CD writers. They know that all other operations to the CD writer can be done via /dev/cdrw, or however it is called on their system, and would like to use the same device name to write a CD. If libscg is unable to handle device names and needs to be feed with strange numbers to address the writer, then libscg may be the wrong tool. > Please explain me: > > - how to use /dev/hd* in order to scan an image from a scanner > > - how to use /dev/hd* in order to talk to a CPU device > > - how to use /dev/hd* in order to talk to a tape device > > - how to use /dev/hd* in order to talk to a printer > > - how to use /dev/hd* in order to talk to a jukebox > > - how to use /dev/hd* in order to talk to a graphical device I don't expect cdrecord to be able to do any of these jobs. I'd just like to write a CD. To be honest - even if libscg would be able to peel carrots I couldn't care less. As for cdrecord I'm just one of those stupid users. I have a problem (write a CD) - I'd like to solve this problem. And if the device addressing scheme of cdrecord is different to all I've seen before from all the other tools in my system, I blame cdrecord to be annoying not the rest of my system - just because I have to investigate how to deal with this program, instead of just being able to use it like all the rest. My 2 cents Ralf -- Van Roy's Law: ------------------------------------------------------- An unbreakable toy is useful for breaking other toys. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 9:39 ` Joerg Schilling ` (2 preceding siblings ...) 2006-02-09 10:50 ` Ralf Müller @ 2006-02-09 16:30 ` Jan Engelhardt 2006-02-09 16:47 ` Joerg Schilling 2006-02-09 17:15 ` Matthias Andree 2006-02-10 4:49 ` Alexander Samad 4 siblings, 2 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-09 16:30 UTC (permalink / raw) To: Joerg Schilling; +Cc: jim, peter.read, matthias.andree, linux-kernel >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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 16:30 ` Jan Engelhardt @ 2006-02-09 16:47 ` Joerg Schilling 2006-02-09 17:15 ` Jan Engelhardt 2006-02-09 17:15 ` Matthias Andree 1 sibling, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 16:47 UTC (permalink / raw) To: schilling, jengelh; +Cc: peter.read, matthias.andree, linux-kernel, jim Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >Please explain me: > > > >- how to use /dev/hd* in order to scan an image from a scanner > >- how to use /dev/hd* in order to talk to a CPU device > >- how to use /dev/hd* in order to talk to a tape device > >- how to use /dev/hd* in order to talk to a printer > >- how to use /dev/hd* in order to talk to a jukebox > >- how to use /dev/hd* in order to talk to a graphical device > > > With /dev/sg, this was possible? Of course! Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 16:47 ` Joerg Schilling @ 2006-02-09 17:15 ` Jan Engelhardt 2006-02-09 17:28 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Jan Engelhardt @ 2006-02-09 17:15 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, linux-kernel, jim >> >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/ ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 17:15 ` Jan Engelhardt @ 2006-02-09 17:28 ` Joerg Schilling 2006-02-09 17:36 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 17:28 UTC (permalink / raw) To: schilling, jengelh; +Cc: peter.read, matthias.andree, linux-kernel, jim Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >> >Please explain me: > >> > > >> >- how to use /dev/hd* in order to scan an image from a scanner > >> >- how to use /dev/hd* in order to talk to a CPU device > >> >- how to use /dev/hd* in order to talk to a tape device > >> >- how to use /dev/hd* in order to talk to a printer > >> >- how to use /dev/hd* in order to talk to a jukebox > >> >- how to use /dev/hd* in order to talk to a graphical device > >> > > >> With /dev/sg, this was possible? > > > >Of course! > > > But you need to open the correct /dev/sg[0-9] too, don't you? > (otherwise cdrecord would set the jukebox on fire) This is why the mapping engine is in the Linux adoption part of libscg. It maps the non-stable device <-> /dev/sg* relation to a stable b,t,l address. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 17:28 ` Joerg Schilling @ 2006-02-09 17:36 ` Matthias Andree 2006-02-09 17:37 ` Jan Engelhardt 2006-02-10 10:58 ` CD writing in future Linux (stirring up a hornets' nest) Joerg Schilling 2006-02-09 17:36 ` Martin Mares 2006-02-09 17:36 ` Jan Engelhardt 2 siblings, 2 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-09 17:36 UTC (permalink / raw) To: Joerg Schilling; +Cc: jengelh, peter.read, linux-kernel, jim Joerg Schilling wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >>>>> Please explain me: >>>>> >>>>> - how to use /dev/hd* in order to scan an image from a scanner >>>>> - how to use /dev/hd* in order to talk to a CPU device >>>>> - how to use /dev/hd* in order to talk to a tape device >>>>> - how to use /dev/hd* in order to talk to a printer >>>>> - how to use /dev/hd* in order to talk to a jukebox >>>>> - how to use /dev/hd* in order to talk to a graphical device >>>>> >>>> With /dev/sg, this was possible? >>> Of course! >>> >> But you need to open the correct /dev/sg[0-9] too, don't you? >> (otherwise cdrecord would set the jukebox on fire) > > This is why the mapping engine is in the Linux adoption part of > libscg. It maps the non-stable device <-> /dev/sg* relation to a > stable b,t,l address. Well, the b,t,l mapping, judging from libscg code, is as stable as the ordering of the device nodes themselves, so it is not clear what the advantage would be other than getting a uniform and artificial b,t,l mapping. If hotplugging shuffles /dev/sg* between running $APPLICATION -scanbus and $APPLICATION -dowhatever, the b,t,l will change as well. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 17:36 ` Matthias Andree @ 2006-02-09 17:37 ` Jan Engelhardt 2006-02-09 21:57 ` CD writing in future Linux Jan Engelhardt 2006-02-10 10:58 ` CD writing in future Linux (stirring up a hornets' nest) Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Jan Engelhardt @ 2006-02-09 17:37 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, peter.read, linux-kernel, jim >>>> >>> 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux 2006-02-09 17:37 ` Jan Engelhardt @ 2006-02-09 21:57 ` Jan Engelhardt 0 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-09 21:57 UTC (permalink / raw) Cc: Linux Kernel Mailing List >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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 17:36 ` Matthias Andree 2006-02-09 17:37 ` Jan Engelhardt @ 2006-02-10 10:58 ` Joerg Schilling 1 sibling, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 10:58 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: peter.read, linux-kernel, jim, jengelh Matthias Andree <matthias.andree@gmx.de> wrote: > > This is why the mapping engine is in the Linux adoption part of > > libscg. It maps the non-stable device <-> /dev/sg* relation to a > > stable b,t,l address. > > Well, the b,t,l mapping, judging from libscg code, is as stable as the > ordering of the device nodes themselves, so it is not clear what the > advantage would be other than getting a uniform and artificial b,t,l mapping. It would help a lot if you at least _try_ to inform yourself before posting. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 17:28 ` Joerg Schilling 2006-02-09 17:36 ` Matthias Andree @ 2006-02-09 17:36 ` Martin Mares 2006-02-10 10:59 ` Joerg Schilling 2006-02-09 17:36 ` Jan Engelhardt 2 siblings, 1 reply; 439+ messages in thread From: Martin Mares @ 2006-02-09 17:36 UTC (permalink / raw) To: Joerg Schilling; +Cc: jengelh, peter.read, matthias.andree, linux-kernel, jim Hello! > This is why the mapping engine is in the Linux adoption part of > libscg. It maps the non-stable device <-> /dev/sg* relation to a > stable b,t,l address. Nonsense. The b,t,l addresses are NOT stable (at least for transports where the kernel would have to make them up) unless you take an extra effort to make them stable (like I understand Solaris does). But you can use the same extra effort to make the /dev entries stable (like udev does). Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth COBOL -- Compiles Only Because Of Luck ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 17:36 ` Martin Mares @ 2006-02-10 10:59 ` Joerg Schilling 2006-02-10 11:47 ` Matthias Andree 2006-02-10 11:49 ` DervishD 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 10:59 UTC (permalink / raw) To: schilling, mj; +Cc: peter.read, matthias.andree, linux-kernel, jim, jengelh Martin Mares <mj@ucw.cz> wrote: > Hello! > > > This is why the mapping engine is in the Linux adoption part of > > libscg. It maps the non-stable device <-> /dev/sg* relation to a > > stable b,t,l address. > > Nonsense. The b,t,l addresses are NOT stable (at least for transports Dou you like to verify that you have no clue on SCSI? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 10:59 ` Joerg Schilling @ 2006-02-10 11:47 ` Matthias Andree 2006-02-10 12:35 ` Joerg Schilling 2006-02-10 11:49 ` DervishD 1 sibling, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-10 11:47 UTC (permalink / raw) To: Joerg Schilling Cc: mj, peter.read, matthias.andree, linux-kernel, jim, jengelh Joerg Schilling schrieb am 2006-02-10: > Martin Mares <mj@ucw.cz> wrote: > > > Hello! > > > > > This is why the mapping engine is in the Linux adoption part of > > > libscg. It maps the non-stable device <-> /dev/sg* relation to a > > > stable b,t,l address. > > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports > > Dou you like to verify that you have no clue on SCSI? How does, for instance, libscg make sure that the b,t,l mappings are hotplug invariant? How does libscg make sure that two external writers, say USB, retain their b,t,l mappings if both are unplugged and then replugged in reverse order, perhaps into different USB hubs? What assumptions does libscg (or cdrecord) make to procure stable mappings? You complained the discussion were non-technical, yet rather than correcting false information at detail scale, you resort to personal insults, and I think you're standing on pretty thin ice with those attacks. Your credibility is about to reach zero. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 11:47 ` Matthias Andree @ 2006-02-10 12:35 ` Joerg Schilling 2006-02-09 12:57 ` D. Hazelton ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 12:35 UTC (permalink / raw) To: schilling, matthias.andree Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh Matthias Andree <matthias.andree@gmx.de> wrote: > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports > > > > Dou you like to verify that you have no clue on SCSI? > > How does, for instance, libscg make sure that the b,t,l mappings are > hotplug invariant? > > How does libscg make sure that two external writers, say USB, retain > their b,t,l mappings if both are unplugged and then replugged in reverse > order, perhaps into different USB hubs? Well, this is a deficit of the Linux kernel - not libscg. If you are unhappy with Hot plug support on Linux, I recommend you to check Solaris. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:35 ` Joerg Schilling @ 2006-02-09 12:57 ` D. Hazelton 2006-02-10 13:03 ` Joerg Schilling 2006-02-10 12:41 ` Martin Mares 2006-02-10 22:40 ` Matthias Andree 2 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-09 12:57 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, peter.read, mj, linux-kernel, jim, jengelh On Friday 10 February 2006 07:35, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports > > > > > > Dou you like to verify that you have no clue on SCSI? > > > > How does, for instance, libscg make sure that the b,t,l mappings are > > hotplug invariant? > > > > How does libscg make sure that two external writers, say USB, retain > > their b,t,l mappings if both are unplugged and then replugged in reverse > > order, perhaps into different USB hubs? > > Well, this is a deficit of the Linux kernel - not libscg. > > If you are unhappy with Hot plug support on Linux, I recommend you to > check Solaris. > > Jörg I've replied once already, but this is going to far. Joerg, if you are so unhappy with Linux that you'd actively tell people on the _LINUX_KERNEL_ mailing list to go use another OS then you have a problem. If, however, you have a point to make, make it. I switched to Linux _completely_ before it even supported the box I was running fully back around kernel 2.0.24 and had run it alongside windows since late in Kernel 1 series. The system has evolved, gotten faster, better and more standards compliant. Then you come along with this teutonic "I'm the Perfect Programmer" BS and expect everyone to change the way something works just for _your_ library. I'm sorry but that is, and I'm being nice here, childish. Programs and libraries *_DO_* *_NOT_* define how an OS does things, they use the framework the OS supplies and work within it. With that in mind I'll say the last thing I ever will on this subject - Your code is broken if it does things in a way that is non-standard to the OS. And does cdrecord even need libscg anymore? From having actually gone through your code, Joerg, I can tell you that it does serve a larger purpose. But at this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_ writing programs, does _ANYONE_ use libscg? Is it ever used to access any other devices that are either SCSI or use a SCSI command protocol (like ATAPI)? My point there is that you have a wonderful library, but despite your wishes, there is no proof that it is ever used for anything except writing/ripping CD's. If anything, the best solution would be to split libscg away from the cdrtools package and release it on it's own. You do that and it might even make the SANE people happy. All the cdrtools package needs is an interface library for CDR/RW stuff and having the code capable of doing anything else is merely bloat. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 12:57 ` D. Hazelton @ 2006-02-10 13:03 ` Joerg Schilling 2006-02-10 3:21 ` D. Hazelton ` (4 more replies) 0 siblings, 5 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 13:03 UTC (permalink / raw) To: schilling, dhazelton Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh "D. Hazelton" <dhazelton@enter.net> wrote: > And does cdrecord even need libscg anymore? From having actually gone through > your code, Joerg, I can tell you that it does serve a larger purpose. But at > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_ > writing programs, does _ANYONE_ use libscg? Is it ever used to access any > other devices that are either SCSI or use a SCSI command protocol (like > ATAPI)? My point there is that you have a wonderful library, but despite > your wishes, there is no proof that it is ever used for anything except > writing/ripping CD's. Name a single program (not using libscg) that implements user space SCSI and runs on as many platforms as cdrecord/libscg does. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 13:03 ` Joerg Schilling @ 2006-02-10 3:21 ` D. Hazelton 2006-02-13 13:40 ` Joerg Schilling 2006-02-10 13:25 ` Dmitry Torokhov ` (3 subsequent siblings) 4 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-10 3:21 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Friday 10 February 2006 08:03, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > And does cdrecord even need libscg anymore? From having actually gone > > through your code, Joerg, I can tell you that it does serve a larger > > purpose. But at this point I have to ask - besides cdrecord and a few > > other _COMPACT_ _DISC_ writing programs, does _ANYONE_ use libscg? Is it > > ever used to access any other devices that are either SCSI or use a SCSI > > command protocol (like ATAPI)? My point there is that you have a > > wonderful library, but despite your wishes, there is no proof that it is > > ever used for anything except writing/ripping CD's. > > Name a single program (not using libscg) that implements user space SCSI > and runs on as many platforms as cdrecord/libscg does. I'm not the maintainer of a program, and hence I don't have to. But why in the hell do you even _need_ SCSI in userspace when the kernel provides complete facilities? And even then your argument is specious, since when I did go through the code for libscg all it provided was a simple wrapper around those kernel facilities for as many OS's as had them. And for the OS's that didn't have it, then you implemented what you could. You really need to stop with the finger pointing and accept that you have a problem in your philosophy. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 3:21 ` D. Hazelton @ 2006-02-13 13:40 ` Joerg Schilling 2006-02-13 13:52 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 13:40 UTC (permalink / raw) To: schilling, dhazelton Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh "D. Hazelton" <dhazelton@enter.net> wrote: > > Name a single program (not using libscg) that implements user space SCSI > > and runs on as many platforms as cdrecord/libscg does. > > I'm not the maintainer of a program, and hence I don't have to. > > But why in the hell do you even _need_ SCSI in userspace when the kernel > provides complete facilities? And even then your argument is specious, since Then please try to inform yourself in order to understand that you are wrong. libscg abstracts from a kernel specific transport and allows to write OS independent applications that rely in generic SCSI transport. For this reason, it is bejond the scope of the Linux kernel team to decide on this abstraction layer. The Linux kernel team just need to take the current libscg interface as given as _this_ _is_ the way to do best abstraction. The Linux kernel team has the freedom to boycott portable user space SCSI applications or to support them. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:40 ` Joerg Schilling @ 2006-02-13 13:52 ` Matthias Andree 2006-02-13 15:15 ` Joerg Schilling 2006-02-13 14:07 ` Martin Mares 2006-02-13 23:13 ` D. Hazelton 2 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-13 13:52 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:52 ` Matthias Andree @ 2006-02-13 15:15 ` Joerg Schilling 2006-02-13 23:26 ` D. Hazelton 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 15:15 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > > For this reason, it is bejond the scope of the Linux kernel team to decide on > > this abstraction layer. The Linux kernel team just need to take the current > > libscg interface as given as _this_ _is_ the way to do best abstraction. > > This is ridiculous. The abstraction (SG_IO on an open special file) is > in the kernel. Feel free to stack as many layers on top as you wish, but > the kernel isn't going to bend just to support a random abstraction > library that cannot achieve its goals in its current form anyways. Try to inform yourself on the difference between an IOCTL and a /dev/ entry. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:15 ` Joerg Schilling @ 2006-02-13 23:26 ` D. Hazelton 0 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-13 23:26 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Monday 13 February 2006 10:15, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > For this reason, it is bejond the scope of the Linux kernel team to > > > decide on this abstraction layer. The Linux kernel team just need to > > > take the current libscg interface as given as _this_ _is_ the way to > > > do best abstraction. > > > > This is ridiculous. The abstraction (SG_IO on an open special file) is > > in the kernel. Feel free to stack as many layers on top as you wish, but > > the kernel isn't going to bend just to support a random abstraction > > library that cannot achieve its goals in its current form anyways. > > Try to inform yourself on the difference between an IOCTL and a /dev/ > entry. I believe he did make the distinction there. He states "The abstraction (SG_IO on an open special file) is in the kernel." An "open special file" could be anything, but in this case it's meant to refer to a /dev/ entry. The point he made is valid, and it appears that in this case, Joerg, you are the one who is "technically uninformed". DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:40 ` Joerg Schilling 2006-02-13 13:52 ` Matthias Andree @ 2006-02-13 14:07 ` Martin Mares 2006-02-13 15:29 ` Joerg Schilling 2006-02-13 23:13 ` D. Hazelton 2 siblings, 1 reply; 439+ messages in thread From: Martin Mares @ 2006-02-13 14:07 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, peter.read, matthias.andree, linux-kernel, jim, jengelh Hello! > libscg abstracts from a kernel specific transport and allows to write OS > independent applications that rely in generic SCSI transport. > > For this reason, it is bejond the scope of the Linux kernel team to decide on > this abstraction layer. The Linux kernel team just need to take the current > libscg interface as given as _this_ _is_ the way to do best abstraction. Do you really believe that libscg is the only way in the world how to access SCSI devices? How can you be so sure that the abstraction you have chosen is the only possible one? If an answer to either of this questions is NO, why do you insist on everybody bending their rules to suit your model? > The Linux kernel team has the freedom to boycott portable user space SCSI > applications or to support them. That's really an interesting view ... if anybody is boycotting anybody, then it's clearly you, because you refuse to extend libscg to support the Linux model, although it's clearly possible. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Ctrl and Alt keys stuck -- press Del to continue. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:07 ` Martin Mares @ 2006-02-13 15:29 ` Joerg Schilling 2006-02-13 16:11 ` Jim Crilly ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 15:29 UTC (permalink / raw) To: schilling, mj Cc: peter.read, matthias.andree, linux-kernel, jim, jengelh, dhazelton Martin Mares <mj@ucw.cz> wrote: > Hello! > > > libscg abstracts from a kernel specific transport and allows to write OS > > independent applications that rely in generic SCSI transport. > > > > For this reason, it is bejond the scope of the Linux kernel team to decide on > > this abstraction layer. The Linux kernel team just need to take the current > > libscg interface as given as _this_ _is_ the way to do best abstraction. > > Do you really believe that libscg is the only way in the world how to > access SCSI devices? > > How can you be so sure that the abstraction you have chosen is the only > possible one? > > If an answer to either of this questions is NO, why do you insist on > everybody bending their rules to suit your model? Name me any other lib that is as OS independent and as clean/stable as libscg is. Note that the interface from libscg did not really change since August 1986. > > The Linux kernel team has the freedom to boycott portable user space SCSI > > applications or to support them. > > That's really an interesting view ... if anybody is boycotting anybody, > then it's clearly you, because you refuse to extend libscg to support > the Linux model, although it's clearly possible. Looks like you did not follow the discussion :-( I am constantly working on better support for Linux while the Linux kernel folks do not even fix obvious bugs. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:29 ` Joerg Schilling @ 2006-02-13 16:11 ` Jim Crilly 2006-02-13 22:54 ` D. Hazelton 2006-02-14 5:09 ` Alexander Samad 2 siblings, 0 replies; 439+ messages in thread From: Jim Crilly @ 2006-02-13 16:11 UTC (permalink / raw) To: Joerg Schilling Cc: mj, peter.read, matthias.andree, linux-kernel, jengelh, dhazelton On 02/13/06 04:29:37PM +0100, Joerg Schilling wrote: > Martin Mares <mj@ucw.cz> wrote: > Looks like you did not follow the discussion :-( > > I am constantly working on better support for Linux while the Linux kernel > folks do not even fix obvious bugs. > > Jörg I guess that depends on your definition of 'working'. From everyone's perspective but your own, all you've done is sling mud and scream about how great Solaris is and how Linux needs to emulate it's conventions. Jim. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:29 ` Joerg Schilling 2006-02-13 16:11 ` Jim Crilly @ 2006-02-13 22:54 ` D. Hazelton 2006-02-14 5:09 ` Alexander Samad 2 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-13 22:54 UTC (permalink / raw) To: Joerg Schilling Cc: mj, peter.read, matthias.andree, linux-kernel, jim, jengelh On Monday 13 February 2006 10:29, Joerg Schilling wrote: > Martin Mares <mj@ucw.cz> wrote: > > Hello! > > > > > libscg abstracts from a kernel specific transport and allows to write > > > OS independent applications that rely in generic SCSI transport. > > > > > > For this reason, it is bejond the scope of the Linux kernel team to > > > decide on this abstraction layer. The Linux kernel team just need to > > > take the current libscg interface as given as _this_ _is_ the way to > > > do best abstraction. > > > > Do you really believe that libscg is the only way in the world how to > > access SCSI devices? > > > > How can you be so sure that the abstraction you have chosen is the only > > possible one? > > > > If an answer to either of this questions is NO, why do you insist on > > everybody bending their rules to suit your model? > > Name me any other lib that is as OS independent and as clean/stable as > libscg is. Note that the interface from libscg did not really change > since August 1986. OS Independant? Almost every userspace library that a linux system uses is OS independant. Stable interface? That's much harder since _most_ libraries change their interfaces incrementally as new technology or techniques become available to support them. I did have an idea the other day and was wondering - why can't you, Joerg, add the capacity to CDRECORD to silently take a given /dev entry and turn it into your "needed" btl mapping? > > > The Linux kernel team has the freedom to boycott portable user space > > > SCSI applications or to support them. > > > > That's really an interesting view ... if anybody is boycotting anybody, > > then it's clearly you, because you refuse to extend libscg to support > > the Linux model, although it's clearly possible. > > Looks like you did not follow the discussion :-( > > I am constantly working on better support for Linux while the Linux kernel > folks do not even fix obvious bugs. > Yes, you are, but you have made a very large mistake in your thinking. As an application and library developer you are supposed to build an application that works properly inside the framework provided by the OS. If your application does not work within the OS, then there is either a large bug in the OS (Not unheard of for M$ products, but in an Open Source product like Linux bugs that large do not survive long) or a bug in your program. Since there is obviously no bug in the OS, and obviously no bug in cdrecord (I use it about once a week to make multi-cd backups) then your complaints about the "badly designed /dev/hd*" interface are just complaints from a programmer that thinks he's smarter than a hundred other people. Since you appear to be a proponent of Solaris and use that on a regular basis it's my guess that you either 1) don't have the skill to create an OS and release it or 2) you are so mired in history and the "beauty" of your code that you refuse to change it at all. In this case I think the second option is the truth. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:29 ` Joerg Schilling 2006-02-13 16:11 ` Jim Crilly 2006-02-13 22:54 ` D. Hazelton @ 2006-02-14 5:09 ` Alexander Samad 2 siblings, 0 replies; 439+ messages in thread From: Alexander Samad @ 2006-02-14 5:09 UTC (permalink / raw) Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 2219 bytes --] On Mon, Feb 13, 2006 at 04:29:37PM +0100, Joerg Schilling wrote: > Martin Mares <mj@ucw.cz> wrote: > > > Hello! > > > > > libscg abstracts from a kernel specific transport and allows to write OS > > > independent applications that rely in generic SCSI transport. > > > > > > For this reason, it is bejond the scope of the Linux kernel team to decide on > > > this abstraction layer. The Linux kernel team just need to take the current > > > libscg interface as given as _this_ _is_ the way to do best abstraction. > > > > Do you really believe that libscg is the only way in the world how to > > access SCSI devices? > > > > How can you be so sure that the abstraction you have chosen is the only > > possible one? > > > > If an answer to either of this questions is NO, why do you insist on > > everybody bending their rules to suit your model? > > Name me any other lib that is as OS independent and as clean/stable as > libscg is. Note that the interface from libscg did not really change > since August 1986. off the top of my head the standard C library been fairly stable > > > > > The Linux kernel team has the freedom to boycott portable user space SCSI > > > applications or to support them. > > > > That's really an interesting view ... if anybody is boycotting anybody, > > then it's clearly you, because you refuse to extend libscg to support > > the Linux model, although it's clearly possible. > > Looks like you did not follow the discussion :-( > > I am constantly working on better support for Linux while the Linux kernel > folks do not even fix obvious bugs. > > J?rg > > -- > EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin > js@cs.tu-berlin.de (uni) > schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:40 ` Joerg Schilling 2006-02-13 13:52 ` Matthias Andree 2006-02-13 14:07 ` Martin Mares @ 2006-02-13 23:13 ` D. Hazelton 2 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-13 23:13 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Monday 13 February 2006 08:40, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > Name a single program (not using libscg) that implements user space > > > SCSI and runs on as many platforms as cdrecord/libscg does. > > > > I'm not the maintainer of a program, and hence I don't have to. > > > > But why in the hell do you even _need_ SCSI in userspace when the kernel > > provides complete facilities? And even then your argument is specious, > > since > > Then please try to inform yourself in order to understand that you are > wrong. Inform myself? Before this discussion even began I had spent hours trying to figure out how to use libscg and decided to just use the provided linux systems and worry about porting to other systems if I ever finished the project. As far as I'm concerned, Linux provides enough of an abstraction layer that anyone with a bit of programming skill and access to the proper documentation can do _anything_ they want. A personal attack like this is how flame wars get started - I will not be party to one. And again you show your colors as a troll, by making a personal attack. The only saving grace is that you did explain yourself. > > libscg abstracts from a kernel specific transport and allows to write OS > independent applications that rely in generic SCSI transport. I still think that on modern operating systems libscg needs to be nothing more than a wrapper around the OS specific code. Anything added extra beyond that is actually unneeded. > For this reason, it is bejond the scope of the Linux kernel team to decide > on this abstraction layer. The Linux kernel team just need to take the > current libscg interface as given as _this_ _is_ the way to do best > abstraction. Why is it the best? Because you wrote it? Beyond cdrtools I have seen only one user of it (and I don't know that that program hasn't been silently folded into cdrtools recently). The fact that no one else has written a SCSI wrapper means a few things. One: That nobody else has ever seen the need for it. Two: That most programmers are like me - lazy and unwilling to "reinvent the wheel" for any project. In truth, it's not an "either-or" it's both of those reasons. And my point still remains - applications and libraries must _WORK_ _WITHIN_ the framework provided by the OS. No application or library that attempts to define the way an OS works is valid - this is a simple fact that you seem unable to grasp. > The Linux kernel team has the freedom to boycott portable user space SCSI > applications or to support them. so I'm guessing you think that your userbase is happy with your scheme? If they are anything like most people I know they have just resigned themselves to using a bad interface or they use a GUI that hides the complexities of the interface from them. And even then, as someone else pointed out, two drives that are identical in all respects except color, plugged onto two seperate busses, will appear the same in the scanbus listing. How can a user tell them apart? DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 13:03 ` Joerg Schilling 2006-02-10 3:21 ` D. Hazelton @ 2006-02-10 13:25 ` Dmitry Torokhov 2006-02-10 3:36 ` D. Hazelton 2006-02-10 15:38 ` jerome lacoste ` (2 subsequent siblings) 4 siblings, 1 reply; 439+ messages in thread From: Dmitry Torokhov @ 2006-02-10 13:25 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > And does cdrecord even need libscg anymore? From having actually gone through > > your code, Joerg, I can tell you that it does serve a larger purpose. But at > > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_ > > writing programs, does _ANYONE_ use libscg? Is it ever used to access any > > other devices that are either SCSI or use a SCSI command protocol (like > > ATAPI)? My point there is that you have a wonderful library, but despite > > your wishes, there is no proof that it is ever used for anything except > > writing/ripping CD's. > > Name a single program (not using libscg) that implements user space SCSI and runs > on as many platforms as cdrecord/libscg does. > Joerg, Please name a single program/package besides cdrtools that is using libscg. Face it, you created and maintained a very decent CD writing program but world domination is a bit out of reach. -- Dmitry ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 13:25 ` Dmitry Torokhov @ 2006-02-10 3:36 ` D. Hazelton 0 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-10 3:36 UTC (permalink / raw) To: dtor_core Cc: Joerg Schilling, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Friday 10 February 2006 08:25, Dmitry Torokhov wrote: > On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > "D. Hazelton" <dhazelton@enter.net> wrote: > > > And does cdrecord even need libscg anymore? From having actually gone > > > through your code, Joerg, I can tell you that it does serve a larger > > > purpose. But at this point I have to ask - besides cdrecord and a few > > > other _COMPACT_ _DISC_ writing programs, does _ANYONE_ use libscg? Is > > > it ever used to access any other devices that are either SCSI or use a > > > SCSI command protocol (like ATAPI)? My point there is that you have a > > > wonderful library, but despite your wishes, there is no proof that it > > > is ever used for anything except writing/ripping CD's. > > > > Name a single program (not using libscg) that implements user space SCSI > > and runs on as many platforms as cdrecord/libscg does. > > Joerg, > > Please name a single program/package besides cdrtools that is using > libscg. Face it, you created and maintained a very decent CD writing > program but world domination is a bit out of reach. Exactly. He has done exactly that, but since then the world has moved on and he refuses to see the truth. Joerg - Lieber gott in himmel! You probably missed 90% of my argument anyway. So here it is encapsulated: Userspace does not define kernel semantics or facilities. Standards do that, and where standards are lacking, the kernel has to provide what it can. Now before you go off and start screaming about the SCSI spec, be aware that I _HAVE_ _READ_ _THEM_ and nowhere do I see it stated that the kernel has to export the SCSI transport layers internal numbering to userspace. All I have seen is that the SCSI system uses a "Host/Bus/Target/Lun" identification system internally. As someone else pointed out, /dev/sr* can be used for writing CD's with the SG_IO system since the same transport code sits under said device as all other block devices. This means that if a program wants to write to the device identified by /dev/sr0 or /dev/hda the kernel knows which HOST/BUS/TARGET/LUN is meant by it. No need to artificially provide those identifiers. As someone else also pointed out, your code doesn't map devices in a sane manner. BTL mapping can change with hotplug, and all your arguments about st_dev are bullshit. From reading the spec you pointed at it seems that st_dev points to the _underlying_ _device_ - which will be stable despite everything. Understood? And before I go, let me reiterate a true statement someone else said: libscg is not the problem - it is the backend. If you _need_ said BTL mappings, why can't cdrecord take the provide /dev/hd* or /dev/sr* and translate it internally into the BTL mapping you need? DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 13:03 ` Joerg Schilling 2006-02-10 3:21 ` D. Hazelton 2006-02-10 13:25 ` Dmitry Torokhov @ 2006-02-10 15:38 ` jerome lacoste 2006-02-10 3:41 ` D. Hazelton ` (2 more replies) 2006-02-13 0:44 ` Alexander Samad 2006-02-13 14:12 ` jerome lacoste 4 siblings, 3 replies; 439+ messages in thread From: jerome lacoste @ 2006-02-10 15:38 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > And does cdrecord even need libscg anymore? From having actually gone through > > your code, Joerg, I can tell you that it does serve a larger purpose. But at > > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_ > > writing programs, does _ANYONE_ use libscg? Is it ever used to access any > > other devices that are either SCSI or use a SCSI command protocol (like > > ATAPI)? My point there is that you have a wonderful library, but despite > > your wishes, there is no proof that it is ever used for anything except > > writing/ripping CD's. > > Name a single program (not using libscg) that implements user space SCSI and runs > on as many platforms as cdrecord/libscg does. I have 2 technical questions, and I hope that you will take the time to answer them. 1) extract from the README of the latest stable cdrtools package: Linux driver design oddities ****************************************** Although cdrecord supports to use dev=/dev/sgc, it is not recommended and it is unsupported. The /dev/sg* device mapping in Linux is not stable! Using dev=/dev/sgc in a shell script may fail after a reboot because the device you want to talk to has moved to /dev/sgd. For the proper and OS independent dev=<bus>,<tgt>,<lun> syntax read the man page of cdrecord. My understanding of that is you say to not use dev=/dev/sgc because it isn't stable. Now that you've said that bus,tgt,lun is not stable on Linux (because of a "Linux bug") why is the b,t,l scheme preferred over the /dev/sg* one ? 2) design question: - cdrecord scans then maps the device to the b,t,l scheme. - the libsg uses the b,t,l ids in its interface to perform the operations So now, if cdrecord could have a new option called -scanbusmap that displays the mapping it performs in a way that people can parse the output, I think that will solve most issues. cdrecord already has this information available, it just doesn't display it: $ cdrecord debug=2 dev=ATAPI -scanbus 2>&1 | grep INFO INFO: /dev/hdc, (host0/bus1/target0/lun0) will be mapped on the schilly bus No 0 (0,0,0) INFO: /dev/hdd, (host0/bus1/target1/lun0) will be mapped on the schilly bus No 0 (0,1,0) It could perform in the following way: $ cdrecord dev=ATAPI -scanbusmap ... 0,0,0 <= /dev/hdc 0,1,0 <= /dev/hdd Are you accepting such a patch? Jerome ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 15:38 ` jerome lacoste @ 2006-02-10 3:41 ` D. Hazelton 2006-02-13 13:44 ` Joerg Schilling 2006-02-10 16:23 ` Gene Heskett 2006-02-13 10:40 ` CD writing in future Linux (stirring up a hornets' nest) Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-10 3:41 UTC (permalink / raw) To: jerome lacoste Cc: Joerg Schilling, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Friday 10 February 2006 10:38, jerome lacoste wrote: > On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > "D. Hazelton" <dhazelton@enter.net> wrote: > > > And does cdrecord even need libscg anymore? From having actually gone > > > through your code, Joerg, I can tell you that it does serve a larger > > > purpose. But at this point I have to ask - besides cdrecord and a few > > > other _COMPACT_ _DISC_ writing programs, does _ANYONE_ use libscg? Is > > > it ever used to access any other devices that are either SCSI or use a > > > SCSI command protocol (like ATAPI)? My point there is that you have a > > > wonderful library, but despite your wishes, there is no proof that it > > > is ever used for anything except writing/ripping CD's. > > > > Name a single program (not using libscg) that implements user space SCSI > > and runs on as many platforms as cdrecord/libscg does. > > I have 2 technical questions, and I hope that you will take the time > to answer them. > > 1) extract from the README of the latest stable cdrtools package: > > Linux driver design oddities > ****************************************** Although cdrecord supports to > use dev=/dev/sgc, it is not recommended and it is unsupported. > > The /dev/sg* device mapping in Linux is not stable! Using > dev=/dev/sgc in a shell script may fail after a reboot because the device > you want to talk to has moved to /dev/sgd. For the proper and OS > independent dev=<bus>,<tgt>,<lun> syntax read the man page of cdrecord. > > My understanding of that is you say to not use dev=/dev/sgc because it > isn't stable. Now that you've said that bus,tgt,lun is not stable on > Linux (because of a "Linux bug") why is the b,t,l scheme preferred > over the /dev/sg* one ? Excellent question. Well Joerg, can you give us a good answer, or will it be more finger pointing, mud slinging and FUD ? > > 2) design question: > > - cdrecord scans then maps the device to the b,t,l scheme. > - the libsg uses the b,t,l ids in its interface to perform the operations > > So now, if cdrecord could have a new option called -scanbusmap that > displays the mapping it performs in a way that people can parse the > output, I think that will solve most issues. I'm wondering this myself. If Joerg didn't seem to think everyone in the world was an idiot I'd attempt this myself and submit it. > cdrecord already has this information available, it just doesn't display > it: > > $ cdrecord debug=2 dev=ATAPI -scanbus 2>&1 | grep INFO > INFO: /dev/hdc, (host0/bus1/target0/lun0) will be mapped on the > schilly bus No 0 (0,0,0) > INFO: /dev/hdd, (host0/bus1/target1/lun0) will be mapped on the > schilly bus No 0 (0,1,0) > > It could perform in the following way: > > $ cdrecord dev=ATAPI -scanbusmap > ... > > 0,0,0 <= /dev/hdc > 0,1,0 <= /dev/hdd > > > Are you accepting such a patch? If his response to the last patch someone provided is any example the answer is going to be no. And I firmly believe the old adage that a leopard can't change it's spots. > Jerome DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 3:41 ` D. Hazelton @ 2006-02-13 13:44 ` Joerg Schilling 2006-02-13 14:08 ` jerome lacoste ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 13:44 UTC (permalink / raw) To: jerome.lacoste, dhazelton Cc: schilling, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh "D. Hazelton" <dhazelton@enter.net> wrote: > > Are you accepting such a patch? > > If his response to the last patch someone provided is any example the answer > is going to be no. And I firmly believe the old adage that a leopard can't > change it's spots. Any patch that - does not break things - fits into the spirit of the currnt implementation - offers useful new features - conforms to coding style standards - does not need more time to integrate than I would need to write this from scratch Unfortunately, many people who send patches to me do not follow these simple rules. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:44 ` Joerg Schilling @ 2006-02-13 14:08 ` jerome lacoste 2006-02-13 15:26 ` Joerg Schilling 2006-02-13 23:01 ` D. Hazelton 2006-02-14 1:05 ` kernel 2 siblings, 1 reply; 439+ messages in thread From: jerome lacoste @ 2006-02-13 14:08 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > > Are you accepting such a patch? > > > > If his response to the last patch someone provided is any example the answer > > is going to be no. And I firmly believe the old adage that a leopard can't > > change it's spots. > > Any patch that > > - does not break things > > - fits into the spirit of the currnt implementation > > - offers useful new features > > - conforms to coding style standards > > - does not need more time to integrate than I would need to > write this from scratch > > Unfortunately, many people who send patches to me do not follow > these simple rules. I am still waiting for an answer as to whether such a patch would be accepted. We will take on the practical details later on. Jerome ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:08 ` jerome lacoste @ 2006-02-13 15:26 ` Joerg Schilling 2006-02-13 15:47 ` jerome lacoste 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 15:26 UTC (permalink / raw) To: schilling, jerome.lacoste Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton jerome lacoste <jerome.lacoste@gmail.com> wrote: > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > "D. Hazelton" <dhazelton@enter.net> wrote: > > > > > > Are you accepting such a patch? > > > > > > If his response to the last patch someone provided is any example the answer > > > is going to be no. And I firmly believe the old adage that a leopard can't > > > change it's spots. > > > > Any patch that > > > > - does not break things > > > > - fits into the spirit of the currnt implementation > > > > - offers useful new features > > > > - conforms to coding style standards > > > > - does not need more time to integrate than I would need to > > write this from scratch > > > > Unfortunately, many people who send patches to me do not follow > > these simple rules. > > I am still waiting for an answer as to whether such a patch would be > accepted. We will take on the practical details later on. If this answer is not sufficient to you, you seem to be wrong here. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:26 ` Joerg Schilling @ 2006-02-13 15:47 ` jerome lacoste 2006-02-13 16:19 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: jerome lacoste @ 2006-02-13 15:47 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > > "D. Hazelton" <dhazelton@enter.net> wrote: > > > > > > > > Are you accepting such a patch? > > > > > > > > If his response to the last patch someone provided is any example the answer > > > > is going to be no. And I firmly believe the old adage that a leopard can't > > > > change it's spots. > > > > > > Any patch that > > > > > > - does not break things > > > > > > - fits into the spirit of the currnt implementation > > > > > > - offers useful new features > > > > > > - conforms to coding style standards > > > > > > - does not need more time to integrate than I would need to > > > write this from scratch > > > > > > Unfortunately, many people who send patches to me do not follow > > > these simple rules. > > > > I am still waiting for an answer as to whether such a patch would be > > accepted. We will take on the practical details later on. > > If this answer is not sufficient to you, you seem to be wrong here. We probably misunderstood each other here. I want a technical approval regarding the proposal I made (which is "publicise the os specific to b,t,l mapping found by cdrecord"). Then I write the patch and I will make sure it will pass all your defined criteria. Jerome ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:47 ` jerome lacoste @ 2006-02-13 16:19 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 16:19 UTC (permalink / raw) To: schilling, jerome.lacoste Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton jerome lacoste <jerome.lacoste@gmail.com> wrote: > > If this answer is not sufficient to you, you seem to be wrong here. > > We probably misunderstood each other here. I want a technical approval > regarding the proposal I made (which is "publicise the os specific to > b,t,l mapping found by cdrecord"). > > Then I write the patch and I will make sure it will pass all your > defined criteria. I did give you the criteria. I don't know what you like to do. I cannot tell you something on code I don't know. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:44 ` Joerg Schilling 2006-02-13 14:08 ` jerome lacoste @ 2006-02-13 23:01 ` D. Hazelton 2006-02-14 13:37 ` Joerg Schilling 2006-02-14 1:05 ` kernel 2 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-13 23:01 UTC (permalink / raw) To: Joerg Schilling Cc: jerome.lacoste, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Monday 13 February 2006 08:44, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > Are you accepting such a patch? > > > > If his response to the last patch someone provided is any example the > > answer is going to be no. And I firmly believe the old adage that a > > leopard can't change it's spots. > > Any patch that > > - does not break things > > - fits into the spirit of the currnt implementation > > - offers useful new features > > - conforms to coding style standards > > - does not need more time to integrate than I would need to > write this from scratch > > Unfortunately, many people who send patches to me do not follow > these simple rules. Okay - show me your standards document and I'll get to work on a patch to do what I earlier proposed. It won't be "adding new functionality" but it will be making the interface a tiny bit simpler for the novice user. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 23:01 ` D. Hazelton @ 2006-02-14 13:37 ` Joerg Schilling 2006-02-14 14:24 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 13:37 UTC (permalink / raw) To: schilling, dhazelton Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh "D. Hazelton" <dhazelton@enter.net> wrote: > > - does not need more time to integrate than I would need to > > write this from scratch > > > > Unfortunately, many people who send patches to me do not follow > > these simple rules. > > Okay - show me your standards document and I'll get to work on a patch to do > what I earlier proposed. It won't be "adding new functionality" but it will > be making the interface a tiny bit simpler for the novice user. ????? 1) RTFM 2) ftp://ftp.berlios.de/pub/cdrecord/PORTING 3) http://cdrecord.berlios.de/old/private/port.ps 4) http://cvs.opensolaris.org/source/xref/on/usr/src/tools/scripts/cstyle.pl If you do not follow the spirit of the interface design or of you break things on other OS, your patch will not be accepted. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 13:37 ` Joerg Schilling @ 2006-02-14 14:24 ` Matthias Andree 2006-02-14 16:55 ` Joerg Schilling 2006-02-14 18:43 ` Jim Crilly 2006-02-14 22:15 ` D. Hazelton 2 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-14 14:24 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel, jerome.lacoste 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 14:24 ` Matthias Andree @ 2006-02-14 16:55 ` Joerg Schilling 2006-02-14 22:27 ` D. Hazelton 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 16:55 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel, jerome.lacoste Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-14: > > > If you do not follow the spirit of the interface design > > This is not a technical restriction, but a soaking sponge you can > throw in anyone's face. Well, it is a _lot_ more open than what Linux requieres. On Linux you need to meet the current feeling of a potentially unknown lord of the manor. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:55 ` Joerg Schilling @ 2006-02-14 22:27 ` D. Hazelton 0 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-14 22:27 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, jerome.lacoste On Tuesday 14 February 2006 11:55, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > Joerg Schilling schrieb am 2006-02-14: > > > If you do not follow the spirit of the interface design > > > > This is not a technical restriction, but a soaking sponge you can > > throw in anyone's face. > > Well, it is a _lot_ more open than what Linux requieres. > On Linux you need to meet the current feeling of a potentially unknown > lord of the manor. > > Jörg Bullshit, Joerg. The only difference in this case is that we know exactly who "the lord of the manor" is. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 13:37 ` Joerg Schilling 2006-02-14 14:24 ` Matthias Andree @ 2006-02-14 18:43 ` Jim Crilly 2006-02-14 19:06 ` Olivier Galibert 2006-02-14 22:15 ` D. Hazelton 2 siblings, 1 reply; 439+ messages in thread From: Jim Crilly @ 2006-02-14 18:43 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, peter.read, mj, matthias.andree, linux-kernel, jerome.lacoste, jengelh On 02/14/06 02:37:14PM +0100, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > > - does not need more time to integrate than I would need to > > > write this from scratch > > > > > > Unfortunately, many people who send patches to me do not follow > > > these simple rules. > > > > Okay - show me your standards document and I'll get to work on a patch to do > > what I earlier proposed. It won't be "adding new functionality" but it will > > be making the interface a tiny bit simpler for the novice user. > > ????? > > 1) RTFM > 2) ftp://ftp.berlios.de/pub/cdrecord/PORTING > 3) http://cdrecord.berlios.de/old/private/port.ps > 4) http://cvs.opensolaris.org/source/xref/on/usr/src/tools/scripts/cstyle.pl > > > If you do not follow the spirit of the interface design or of you break > things on other OS, your patch will not be accepted. > > Jörg You're allowed to yell RTFM to him, but when you were pointed to the HAL documentation you cried that you didn't want to spend time reading it? How does that work? Jim. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 18:43 ` Jim Crilly @ 2006-02-14 19:06 ` Olivier Galibert 0 siblings, 0 replies; 439+ messages in thread From: Olivier Galibert @ 2006-02-14 19:06 UTC (permalink / raw) To: linux-kernel 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 13:37 ` Joerg Schilling 2006-02-14 14:24 ` Matthias Andree 2006-02-14 18:43 ` Jim Crilly @ 2006-02-14 22:15 ` D. Hazelton 2 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-14 22:15 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh On Tuesday 14 February 2006 08:37, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > - does not need more time to integrate than I would need to > > > write this from scratch > > > > > > Unfortunately, many people who send patches to me do not follow > > > these simple rules. > > > > Okay - show me your standards document and I'll get to work on a patch to > > do what I earlier proposed. It won't be "adding new functionality" but it > > will be making the interface a tiny bit simpler for the novice user. > > ????? > > 1) RTFM > 2) ftp://ftp.berlios.de/pub/cdrecord/PORTING > 3) http://cdrecord.berlios.de/old/private/port.ps > 4) http://cvs.opensolaris.org/source/xref/on/usr/src/tools/scripts/cstyle.p >l > > > If you do not follow the spirit of the interface design or of you break > things on other OS, your patch will not be accepted. > > Jörg I shall and thank you. Given current constraints on my time I should have the patch I mentioned available in no more than two weeks. If my patch breaks something on another OS, then please inform me so that I can modify the code and send you a fixed patch. After all, as I've said before, I don't have the access to the resources you do for testing. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:44 ` Joerg Schilling 2006-02-13 14:08 ` jerome lacoste 2006-02-13 23:01 ` D. Hazelton @ 2006-02-14 1:05 ` kernel 2006-02-14 14:03 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: kernel @ 2006-02-14 1:05 UTC (permalink / raw) To: Joerg Schilling Cc: jerome.lacoste, dhazelton, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 1:05 ` kernel @ 2006-02-14 14:03 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 14:03 UTC (permalink / raw) To: schilling, kernel Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh, dhazelton kernel <kernel@crazytrain.com> wrote: > On Mon, 2006-02-13 at 08:44, Joerg Schilling wrote: > > Any patch that > > > > - does not break things > > > Good. Makes sense. Acceptable. > > > > - fits into the spirit of the currnt implementation > > > Bad. Subject to the gate keeper's ideas, whims, and personal agenda. So you like to tell us that you don"t like this? Well, then start a campaign against Linux...... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 15:38 ` jerome lacoste 2006-02-10 3:41 ` D. Hazelton @ 2006-02-10 16:23 ` Gene Heskett 2006-02-12 10:12 ` [ot] Linux heritage (was Re: CD writing in future Linux) Jan Engelhardt 2006-02-13 10:40 ` CD writing in future Linux (stirring up a hornets' nest) Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: Gene Heskett @ 2006-02-10 16:23 UTC (permalink / raw) To: linux-kernel On Friday 10 February 2006 10:38, jerome lacoste wrote: >On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: >> "D. Hazelton" <dhazelton@enter.net> wrote: >> > And does cdrecord even need libscg anymore? From having actually >> > gone through your code, Joerg, I can tell you that it does serve a >> > larger purpose. But at this point I have to ask - besides cdrecord >> > and a few other _COMPACT_ _DISC_ writing programs, does _ANYONE_ >> > use libscg? Is it ever used to access any other devices that are >> > either SCSI or use a SCSI command protocol (like ATAPI)? My point >> > there is that you have a wonderful library, but despite your >> > wishes, there is no proof that it is ever used for anything except >> > writing/ripping CD's. >> >> Name a single program (not using libscg) that implements user space >> SCSI and runs on as many platforms as cdrecord/libscg does. > >I have 2 technical questions, and I hope that you will take the time >to answer them. > >1) extract from the README of the latest stable cdrtools package: > > Linux driver design oddities > ****************************************** Although cdrecord supports > to use dev=/dev/sgc, it is not recommended and it is unsupported. > > The /dev/sg* device mapping in Linux is not stable! Using > dev=/dev/sgc in a shell script may fail after a reboot because the > device you want to talk to has moved to /dev/sgd. For the proper and > OS independent dev=<bus>,<tgt>,<lun> syntax read the man page of > cdrecord. > >My understanding of that is you say to not use dev=/dev/sgc because it >isn't stable. Now that you've said that bus,tgt,lun is not stable on >Linux (because of a "Linux bug") why is the b,t,l scheme preferred >over the /dev/sg* one ? > > >2) design question: > >- cdrecord scans then maps the device to the b,t,l scheme. >- the libsg uses the b,t,l ids in its interface to perform the > operations > >So now, if cdrecord could have a new option called -scanbusmap that >displays the mapping it performs in a way that people can parse the >output, I think that will solve most issues. > >cdrecord already has this information available, it just doesn't > display it: > >$ cdrecord debug=2 dev=ATAPI -scanbus 2>&1 | grep INFO >INFO: /dev/hdc, (host0/bus1/target0/lun0) will be mapped on the >schilly bus No 0 (0,0,0) >INFO: /dev/hdd, (host0/bus1/target1/lun0) will be mapped on the >schilly bus No 0 (0,1,0) And here I'd call the -scanbus output broken, extremely so, and in a manner that makes all of your arguments rather specious. I've tried to stay the hell out of this thread because its clearly a pissing match between some with excessive ego's, but this example requires an answer. [root@coyote]# cdrecord debug=2 dev=ATAPI -scanbus 2>&1 | grep INFO INFO: /dev/hdd, (host0/bus1/target1/lun0) will be mapped on the schilly bus No 0 (0,1,0) INFO: /dev/hdc, (host0/bus1/target0/lun0) will be mapped on the schilly bus No 0 (0,0,0) INFO: /dev/hda, (host0/bus0/target0/lun0) will be mapped on the schilly bus No 1 (1,0,0) The above make very little sense, and argues against Jorg's assertions that his way is the 'correct' way. Since when in the hello is /dev/hda NOT the first device in this so-called mapping scheme? This is clearly broken, but I have no trouble at all burning whatever I want to burn when using /deb/hdc at the target in k3b. True, cdrecord does place that target at 0,0,0 but that has to be because of some mechanation in the cdrecord code to defeat what really should be common sense that says /dev/hdc SHOULD be 1,0,0 as its the first device found on the 2nd buss(or cable as some would call it). Now, take this next as a users statement, not from the point of a coder although I have written some in past decades when the machinery was a little simpler. Now I'm just an old codger user at 71. So how Jorg, can you justify your reticence to make use of a system that linux has, and which clearly works now since very close to the 2.6 kernel series transition? Your constant harping on how solaris does it is as distastefull as some winderz dweeb coming in here to try and evangelize windows use. This IS linux, and our numbers probably exceed solaris users by a factor of at least 10. We're here, and unless a buss hits Linus and no similar minded person is named as his successor, get over it. You are drasticly outnumbered. We just want it to work and we don't care about your mostly FUD, often silly, usually specious/empty arguments because no facts are ever stated more than once over a given 5 year period. We are all in your view expected to have photographic memory. Not guilty here, we do have other concerns in life. >It could perform in the following way: > >$ cdrecord dev=ATAPI -scanbusmap >... > >0,0,0 <= /dev/hdc >0,1,0 <= /dev/hdd > > >Are you accepting such a patch? > >Jerome -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 439+ messages in thread
* [ot] Linux heritage (was Re: CD writing in future Linux) 2006-02-10 16:23 ` Gene Heskett @ 2006-02-12 10:12 ` Jan Engelhardt 0 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-12 10:12 UTC (permalink / raw) To: Gene Heskett; +Cc: linux-kernel >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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 15:38 ` jerome lacoste 2006-02-10 3:41 ` D. Hazelton 2006-02-10 16:23 ` Gene Heskett @ 2006-02-13 10:40 ` Joerg Schilling 2006-02-13 10:52 ` Martin Mares ` (2 more replies) 2 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 10:40 UTC (permalink / raw) To: schilling, jerome.lacoste Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton jerome lacoste <jerome.lacoste@gmail.com> wrote: > On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > "D. Hazelton" <dhazelton@enter.net> wrote: > > > > > And does cdrecord even need libscg anymore? From having actually gone through > > > your code, Joerg, I can tell you that it does serve a larger purpose. But at > > > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_ > > > writing programs, does _ANYONE_ use libscg? Is it ever used to access any > > > other devices that are either SCSI or use a SCSI command protocol (like > > > ATAPI)? My point there is that you have a wonderful library, but despite > > > your wishes, there is no proof that it is ever used for anything except > > > writing/ripping CD's. > > > > Name a single program (not using libscg) that implements user space SCSI and runs > > on as many platforms as cdrecord/libscg does. > > > I have 2 technical questions, and I hope that you will take the time > to answer them. > > 1) extract from the README of the latest stable cdrtools package: > > Linux driver design oddities ****************************************** > Although cdrecord supports to use dev=/dev/sgc, it is not recommended > and it is unsupported. > > The /dev/sg* device mapping in Linux is not stable! Using dev=/dev/sgc > in a shell script may fail after a reboot because the device you want > to talk to has moved to /dev/sgd. For the proper and OS independent > dev=<bus>,<tgt>,<lun> syntax read the man page of cdrecord. > > My understanding of that is you say to not use dev=/dev/sgc because it > isn't stable. Now that you've said that bus,tgt,lun is not stable on > Linux (because of a "Linux bug") why is the b,t,l scheme preferred > over the /dev/sg* one ? b,t,l _is_ stable as long as the OS does a reasonable and orthogonal work. This was true until ~ 2001, when Linux introduced unstable USB handling. Note that this fact is not a failure from libscg but from Linux. > 2) design question: > > - cdrecord scans then maps the device to the b,t,l scheme. > - the libsg uses the b,t,l ids in its interface to perform the operations > > So now, if cdrecord could have a new option called -scanbusmap that > displays the mapping it performs in a way that people can parse the > output, I think that will solve most issues. The output of cdrecord -scanbus is already parsable, so what is your point? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:40 ` CD writing in future Linux (stirring up a hornets' nest) Joerg Schilling @ 2006-02-13 10:52 ` Martin Mares 2006-02-13 14:57 ` Joerg Schilling ` (2 more replies) 2006-02-13 12:07 ` jerome lacoste 2006-02-13 22:57 ` D. Hazelton 2 siblings, 3 replies; 439+ messages in thread From: Martin Mares @ 2006-02-13 10:52 UTC (permalink / raw) To: Joerg Schilling Cc: jerome.lacoste, peter.read, matthias.andree, linux-kernel, jim, jengelh, dhazelton Hello! > This was true until ~ 2001, when Linux introduced unstable USB handling. Even before that point it wasn't true, adding a new controller card could always result in renumbering the previously existing controllers. The key failure in your reasoning is that there is no definition of "the same device", which would be both consistent and useful. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Not all rumors are as misleading as this one. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:52 ` Martin Mares @ 2006-02-13 14:57 ` Joerg Schilling 2006-02-13 15:03 ` Matthias Andree 2006-02-13 16:29 ` Jan Engelhardt 2006-02-13 16:30 ` Jan Engelhardt 2006-02-14 5:19 ` Marcin Dalecki 2 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 14:57 UTC (permalink / raw) To: schilling, mj Cc: peter.read, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh, dhazelton Martin Mares <mj@ucw.cz> wrote: > Hello! > > > This was true until ~ 2001, when Linux introduced unstable USB handling. > > Even before that point it wasn't true, adding a new controller card > could always result in renumbering the previously existing controllers. Even in this case, this was a deficit from Linux. On Solaris, adding a new controler always asigns this new controler a new higher ID (except for the case when the sysadmin explicitly requests different behavior). On Linux a sysadmin needs to know how the evaluation works.... And BTW: if a sysadmin does not know how things work on Linux and thus causes a remapping, all /etc/vfstab entries would be void. So you are talking about a major fault that should be avoided under all circumstances. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:57 ` Joerg Schilling @ 2006-02-13 15:03 ` Matthias Andree 2006-02-13 16:29 ` Jan Engelhardt 1 sibling, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-13 15:03 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:57 ` Joerg Schilling 2006-02-13 15:03 ` Matthias Andree @ 2006-02-13 16:29 ` Jan Engelhardt 2006-02-13 16:34 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Jan Engelhardt @ 2006-02-13 16:29 UTC (permalink / raw) To: Joerg Schilling Cc: mj, peter.read, matthias.andree, linux-kernel, jim, jerome.lacoste, dhazelton > >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? ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:29 ` Jan Engelhardt @ 2006-02-13 16:34 ` Joerg Schilling 2006-02-14 8:08 ` Jan Engelhardt 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 16:34 UTC (permalink / raw) To: schilling, jengelh Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, dhazelton Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > >On Solaris, adding a new controler always asigns this new controler a new > >higher ID (except for the case when the sysadmin explicitly requests different > >behavior). > > What if the OS runs out of next-higher IDs? ???? Do you believe that an int32_t is not sufficient? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:34 ` Joerg Schilling @ 2006-02-14 8:08 ` Jan Engelhardt 0 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-14 8:08 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, dhazelton >> > >> >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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:52 ` Martin Mares 2006-02-13 14:57 ` Joerg Schilling @ 2006-02-13 16:30 ` Jan Engelhardt 2006-02-14 5:19 ` Marcin Dalecki 2 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-13 16:30 UTC (permalink / raw) To: Martin Mares Cc: Joerg Schilling, jerome.lacoste, peter.read, matthias.andree, linux-kernel, jim, dhazelton > >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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:52 ` Martin Mares 2006-02-13 14:57 ` Joerg Schilling 2006-02-13 16:30 ` Jan Engelhardt @ 2006-02-14 5:19 ` Marcin Dalecki 2006-02-14 9:20 ` Martin Mares 2 siblings, 1 reply; 439+ messages in thread From: Marcin Dalecki @ 2006-02-14 5:19 UTC (permalink / raw) To: Martin Mares Cc: Joerg Schilling, jerome.lacoste, peter.read, matthias.andree, linux-kernel, jim, jengelh, dhazelton 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 5:19 ` Marcin Dalecki @ 2006-02-14 9:20 ` Martin Mares 2006-02-14 10:03 ` D. Hazelton 2006-02-14 14:25 ` Lennart Sorensen 0 siblings, 2 replies; 439+ messages in thread From: Martin Mares @ 2006-02-14 9:20 UTC (permalink / raw) To: Marcin Dalecki Cc: Joerg Schilling, jerome.lacoste, peter.read, matthias.andree, linux-kernel, jim, jengelh, dhazelton Hello! > This claim is a bit surprising since only, but the most irrelevant > stuff from the dust bin of history, doesn't define a world global > unique id those days. That's unfortunately not true -- many USB devices don't have a usable serial number. Also, if I have a single device of its kind, let's say a USB mouse, I really want to call it "The Mouse" and I don't want to reconfigure anything if I plug it to a different port or replace it with a slightly different mouse. All mice are considered equivalent by the user as there is no reason to distinguish between them. The same applies to CD burners -- as long as I have only one (which is still the most common situation), I shouldn't have to think about how to call it. Let it be just /dev/cdrw. When I get multiple such devices, things start getting interesting, but there is no single naming strategy which fits all uses. For example, if I have two USB ports into which I connect USB disks various people bring to me, it's convenient to call them "left" and "right", because the serial number doesn't mean anything to me if I haven't seen the device before. On the other hand, if I connect my own drives, it makes sense to call them by their serial numbers or something like that. I think that it's clear from all this, that device naming is a matter of policy and that the best the OS can do is to give the users a way how to specify their policy, which is what udev does. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth P.C.M.C.I.A. stands for `People Can't Memorize Computer Industry Acronyms' ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 9:20 ` Martin Mares @ 2006-02-14 10:03 ` D. Hazelton 2006-02-14 15:11 ` Joerg Schilling 2006-02-14 14:25 ` Lennart Sorensen 1 sibling, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-14 10:03 UTC (permalink / raw) To: Martin Mares Cc: Marcin Dalecki, Joerg Schilling, jerome.lacoste, peter.read, matthias.andree, linux-kernel, jim, jengelh 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 10:03 ` D. Hazelton @ 2006-02-14 15:11 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 15:11 UTC (permalink / raw) To: mj, dhazelton Cc: schilling, peter.read, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh, dalecki.marcin "D. Hazelton" <dhazelton@enter.net> wrote: > True, and the point I was trying to make. Joerg has a policy that works well > on some systems and doesn't on others. Rather than giving people a clear > option to use the other system he has. In Linux udev provides a user > configurable policy that works extremely well. Rather than change the If you believe this, then send a whitepaper on udev together with devent documentation and a grant on how long Linux will support the related interfaces without breaking them. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 9:20 ` Martin Mares 2006-02-14 10:03 ` D. Hazelton @ 2006-02-14 14:25 ` Lennart Sorensen 1 sibling, 0 replies; 439+ messages in thread From: Lennart Sorensen @ 2006-02-14 14:25 UTC (permalink / raw) To: Martin Mares Cc: Marcin Dalecki, Joerg Schilling, jerome.lacoste, peter.read, matthias.andree, linux-kernel, jim, jengelh, dhazelton 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:40 ` CD writing in future Linux (stirring up a hornets' nest) Joerg Schilling 2006-02-13 10:52 ` Martin Mares @ 2006-02-13 12:07 ` jerome lacoste 2006-02-13 15:04 ` Joerg Schilling 2006-02-13 22:57 ` D. Hazelton 2 siblings, 1 reply; 439+ messages in thread From: jerome lacoste @ 2006-02-13 12:07 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > jerome lacoste <jerome.lacoste@gmail.com> wrote: [...] > > My understanding of that is you say to not use dev=/dev/sgc because it > > isn't stable. Now that you've said that bus,tgt,lun is not stable on > > Linux (because of a "Linux bug") why is the b,t,l scheme preferred > > over the /dev/sg* one ? > > b,t,l _is_ stable as long as the OS does a reasonable and orthogonal work. > > This was true until ~ 2001, when Linux introduced unstable USB handling. > Note that this fact is not a failure from libscg but from Linux. This is true if you assume that "stable b,t,l" was an advertised Linux functionality. I may be wrong, but I don't think that this was ever the case. It might just have been a side-effect of the implementation. Anyway, point #2 is much more important, so let's focus on that: > > 2) design question: > > > > - cdrecord scans then maps the device to the b,t,l scheme. > > - the libsg uses the b,t,l ids in its interface to perform the operations > > > > So now, if cdrecord could have a new option called -scanbusmap that > > displays the mapping it performs in a way that people can parse the > > output, I think that will solve most issues. > > The output of cdrecord -scanbus is already parsable, But it doesn't show the OS specific mapping. > so what is your point? I am aiming for a compromise. My point is that people want to use dev=/dev/hdc in their interface, because that's what they are used to. That's a point that I think you cannot deny. If you want to still keep your dev=b,t,l command line interface, just let the users know how your mapping is done. That will allow a cdrecord wrapper to first query the mapping, then using this mapping information and OS specific information (e.g. links) identify the b,t,l expected by your interface. That way you have mostly no code change to do. And you keep your b,t,l naming. Everybody is happy. I've added something like: fprintf(stdout, "%d,%d,%d <= /dev/%s\n", first_free_schilly_bus, t, l, token[ID_TOKEN_SUBSYSTEM] ); in scsi-linux-ata.c and it does what I want. WDYT? Cheers, Jerome ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 12:07 ` jerome lacoste @ 2006-02-13 15:04 ` Joerg Schilling 2006-02-13 15:24 ` jerome lacoste 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 15:04 UTC (permalink / raw) To: schilling, jerome.lacoste Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton jerome lacoste <jerome.lacoste@gmail.com> wrote: > > The output of cdrecord -scanbus is already parsable, > > But it doesn't show the OS specific mapping. > > > so what is your point? > > I am aiming for a compromise. > > My point is that people want to use dev=/dev/hdc in their interface, > because that's what they are used to. That's a point that I think you > cannot deny. > > If you want to still keep your dev=b,t,l command line interface, just > let the users know how your mapping is done. That will allow a > cdrecord wrapper to first query the mapping, then using this mapping > information and OS specific information (e.g. links) identify the > b,t,l expected by your interface. > > That way you have mostly no code change to do. And you keep your b,t,l > naming. Everybody is happy. > > I've added something like: > > fprintf(stdout, "%d,%d,%d <= /dev/%s\n", > first_free_schilly_bus, t, l, token[ID_TOKEN_SUBSYSTEM] ); > > in scsi-linux-ata.c and it does what I want. The scanbus code was taken from "sformat". Sformat already includes such a mapping if you are on Solaris. Unfortunately this does cleanly work on Linux and for this reason is did not make it into cdrecord. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:04 ` Joerg Schilling @ 2006-02-13 15:24 ` jerome lacoste 2006-02-13 15:49 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: jerome lacoste @ 2006-02-13 15:24 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > > > The output of cdrecord -scanbus is already parsable, > > > > But it doesn't show the OS specific mapping. > > > > > so what is your point? > > > > I am aiming for a compromise. > > > > My point is that people want to use dev=/dev/hdc in their interface, > > because that's what they are used to. That's a point that I think you > > cannot deny. > > > > If you want to still keep your dev=b,t,l command line interface, just > > let the users know how your mapping is done. That will allow a > > cdrecord wrapper to first query the mapping, then using this mapping > > information and OS specific information (e.g. links) identify the > > b,t,l expected by your interface. > > > > That way you have mostly no code change to do. And you keep your b,t,l > > naming. Everybody is happy. > > > > I've added something like: > > > > fprintf(stdout, "%d,%d,%d <= /dev/%s\n", > > first_free_schilly_bus, t, l, token[ID_TOKEN_SUBSYSTEM] ); > > > > in scsi-linux-ata.c and it does what I want. > > The scanbus code was taken from "sformat". > > Sformat already includes such a mapping if you are on Solaris. > Unfortunately this does cleanly work on Linux and for this > reason is did not make it into cdrecord. Jorg, thanks for your answer. I fail to understand how it is connected to my proposal. Maybe we misunderstood each other. I assume that you refer to the sformat/fmt.c implementation (sformat 3.5) being reproduced in cdrecord/scsi_scan.c (latest cdrtools). Could you please elaborate on: - what does the sformat scanbus code has to do with my proposal, whose changes would mostly be located in the libscg modules, not in the cdrecord module - why 'it' doesn't clearly work on Linux. cdrecord clearly creates this os specific to b,t,l mapping (e.g. in scsi-linux-ata.c, scsi-wnt.c etc..). Why this mapping cannot be publicised in a parseable format? Jerome, still looking for a compromise. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:24 ` jerome lacoste @ 2006-02-13 15:49 ` Joerg Schilling 2006-02-13 16:05 ` jerome lacoste 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 15:49 UTC (permalink / raw) To: schilling, jerome.lacoste Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton jerome lacoste <jerome.lacoste@gmail.com> wrote: > > Sformat already includes such a mapping if you are on Solaris. > > Unfortunately this does cleanly work on Linux and for this > > reason is did not make it into cdrecord. > > Jorg, > > thanks for your answer. > > I fail to understand how it is connected to my proposal. Maybe we > misunderstood each other. > > I assume that you refer to the sformat/fmt.c implementation (sformat > 3.5) being reproduced in cdrecord/scsi_scan.c (latest cdrtools). > > Could you please elaborate on: > - what does the sformat scanbus code has to do with my proposal, whose > changes would mostly be located in the libscg modules, not in the > cdrecord module What has your proposal to do with libscg and how would you like to implement it OS independent? > - why 'it' doesn't clearly work on Linux. cdrecord clearly creates > this os specific to b,t,l mapping (e.g. in scsi-linux-ata.c, > scsi-wnt.c etc..). Why this mapping cannot be publicised in a > parseable format? Name a method that would work for anhy type of devices and any of the supported 21 OS. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:49 ` Joerg Schilling @ 2006-02-13 16:05 ` jerome lacoste 2006-02-13 16:24 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: jerome lacoste @ 2006-02-13 16:05 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > > > Sformat already includes such a mapping if you are on Solaris. > > > Unfortunately this does cleanly work on Linux and for this > > > reason is did not make it into cdrecord. > > > > Jorg, > > > > thanks for your answer. > > > > I fail to understand how it is connected to my proposal. Maybe we > > misunderstood each other. > > > > I assume that you refer to the sformat/fmt.c implementation (sformat > > 3.5) being reproduced in cdrecord/scsi_scan.c (latest cdrtools). > > > > Could you please elaborate on: > > - what does the sformat scanbus code has to do with my proposal, whose > > changes would mostly be located in the libscg modules, not in the > > cdrecord module > > What has your proposal to do with libscg The mapping I am talking about is currently done inside libscg (inside the scsi-*.c files). Hence libscg is the one capable of exposing this information to higher levels. > and how would you like to implement it OS independent? The information printed will be printed in a format such as: b,t,l <= os_specific_name This information is obviously not completely OS dependent (the os_specifc_name is OS specific). But it is exactly this information that would make your program integrable with OS specific user interfaces. And this information would only be outputted. Think about it in term of high level interface: struct mapping { btl btl; char* name; } mapping* get_drives(); void burn(btl, ....) To use your b,t,l naming effectively, we need to have a way to identify it correctly. and no scanbus is not sufficient because what is needed is the btl to os specific name. > > - why 'it' doesn't clearly work on Linux. cdrecord clearly creates > > this os specific to b,t,l mapping (e.g. in scsi-linux-ata.c, > > scsi-wnt.c etc..). Why this mapping cannot be publicised in a > > parseable format? > > Name a method that would work for anhy type of devices and any of the > supported 21 OS. I don't want to change anything cdrecord does. wrapper programs will still use your dev=b,t,l on all platforms. The publicised mapping would allow program to identify the correct b,t,l value. How does that sound? Jerome ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:05 ` jerome lacoste @ 2006-02-13 16:24 ` Joerg Schilling 2006-02-13 16:34 ` Jan Engelhardt ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 16:24 UTC (permalink / raw) To: schilling, jerome.lacoste Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton jerome lacoste <jerome.lacoste@gmail.com> wrote: > The mapping I am talking about is currently done inside libscg (inside > the scsi-*.c files). Hence libscg is the one capable of exposing this > information to higher levels. > > > and how would you like to implement it OS independent? > > The information printed will be printed in a format such as: > > b,t,l <= os_specific_name Why do you believe that this kind of mapping is needed? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:24 ` Joerg Schilling @ 2006-02-13 16:34 ` Jan Engelhardt 2006-02-13 16:37 ` Joerg Schilling 2006-02-13 16:36 ` Xavier Bestel 2006-02-13 17:12 ` jerome lacoste 2 siblings, 1 reply; 439+ messages in thread From: Jan Engelhardt @ 2006-02-13 16:34 UTC (permalink / raw) To: Joerg Schilling Cc: jerome.lacoste, peter.read, mj, matthias.andree, linux-kernel, jim, dhazelton >> 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:34 ` Jan Engelhardt @ 2006-02-13 16:37 ` Joerg Schilling 2006-02-13 19:19 ` Valdis.Kletnieks 2006-02-13 22:01 ` Carlo J. Calica 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 16:37 UTC (permalink / raw) To: schilling, jengelh Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, dhazelton Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >> The information printed will be printed in a format such as: > >> > >> b,t,l <= os_specific_name > > > >Why do you believe that this kind of mapping is needed? > > > > Assume the user has a /dev/white_dvd and a /dev/black_dvd, both of being > the same brand. `cdrecord -scanbus` would return sth like > > scsibus0: > 0,0,0 0) * > 0,1,0 1) 'HL-DT-ST' 'DVDRAM GSA-4160B' 'A301' Removable CD-ROM > 0,2,0 2) * > 0,3,0 3) * > 0,4,0 4) * > 0,5,0 5) * > 0,6,0 6) * > 0,7,0 7) * > scsibus1: > 1,0,0 0) * > 1,1,0 1) 'HL-DT-ST' 'DVDRAM GSA-4160B' 'A301' Removable CD-ROM > 1,2,0 2) * > 1,3,0 3) * > 1,4,0 4) * > 1,5,0 5) * > 1,6,0 6) * > 1,7,0 7) * > > probably. But how to find out from the btl which one is the black and which > one is the white one? A user has a bigger chance to do that from b,t,l than a program has when trying possible aliases.... And if you have a working vold on Solaris, libscg accepts the vold aliases. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:37 ` Joerg Schilling @ 2006-02-13 19:19 ` Valdis.Kletnieks 2006-02-14 11:48 ` Joerg Schilling 2006-02-13 22:01 ` Carlo J. Calica 1 sibling, 1 reply; 439+ messages in thread From: Valdis.Kletnieks @ 2006-02-13 19:19 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, dhazelton [-- Attachment #1: Type: text/plain, Size: 228 bytes --] On Mon, 13 Feb 2006 17:37:18 +0100, Joerg Schilling said: > And if you have a working vold on Solaris, libscg accepts the vold aliases. And if you have a working hald on Linux, libscg should therefor accept hald aliases. [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 19:19 ` Valdis.Kletnieks @ 2006-02-14 11:48 ` Joerg Schilling 2006-02-14 12:21 ` D. Hazelton ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 11:48 UTC (permalink / raw) To: Valdis.Kletnieks, schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh, dhazelton Valdis.Kletnieks@vt.edu wrote: > On Mon, 13 Feb 2006 17:37:18 +0100, Joerg Schilling said: > > > And if you have a working vold on Solaris, libscg accepts the vold aliases. > > And if you have a working hald on Linux, libscg should therefor accept hald aliases. How about pointing to _useful_ documentation: - How to find _any_ device that talks SCSI? - How does HAL allow one cdrecord instance to work without being interrupted by HAL? - How to send non disturbing SCSI commands from another cdrecord process in case one or more are already running? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 11:48 ` Joerg Schilling @ 2006-02-14 12:21 ` D. Hazelton 2006-02-14 16:42 ` Joerg Schilling 2006-02-14 12:23 ` Matthias Andree [not found] ` <515e525f0602140501j1f9fbe14x8a3eef0bbf179035@mail.gmail.com> 2 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-14 12:21 UTC (permalink / raw) To: Joerg Schilling Cc: Valdis.Kletnieks, peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh On Tuesday 14 February 2006 06:48, Joerg Schilling wrote: > Valdis.Kletnieks@vt.edu wrote: > > On Mon, 13 Feb 2006 17:37:18 +0100, Joerg Schilling said: > > > And if you have a working vold on Solaris, libscg accepts the vold > > > aliases. > > > > And if you have a working hald on Linux, libscg should therefor accept > > hald aliases. > > How about pointing to _useful_ documentation: > > - How to find _any_ device that talks SCSI? > > - How does HAL allow one cdrecord instance to work > without being interrupted by HAL? > > - How to send non disturbing SCSI commands from another > cdrecord process in case one or more are already running? > > Jörg Documentation? Didn't even take me two minutes to find the entire specification for hald on the net. http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only_with_tag=HEAD theres a link. if I wasn't half asleep I'd actually dig through it and find the information you're asking about. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 12:21 ` D. Hazelton @ 2006-02-14 16:42 ` Joerg Schilling 2006-02-14 16:57 ` grundig 2006-02-14 22:22 ` D. Hazelton 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 16:42 UTC (permalink / raw) To: schilling, dhazelton Cc: Valdis.Kletnieks, peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh "D. Hazelton" <dhazelton@enter.net> wrote: > > How about pointing to _useful_ documentation: > > > > - How to find _any_ device that talks SCSI? > > > > - How does HAL allow one cdrecord instance to work > > without being interrupted by HAL? > > > > - How to send non disturbing SCSI commands from another > > cdrecord process in case one or more are already running? > > > > Jörg > > Documentation? > > Didn't even take me two minutes to find the entire specification for hald on > the net. > > http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only_with_tag=HEAD > ???? Did yoiu try to read this? I like to see a whitepaper first that allows me to get an overview in less than 10 minutes. If this is not available, I suspect you just try another attempt to waste my time. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:42 ` Joerg Schilling @ 2006-02-14 16:57 ` grundig 2006-02-14 17:42 ` Joerg Schilling 2006-02-14 22:22 ` D. Hazelton 1 sibling, 1 reply; 439+ messages in thread From: grundig @ 2006-02-14 16:57 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, Valdis.Kletnieks, peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh El Tue, 14 Feb 2006 17:42:27 +0100, Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > I like to see a whitepaper first that allows me to get an overview in less than > 10 minutes. If this is not available, I suspect you just try another attempt to > waste my time. A "overview"? And "I'll only waste 10 minutes of my life to look at this"? Strange way to handle design decisions for a software developer - there're people who will not just read that paper, but read aswell the code to take such decisions. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:57 ` grundig @ 2006-02-14 17:42 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 17:42 UTC (permalink / raw) To: schilling, grundig Cc: Valdis.Kletnieks, peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh, dhazelton <grundig@teleline.es> wrote: > El Tue, 14 Feb 2006 17:42:27 +0100, > Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > > > > I like to see a whitepaper first that allows me to get an overview in less than > > 10 minutes. If this is not available, I suspect you just try another attempt to > > waste my time. > > A "overview"? And "I'll only waste 10 minutes of my life to look at this"? Strange > way to handle design decisions for a software developer - there're people who > will not just read that paper, but read aswell the code to take such decisions. If _you_ did not watste so much from my time, there was a chance..... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:42 ` Joerg Schilling 2006-02-14 16:57 ` grundig @ 2006-02-14 22:22 ` D. Hazelton 1 sibling, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-14 22:22 UTC (permalink / raw) To: Joerg Schilling Cc: Valdis.Kletnieks, peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh On Tuesday 14 February 2006 11:42, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > How about pointing to _useful_ documentation: > > > > > > - How to find _any_ device that talks SCSI? > > > > > > - How does HAL allow one cdrecord instance to work > > > without being interrupted by HAL? > > > > > > - How to send non disturbing SCSI commands from another > > > cdrecord process in case one or more are already running? > > > > > > Jörg > > > > Documentation? > > > > Didn't even take me two minutes to find the entire specification for hald > > on the net. > > > > http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only > >_with_tag=HEAD > > ???? > Did yoiu try to read this? Did you notice my comment? When I sent that message I'd been awake for nearly 24 hours helping a friend through depression and was ready to fall asleep while checking my email. I have since read it and I understand your problem. That documentation does state, however, that the HAL system is normally accessed via the dbus system message bus. In order to help you with that facet of things here is a link to the dbus documentation: http://dbus.freedesktop.org/doc/dbus-specification.html And I will look into the HAL source code and provided headers to see if I cannot find you a direct interface such as dbus has with HAL. But not at the current moment, as I am limited in my available time. > I like to see a whitepaper first that allows me to get an overview in less > than 10 minutes. If this is not available, I suspect you just try another > attempt to waste my time. Huh? I understood HAL in less than ten minutes from that specification. But then, any competant programmer would spend a great deal more time on learning an interface. I have been studying the ATAPI, SCSI and MMC specs for more than six months now and, while I have a firm grasp of the concepts, could not sit down and write a piece of software that spoke those protocols. (This is mainly because I haven't been focusing on them, but rather referencing in passing after having read them in their entirety at least once) DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 11:48 ` Joerg Schilling 2006-02-14 12:21 ` D. Hazelton @ 2006-02-14 12:23 ` Matthias Andree 2006-02-14 22:51 ` Rob Landley [not found] ` <515e525f0602140501j1f9fbe14x8a3eef0bbf179035@mail.gmail.com> 2 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-14 12:23 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 12:23 ` Matthias Andree @ 2006-02-14 22:51 ` Rob Landley 2006-02-14 23:24 ` Olivier Galibert 2006-02-15 0:04 ` Matthias Andree 0 siblings, 2 replies; 439+ messages in thread From: Rob Landley @ 2006-02-14 22:51 UTC (permalink / raw) To: Matthias Andree; +Cc: Linux-Kernel mailing list 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 22:51 ` Rob Landley @ 2006-02-14 23:24 ` Olivier Galibert 2006-02-15 0:26 ` Rob Landley 2006-02-15 2:19 ` D. Hazelton 2006-02-15 0:04 ` Matthias Andree 1 sibling, 2 replies; 439+ messages in thread From: Olivier Galibert @ 2006-02-14 23:24 UTC (permalink / raw) To: Rob Landley; +Cc: Matthias Andree, Linux-Kernel mailing list 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 23:24 ` Olivier Galibert @ 2006-02-15 0:26 ` Rob Landley 2006-02-15 2:19 ` D. Hazelton 1 sibling, 0 replies; 439+ messages in thread From: Rob Landley @ 2006-02-15 0:26 UTC (permalink / raw) To: Olivier Galibert; +Cc: Matthias Andree, Linux-Kernel mailing list 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 23:24 ` Olivier Galibert 2006-02-15 0:26 ` Rob Landley @ 2006-02-15 2:19 ` D. Hazelton 2006-02-15 2:32 ` grundig 1 sibling, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-15 2:19 UTC (permalink / raw) To: Olivier Galibert; +Cc: Rob Landley, Matthias Andree, Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 2:19 ` D. Hazelton @ 2006-02-15 2:32 ` grundig 0 siblings, 0 replies; 439+ messages in thread From: grundig @ 2006-02-15 2:32 UTC (permalink / raw) To: D. Hazelton; +Cc: galibert, rob, matthias.andree, linux-kernel El Tue, 14 Feb 2006 21:19:42 -0500, "D. Hazelton" <dhazelton@enter.net> escribió: > However it is a C++ application, and I don't know about other people, but for > various historic reasons I'd rather use C for a command-line application. And This doesn't have any sense at all, there's no reason why C++ is not a valid language for command line apps (like C is perfect...hint: python/perl/etc are famous languages to write command line scripts because of a reason). There's lot of serious software written in C++ (dpkg, for one). C in fact was created to write a operative system in a time when writting things in asm was the rule. Looking back at the history and learning the lesson from C, common sense tells me that there're lots of problems that can be solved in a much easier way with C++ just like C vs asm in the 60-70's.... ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 22:51 ` Rob Landley 2006-02-14 23:24 ` Olivier Galibert @ 2006-02-15 0:04 ` Matthias Andree 2006-02-15 2:55 ` Rob Landley 1 sibling, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-15 0:04 UTC (permalink / raw) To: Rob Landley; +Cc: Matthias Andree, Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 0:04 ` Matthias Andree @ 2006-02-15 2:55 ` Rob Landley 2006-02-15 6:13 ` Anders Karlsson ` (3 more replies) 0 siblings, 4 replies; 439+ messages in thread From: Rob Landley @ 2006-02-15 2:55 UTC (permalink / raw) To: Matthias Andree; +Cc: Linux-Kernel mailing list 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 2:55 ` Rob Landley @ 2006-02-15 6:13 ` Anders Karlsson 2006-02-15 8:37 ` Matthias Andree ` (2 subsequent siblings) 3 siblings, 0 replies; 439+ messages in thread From: Anders Karlsson @ 2006-02-15 6:13 UTC (permalink / raw) To: Rob Landley, Matthias Andree; +Cc: Linux-Kernel mailing list On Wed, 15 Feb 2006 02:55:03 -0000, Rob Landley <rob@landley.net> wrote: [snip] > The last gasp of the SCSI bigots is Serial Attached Scsi. It's > hilarious. Electrically it's identical (they just gold-plate the > connectors and such so they can charge more for it). The > giveaway is that you can plug a SATA drive into a SAS controller > and it works on "dual standard" controller firmware. > Which one's going to have the unit volume to be cheap and sell > through its inventory to bring out new generations faster? And > which one is exactly the same technology with buckets of hype, > slightly different firmware, and a huge markup for the people who > still think that because ISA sucked, its designated successor PCI > can't be trusted? > > Buying the exact same technology for way more money, based on a > two-decade old bias in an industry where a given generation of > hardware becomes obsolete every 3 years. Funny to me, anyway... [snip] SAS will have the old SCSI advantage of multiple devices per chain though. That is something that is very off-putting about SATA actually that you need as many interfaces as you have disks. For commercial reasons, you'll probably find that the more expensive SAS disks will be the ones with the lower seek-times, the better warranties etc. We may not like it, but it ain't going to change in a hurry. Regards, -- Anders Karlsson <anders@trudheim.com> QA Engineer | GnuPG Key ID - 0x4B20601A ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 2:55 ` Rob Landley 2006-02-15 6:13 ` Anders Karlsson @ 2006-02-15 8:37 ` Matthias Andree 2006-02-15 18:31 ` Lennart Sorensen 2006-02-17 8:54 ` Helge Hafting 3 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-15 8:37 UTC (permalink / raw) To: Rob Landley; +Cc: Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 2:55 ` Rob Landley 2006-02-15 6:13 ` Anders Karlsson 2006-02-15 8:37 ` Matthias Andree @ 2006-02-15 18:31 ` Lennart Sorensen 2006-02-15 19:09 ` Rob Landley 2006-02-17 8:54 ` Helge Hafting 3 siblings, 1 reply; 439+ messages in thread From: Lennart Sorensen @ 2006-02-15 18:31 UTC (permalink / raw) To: Rob Landley; +Cc: Matthias Andree, Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 18:31 ` Lennart Sorensen @ 2006-02-15 19:09 ` Rob Landley 2006-02-15 19:16 ` Doug McNaught ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Rob Landley @ 2006-02-15 19:09 UTC (permalink / raw) To: Lennart Sorensen; +Cc: Matthias Andree, Linux-Kernel mailing list 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 19:09 ` Rob Landley @ 2006-02-15 19:16 ` Doug McNaught 2006-02-15 19:47 ` Rob Landley 2006-02-15 19:50 ` Lennart Sorensen 2006-02-16 3:06 ` John Stoffel 2 siblings, 1 reply; 439+ messages in thread From: Doug McNaught @ 2006-02-15 19:16 UTC (permalink / raw) To: Rob Landley; +Cc: Lennart Sorensen, Matthias Andree, Linux-Kernel mailing list Rob Landley <rob@landley.net> writes: > On Wednesday 15 February 2006 1:31 pm, Lennart Sorensen wrote: >> once. > > Yup. Apparently with SAS, the controllers are far more likely to fail than > the drives. I think the actual idea (or one of them) is to have two machines connected to each drive, in a hot-standby configuration. This has been done for a long time with parallel SCSI, where both machines have controllers on the bus. -Doug ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 19:16 ` Doug McNaught @ 2006-02-15 19:47 ` Rob Landley 0 siblings, 0 replies; 439+ messages in thread From: Rob Landley @ 2006-02-15 19:47 UTC (permalink / raw) To: Doug McNaught Cc: Lennart Sorensen, Matthias Andree, Linux-Kernel mailing list On Wednesday 15 February 2006 2:16 pm, Doug McNaught wrote: > Rob Landley <rob@landley.net> writes: > > On Wednesday 15 February 2006 1:31 pm, Lennart Sorensen wrote: > >> once. > > > > Yup. Apparently with SAS, the controllers are far more likely to fail > > than the drives. > > I think the actual idea (or one of them) is to have two machines > connected to each drive, in a hot-standby configuration. This has > been done for a long time with parallel SCSI, where both machines have > controllers on the bus. Ah. I'm used to projects doing that through ethernet instead, in various hand-rolled implementations. A generic solution for staying in sync through the network would be nice. A potentially interesting project might be hooking into the journaling stuff to update a network block device as data gets flushed out of the journal. It'd need some kind of heartbeat mechanism (if the network block device doesn't confirm receipt of the data within X seconds, don't hold up flushing the journal to the filesystem and moving on with life). And some mechanism to get back in sync after getting out of sync, which could be done a number of ways. I wonder if there's already something like this? (Probably...) > -Doug Rob -- Never bet against the cheap plastic solution. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 19:09 ` Rob Landley 2006-02-15 19:16 ` Doug McNaught @ 2006-02-15 19:50 ` Lennart Sorensen 2006-02-15 21:31 ` Rob Landley 2006-02-17 15:33 ` Jan Engelhardt 2006-02-16 3:06 ` John Stoffel 2 siblings, 2 replies; 439+ messages in thread From: Lennart Sorensen @ 2006-02-15 19:50 UTC (permalink / raw) To: Rob Landley; +Cc: Matthias Andree, Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 19:50 ` Lennart Sorensen @ 2006-02-15 21:31 ` Rob Landley 2006-02-17 9:06 ` Helge Hafting 2006-02-17 15:33 ` Jan Engelhardt 1 sibling, 1 reply; 439+ messages in thread From: Rob Landley @ 2006-02-15 21:31 UTC (permalink / raw) To: Lennart Sorensen; +Cc: Matthias Andree, Linux-Kernel mailing list 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 21:31 ` Rob Landley @ 2006-02-17 9:06 ` Helge Hafting 2006-02-17 13:07 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Helge Hafting @ 2006-02-17 9:06 UTC (permalink / raw) To: Rob Landley; +Cc: Lennart Sorensen, Matthias Andree, Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 9:06 ` Helge Hafting @ 2006-02-17 13:07 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-17 13:07 UTC (permalink / raw) To: Helge Hafting; +Cc: Rob Landley, Lennart Sorensen, Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 19:50 ` Lennart Sorensen 2006-02-15 21:31 ` Rob Landley @ 2006-02-17 15:33 ` Jan Engelhardt 1 sibling, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-17 15:33 UTC (permalink / raw) To: Lennart Sorensen; +Cc: Rob Landley, Matthias Andree, Linux-Kernel mailing list > >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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 19:09 ` Rob Landley 2006-02-15 19:16 ` Doug McNaught 2006-02-15 19:50 ` Lennart Sorensen @ 2006-02-16 3:06 ` John Stoffel 2006-02-16 3:32 ` Rob Landley 2 siblings, 1 reply; 439+ messages in thread From: John Stoffel @ 2006-02-16 3:06 UTC (permalink / raw) To: Rob Landley; +Cc: Lennart Sorensen, Matthias Andree, Linux-Kernel mailing list >>>>> "Rob" == Rob Landley <rob@landley.net> writes: Rob> Yup. Apparently with SAS, the controllers are far more likely to Rob> fail than the drives. While a single drive is more likely to fail when compared to a single controller, for a truly redundant system you want no single point of failure, which means redundant controllers is a requirement. >> Makes redundant systems much simpler to build if you can connect >> each physical drive to two places at once. Rob> Or you could use raid and get complete redundancy rather than two Rob> paths to the same single point of failure. Your choice. Excuse me? Think about what you just wrote here and what you're implying. Of course you would use RAID here, along with two controllers and two paths to the single disk. But you'd also have multiple disks here as well. Not a single disk and two controllers and consider that reliable. >> They support port expanders (which SATA seems to be starting to >> support although more limited). Rob> I still don't see why drives are expected to be more reliable Rob> than controllers. He never said they were. Rob> I think the most paranoid setup I've seen was six disks holding Rob> two disks worth of information. A three way raid-5, mirrored. Rob> It could lose any three disks out of the group, and several 4 Rob> disk combinations. If six SATA drives are cheaper than two SAS Rob> drives. (Yeah, the CRC calculation eats CPU and flushes your Rob> cache. So what?) And how many controllers could that setup lose? You need to think of the whole path, not just the disks at the ends, when you are planning for reliability (and performance as well). Also, with dual ports on a drive, it becomes much easier to build two machine clusters which both can see all the drives shared between the clusters. Just like SCSI (old, original 5MB/S scsi) where you changed hte ID of one of the initiators. Not done frequently, but certainly done alot with VMS/VAX clusters. Rob> I keep thinking there should be something more useful you could Rob> do than "hot spare" with extra disks in simple RAID 5, some way Rob> of dynamically scaling more parity info. But it's not an area I Rob> play in much... RAID6, or as NetApp calls it, Dual Parity. You can lose any TWO disks in a raid group and still be working. It covers to more common single disk fails, and then you still have full parity coverage if another disk fails during the re-build of the parity info onto the spare drive. With 250Gb disks, that run a 50MB/S, it takes a LONG time to actually sweep though all the data and rebuild the parity. 24 hours or more. So to cover your butt, you'd like to have even more redundancy. I've run fully mirrored servers, where I had redundant paths to each disk from each controller. When I lost a controller, which certainly happened, I didn't lose any data, nor disk I lose mirroring either. Very nice. In the situtations where I only had one controller per set of disks, and mirrored between controlles, losing a controller meant I had to re-mirror things once they got running again, but I didn't lose data. Very nice. Building reliable disk storage is not cheap. Fast, reliable, cheap. Pick any two. :] John ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 3:06 ` John Stoffel @ 2006-02-16 3:32 ` Rob Landley 2006-02-16 4:08 ` Alexander Samad 0 siblings, 1 reply; 439+ messages in thread From: Rob Landley @ 2006-02-16 3:32 UTC (permalink / raw) To: John Stoffel; +Cc: Lennart Sorensen, Matthias Andree, Linux-Kernel mailing list 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 3:32 ` Rob Landley @ 2006-02-16 4:08 ` Alexander Samad 0 siblings, 0 replies; 439+ messages in thread From: Alexander Samad @ 2006-02-16 4:08 UTC (permalink / raw) To: Linux-Kernel mailing list [-- Attachment #1: Type: text/plain, Size: 756 bytes --] On Wed, Feb 15, 2006 at 10:32:54PM -0500, Rob Landley wrote: > On Wednesday 15 February 2006 10:06 pm, John Stoffel wrote: > > Building reliable disk storage is not cheap. Fast, reliable, cheap. > > Pick any two. :] > > Nah, I start by picking cheap anyway, and apparently if I want reliable that > just means it'd be slow by your formula. :) any particular reason we haven't talked about SAN's > > > John > > Rob > -- > Never bet against the cheap plastic solution. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 2:55 ` Rob Landley ` (2 preceding siblings ...) 2006-02-15 18:31 ` Lennart Sorensen @ 2006-02-17 8:54 ` Helge Hafting 3 siblings, 0 replies; 439+ messages in thread From: Helge Hafting @ 2006-02-17 8:54 UTC (permalink / raw) To: Rob Landley; +Cc: Matthias Andree, Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
[parent not found: <515e525f0602140501j1f9fbe14x8a3eef0bbf179035@mail.gmail.com>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <515e525f0602140501j1f9fbe14x8a3eef0bbf179035@mail.gmail.com> @ 2006-02-14 16:47 ` Joerg Schilling 2006-02-14 17:08 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 16:47 UTC (permalink / raw) To: trudheim, schilling Cc: Valdis.Kletnieks, peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh, dhazelton Anders Karlsson <trudheim@gmail.com> wrote: > On 2/14/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > [snip] > > - How does HAL allow one cdrecord instance to work > > without being interrupted by HAL? > > Uuh, if the writer unit is plugged in via USB and HAL detects it going > away, as in getting disconnected from the system, don't you think it > would be a smart move for cdrecord to pay attention to such an alert? > > I am sure you can explain to me if there are overwhelming technical > reason to continue dumping data to a non-existant device. It seems that you did not loisten to this discussion before, why doyou come in now not knowing the topcis? Try to get hand on the deleted bug entries on Debian and you will see how cdrecord is interrupted. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:47 ` Joerg Schilling @ 2006-02-14 17:08 ` Matthias Andree 2006-02-14 18:05 ` Jan Engelhardt 2006-02-14 17:47 ` Lennart Sorensen 2006-02-14 18:42 ` Jim Crilly 2 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-14 17:08 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-14: > Try to get hand on the deleted bug entries on Debian and you will see how > cdrecord is interrupted. How about you offer a few "deleted bug" numbers? Or have you been so sloppy not to record the bugs of interest in external packages? -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 17:08 ` Matthias Andree @ 2006-02-14 18:05 ` Jan Engelhardt 0 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-14 18:05 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, Linux-Kernel mailing list > >> Try to get hand on the deleted bug entries on Debian and you will see how >> cdrecord is interrupted. > >How about you offer a few "deleted bug" numbers? > why does debian delete bugs after all? this sounds like aggregativing searches for it. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:47 ` Joerg Schilling 2006-02-14 17:08 ` Matthias Andree @ 2006-02-14 17:47 ` Lennart Sorensen 2006-02-14 18:42 ` Jim Crilly 2 siblings, 0 replies; 439+ messages in thread From: Lennart Sorensen @ 2006-02-14 17:47 UTC (permalink / raw) To: Joerg Schilling Cc: trudheim, Valdis.Kletnieks, peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh, dhazelton On Tue, Feb 14, 2006 at 05:47:55PM +0100, Joerg Schilling wrote: > It seems that you did not loisten to this discussion before, why doyou come in > now not knowing the topcis? > > Try to get hand on the deleted bug entries on Debian and you will see how > cdrecord is interrupted. Debian archives old closed bugs. They can still be found by searching the archived bugs. I have never seen them delete bugs, although maybe they do and I just missed it. Len Sorensen ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:47 ` Joerg Schilling 2006-02-14 17:08 ` Matthias Andree 2006-02-14 17:47 ` Lennart Sorensen @ 2006-02-14 18:42 ` Jim Crilly 2 siblings, 0 replies; 439+ messages in thread From: Jim Crilly @ 2006-02-14 18:42 UTC (permalink / raw) To: Joerg Schilling Cc: trudheim, Valdis.Kletnieks, peter.read, mj, matthias.andree, linux-kernel, jerome.lacoste, jengelh, dhazelton On 02/14/06 05:47:55PM +0100, Joerg Schilling wrote: > Anders Karlsson <trudheim@gmail.com> wrote: > > > On 2/14/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > [snip] > > > - How does HAL allow one cdrecord instance to work > > > without being interrupted by HAL? > > > > Uuh, if the writer unit is plugged in via USB and HAL detects it going > > away, as in getting disconnected from the system, don't you think it > > would be a smart move for cdrecord to pay attention to such an alert? > > > > I am sure you can explain to me if there are overwhelming technical > > reason to continue dumping data to a non-existant device. > > It seems that you did not loisten to this discussion before, why doyou come in > now not knowing the topcis? > > Try to get hand on the deleted bug entries on Debian and you will see how > cdrecord is interrupted. > > Jörg Apparently you're the one not paying attention, the so-called bugs you were talking about haven't been deleted and I even mentioned that I found them in this 'discussion' days ago. Jim. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:37 ` Joerg Schilling 2006-02-13 19:19 ` Valdis.Kletnieks @ 2006-02-13 22:01 ` Carlo J. Calica 1 sibling, 0 replies; 439+ messages in thread From: Carlo J. Calica @ 2006-02-13 22:01 UTC (permalink / raw) To: linux-kernel Joerg Schilling wrote: > > And if you have a working vold on Solaris, libscg accepts the vold > aliases. > But vold isn't supported on all cdrecord platforms? Why do you support that but not Linux equivalents? ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:24 ` Joerg Schilling 2006-02-13 16:34 ` Jan Engelhardt @ 2006-02-13 16:36 ` Xavier Bestel 2006-02-13 17:12 ` jerome lacoste 2 siblings, 0 replies; 439+ messages in thread From: Xavier Bestel @ 2006-02-13 16:36 UTC (permalink / raw) To: Joerg Schilling Cc: jerome.lacoste, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton On Mon, 2006-02-13 at 17:24, Joerg Schilling wrote: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > b,t,l <= os_specific_name > > Why do you believe that this kind of mapping is needed? Eh .. because b,t,l mapping isn't stable under linux ! Xav ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:24 ` Joerg Schilling 2006-02-13 16:34 ` Jan Engelhardt 2006-02-13 16:36 ` Xavier Bestel @ 2006-02-13 17:12 ` jerome lacoste 2006-02-13 18:12 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: jerome lacoste @ 2006-02-13 17:12 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > > The mapping I am talking about is currently done inside libscg (inside > > the scsi-*.c files). Hence libscg is the one capable of exposing this > > information to higher levels. > > > > > and how would you like to implement it OS independent? > > > > The information printed will be printed in a format such as: > > > > b,t,l <= os_specific_name > > Why do you believe that this kind of mapping is needed? To make it so that: - cdrecord keeps its dev=b,t,l command line interface - a cdrecord wrapper program lets a user specify the os specific name to access the drive. The wrapper program would identify the b,t,l name and feed it correctly to cdrecord. This can also be used to correctly identify 2 identical drives using their OS specific names. -scanbus displays: 1,0,0: DRIVE MODEL XYZ 2,0,0: DRIVE MODEL XYZ but thank to that proposal, one would also have: 1,0,0 <= /dev/hdc 2,0,0 <= /dev/hdd I think it's a good compromise between what the users want and what you want. So, WDYT? Jerome ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:12 ` jerome lacoste @ 2006-02-13 18:12 ` Joerg Schilling 2006-02-14 11:31 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 18:12 UTC (permalink / raw) To: schilling, jerome.lacoste Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton jerome lacoste <jerome.lacoste@gmail.com> wrote: > To make it so that: > > - cdrecord keeps its dev=b,t,l command line interface > > - a cdrecord wrapper program lets a user specify the os specific name > to access the drive. The wrapper program would identify the b,t,l name > and feed it correctly to cdrecord. This can also be used to correctly > identify 2 identical drives using their OS specific names. > > -scanbus displays: > 1,0,0: DRIVE MODEL XYZ > 2,0,0: DRIVE MODEL XYZ > > but thank to that proposal, one would also have: > > 1,0,0 <= /dev/hdc > 2,0,0 <= /dev/hdd > > I think it's a good compromise between what the users want and what you want. > > So, WDYT? If this would not be Linux only, go ahead. Note that you would have to do real hard work as it is not trivial to prove your patch on all supported OS.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 18:12 ` Joerg Schilling @ 2006-02-14 11:31 ` Joerg Schilling 2006-02-14 12:15 ` D. Hazelton 2006-02-14 12:43 ` jerome lacoste 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 11:31 UTC (permalink / raw) To: schilling, jerome.lacoste Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > but thank to that proposal, one would also have: > > > > 1,0,0 <= /dev/hdc > > 2,0,0 <= /dev/hdd > > > > I think it's a good compromise between what the users want and what you want. > > > > So, WDYT? > > If this would not be Linux only, go ahead. > > Note that you would have to do real hard work as it is not trivial to prove your > patch on all supported OS.... I did get no reply. Does this mean that you are no longer interested because I request real work instead of a cheap hack? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 11:31 ` Joerg Schilling @ 2006-02-14 12:15 ` D. Hazelton 2006-02-14 16:40 ` Joerg Schilling 2006-02-14 12:43 ` jerome lacoste 1 sibling, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-14 12:15 UTC (permalink / raw) To: Joerg Schilling Cc: jerome.lacoste, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Tuesday 14 February 2006 06:31, Joerg Schilling wrote: > Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > > but thank to that proposal, one would also have: > > > > > > 1,0,0 <= /dev/hdc > > > 2,0,0 <= /dev/hdd > > > > > > I think it's a good compromise between what the users want and what you > > > want. > > > > > > So, WDYT? > > > > If this would not be Linux only, go ahead. > > > > Note that you would have to do real hard work as it is not trivial to > > prove your patch on all supported OS.... > > I did get no reply. > > Does this mean that you are no longer interested because I request real > work instead of a cheap hack? Joerg, enough with the personal attacks. That you didn't see the reply is just proof that you don't read the entirety of messages posted or sent to you directly. here is both responses: in one he posts the contents of a single line of code that he added to the linux wrapper code in libscg. In the second he asks for a guarantee that you will stand behind your (somewhat sketchy) posted guidelines for patches. And what follows from here out is the relevant portions of the messages, complete with the "Message ID" field from the headers in case you want to dig through you inbox or wherever you misfiled these responses to read the entirety of them. DRH Message-ID: <5a2cf1f60602130407j79805b8al55fe999426d90b97@mail.gmail.com> <snip> I am aiming for a compromise. My point is that people want to use dev=/dev/hdc in their interface, because that's what they are used to. That's a point that I think you cannot deny. If you want to still keep your dev=b,t,l command line interface, just let the users know how your mapping is done. That will allow a cdrecord wrapper to first query the mapping, then using this mapping information and OS specific information (e.g. links) identify the b,t,l expected by your interface. That way you have mostly no code change to do. And you keep your b,t,l naming. Everybody is happy. I've added something like: fprintf(stdout, "%d,%d,%d <= /dev/%s\n", first_free_schilly_bus, t, l, token[ID_TOKEN_SUBSYSTEM] ); in scsi-linux-ata.c and it does what I want. WDYT? Cheers, Jerome Message-ID: <5a2cf1f60602130608qf6a2575ucbd57615eb32cc67@mail.gmail.com> On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > > Are you accepting such a patch? > > > > If his response to the last patch someone provided is any example the answer > > is going to be no. And I firmly believe the old adage that a leopard can't > > change it's spots. > > Any patch that > > - does not break things > > - fits into the spirit of the currnt implementation > > - offers useful new features > > - conforms to coding style standards > > - does not need more time to integrate than I would need to > write this from scratch > > Unfortunately, many people who send patches to me do not follow > these simple rules. I am still waiting for an answer as to whether such a patch would be accepted. We will take on the practical details later on. Jerome ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 12:15 ` D. Hazelton @ 2006-02-14 16:40 ` Joerg Schilling 2006-02-14 22:12 ` D. Hazelton 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 16:40 UTC (permalink / raw) To: schilling, dhazelton Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh "D. Hazelton" <dhazelton@enter.net> wrote: > > > > I think it's a good compromise between what the users want and what you > > > > want. > > > > > > > > So, WDYT? > > > > > > If this would not be Linux only, go ahead. > > > > > > Note that you would have to do real hard work as it is not trivial to > > > prove your patch on all supported OS.... > > > > I did get no reply. > > > > Does this mean that you are no longer interested because I request real > > work instead of a cheap hack? > > > Joerg, enough with the personal attacks. That you didn't see the reply is just > proof that you don't read the entirety of messages posted or sent to you > directly. > > here is both responses: It seems that you still not understand that you cannot demand things from me that Linux does not offer at all. The person who had problem with the fact that I like a patch to fit into the spirit of the current implementation obviously does not know that he tries to demand things that he will not get from any known project. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:40 ` Joerg Schilling @ 2006-02-14 22:12 ` D. Hazelton 0 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-14 22:12 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh On Tuesday 14 February 2006 11:40, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > > > I think it's a good compromise between what the users want and what > > > > > you want. > > > > > > > > > > So, WDYT? > > > > > > > > If this would not be Linux only, go ahead. > > > > > > > > Note that you would have to do real hard work as it is not trivial to > > > > prove your patch on all supported OS.... > > > > > > I did get no reply. > > > > > > Does this mean that you are no longer interested because I request real > > > work instead of a cheap hack? > > > > Joerg, enough with the personal attacks. That you didn't see the reply is > > just proof that you don't read the entirety of messages posted or sent to > > you directly. > > > > here is both responses: > > It seems that you still not understand that you cannot demand things from > me that Linux does not offer at all. > > The person who had problem with the fact that I like a patch to fit into > the spirit of the current implementation obviously does not know that he > tries to demand things that he will not get from any known project. > > Jörg And what was demanded? He asked for an assurance that you would look at the patch and at least consider including it rather than debying it sight unseen as you did with Matthias' patch. Furthermore, he provided a sample of what he was doing to achieve the goal he posted of having cdrecord print useful data for those people who have multiple devices and to whom the btl addresses and vendor strings mean little. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 11:31 ` Joerg Schilling 2006-02-14 12:15 ` D. Hazelton @ 2006-02-14 12:43 ` jerome lacoste 2006-02-14 16:45 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: jerome lacoste @ 2006-02-14 12:43 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton On 2/14/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > > but thank to that proposal, one would also have: > > > > > > 1,0,0 <= /dev/hdc > > > 2,0,0 <= /dev/hdd > > > > > > I think it's a good compromise between what the users want and what you want. > > > > > > So, WDYT? > > > > If this would not be Linux only, go ahead. > > > > Note that you would have to do real hard work as it is not trivial to prove your > > patch on all supported OS.... > > I did get no reply. Nothin I read above give me the impression that you expected an answer. > Does this mean that you are no longer interested because I request real work > instead of a cheap hack? ... Jerome ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 12:43 ` jerome lacoste @ 2006-02-14 16:45 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 16:45 UTC (permalink / raw) To: schilling, jerome.lacoste Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, dhazelton jerome lacoste <jerome.lacoste@gmail.com> wrote: > > > > 1,0,0 <= /dev/hdc > > > > 2,0,0 <= /dev/hdd > > > > > > > > I think it's a good compromise between what the users want and what you want. > > > > > > > > So, WDYT? > > > > > > If this would not be Linux only, go ahead. > > > > > > Note that you would have to do real hard work as it is not trivial to prove your > > > patch on all supported OS.... > > > > I did get no reply. > > Nothin I read above give me the impression that you expected an answer. Isn't a reply an act of politeness? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:40 ` CD writing in future Linux (stirring up a hornets' nest) Joerg Schilling 2006-02-13 10:52 ` Martin Mares 2006-02-13 12:07 ` jerome lacoste @ 2006-02-13 22:57 ` D. Hazelton 2 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-13 22:57 UTC (permalink / raw) To: Joerg Schilling Cc: jerome.lacoste, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Monday 13 February 2006 05:40, Joerg Schilling wrote: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > > "D. Hazelton" <dhazelton@enter.net> wrote: > > > > And does cdrecord even need libscg anymore? From having actually gone > > > > through your code, Joerg, I can tell you that it does serve a larger > > > > purpose. But at this point I have to ask - besides cdrecord and a few > > > > other _COMPACT_ _DISC_ writing programs, does _ANYONE_ use libscg? Is > > > > it ever used to access any other devices that are either SCSI or use > > > > a SCSI command protocol (like ATAPI)? My point there is that you > > > > have a wonderful library, but despite your wishes, there is no proof > > > > that it is ever used for anything except writing/ripping CD's. > > > > > > Name a single program (not using libscg) that implements user space > > > SCSI and runs on as many platforms as cdrecord/libscg does. > > > > I have 2 technical questions, and I hope that you will take the time > > to answer them. > > > > 1) extract from the README of the latest stable cdrtools package: > > > > Linux driver design oddities > > ****************************************** Although cdrecord supports to > > use dev=/dev/sgc, it is not recommended and it is unsupported. > > > > The /dev/sg* device mapping in Linux is not stable! Using > > dev=/dev/sgc in a shell script may fail after a reboot because the device > > you want to talk to has moved to /dev/sgd. For the proper and OS > > independent dev=<bus>,<tgt>,<lun> syntax read the man page of cdrecord. > > > > My understanding of that is you say to not use dev=/dev/sgc because it > > isn't stable. Now that you've said that bus,tgt,lun is not stable on > > Linux (because of a "Linux bug") why is the b,t,l scheme preferred > > over the /dev/sg* one ? > > b,t,l _is_ stable as long as the OS does a reasonable and orthogonal work. > > This was true until ~ 2001, when Linux introduced unstable USB handling. > Note that this fact is not a failure from libscg but from Linux. Isn't that also when the USB system underwent a massive rewrite to fully support hotplugging and to fix a lot of bugs that were present in the original implementation? Still, the question I posed in my earlier post remains - why can't you have your program do the BTL mappings behind the scenes? You can easily allow it from the command line and also allow pointing to a /dev entry... If you want I'll actually put together a patch based on whatever version of cdrecord I have here on my system and send it to you. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 13:03 ` Joerg Schilling ` (2 preceding siblings ...) 2006-02-10 15:38 ` jerome lacoste @ 2006-02-13 0:44 ` Alexander Samad 2006-02-13 14:12 ` jerome lacoste 4 siblings, 0 replies; 439+ messages in thread From: Alexander Samad @ 2006-02-13 0:44 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh [-- Attachment #1: Type: text/plain, Size: 1726 bytes --] On Fri, Feb 10, 2006 at 02:03:30PM +0100, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > And does cdrecord even need libscg anymore? From having actually gone through > > your code, Joerg, I can tell you that it does serve a larger purpose. But at > > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_ > > writing programs, does _ANYONE_ use libscg? Is it ever used to access any > > other devices that are either SCSI or use a SCSI command protocol (like > > ATAPI)? My point there is that you have a wonderful library, but despite > > your wishes, there is no proof that it is ever used for anything except > > writing/ripping CD's. > > Name a single program (not using libscg) that implements user space SCSI and runs > on as many platforms as cdrecord/libscg does. Isnt this like saying why do we need windows server software when we have Novell running most of the worlds server and again why do we need linux when we have Microsoft running a majourity of the worlds servers. Why cause we evolve we try to make things better, natural evolution > > J?rg > > -- > EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin > js@cs.tu-berlin.de (uni) > schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 13:03 ` Joerg Schilling ` (3 preceding siblings ...) 2006-02-13 0:44 ` Alexander Samad @ 2006-02-13 14:12 ` jerome lacoste 4 siblings, 0 replies; 439+ messages in thread From: jerome lacoste @ 2006-02-13 14:12 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > And does cdrecord even need libscg anymore? From having actually gone through > > your code, Joerg, I can tell you that it does serve a larger purpose. But at > > this point I have to ask - besides cdrecord and a few other _COMPACT_ _DISC_ > > writing programs, does _ANYONE_ use libscg? Is it ever used to access any > > other devices that are either SCSI or use a SCSI command protocol (like > > ATAPI)? My point there is that you have a wonderful library, but despite > > your wishes, there is no proof that it is ever used for anything except > > writing/ripping CD's. > > Name a single program (not using libscg) that implements user space SCSI and runs > on as many platforms as cdrecord/libscg does. As an application developer, I would focus on the following questions: * what is the percentage of Windows users using a CD burning/ripping program based on libscg? * what is the percentage of cdrecord Linux users out of the total number of cdrecord users? * what are your expectations with regard to those numbers in the future? Jerome ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:35 ` Joerg Schilling 2006-02-09 12:57 ` D. Hazelton @ 2006-02-10 12:41 ` Martin Mares 2006-02-10 12:59 ` Joerg Schilling 2006-02-10 22:40 ` Matthias Andree 2 siblings, 1 reply; 439+ messages in thread From: Martin Mares @ 2006-02-10 12:41 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, peter.read, linux-kernel, jim, jengelh Hello! > Well, this is a deficit of the Linux kernel - not libscg. This is exactly what I have written -- extra effort is needed to get a stable numbering (which Solaris does), but you can use a very similar extra care to get stable names (which Linux with udev does). So I really se no advantage in preferring the numeric addresses over device names, while device names have the obvious advantage of working for all devices, not only SCSI. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Light-year? One-third less calories than a regular year. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:41 ` Martin Mares @ 2006-02-10 12:59 ` Joerg Schilling 2006-02-10 13:10 ` Jan Engelhardt 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 12:59 UTC (permalink / raw) To: schilling, mj; +Cc: peter.read, matthias.andree, linux-kernel, jim, jengelh Martin Mares <mj@ucw.cz> wrote: > Hello! > > > Well, this is a deficit of the Linux kernel - not libscg. > > This is exactly what I have written -- extra effort is needed to get > a stable numbering (which Solaris does), but you can use a very similar > extra care to get stable names (which Linux with udev does). As this conceptional deficite in Linux causes Linux to break POSIX compliance e.g. for stat(2) with hot plugged devices, people with sufficient background knowledge should know that Linux tried to fix a low level bug at a high level ignoring that the mid-level is still broken. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:59 ` Joerg Schilling @ 2006-02-10 13:10 ` Jan Engelhardt 2006-02-10 13:22 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Jan Engelhardt @ 2006-02-10 13:10 UTC (permalink / raw) To: Joerg Schilling; +Cc: mj, peter.read, matthias.andree, linux-kernel, jim >> > 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 13:10 ` Jan Engelhardt @ 2006-02-10 13:22 ` Joerg Schilling 2006-02-10 14:16 ` Theodore Ts'o 2006-02-13 10:14 ` Joerg Schilling 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 13:22 UTC (permalink / raw) To: schilling, jengelh; +Cc: peter.read, mj, matthias.andree, linux-kernel, jim Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >> > Well, this is a deficit of the Linux kernel - not libscg. > >> > >> This is exactly what I have written -- extra effort is needed to get > >> a stable numbering (which Solaris does), but you can use a very similar > >> extra care to get stable names (which Linux with udev does). > > > >As this conceptional deficite in Linux causes Linux to break POSIX > >compliance e.g. for stat(2) with hot plugged devices, people with > > The struct stat->st_rdev field need to be stable too to comply to POSIX? Correct. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 13:22 ` Joerg Schilling @ 2006-02-10 14:16 ` Theodore Ts'o 2006-02-10 14:32 ` Joerg Schilling 2006-02-13 10:14 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Theodore Ts'o @ 2006-02-10 14:16 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, peter.read, mj, matthias.andree, linux-kernel, jim 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:16 ` Theodore Ts'o @ 2006-02-10 14:32 ` Joerg Schilling 2006-02-10 14:45 ` Christopher Friesen ` (3 more replies) 0 siblings, 4 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 14:32 UTC (permalink / raw) To: tytso, schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh "Theodore Ts'o" <tytso@mit.edu> wrote: > On Fri, Feb 10, 2006 at 02:22:42PM +0100, Joerg Schilling wrote: > > > > > > The struct stat->st_rdev field need to be stable too to comply to POSIX? > > > > Correct. > > > > Chapter and verse, please? > > Can you please list the POSIX standard, section, and line number which > states that a particular device must always have the same st_rdev > across reboots, and hot plugs/unplugs? A particular file on the system must not change st_dev while the system is running. http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:32 ` Joerg Schilling @ 2006-02-10 14:45 ` Christopher Friesen 2006-02-10 14:52 ` Joerg Schilling 2006-02-10 14:52 ` Theodore Ts'o ` (2 subsequent siblings) 3 siblings, 1 reply; 439+ messages in thread From: Christopher Friesen @ 2006-02-10 14:45 UTC (permalink / raw) To: Joerg Schilling Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh Joerg Schilling wrote: > "Theodore Ts'o" <tytso@mit.edu> wrote: >>Can you please list the POSIX standard, section, and line number which >>states that a particular device must always have the same st_rdev >>across reboots, and hot plugs/unplugs? > > > A particular file on the system must not change st_dev while the system > is running. > > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html I don't actually see that requirement listed there. It says that st_dev must be unique, and that all files are uniquely identified by st_ino and st_dev. There's nothing there that says the mapping cannot change with time...just that it has to be unique. Chris ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:45 ` Christopher Friesen @ 2006-02-10 14:52 ` Joerg Schilling 2006-02-10 15:13 ` Christopher Friesen 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 14:52 UTC (permalink / raw) To: schilling, cfriesen Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh "Christopher Friesen" <cfriesen@nortel.com> wrote: > > A particular file on the system must not change st_dev while the system > > is running. > > > > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html > > > I don't actually see that requirement listed there. It says that st_dev > must be unique, and that all files are uniquely identified by st_ino and > st_dev. > > There's nothing there that says the mapping cannot change with > time...just that it has to be unique. If it changes over the runtime of a program, it is not unique from the view of that program. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:52 ` Joerg Schilling @ 2006-02-10 15:13 ` Christopher Friesen 2006-02-10 15:32 ` Chris Shoemaker 2006-02-13 10:30 ` Joerg Schilling 0 siblings, 2 replies; 439+ messages in thread From: Christopher Friesen @ 2006-02-10 15:13 UTC (permalink / raw) To: Joerg Schilling Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh Joerg Schilling wrote: > "Christopher Friesen" <cfriesen@nortel.com> wrote: >>There's nothing there that says the mapping cannot change with >>time...just that it has to be unique. > > > If it changes over the runtime of a program, it is not unique from the > view of that program. That depends on what "uniquely identified" actually means. One possible definition is that at any time, a particular path maps to a single unique st_ino/st_dev tuple. The other possibility (and this is what you seem to be advocating) is that a st_ino/st_dev tuple always maps to the same file over the entire runtime of the system. This second possibility seems easily disproved. If you delete and recreate files on a filesystem (assuming nobody has open files in the filesystem), at some point a new file will end up with the same inode as an old (deleted) file. The two files are different, but have the same st_ino/st_dev tuple. This leaves the first possibility as the only choice... Chris ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 15:13 ` Christopher Friesen @ 2006-02-10 15:32 ` Chris Shoemaker 2006-02-10 15:53 ` Christopher Friesen 2006-02-13 10:33 ` Joerg Schilling 2006-02-13 10:30 ` Joerg Schilling 1 sibling, 2 replies; 439+ messages in thread From: Chris Shoemaker @ 2006-02-10 15:32 UTC (permalink / raw) To: Christopher Friesen Cc: Joerg Schilling, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Fri, Feb 10, 2006 at 09:13:44AM -0600, Christopher Friesen wrote: > Joerg Schilling wrote: > >"Christopher Friesen" <cfriesen@nortel.com> wrote: > > >>There's nothing there that says the mapping cannot change with > >>time...just that it has to be unique. > > > > > >If it changes over the runtime of a program, it is not unique from the > >view of that program. > > That depends on what "uniquely identified" actually means. "The st_ino and st_dev fields taken together uniquely identify the file within the system." > One possible definition is that at any time, a particular path maps to a > single unique st_ino/st_dev tuple. The quoted sentence certainly implies _at_least_ that much. > The other possibility (and this is what you seem to be advocating) is > that a st_ino/st_dev tuple always maps to the same file over the entire > runtime of the system. However, I don't think this is a reasonable interpretation, and it's clearly _not_ the one that Joerg is implying. Joerg is claiming that the quoted sentence also implies that _different_ st_ino/st_dev pairs will _always_ identify different files. Taken in just the immediate context of stat.h, this is a very reasonable interpretation. > This second possibility seems easily disproved. If you delete and > recreate files on a filesystem (assuming nobody has open files in the > filesystem), at some point a new file will end up with the same inode as > an old (deleted) file. The two files are different, but have the same > st_ino/st_dev tuple. > > This leaves the first possibility as the only choice... If you want to show that his interpretation is incorrent (which it may be for all I know), you need a better argument than this. -chris > > Chris ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 15:32 ` Chris Shoemaker @ 2006-02-10 15:53 ` Christopher Friesen 2006-02-10 18:48 ` Chris Shoemaker 2006-02-13 10:33 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Christopher Friesen @ 2006-02-10 15:53 UTC (permalink / raw) To: Chris Shoemaker Cc: Joerg Schilling, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 15:53 ` Christopher Friesen @ 2006-02-10 18:48 ` Chris Shoemaker 0 siblings, 0 replies; 439+ messages in thread From: Chris Shoemaker @ 2006-02-10 18:48 UTC (permalink / raw) To: Christopher Friesen Cc: Joerg Schilling, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 15:32 ` Chris Shoemaker 2006-02-10 15:53 ` Christopher Friesen @ 2006-02-13 10:33 ` Joerg Schilling 1 sibling, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 10:33 UTC (permalink / raw) To: cfriesen, c.shoemaker Cc: tytso, schilling, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh Chris Shoemaker <c.shoemaker@cox.net> wrote: > However, I don't think this is a reasonable interpretation, and it's > clearly _not_ the one that Joerg is implying. > > Joerg is claiming that the quoted sentence also implies that > _different_ st_ino/st_dev pairs will _always_ identify different > files. Taken in just the immediate context of stat.h, this is a > very reasonable interpretation. Correct, as a st_ino/st_dev pair uniquely identifies a file, the reverse needs to be true in addition. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 15:13 ` Christopher Friesen 2006-02-10 15:32 ` Chris Shoemaker @ 2006-02-13 10:30 ` Joerg Schilling 2006-02-13 10:55 ` Martin Mares ` (3 more replies) 1 sibling, 4 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 10:30 UTC (permalink / raw) To: schilling, cfriesen Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh "Christopher Friesen" <cfriesen@nortel.com> wrote: > Joerg Schilling wrote: > > "Christopher Friesen" <cfriesen@nortel.com> wrote: > > >>There's nothing there that says the mapping cannot change with > >>time...just that it has to be unique. > > > > > > If it changes over the runtime of a program, it is not unique from the > > view of that program. > > That depends on what "uniquely identified" actually means. > > One possible definition is that at any time, a particular path maps to a > single unique st_ino/st_dev tuple. > > The other possibility (and this is what you seem to be advocating) is > that a st_ino/st_dev tuple always maps to the same file over the entire > runtime of the system. Well it is obvious that this is a requirement. If Linux does device name mapping at high level but leaves the low level part unstable, then the following coul happen: Just think about a program that checks a file that is on a removable media. This media is mounted via a vold service and someone removes the USB cable and reinserts it a second later. The filesystem on the device will be mounted on the same mount point but the device ID inside the system did change. As a result, the file unique identification st_ino/st_dev is not retained and the program is confused. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:30 ` Joerg Schilling @ 2006-02-13 10:55 ` Martin Mares 2006-02-13 12:01 ` Matthias Andree ` (2 subsequent siblings) 3 siblings, 0 replies; 439+ messages in thread From: Martin Mares @ 2006-02-13 10:55 UTC (permalink / raw) To: Joerg Schilling Cc: cfriesen, tytso, peter.read, matthias.andree, linux-kernel, jim, jengelh Hello! > Just think about a program that checks a file that is on a removable media. > > This media is mounted via a vold service and someone removes the USB cable > and reinserts it a second later. The filesystem on the device will be mounted > on the same mount point but the device ID inside the system did change. > > As a result, the file unique identification st_ino/st_dev is not retained > and the program is confused. And it would be equally confused if I inserted a different media instead. Relying on stability of anything across mounts/umounts does not make any sense. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth The number of UNIX installations has grown to 10, with more expected. (6/72) ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:30 ` Joerg Schilling 2006-02-13 10:55 ` Martin Mares @ 2006-02-13 12:01 ` Matthias Andree 2006-02-14 5:22 ` Marcin Dalecki 2006-02-13 12:14 ` vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)] Xavier Bestel 2006-02-13 23:35 ` CD writing in future Linux (stirring up a hornets' nest) D. Hazelton 3 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-13 12:01 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 12:01 ` Matthias Andree @ 2006-02-14 5:22 ` Marcin Dalecki 0 siblings, 0 replies; 439+ messages in thread From: Marcin Dalecki @ 2006-02-14 5:22 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, Linux-Kernel mailing list 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)] 2006-02-13 10:30 ` Joerg Schilling 2006-02-13 10:55 ` Martin Mares 2006-02-13 12:01 ` Matthias Andree @ 2006-02-13 12:14 ` Xavier Bestel 2006-02-13 12:19 ` forget this maim (vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)]) Xavier Bestel 2006-02-13 23:35 ` CD writing in future Linux (stirring up a hornets' nest) D. Hazelton 3 siblings, 1 reply; 439+ messages in thread From: Xavier Bestel @ 2006-02-13 12:14 UTC (permalink / raw) To: Joerg Schilling Cc: cfriesen, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* forget this maim (vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)]) 2006-02-13 12:14 ` vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)] Xavier Bestel @ 2006-02-13 12:19 ` Xavier Bestel 2006-02-13 16:27 ` Jan Engelhardt 0 siblings, 1 reply; 439+ messages in thread From: Xavier Bestel @ 2006-02-13 12:19 UTC (permalink / raw) To: Joerg Schilling Cc: cfriesen, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Mon, 2006-02-13 at 13:14, Xavier Bestel wrote: > BTW, is there a vold-like implementation for linux somewhere ? Yes, there is. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: forget this maim (vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)]) 2006-02-13 12:19 ` forget this maim (vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)]) Xavier Bestel @ 2006-02-13 16:27 ` Jan Engelhardt 0 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-13 16:27 UTC (permalink / raw) To: Xavier Bestel Cc: Joerg Schilling, cfriesen, tytso, peter.read, mj, matthias.andree, linux-kernel, jim >> 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:30 ` Joerg Schilling ` (2 preceding siblings ...) 2006-02-13 12:14 ` vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)] Xavier Bestel @ 2006-02-13 23:35 ` D. Hazelton 3 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-13 23:35 UTC (permalink / raw) To: Joerg Schilling Cc: cfriesen, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Monday 13 February 2006 05:30, Joerg Schilling wrote: > "Christopher Friesen" <cfriesen@nortel.com> wrote: > > Joerg Schilling wrote: > > > "Christopher Friesen" <cfriesen@nortel.com> wrote: > > >>There's nothing there that says the mapping cannot change with > > >>time...just that it has to be unique. > > > > > > If it changes over the runtime of a program, it is not unique from the > > > view of that program. > > > > That depends on what "uniquely identified" actually means. > > > > One possible definition is that at any time, a particular path maps to a > > single unique st_ino/st_dev tuple. > > > > The other possibility (and this is what you seem to be advocating) is > > that a st_ino/st_dev tuple always maps to the same file over the entire > > runtime of the system. > > Well it is obvious that this is a requirement. > > If Linux does device name mapping at high level but leaves the low level > part unstable, then the following coul happen: > > Just think about a program that checks a file that is on a removable media. > > This media is mounted via a vold service and someone removes the USB cable > and reinserts it a second later. The filesystem on the device will be > mounted on the same mount point but the device ID inside the system did > change. Joerg, I think you've got your OS's mixed up here. AFAIK, Linux does not have a "vold" system. > As a result, the file unique identification st_ino/st_dev is not retained > and the program is confused. I have to agree that you are correct, but then, most removable media in the Linux world do not actually have physical inodes. AFAIK, DVD's use the UDF filesystem, a lot of CDRW's are formatted the same, CD's/CDR's generally use the ISO9660 filesystem and other removable media, such as any floppy disc and the now ubiquitous "zip disk's" use FAT16. I'm not current on UDF, but from prior experience, I'd be willing to bet it doesn't have indoes, and the ISO9660 filesystem doesn't have them, even if you use the RR extensions. What is referred to in the Linux kernel as inodes for those systems are generally block indexes, and for the FAT filesystem what it calls an "inode" is just the name and a few other bits - and in the case of an LFN being used on said volume, the name is spread across several "special blocks"... invalidating the concept of an INODE for said filesystems. In any case, the hypothetical case you present here seems more in tune with Solaris as you present it, since with UDEV the device node created for said removable media would stay the same, and hence st_dev would also (IIRC) remain the same. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:32 ` Joerg Schilling 2006-02-10 14:45 ` Christopher Friesen @ 2006-02-10 14:52 ` Theodore Ts'o 2006-02-10 14:54 ` Joerg Schilling 2006-02-10 17:03 ` Nikita Danilov 2006-02-12 10:01 ` Jan Engelhardt 3 siblings, 1 reply; 439+ messages in thread From: Theodore Ts'o @ 2006-02-10 14:52 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:52 ` Theodore Ts'o @ 2006-02-10 14:54 ` Joerg Schilling 2006-02-10 15:42 ` Erik Mouw ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 14:54 UTC (permalink / raw) To: tytso, schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh "Theodore Ts'o" <tytso@mit.edu> wrote: > On Fri, Feb 10, 2006 at 03:32:28PM +0100, Joerg Schilling wrote: > > > Chapter and verse, please? > > > > > > Can you please list the POSIX standard, section, and line number which > > > states that a particular device must always have the same st_rdev > > > across reboots, and hot plugs/unplugs? > > > > A particular file on the system must not change st_dev while the system > > is running. > > > > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html > > 1) File != device. I am sorry, but it turns out that you did not understand the problem. Try to inform yourself about the relevence (and content) of st_dev before replying again. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:54 ` Joerg Schilling @ 2006-02-10 15:42 ` Erik Mouw 2006-02-10 23:28 ` Marc Koschewski 2006-02-10 15:57 ` Theodore Ts'o 2006-02-10 16:24 ` Diego Calleja 2 siblings, 1 reply; 439+ messages in thread From: Erik Mouw @ 2006-02-10 15:42 UTC (permalink / raw) To: Joerg Schilling Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh On Fri, Feb 10, 2006 at 03:54:44PM +0100, Joerg Schilling wrote: > "Theodore Ts'o" <tytso@mit.edu> wrote: > > On Fri, Feb 10, 2006 at 03:32:28PM +0100, Joerg Schilling wrote: > > > A particular file on the system must not change st_dev while the system > > > is running. > > > > > > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html > > > > 1) File != device. > > I am sorry, but it turns out that you did not understand the problem. Why do you start an ad hominem attack every time somebody shows you're wrong for technical reasons? > Try to inform yourself about the relevence (and content) of st_dev before > replying again. It has no relevance. st_dev holds the device number of the device containing the file. That means that if /dev/hda (3,01) is on /dev, it contains the device number of filesystem of /dev, 0x0b in my case (udev using tmpfs): root@arthur:/home # stat /dev/hda File: `/dev/hda' Size: 0 Blocks: 0 IO Block: 4096 block special file Device: bh/11d Inode: 548 Links: 1 Device type: 3,0 [...] If I create that same special file "hda" in /home, I get: root@arthur:/home # mknod hda b 3 0 root@arthur:/home # stat hda File: `hda' Size: 0 Blocks: 0 IO Block: 4096 block special file Device: 308h/776d Inode: 3026 Links: 1 Device type: 3,0 [...] It's the same device because st_rdev is the same in both cases, it just lives on a different filesystem. You can use either device to operate on. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 15:42 ` Erik Mouw @ 2006-02-10 23:28 ` Marc Koschewski 0 siblings, 0 replies; 439+ messages in thread From: Marc Koschewski @ 2006-02-10 23:28 UTC (permalink / raw) To: Erik Mouw Cc: Joerg Schilling, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh * Erik Mouw <erik@harddisk-recovery.com> [2006-02-10 16:42:56 +0100]: > On Fri, Feb 10, 2006 at 03:54:44PM +0100, Joerg Schilling wrote: > > "Theodore Ts'o" <tytso@mit.edu> wrote: > > > On Fri, Feb 10, 2006 at 03:32:28PM +0100, Joerg Schilling wrote: > > > > A particular file on the system must not change st_dev while the system > > > > is running. > > > > > > > > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html > > > > > > 1) File != device. > > > > I am sorry, but it turns out that you did not understand the problem. > > Why do you start an ad hominem attack every time somebody shows you're > wrong for technical reasons? Duuude ... could you all calm down and get the facts together? What if you'd all be in the same room with a knife by the hand every one of you?! I suggest Joerg summarizes the facts from his point of view _in detail_ and people are going to respond to it. I think it pretty useless to get people respond to you, Joerg, where you just drop a two-liner where one line is that someone is stupid or not as good at something and the other line is a quick statement that just always leaves place for people to ask more questions and proceed arguing. Please clarify. Summarize. This whole thing turns into some totally useles infitine state machine... Thanks anyone for your eyes. :) Marc ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:54 ` Joerg Schilling 2006-02-10 15:42 ` Erik Mouw @ 2006-02-10 15:57 ` Theodore Ts'o 2006-02-13 10:45 ` Joerg Schilling 2006-02-10 16:24 ` Diego Calleja 2 siblings, 1 reply; 439+ messages in thread From: Theodore Ts'o @ 2006-02-10 15:57 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 15:57 ` Theodore Ts'o @ 2006-02-13 10:45 ` Joerg Schilling 2006-02-13 12:15 ` Theodore Ts'o 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 10:45 UTC (permalink / raw) To: tytso, schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh "Theodore Ts'o" <tytso@mit.edu> wrote: > On Fri, Feb 10, 2006 at 03:54:44PM +0100, Joerg Schilling wrote: > > > > > > 1) File != device. > > > > I am sorry, but it turns out that you did not understand the problem. > > > > Try to inform yourself about the relevence (and content) of st_dev before > > replying again. > > st_dev is irrelevant in the context of CD burning. If you did try to understand the reason why I did introduce the POSIX claim, you would know that if Linux did try to follow the POSIX rule, a side effect would be that removable devices need to have a stable mapping in the kernel > In the context of mounted files, the only guarantee given by POSIX is > that st_dev and st_ino for a particular file is unique. But that > clearly is true while the containing filesystem is mounted. Even with > Solaris, if a particular removable filesystem is unmounted and removed > from one device (say one Jazz/Zip drive) and inserted into another > device (say another Jazz/Zip drive), st_dev will change --- while the > system is running. Please don't confuse the fact that you will _always_ be able to find ways to confuse a system with the fact that this needs to happen in all cases. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:45 ` Joerg Schilling @ 2006-02-13 12:15 ` Theodore Ts'o 2006-02-13 15:07 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Theodore Ts'o @ 2006-02-13 12:15 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 12:15 ` Theodore Ts'o @ 2006-02-13 15:07 ` Joerg Schilling 2006-02-13 15:26 ` Matthias Andree 2006-02-13 16:35 ` Jan Engelhardt 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 15:07 UTC (permalink / raw) To: tytso, schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh "Theodore Ts'o" <tytso@mit.edu> wrote: > On Mon, Feb 13, 2006 at 11:45:32AM +0100, Joerg Schilling wrote: > > If you did try to understand the reason why I did introduce the POSIX > > claim, you would know that if Linux did try to follow the POSIX rule, > > a side effect would be that removable devices need to have a stable > > mapping in the kernel > > It is _not_ a POSIX rule, as I and others have shown. You claimed it > was required by POSIX, but you are quite clearly incorrect. It has > never worked that way with Unix systems, and POSIX was always designed > to codify existing practice. On Unix systems fixed disks would and > did have their devices numbering schemes move around under a number of > conditions. If you believe this, pleace give evidence. I was quoting POSIX documents which prove my claims...... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:07 ` Joerg Schilling @ 2006-02-13 15:26 ` Matthias Andree 2006-02-13 16:35 ` Jan Engelhardt 1 sibling, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-13 15:26 UTC (permalink / raw) To: Joerg Schilling; +Cc: tytso, Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-13: > "Theodore Ts'o" <tytso@mit.edu> wrote: > > > On Mon, Feb 13, 2006 at 11:45:32AM +0100, Joerg Schilling wrote: > > > If you did try to understand the reason why I did introduce the POSIX > > > claim, you would know that if Linux did try to follow the POSIX rule, > > > a side effect would be that removable devices need to have a stable > > > mapping in the kernel > > > > It is _not_ a POSIX rule, as I and others have shown. You claimed it > > was required by POSIX, but you are quite clearly incorrect. It has > > never worked that way with Unix systems, and POSIX was always designed > > to codify existing practice. On Unix systems fixed disks would and > > did have their devices numbering schemes move around under a number of > > conditions. > > If you believe this, pleace give evidence. > > I was quoting POSIX documents which prove my claims...... The source you quoted neither contained the quoted material nor did it support your view in any other way. This was shown by several people, you have been Cc:d. You are beyond help. EOD. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:07 ` Joerg Schilling 2006-02-13 15:26 ` Matthias Andree @ 2006-02-13 16:35 ` Jan Engelhardt 1 sibling, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-13 16:35 UTC (permalink / raw) To: Joerg Schilling; +Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim >> 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:54 ` Joerg Schilling 2006-02-10 15:42 ` Erik Mouw 2006-02-10 15:57 ` Theodore Ts'o @ 2006-02-10 16:24 ` Diego Calleja 2006-02-13 10:47 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: Diego Calleja @ 2006-02-10 16:24 UTC (permalink / raw) To: Joerg Schilling Cc: tytso, schilling, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh El Fri, 10 Feb 2006 15:54:44 +0100, Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > I am sorry, but it turns out that you did not understand the problem. Could you explain why stat->st_dev / stat->st_ino POSIX semantics forces POSIX implementations to have a stable stat->st_rdev number? ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 16:24 ` Diego Calleja @ 2006-02-13 10:47 ` Joerg Schilling 2006-02-13 15:36 ` Florin Malita 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 10:47 UTC (permalink / raw) To: schilling, diegocg Cc: tytso, schilling, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh Diego Calleja <diegocg@gmail.com> wrote: > El Fri, 10 Feb 2006 15:54:44 +0100, > Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > > > I am sorry, but it turns out that you did not understand the problem. > > > Could you explain why stat->st_dev / stat->st_ino POSIX semantics forces > POSIX implementations to have a stable stat->st_rdev number? I was never talking about stat->st_rdev see: http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:47 ` Joerg Schilling @ 2006-02-13 15:36 ` Florin Malita 2006-02-13 15:56 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Florin Malita @ 2006-02-13 15:36 UTC (permalink / raw) To: Joerg Schilling Cc: diegocg, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh Joerg Schilling wrote: >>Could you explain why stat->st_dev / stat->st_ino POSIX semantics forces >>POSIX implementations to have a stable stat->st_rdev number? >> >> > >I was never talking about stat->st_rdev > > This is blatantly incorrect. You *were* talking about stat->st_rdev: http://lkml.org/lkml/2006/2/10/143 On 2/10/06, *Joerg Schilling* <schilling@fokus.fraunhofer.de> wrote: Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > The struct stat->st_rdev field need to be stable too to comply to POSIX? Correct. Jörg You may claim you *never meant to* or you *never realized* you were talking about, but you can't say you never talked about it - that's an outright lie. -- fm ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:36 ` Florin Malita @ 2006-02-13 15:56 ` Joerg Schilling 2006-02-13 16:28 ` Diego Calleja ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 15:56 UTC (permalink / raw) To: schilling, fmalita Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, diegocg Florin Malita <fmalita@gmail.com> wrote: > Joerg Schilling wrote: > > >>Could you explain why stat->st_dev / stat->st_ino POSIX semantics forces > >>POSIX implementations to have a stable stat->st_rdev number? > >> > >> > > > >I was never talking about stat->st_rdev > > > > > This is blatantly incorrect. You *were* talking about stat->st_rdev: > http://lkml.org/lkml/2006/2/10/143 > > On 2/10/06, *Joerg Schilling* <schilling@fokus.fraunhofer.de> wrote: > > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > The struct stat->st_rdev field need to be stable too to comply to > POSIX? > > Correct. > > Jörg > > > You may claim you *never meant to* or you *never realized* you were > talking about, but you can't say you never talked about it - that's an > outright lie. You are lying here. I did not write st_rdev and from my previous mail it was obvioys that I was referring to st_dev. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:56 ` Joerg Schilling @ 2006-02-13 16:28 ` Diego Calleja 2006-02-13 16:38 ` Jan Engelhardt 2006-02-13 16:40 ` Florin Malita 2 siblings, 0 replies; 439+ messages in thread From: Diego Calleja @ 2006-02-13 16:28 UTC (permalink / raw) To: Joerg Schilling Cc: schilling, fmalita, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh El Mon, 13 Feb 2006 16:56:18 +0100, Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > I did not write st_rdev and from my previous mail it was obvioys that > I was referring to st_dev. Well, and everbody else was referring to st_rdev, including the email you answered.... ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:56 ` Joerg Schilling 2006-02-13 16:28 ` Diego Calleja @ 2006-02-13 16:38 ` Jan Engelhardt 2006-02-13 16:40 ` Florin Malita 2 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-13 16:38 UTC (permalink / raw) To: Joerg Schilling Cc: fmalita, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, diegocg [-- Attachment #1: Type: TEXT/PLAIN, Size: 794 bytes --] >> This is blatantly incorrect. You *were* talking about stat->st_rdev: >> http://lkml.org/lkml/2006/2/10/143 >> >> On 2/10/06, *Joerg Schilling* <schilling@fokus.fraunhofer.de> wrote: >> >> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: >> > The struct stat->st_rdev field need to be stable too to comply to >> > POSIX? >> >> Correct. >> >> Jörg >> >> >> You may claim you *never meant to* or you *never realized* you were >> talking about, but you can't say you never talked about it - that's an >> outright lie. > >You are lying here. > >I did not write st_rdev and from my previous mail it was obvioys that >I was referring to st_dev. > Exactly. But I asked specifically about Rdev... see "stable too" (=German: "Muss st_rdev auch stabil sein?") Jan Engelhardt -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:56 ` Joerg Schilling 2006-02-13 16:28 ` Diego Calleja 2006-02-13 16:38 ` Jan Engelhardt @ 2006-02-13 16:40 ` Florin Malita 2006-02-13 16:43 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: Florin Malita @ 2006-02-13 16:40 UTC (permalink / raw) To: Joerg Schilling Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, diegocg Joerg Schilling wrote: >Florin Malita <fmalita@gmail.com> wrote: > >>On 2/10/06, *Joerg Schilling* <schilling@fokus.fraunhofer.de> wrote: >> >> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: >> > The struct stat->st_rdev field need to be stable too to comply to >> POSIX? >> >> Correct. >> >> Jörg >> >> >>You may claim you *never meant to* or you *never realized* you were >>talking about, but you can't say you never talked about it - that's an >>outright lie. >> >> >I did not write st_rdev and from my previous mail it was obvioys that >I was referring to st_dev. > > I never said you *wrote* st_rdev, did I? You confirmed a statement about st_rdev - that's called "talking about it". The fact that you didn't intend to or how obvious that is is irrelevant in this context: you *did talk* about st_rdev and there's no way you can deny or erase that. But here comes the classic twist: instead of acknowledging your mistake, you place the blame on everybody else for not guessing you were talking about something else. This is not a rational behavior, please stop. -- fm ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:40 ` Florin Malita @ 2006-02-13 16:43 ` Joerg Schilling 2006-02-13 17:16 ` Luke-Jr 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 16:43 UTC (permalink / raw) To: schilling, fmalita Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, diegocg It seems that this "discussion" is missong new ideas and I believe it's best to stop any conversation that does not introduce new ideas. I mentioned the two most important Linux Bugs to fix. Let us continue after there is at least a hint that leads to a possible fix for these bugs. It makes no sense to waste my time while it is obvious that the Linux kernel folks are completely missing any will to fix their bugs. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:43 ` Joerg Schilling @ 2006-02-13 17:16 ` Luke-Jr 0 siblings, 0 replies; 439+ messages in thread From: Luke-Jr @ 2006-02-13 17:16 UTC (permalink / raw) To: Joerg Schilling Cc: fmalita, tytso, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, diegocg 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:32 ` Joerg Schilling 2006-02-10 14:45 ` Christopher Friesen 2006-02-10 14:52 ` Theodore Ts'o @ 2006-02-10 17:03 ` Nikita Danilov 2006-02-12 10:01 ` Jan Engelhardt 3 siblings, 0 replies; 439+ messages in thread From: Nikita Danilov @ 2006-02-10 17:03 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh Joerg Schilling writes: > "Theodore Ts'o" <tytso@mit.edu> wrote: > > > On Fri, Feb 10, 2006 at 02:22:42PM +0100, Joerg Schilling wrote: > > > > > > > > The struct stat->st_rdev field need to be stable too to comply to POSIX? > > > > > > Correct. > > > > > > > Chapter and verse, please? > > > > Can you please list the POSIX standard, section, and line number which > > states that a particular device must always have the same st_rdev > > across reboots, and hot plugs/unplugs? > > A particular file on the system must not change st_dev while the system > is running. Where is that from? > > http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html This text doesn't seem to support your claim. > > JЖrg Nikita. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 14:32 ` Joerg Schilling ` (2 preceding siblings ...) 2006-02-10 17:03 ` Nikita Danilov @ 2006-02-12 10:01 ` Jan Engelhardt 2006-02-13 14:07 ` Joerg Schilling 3 siblings, 1 reply; 439+ messages in thread From: Jan Engelhardt @ 2006-02-12 10:01 UTC (permalink / raw) To: Joerg Schilling; +Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim >> > > 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-12 10:01 ` Jan Engelhardt @ 2006-02-13 14:07 ` Joerg Schilling 2006-02-13 14:24 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 14:07 UTC (permalink / raw) To: schilling, jengelh Cc: tytso, peter.read, mj, matthias.andree, linux-kernel, jim Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >> > > The struct stat->st_rdev field need to be stable too to comply to POSIX? > >> > Correct. > >A particular file on the system must not change st_dev while the system > >is running. > > > > Attention, I asked for st_rdev (=major/minor as presented in ls -l), > not st_dev (major/minor of the disk /dev is on). I was of course talking about st_dev But as a note: st_rdev from the device carrying the FS becomes st_dev for all files inside a particular FS. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:07 ` Joerg Schilling @ 2006-02-13 14:24 ` Matthias Andree 2006-02-13 16:25 ` Jan Engelhardt 0 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-13 14:24 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:24 ` Matthias Andree @ 2006-02-13 16:25 ` Jan Engelhardt 0 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-13 16:25 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, Linux-Kernel mailing list >> 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 13:22 ` Joerg Schilling 2006-02-10 14:16 ` Theodore Ts'o @ 2006-02-13 10:14 ` Joerg Schilling 2006-02-13 10:54 ` Matthias Andree 1 sibling, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 10:14 UTC (permalink / raw) To: schilling, jengelh; +Cc: peter.read, mj, matthias.andree, linux-kernel, jim Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > >> > Well, this is a deficit of the Linux kernel - not libscg. > > >> > > >> This is exactly what I have written -- extra effort is needed to get > > >> a stable numbering (which Solaris does), but you can use a very similar > > >> extra care to get stable names (which Linux with udev does). > > > > > >As this conceptional deficite in Linux causes Linux to break POSIX > > >compliance e.g. for stat(2) with hot plugged devices, people with > > > > The struct stat->st_rdev field need to be stable too to comply to POSIX? > > Correct. Mmmm, it looks like I did oversee that you did change the subject..... I did say that stat->st_dev needs to be stable Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:14 ` Joerg Schilling @ 2006-02-13 10:54 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-13 10:54 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:35 ` Joerg Schilling 2006-02-09 12:57 ` D. Hazelton 2006-02-10 12:41 ` Martin Mares @ 2006-02-10 22:40 ` Matthias Andree 2 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-10 22:40 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, peter.read, mj, linux-kernel, jim, jengelh Joerg Schilling schrieb am 2006-02-10: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports > > > > > > Dou you like to verify that you have no clue on SCSI? > > > > How does, for instance, libscg make sure that the b,t,l mappings are > > hotplug invariant? > > > > How does libscg make sure that two external writers, say USB, retain > > their b,t,l mappings if both are unplugged and then replugged in reverse > > order, perhaps into different USB hubs? > > Well, this is a deficit of the Linux kernel - not libscg. I wrote this before, but to fresh up your memory, here again, different wording: Unless Solaris's behavior is mandated by a commonly accepted standard, comparable in relevance to IEEE or IETF standards, it is not relevant for Linux. It is YOU who has to make that decision: support your cdrtools users who chose Linux (which means: accepting its decisions and adjusting YOUR code to work properly, and either file detailed, traceable and comprehensible bug reports, or work around the bugs), or leave the Linux users standing in the rain. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 10:59 ` Joerg Schilling 2006-02-10 11:47 ` Matthias Andree @ 2006-02-10 11:49 ` DervishD 2006-02-10 11:55 ` Matthias Andree ` (2 more replies) 1 sibling, 3 replies; 439+ messages in thread From: DervishD @ 2006-02-10 11:49 UTC (permalink / raw) To: Joerg Schilling Cc: mj, peter.read, matthias.andree, linux-kernel, jim, jengelh Hi Joerg :) * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > Martin Mares <mj@ucw.cz> wrote: > > > This is why the mapping engine is in the Linux adoption part of > > > libscg. It maps the non-stable device <-> /dev/sg* relation to a > > > stable b,t,l address. > > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports > > Dou you like to verify that you have no clue on SCSI? My system is clueless, too! If I write a CD before plugging my USB storage device, my CD writer is on 0,0,0. If I plug my USB storage device *before* doing any access, my cdwriter is on 1,0,0. Pretty stable. But of course, I could made all of the above stable by using udev. But then the /dev/sg mapping will be stable, too. I can't see why the three random numbers are more stable than /dev/sg. By the way, I don't have any SCSI host adapter in my system. And please, Joerg, be more respectful when answering. It doesn't cost money and people will likely respect you, too. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 11:49 ` DervishD @ 2006-02-10 11:55 ` Matthias Andree 2006-02-10 12:15 ` DervishD 2006-02-10 12:36 ` Joerg Schilling 2006-02-13 0:50 ` Alexander Samad 2 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-10 11:55 UTC (permalink / raw) To: Joerg Schilling, mj, linux-kernel, jim, jengelh DervishD schrieb am 2006-02-10: > Hi Joerg :) > > * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > > Martin Mares <mj@ucw.cz> wrote: > > > > This is why the mapping engine is in the Linux adoption part of > > > > libscg. It maps the non-stable device <-> /dev/sg* relation to a > > > > stable b,t,l address. > > > > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports > > > > Dou you like to verify that you have no clue on SCSI? > > My system is clueless, too! If I write a CD before plugging my > USB storage device, my CD writer is on 0,0,0. If I plug my USB > storage device *before* doing any access, my cdwriter is on 1,0,0. > Pretty stable. Thanks for answering the question I directed towards Jörg, which proves Martin Mares's point that b,t,l is not stable. I think, Martin, too deserves Jörg's apology, and Jörg shouldn't only be more respectful, but listen to those who know their system better than he does. (Of course this'll turn into a flame feast how stupid Linux is.) -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 11:55 ` Matthias Andree @ 2006-02-10 12:15 ` DervishD 0 siblings, 0 replies; 439+ messages in thread From: DervishD @ 2006-02-10 12:15 UTC (permalink / raw) To: Joerg Schilling, mj, linux-kernel, jim, jengelh Hi Matthias :) * Matthias Andree <matthias.andree@gmx.de> dixit: > > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports > > > > > > Dou you like to verify that you have no clue on SCSI? > > > > My system is clueless, too! If I write a CD before plugging my > > USB storage device, my CD writer is on 0,0,0. If I plug my USB > > storage device *before* doing any access, my cdwriter is on 1,0,0. > > Pretty stable. > > Thanks for answering the question I directed towards Jörg, which proves > Martin Mares's point that b,t,l is not stable. This is a typical problem with the BTL numbering that any 2.4.x modular Linux kernel running without hotplug or udev has. And, at least to my knowledge and in /dev/sg side, it can be fixed using hotplug or udev (in 2.6.x). The BTL problem cannot. > I think, Martin, too deserves Jörg's apology I think so. Martin was being very respectuf. > and Jörg shouldn't only be more respectful, but listen to those who > know their system better than he does. (Of course this'll turn into > a flame feast how stupid Linux is.) And that's a pity, because it is a waste of human resources. And the bigger problem is that I still don't know why BTL is better than /dev/sg, and I've tried to understand it from the thread. I would be glad to hear Jörg explanations, but he thinks I'm trying to FUD :( Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 11:49 ` DervishD 2006-02-10 11:55 ` Matthias Andree @ 2006-02-10 12:36 ` Joerg Schilling 2006-02-10 22:43 ` Matthias Andree 2006-02-12 23:17 ` Sam Vilain 2006-02-13 0:50 ` Alexander Samad 2 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 12:36 UTC (permalink / raw) To: schilling, lkml Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh DervishD <lkml@dervishd.net> wrote: > My system is clueless, too! If I write a CD before plugging my > USB storage device, my CD writer is on 0,0,0. If I plug my USB > storage device *before* doing any access, my cdwriter is on 1,0,0. > Pretty stable. You are referring to a conceptional problem in the Linux kernel. If you are unhappy with this, send a bug report to the related people. This does not belong to libscg. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:36 ` Joerg Schilling @ 2006-02-10 22:43 ` Matthias Andree 2006-02-12 23:17 ` Sam Vilain 1 sibling, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-10 22:43 UTC (permalink / raw) To: Joerg Schilling Cc: lkml, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh Joerg Schilling schrieb am 2006-02-10: > DervishD <lkml@dervishd.net> wrote: > > > My system is clueless, too! If I write a CD before plugging my > > USB storage device, my CD writer is on 0,0,0. If I plug my USB > > storage device *before* doing any access, my cdwriter is on 1,0,0. > > Pretty stable. > > You are referring to a conceptional problem in the Linux kernel. > If you are unhappy with this, send a bug report to the related > people. > > This does not belong to libscg. No. You're shifting the blame, and this won't work here. You claim b,t,l were more stable than device node naming (which is untrue, as proven), and if it isn't because the assumptions in libscg don't hold, it's still someone else's fault. In doubt, everything that isn't Solaris or SchilliX is badly designed, a bug, or whatever. That's a pretty egocentric view. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:36 ` Joerg Schilling 2006-02-10 22:43 ` Matthias Andree @ 2006-02-12 23:17 ` Sam Vilain 2006-02-13 14:29 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: Sam Vilain @ 2006-02-12 23:17 UTC (permalink / raw) To: Joerg Schilling Cc: lkml, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-12 23:17 ` Sam Vilain @ 2006-02-13 14:29 ` Joerg Schilling 2006-02-13 14:57 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 14:29 UTC (permalink / raw) To: schilling, sam Cc: peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh Sam Vilain <sam@vilain.net> wrote: > Joerg Schilling wrote: > >> My system is clueless, too! If I write a CD before plugging my > >>USB storage device, my CD writer is on 0,0,0. If I plug my USB > >>storage device *before* doing any access, my cdwriter is on 1,0,0. > >>Pretty stable. > > You are referring to a conceptional problem in the Linux kernel. > > If you are unhappy with this, send a bug report to the related > > people. > > This does not belong to libscg. > > Jörg, > > Technically, you may have a point[*1*]. > > However, no matter how correct someone is, if they act like a complete > dork, they're not going to be listened to. This is why I have less and less intrest in listening to most of the people who are around here. They are either technically uninformed, personal offensive or obviously not interested in a solution. > This is a shame, because you appear to have some good experience to > relate. If only you could keep your social interaction problems in > check, you might be able to harbour and attract less hate, and perhaps > even get some of your suggestions implemented. Well, once the people here express real interest, things may change. As for now, it looks like I may make the following conclusions: - Linux was helpful and interesting between 1996 and ~ 2001 - Since ~ 2001, Linux seems to be bejond it's climax as I cannot see any intrest in even fixing obvious bugs known for a long time. When looking at the current discussion, it seems to me that most people here are still not interested in a fix. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:29 ` Joerg Schilling @ 2006-02-13 14:57 ` Matthias Andree [not found] ` <20060213095038.03247484.seanlkml@sympatico.ca> 2006-02-13 23:18 ` D. Hazelton 2 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-13 14:57 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
[parent not found: <20060213095038.03247484.seanlkml@sympatico.ca>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <20060213095038.03247484.seanlkml@sympatico.ca> @ 2006-02-13 14:50 ` sean 2006-02-13 15:36 ` Joerg Schilling 1 sibling, 0 replies; 439+ messages in thread From: sean @ 2006-02-13 14:50 UTC (permalink / raw) To: Joerg Schilling Cc: schilling, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh On Mon, 13 Feb 2006 15:29:02 +0100 Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > When looking at the current discussion, it seems to me that most people > here are still not interested in a fix. Most people don't see a problem to fix. Your arguments have been roundly refuted. On top of which, cdrecord works on Linux just fine already when you pass the device node on the command line. There just isn't much motivation to pursue a fix for some theoretical problem that doesn't affect real users in practice. Since you are the only one who sees this as a huge problem you should invest in providing a patch that can be reviewed for inclusion. Sean ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <20060213095038.03247484.seanlkml@sympatico.ca> 2006-02-13 14:50 ` sean @ 2006-02-13 15:36 ` Joerg Schilling [not found] ` <20060213104548.2999033d.seanlkml@sympatico.ca> ` (2 more replies) 1 sibling, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 15:36 UTC (permalink / raw) To: seanlkml, schilling Cc: schilling, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh sean <seanlkml@sympatico.ca> wrote: > On Mon, 13 Feb 2006 15:29:02 +0100 > Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > > When looking at the current discussion, it seems to me that most people > > here are still not interested in a fix. > > Most people don't see a problem to fix. Your arguments have been roundly > refuted. On top of which, cdrecord works on Linux just fine already when > you pass the device node on the command line. There just isn't much > motivation to pursue a fix for some theoretical problem that doesn't affect > real users in practice. Since you are the only one who sees this as a huge > problem you should invest in providing a patch that can be reviewed for > inclusion. So you like to prove that it makes not sense to talk to LKML people? If there is no interest to fox well known bugs in Linux, I would need to warn people from using Linux. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
[parent not found: <20060213104548.2999033d.seanlkml@sympatico.ca>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <20060213104548.2999033d.seanlkml@sympatico.ca> @ 2006-02-13 15:45 ` sean 0 siblings, 0 replies; 439+ messages in thread From: sean @ 2006-02-13 15:45 UTC (permalink / raw) To: Joerg Schilling Cc: schilling, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh On Mon, 13 Feb 2006 16:36:17 +0100 Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > Most people don't see a problem to fix. Your arguments have been roundly > > refuted. On top of which, cdrecord works on Linux just fine already when > > you pass the device node on the command line. There just isn't much > > motivation to pursue a fix for some theoretical problem that doesn't affect > > real users in practice. Since you are the only one who sees this as a huge > > problem you should invest in providing a patch that can be reviewed for > > inclusion. > > So you like to prove that it makes not sense to talk to LKML people? This is a non sequitur. > If there is no interest to fox well known bugs in Linux, I would need to warn > people from using Linux. People have a lot of interest to fix well known bugs in Linux, it happens every day. The point is nobody but you classifies this as a bug. Since you are alone in classifying this as a bug, you will be alone in submitting patches for it. Good luck. Sean ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:36 ` Joerg Schilling [not found] ` <20060213104548.2999033d.seanlkml@sympatico.ca> @ 2006-02-13 16:10 ` Martin Mares 2006-02-13 16:26 ` Joerg Schilling 2006-02-13 16:13 ` Matthias Andree 2 siblings, 1 reply; 439+ messages in thread From: Martin Mares @ 2006-02-13 16:10 UTC (permalink / raw) To: Joerg Schilling Cc: seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim, jengelh Hello! > If there is no interest to fox well known bugs in Linux, I would need to warn > people from using Linux. Except for mentioning some DMA related problems at the beginning of this monstrous thread, you haven't shown anything which even remotely qualifies as a bug. You are only endlessly complaining about Linux not following the same model of SCSI access as you love, which might be a little incovenient for you, but that certainly doesn't make it a bug. You tried to juggle with dubious POSIX references, but so far nobody has found any place in POSIX or SuS saying that anything has to be stable across mounts/umounts. So what damned bugs are you speaking about? Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "One single semicolon. A perfect drop of perliness. The rest is padding." -- S. Manandhar ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:10 ` Martin Mares @ 2006-02-13 16:26 ` Joerg Schilling [not found] ` <515e525f0602130834h1fd23146laf9daf354b1b8c75@mail.gmail.com> ` (4 more replies) 0 siblings, 5 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 16:26 UTC (permalink / raw) To: schilling, mj Cc: seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim, jengelh Martin Mares <mj@ucw.cz> wrote: > Hello! > > > If there is no interest to fox well known bugs in Linux, I would need to warn > > people from using Linux. > > Except for mentioning some DMA related problems at the beginning of this > monstrous thread, you haven't shown anything which even remotely qualifies > as a bug. If you forget these things, then please forget about this thread. I mentioned: - ide-scsi does not do DMA correctly - SCSI commands are bastardized on ATAPI If you like, I can give you many other Linux related bugs but it does not make sense unless the two bugs above are fixed. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
[parent not found: <515e525f0602130834h1fd23146laf9daf354b1b8c75@mail.gmail.com>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <515e525f0602130834h1fd23146laf9daf354b1b8c75@mail.gmail.com> @ 2006-02-13 16:38 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 16:38 UTC (permalink / raw) To: trudheim, schilling Cc: seanlkml, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh Anders Karlsson <trudheim@gmail.com> wrote: > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > [snip] > > If you forget these things, then please forget about this thread. > > > > I mentioned: > > > > - ide-scsi does not do DMA correctly > > > > - SCSI commands are bastardized on ATAPI > > > > If you like, I can give you many other Linux related bugs but it does > > not make sense unless the two bugs above are fixed. > > Perhaps libata is more to your liking and that seems to be the > direction things are heading in. Perhaps that can make this flamefest > go away? ??? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:26 ` Joerg Schilling [not found] ` <515e525f0602130834h1fd23146laf9daf354b1b8c75@mail.gmail.com> @ 2006-02-13 16:44 ` Matthias Andree 2006-02-13 16:50 ` Martin Mares ` (2 subsequent siblings) 4 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-13 16:44 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-13: > Martin Mares <mj@ucw.cz> wrote: > > > Hello! > > > > > If there is no interest to fox well known bugs in Linux, I would need to warn > > > people from using Linux. > > > > Except for mentioning some DMA related problems at the beginning of this > > monstrous thread, you haven't shown anything which even remotely qualifies > > as a bug. > > If you forget these things, then please forget about this thread. > > I mentioned: > > - ide-scsi does not do DMA correctly Apparently no-one bothers to fix this with ide-cd supporting SG_IO, and nobody produced any use case for other ide-*.c devices. You'll either have to fix this yourself or wait until the day the cows coime home. > - SCSI commands are bastardized on ATAPI You were asked for a proof but didn't provide one. If you think otherwise, post URL or Message-ID. We're all sooooooooooooooo terrible forgetful we don't recall your reports from 2001. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:26 ` Joerg Schilling [not found] ` <515e525f0602130834h1fd23146laf9daf354b1b8c75@mail.gmail.com> 2006-02-13 16:44 ` Matthias Andree @ 2006-02-13 16:50 ` Martin Mares 2006-02-13 16:56 ` Joerg Schilling 2006-02-13 17:22 ` Luke-Jr 2006-02-13 23:42 ` D. Hazelton 4 siblings, 1 reply; 439+ messages in thread From: Martin Mares @ 2006-02-13 16:50 UTC (permalink / raw) To: Joerg Schilling Cc: seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim, jengelh Hello! > - SCSI commands are bastardized on ATAPI One more question before this thread hopefully dies out: What do you mean by "bastardized"? Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Don't take life too seriously -- you'll never get out of it alive. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:50 ` Martin Mares @ 2006-02-13 16:56 ` Joerg Schilling 2006-02-13 17:14 ` Martin Mares 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 16:56 UTC (permalink / raw) To: schilling, mj Cc: seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim, jengelh Martin Mares <mj@ucw.cz> wrote: > Hello! > > > - SCSI commands are bastardized on ATAPI > > One more question before this thread hopefully dies out: > > What do you mean by "bastardized"? I did describe this in detail before: some drives complain about "illegal field in cdb" with "read full toc" and "blank" while the same HW booted with Solaris or SCO UnixWare has no problems. Let me write a final remark: cdrecord currently has no known Linux specific bug. Let us comtinue to talk after the Linux kernel bugs that prevent cdrecord from working have been fixed. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:56 ` Joerg Schilling @ 2006-02-13 17:14 ` Martin Mares 2006-02-13 17:27 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Martin Mares @ 2006-02-13 17:14 UTC (permalink / raw) To: Joerg Schilling Cc: seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim, jengelh Hello! > Let me write a final remark: > > cdrecord currently has no known Linux specific bug. > > Let us comtinue to talk after the Linux kernel bugs that > prevent cdrecord from working have been fixed. OK. And in the meantime you can remove the silly warnings about device names being unsupported. MM ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:14 ` Martin Mares @ 2006-02-13 17:27 ` Joerg Schilling 2006-02-13 17:37 ` Martin Mares ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 17:27 UTC (permalink / raw) To: schilling, mj Cc: seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim, jengelh Martin Mares <mj@ucw.cz> wrote: > Hello! > > > Let me write a final remark: > > > > cdrecord currently has no known Linux specific bug. > > > > Let us comtinue to talk after the Linux kernel bugs that > > prevent cdrecord from working have been fixed. > > OK. And in the meantime you can remove the silly warnings about > device names being unsupported. The warnings are not silly. They could have been removed long ago if the icd-scsi DMA bug was fixed. So take it as it is: Linux first fixes the icd-scsi DMA bug and then it makes sense to remove the related warning. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:27 ` Joerg Schilling @ 2006-02-13 17:37 ` Martin Mares 2006-02-13 20:13 ` Matthias Andree 2006-02-14 8:01 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: Martin Mares @ 2006-02-13 17:37 UTC (permalink / raw) To: Joerg Schilling Cc: seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim, jengelh Hello! > The warnings are not silly. They could have been removed long ago > if the icd-scsi DMA bug was fixed. This doesn't make sense, the usual case when the warning is printed, that is referring to /dev/hd* directly, doesn't use ide-scsi at all. Hence the only logical warning would be exactly the opposite: warn the user if he uses ide-scsi, because you know it's broken. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth The number of UNIX installations has grown to 10, with more expected. (6/72) ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:27 ` Joerg Schilling 2006-02-13 17:37 ` Martin Mares @ 2006-02-13 20:13 ` Matthias Andree 2006-02-14 8:01 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-13 20:13 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-13: > The warnings are not silly. They could have been removed long ago > if the icd-scsi DMA bug was fixed. The warnings are way off track, because 1. /dev/hd* means ide-cd which has never had the incriminated bugs, no matter if badly designed or not 2. you can't tell from looking at /dev/sg* or the b,t,l if the device node is operated by the ide-scsi or sg drivers. Both use the unified /dev/sg* namespace. In fact, it makes sense to suppress the warning for /dev/hd* and ATA: which are known good. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:27 ` Joerg Schilling 2006-02-13 17:37 ` Martin Mares 2006-02-13 20:13 ` Matthias Andree @ 2006-02-14 8:01 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-14 8:01 UTC (permalink / raw) To: Joerg Schilling Cc: mj, seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim > >The warnings are not silly. They could have been removed long ago >if the icd-scsi DMA bug was fixed. > ...if someone cared to fix it. This is the opensource world, and if someone's out for a fix, they either have to write it themselves or pay someone to do so. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:26 ` Joerg Schilling ` (2 preceding siblings ...) 2006-02-13 16:50 ` Martin Mares @ 2006-02-13 17:22 ` Luke-Jr 2006-02-13 17:40 ` Joerg Schilling 2006-02-13 23:42 ` D. Hazelton 4 siblings, 1 reply; 439+ messages in thread From: Luke-Jr @ 2006-02-13 17:22 UTC (permalink / raw) To: Joerg Schilling Cc: mj, seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim, jengelh On Monday 13 February 2006 16:26, Joerg Schilling wrote: > Martin Mares <mj@ucw.cz> wrote: > > > If there is no interest to fox well known bugs in Linux, I would need > > > to warn people from using Linux. > > > > Except for mentioning some DMA related problems at the beginning of this > > monstrous thread, you haven't shown anything which even remotely > > qualifies as a bug. > > If you forget these things, then please forget about this thread. > > I mentioned: > > - ide-scsi does not do DMA correctly IIRC, ide-scsi is deprecated and would be removed as a fix for this bug. Note that ide-scsi is known to be broken in more ways than just this-- for example, unloading the module causes a kernel panic. > - SCSI commands are bastardized on ATAPI I'm not a kernel developer, but my understanding is that they're basically passed through the ATAPI layer. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:22 ` Luke-Jr @ 2006-02-13 17:40 ` Joerg Schilling 2006-02-13 17:48 ` newbiz ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 17:40 UTC (permalink / raw) To: schilling, luke Cc: seanlkml, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh Luke-Jr <luke@dashjr.org> wrote: > > I mentioned: > > > > - ide-scsi does not do DMA correctly > > IIRC, ide-scsi is deprecated and would be removed as a fix for this bug. Note > that ide-scsi is known to be broken in more ways than just this-- for > example, unloading the module causes a kernel panic. A last word on that: - this bug is known for more than 2 years. - time to fix: less than 3 hours for the right person - I therefore expect a fix in less than a month or I must asume that Linux is not longer actively maintained. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:40 ` Joerg Schilling @ 2006-02-13 17:48 ` newbiz 2006-02-13 17:49 ` Luke-Jr 2006-02-13 19:20 ` Matthias Andree 2 siblings, 0 replies; 439+ messages in thread From: newbiz @ 2006-02-13 17:48 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel Joerg Schilling a ecrit le 13.02.2006 18:40 : > - I therefore expect a fix in less than a month or > I must asume that Linux is not longer actively maintained. so is your brain, obviously ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:40 ` Joerg Schilling 2006-02-13 17:48 ` newbiz @ 2006-02-13 17:49 ` Luke-Jr 2006-02-14 11:13 ` Joerg Schilling 2006-02-13 19:20 ` Matthias Andree 2 siblings, 1 reply; 439+ messages in thread From: Luke-Jr @ 2006-02-13 17:49 UTC (permalink / raw) To: Joerg Schilling Cc: seanlkml, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh On Monday 13 February 2006 17:40, Joerg Schilling wrote: > Luke-Jr <luke@dashjr.org> wrote: > > > I mentioned: > > > > > > - ide-scsi does not do DMA correctly > > > > IIRC, ide-scsi is deprecated and would be removed as a fix for this bug. > > Note that ide-scsi is known to be broken in more ways than just this-- > > for example, unloading the module causes a kernel panic. > > A last word on that: > > - this bug is known for more than 2 years. > > - time to fix: less than 3 hours for the right person > > - I therefore expect a fix in less than a month or > I must asume that Linux is not longer actively maintained. What does it do "wrong" anyway? IIRC, DMA in general works... Also note that since SCSI does not support DMA, I wouldn't consider lack of DMA for ide-scsi a bug. Just because the underlying device is IDE and has DMA support doesn't mean that the SCSI layer (which has no reason for DMA) should use it. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:49 ` Luke-Jr @ 2006-02-14 11:13 ` Joerg Schilling 2006-02-14 12:08 ` D. Hazelton 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 11:13 UTC (permalink / raw) To: schilling, luke Cc: seanlkml, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh Luke-Jr <luke@dashjr.org> wrote: > What does it do "wrong" anyway? IIRC, DMA in general works... If you really believe that it is good practice to implement DMA in a way so it works at some places as expected but on others not.... ... then you like the Linux kernel be a junk yard :-( Good practice is to fix _all_ related code in a project in case a bug is identified and fixed at some place. Unfortunately this is not true for Linux and for this reason, Linux cannot yet be called mature. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 11:13 ` Joerg Schilling @ 2006-02-14 12:08 ` D. Hazelton 2006-02-14 16:35 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-14 12:08 UTC (permalink / raw) To: Joerg Schilling Cc: luke, seanlkml, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh On Tuesday 14 February 2006 06:13, Joerg Schilling wrote: > Luke-Jr <luke@dashjr.org> wrote: > > What does it do "wrong" anyway? IIRC, DMA in general works... > > If you really believe that it is good practice to implement DMA in > a way so it works at some places as expected but on others not.... > > ... then you like the Linux kernel be a junk yard :-( > > Good practice is to fix _all_ related code in a project in case a bug > is identified and fixed at some place. Unfortunately this is not true > for Linux and for this reason, Linux cannot yet be called mature. Joerg, I think you misunderstand the problem here. The block layer itself supports DMA unilaterally. Some of the extended drivers that provide support for older hardware or, in the case of the (need I remind you) deprecated ide-scsi system, for an abstraction layer do not for various reasons. Whether that is because the device itself doesn't support DMA or if it's because the added complexity (in the ide-scsi case) of providing DMA for an abstraction layer made it nearly impossible. As the problems with ide-scsi are soon to be gone from main-line up-to-date kernels, I have trouble seeing why you still harp on this problem. As I'm sure you know, Linux is an Open Source operating system. If you need it to support DMA in the ide-scsi system, then you are free to add said support. If you do not have the time or the skill to do so, you are also free to pay someone to do it for you. But as the kernel progresses through 2.6 you will find that most of your "bugs" are being dealt with. As a matter of fact I have offered to attempt to fix the problems you have with the ATAPI layer munging packets. As I said before, if you can provide me with the details of which hardware is affected and what exactly is occurring I can probably work on this. (And from the contents of a recent post, you can be certain I am not the only one interested in fixing this problem of yours) However, if the problem is non-existant with a _modern_ kernel, then may I make one suggestion: remove your constant reporting of the problem. Furthermore I have been quiet until now regarding the comments you have made in the source to cdrecord and libscg regarding Linux. While I appreciate that your software has been functional for twenty years now, I would suggest that you question your own motives, as it appears that your problems with Linux are more of a personal nature and not a technical one. Moreover I find that you make constant reference to "how things should have been done" but in looking through the Linux sources, I can find no hint that you ever touched the portions of the OS in question. Therefore I have to wonder if your abrasive manner and repeated personal attacks were not occurring even as the block device layer was undergoing it's last sets of rewrites and managed to alienate the entire crew of people working on it. Up to this point I have attempted to be calm and civil, if not polite. However you preach about "good practice" and claim you will accept patches, yet in your stated policy you reserve the right to reject any patch on non-technical grounds. What's more is that you _have_ shown this to be your most common mode of operation, to the point of refusing to actually look at patches that meet the rest of the standards you provide. I have no wish for this discussion to devolve any further, and have been attempting to turn it around and make it productive. Patience is something that I do not have in infinite quantities, however. My offers to attempt to fix the second of the two "major" bugs you reported stands, as does my offer to patch cdrecord so that it uniformly uses the b,t,l addressing scheme internally while allowing users to select a device node. I will let them stand for one week. If, at the end of that week, you have either 1) not provided me with the documentation I need to attempt to fix the bugs in the linux kernel or 2) not provided me with a written standards document on how code should be formatted for cdrecord patches either or both of the offers will be withdrawn and I will neither read nor respond to further mail from you. Did I make myself clear, or should I attempt to restate that in my very rusty and beleagured german? DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 12:08 ` D. Hazelton @ 2006-02-14 16:35 ` Joerg Schilling 2006-02-14 16:44 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 16:35 UTC (permalink / raw) To: schilling, dhazelton Cc: seanlkml, sam, peter.read, mj, matthias.andree, luke, lkml, linux-kernel, jim, jengelh "D. Hazelton" <dhazelton@enter.net> wrote: > As I'm sure you know, Linux is an Open Source operating system. If you need it > to support DMA in the ide-scsi system, then you are free to add said support. It seems that you did missunderstand Linux: I did send a fix for an important bug in 1997 and it was NOT integraded by the Linux kernel people. As long as the Linux project proves that Linux is not yet mature enough for being able to _really_ do what you propose, it makes no sense to waste time on LKML. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:35 ` Joerg Schilling @ 2006-02-14 16:44 ` Matthias Andree 2006-02-14 16:45 ` grundig 2006-02-14 18:00 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-14 16:44 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-14: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > > As I'm sure you know, Linux is an Open Source operating system. If you need it > > to support DMA in the ide-scsi system, then you are free to add said support. > > It seems that you did missunderstand Linux: > > I did send a fix for an important bug in 1997 and it was NOT integraded by > the Linux kernel people. Wow, 9 years ago. Was it for 2.0 already or still 1.2? Does the bug persist in 2.6.16-rc3? If so, resend your fix. > As long as the Linux project proves that Linux is not yet mature enough for > being able to _really_ do what you propose, it makes no sense to waste time > on LKML. An action speaks louder than 1000 words. When are you leaving? -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:35 ` Joerg Schilling 2006-02-14 16:44 ` Matthias Andree @ 2006-02-14 16:45 ` grundig 2006-02-14 18:00 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: grundig @ 2006-02-14 16:45 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, seanlkml, sam, peter.read, mj, matthias.andree, luke, lkml, linux-kernel, jim, jengelh El Tue, 14 Feb 2006 17:35:32 +0100, Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > I did send a fix for an important bug in 1997 and it was NOT integraded by > the Linux kernel people. Many patches are rejected. Looking at the way you handle cross-platform design for libscg is not something that surprises me.... ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:35 ` Joerg Schilling 2006-02-14 16:44 ` Matthias Andree 2006-02-14 16:45 ` grundig @ 2006-02-14 18:00 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-14 18:00 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, seanlkml, sam, peter.read, mj, matthias.andree, luke, lkml, linux-kernel, jim > >I did send a fix for an important bug in 1997 and it was NOT integraded by >the Linux kernel people. > Resend it. I also see that some of my patches/compilefixes don't make it into the main tree at first time. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:40 ` Joerg Schilling 2006-02-13 17:48 ` newbiz 2006-02-13 17:49 ` Luke-Jr @ 2006-02-13 19:20 ` Matthias Andree 2 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-13 19:20 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-13: > - this bug is known for more than 2 years. > > - time to fix: less than 3 hours for the right person > > - I therefore expect a fix in less than a month or > I must asume that Linux is not longer actively maintained. The kernel jumps at Jörg's command. Film at eleven. Where's my popcorn? You were told that ide-scsi fixes are not a priority item, you were shown that ide-cd works, you were shown that /dev/hd* and /dev/sg* can share the same namespace (see my proof-of-concept patch), so there's nothing left for you to want. Either fix ide-scsi yourself, or fork a few 50 € bills and contract somebody to do it. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:26 ` Joerg Schilling ` (3 preceding siblings ...) 2006-02-13 17:22 ` Luke-Jr @ 2006-02-13 23:42 ` D. Hazelton 2006-02-14 8:04 ` Jan Engelhardt 4 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-13 23:42 UTC (permalink / raw) To: Joerg Schilling Cc: mj, seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim, jengelh On Monday 13 February 2006 11:26, Joerg Schilling wrote: > Martin Mares <mj@ucw.cz> wrote: > > Hello! > > > > > If there is no interest to fox well known bugs in Linux, I would need > > > to warn people from using Linux. > > > > Except for mentioning some DMA related problems at the beginning of this > > monstrous thread, you haven't shown anything which even remotely > > qualifies as a bug. > > If you forget these things, then please forget about this thread. > > I mentioned: > > - ide-scsi does not do DMA correctly ide-scsi is deprecated and will be removed at a later date. Any program relying on ide-scsi will have to be rewritten. > - SCSI commands are bastardized on ATAPI identify the problem - provide a test case or two and I'll get off my lazy ass and see if I can't figure out what's causing the problem. > If you like, I can give you many other Linux related bugs but it does > not make sense unless the two bugs above are fixed. Only one bug needs fixed. ide-scsi is not going to be in the kernel much longer. Although someone might find the time to fix the bugs for those people dependant on older kernels. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 23:42 ` D. Hazelton @ 2006-02-14 8:04 ` Jan Engelhardt 2006-02-14 8:25 ` D. Hazelton 2006-02-14 15:04 ` Joerg Schilling 0 siblings, 2 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-14 8:04 UTC (permalink / raw) To: D. Hazelton Cc: Joerg Schilling, mj, seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim > >> - SCSI commands are bastardized on ATAPI > >identify the problem - provide a test case or two and I'll get off my lazy ass >and see if I can't figure out what's causing the problem. > Maybe we can put a testsuite together that sends all sorts of commands to a cd drive and then see with 1. which Linuxes 2. which models it happens. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 8:04 ` Jan Engelhardt @ 2006-02-14 8:25 ` D. Hazelton 2006-02-14 15:04 ` Joerg Schilling 1 sibling, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-14 8:25 UTC (permalink / raw) To: Jan Engelhardt Cc: Joerg Schilling, mj, seanlkml, sam, peter.read, matthias.andree, lkml, linux-kernel, jim On Tuesday 14 February 2006 03:04, Jan Engelhardt wrote: > >> - SCSI commands are bastardized on ATAPI > > > >identify the problem - provide a test case or two and I'll get off my lazy > > ass and see if I can't figure out what's causing the problem. > > Maybe we can put a testsuite together that sends all sorts of commands to a > cd drive and then see with 1. which Linuxes 2. which models it happens. > > > Jan Engelhardt Excellent idea, but since Joerg probably has all the information already I don't see why he can't provide it. At least that way there is some time saved and I won't wind up seeing my aging CDRW drive get any excessive wear. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 8:04 ` Jan Engelhardt 2006-02-14 8:25 ` D. Hazelton @ 2006-02-14 15:04 ` Joerg Schilling 2006-02-14 16:53 ` Matthias Andree 2006-02-14 22:10 ` D. Hazelton 1 sibling, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 15:04 UTC (permalink / raw) To: jengelh, dhazelton Cc: seanlkml, schilling, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > >> - SCSI commands are bastardized on ATAPI > > > >identify the problem - provide a test case or two and I'll get off my lazy ass > >and see if I can't figure out what's causing the problem. > > > > Maybe we can put a testsuite together that sends all sorts of commands to a > cd drive and then see with 1. which Linuxes 2. which models it happens. You need to ask around for people with problems.... Debian had some relevent data but removed it the day I was referring to it :-( Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 15:04 ` Joerg Schilling @ 2006-02-14 16:53 ` Matthias Andree 2006-02-14 17:41 ` Joerg Schilling 2006-02-14 22:10 ` D. Hazelton 1 sibling, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-14 16:53 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-14: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > > > > >> - SCSI commands are bastardized on ATAPI > > > > > >identify the problem - provide a test case or two and I'll get off my lazy ass > > >and see if I can't figure out what's causing the problem. > > > > > > > Maybe we can put a testsuite together that sends all sorts of commands to a > > cd drive and then see with 1. which Linuxes 2. which models it happens. > > You need to ask around for people with problems.... > Debian had some relevent data but removed it the day I was referring to it :-( In other words: you cannot provide details or even prove the asserted bug, and you are trying to shift the blame on Debian. If they no longer have the reports, chances are the bugs have been fixed since through Debian patches, that's their workflow. And if you want Debian bugs, look here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=cdrecord&archive=no&version=&dist=unstable&pend-exc=fixed&pend-exc=done&sev-exc=wishlist&sev-exc=fixed But keep in mind only the "forwarded" or "upstream" bugs are your business. Besides that, I wouldn't exactly call it quality standard if you lose important bug reports about the environment. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 16:53 ` Matthias Andree @ 2006-02-14 17:41 ` Joerg Schilling 2006-02-14 19:49 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 17:41 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-14: > > > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > > > > > > > >> - SCSI commands are bastardized on ATAPI > > > > > > > >identify the problem - provide a test case or two and I'll get off my lazy ass > > > >and see if I can't figure out what's causing the problem. > > > > > > > > > > Maybe we can put a testsuite together that sends all sorts of commands to a > > > cd drive and then see with 1. which Linuxes 2. which models it happens. > > > > You need to ask around for people with problems.... > > Debian had some relevent data but removed it the day I was referring to it :-( > > In other words: you cannot provide details or even prove the asserted > bug, and you are trying to shift the blame on Debian. If they no longer > have the reports, chances are the bugs have been fixed since through > Debian patches, that's their workflow. In other words, you are still only trying to create voilence but unable/unwilling to cooperate? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099 Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 17:41 ` Joerg Schilling @ 2006-02-14 19:49 ` Matthias Andree 2006-02-14 19:56 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-14 19:49 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-14: > Matthias Andree <matthias.andree@gmx.de> wrote: > > In other words, you are still only trying to create voilence but > unable/unwilling to cooperate? Amusing question, isn't it you who dropped the patch (= quit cooperation) without looking at it? > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099 So Debian didn't delete your bugs? Hm... and tomorrow you'll tell us you never insinuated Debian deleted bugs. Quote "This seems to be a general problem with QSI-drives, see e.g. http://lists.debian.org/debian-user-german/2004/debian-user-german-200402/msg05143.html which shows testimonials about failed blanking of cd-rws for QSI CD-RW/DVD-ROM SBW-241, cdrdao succeeds." "If you are unwilling to remove a non cdrecord related bug from the list or if you unable to understand the background, you should ask for help or leave the cdrecord project." http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099;msg=84 Uncle Jörg the Dictator, commander in charge of earth motion. Fails to mention libscg code paths for Solaris and Linux differ. I've filed a 186099 amendment to prevent fallacies there... -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 19:49 ` Matthias Andree @ 2006-02-14 19:56 ` Joerg Schilling 2006-02-14 20:23 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 19:56 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-14: > > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > In other words, you are still only trying to create voilence but > > unable/unwilling to cooperate? > > Amusing question, isn't it you who dropped the patch (= quit > cooperation) without looking at it? > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099 > > So Debian didn't delete your bugs? Hm... and tomorrow you'll tell us you > never insinuated Debian deleted bugs. > > Quote "This seems to be a general problem with QSI-drives, see e.g. > http://lists.debian.org/debian-user-german/2004/debian-user-german-200402/msg05143.html > which shows testimonials about failed blanking of cd-rws for QSI > CD-RW/DVD-ROM SBW-241, cdrdao succeeds." > > "If you are unwilling to remove a non cdrecord related bug from the list > or if you unable to understand the background, you should ask for help > or leave the cdrecord project." > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099;msg=84 If you don't know the background, stay quiet! This bug has been moved away from Linux kernel bugs several times. I was requesting to put the bug where it belongs.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 19:56 ` Joerg Schilling @ 2006-02-14 20:23 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-14 20:23 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel Joerg Schilling schrieb am 2006-02-14: > Matthias Andree <matthias.andree@gmx.de> wrote: > > "If you are unwilling to remove a non cdrecord related bug from the list > > or if you unable to understand the background, you should ask for help > > or leave the cdrecord project." > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186099;msg=84 > > If you don't know the background, stay quiet! Right, hello everyone, jump at Jörg's command. One, two, ... > This bug has been moved away from Linux kernel bugs several times. False. It had never been assigned to the kernel. > I was requesting to put the bug where it belongs.... I can read, thank you, and the bugreport lacks any evidence as to the nature of the bug. "where it belongs" are typical fallacies, unless someone invokes "in dubio pro reo", concludes it's a firmware bug and closes it. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 15:04 ` Joerg Schilling 2006-02-14 16:53 ` Matthias Andree @ 2006-02-14 22:10 ` D. Hazelton 2006-02-16 11:42 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-14 22:10 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, seanlkml, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim On Tuesday 14 February 2006 10:04, Joerg Schilling wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > >> - SCSI commands are bastardized on ATAPI > > > > > >identify the problem - provide a test case or two and I'll get off my > > > lazy ass and see if I can't figure out what's causing the problem. > > > > Maybe we can put a testsuite together that sends all sorts of commands to > > a cd drive and then see with 1. which Linuxes 2. which models it happens. > > You need to ask around for people with problems.... > Debian had some relevent data but removed it the day I was referring to it > :-( As the maintainer of the cdrtools package and the author of both libscg and cdrecord I find it hard to believe that you do not have a log of these somewhere. If Debian had relevant data and removed it, then it is quite probable that they fixed the problem already. If that is the case, then all it should take to find out is making an enquiry or searching among their distribution specific kernel patches. However, in the spirit of making this discussion bear useful fruit, I will take it upon myself to search the Debian archived bugs and see if I can find out the relevant data myself. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 22:10 ` D. Hazelton @ 2006-02-16 11:42 ` Joerg Schilling 2006-02-16 11:52 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-16 11:42 UTC (permalink / raw) To: schilling, dhazelton Cc: seanlkml, sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh "D. Hazelton" <dhazelton@enter.net> wrote: > As the maintainer of the cdrtools package and the author of both libscg and > cdrecord I find it hard to believe that you do not have a log of these > somewhere. If Debian had relevant data and removed it, then it is quite > probable that they fixed the problem already. If that is the case, then all > it should take to find out is making an enquiry or searching among their > distribution specific kernel patches. I usually fix real bugs immediately after I know them. I don't see that it makes sense to archive Linux bugs as long ad the Linux kernel folks are obviously not willing to fix them. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 11:42 ` Joerg Schilling @ 2006-02-16 11:52 ` Matthias Andree 2006-02-16 18:06 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-16 11:52 UTC (permalink / raw) To: Joerg Schilling; +Cc: dhazelton, Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-16: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > As the maintainer of the cdrtools package and the author of both libscg and > > cdrecord I find it hard to believe that you do not have a log of these > > somewhere. If Debian had relevant data and removed it, then it is quite > > probable that they fixed the problem already. If that is the case, then all > > it should take to find out is making an enquiry or searching among their > > distribution specific kernel patches. > > I usually fix real bugs immediately after I know them. "Usually" is the key here. Sometimes, you refuse to fix real bugs forever even if you're made aware of them, and rather shift the blame on somebody else. > I don't see that it makes sense to archive Linux bugs as long ad the Linux > kernel folks are obviously not willing to fix them. Then the bugs can't have been important to you. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 11:52 ` Matthias Andree @ 2006-02-16 18:06 ` Joerg Schilling 2006-02-16 18:14 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-16 18:06 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel, dhazelton Matthias Andree <matthias.andree@gmx.de> wrote: > > I usually fix real bugs immediately after I know them. > > "Usually" is the key here. Sometimes, you refuse to fix real bugs > forever even if you're made aware of them, and rather shift the blame > on somebody else. Show me a single real bug that I did not fix. > > I don't see that it makes sense to archive Linux bugs as long ad the Linux > > kernel folks are obviously not willing to fix them. > > Then the bugs can't have been important to you. ??? Id the Linux kernel is not fixed, the importance is irrelevent unfortunately. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 18:06 ` Joerg Schilling @ 2006-02-16 18:14 ` Matthias Andree 2006-02-17 10:29 ` Joerg Schilling 2006-02-16 19:26 ` Edgar Toernig 2006-02-16 22:42 ` D. Hazelton 2 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-16 18:14 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-16: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > I usually fix real bugs immediately after I know them. > > > > "Usually" is the key here. Sometimes, you refuse to fix real bugs > > forever even if you're made aware of them, and rather shift the blame > > on somebody else. > > Show me a single real bug that I did not fix. Namespace split ATA/SCSI is unfixed in 2.01.01a06. Bogus warnings about Linux are unfixed in said version. Bogus warnings about /dev/* are unfixed in said version. Linux uname() detection code is broken since 2.6.10 because it assumes fixed-width fields. That makes four. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 18:14 ` Matthias Andree @ 2006-02-17 10:29 ` Joerg Schilling 2006-02-17 10:48 ` Martin Mares ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-17 10:29 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-16: > > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > > I usually fix real bugs immediately after I know them. > > > > > > "Usually" is the key here. Sometimes, you refuse to fix real bugs > > > forever even if you're made aware of them, and rather shift the blame > > > on somebody else. > > > > Show me a single real bug that I did not fix. > > Namespace split ATA/SCSI is unfixed in 2.01.01a06. The namne space split is a Linux kernel bug > Bogus warnings about Linux are unfixed in said version. Warnings related to Linux kernel bugs > Bogus warnings about /dev/* are unfixed in said version. Warnings related to Linux kernel bugs > Linux uname() detection code is broken since 2.6.10 because it assumes > fixed-width fields. Warnings related to Linux kernel bugs Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 10:29 ` Joerg Schilling @ 2006-02-17 10:48 ` Martin Mares 2006-02-17 12:09 ` Matthias Andree 2006-02-17 20:45 ` D. Hazelton 2 siblings, 0 replies; 439+ messages in thread From: Martin Mares @ 2006-02-17 10:48 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel Hello! > > Namespace split ATA/SCSI is unfixed in 2.01.01a06. > > The namne space split is a Linux kernel bug You are getting ridiculous. A bug against what? Against your wishes? > > Bogus warnings about /dev/* are unfixed in said version. > > Warnings related to Linux kernel bugs Rubbish. The Linux bugs you have pointed to are in ide-scsi and opening /dev/hd* directly is guaranteed to avoid them. The only warning which would make sense would be if somebody USES ide-scsi, not if he avoids it. > > Linux uname() detection code is broken since 2.6.10 because it assumes > > fixed-width fields. > > Warnings related to Linux kernel bugs Stop parroting and read what you are replying to. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth My Wife Says I Never Listen, Or Something Like That... ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 10:29 ` Joerg Schilling 2006-02-17 10:48 ` Martin Mares @ 2006-02-17 12:09 ` Matthias Andree 2006-02-17 20:45 ` D. Hazelton 2 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-17 12:09 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel Joerg Schilling schrieb am 2006-02-17: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > Namespace split ATA/SCSI is unfixed in 2.01.01a06. > > The namne space split is a Linux kernel bug Define: name space := cdrecord/libscg device identifier, specified as [transport:]bus,target,lun It is a libscg bug, as proven before in <http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html> (Just so you don't get the last word.) > > Linux uname() detection code is broken since 2.6.10 because it assumes > > fixed-width fields. > > Warnings related to Linux kernel bugs OK. Since the bug is actually beneficial to Linux >= 2.6.10 users, I'm not detailing. You don't need to fix it. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 10:29 ` Joerg Schilling 2006-02-17 10:48 ` Martin Mares 2006-02-17 12:09 ` Matthias Andree @ 2006-02-17 20:45 ` D. Hazelton 2006-02-20 14:59 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-17 20:45 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Friday 17 February 2006 05:29, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > Joerg Schilling schrieb am 2006-02-16: > > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > I usually fix real bugs immediately after I know them. > > > > > > > > "Usually" is the key here. Sometimes, you refuse to fix real bugs > > > > forever even if you're made aware of them, and rather shift the blame > > > > on somebody else. > > > > > > Show me a single real bug that I did not fix. > > > > Namespace split ATA/SCSI is unfixed in 2.01.01a06. > > The namne space split is a Linux kernel bug Then why have I been talking about a unification with you? I would quote your comments on it, but since that was a private mail I will not do so. > > Bogus warnings about Linux are unfixed in said version. > > Warnings related to Linux kernel bugs >From what I can tell a lot of the warnings are bogus. You even go to great lengths to "scare" people into only using "official" versions of cdrtools. As to that, you have sections in the code marked "Do Not Change" and "Do Not Remove" - I checked the GPLv2 today (the one shipped with all versions of cdrecord I can find) and there is nothing in that which gives you the right to restrict what someone else does to your code. Call it people being polite that nobody has removed that stuff from the existing primary port of cdrtools. > > Bogus warnings about /dev/* are unfixed in said version. > > Warnings related to Linux kernel bugs No. There is no Kernel bug in the SG_IO via /dev/hd* implementation. While I can gloss over most other warnings, the following seem to be scare tactics to me: cdrecord: Warning: Running on Linux-2.6.12-gentoo-r6 cdrecord: There are unsettled issues with Linux-2.5 and newer. cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris. Warning: Using badly designed ATAPI via /dev/hd* interface. > > Linux uname() detection code is broken since 2.6.10 because it assumes > > fixed-width fields. > > Warnings related to Linux kernel bugs Since when is a function that doesn't handle a value returned not the source of a bug? Show me the POSIX rules that say all fields returned by uname() have to have a certain fixed size. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 20:45 ` D. Hazelton @ 2006-02-20 14:59 ` Joerg Schilling 2006-02-20 18:33 ` D. Hazelton 2006-02-21 9:30 ` Matthias Andree 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-20 14:59 UTC (permalink / raw) To: schilling, dhazelton; +Cc: matthias.andree, linux-kernel "D. Hazelton" <dhazelton@enter.net> wrote: > > The namne space split is a Linux kernel bug > > Then why have I been talking about a unification with you? > > I would quote your comments on it, but since that was a private mail I will > not do so. ???? I did not get any proposal for working on making ide-scsi work nor did I get a useful proposal that would explain how it might be done without ide-scsi. > > > Bogus warnings about Linux are unfixed in said version. > > > > Warnings related to Linux kernel bugs > > From what I can tell a lot of the warnings are bogus. You even go to great > lengths to "scare" people into only using "official" versions of cdrtools. They are related to serious problems. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 14:59 ` Joerg Schilling @ 2006-02-20 18:33 ` D. Hazelton 2006-02-21 9:55 ` Joerg Schilling 2006-02-21 9:30 ` Matthias Andree 1 sibling, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-20 18:33 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Monday 20 February 2006 09:59, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > The namne space split is a Linux kernel bug > > > > Then why have I been talking about a unification with you? > > > > I would quote your comments on it, but since that was a private mail I > > will not do so. > > ???? > > I did not get any proposal for working on making ide-scsi work nor did > I get a useful proposal that would explain how it might be done without > ide-scsi. Don't even start. In a private exchange you stated that you had been thinking of mapping ATA/ATAPI devices into a "middle" bus slot to remove the need for the "ATA" and "ATAPI" host identifiers and to allow libscg to scan the ATA/ATAPI bus at the same time it scans the SCSI bus on Linux systems. I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0 - and you said it was wrong and not useful. I've since asked you in another private mail if you have another solution I could code into the patch and don't expect a reply until tomorrow. For the record, I am trying to work with you to resolve these problems, but at the moment the problem of unifying the scannign of the SCSI and ATA/ATAPI busses inside libscg in order to workaround the Kernel not providing access to ATA/ATAPI devices via /dev/sg* is stopped because of the problem of how to uniquely identify said devices and the problem with the kernel munging SCSI CDB's for certain devices is stopped because I don't have access to the hardware to see exactly what gets munged. And since you've stated that the machine on which you could reproduce the problem died 3 years ago, I have to assume that the problem may have been fixed in the ensuing time period. > > > > Bogus warnings about Linux are unfixed in said version. > > > > > > Warnings related to Linux kernel bugs > > > > From what I can tell a lot of the warnings are bogus. You even go to > > great lengths to "scare" people into only using "official" versions of > > cdrtools. > > They are related to serious problems. Really? From what I've seen you mark sections "You cannot change this" to stop people from removing those warnings. In fact, there is code in cdrecord that relates to "bugs" in distribution patched versions that most likely do not exist anymore. "Serious problems", though? Seems you just love SCSI, fell in love with ide-scsi and can't let it go. I've been using cdrecord for more than six years now, the last two on a system without _ide-scsi_ and have yet to have a problem - so either the problems you call serious are not serious enough or I was lucky to build a system from spare parts that managed to dodge all those problems. By applying Occams razor, I find that the first is likely true. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 18:33 ` D. Hazelton @ 2006-02-21 9:55 ` Joerg Schilling 2006-02-21 23:48 ` D. Hazelton 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-21 9:55 UTC (permalink / raw) To: schilling, dhazelton; +Cc: matthias.andree, linux-kernel "D. Hazelton" <dhazelton@enter.net> wrote: > > Don't even start. In a private exchange you stated that you had been thinking > of mapping ATA/ATAPI devices into a "middle" bus slot to remove the need for > the "ATA" and "ATAPI" host identifiers and to allow libscg to scan the > ATA/ATAPI bus at the same time it scans the SCSI bus on Linux systems. > > I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0 - and > you said it was wrong and not useful. I've since asked you in another private > mail if you have another solution I could code into the patch and don't > expect a reply until tomorrow. And I explained you why this is inapropriate. So what is your peoblem? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 9:55 ` Joerg Schilling @ 2006-02-21 23:48 ` D. Hazelton 2006-02-22 17:49 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-21 23:48 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Tuesday 21 February 2006 04:55, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > Don't even start. In a private exchange you stated that you had been > > thinking of mapping ATA/ATAPI devices into a "middle" bus slot to remove > > the need for the "ATA" and "ATAPI" host identifiers and to allow libscg > > to scan the ATA/ATAPI bus at the same time it scans the SCSI bus on Linux > > systems. > > > > I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0 > > - and you said it was wrong and not useful. I've since asked you in > > another private mail if you have another solution I could code into the > > patch and don't expect a reply until tomorrow. > > And I explained you why this is inapropriate. So what is your peoblem? And I asked if _you_ had a solution that I could then implement. Apparently you are no intelligent enough, or have your head too far up your ass, to understand a simple question. Goodbye, Joerg - you are now in my killfile. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 23:48 ` D. Hazelton @ 2006-02-22 17:49 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-22 17:49 UTC (permalink / raw) To: schilling, dhazelton; +Cc: matthias.andree, linux-kernel "D. Hazelton" <dhazelton@enter.net> wrote: > On Tuesday 21 February 2006 04:55, Joerg Schilling wrote: > > "D. Hazelton" <dhazelton@enter.net> wrote: > > > Don't even start. In a private exchange you stated that you had been > > > thinking of mapping ATA/ATAPI devices into a "middle" bus slot to remove > > > the need for the "ATA" and "ATAPI" host identifiers and to allow libscg > > > to scan the ATA/ATAPI bus at the same time it scans the SCSI bus on Linux > > > systems. > > > > > > I asked about using the numbers provided by Linux - ie. /dev/hda = 6,3,0 > > > - and you said it was wrong and not useful. I've since asked you in > > > another private mail if you have another solution I could code into the > > > patch and don't expect a reply until tomorrow. > > > > And I explained you why this is inapropriate. So what is your peoblem? > > And I asked if _you_ had a solution that I could then implement. Apparently And I did tell you what I was thinking off, so where is your problem? Don't you remember anymore that I did reply on 30th January to a mail from Albert Cahalan that the dirty cheap mapping is not useful? > you are no intelligent enough, or have your head too far up your ass, to > understand a simple question. Goodbye, Joerg - you are now in my killfile. So even you are just one of these trolls that are unable to have a tachical based discussion and at some time start with personal infrimngements? Tell me why I did spend so much time replying to your mail if you are not able to to what you did promise before? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 14:59 ` Joerg Schilling 2006-02-20 18:33 ` D. Hazelton @ 2006-02-21 9:30 ` Matthias Andree 1 sibling, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-21 9:30 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel Joerg Schilling schrieb am 2006-02-20: > I did not get any proposal for working on making ide-scsi work The suggestion was not to insist on it. > nor did I get a useful proposal that would explain how it might be > done without ide-scsi. The existing code works good enough for the cdrecord "consumer" of your libscg library when the scary warnings are dropped. Problems with new hardware can be fixed as use cases and hardware appear and real problems show up. Given that the Linux device layering is documented as passing unknown ioctls to lower layers to see if they can deal with them, there shouldn't be many issues. If you're unware of problems with new hardware or inventions, nobody can seriously blame you, just stuff "last found working with Linux 2.6.y" into some readme file and that's it. > > From what I can tell a lot of the warnings are bogus. You even go to great > > lengths to "scare" people into only using "official" versions of cdrtools. > > They are related to serious problems. They are related to problems that you encountered with a SUSE version ages ago, else your commentary in the code is insufficient. You ought to check once a year or once every two years if the problems you are so heftily complain about persist in supported versions; for instance, any SUSE warnings related to 8.X versions can be removed and replaced by a note that you don't intend to support operating systems that are no longer supported by their respective vendor. You don't have support contracts with distributors, so they aren't obliged to tell you "hey we fixed that bug" -- and if you asked, you'd probably get a useful answers. I'm applying the same policy to my software (no support on unsupported distributions) and it hasn't caused a single complaint yet, the only comments I received were apologies for having to use obsolete systems for some reasons, with people being rather modest and cooperative, like offering testing, accounts on those systems and so on. Pretty reasonable all in all IMO. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 18:06 ` Joerg Schilling 2006-02-16 18:14 ` Matthias Andree @ 2006-02-16 19:26 ` Edgar Toernig 2006-02-17 10:49 ` Joerg Schilling 2006-02-16 22:42 ` D. Hazelton 2 siblings, 1 reply; 439+ messages in thread From: Edgar Toernig @ 2006-02-16 19:26 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, dhazelton Joerg Schilling wrote: > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > I usually fix real bugs immediately after I know them. > > > > "Usually" is the key here. Sometimes, you refuse to fix real bugs > > forever even if you're made aware of them, and rather shift the blame > > on somebody else. > > Show me a single real bug that I did not fix. Well, the kill(getppid(), SIG_INT)s in cdda2wav still cause system reboots when run as root. Ciao, ET. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 19:26 ` Edgar Toernig @ 2006-02-17 10:49 ` Joerg Schilling 2006-02-17 13:08 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-17 10:49 UTC (permalink / raw) To: schilling, froese; +Cc: matthias.andree, linux-kernel, dhazelton Edgar Toernig <froese@gmx.de> wrote: > Joerg Schilling wrote: > > > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > > I usually fix real bugs immediately after I know them. > > > > > > "Usually" is the key here. Sometimes, you refuse to fix real bugs > > > forever even if you're made aware of them, and rather shift the blame > > > on somebody else. > > > > Show me a single real bug that I did not fix. > > Well, the kill(getppid(), SIG_INT)s in cdda2wav still cause system > reboots when run as root. Isn't this unfair? Heiko did not work on cdda2wav since ~ 2.5 years. You may have luck in the future as I received the SCCS history for cdda2wav 3 days ago, but there are other more important things to do first...... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 10:49 ` Joerg Schilling @ 2006-02-17 13:08 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-17 13:08 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-17: > > Well, the kill(getppid(), SIG_INT)s in cdda2wav still cause system > > reboots when run as root. > > Isn't this unfair? No. You asked for bugs, you got bugs. You ship cdda2wav, you take the blame. > Heiko did not work on cdda2wav since ~ 2.5 years. Does that alleviate the bug? No. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 18:06 ` Joerg Schilling 2006-02-16 18:14 ` Matthias Andree 2006-02-16 19:26 ` Edgar Toernig @ 2006-02-16 22:42 ` D. Hazelton 2006-02-17 11:41 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-16 22:42 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Thursday 16 February 2006 13:06, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > I usually fix real bugs immediately after I know them. > > > > "Usually" is the key here. Sometimes, you refuse to fix real bugs > > forever even if you're made aware of them, and rather shift the blame > > on somebody else. > > Show me a single real bug that I did not fix. At this point I, personally, am not aware of any. However, after a careful review of libscg in preparation for the patch I promised you, I can see that it would be possible for the code to be rewritten so that just the linux section contains the various workarounds that might be needed. With your refusal to even consider doing that I can see where some people get this idea (I myself was under this exact same belief until I began my code review in preparation for the proposed patch). I am unsure if you refused to provide OS specific workarounds for known bugs in order to keep the code orthogonal, or if you had another reason. But with the division of the various operating system specific pieces of libscg into seperate source files it doesn't make sense. > > > I don't see that it makes sense to archive Linux bugs as long ad the > > > Linux kernel folks are obviously not willing to fix them. > > > > Then the bugs can't have been important to you. > > ??? Id the Linux kernel is not fixed, the importance is irrelevent > unfortunately. Of the two bugs you've reported, one only exists in a deprecated and soon to be removed module. I will try to fix the other one as soon as you can provide me with enough data that I can see exactly what is getting messed up where. As to you wanting to be able to read the SCSI status byte and the actual size of the completed DMA... Those parts of the kernel are as close to a blackbox to me as any code gets. Perhaps you could provide information or ideas on how it could be managed? DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 22:42 ` D. Hazelton @ 2006-02-17 11:41 ` Joerg Schilling 2006-02-17 12:01 ` Martin Mares ` (3 more replies) 0 siblings, 4 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-17 11:41 UTC (permalink / raw) To: schilling, dhazelton; +Cc: matthias.andree, linux-kernel "D. Hazelton" <dhazelton@enter.net> wrote: > At this point I, personally, am not aware of any. However, after a careful > review of libscg in preparation for the patch I promised you, I can see that > it would be possible for the code to be rewritten so that just the linux > section contains the various workarounds that might be needed. > > With your refusal to even consider doing that I can see where some people get > this idea (I myself was under this exact same belief until I began my code > review in preparation for the proposed patch). I am not refusing useful changes but I of course refuse to apply changes that will or even may cause problems in the future. cdrtools and libscg are a serious project and are maintained in a way that tries to _plan_ all interfaces in a way that allows to upgrade interfaces for at least 10 years without a need for incompatible changes. > I am unsure if you refused to provide OS specific workarounds for known bugs > in order to keep the code orthogonal, or if you had another reason. But with > the division of the various operating system specific pieces of libscg into > seperate source files it doesn't make sense. I like to have things orthogonal, but it seems that most people in LKML do not understand implicit constraints from requiring orthogobality. > Of the two bugs you've reported, one only exists in a deprecated and soon to > be removed module. I will try to fix the other one as soon as you can provide > me with enough data that I can see exactly what is getting messed up where. Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI in a generic way is removed from Linux. If Linux does nto care about orthogonality of interfaces, this is a problem of the people who are responbile for the related interfaces. > As to you wanting to be able to read the SCSI status byte and the actual size > of the completed DMA... Those parts of the kernel are as close to a blackbox > to me as any code gets. Perhaps you could provide information or ideas on how > it could be managed? This is another construction side in Linux. In 1997, I did cleanly write dowen what exact features are missing to allow Linux to be used to _develop_ SCSI user space programs. I did even send a patch for sg.c to the Linux folks. This patch extends the sg SCSI Generic interface in a source AND binary, up AND downwards compatible way. This patch has been rejected for unknown reasons and the fact that the source code fond in official Linux release has been changed in an incompatible way, it is impossible to apply it now. My patch did enable sg.c to return more error/status information back to the user (e.g. the SCSI status byte) _and_ it defined a way to return DMA residual counts to the user. If Linux still does not even have the DMA residual count internally available, this is a proof that nobody with sufficient SCSI know how is willing to work on the Linux SCSI layer. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 11:41 ` Joerg Schilling @ 2006-02-17 12:01 ` Martin Mares 2006-02-17 13:22 ` Joerg Schilling [not found] ` <20060217083710.2dc6879e.seanlkml@sympatico.ca> ` (2 subsequent siblings) 3 siblings, 1 reply; 439+ messages in thread From: Martin Mares @ 2006-02-17 12:01 UTC (permalink / raw) To: Joerg Schilling; +Cc: dhazelton, matthias.andree, linux-kernel Hello! > Sorry, the way to access SCSI generic via /dev/hd* is deprecated. By whom? > ir removed, then a clean and orthogonal way of accessing SCSI in a generic > way is removed from Linux. If Linux does nto care about orthogonality of > interfaces, this is a problem of the people who are responbile for the related > interfaces. You open any SCSI device, you do SG_IO on it. What is non-orthogonal in that? Yes, I agree with you that it's hard to do device discovery, but discovering devices is completely orthogonal to doing I/O in them and it's also not a problem specific to SCSI devices at all. Hence we want to find a general solution suitable for *all* devices and that's what sysfs, udev and HAL are for. They might have some rough edges yet, but they definitely solve the right problem. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "In theory, practice and theory are the same, but in practice they are different." -- Larry McVoy ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 12:01 ` Martin Mares @ 2006-02-17 13:22 ` Joerg Schilling 2006-02-17 13:40 ` Martin Mares 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-17 13:22 UTC (permalink / raw) To: schilling, mj; +Cc: matthias.andree, linux-kernel, dhazelton Martin Mares <mj@ucw.cz> wrote: > > ir removed, then a clean and orthogonal way of accessing SCSI in a generic > > way is removed from Linux. If Linux does nto care about orthogonality of > > interfaces, this is a problem of the people who are responbile for the related > > interfaces. > > You open any SCSI device, you do SG_IO on it. What is non-orthogonal in that? I encourage you to read the previous mails, this has been explained for more than ten times now..... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 13:22 ` Joerg Schilling @ 2006-02-17 13:40 ` Martin Mares 0 siblings, 0 replies; 439+ messages in thread From: Martin Mares @ 2006-02-17 13:40 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, dhazelton Hello! > I encourage you to read the previous mails, this has been explained for more > than ten times now..... Maybe the problem lies in nobody except you considering it an explanation. E.g., your theory about Linux breaking POSIX has been disproved pretty quickly. Feel free to consider the Linux interface silly or badly designed, that's everybody's right, but please keep in mind that as long as you are unable to point to any *real* problems with it, it's just your opinion not shared by most of the other people, including the maintainers of the said subsystems, so it's hardly a reason for changing the interface. Sorry, but although I value your experience with CD writing very much, I don't think you are the right person to decide on what the naming of devices in Linux will look like, exactly because it's a problem with much broader context than just SCSI devices. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "God doesn't play dice." -- Albert Einstein ^ permalink raw reply [flat|nested] 439+ messages in thread
[parent not found: <20060217083710.2dc6879e.seanlkml@sympatico.ca>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <20060217083710.2dc6879e.seanlkml@sympatico.ca> @ 2006-02-17 13:37 ` sean 0 siblings, 0 replies; 439+ messages in thread From: sean @ 2006-02-17 13:37 UTC (permalink / raw) To: Joerg Schilling; +Cc: schilling, dhazelton, matthias.andree, linux-kernel On Fri, 17 Feb 2006 12:41:58 +0100 Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > In 1997, I did cleanly write dowen what exact features are missing to allow > Linux to be used to _develop_ SCSI user space programs. I did even send a patch > for sg.c to the Linux folks. This patch extends the sg SCSI Generic interface > in a source AND binary, up AND downwards compatible way. > > This patch has been rejected for unknown reasons and the fact that the source > code fond in official Linux release has been changed in an incompatible way, it > is impossible to apply it now. Shock! 1997 patch no longer applies cleanly in 2006! Alert the media! Seriously though, this is exactly why I think Linux should start accepting patches from crazy people without question or review. It's much easier to deal with whatever cruft is applied by the patch than it is to endure the multi year manic tirades of such individuals who have their egos bruised as a result of rejection. Sean ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 11:41 ` Joerg Schilling 2006-02-17 12:01 ` Martin Mares [not found] ` <20060217083710.2dc6879e.seanlkml@sympatico.ca> @ 2006-02-17 15:45 ` Jan Engelhardt 2006-02-17 21:52 ` Joerg Schilling 2006-02-17 20:02 ` D. Hazelton 3 siblings, 1 reply; 439+ messages in thread From: Jan Engelhardt @ 2006-02-17 15:45 UTC (permalink / raw) To: Joerg Schilling; +Cc: dhazelton, matthias.andree, linux-kernel >> Of the two bugs you've reported, one only exists in a deprecated and soon to >> be removed module. I will try to fix the other one as soon as you can provide >> me with enough data that I can see exactly what is getting messed up where. > >Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If ide-scsi >ir removed, then a clean and orthogonal way of accessing SCSI in a generic >way is removed from Linux. If Linux does nto care about orthogonality of >interfaces, this is a problem of the people who are responbile for the related >interfaces. > So what you want is to be able to use write() on a <sg-compatible> device rather than doing SG_IO ioctl() on <any> device? Jan Engelhardt -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 15:45 ` Jan Engelhardt @ 2006-02-17 21:52 ` Joerg Schilling 2006-02-17 23:46 ` D. Hazelton 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-17 21:52 UTC (permalink / raw) To: schilling, jengelh; +Cc: matthias.andree, linux-kernel, dhazelton Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If ide-scsi > >ir removed, then a clean and orthogonal way of accessing SCSI in a generic > >way is removed from Linux. If Linux does nto care about orthogonality of > >interfaces, this is a problem of the people who are responbile for the related > >interfaces. > > > > So what you want is to be able to use write() on a <sg-compatible> device > rather than doing SG_IO ioctl() on <any> device? This kind of disinformation is what constantly puts fuel into the fire.... Are you a victim of the firebugs in this list? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 21:52 ` Joerg Schilling @ 2006-02-17 23:46 ` D. Hazelton 0 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-17 23:46 UTC (permalink / raw) To: Joerg Schilling; +Cc: jengelh, matthias.andree, linux-kernel On Friday 17 February 2006 16:52, Joerg Schilling wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > >Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If > > > ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI > > > in a generic way is removed from Linux. If Linux does nto care about > > > orthogonality of interfaces, this is a problem of the people who are > > > responbile for the related interfaces. > > > > So what you want is to be able to use write() on a <sg-compatible> device > > rather than doing SG_IO ioctl() on <any> device? > > This kind of disinformation is what constantly puts fuel into the fire.... > > Are you a victim of the firebugs in this list? Joerg, it may not be perfect, but it does work. If you're still worried about how a few of the currently unmaintained devices still don't support SG_IO then I suggest you find someone to take maintainership. I have neither the skill nor the want to do it or I would, just to see if it quieted you down any. BTW, make it more than a couple of weeks for the patch I mentioned for libscg - I still need a response about my suggestion to use the BTL addresses Linux provides as the addresses passed around from libscg to cdrecord. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 11:41 ` Joerg Schilling ` (2 preceding siblings ...) 2006-02-17 15:45 ` Jan Engelhardt @ 2006-02-17 20:02 ` D. Hazelton 2006-02-17 18:12 ` Matthias Andree 2006-02-20 14:51 ` Joerg Schilling 3 siblings, 2 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-17 20:02 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Friday 17 February 2006 06:41, you wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > At this point I, personally, am not aware of any. However, after a > > careful review of libscg in preparation for the patch I promised you, I > > can see that it would be possible for the code to be rewritten so that > > just the linux section contains the various workarounds that might be > > needed. > > > > With your refusal to even consider doing that I can see where some people > > get this idea (I myself was under this exact same belief until I began my > > code review in preparation for the proposed patch). > > I am not refusing useful changes but I of course refuse to apply changes > that will or even may cause problems in the future. sysfs is in the kernel and I doubt the contents of /sys/block will change any. By reading that directory you can find _all_ existing ATA/ATAPI devices as well as all existing SCSI devices. As a useful change I could patch your ATA/ATAPI scanning code in libscg to do that - it would certainly clean up the code. Furthermore, as was pointed out by Albert Cahalan, Linux does provide b,t,l addresses for ATA/ATAPI devices - available from a simple stat of the device node. With him having checked a quick hack of code I tossed together to check the idea I can even provide code to you that proves this point. If you are amenable to a patch that does nothing more than fix the ATA/ATAPI scanning code on Linux so it functions properly then I will go ahead and create such. > cdrtools and libscg are a serious project and are maintained in a way that > tries to _plan_ all interfaces in a way that allows to upgrade interfaces > for at least 10 years without a need for incompatible changes. Noted. However even if I do create said patch, I'm more than 90% certain you won't even take a look at it. And if you are worried about the future of your code... Why do you use the autoconf system in such a nonstandard way? It's scripts are portable to all POSIX compliant systems. From what I have seen they would remove most of the problems you have and would allow for the code to be ported to other operating systems even faster. (Yes, I'm aware of the DOS/Windows case - but I did say all POSIX compliant systems, didn't I? Most packages provide prebuilt stuff for compiling for DOS/Windows anyway.) > > I am unsure if you refused to provide OS specific workarounds for known > > bugs in order to keep the code orthogonal, or if you had another reason. > > But with the division of the various operating system specific pieces of > > libscg into seperate source files it doesn't make sense. > > I like to have things orthogonal, but it seems that most people in LKML > do not understand implicit constraints from requiring orthogobality. This is why I'm asking why you don't include such workarounds. As far as I can see all you do in your code is complain about things with somewhat pointless warnings and do minimal work to get around the flaws you complain about. > > Of the two bugs you've reported, one only exists in a deprecated and soon > > to be removed module. I will try to fix the other one as soon as you can > > provide me with enough data that I can see exactly what is getting messed > > up where. > > Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If > ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI in a > generic way is removed from Linux. If Linux does nto care about > orthogonality of interfaces, this is a problem of the people who are > responbile for the related interfaces. Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5 series kernel - at the same time ide-scsi was deprecated access via SG_IO on /dev/hd* is the new method and not deprecated. I do agree that it would be _easier_ if Linux had tied the ATA/ATAPI transport layer into the SCSI bus code for generic SCSI access, but in Linux there is a clear distinction that exists because the IDE/ATA/ATAPI drivers can exist on the system entirely without the SCSI system even being built. The reason for this, at least to me, is to allow people building Linux kernels for embedded devices to turn off everything that isn't needed. > > As to you wanting to be able to read the SCSI status byte and the actual > > size of the completed DMA... Those parts of the kernel are as close to a > > blackbox to me as any code gets. Perhaps you could provide information or > > ideas on how it could be managed? > > This is another construction side in Linux. > > In 1997, I did cleanly write dowen what exact features are missing to allow > Linux to be used to _develop_ SCSI user space programs. I did even send a > patch for sg.c to the Linux folks. This patch extends the sg SCSI Generic > interface in a source AND binary, up AND downwards compatible way. Okay. I haven't gone through the mailing list archives to look at this patch. There are any number of reasons for it being rejected. One of them is that it got lost in the traffic on LKML. > > My patch did enable sg.c to return more error/status information back to > the user (e.g. the SCSI status byte) _and_ it defined a way to return DMA > residual counts to the user. If Linux still does not even have the DMA > residual count internally available, this is a proof that nobody with > sufficient SCSI know how is willing to work on the Linux SCSI layer. I can see how the residual DMA count information might be impossible to get at - the Linux memory allocator has been changed quite a bit over the course of the past nine years. However reading the SCSI status byte should still be possible. I have absolutely _no_ familiarity with that section of the kernel so I wont even attempt to create such a patch but you should be familiar enough with whats going on to create said patch. So, in the end, I have to ask - why don't you create that patch? DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 20:02 ` D. Hazelton @ 2006-02-17 18:12 ` Matthias Andree 2006-02-20 14:51 ` Joerg Schilling 1 sibling, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-17 18:12 UTC (permalink / raw) To: D. Hazelton; +Cc: Joerg Schilling, linux-kernel On Fri, 17 Feb 2006, D. Hazelton wrote: > Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5 > series kernel - at the same time ide-scsi was deprecated access via SG_IO > on /dev/hd* is the new method and not deprecated. This is all information that libscg does not need to know. There are only two models: 1. the old sg2 model before SG_IO was available, was to use write() and read() on a /dev/sg* node. 2. the new sg3 model is do SG_IO on any device node no matter if /dev/hd, /dev/sg or perhaps /dev/foobaz42 next year. /dev/sg* happened to be the first to implement this, others followed suit, and more to come. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 20:02 ` D. Hazelton 2006-02-17 18:12 ` Matthias Andree @ 2006-02-20 14:51 ` Joerg Schilling 2006-02-20 15:47 ` Martin Mares ` (2 more replies) 1 sibling, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-20 14:51 UTC (permalink / raw) To: schilling, dhazelton; +Cc: matthias.andree, linux-kernel "D. Hazelton" <dhazelton@enter.net> wrote: > > cdrtools and libscg are a serious project and are maintained in a way that > > tries to _plan_ all interfaces in a way that allows to upgrade interfaces > > for at least 10 years without a need for incompatible changes. > > Noted. However even if I do create said patch, I'm more than 90% certain you > won't even take a look at it. If your code will have similar relevence than the code from Matthias, you are obviously true. > Why do you use the autoconf system in such a nonstandard way? It's scripts are > portable to all POSIX compliant systems. From what I have seen they would > remove most of the problems you have and would allow for the code to be > ported to other operating systems even faster. I do use autoconf in the only senseful way. And if you did have a look at the schily makefile system you would know that it provides protability to more plaforms than you get from using an GNU autoconf the way the GNU people tell you. If you like best portability, you need to use my version of autoconf inside the schily makefile system and you need to use my smake instead of GNU make. So my conclusion is that you did not understand portability. All my software is using layered portability and if you did take a closer look at the few FSF people who know what they are talking about, you would find that e.g. Paul Eggert recently started to silently imitate my portability methods..... > (Yes, I'm aware of the DOS/Windows case - but I did say all POSIX compliant > systems, didn't I? Most packages provide prebuilt stuff for compiling for > DOS/Windows anyway.) ???? There are many problems with portability. One problem is that GNU make is not working in a useful way on many patforms that are listed to be working. GNU make is unmaintained since many years and a serious bug I reported in 1999 still has not been fixed. So for portability, I was forced to make my smake more portable than any other open source make program. The automake features (don't confuse this with the ill designed and wrongly named "automake" program from the FSF) of smake allow to compile my software on nearly any unknown platform. > > I like to have things orthogonal, but it seems that most people in LKML > > do not understand implicit constraints from requiring orthogobality. > > This is why I'm asking why you don't include such workarounds. As far as I can > see all you do in your code is complain about things with somewhat pointless > warnings and do minimal work to get around the flaws you complain about. Well what I did first was to try to have a discussion with the Linux people in order to avoid the problems introduced by Linux. When it turned out that the related people are not interested, all I could do was to print warnings. > > Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If > > ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI in a > > generic way is removed from Linux. If Linux does nto care about > > orthogonality of interfaces, this is a problem of the people who are > > responbile for the related interfaces. > > Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5 > series kernel - at the same time ide-scsi was deprecated access via SG_IO > on /dev/hd* is the new method and not deprecated. Any system that is worse than another one is deprecated. If people on LKML believe it is OK not to abide promises and if they don't have the vision that /dev/hd* only serves some limited applications but not the need of generic applications like libscg, this is a LKML problem. > I do agree that it would be _easier_ if Linux had tied the ATA/ATAPI transport > layer into the SCSI bus code for generic SCSI access, but in Linux there is a > clear distinction that exists because the IDE/ATA/ATAPI drivers can exist on > the system entirely without the SCSI system even being built. The SCSI glue layer on Solaris is less than 50 kB. I did mention more than once that a uniquely layered system could save a lot of code by avoiding to implement things more than once. > The reason for this, at least to me, is to allow people building Linux kernels > for embedded devices to turn off everything that isn't needed. Well, on such a system, a /dev/hd driver is not needed for the CD-ROM. A SCSI disk driver would be sufficient. > > My patch did enable sg.c to return more error/status information back to > > the user (e.g. the SCSI status byte) _and_ it defined a way to return DMA > > residual counts to the user. If Linux still does not even have the DMA > > residual count internally available, this is a proof that nobody with > > sufficient SCSI know how is willing to work on the Linux SCSI layer. > > I can see how the residual DMA count information might be impossible to get at > - the Linux memory allocator has been changed quite a bit over the course of > the past nine years. Most other OS provide this information. Is Linux really that underdeveloped for not being able to provide DMA residual counts? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 14:51 ` Joerg Schilling @ 2006-02-20 15:47 ` Martin Mares 2006-02-20 17:14 ` Matthias Andree 2006-02-20 18:02 ` D. Hazelton 2 siblings, 0 replies; 439+ messages in thread From: Martin Mares @ 2006-02-20 15:47 UTC (permalink / raw) To: Joerg Schilling; +Cc: dhazelton, matthias.andree, linux-kernel Hello! > The SCSI glue layer on Solaris is less than 50 kB. I did mention more than once > that a uniquely layered system could save a lot of code by avoiding to > implement things more than once. Could you please stop parrotting this again and again, at least as long as you are unable to point to any duplicated code? > Is Linux really that underdeveloped for not being able to provide DMA residual > counts? How is it related to the discussion about interfaces? So far, whenever you were asked to support your assertions (dynamic device naming violating POSIX, duplicated code, your warning which is printed when not using ide-scsi while the bugs you were speaking about occur only _with_ ide-scsi and so on), you have ignored the request and started either repeating the same or diverting the attention to completely unrelated problems (like above). Unless you wish to stop spreading your demagogy and write facts instead, I recommend you to shut up and this is my last mail in this discussion. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "This quote has been selected randomly. Really." -- M. Ulrichs ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 14:51 ` Joerg Schilling 2006-02-20 15:47 ` Martin Mares @ 2006-02-20 17:14 ` Matthias Andree 2006-02-20 18:02 ` D. Hazelton 2 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-20 17:14 UTC (permalink / raw) To: Joerg Schilling; +Cc: dhazelton, matthias.andree, linux-kernel Joerg Schilling schrieb am 2006-02-20: > > Noted. However even if I do create said patch, I'm more than 90% certain you > > won't even take a look at it. > > If your code will have similar relevence than the code from Matthias, you are > obviously true. Well, it is irrelevant to _you_ because it proves you're wrong. At least, not a single objective argument WRT bugs in side the code have surfaced. > One problem is that GNU make is not working in a useful way on many patforms > that are listed to be working. GNU make is unmaintained since many years and > a serious bug I reported in 1999 still has not been fixed. The so-called "serious" bug is a purely cosmetic complaint about non-existant .d files. > > Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the 2.5 > > series kernel - at the same time ide-scsi was deprecated access via SG_IO > > on /dev/hd* is the new method and not deprecated. > > Any system that is worse than another one is deprecated. Hm. Schilling's applications are worse than others by printing meaningless warnings... > If people on LKML believe it is OK not to abide promises and if they don't have Your delusions about who "promise"d something to you... > Well, on such a system, a /dev/hd driver is not needed for the CD-ROM. > A SCSI disk driver would be sufficient. Not your business. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 14:51 ` Joerg Schilling 2006-02-20 15:47 ` Martin Mares 2006-02-20 17:14 ` Matthias Andree @ 2006-02-20 18:02 ` D. Hazelton 2006-02-21 9:44 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-20 18:02 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Monday 20 February 2006 09:51, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > cdrtools and libscg are a serious project and are maintained in a way > > > that tries to _plan_ all interfaces in a way that allows to upgrade > > > interfaces for at least 10 years without a need for incompatible > > > changes. > > > > Noted. However even if I do create said patch, I'm more than 90% certain > > you won't even take a look at it. > > If your code will have similar relevence than the code from Matthias, you > are obviously true. > > > Why do you use the autoconf system in such a nonstandard way? It's > > scripts are portable to all POSIX compliant systems. From what I have > > seen they would remove most of the problems you have and would allow for > > the code to be ported to other operating systems even faster. > > I do use autoconf in the only senseful way. > > And if you did have a look at the schily makefile system you would know > that it provides protability to more plaforms than you get from using an > GNU autoconf the way the GNU people tell you. > > If you like best portability, you need to use my version of autoconf inside > the schily makefile system and you need to use my smake instead of GNU > make. > > So my conclusion is that you did not understand portability. All my > software is using layered portability and if you did take a closer look at > the few FSF people who know what they are talking about, you would find > that e.g. Paul Eggert recently started to silently imitate my portability > methods..... I have taken a second look and it does appear that you are correct. But I still have some doubts (none that I can quantify) - would it not make sense to also use automake? > > (Yes, I'm aware of the DOS/Windows case - but I did say all POSIX > > compliant systems, didn't I? Most packages provide prebuilt stuff for > > compiling for DOS/Windows anyway.) > > ???? There are many problems with portability. > > One problem is that GNU make is not working in a useful way on many > patforms that are listed to be working. GNU make is unmaintained since many > years and a serious bug I reported in 1999 still has not been fixed. Apparently true - the version of gmake I use is four years old. Too bad almost everything on my system relies on the quirks and features of gmake... <snip> > > > I like to have things orthogonal, but it seems that most people in LKML > > > do not understand implicit constraints from requiring orthogobality. > > > > This is why I'm asking why you don't include such workarounds. As far as > > I can see all you do in your code is complain about things with somewhat > > pointless warnings and do minimal work to get around the flaws you > > complain about. > > Well what I did first was to try to have a discussion with the Linux people > in order to avoid the problems introduced by Linux. > > When it turned out that the related people are not interested, all I could > do was to print warnings. Dodged the question there, didn't you? My question here goes unanswered. Rather than putting workarounds in your code for the bugs you complain about you've just put warnings in the code. Seems that that breaks orthagonality in favor of complaining. > > > Sorry, the way to access SCSI generic via /dev/hd* is deprecated. If > > > ide-scsi ir removed, then a clean and orthogonal way of accessing SCSI > > > in a generic way is removed from Linux. If Linux does nto care about > > > orthogonality of interfaces, this is a problem of the people who are > > > responbile for the related interfaces. > > > > Says you. Since the SCSI system via /dev/hd* was just added in, IIRC, the > > 2.5 series kernel - at the same time ide-scsi was deprecated access via > > SG_IO on /dev/hd* is the new method and not deprecated. > > Any system that is worse than another one is deprecated. It seems we have different definitions of deprecated. The definition you are using is incompatable with the definition of the word as used in software development. In software development the word means "Old and in the process of being removed from use". <snip> > > I do agree that it would be _easier_ if Linux had tied the ATA/ATAPI > > transport layer into the SCSI bus code for generic SCSI access, but in > > Linux there is a clear distinction that exists because the IDE/ATA/ATAPI > > drivers can exist on the system entirely without the SCSI system even > > being built. > > The SCSI glue layer on Solaris is less than 50 kB. I did mention more than > once that a uniquely layered system could save a lot of code by avoiding to > implement things more than once. Does that glue code comprise the proposed SATL system? Recently I've come across those whitepapers and opened a discussion about it on LKML. > > The reason for this, at least to me, is to allow people building Linux > > kernels for embedded devices to turn off everything that isn't needed. > > Well, on such a system, a /dev/hd driver is not needed for the CD-ROM. > A SCSI disk driver would be sufficient. and? The ATA/IDE drivers are more compact that requiring the _entire_ SCSI transport code and the specific SCSI driver for a device. > > > My patch did enable sg.c to return more error/status information back > > > to the user (e.g. the SCSI status byte) _and_ it defined a way to > > > return DMA residual counts to the user. If Linux still does not even > > > have the DMA residual count internally available, this is a proof that > > > nobody with sufficient SCSI know how is willing to work on the Linux > > > SCSI layer. > > > > I can see how the residual DMA count information might be impossible to > > get at - the Linux memory allocator has been changed quite a bit over the > > course of the past nine years. > > Most other OS provide this information. > > Is Linux really that underdeveloped for not being able to provide DMA > residual counts? No idea. All I said was that with the changes to how the memory allocator works I can see where it might be impossible to get such information. I don't think it is, though. What I think is that the developers of the allocator and the DMA systems just forgot to include such a capability. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 18:02 ` D. Hazelton @ 2006-02-21 9:44 ` Joerg Schilling 2006-02-21 10:16 ` Matthias Andree 2006-02-21 23:37 ` CD writing in future Linux (stirring up a hornets' nest) D. Hazelton 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-21 9:44 UTC (permalink / raw) To: schilling, dhazelton; +Cc: matthias.andree, linux-kernel "D. Hazelton" <dhazelton@enter.net> wrote: > > I do use autoconf in the only senseful way. > > > > And if you did have a look at the schily makefile system you would know > > that it provides protability to more plaforms than you get from using an > > GNU autoconf the way the GNU people tell you. > > > > If you like best portability, you need to use my version of autoconf inside > > the schily makefile system and you need to use my smake instead of GNU > > make. > > > > So my conclusion is that you did not understand portability. All my > > software is using layered portability and if you did take a closer look at > > the few FSF people who know what they are talking about, you would find > > that e.g. Paul Eggert recently started to silently imitate my portability > > methods..... > > I have taken a second look and it does appear that you are correct. But I > still have some doubts (none that I can quantify) - would it not make sense > to also use automake? The way autoconf should be used acording to the autoconf manual is already wrong and the creation of just another makefile generator, that even is incorrectly called "automake", is definitely a step into the wrong direction. David Korn recently discovered that my makefile system basically does the same as his system. But while he need to write a "make successor" "nmake", I was able to do the same using "make". The ideas that I am sucessfully using since more than 12 years is what researchers did start around 1985. GNU autoconf (used the documented way) or "automake" is trying to do things in a way that did look apropriate in the 1970s. People should look at better solutions (like my makefile system) that do not need to modify makefiles in place but rather implement object oriented design that depend on a "table like" master makefile and for this reason allow to concurrently compile on _all_ supported platforms on the same source tree in case that the tree is mounted via NFS. > > One problem is that GNU make is not working in a useful way on many > > patforms that are listed to be working. GNU make is unmaintained since many > > years and a serious bug I reported in 1999 still has not been fixed. > > Apparently true - the version of gmake I use is four years old. Too bad almost > everything on my system relies on the quirks and features of gmake... Try to use my smake to find out whether you use non-portable constructs. Smake warns you about the most common problems in makefiles. > > When it turned out that the related people are not interested, all I could > > do was to print warnings. > > Dodged the question there, didn't you? My question here goes unanswered. > Rather than putting workarounds in your code for the bugs you complain about > you've just put warnings in the code. Seems that that breaks orthagonality in > favor of complaining. The more rotten Linux interfaces become, the harder it is to implement work arounds. > > The SCSI glue layer on Solaris is less than 50 kB. I did mention more than > > once that a uniquely layered system could save a lot of code by avoiding to > > implement things more than once. > > Does that glue code comprise the proposed SATL system? Recently I've come > across those whitepapers and opened a discussion about it on LKML. ??? Solaris supports SAS decives, is this your question? > > Well, on such a system, a /dev/hd driver is not needed for the CD-ROM. > > A SCSI disk driver would be sufficient. > > and? The ATA/IDE drivers are more compact that requiring the _entire_ SCSI > transport code and the specific SCSI driver for a device. This is an unproven statement. > > > I can see how the residual DMA count information might be impossible to > > > get at - the Linux memory allocator has been changed quite a bit over the > > > course of the past nine years. > > > > Most other OS provide this information. > > > > Is Linux really that underdeveloped for not being able to provide DMA > > residual counts? > > No idea. All I said was that with the changes to how the memory allocator > works I can see where it might be impossible to get such information. I don't > think it is, though. What I think is that the developers of the allocator and > the DMA systems just forgot to include such a capability. It seems that Linux is not used for developing SCSI applications, otherwise I would not be the only person complaining about this missing feature. I am using SunOS/Solaris for my SCSI programs since 1985, so I don't have problem. It seems that Linux users don't like to know if their software fails. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 9:44 ` Joerg Schilling @ 2006-02-21 10:16 ` Matthias Andree 2006-02-21 11:01 ` Joerg Schilling 2006-02-21 23:37 ` CD writing in future Linux (stirring up a hornets' nest) D. Hazelton 1 sibling, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-21 10:16 UTC (permalink / raw) To: Joerg Schilling; +Cc: dhazelton, linux-kernel Joerg Schilling schrieb am 2006-02-21: > Try to use my smake to find out whether you use non-portable constructs. > Smake warns you about the most common problems in makefiles. To complement this, running Solaris' /usr/{ccs,xpg4}/bin/make and BSD's portable make (just bootstrap www.pkgsrc.org to obtain "bmake" on Linux) is probably a much better approach since it tests real-world make implementations rather than an artificial and not widely available local flavor. > > and? The ATA/IDE drivers are more compact that requiring the _entire_ SCSI > > transport code and the specific SCSI driver for a device. > > This is an unproven statement. Proof sketch: Compile Linux without SCSI subsystem and see if cdrecord dev=/dev/hdc still works. > It seems that Linux is not used for developing SCSI applications, otherwise > I would not be the only person complaining about this missing feature. The other scenario is that nobody but you has problems developing/porting SCSI applications to Linux, or nobody but you has problems formulating useful bug reports. Holding on to 1999 bug reports that you cannot dig up doesn't work without paid support contract, as you've seen. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 10:16 ` Matthias Andree @ 2006-02-21 11:01 ` Joerg Schilling 2006-02-21 11:46 ` [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-21 11:01 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel, dhazelton Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-21: > > > Try to use my smake to find out whether you use non-portable constructs. > > Smake warns you about the most common problems in makefiles. > > To complement this, running Solaris' /usr/{ccs,xpg4}/bin/make and BSD's > portable make (just bootstrap www.pkgsrc.org to obtain "bmake" on Linux) > is probably a much better approach since it tests real-world make > implementations rather than an artificial and not widely available local > flavor. Thank you for proving that you are completely uninformed! Smake is able to compile a _lot_ more real world applications than BSD make. This is because smake is POSIX compliant while BSD make is not. Smake is even able to compile more free software that depends on non-portable GNU make extensions than Sun make does. And smake warns about makefiles that only work because they depend on Bugs found in Sun make or GNU make (e.g. because they try to expand '$*' or '$<' in explicit target rules). Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-21 11:01 ` Joerg Schilling @ 2006-02-21 11:46 ` Matthias Andree 2006-02-22 13:36 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-21 11:46 UTC (permalink / raw) To: linux-kernel, Joerg Schilling Joerg Schilling schrieb am 2006-02-21: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > Joerg Schilling schrieb am 2006-02-21: > > > > > Try to use my smake to find out whether you use non-portable constructs. > > > Smake warns you about the most common problems in makefiles. > > > > To complement this, running Solaris' /usr/{ccs,xpg4}/bin/make and BSD's > > portable make (just bootstrap www.pkgsrc.org to obtain "bmake" on Linux) > > is probably a much better approach since it tests real-world make > > implementations rather than an artificial and not widely available local > > flavor. > > Thank you for proving that you are completely uninformed! You just proved your incapability to extract the meaning of five simple lines. If you're incapable to understand simple statements like these, shut your head. The meaning is, just especially for you so you can excuse yourself, and in PowerPoint style to be easy on your time: - run Solaris' /usr/{ccs,xpg4}/bin/make to find out if your Makefile is portable - run BSD's portable make (that's a proper name) to find out if your Makefile is portable - testing real-world make programs with Makefiles will find out much more reliably if non-portable constructs are used. Examples: smake -W -posix (version 1.2a34, the newest available) doesn't warn of include foo.d (works with said make tools, but isn't POSIX compliant), and doesn't warn of -include foo.d (works with smake, GNU make, BSD make, but not SUN make). This is pretty strong evidence that smake is insufficient as Makefile portability validator, which substantiates my recommendation to test real-world make(1) programs rather than smake to find out the portability characteristics. And now repeat your insult I were uninformed again, that's your quickest way to criminal prosecution. You said good-bye to factual discussion long ago. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-21 11:46 ` [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) Matthias Andree @ 2006-02-22 13:36 ` Joerg Schilling 2006-02-22 14:05 ` Matthias Andree 2006-02-23 8:12 ` Herbert Poetzl 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-22 13:36 UTC (permalink / raw) To: schilling, matthias.andree, linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > > Thank you for proving that you are completely uninformed! > > You just proved your incapability to extract the meaning of five simple > lines. If you're incapable to understand simple statements like these, > shut your head. You just did strengthen the impression you gave with your mail before.... although - after a long time - you at least did again make yourself busy with the topic in a mail.... > The meaning is, just especially for you so you can excuse yourself, and > in PowerPoint style to be easy on your time: > > - run Solaris' /usr/{ccs,xpg4}/bin/make > to find out if your Makefile is portable Solaris make does not write useful error messages in case of non-portable makefiles. > - run BSD's portable make (that's a proper name) > to find out if your Makefile is portable BSD make may be portable (although I am sure that smake comppiles/runs on much more platforms) but it is not POSIX compliant. The fact that a makefile does not work with BSD make does not prove anything as only simpile makefiles are handeled the same way as POSIX based make programs do. After we fixed the bug with pattern macro expansions in FreeBSDs make, it turned out that cc -o some/dir/to/file.o file.c is handled completely different from UNIX make programs. This makes it impossible to use FreeBSD make for e.g. the Schily makefilesystem. > - testing real-world make programs with Makefiles will find out much > more reliably if non-portable constructs are used. ??? smake _is_ a real world make program and if you rate POSIX compliance and portability, it will outstrip all other known make programs. > Examples: smake -W -posix (version 1.2a34, the newest available) doesn't > warn of include foo.d (works with said make tools, but isn't POSIX > compliant), and doesn't warn of -include foo.d (works with smake, GNU > make, BSD make, but not SUN make). While smake is much closer to POSIX than e.g. GNU make (proof by looking at #ifdefs related to DOS like OS <CR/NL> instead of just <NL> in the source code and find that smake has no single exception for DOS in the parser while GNU make still does not work correctly with all makefiles). But in a single point, the GNU make maintainers are correct: A POSIX make is not able to compile portable applications, so we need to make the make program portable and add features. Smake does exactly this. It adds the needed features (see "man makefiles" & "man makerules") from Sun ideas in 1986 and implements them in a portable way. The needed features are pattern matching expansion and "include". > This is pretty strong evidence that smake is insufficient as > Makefile portability validator, which substantiates my recommendation to > test real-world make(1) programs rather than smake to find out the > portability characteristics. The other make programs I know are worse then smake and they are usually not portable themself. Note that I don't like to use the technology from the 1970s as GNU "automake" does. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-22 13:36 ` Joerg Schilling @ 2006-02-22 14:05 ` Matthias Andree 2006-02-23 12:15 ` Joerg Schilling 2006-02-23 8:12 ` Herbert Poetzl 1 sibling, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-22 14:05 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel Joerg Schilling schrieb am 2006-02-22: > > - run Solaris' /usr/{ccs,xpg4}/bin/make > > to find out if your Makefile is portable > > Solaris make does not write useful error messages in case of non-portable > makefiles. Sun Microsystems do not advertise their make tool as Makefile portability validator. Note the difference: each tool is held to its own standards. > > - run BSD's portable make (that's a proper name) > > to find out if your Makefile is portable > > BSD make may be portable (although I am sure that smake comppiles/runs > on much more platforms) but it is not POSIX compliant. Please look up the term "proper name" before continuing. BSD make does not mention "POSIX" a single time in its documentation. > After we fixed the bug with pattern macro expansions in FreeBSDs make, > it turned out that cc -o some/dir/to/file.o file.c is handled completely > different from UNIX make programs. This makes it impossible to use FreeBSD > make for e.g. the Schily makefilesystem. If BSD make is not UNIX make, then what is? That FreeBSD's /usr/bin/make doesn't like your Makefiles doesn't matter, GNU and Schily make are available in the ports collection, either is fine. > > - testing real-world make programs with Makefiles will find out much > > more reliably if non-portable constructs are used. > > ??? smake _is_ a real world make program and if you rate POSIX compliance > and portability, it will outstrip all other known make programs. You still haven't got my point. Last attempt to explain: smake isn't sufficient to judge if a "Makefile" is portable to all widespread make programs, particularly does it not warn about non-POSIX syntax that SUN make or BSD make reject, as shown in my previous message. > > This is pretty strong evidence that smake is insufficient as > > Makefile portability validator, which substantiates my recommendation to > > test real-world make(1) programs rather than smake to find out the > > portability characteristics. > > The other make programs I know are worse then smake and they are usually not > portable themself. Note that I don't like to use the technology from the 1970s > as GNU "automake" does. Your dislike for GNU make is widely documented, yet only based on cosmetic bugs. Try if the "remake" guys fix the concerns you have had about GNU make. remake is a GNU make spinoff with usability improvements, getting rid of meaningless "Makefile:5: foo.d: No such file or directory" should be well within reach. Dig through your sent-mail folder for the explanation you sent me a year or two ago. See <http://bashdb.sourceforge.net/remake/> I'm redirecting answers off-list. This isn't linux-kernel stuff any more. BTW, your Message-ID is nonconformant (it doesn't use a qualified domain name, "burner" isn't appropriate), please fix your mailer. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-22 14:05 ` Matthias Andree @ 2006-02-23 12:15 ` Joerg Schilling 2006-02-23 14:57 ` Matthias Andree 2006-02-23 15:42 ` D. Hazelton 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-23 12:15 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-22: > > > > - run Solaris' /usr/{ccs,xpg4}/bin/make > > > to find out if your Makefile is portable > > > > Solaris make does not write useful error messages in case of non-portable > > makefiles. > > Sun Microsystems do not advertise their make tool as Makefile > portability validator. Note the difference: each tool is held to its > own standards. I do not advertize smake as makefile validator either. It would help a lot, if people on LKML would not repeatedly impute me things I never said.... Smake helps to find non-portable code, this is something completely different! Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 12:15 ` Joerg Schilling @ 2006-02-23 14:57 ` Matthias Andree 2006-02-23 16:49 ` Joerg Schilling 2006-02-23 15:42 ` D. Hazelton 1 sibling, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-23 14:57 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-23: > I do not advertize smake as makefile validator either. In your message from Monday 10:44 Central European Time you advertise smake as warning about most non-portable constructs... -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 14:57 ` Matthias Andree @ 2006-02-23 16:49 ` Joerg Schilling 2006-02-23 17:16 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-23 16:49 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-23: > > > I do not advertize smake as makefile validator either. > > In your message from Monday 10:44 Central European Time you advertise > smake as warning about most non-portable constructs... So you read the correct text and still try to reverse it? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 16:49 ` Joerg Schilling @ 2006-02-23 17:16 ` Matthias Andree 2006-02-24 10:04 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-23 17:16 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel Joerg Schilling schrieb am 2006-02-23: > So you read the correct text and still try to reverse it? No. You advertised smake in spite of my recommendation to test Makefiles with real-world make implementations, and now you're ranting about a particular make implementation. 1. Stick to the topic please. 2. Stop Cc:ing me on this topic, I'm not interested in discussing make programs beyond showing that smake isn't up to its own standards, and that I already did. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 17:16 ` Matthias Andree @ 2006-02-24 10:04 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-24 10:04 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: matthias.andree, linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-23: > > > So you read the correct text and still try to reverse it? > > No. You advertised smake in spite of my recommendation to test Makefiles > with real-world make implementations, and now you're ranting about a > particular make implementation. So you still read the correct text and try to reverse it? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 12:15 ` Joerg Schilling 2006-02-23 14:57 ` Matthias Andree @ 2006-02-23 15:42 ` D. Hazelton 2006-02-23 16:56 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-23 15:42 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Thursday 23 February 2006 07:15, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > Joerg Schilling schrieb am 2006-02-22: > > > > - run Solaris' /usr/{ccs,xpg4}/bin/make > > > > to find out if your Makefile is portable > > > > > > Solaris make does not write useful error messages in case of > > > non-portable makefiles. > > > > Sun Microsystems do not advertise their make tool as Makefile > > portability validator. Note the difference: each tool is held to its > > own standards. > > I do not advertize smake as makefile validator either. > > It would help a lot, if people on LKML would not repeatedly impute me > things I never said.... > > > Smake helps to find non-portable code, this is something completely > different! Umm - Joerg, you just stepped on your own toes there. A makefile validator does exactly that - helps people find non-portable code. You're fighting a losing battle when you claim one thing then say something that proves it false. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 15:42 ` D. Hazelton @ 2006-02-23 16:56 ` Joerg Schilling 2006-02-23 20:36 ` D. Hazelton 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-23 16:56 UTC (permalink / raw) To: schilling, dhazelton; +Cc: matthias.andree, linux-kernel "D. Hazelton" <dhazelton@enter.net> wrote: > > Smake helps to find non-portable code, this is something completely > > different! > > Umm - Joerg, you just stepped on your own toes there. A makefile validator > does exactly that - helps people find non-portable code. You're fighting a > losing battle when you claim one thing then say something that proves it > false. Wrong: a CD box with Suse or Redhat Linux may act as a door stop. Does this make it a doorstop? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 16:56 ` Joerg Schilling @ 2006-02-23 20:36 ` D. Hazelton 0 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-23 20:36 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Thursday 23 February 2006 11:56, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > Smake helps to find non-portable code, this is something completely > > > different! > > > > Umm - Joerg, you just stepped on your own toes there. A makefile > > validator does exactly that - helps people find non-portable code. You're > > fighting a losing battle when you claim one thing then say something that > > proves it false. > > Wrong: a CD box with Suse or Redhat Linux may act as a door stop. > > Does this make it a doorstop? If you decide to use it as such, yes. I have actually done such in the past, since I needed to find some use for the box once the media was removed. And anyway, you did state, as pointed out by someone else, that "smake may be used as a Makefile validator" Since you advertise such a fact - that it works as a Makefile validator - does that not make it such? I realize you'll just deny it and don't know why I bother even looking in the folder your mails get sorted into. Maybe I just have a masochistic streak... DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-22 13:36 ` Joerg Schilling 2006-02-22 14:05 ` Matthias Andree @ 2006-02-23 8:12 ` Herbert Poetzl 2006-02-23 13:04 ` linux-os (Dick Johnson) 2006-02-23 15:48 ` Joerg Schilling 1 sibling, 2 replies; 439+ messages in thread From: Herbert Poetzl @ 2006-02-23 8:12 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote: > ??? smake _is_ a real world make program and if you rate POSIX compliance > and portability, it will outstrip all other known make programs. does anybody (except for the author, of course) use smake for building their stuff? just curious .. best, Herbert ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 8:12 ` Herbert Poetzl @ 2006-02-23 13:04 ` linux-os (Dick Johnson) 2006-02-23 16:35 ` Joerg Schilling 2006-02-23 15:48 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: linux-os (Dick Johnson) @ 2006-02-23 13:04 UTC (permalink / raw) To: Herbert Poetzl; +Cc: Joerg Schilling, matthias.andree, linux-kernel On Thu, 23 Feb 2006, Herbert Poetzl wrote: > On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote: >> ??? smake _is_ a real world make program and if you rate POSIX compliance >> and portability, it will outstrip all other known make programs. > > does anybody (except for the author, of course) use > smake for building their stuff? just curious .. > > best, > Herbert The author wrote it so he is likely to use it. It claims to have compatible make-files so the source-code tree should be just fine. I don't know who would waste their time making another 'make' program, but I guess the author of smake has lots of time on his hands! Cheers, Dick Johnson Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips). Warning : 98.36% of all statistics are fiction. _ \x1a\x04 **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 13:04 ` linux-os (Dick Johnson) @ 2006-02-23 16:35 ` Joerg Schilling 2006-02-23 16:42 ` Herbert Poetzl 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-23 16:35 UTC (permalink / raw) To: linux-os, herbert; +Cc: schilling, matthias.andree, linux-kernel "linux-os \(Dick Johnson\)" <linux-os@analogic.com> wrote: > > I don't know who would waste their time making another 'make' > program, but I guess the author of smake has lots of time > on his hands! Who would waste his time with something like GNU make that is unmaintained since more than 6 years? If I need a bugfix in smake, I can do this in a few hours. This is impossible with GNU make.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 16:35 ` Joerg Schilling @ 2006-02-23 16:42 ` Herbert Poetzl 2006-02-23 17:01 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Herbert Poetzl @ 2006-02-23 16:42 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-os, matthias.andree, linux-kernel On Thu, Feb 23, 2006 at 05:35:07PM +0100, Joerg Schilling wrote: > "linux-os \(Dick Johnson\)" <linux-os@analogic.com> wrote: > > > > > I don't know who would waste their time making another 'make' > > program, but I guess the author of smake has lots of time > > on his hands! > > Who would waste his time with something like GNU make that is > unmaintained since more than 6 years? > > If I need a bugfix in smake, I can do this in a few hours. > This is impossible with GNU make.... just tried with GNU make, did work here within minutes :) best, Herbert > Jörg > > -- > EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin > js@cs.tu-berlin.de (uni) > schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 16:42 ` Herbert Poetzl @ 2006-02-23 17:01 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-23 17:01 UTC (permalink / raw) To: schilling, herbert; +Cc: matthias.andree, linux-os, linux-kernel Herbert Poetzl <herbert@13thfloor.at> wrote: > > Who would waste his time with something like GNU make that is > > unmaintained since more than 6 years? > > > > If I need a bugfix in smake, I can do this in a few hours. > > This is impossible with GNU make.... > > just tried with GNU make, did work here within minutes :) If you can fix things in GNU make within minutes, please fix the bug that causes GNU make to complain about missing include files. This is a self non-compliance as GNU make applies all so far known rules on any other object before trying to use them (e.g. try to check out Makefile from SCCS before complaining that Makefiles is missing). If you need the correct algorithm, look into the smake source... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 8:12 ` Herbert Poetzl 2006-02-23 13:04 ` linux-os (Dick Johnson) @ 2006-02-23 15:48 ` Joerg Schilling 2006-02-23 16:02 ` Tim Walberg 1 sibling, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-23 15:48 UTC (permalink / raw) To: schilling, herbert; +Cc: matthias.andree, linux-kernel Herbert Poetzl <herbert@13thfloor.at> wrote: > On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote: > > ??? smake _is_ a real world make program and if you rate POSIX compliance > > and portability, it will outstrip all other known make programs. > > does anybody (except for the author, of course) use > smake for building their stuff? just curious .. Many people use smake on platforms where there is no other sufficiently compliant make program. As GNU make incorrectly states to run on many plaforms, there are a lot of people who suffer from the fact that GNU make is not maintained since > 6 years. Note that I did make bug reports against GNU make that have been accepted as bugs but never fixed! Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 15:48 ` Joerg Schilling @ 2006-02-23 16:02 ` Tim Walberg 2006-02-23 16:57 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Tim Walberg @ 2006-02-23 16:02 UTC (permalink / raw) To: Joerg Schilling; +Cc: herbert, matthias.andree, linux-kernel On 02/23/2006 16:48 +0100, Joerg Schilling wrote: >> Herbert Poetzl <herbert@13thfloor.at> wrote: >> >> > On Wed, Feb 22, 2006 at 02:36:01PM +0100, Joerg Schilling wrote: >> > > ??? smake _is_ a real world make program and if you rate POSIX compliance >> > > and portability, it will outstrip all other known make programs. >> > >> > does anybody (except for the author, of course) use >> > smake for building their stuff? just curious .. >> >> Many people use smake on platforms where there is no other >> sufficiently compliant make program. >> >> As GNU make incorrectly states to run on many plaforms, there are >> a lot of people who suffer from the fact that GNU make is not maintained >> since > 6 years. >> Hmmm... from the GNU Make web page: Version 3.80 (stable) released on 2002-10-04 00:00:00.000 Seems to me that's slightly less than 6 years, but then I was never that great at math... Maybe I missed something.... -- twalberg@mindspring.com ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 16:02 ` Tim Walberg @ 2006-02-23 16:57 ` Joerg Schilling 2006-02-23 17:23 ` Tim Walberg 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-23 16:57 UTC (permalink / raw) To: twalberg, schilling; +Cc: matthias.andree, linux-kernel, herbert Tim Walberg <twalberg@mindspring.com> wrote: > > Hmmm... from the GNU Make web page: > > Version 3.80 (stable) released on 2002-10-04 00:00:00.000 > > Seems to me that's slightly less than 6 years, but then I was never > that great at math... Maybe I missed something.... And why are the accepted bugs from 1999 not yet fixed? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 16:57 ` Joerg Schilling @ 2006-02-23 17:23 ` Tim Walberg 2006-02-23 17:32 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Tim Walberg @ 2006-02-23 17:23 UTC (permalink / raw) To: Joerg Schilling; +Cc: twalberg, matthias.andree, linux-kernel, herbert On 02/23/2006 17:57 +0100, Joerg Schilling wrote: >> Tim Walberg <twalberg@mindspring.com> wrote: >> >> > >> > Hmmm... from the GNU Make web page: >> > >> > Version 3.80 (stable) released on 2002-10-04 00:00:00.000 >> > >> > Seems to me that's slightly less than 6 years, but then I was never >> > that great at math... Maybe I missed something.... >> >> And why are the accepted bugs from 1999 not yet fixed? >> 'accepted "bugs" not being fixed' is not equivalent to 'package is not being maintained'... at least not in my admittedly meager grasp of logic... -- twalberg@mindspring.com ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 17:23 ` Tim Walberg @ 2006-02-23 17:32 ` Joerg Schilling 2006-02-23 17:53 ` Tim Walberg 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-23 17:32 UTC (permalink / raw) To: twalberg, schilling; +Cc: twalberg, matthias.andree, linux-kernel, herbert Tim Walberg <twalberg@mindspring.com> wrote: > >> > Hmmm... from the GNU Make web page: > >> > > >> > Version 3.80 (stable) released on 2002-10-04 00:00:00.000 > >> > > >> > Seems to me that's slightly less than 6 years, but then I was never > >> > that great at math... Maybe I missed something.... > >> > >> And why are the accepted bugs from 1999 not yet fixed? > >> > > 'accepted "bugs" not being fixed' is not equivalent to 'package is > not being maintained'... at least not in my admittedly meager grasp > of logic... They told me that fixing would take "a while". If you believe that "a while" is 20 years, then you seem to live in a different universe then I do. A ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 17:32 ` Joerg Schilling @ 2006-02-23 17:53 ` Tim Walberg 2006-02-24 7:08 ` Jan Engelhardt 2006-02-24 10:09 ` Joerg Schilling 0 siblings, 2 replies; 439+ messages in thread From: Tim Walberg @ 2006-02-23 17:53 UTC (permalink / raw) To: Joerg Schilling; +Cc: twalberg, linux-kernel On 02/23/2006 18:32 +0100, Joerg Schilling wrote: >> Tim Walberg <twalberg@mindspring.com> wrote: >> >> > >> > Hmmm... from the GNU Make web page: >> > >> > >> > >> > Version 3.80 (stable) released on 2002-10-04 00:00:00.000 >> > >> > >> > >> > Seems to me that's slightly less than 6 years, but then I was never >> > >> > that great at math... Maybe I missed something.... >> > >> >> > >> And why are the accepted bugs from 1999 not yet fixed? >> > >> >> > >> > 'accepted "bugs" not being fixed' is not equivalent to 'package is >> > not being maintained'... at least not in my admittedly meager grasp >> > of logic... >> >> They told me that fixing would take "a while". If you believe that >> "a while" is 20 years, then you seem to live in a different universe then I do. >> Indeed... I had already concluded that. It now seems that in your universe, the time span between 1999 and 2006 is on the order of 20 years, which seems to be a factor of nearly 3 over what it is in my universe (either that, or it's not 2006 where you are, but rather 2019...). -- twalberg@mindspring.com ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 17:53 ` Tim Walberg @ 2006-02-24 7:08 ` Jan Engelhardt 2006-02-24 10:09 ` Joerg Schilling 1 sibling, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-24 7:08 UTC (permalink / raw) To: Tim Walberg; +Cc: Joerg Schilling, linux-kernel >>> They told me that fixing would take "a while". If you believe that >>> "a while" is 20 years, then you seem to live in a different universe then I do. > >Indeed... I had already concluded that. It now seems that in >your universe, the time span between 1999 and 2006 is on >the order of 20 years, which seems to be a factor of nearly >3 over what it is in my universe (either that, or it's not >2006 where you are, but rather 2019...). > <sarcasm>That explains why Solaris is so much better.</sarcasm> But when Linux gets to 2019, it will rule compared to the current Solaris 2019. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-23 17:53 ` Tim Walberg 2006-02-24 7:08 ` Jan Engelhardt @ 2006-02-24 10:09 ` Joerg Schilling 2006-02-25 17:44 ` David Weinehall 1 sibling, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-24 10:09 UTC (permalink / raw) To: twalberg, schilling; +Cc: twalberg, linux-kernel Tim Walberg <twalberg@mindspring.com> wrote: > >> > 'accepted "bugs" not being fixed' is not equivalent to 'package is > >> > not being maintained'... at least not in my admittedly meager grasp > >> > of logic... > >> > >> They told me that fixing would take "a while". If you believe that > >> "a while" is 20 years, then you seem to live in a different universe then I do. > >> > > Indeed... I had already concluded that. It now seems that in > your universe, the time span between 1999 and 2006 is on > the order of 20 years, which seems to be a factor of nearly > 3 over what it is in my universe (either that, or it's not > 2006 where you are, but rather 2019...). I don't know in which universe you live, but in my universe software that does not fix severe bugs after 7 years or does not publish a new version at least every 2-3 years is called deas and unmaintained. Both applies to GNU make. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-24 10:09 ` Joerg Schilling @ 2006-02-25 17:44 ` David Weinehall 2006-02-28 7:24 ` David Weinehall 0 siblings, 1 reply; 439+ messages in thread From: David Weinehall @ 2006-02-25 17:44 UTC (permalink / raw) To: Joerg Schilling; +Cc: twalberg, linux-kernel On Fri, Feb 24, 2006 at 11:09:39AM +0100, Joerg Schilling wrote: > Tim Walberg <twalberg@mindspring.com> wrote: > > > >> > 'accepted "bugs" not being fixed' is not equivalent to 'package is > > >> > not being maintained'... at least not in my admittedly meager grasp > > >> > of logic... > > >> > > >> They told me that fixing would take "a while". If you believe that > > >> "a while" is 20 years, then you seem to live in a different universe then I do. > > >> > > > > Indeed... I had already concluded that. It now seems that in > > your universe, the time span between 1999 and 2006 is on > > the order of 20 years, which seems to be a factor of nearly > > 3 over what it is in my universe (either that, or it's not > > 2006 where you are, but rather 2019...). > > I don't know in which universe you live, but in my universe software > that does not fix severe bugs after 7 years or does not publish a new > version at least every 2-3 years is called deas and unmaintained. Both > applies to GNU make. Uhm, the version of GNU make in Debian (3.81beta4) was released 12 December 2005; I wouldn't call that dead (or unmaintained). Regards: David Weinehall -- /) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/ (/ Full colour fire (/ ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-25 17:44 ` David Weinehall @ 2006-02-28 7:24 ` David Weinehall 2006-02-28 18:47 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: David Weinehall @ 2006-02-28 7:24 UTC (permalink / raw) To: Joerg Schilling, twalberg, linux-kernel On Sat, Feb 25, 2006 at 06:44:10PM +0100, David Weinehall wrote: > On Fri, Feb 24, 2006 at 11:09:39AM +0100, Joerg Schilling wrote: > > Tim Walberg <twalberg@mindspring.com> wrote: > > > > > >> > 'accepted "bugs" not being fixed' is not equivalent to 'package is > > > >> > not being maintained'... at least not in my admittedly meager grasp > > > >> > of logic... > > > >> > > > >> They told me that fixing would take "a while". If you believe that > > > >> "a while" is 20 years, then you seem to live in a different universe then I do. > > > >> > > > > > > Indeed... I had already concluded that. It now seems that in > > > your universe, the time span between 1999 and 2006 is on > > > the order of 20 years, which seems to be a factor of nearly > > > 3 over what it is in my universe (either that, or it's not > > > 2006 where you are, but rather 2019...). > > > > I don't know in which universe you live, but in my universe software > > that does not fix severe bugs after 7 years or does not publish a new > > version at least every 2-3 years is called deas and unmaintained. Both > > applies to GNU make. > > Uhm, the version of GNU make in Debian (3.81beta4) was released > 12 December 2005; I wouldn't call that dead (or unmaintained). Oh, and as an update, 3.81rc1 was release on the 19th of February 2006. Yeah, very unmaintained and dead upstream... Regards: David -- /) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/ (/ Full colour fire (/ ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-28 7:24 ` David Weinehall @ 2006-02-28 18:47 ` Joerg Schilling 2006-02-28 19:49 ` Sam Vilain 2006-02-28 20:01 ` David Weinehall 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-28 18:47 UTC (permalink / raw) To: twalberg, tao, schilling, linux-kernel David Weinehall <tao@acc.umu.se> wrote: > > Uhm, the version of GNU make in Debian (3.81beta4) was released > > 12 December 2005; I wouldn't call that dead (or unmaintained). > > Oh, and as an update, 3.81rc1 was release on the 19th of February 2006. > > Yeah, very unmaintained and dead upstream... None of the bugs I did report has been fixed. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-28 18:47 ` Joerg Schilling @ 2006-02-28 19:49 ` Sam Vilain 2006-02-28 20:01 ` David Weinehall 1 sibling, 0 replies; 439+ messages in thread From: Sam Vilain @ 2006-02-28 19:49 UTC (permalink / raw) To: Joerg Schilling; +Cc: twalberg, tao, linux-kernel Joerg Schilling wrote: >>>Uhm, the version of GNU make in Debian (3.81beta4) was released >>>12 December 2005; I wouldn't call that dead (or unmaintained). >>Oh, and as an update, 3.81rc1 was release on the 19th of February 2006. >>Yeah, very unmaintained and dead upstream... > None of the bugs I did report has been fixed. Just because a project doesn't fix every bug does not mean it is dead. That aside, are your bugs listed on http://savannah.gnu.org/bugs/?group=make ? Sam. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-28 18:47 ` Joerg Schilling 2006-02-28 19:49 ` Sam Vilain @ 2006-02-28 20:01 ` David Weinehall 2006-02-28 20:53 ` Sam Vilain 2006-03-01 16:17 ` Joerg Schilling 1 sibling, 2 replies; 439+ messages in thread From: David Weinehall @ 2006-02-28 20:01 UTC (permalink / raw) To: Joerg Schilling; +Cc: twalberg, linux-kernel On Tue, Feb 28, 2006 at 07:47:58PM +0100, Joerg Schilling wrote: > David Weinehall <tao@acc.umu.se> wrote: > > > > Uhm, the version of GNU make in Debian (3.81beta4) was released > > > 12 December 2005; I wouldn't call that dead (or unmaintained). > > > > Oh, and as an update, 3.81rc1 was release on the 19th of February 2006. > > > > Yeah, very unmaintained and dead upstream... > > None of the bugs I did report has been fixed. Well, the bug you complain most about is about spewing of some warnings for something completely harmless. I know of another certain set of software that spews unnecessary and annoying warnings. Those haven't been removed for despite complaints for several years either. Does this mean that cdrecord is an unmaintained piece of software that's dead upstream? Regards: David Weinehall -- /) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/ (/ Full colour fire (/ ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-28 20:01 ` David Weinehall @ 2006-02-28 20:53 ` Sam Vilain 2006-03-01 16:17 ` Joerg Schilling 1 sibling, 0 replies; 439+ messages in thread From: Sam Vilain @ 2006-02-28 20:53 UTC (permalink / raw) To: David Weinehall; +Cc: twalberg, Linux Kernel Mailing List David Weinehall wrote: >>>>12 December 2005; I wouldn't call that dead (or unmaintained). >>>Oh, and as an update, 3.81rc1 was release on the 19th of February 2006. >>>Yeah, very unmaintained and dead upstream... >>None of the bugs I did report has been fixed. > Well, the bug you complain most about is about spewing of some > warnings for something completely harmless. I know of another > certain set of software that spews unnecessary and annoying > warnings. Those haven't been removed for despite complaints for > several years either. Does this mean that cdrecord is an unmaintained > piece of software that's dead upstream? This "cdrecord" package doesn't even support recording DVDs! DVD writers have been around for so long, and the technology is so similar you would think that the author would implement the feature. The users sure must be asking for it. However it still seems to be being updated but not co-operating with the community or releasing new important features ... looks like we've got a piece of software that's UNdead upstream. Sam. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-02-28 20:01 ` David Weinehall 2006-02-28 20:53 ` Sam Vilain @ 2006-03-01 16:17 ` Joerg Schilling 2006-03-01 17:39 ` Matthias Andree 1 sibling, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-03-01 16:17 UTC (permalink / raw) To: tao, schilling; +Cc: twalberg, linux-kernel David Weinehall <tao@acc.umu.se> wrote: > On Tue, Feb 28, 2006 at 07:47:58PM +0100, Joerg Schilling wrote: > > David Weinehall <tao@acc.umu.se> wrote: > > > > > > Uhm, the version of GNU make in Debian (3.81beta4) was released > > > > 12 December 2005; I wouldn't call that dead (or unmaintained). > > > > > > Oh, and as an update, 3.81rc1 was release on the 19th of February 2006. > > > > > > Yeah, very unmaintained and dead upstream... > > > > None of the bugs I did report has been fixed. > > Well, the bug you complain most about is about spewing of some > warnings for something completely harmless. I know of another > certain set of software that spews unnecessary and annoying > warnings. Those haven't been removed for despite complaints for > several years either. Does this mean that cdrecord is an unmaintained > piece of software that's dead upstream? If you do not understand the diffeence between a useful warning (as with cdrecord) and a warning that is a result of a severe bug caused by incorrect make file handling (as in GNU make) you are obviously wrong here. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) 2006-03-01 16:17 ` Joerg Schilling @ 2006-03-01 17:39 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-03-01 17:39 UTC (permalink / raw) To: Joerg Schilling; +Cc: tao, twalberg, linux-kernel Joerg Schilling schrieb am 2006-03-01: > If you do not understand the diffeence between a useful warning (as with > cdrecord) and a warning that is a result of a severe bug caused by incorrect > make file handling (as in GNU make) you are obviously wrong here. Continued offenses, rather than substantiating your claims. This cosmetic GNU make bug that you've been ranting about for years, which isn't a warning, has not, to my knowledge, caused any code to be miscompiled. If you think otherwise, then you'll need to provide the GNU make maintainers with such information so they are aware of the severity. However, until you can substantiate your claims, it's just Schilling's usually offensive ranting and not a make "bug". Besides that, you can just use "-include" to suppress the message. It even works in smake and BSD make ... -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 9:44 ` Joerg Schilling 2006-02-21 10:16 ` Matthias Andree @ 2006-02-21 23:37 ` D. Hazelton 2006-02-22 17:13 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-21 23:37 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On Tuesday 21 February 2006 04:44, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > I do use autoconf in the only senseful way. > > > <snip> > > > The SCSI glue layer on Solaris is less than 50 kB. I did mention more > > > than once that a uniquely layered system could save a lot of code by > > > avoiding to implement things more than once. > > > > Does that glue code comprise the proposed SATL system? Recently I've come > > across those whitepapers and opened a discussion about it on LKML. > > ??? Solaris supports SAS decives, is this your question? SAS? No. To quote you quite frequently - RTFM. SATL is an entire system, similar to the old ide-scsi module, that sits on top of the SCSI and ATA interfaces and provides the capacity to access any disk device on the system using SCSI commands. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 23:37 ` CD writing in future Linux (stirring up a hornets' nest) D. Hazelton @ 2006-02-22 17:13 ` Joerg Schilling 2006-02-22 17:30 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-22 17:13 UTC (permalink / raw) To: schilling, dhazelton; +Cc: matthias.andree, linux-kernel "D. Hazelton" <dhazelton@enter.net> wrote: > > > Does that glue code comprise the proposed SATL system? Recently I've come > > > across those whitepapers and opened a discussion about it on LKML. > > > > ??? Solaris supports SAS decives, is this your question? > > SAS? No. To quote you quite frequently - RTFM. SATL is an entire system, Please read again your text I was responding to..... It was Solaris related and you did not mention Linux here. > similar to the old ide-scsi module, that sits on top of the SCSI and ATA > interfaces and provides the capacity to access any disk device on the system > using SCSI commands. If this is a ide-scsi replacement, everything would be fine. When is it available? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-22 17:13 ` Joerg Schilling @ 2006-02-22 17:30 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-22 17:30 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel Joerg Schilling schrieb am 2006-02-22: > "D. Hazelton" <dhazelton@enter.net> wrote: > > similar to the old ide-scsi module, that sits on top of the SCSI and ATA > > interfaces and provides the capacity to access any disk device on the system > > using SCSI commands. > > If this is a ide-scsi replacement, everything would be fine. That doesn't matter: your policy is to support older kernels, and by the time it will become available there will still be 2.6.13, .14, .15 kernels around that don't have SAT, so you will need to have code that works well with 2.6.15 anyhow if you are to comply with your own intentions. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:36 ` Joerg Schilling [not found] ` <20060213104548.2999033d.seanlkml@sympatico.ca> 2006-02-13 16:10 ` Martin Mares @ 2006-02-13 16:13 ` Matthias Andree 2 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-13 16:13 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-13: > So you like to prove that it makes not sense to talk to LKML people? Wrong. It does not make sense to keep talking about issues that were refused, such as providing stable b,t,l device mapping, or violating layering requirements that you are so fond of. Such a violation might be making libscg the core and arranging the kernel around it. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:29 ` Joerg Schilling 2006-02-13 14:57 ` Matthias Andree [not found] ` <20060213095038.03247484.seanlkml@sympatico.ca> @ 2006-02-13 23:18 ` D. Hazelton 2006-02-14 13:39 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: D. Hazelton @ 2006-02-13 23:18 UTC (permalink / raw) To: Joerg Schilling Cc: sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh On Monday 13 February 2006 09:29, Joerg Schilling wrote: > Sam Vilain <sam@vilain.net> wrote: > > Joerg Schilling wrote: > > >> My system is clueless, too! If I write a CD before plugging my > > >>USB storage device, my CD writer is on 0,0,0. If I plug my USB > > >>storage device *before* doing any access, my cdwriter is on 1,0,0. > > >>Pretty stable. > > > > > > You are referring to a conceptional problem in the Linux kernel. > > > If you are unhappy with this, send a bug report to the related > > > people. > > > This does not belong to libscg. > > > > Jörg, > > > > Technically, you may have a point[*1*]. > > > > However, no matter how correct someone is, if they act like a complete > > dork, they're not going to be listened to. > > This is why I have less and less intrest in listening to most of the > people who are around here. > > They are either technically uninformed, personal offensive or obviously > not interested in a solution. Joerg, if anyone involved in this entire discussion can be accused of being personally offensive, it's you. As to "technically uninformed" remember, you are still human and there is always someone smarter. I've seen that "technically uninformed" line used by to many people who didn't want to change their viewpoint. And you seem to have missed the point here - he was giving you a hint that you should at least try to be civil. I have limited capacity for that myself when dealing with people that have offended me, but I am trying to keep a civil tone in these communications nonetheless. DRH ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 23:18 ` D. Hazelton @ 2006-02-14 13:39 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-14 13:39 UTC (permalink / raw) To: schilling, dhazelton Cc: sam, peter.read, mj, matthias.andree, lkml, linux-kernel, jim, jengelh "D. Hazelton" <dhazelton@enter.net> wrote: > And you seem to have missed the point here - he was giving you a hint that you > should at least try to be civil. I have limited capacity for that myself when > dealing with people that have offended me, but I am trying to keep a civil > tone in these communications nonetheless. I am just trying to follow the "rules" on this list, this is _not_ a civilized list :-( Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 11:49 ` DervishD 2006-02-10 11:55 ` Matthias Andree 2006-02-10 12:36 ` Joerg Schilling @ 2006-02-13 0:50 ` Alexander Samad 2006-02-13 14:33 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: Alexander Samad @ 2006-02-13 0:50 UTC (permalink / raw) To: Joerg Schilling, mj, peter.read, matthias.andree, linux-kernel, jim, jengelh [-- Attachment #1: Type: text/plain, Size: 1756 bytes --] On Fri, Feb 10, 2006 at 12:49:30PM +0100, DervishD wrote: > Hi Joerg :) > > * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > > Martin Mares <mj@ucw.cz> wrote: > > > > This is why the mapping engine is in the Linux adoption part of > > > > libscg. It maps the non-stable device <-> /dev/sg* relation to a > > > > stable b,t,l address. > > > > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports > > > > Dou you like to verify that you have no clue on SCSI? > > My system is clueless, too! If I write a CD before plugging my > USB storage device, my CD writer is on 0,0,0. If I plug my USB > storage device *before* doing any access, my cdwriter is on 1,0,0. > Pretty stable. Had exactly the same problem with firewire and usb devices, depending on the order of the loading of the kernel modules it all changes! > > But of course, I could made all of the above stable by using > udev. But then the /dev/sg mapping will be stable, too. I can't see > why the three random numbers are more stable than /dev/sg. By the > way, I don't have any SCSI host adapter in my system. > > And please, Joerg, be more respectful when answering. It doesn't > cost money and people will likely respect you, too. > > Ra?l N??ez de Arenas Coronado > > -- > Linux Registered User 88736 | http://www.dervishd.net > http://www.pleyades.net & http://www.gotesdelluna.net > It's my PC and I'll cry if I want to... RAmen! > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 0:50 ` Alexander Samad @ 2006-02-13 14:33 ` Joerg Schilling 2006-02-13 22:12 ` Lennart Sorensen ` (2 more replies) 0 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-13 14:33 UTC (permalink / raw) To: schilling, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, alex Alexander Samad <alex@samad.com.au> wrote: > On Fri, Feb 10, 2006 at 12:49:30PM +0100, DervishD wrote: > > Hi Joerg :) > > > > * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > > > Martin Mares <mj@ucw.cz> wrote: > > > > > This is why the mapping engine is in the Linux adoption part of > > > > > libscg. It maps the non-stable device <-> /dev/sg* relation to a > > > > > stable b,t,l address. > > > > > > > > Nonsense. The b,t,l addresses are NOT stable (at least for transports > > > > > > Dou you like to verify that you have no clue on SCSI? > > > > My system is clueless, too! If I write a CD before plugging my > > USB storage device, my CD writer is on 0,0,0. If I plug my USB > > storage device *before* doing any access, my cdwriter is on 1,0,0. > > Pretty stable. > > Had exactly the same problem with firewire and usb devices, depending on > the order of the loading of the kernel modules it all changes! This is a deficite of the Linux kernel model. You don't have similar problems on Solaris. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:33 ` Joerg Schilling @ 2006-02-13 22:12 ` Lennart Sorensen 2006-02-13 23:21 ` D. Hazelton 2006-02-14 8:06 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: Lennart Sorensen @ 2006-02-13 22:12 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, alex 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:33 ` Joerg Schilling 2006-02-13 22:12 ` Lennart Sorensen @ 2006-02-13 23:21 ` D. Hazelton 2006-02-14 8:06 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: D. Hazelton @ 2006-02-13 23:21 UTC (permalink / raw) To: Joerg Schilling Cc: peter.read, mj, matthias.andree, linux-kernel, jim, jengelh, alex 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:33 ` Joerg Schilling 2006-02-13 22:12 ` Lennart Sorensen 2006-02-13 23:21 ` D. Hazelton @ 2006-02-14 8:06 ` Jan Engelhardt 2 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-14 8:06 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, mj, matthias.andree, linux-kernel, jim, alex >> > 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 17:28 ` Joerg Schilling 2006-02-09 17:36 ` Matthias Andree 2006-02-09 17:36 ` Martin Mares @ 2006-02-09 17:36 ` Jan Engelhardt 2006-02-10 11:02 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: Jan Engelhardt @ 2006-02-09 17:36 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, linux-kernel, jim >> >> >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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 17:36 ` Jan Engelhardt @ 2006-02-10 11:02 ` Joerg Schilling 2006-02-10 13:13 ` Jan Engelhardt 2006-02-10 17:32 ` Michael Buesch 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 11:02 UTC (permalink / raw) To: schilling, jengelh; +Cc: peter.read, matthias.andree, linux-kernel, jim Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > Right. The question was rather like this: > Say we have our non-stable /dev/sr0 mapping to /dev/sg0, and it has got BTL > 1,1,0. Now, if the user starts `cdrecord -dev=1,1,0`, > `ls -l /proc/$(pidof -s cdrecord)/fd/` should show (and in fact did when I > used ide-scsi back then) /dev/sg0, right? > > If so, what's wrong with just opening /dev/sg0 directly (as per user > request, i.e. cdrecord -dev=/dev/sg0) and sending the scsi commands down > the fd? As I did write _many_ times, this was done by the program "cdwrite" on Linux in 1995 and as cdwrite did not check whether if actually got a CD writer, cdwrite did destroy many hard disk drives just _because_ the /dev/sg* is non-stable. People did not believe this and did write shell scripts with e.g. /dev/sg0 inside and later suffered from the non-stable /dev/sg* <-> device relation. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 11:02 ` Joerg Schilling @ 2006-02-10 13:13 ` Jan Engelhardt 2006-02-10 17:32 ` Michael Buesch 1 sibling, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-10 13:13 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, linux-kernel, jim >> 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 -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 11:02 ` Joerg Schilling 2006-02-10 13:13 ` Jan Engelhardt @ 2006-02-10 17:32 ` Michael Buesch 1 sibling, 0 replies; 439+ messages in thread From: Michael Buesch @ 2006-02-10 17:32 UTC (permalink / raw) To: Joerg Schilling; +Cc: eter.read, matthias.andree, linux-kernel, jim, jengelh [-- Attachment #1: Type: text/plain, Size: 1080 bytes --] On Friday 10 February 2006 12:02, you wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > > Right. The question was rather like this: > > Say we have our non-stable /dev/sr0 mapping to /dev/sg0, and it has got BTL > > 1,1,0. Now, if the user starts `cdrecord -dev=1,1,0`, > > `ls -l /proc/$(pidof -s cdrecord)/fd/` should show (and in fact did when I > > used ide-scsi back then) /dev/sg0, right? > > > > If so, what's wrong with just opening /dev/sg0 directly (as per user > > request, i.e. cdrecord -dev=/dev/sg0) and sending the scsi commands down > > the fd? > > As I did write _many_ times, this was done by the program "cdwrite" on Linux > in 1995 and as cdwrite did not check whether if actually got a CD writer, > cdwrite did destroy many hard disk drives just _because_ the /dev/sg* > is non-stable. > > People did not believe this and did write shell scripts with e.g. /dev/sg0 > inside and later suffered from the non-stable /dev/sg* <-> device relation. I am sure they used udev, back in 1995... -- Greetings Michael. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 16:30 ` Jan Engelhardt 2006-02-09 16:47 ` Joerg Schilling @ 2006-02-09 17:15 ` Matthias Andree 1 sibling, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-09 17:15 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Joerg Schilling, jim, peter.read, linux-kernel 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. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 9:39 ` Joerg Schilling ` (3 preceding siblings ...) 2006-02-09 16:30 ` Jan Engelhardt @ 2006-02-10 4:49 ` Alexander Samad 4 siblings, 0 replies; 439+ messages in thread From: Alexander Samad @ 2006-02-10 4:49 UTC (permalink / raw) To: Joerg Schilling; +Cc: jim, peter.read, matthias.andree, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2121 bytes --] On Thu, Feb 09, 2006 at 10:39:55AM +0100, Joerg Schilling wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > > You just verify that you don't listen... > > > > Yes, I have been listening and I haven't seen you list one reason why > > cdrecord absolutely has to use SCSI IDs when fsck can get away with using > > /dev/blah just fine. > > Are you _really_ missing basic know how to understand that fsck is using the > block layer of a virtual "block device" emulated by UNIX while libscg is > offering _direct_ acces to _any_ type of device allowing you to send _commands_ > understood by the device? > > fsck is just sending abstract instructions to a virtual device and does > not care about > > Please explain me: > > - how to use /dev/hd* in order to scan an image from a scanner > > - how to use /dev/hd* in order to talk to a CPU device > > - how to use /dev/hd* in order to talk to a tape device > > - how to use /dev/hd* in order to talk to a printer > > - how to use /dev/hd* in order to talk to a jukebox > > - how to use /dev/hd* in order to talk to a graphical device Hi I have been following this thread for quite a while, would just like to point out that you are quick pedantic about accuracy. so even though it might be a bit of a pain to create a file called /dev/hd*, I believe with mknod you could assign this name to any device you wanted to or even symlink it to any device so you could use you /dev/hd* the same way as you used /dev/sda etc > > J?rg > > -- > EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin > js@cs.tu-berlin.de (uni) > schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 16:32 ` Joerg Schilling 2006-02-08 16:53 ` Jim Crilly @ 2006-02-08 22:52 ` Martin Mares [not found] ` <43EA2A58.9070501@gmx.de> 2 siblings, 0 replies; 439+ messages in thread From: Martin Mares @ 2006-02-08 22:52 UTC (permalink / raw) To: Joerg Schilling; +Cc: jim, peter.read, matthias.andree, linux-kernel > I did answer this many times and I will not repeat it another time. So just point to the Message-ID. Martin ^ permalink raw reply [flat|nested] 439+ messages in thread
[parent not found: <43EA2A58.9070501@gmx.de>]
[parent not found: <43EB1067.nail52A2154ZR@burner>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <43EB1067.nail52A2154ZR@burner> @ 2006-02-09 10:50 ` Matthias Andree 2006-02-09 13:40 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-09 10:50 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-09: > Linux does not offer a UNIX style interface in this case as it breaks > layering rules. Where is that standard that stipulates said layering rules? Quote standard and name, issuer, publisher, edition (year) and section or page number. And don't dare answer unless you can prove the standard applies to the device at hand, again, with standard, edition, and section/page number. > Do you _really_ want me to start a discussion conderning the content > of your junk patch? I demand that you revoke and post a public excuse for that offense. The deadline ends tomorrow, Friday February 10th at 12:00 (noon) German official time. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 10:50 ` Matthias Andree @ 2006-02-09 13:40 ` Joerg Schilling 2006-02-09 15:11 ` DervishD 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 13:40 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-09: > > > Linux does not offer a UNIX style interface in this case as it breaks > > layering rules. > > Where is that standard that stipulates said layering rules? You still try to deviate from the problem by sending relationless remarks. You should _read_ my mail before sending unrelated replies. > > Do you _really_ want me to start a discussion conderning the content > > of your junk patch? > > I demand that you revoke and post a public excuse for that offense. > > The deadline ends tomorrow, Friday February 10th at 12:00 (noon) German > official time. Do you like to out yourself as a troll? You send completely useless things just in order to personally affront me. Note that is was _you_ who said that you like to discuss this useless code. I was ging to ignore it. You like to discuss is, you receive a reply that you might not expect. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 13:40 ` Joerg Schilling @ 2006-02-09 15:11 ` DervishD 2006-02-09 15:46 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: DervishD @ 2006-02-09 15:11 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel Hi Joerg :) * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > > > Do you _really_ want me to start a discussion conderning the content > > > of your junk patch? > > > > I demand that you revoke and post a public excuse for that offense. > > > > The deadline ends tomorrow, Friday February 10th at 12:00 (noon) German > > official time. > > Do you like to out yourself as a troll? > > You send completely useless things just in order to personally affront me. Joerg, it's really sad to see a person as talented and clever as you resorting to personal offences. Matthias sent you a patch, hoping to be useful; IMHO, you took it bad because he insisted on you honoring the same kind of things you force people to honor when it comes to the GPL. IMHO, that made his patch "junk" for you. The patch is not junk, at least to me, but even if it was junk, it was the only sane thing in this whole thread: code to proof things and fix things that someone (many of us, as a matter of fact) thinks is a cdrecord problem. He wanted to discuss the patch: if it is junk, that's the opportunity to fix it and make it good, and avoid new bugs, why not?. But instead of discussing the code (no matter if you just think that it is crap) you offended Matthias (who, BTW, has been very respectful in this thread, probably the most respectful one). You've been very unpolite, Joerg, and it is a pity, because you're very intelligent but nonetheless sometimes you look like... well, both know. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 15:11 ` DervishD @ 2006-02-09 15:46 ` Joerg Schilling 2006-02-09 16:32 ` Jan Engelhardt 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 15:46 UTC (permalink / raw) To: schilling, lkml; +Cc: matthias.andree, linux-kernel DervishD <lkml@dervishd.net> wrote: > Joerg, it's really sad to see a person as talented and clever as > you resorting to personal offences. Matthias sent you a patch, hoping I am not sure whether Matthias is telented, but he was unfortunately starting personal offenses.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 15:46 ` Joerg Schilling @ 2006-02-09 16:32 ` Jan Engelhardt 0 siblings, 0 replies; 439+ messages in thread From: Jan Engelhardt @ 2006-02-09 16:32 UTC (permalink / raw) To: Joerg Schilling; +Cc: lkml, matthias.andree, linux-kernel >> Joerg, it's really sad to see a person as talented and clever as >> you resorting to personal offences. Matthias sent you a patch, hoping > >I am not sure whether Matthias is telented, but he was unfortunately >starting personal offenses.... > With a patch? Jan Engelhardt -- ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 13:27 ` Joerg Schilling ` (3 preceding siblings ...) 2006-02-08 16:28 ` Jim Crilly @ 2006-02-08 21:02 ` DervishD 2006-02-08 21:14 ` Lennart Sorensen 2006-02-09 10:27 ` Joerg Schilling 4 siblings, 2 replies; 439+ messages in thread From: DervishD @ 2006-02-08 21:02 UTC (permalink / raw) To: Joerg Schilling; +Cc: jim, peter.read, matthias.andree, linux-kernel Hi Joerg :) * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > > The people replying here are your users, if you don't want to listen to > > them pretty much any conversation with you will be a waste of time. > > Sorry, but from reading the mail from _real_ cdrecord users, it is > obvious that the people here are either not my users or users with > a stange way of thinking. Joerg, I know you're going to ignore this email just as you ignored other emails I sent you in the past regarding cdrecord, the annoying numbering scheme and the stupid "your DMA speed is too slow, you cannot write at more than 12x" (fortunately, my CD writer doesn't know that and writes correctly at 50x and even more). Anyway, I want to tell you that I've been a cdrecord _real_ user for more than 5 years, and while I consider your work valuable and clever, you have NO respect for anybody who doesn't think the same as you. I know many cdrecord users (_real_ ones, IMHO), and ALL of them think that the numbering scheme to access their writers is CRAP: crappy design, crappy coding and crappy user interface. I'm going to be a bit more respectful: I don't consider it crap. I just consider it bad. Bad because cdrecord is the only program in my system that forces me to think what the heck is the correct number for my CD writer (which is /dev/cdrw in my system) or which number do I have to use to READ a CD image using "readcd" (instead of /dev/cdrw or /dev/dvd, or even the ugly /dev/hdc). I end up using "-scanbus" everytime I use a system which is not mine, and that's bad, because most of those systems have /dev/cdrw, or /dev/cdrecorder, or something like that. Joerg, the problem is that you never listen to things you don't like. I understand, because I sometimes do exactly the same, but I don't maintain a program with thousand of users... cdrecord is GPL, so in the end nobody has the right to ask you to modify it in ways you don't like or you don't want it to. That goes with free software: you don't pay, you don't have the right to ask for things. But, how about trying to listen to third parties? I mean, you are probably OK ignoring my suggestions, I am probably a mediocre programmer, but... do you _really_ think that you are more clever than ALL the programmers in this mailing list? Do you _really_ think that you have the correct answer and that ALL of them are plainly wrong? Do you _REALLY_ think that EVERYBODY is wrong *except* you in this issue about the user interface? C'mon, Joerg, you're more clever than that. You probably know that a program where half the options have a leading "-" and the other half doesn't have it probably has a bad user interface. You know that if a program uses a naming convention different from ALL the rest of programs is because the program has a problem. You know that if the only UNIX program out there that doesn't use /dev entries to talk to devices is cdrecord, the problem *probably* is in cdrecord, and not in UNIX... Well, I will stop here. I don't want to argue with you about this because I'm not sure if I'm right or not. I just happen to like more the "/dev" approach that a set of three numbers to locate a unit in a SCSI bus that I DON'T HAVE in my box... Believe me: I consider you a very good programmer and a very clever person, but your attitude is... My best wishes, Joerg. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 21:02 ` DervishD @ 2006-02-08 21:14 ` Lennart Sorensen 2006-02-08 21:26 ` Matthias Andree ` (2 more replies) 2006-02-09 10:27 ` Joerg Schilling 1 sibling, 3 replies; 439+ messages in thread From: Lennart Sorensen @ 2006-02-08 21:14 UTC (permalink / raw) To: Joerg Schilling, jim, peter.read, matthias.andree, linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 21:14 ` Lennart Sorensen @ 2006-02-08 21:26 ` Matthias Andree 2006-02-09 17:54 ` Lennart Sorensen 2006-02-09 9:02 ` DervishD 2006-02-09 10:29 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-08 21:26 UTC (permalink / raw) To: Lennart Sorensen; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 21:26 ` Matthias Andree @ 2006-02-09 17:54 ` Lennart Sorensen 0 siblings, 0 replies; 439+ messages in thread From: Lennart Sorensen @ 2006-02-09 17:54 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 21:14 ` Lennart Sorensen 2006-02-08 21:26 ` Matthias Andree @ 2006-02-09 9:02 ` DervishD 2006-02-09 13:31 ` Joerg Schilling 2006-02-09 10:29 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: DervishD @ 2006-02-09 9:02 UTC (permalink / raw) To: Lennart Sorensen Cc: Joerg Schilling, jim, peter.read, matthias.andree, linux-kernel Hi Lennart :) * Lennart Sorensen <lsorense@csclub.uwaterloo.ca> dixit: > On Wed, Feb 08, 2006 at 10:02:19PM +0100, DervishD wrote: > > cdrecord is GPL, so in the end nobody has the right to ask you to > > modify it in ways you don't like or you don't want it to. That goes > > with free software: you don't pay, you don't have the right to ask > > for things. But, how about trying to listen to third parties? I mean, > > you are probably OK ignoring my suggestions, I am probably a mediocre > > programmer, but... do you _really_ think that you are more clever > > than ALL the programmers in this mailing list? Do you _really_ think > > that you have the correct answer and that ALL of them are plainly > > wrong? Do you _REALLY_ think that EVERYBODY is wrong *except* you in > > this issue about the user interface? > > Hmm, perhaps what should be done is that someone needs to write and > maintain a patch that linux users can apply to cdrecord (since other OSs > are different and hence have no reason to use such a patch), to make it > behave in a manner which is sane on linux. It should of course be > clearly marked as having been changed in such a way. It should use udev > if available and HAL and whatever else is appropriate on a modern linux > system, and if on an old system it should at least not break the > interfaces that already worked on those systems in cdrecord. Matthias Andree posted such a patch last week, and he was ignored by Joerg. In fact, he got an answer of "I haven't looked at it and I never will" or something like that (check the list archives). Joerg was offered help to maintain a bit of code he doesn't want to maintain and rejected it. > cdrecord does a wonderful job writing CDs, once you get the silly > command line syntax right and figure out which device option it > wants you to tell it to access your write. I still find the syntax > of driveropts=option=value is a bit odd, although the linux kernel > does the same thing for some kernel boot arguments as far as I > recall, so who am I to argue. cdrecord is a good tool, no doubt about that. IMHO it can be improved by changing the user interface and getting rid of useless warnings, but nonetheless it is a good tool. The problem is Joerg attitude... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 9:02 ` DervishD @ 2006-02-09 13:31 ` Joerg Schilling 2006-02-09 15:02 ` DervishD 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 13:31 UTC (permalink / raw) To: lsorense, lkml; +Cc: schilling, peter.read, matthias.andree, linux-kernel, jim DervishD <lkml@dervishd.net> wrote: > Matthias Andree posted such a patch last week, and he was ignored > by Joerg. In fact, he got an answer of "I haven't looked at it and I > never will" or something like that (check the list archives). If you like to look at the junk he send, do it.... > Joerg was offered help to maintain a bit of code he doesn't want > to maintain and rejected it. Sorry this cannot be called help, in contrary it is an attempt to waste my time. w Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 13:31 ` Joerg Schilling @ 2006-02-09 15:02 ` DervishD 2006-02-09 15:45 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: DervishD @ 2006-02-09 15:02 UTC (permalink / raw) To: Joerg Schilling; +Cc: lsorense, peter.read, matthias.andree, linux-kernel, jim Hi Joerg :) * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > DervishD <lkml@dervishd.net> wrote: > > Matthias Andree posted such a patch last week, and he was ignored > > by Joerg. In fact, he got an answer of "I haven't looked at it and I > > never will" or something like that (check the list archives). > > If you like to look at the junk he send, do it.... I've already done it. Doesn't seem to be junk. It works for me, and the patch was well prepared (at least it looks good to me). Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 15:02 ` DervishD @ 2006-02-09 15:45 ` Joerg Schilling 2006-02-09 15:57 ` Jim Crilly 2006-02-10 5:05 ` Alexander Samad 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 15:45 UTC (permalink / raw) To: schilling, lkml; +Cc: peter.read, matthias.andree, lsorense, linux-kernel, jim DervishD <lkml@dervishd.net> wrote: > I've already done it. Doesn't seem to be junk. It works for me, > and the patch was well prepared (at least it looks good to me). If this is thew way you write software.... it will not have the quality I am loking for. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 15:45 ` Joerg Schilling @ 2006-02-09 15:57 ` Jim Crilly 2006-02-10 5:05 ` Alexander Samad 1 sibling, 0 replies; 439+ messages in thread From: Jim Crilly @ 2006-02-09 15:57 UTC (permalink / raw) To: Joerg Schilling; +Cc: lkml, peter.read, matthias.andree, lsorense, linux-kernel On 02/09/06 04:45:07PM +0100, Joerg Schilling wrote: > DervishD <lkml@dervishd.net> wrote: > > > I've already done it. Doesn't seem to be junk. It works for me, > > and the patch was well prepared (at least it looks good to me). > > If this is thew way you write software.... it will not have the quality > I am loking for. > > > Jörg At least he's willing to read people's contributions and listen to their ideas and criticisms. Jim. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 15:45 ` Joerg Schilling 2006-02-09 15:57 ` Jim Crilly @ 2006-02-10 5:05 ` Alexander Samad 1 sibling, 0 replies; 439+ messages in thread From: Alexander Samad @ 2006-02-10 5:05 UTC (permalink / raw) To: Joerg Schilling Cc: lkml, peter.read, matthias.andree, lsorense, linux-kernel, jim [-- Attachment #1: Type: text/plain, Size: 1067 bytes --] On Thu, Feb 09, 2006 at 04:45:07PM +0100, Joerg Schilling wrote: > DervishD <lkml@dervishd.net> wrote: > > > I've already done it. Doesn't seem to be junk. It works for me, > > and the patch was well prepared (at least it looks good to me). > > If this is thew way you write software.... it will not have the quality > I am loking for. How would you know if you don't read it, seems pretty presumptious and very narrow minded, but I haven't read it either > > > J?rg > > -- > EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin > js@cs.tu-berlin.de (uni) > schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 21:14 ` Lennart Sorensen 2006-02-08 21:26 ` Matthias Andree 2006-02-09 9:02 ` DervishD @ 2006-02-09 10:29 ` Joerg Schilling 2006-02-09 10:53 ` Matthias Andree ` (2 more replies) 2 siblings, 3 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 10:29 UTC (permalink / raw) To: schilling, peter.read, matthias.andree, lsorense, linux-kernel, jim lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote: > Hmm, perhaps what should be done is that someone needs to write and > maintain a patch that linux users can apply to cdrecord (since other OSs > are different and hence have no reason to use such a patch), to make it > behave in a manner which is sane on linux. It should of course be > clearly marked as having been changed in such a way. It should use udev > if available and HAL and whatever else is appropriate on a modern linux > system, and if on an old system it should at least not break the > interfaces that already worked on those systems in cdrecord. Unfortunately is it a matter oif facts that all known patches for cdrecord break more things than they claim to fix. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 10:29 ` Joerg Schilling @ 2006-02-09 10:53 ` Matthias Andree 2006-02-09 13:42 ` Joerg Schilling 2006-02-09 14:57 ` DervishD 2006-02-09 16:00 ` Jim Crilly 2 siblings, 1 reply; 439+ messages in thread From: Matthias Andree @ 2006-02-09 10:53 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, lsorense, linux-kernel, jim Joerg Schilling schrieb am 2006-02-09: > lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote: > > > Hmm, perhaps what should be done is that someone needs to write and > > maintain a patch that linux users can apply to cdrecord (since other OSs > > are different and hence have no reason to use such a patch), to make it > > behave in a manner which is sane on linux. It should of course be > > clearly marked as having been changed in such a way. It should use udev > > if available and HAL and whatever else is appropriate on a modern linux > > system, and if on an old system it should at least not break the > > interfaces that already worked on those systems in cdrecord. > > Unfortunately is it a matter oif facts that all known patches for cdrecord > break more things than they claim to fix. So prove my patch is wrong, and give a detailed report what it breaks, unless you wish to fix it yourself. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 10:53 ` Matthias Andree @ 2006-02-09 13:42 ` Joerg Schilling 2006-02-09 15:33 ` Matthias Andree 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 13:42 UTC (permalink / raw) To: schilling, matthias.andree Cc: peter.read, matthias.andree, lsorense, linux-kernel, jim Matthias Andree <matthias.andree@gmx.de> wrote: > > Unfortunately is it a matter oif facts that all known patches for cdrecord > > break more things than they claim to fix. > > So prove my patch is wrong, and give a detailed report what it breaks, > unless you wish to fix it yourself. Give a detailed report on what it fixes. It does not make sense to discuss useless code that introduces more bugs than it pretends to fix. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 13:42 ` Joerg Schilling @ 2006-02-09 15:33 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-09 15:33 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, lsorense, linux-kernel, jim Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > >>> Unfortunately is it a matter oif facts that all known patches for cdrecord >>> break more things than they claim to fix. >> So prove my patch is wrong, and give a detailed report what it breaks, >> unless you wish to fix it yourself. > > Give a detailed report on what it fixes. It does not make sense to discuss > useless code that introduces more bugs than it pretends to fix. That was contained in the message you blatantly ignored. I'm not going to repost, see <http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html> ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 10:29 ` Joerg Schilling 2006-02-09 10:53 ` Matthias Andree @ 2006-02-09 14:57 ` DervishD 2006-02-09 15:42 ` Joerg Schilling 2006-02-09 16:00 ` Jim Crilly 2 siblings, 1 reply; 439+ messages in thread From: DervishD @ 2006-02-09 14:57 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, lsorense, linux-kernel, jim Hi Joerg :) * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote: > > Hmm, perhaps what should be done is that someone needs to write and > > maintain a patch that linux users can apply to cdrecord (since other OSs > > are different and hence have no reason to use such a patch), to make it > > behave in a manner which is sane on linux. It should of course be > > clearly marked as having been changed in such a way. It should use udev > > if available and HAL and whatever else is appropriate on a modern linux > > system, and if on an old system it should at least not break the > > interfaces that already worked on those systems in cdrecord. > > Unfortunately is it a matter oif facts that all known patches for > cdrecord break more things than they claim to fix. Could you please clarify which things are broken by Matthias patch? This way he (or other developer) can prepare a better patch and maintain it. BTW, I patched my cdrecord with Matthias patch and nothing seems to be broken :? Maybe am I missing something? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 14:57 ` DervishD @ 2006-02-09 15:42 ` Joerg Schilling 2006-02-09 16:32 ` Matthias Andree 2006-02-09 17:33 ` DervishD 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 15:42 UTC (permalink / raw) To: schilling, lkml; +Cc: peter.read, matthias.andree, lsorense, linux-kernel, jim DervishD <lkml@dervishd.net> wrote: > Could you please clarify which things are broken by Matthias > patch? This way he (or other developer) can prepare a better patch > and maintain it. BTW, I patched my cdrecord with Matthias patch and > nothing seems to be broken :? Maybe am I missing something? It is completely broken and thus makes no sense at all. As I did write it looks lie a dentist drills a hole into an aking tooth and then claims to be complete with the whole treatment. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 15:42 ` Joerg Schilling @ 2006-02-09 16:32 ` Matthias Andree 2006-02-09 17:33 ` DervishD 1 sibling, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-09 16:32 UTC (permalink / raw) To: Joerg Schilling; +Cc: lkml, peter.read, lsorense, linux-kernel, jim Joerg Schilling wrote: > DervishD <lkml@dervishd.net> wrote: > >> Could you please clarify which things are broken by Matthias >> patch? This way he (or other developer) can prepare a better patch >> and maintain it. BTW, I patched my cdrecord with Matthias patch and >> nothing seems to be broken :? Maybe am I missing something? > > It is completely broken and thus makes no sense at all. "Completely broken" is not a proper description that might become the basis of a technical discussion. It looks like the quick way of not having to look at it, at least there is no hint you could provide specific information as to what the patch breaks. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 15:42 ` Joerg Schilling 2006-02-09 16:32 ` Matthias Andree @ 2006-02-09 17:33 ` DervishD 2006-02-10 10:57 ` Joerg Schilling 1 sibling, 1 reply; 439+ messages in thread From: DervishD @ 2006-02-09 17:33 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, lsorense, linux-kernel, jim Hi Joerg :) * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > > Could you please clarify which things are broken by Matthias > > patch? This way he (or other developer) can prepare a better patch > > and maintain it. BTW, I patched my cdrecord with Matthias patch and > > nothing seems to be broken :? Maybe am I missing something? > > It is completely broken and thus makes no sense at all. OK, I understand now... Completely broken... Have you any actual proof or should I use my faith and just believe it is completely broken? Anyway, forget about it. As you suggest in other message, my way of writing software is so poor ('cause I think that the junk Matthias wrote is good for me) that probably I won't understand your explanation. You know, that's the problem with stupid people like me, that we don't understand what people say to us, so there's not point in explaining. You do the right think and don't provide facts, because nobody is clever or talented enough to understand them. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 17:33 ` DervishD @ 2006-02-10 10:57 ` Joerg Schilling 2006-02-10 11:45 ` DervishD 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 10:57 UTC (permalink / raw) To: schilling, lkml; +Cc: peter.read, matthias.andree, lsorense, linux-kernel, jim DervishD <lkml@dervishd.net> wrote: > * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > > > Could you please clarify which things are broken by Matthias > > > patch? This way he (or other developer) can prepare a better patch > > > and maintain it. BTW, I patched my cdrecord with Matthias patch and > > > nothing seems to be broken :? Maybe am I missing something? > > > > It is completely broken and thus makes no sense at all. > > OK, I understand now... Completely broken... Have you any actual > proof or should I use my faith and just believe it is completely > broken? What is your intent for writing this? FUD? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 10:57 ` Joerg Schilling @ 2006-02-10 11:45 ` DervishD 2006-02-10 12:33 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: DervishD @ 2006-02-10 11:45 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, lsorense, linux-kernel, jim Hi Joerg :) * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > DervishD <lkml@dervishd.net> wrote: > > * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > > > > Could you please clarify which things are broken by Matthias > > > > patch? This way he (or other developer) can prepare a better patch > > > > and maintain it. BTW, I patched my cdrecord with Matthias patch and > > > > nothing seems to be broken :? Maybe am I missing something? > > > > > > It is completely broken and thus makes no sense at all. > > > > OK, I understand now... Completely broken... Have you any actual > > proof or should I use my faith and just believe it is completely > > broken? > > What is your intent for writing this? My intention is to get real proofs about the "brokenness" of the patch, not just an "It is completely broken". That's not technical. That's the same than saying "Windows sucks". Now, tell why it sucks, in technical terms. A better example: it is like saying that the numbering scheme that cdrecord uses is crap. That's nontechnical. A technical approach is "UNIX userspace programs doesn't use three numbers to talk to devices, they use /dev nodes, so cdrecord is breaking the UNIX way of doing things". Or "Windows uses letters to refer to storage devices and cdrecorders and not three numbers, so cdrecord is breaking the way of doing things on Windows". I don't even ask for a deep technical discussion, anything more technical than "It is completely broken" will do. > FUD? Why do you think that? Have I offended you? Have I attacked you personally? Up to this point I have: - Asked for technical reasons about a patch rejection. - Tell my *opinion*, as a cdrecord user, about the user interface. I can't see fear, my only uncertainty is about the technical (un)correctness of the patch, which you haven't clarified yet, and my only doubt is if there are programs, apart from cdrecord and libscg users, which uses your numbering scheme instead of /dev entries :? That makes (at worst) UD, but not FUD. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 11:45 ` DervishD @ 2006-02-10 12:33 ` Joerg Schilling 2006-02-10 12:58 ` DervishD 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-10 12:33 UTC (permalink / raw) To: schilling, lkml; +Cc: peter.read, matthias.andree, lsorense, linux-kernel, jim DervishD <lkml@dervishd.net> wrote: > > What is your intent for writing this? > > My intention is to get real proofs about the "brokenness" of the > patch, not just an "It is completely broken". That's not technical. > That's the same than saying "Windows sucks". Now, tell why it sucks, > in technical terms. > So why don't you look at the patch then? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:33 ` Joerg Schilling @ 2006-02-10 12:58 ` DervishD 0 siblings, 0 replies; 439+ messages in thread From: DervishD @ 2006-02-10 12:58 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, lsorense, linux-kernel, jim Hi Joerg :) * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > DervishD <lkml@dervishd.net> wrote: > > > What is your intent for writing this? > > > > My intention is to get real proofs about the "brokenness" of the > > patch, not just an "It is completely broken". That's not technical. > > That's the same than saying "Windows sucks". Now, tell why it sucks, > > in technical terms. > > > > So why don't you look at the patch then? I've done it. I told in my first message. Have you done it? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 10:29 ` Joerg Schilling 2006-02-09 10:53 ` Matthias Andree 2006-02-09 14:57 ` DervishD @ 2006-02-09 16:00 ` Jim Crilly 2006-02-09 16:01 ` Joerg Schilling 2 siblings, 1 reply; 439+ messages in thread From: Jim Crilly @ 2006-02-09 16:00 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, lsorense, linux-kernel On 02/09/06 11:29:28AM +0100, Joerg Schilling wrote: > lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote: > > > Hmm, perhaps what should be done is that someone needs to write and > > maintain a patch that linux users can apply to cdrecord (since other OSs > > are different and hence have no reason to use such a patch), to make it > > behave in a manner which is sane on linux. It should of course be > > clearly marked as having been changed in such a way. It should use udev > > if available and HAL and whatever else is appropriate on a modern linux > > system, and if on an old system it should at least not break the > > interfaces that already worked on those systems in cdrecord. > > Unfortunately is it a matter oif facts that all known patches for cdrecord > break more things than they claim to fix. > > Jörg I've been using the cdrecord packaged by Debian for years without a single problem and it has 35 patches included in the source package. Please enlighten me as to what they've broken because obviously none of it has affected me. Jim. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 16:00 ` Jim Crilly @ 2006-02-09 16:01 ` Joerg Schilling 2006-02-09 16:10 ` Jim Crilly 0 siblings, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 16:01 UTC (permalink / raw) To: schilling, jim; +Cc: peter.read, matthias.andree, lsorense, linux-kernel "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > I've been using the cdrecord packaged by Debian for years without a single > problem and it has 35 patches included in the source package. Please > enlighten me as to what they've broken because obviously none of it has > affected me. Are you unwilling to reead critisism? Just read my comments on the Debian bug tracking system Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 16:01 ` Joerg Schilling @ 2006-02-09 16:10 ` Jim Crilly 2006-02-09 16:13 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Jim Crilly @ 2006-02-09 16:10 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, lsorense, linux-kernel On 02/09/06 05:01:50PM +0100, Joerg Schilling wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > I've been using the cdrecord packaged by Debian for years without a single > > problem and it has 35 patches included in the source package. Please > > enlighten me as to what they've broken because obviously none of it has > > affected me. > > Are you unwilling to reead critisism? > > Just read my comments on the Debian bug tracking system > > Jörg To which bugs are you referring? Looking at the bugs for the cdrtools package, I only see 1 functionality bug. All of the rest are policy violations, copyright updates, translation updates, etc. And ironically in that 1 real bug the entire thread degenerated into you pointing fingers and slinging mud at the Linux kernel maintainers again, just like this one. Jim. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 16:10 ` Jim Crilly @ 2006-02-09 16:13 ` Joerg Schilling 2006-02-09 16:26 ` Matthias Andree 2006-02-09 16:30 ` Jim Crilly 0 siblings, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 16:13 UTC (permalink / raw) To: schilling, jim; +Cc: peter.read, matthias.andree, lsorense, linux-kernel "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > Just read my comments on the Debian bug tracking system > > > > Jörg > > To which bugs are you referring? Looking at the bugs for the cdrtools > package, I only see 1 functionality bug. All of the rest are policy > violations, copyright updates, translation updates, etc. And ironically > in that 1 real bug the entire thread degenerated into you pointing > fingers and slinging mud at the Linux kernel maintainers again, just > like this one. It's not me who proablty did delete unwanted information on Debian.org..... A few weeks ago, there have been aprox. 100 "bug" entries. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 16:13 ` Joerg Schilling @ 2006-02-09 16:26 ` Matthias Andree 2006-02-09 16:30 ` Jim Crilly 1 sibling, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-09 16:26 UTC (permalink / raw) To: Joerg Schilling; +Cc: jim, peter.read, lsorense, linux-kernel Joerg Schilling wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > >>> Just read my comments on the Debian bug tracking system >>> >>> Jörg >> To which bugs are you referring? Looking at the bugs for the cdrtools >> package, I only see 1 functionality bug. All of the rest are policy >> violations, copyright updates, translation updates, etc. And ironically >> in that 1 real bug the entire thread degenerated into you pointing >> fingers and slinging mud at the Linux kernel maintainers again, just >> like this one. > > It's not me who proablty did delete unwanted information on Debian.org..... > > A few weeks ago, there have been aprox. 100 "bug" entries. You need not care about the Debian bugs, except the few the Debian package maintainers have forwarded to you. Every other bug is Debian specific. The idea is they will pass bug reports through a triage process, filter support requests, filter bug reports that are related to their local changes, and forward what they deem upstream bugs to you. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 16:13 ` Joerg Schilling 2006-02-09 16:26 ` Matthias Andree @ 2006-02-09 16:30 ` Jim Crilly 1 sibling, 0 replies; 439+ messages in thread From: Jim Crilly @ 2006-02-09 16:30 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, lsorense, linux-kernel On 02/09/06 05:13:08PM +0100, Joerg Schilling wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > > Just read my comments on the Debian bug tracking system > > > > > > Jörg > > > > To which bugs are you referring? Looking at the bugs for the cdrtools > > package, I only see 1 functionality bug. All of the rest are policy > > violations, copyright updates, translation updates, etc. And ironically > > in that 1 real bug the entire thread degenerated into you pointing > > fingers and slinging mud at the Linux kernel maintainers again, just > > like this one. > > It's not me who proablty did delete unwanted information on Debian.org..... > > A few weeks ago, there have been aprox. 100 "bug" entries. > > Jörg Nevermind, I found them. They're rightfully attributed to the cdrecord binary package and not the cdrtools source package. So far I've looked through two dozen or so bugs and found only like 3 comments from you, 1 was telling someone that they had a hardware problem and the others were finger pointing at the Linux kernel devs. Jim. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 21:02 ` DervishD 2006-02-08 21:14 ` Lennart Sorensen @ 2006-02-09 10:27 ` Joerg Schilling 2006-02-09 10:58 ` Matthias Andree 2006-02-09 14:55 ` DervishD 1 sibling, 2 replies; 439+ messages in thread From: Joerg Schilling @ 2006-02-09 10:27 UTC (permalink / raw) To: schilling, lkml; +Cc: peter.read, matthias.andree, linux-kernel, jim DervishD <lkml@dervishd.net> wrote: > other half doesn't have it probably has a bad user interface. You > know that if a program uses a naming convention different from ALL > the rest of programs is because the program has a problem. You know > that if the only UNIX program out there that doesn't use /dev entries > to talk to devices is cdrecord, the problem *probably* is in > cdrecord, and not in UNIX... So why do you like to introduce a different naming scheme? Look into the real world and you will find that most SCSI related programs use a namischscheme that is either identical to what cdrecord does or a very similar one. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 10:27 ` Joerg Schilling @ 2006-02-09 10:58 ` Matthias Andree 2006-02-09 14:55 ` DervishD 1 sibling, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-09 10:58 UTC (permalink / raw) To: Joerg Schilling; +Cc: lkml, peter.read, matthias.andree, linux-kernel, jim Joerg Schilling schrieb am 2006-02-09: > DervishD <lkml@dervishd.net> wrote: > > > > other half doesn't have it probably has a bad user interface. You > > know that if a program uses a naming convention different from ALL > > the rest of programs is because the program has a problem. You know > > that if the only UNIX program out there that doesn't use /dev entries > > to talk to devices is cdrecord, the problem *probably* is in > > cdrecord, and not in UNIX... > > So why do you like to introduce a different naming scheme? It is striking that Jörg Schilling's code alone uses this naming scheme, and nothing else appears to be. If there is, perhaps naming a few typical real-world applications could enlighten us. You haven't mentioned examples yet, so there isn't even a faint hint cdrecord is consistent with the so-called real-world. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 10:27 ` Joerg Schilling 2006-02-09 10:58 ` Matthias Andree @ 2006-02-09 14:55 ` DervishD 1 sibling, 0 replies; 439+ messages in thread From: DervishD @ 2006-02-09 14:55 UTC (permalink / raw) To: Joerg Schilling; +Cc: peter.read, matthias.andree, linux-kernel, jim Hi Joerg :) * Joerg Schilling <schilling@fokus.fraunhofer.de> dixit: > DervishD <lkml@dervishd.net> wrote: > > other half doesn't have it probably has a bad user interface. You > > know that if a program uses a naming convention different from ALL > > the rest of programs is because the program has a problem. You know > > that if the only UNIX program out there that doesn't use /dev entries > > to talk to devices is cdrecord, the problem *probably* is in > > cdrecord, and not in UNIX... > > So why do you like to introduce a different naming scheme? Exactly, Joerg, why do YOU like to introduce a different naming scheme? UNIX uses /dev/whatever, Win32 uses <UNIT>:, etc. Why do you want to break those names, which are familiar to the user? > Look into the real world and you will find that most SCSI related > programs use a namischscheme that is either identical to what > cdrecord does or a very similar one. I don't know any program, except cdrecord and family, which uses your naming scheme, but I will more than happy to hear examples, look at them and change my mind if I finally get convinced that the naming scheme you're using is finally better. But instead of telling me to look into the real world, tell me examples, please. I don't have at home any SCSI bus and so I don't use SCSI related programs. Thanks in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... RAmen! ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-02-06 15:06 ` Peter Read 2006-02-06 15:15 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree @ 2006-02-06 17:25 ` Joerg Schilling 2006-02-07 10:57 ` Matthias Andree 1 sibling, 1 reply; 439+ messages in thread From: Joerg Schilling @ 2006-02-06 17:25 UTC (permalink / raw) To: schilling, peter.read, luke Cc: rlrevell, matthias.andree, linux-kernel, jengelh Peter Read <peter.read@gmail.com> wrote: > I'm confused about where software has inherited a sense of morality from? > > Equally, as I can't see any restriction of the GPL in that link I > don't get the reference. What it's essentially saying to me is 'if > you don't want it under the GPL licence terms, talk to the copyright > holder(s) or their authorised representative about alternatives'. Please read again carefully. It says that it is not allowed to be shipped together with commercial software unless the publisher did pay money. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-02-06 17:25 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Joerg Schilling @ 2006-02-07 10:57 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-02-07 10:57 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-06: > Peter Read <peter.read@gmail.com> wrote: > > > I'm confused about where software has inherited a sense of morality from? > > > > Equally, as I can't see any restriction of the GPL in that link I > > don't get the reference. What it's essentially saying to me is 'if > > you don't want it under the GPL licence terms, talk to the copyright > > holder(s) or their authorised representative about alternatives'. > > Please read again carefully. It says that it is not allowed to be shipped > together with commercial software unless the publisher did pay money. The topic is still cdrecord with Linux, growisofs and dvd+rw-tools discussion is a matter for a separate thread. -- Matthias Andree ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-02-06 13:51 ` Joerg Schilling 2006-02-06 14:01 ` Matthias Andree 2006-02-06 15:06 ` Peter Read @ 2006-02-06 17:40 ` Luke-Jr 2 siblings, 0 replies; 439+ messages in thread From: Luke-Jr @ 2006-02-06 17:40 UTC (permalink / raw) To: Joerg Schilling; +Cc: jengelh, rlrevell, matthias.andree, linux-kernel On Monday 06 February 2006 13:51, Joerg Schilling wrote: > Luke-Jr <luke@dashjr.org> wrote: > > ProDVD is immoral software. I use growisofs. > > growisofs is immoral, see > > http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html > > Either this, or the GPL applies, but not both as intended by the author.... You can dual license any work. Someone who receives growisofs under this license would not be allowed to redistribute it without permission granted therein. However, if that same person receives growisofs under the GPL license, the GPL terms apply. A GPL license only applies if the person has received the software under those terms. While most GPL'd software is available online under the GPL license, making it effectively everyone to receive the license, it is not necessary. On Monday 06 February 2006 17:25, you wrote: > Peter Read <peter.read@gmail.com> wrote: > > I'm confused about where software has inherited a sense of morality from? > > > > Equally, as I can't see any restriction of the GPL in that link I > > don't get the reference. What it's essentially saying to me is 'if > > you don't want it under the GPL licence terms, talk to the copyright > > holder(s) or their authorised representative about alternatives'. > > Please read again carefully. It says that it is not allowed to be shipped > together with commercial software unless the publisher did pay money. However, that applies only for that particular license. If the publisher obtains the rights elsewhere (eg, the GPL licensed version), then they may do so provided they comply with the rest of the GPL terms. Note that the GPL prohibits distributing growisofs linked to non-GPL-compatible software. Thus, if Solaris is not under a GPL-compatible license, the GPL prohibits distributing growisofs with it. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 20:30 ` Lee Revell 2006-01-23 21:21 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree @ 2006-01-23 21:33 ` Joerg Schilling 1 sibling, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-23 21:33 UTC (permalink / raw) To: schilling, rlrevell; +Cc: matthias.andree, linux-kernel, arjan Lee Revell <rlrevell@joe-job.com> wrote: > > In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later > > ignores this contract. This bug should be fixed. > > Joerg, > > You will be happy to know that in future Linux distros, cdrecord will > not require setuid to mlock() and get SCHED_FIFO - both are now > controlled by rlimits, so if the distro ships with a sane PAM/group > configuration, all you will need to do is add cdrecord users to the > "realtime" or "cdrecord" or "audio" group. > > This will take a while to make it into distros as it requires changes to > PAM and glibc in addition to the kernel. Well, on Solaris running cdrecord root-less is possible since 2 years. What you do is to add a line joerg::::profiles=CD RW to /etc/user_attr and a line: CD RW:solaris:cmd:::/opt/schily/bin/cdrecord: privs=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr to /etc/security/exec_attr or to just a line All:solaris:cmd:::/opt/schily/bin/cdrecord: privs=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr to /etc/security/exec_attr the command then is executed via /usr/vin/pfexec and gets the listed fine grained privileges in addition to the basic privileges. We plan to break sys_devices into more fine grained privs that include several levels of SCSI rights in the near future. If Linux manages to do something similar, I would be happy. It is obvious that this is someting that could only be used if there is not only kernel code to support fine grained privs but there is a need for a user space infrastructure that allows to use a seamless integration. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 18:55 ` Matthias Andree 2006-01-23 19:04 ` Arjan van de Ven 2006-01-23 19:38 ` Joerg Schilling @ 2006-01-23 19:57 ` Lee Revell 2006-01-23 21:34 ` Theodore Ts'o 3 siblings, 0 replies; 439+ messages in thread From: Lee Revell @ 2006-01-23 19:57 UTC (permalink / raw) To: Matthias Andree; +Cc: Arjan van de Ven, Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 18:55 ` Matthias Andree ` (2 preceding siblings ...) 2006-01-23 19:57 ` Lee Revell @ 2006-01-23 21:34 ` Theodore Ts'o 2006-01-24 11:06 ` Matthias Andree 3 siblings, 1 reply; 439+ messages in thread From: Theodore Ts'o @ 2006-01-23 21:34 UTC (permalink / raw) To: Arjan van de Ven, Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 21:34 ` Theodore Ts'o @ 2006-01-24 11:06 ` Matthias Andree 0 siblings, 0 replies; 439+ messages in thread From: Matthias Andree @ 2006-01-24 11:06 UTC (permalink / raw) To: Theodore Ts'o, Arjan van de Ven, Linux-Kernel mailing list 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 ^ permalink raw reply [flat|nested] 439+ messages in thread
[parent not found: <5y7B5-1dw-15@gated-at.bofh.it>]
[parent not found: <5y7KL-1DZ-31@gated-at.bofh.it>]
[parent not found: <5yddh-1pA-47@gated-at.bofh.it>]
[parent not found: <5ydni-1Qq-3@gated-at.bofh.it>]
[parent not found: <5yek1-3iP-53@gated-at.bofh.it>]
[parent not found: <5yeth-3us-33@gated-at.bofh.it>]
[parent not found: <5yf5O-4iF-19@gated-at.bofh.it>]
[parent not found: <5yfI4-5kU-11@gated-at.bofh.it>]
[parent not found: <5ygE4-6LK-35@gated-at.bofh.it>]
[parent not found: <5yhqg-7ZR-5@gated-at.bofh.it>]
[parent not found: <5yi2X-zm-7@gated-at.bofh.it>]
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) [not found] ` <5yi2X-zm-7@gated-at.bofh.it> @ 2006-01-24 9:14 ` Bodo Eggert 2006-01-24 14:38 ` Joerg Schilling 0 siblings, 1 reply; 439+ messages in thread From: Bodo Eggert @ 2006-01-24 9:14 UTC (permalink / raw) To: Joerg Schilling, rlrevell, matthias.andree, schilling, linux-kernel Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: [...] > On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh) > that calls getexecuser() in order to find whether there is a specific > treatment needed. If this specific treatment is needed, then the shell calls > execve(/usr/bin/pfexec cmd <args>) > else it calls execve(cmd <args>) > > I did recently voted to require all shells to be profile enabled by default. Why? I asume there will only be few programs requiring to be run by a wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo; echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo; chmod 755 /usr/bin/foo should be easier than patching e.g. all callers of cdrecord, and it won't slow down starting non-profiled applications. Possibly the pfexec can tell the application to be run by the basename (like su1), in this case you'd add something like "alias cdrecord /opt/schily/bin/cdrecord" to it's configuration and link it to /usr/bin/cdrecord. > With the future plans for extending fine grained privs on Solaris, sending > SCSI commands will become more than one priv. > > I proposed to have a low priv right to send commands like inquiry and test > unit ready. These commands may e.g. be send without interfering a concurrent > CD/DVD write operation. > > The next priv could be the permission for sending simple SCSI commands that > allow reading from the device. > > The next priv could be the permission for sending simple SCSI Commands that > allow writing. > > The final priv would allow even vendor specific commands: this is what > cdrecord needs. That sounds reasonable, but I wonder how you can get access to a device file descriptor in order to do unprivileged access. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. ^ permalink raw reply [flat|nested] 439+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-01-24 9:14 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Bodo Eggert @ 2006-01-24 14:38 ` Joerg Schilling 0 siblings, 0 replies; 439+ messages in thread From: Joerg Schilling @ 2006-01-24 14:38 UTC (permalink / raw) To: schilling, rlrevell, matthias.andree, linux-kernel, 7eggert Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote: > Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > [...] > > On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh) > > that calls getexecuser() in order to find whether there is a specific > > treatment needed. If this specific treatment is needed, then the shell calls > > execve(/usr/bin/pfexec cmd <args>) > > else it calls execve(cmd <args>) > > > > I did recently voted to require all shells to be profile enabled by default. > > Why? I asume there will only be few programs requiring to be run by a > wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo; > echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo; > chmod 755 /usr/bin/foo > should be easier than patching e.g. all callers of cdrecord, and it won't > slow down starting non-profiled applications. Because the architecture review commitee decided this would be the right way. Note that we are on a migration from the classical root/non-root UNIX to a fine grained privileges handling. The current documentation says that you need to have a profile enabled shell as your SHELL in order to be able to use a root-less Solaris. > Possibly the pfexec can tell the application to be run by the basename (like > su1), in this case you'd add something like > "alias cdrecord /opt/schily/bin/cdrecord" to it's configuration and link it > to /usr/bin/cdrecord. But you are right that another way would be to use something like "isaexec" > > The final priv would allow even vendor specific commands: this is what > > cdrecord needs. > > That sounds reasonable, but I wonder how you can get access to a device > file descriptor in order to do unprivileged access. This is something that needs to be discussed. Last night, I found that there should be a way to run cdrecord without the need to have the "file_dac_read" provilege. I'll discuss this with the security group. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 439+ messages in thread
end of thread, other threads:[~2006-03-01 17:39 UTC | newest] Thread overview: 439+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-23 10:56 Rationale for RLIMIT_MEMLOCK? Matthias Andree 2006-01-23 11:05 ` Arjan van de Ven 2006-01-23 16:54 ` Matthias Andree 2006-01-23 17:00 ` Arjan van de Ven 2006-01-23 18:01 ` Matthias Andree 2006-01-23 18:13 ` Arjan van de Ven 2006-01-23 18:55 ` Matthias Andree 2006-01-23 19:04 ` Arjan van de Ven 2006-01-23 19:38 ` Joerg Schilling 2006-01-23 20:30 ` Matthias Andree 2006-01-23 21:23 ` Joerg Schilling 2006-01-23 22:05 ` Matthias Andree 2006-01-24 8:52 ` Arjan van de Ven 2006-01-24 9:08 ` Joerg Schilling 2006-01-24 9:15 ` Arjan van de Ven 2006-01-24 9:18 ` Joerg Schilling 2006-01-24 21:28 ` Theodore Ts'o 2006-01-24 23:19 ` Edgar Toernig 2006-01-25 15:38 ` Joerg Schilling 2006-01-24 23:26 ` Matthias Andree 2006-01-24 23:27 ` Matthias Andree 2006-01-25 15:33 ` Joerg Schilling 2006-01-25 16:01 ` Matthias Andree 2006-01-24 10:51 ` Matthias Andree 2006-01-23 20:30 ` Lee Revell 2006-01-23 21:21 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree 2006-01-23 21:26 ` Lee Revell 2006-01-23 21:45 ` Joerg Schilling 2006-01-23 22:00 ` Lee Revell 2006-01-23 21:30 ` Lee Revell 2006-01-23 22:03 ` Joerg Schilling 2006-01-24 13:58 ` Joerg Schilling 2006-01-24 17:42 ` Jan Engelhardt 2006-01-24 18:18 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 2006-01-24 20:54 ` Jan Engelhardt 2006-01-25 15:26 ` Joerg Schilling 2006-01-25 15:13 ` Joerg Schilling 2006-01-25 14:04 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Joerg Schilling 2006-01-25 14:21 ` Jens Axboe 2006-01-25 14:47 ` Jan Engelhardt 2006-01-25 14:55 ` Jens Axboe 2006-01-25 14:58 ` Jens Axboe 2006-01-25 17:00 ` Joerg Schilling 2006-01-25 17:10 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 2006-01-25 17:20 ` Joerg Schilling 2006-01-25 17:27 ` Jens Axboe 2006-01-25 23:19 ` Matthias Andree 2006-01-26 12:30 ` Joerg Schilling 2006-01-26 12:58 ` Matthias Andree 2006-01-26 14:19 ` Joerg Schilling 2006-01-26 21:02 ` Jan Engelhardt 2006-01-26 21:40 ` Matthias Andree 2006-01-25 17:24 ` Jens Axboe 2006-01-26 9:35 ` Joerg Schilling 2006-01-26 9:48 ` Jens Axboe 2006-01-26 10:10 ` Matthias Andree 2006-01-26 14:01 ` Joerg Schilling 2006-01-25 17:23 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Jens Axboe 2006-01-25 16:57 ` Joerg Schilling 2006-01-25 17:20 ` Jens Axboe 2006-01-25 20:16 ` Lee Revell 2006-01-26 21:06 ` Jan Engelhardt 2006-01-26 21:33 ` Vadim Lobanov 2006-01-26 21:48 ` Gene Heskett 2006-01-26 21:34 ` Vadim Lobanov 2006-01-26 12:32 ` Pavel Machek 2006-02-02 17:17 ` Luke-Jr 2006-02-03 14:08 ` Jan Engelhardt 2006-02-03 16:50 ` Joerg Schilling 2006-02-03 17:24 ` Luke-Jr 2006-02-06 13:51 ` Joerg Schilling 2006-02-06 14:01 ` Matthias Andree 2006-02-06 15:06 ` Peter Read 2006-02-06 15:15 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 2006-02-06 20:54 ` Jim Crilly 2006-02-07 13:06 ` Joerg Schilling 2006-02-07 13:18 ` Martin Mares 2006-02-07 13:47 ` Matthias Andree 2006-02-07 18:37 ` Jim Crilly 2006-02-08 13:27 ` Joerg Schilling [not found] ` <20060208084501.7bee86b4.seanlkml@sympatico.ca> 2006-02-08 13:45 ` sean 2006-02-08 13:51 ` Martin Mares 2006-02-08 14:12 ` Keith Duthie 2006-02-08 16:28 ` Jim Crilly 2006-02-08 16:32 ` Joerg Schilling 2006-02-08 16:53 ` Jim Crilly 2006-02-09 9:39 ` Joerg Schilling 2006-02-09 10:00 ` Martin Mares 2006-02-09 23:14 ` Kyle Moffett 2006-02-10 1:52 ` Jim Crilly 2006-02-10 12:24 ` Joerg Schilling 2006-02-10 12:15 ` Joerg Schilling 2006-02-09 12:37 ` D. Hazelton 2006-02-10 13:02 ` Christoph Hellwig 2006-02-17 20:55 ` Bill Davidsen 2006-02-17 21:01 ` Christoph Hellwig 2006-02-18 16:44 ` Bill Davidsen [not found] ` <20060218115802.739dc947.seanlkml@sympatico.ca> 2006-02-18 16:58 ` sean 2006-02-10 16:32 ` Luke-Jr 2006-02-09 10:41 ` Matthias Andree 2006-02-09 13:35 ` Joerg Schilling 2006-02-09 14:00 ` Nick Piggin 2006-02-09 10:50 ` Ralf Müller 2006-02-09 16:30 ` Jan Engelhardt 2006-02-09 16:47 ` Joerg Schilling 2006-02-09 17:15 ` Jan Engelhardt 2006-02-09 17:28 ` Joerg Schilling 2006-02-09 17:36 ` Matthias Andree 2006-02-09 17:37 ` Jan Engelhardt 2006-02-09 21:57 ` CD writing in future Linux Jan Engelhardt 2006-02-10 10:58 ` CD writing in future Linux (stirring up a hornets' nest) Joerg Schilling 2006-02-09 17:36 ` Martin Mares 2006-02-10 10:59 ` Joerg Schilling 2006-02-10 11:47 ` Matthias Andree 2006-02-10 12:35 ` Joerg Schilling 2006-02-09 12:57 ` D. Hazelton 2006-02-10 13:03 ` Joerg Schilling 2006-02-10 3:21 ` D. Hazelton 2006-02-13 13:40 ` Joerg Schilling 2006-02-13 13:52 ` Matthias Andree 2006-02-13 15:15 ` Joerg Schilling 2006-02-13 23:26 ` D. Hazelton 2006-02-13 14:07 ` Martin Mares 2006-02-13 15:29 ` Joerg Schilling 2006-02-13 16:11 ` Jim Crilly 2006-02-13 22:54 ` D. Hazelton 2006-02-14 5:09 ` Alexander Samad 2006-02-13 23:13 ` D. Hazelton 2006-02-10 13:25 ` Dmitry Torokhov 2006-02-10 3:36 ` D. Hazelton 2006-02-10 15:38 ` jerome lacoste 2006-02-10 3:41 ` D. Hazelton 2006-02-13 13:44 ` Joerg Schilling 2006-02-13 14:08 ` jerome lacoste 2006-02-13 15:26 ` Joerg Schilling 2006-02-13 15:47 ` jerome lacoste 2006-02-13 16:19 ` Joerg Schilling 2006-02-13 23:01 ` D. Hazelton 2006-02-14 13:37 ` Joerg Schilling 2006-02-14 14:24 ` Matthias Andree 2006-02-14 16:55 ` Joerg Schilling 2006-02-14 22:27 ` D. Hazelton 2006-02-14 18:43 ` Jim Crilly 2006-02-14 19:06 ` Olivier Galibert 2006-02-14 22:15 ` D. Hazelton 2006-02-14 1:05 ` kernel 2006-02-14 14:03 ` Joerg Schilling 2006-02-10 16:23 ` Gene Heskett 2006-02-12 10:12 ` [ot] Linux heritage (was Re: CD writing in future Linux) Jan Engelhardt 2006-02-13 10:40 ` CD writing in future Linux (stirring up a hornets' nest) Joerg Schilling 2006-02-13 10:52 ` Martin Mares 2006-02-13 14:57 ` Joerg Schilling 2006-02-13 15:03 ` Matthias Andree 2006-02-13 16:29 ` Jan Engelhardt 2006-02-13 16:34 ` Joerg Schilling 2006-02-14 8:08 ` Jan Engelhardt 2006-02-13 16:30 ` Jan Engelhardt 2006-02-14 5:19 ` Marcin Dalecki 2006-02-14 9:20 ` Martin Mares 2006-02-14 10:03 ` D. Hazelton 2006-02-14 15:11 ` Joerg Schilling 2006-02-14 14:25 ` Lennart Sorensen 2006-02-13 12:07 ` jerome lacoste 2006-02-13 15:04 ` Joerg Schilling 2006-02-13 15:24 ` jerome lacoste 2006-02-13 15:49 ` Joerg Schilling 2006-02-13 16:05 ` jerome lacoste 2006-02-13 16:24 ` Joerg Schilling 2006-02-13 16:34 ` Jan Engelhardt 2006-02-13 16:37 ` Joerg Schilling 2006-02-13 19:19 ` Valdis.Kletnieks 2006-02-14 11:48 ` Joerg Schilling 2006-02-14 12:21 ` D. Hazelton 2006-02-14 16:42 ` Joerg Schilling 2006-02-14 16:57 ` grundig 2006-02-14 17:42 ` Joerg Schilling 2006-02-14 22:22 ` D. Hazelton 2006-02-14 12:23 ` Matthias Andree 2006-02-14 22:51 ` Rob Landley 2006-02-14 23:24 ` Olivier Galibert 2006-02-15 0:26 ` Rob Landley 2006-02-15 2:19 ` D. Hazelton 2006-02-15 2:32 ` grundig 2006-02-15 0:04 ` Matthias Andree 2006-02-15 2:55 ` Rob Landley 2006-02-15 6:13 ` Anders Karlsson 2006-02-15 8:37 ` Matthias Andree 2006-02-15 18:31 ` Lennart Sorensen 2006-02-15 19:09 ` Rob Landley 2006-02-15 19:16 ` Doug McNaught 2006-02-15 19:47 ` Rob Landley 2006-02-15 19:50 ` Lennart Sorensen 2006-02-15 21:31 ` Rob Landley 2006-02-17 9:06 ` Helge Hafting 2006-02-17 13:07 ` Matthias Andree 2006-02-17 15:33 ` Jan Engelhardt 2006-02-16 3:06 ` John Stoffel 2006-02-16 3:32 ` Rob Landley 2006-02-16 4:08 ` Alexander Samad 2006-02-17 8:54 ` Helge Hafting [not found] ` <515e525f0602140501j1f9fbe14x8a3eef0bbf179035@mail.gmail.com> 2006-02-14 16:47 ` Joerg Schilling 2006-02-14 17:08 ` Matthias Andree 2006-02-14 18:05 ` Jan Engelhardt 2006-02-14 17:47 ` Lennart Sorensen 2006-02-14 18:42 ` Jim Crilly 2006-02-13 22:01 ` Carlo J. Calica 2006-02-13 16:36 ` Xavier Bestel 2006-02-13 17:12 ` jerome lacoste 2006-02-13 18:12 ` Joerg Schilling 2006-02-14 11:31 ` Joerg Schilling 2006-02-14 12:15 ` D. Hazelton 2006-02-14 16:40 ` Joerg Schilling 2006-02-14 22:12 ` D. Hazelton 2006-02-14 12:43 ` jerome lacoste 2006-02-14 16:45 ` Joerg Schilling 2006-02-13 22:57 ` D. Hazelton 2006-02-13 0:44 ` Alexander Samad 2006-02-13 14:12 ` jerome lacoste 2006-02-10 12:41 ` Martin Mares 2006-02-10 12:59 ` Joerg Schilling 2006-02-10 13:10 ` Jan Engelhardt 2006-02-10 13:22 ` Joerg Schilling 2006-02-10 14:16 ` Theodore Ts'o 2006-02-10 14:32 ` Joerg Schilling 2006-02-10 14:45 ` Christopher Friesen 2006-02-10 14:52 ` Joerg Schilling 2006-02-10 15:13 ` Christopher Friesen 2006-02-10 15:32 ` Chris Shoemaker 2006-02-10 15:53 ` Christopher Friesen 2006-02-10 18:48 ` Chris Shoemaker 2006-02-13 10:33 ` Joerg Schilling 2006-02-13 10:30 ` Joerg Schilling 2006-02-13 10:55 ` Martin Mares 2006-02-13 12:01 ` Matthias Andree 2006-02-14 5:22 ` Marcin Dalecki 2006-02-13 12:14 ` vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)] Xavier Bestel 2006-02-13 12:19 ` forget this maim (vold for linux ? [was: Re: CD writing in future Linux (stirring up a hornets' nest)]) Xavier Bestel 2006-02-13 16:27 ` Jan Engelhardt 2006-02-13 23:35 ` CD writing in future Linux (stirring up a hornets' nest) D. Hazelton 2006-02-10 14:52 ` Theodore Ts'o 2006-02-10 14:54 ` Joerg Schilling 2006-02-10 15:42 ` Erik Mouw 2006-02-10 23:28 ` Marc Koschewski 2006-02-10 15:57 ` Theodore Ts'o 2006-02-13 10:45 ` Joerg Schilling 2006-02-13 12:15 ` Theodore Ts'o 2006-02-13 15:07 ` Joerg Schilling 2006-02-13 15:26 ` Matthias Andree 2006-02-13 16:35 ` Jan Engelhardt 2006-02-10 16:24 ` Diego Calleja 2006-02-13 10:47 ` Joerg Schilling 2006-02-13 15:36 ` Florin Malita 2006-02-13 15:56 ` Joerg Schilling 2006-02-13 16:28 ` Diego Calleja 2006-02-13 16:38 ` Jan Engelhardt 2006-02-13 16:40 ` Florin Malita 2006-02-13 16:43 ` Joerg Schilling 2006-02-13 17:16 ` Luke-Jr 2006-02-10 17:03 ` Nikita Danilov 2006-02-12 10:01 ` Jan Engelhardt 2006-02-13 14:07 ` Joerg Schilling 2006-02-13 14:24 ` Matthias Andree 2006-02-13 16:25 ` Jan Engelhardt 2006-02-13 10:14 ` Joerg Schilling 2006-02-13 10:54 ` Matthias Andree 2006-02-10 22:40 ` Matthias Andree 2006-02-10 11:49 ` DervishD 2006-02-10 11:55 ` Matthias Andree 2006-02-10 12:15 ` DervishD 2006-02-10 12:36 ` Joerg Schilling 2006-02-10 22:43 ` Matthias Andree 2006-02-12 23:17 ` Sam Vilain 2006-02-13 14:29 ` Joerg Schilling 2006-02-13 14:57 ` Matthias Andree [not found] ` <20060213095038.03247484.seanlkml@sympatico.ca> 2006-02-13 14:50 ` sean 2006-02-13 15:36 ` Joerg Schilling [not found] ` <20060213104548.2999033d.seanlkml@sympatico.ca> 2006-02-13 15:45 ` sean 2006-02-13 16:10 ` Martin Mares 2006-02-13 16:26 ` Joerg Schilling [not found] ` <515e525f0602130834h1fd23146laf9daf354b1b8c75@mail.gmail.com> 2006-02-13 16:38 ` Joerg Schilling 2006-02-13 16:44 ` Matthias Andree 2006-02-13 16:50 ` Martin Mares 2006-02-13 16:56 ` Joerg Schilling 2006-02-13 17:14 ` Martin Mares 2006-02-13 17:27 ` Joerg Schilling 2006-02-13 17:37 ` Martin Mares 2006-02-13 20:13 ` Matthias Andree 2006-02-14 8:01 ` Jan Engelhardt 2006-02-13 17:22 ` Luke-Jr 2006-02-13 17:40 ` Joerg Schilling 2006-02-13 17:48 ` newbiz 2006-02-13 17:49 ` Luke-Jr 2006-02-14 11:13 ` Joerg Schilling 2006-02-14 12:08 ` D. Hazelton 2006-02-14 16:35 ` Joerg Schilling 2006-02-14 16:44 ` Matthias Andree 2006-02-14 16:45 ` grundig 2006-02-14 18:00 ` Jan Engelhardt 2006-02-13 19:20 ` Matthias Andree 2006-02-13 23:42 ` D. Hazelton 2006-02-14 8:04 ` Jan Engelhardt 2006-02-14 8:25 ` D. Hazelton 2006-02-14 15:04 ` Joerg Schilling 2006-02-14 16:53 ` Matthias Andree 2006-02-14 17:41 ` Joerg Schilling 2006-02-14 19:49 ` Matthias Andree 2006-02-14 19:56 ` Joerg Schilling 2006-02-14 20:23 ` Matthias Andree 2006-02-14 22:10 ` D. Hazelton 2006-02-16 11:42 ` Joerg Schilling 2006-02-16 11:52 ` Matthias Andree 2006-02-16 18:06 ` Joerg Schilling 2006-02-16 18:14 ` Matthias Andree 2006-02-17 10:29 ` Joerg Schilling 2006-02-17 10:48 ` Martin Mares 2006-02-17 12:09 ` Matthias Andree 2006-02-17 20:45 ` D. Hazelton 2006-02-20 14:59 ` Joerg Schilling 2006-02-20 18:33 ` D. Hazelton 2006-02-21 9:55 ` Joerg Schilling 2006-02-21 23:48 ` D. Hazelton 2006-02-22 17:49 ` Joerg Schilling 2006-02-21 9:30 ` Matthias Andree 2006-02-16 19:26 ` Edgar Toernig 2006-02-17 10:49 ` Joerg Schilling 2006-02-17 13:08 ` Matthias Andree 2006-02-16 22:42 ` D. Hazelton 2006-02-17 11:41 ` Joerg Schilling 2006-02-17 12:01 ` Martin Mares 2006-02-17 13:22 ` Joerg Schilling 2006-02-17 13:40 ` Martin Mares [not found] ` <20060217083710.2dc6879e.seanlkml@sympatico.ca> 2006-02-17 13:37 ` sean 2006-02-17 15:45 ` Jan Engelhardt 2006-02-17 21:52 ` Joerg Schilling 2006-02-17 23:46 ` D. Hazelton 2006-02-17 20:02 ` D. Hazelton 2006-02-17 18:12 ` Matthias Andree 2006-02-20 14:51 ` Joerg Schilling 2006-02-20 15:47 ` Martin Mares 2006-02-20 17:14 ` Matthias Andree 2006-02-20 18:02 ` D. Hazelton 2006-02-21 9:44 ` Joerg Schilling 2006-02-21 10:16 ` Matthias Andree 2006-02-21 11:01 ` Joerg Schilling 2006-02-21 11:46 ` [OT] portable Makefiles (was: CD writing in future Linux (stirring up a hornets' nest)) Matthias Andree 2006-02-22 13:36 ` Joerg Schilling 2006-02-22 14:05 ` Matthias Andree 2006-02-23 12:15 ` Joerg Schilling 2006-02-23 14:57 ` Matthias Andree 2006-02-23 16:49 ` Joerg Schilling 2006-02-23 17:16 ` Matthias Andree 2006-02-24 10:04 ` Joerg Schilling 2006-02-23 15:42 ` D. Hazelton 2006-02-23 16:56 ` Joerg Schilling 2006-02-23 20:36 ` D. Hazelton 2006-02-23 8:12 ` Herbert Poetzl 2006-02-23 13:04 ` linux-os (Dick Johnson) 2006-02-23 16:35 ` Joerg Schilling 2006-02-23 16:42 ` Herbert Poetzl 2006-02-23 17:01 ` Joerg Schilling 2006-02-23 15:48 ` Joerg Schilling 2006-02-23 16:02 ` Tim Walberg 2006-02-23 16:57 ` Joerg Schilling 2006-02-23 17:23 ` Tim Walberg 2006-02-23 17:32 ` Joerg Schilling 2006-02-23 17:53 ` Tim Walberg 2006-02-24 7:08 ` Jan Engelhardt 2006-02-24 10:09 ` Joerg Schilling 2006-02-25 17:44 ` David Weinehall 2006-02-28 7:24 ` David Weinehall 2006-02-28 18:47 ` Joerg Schilling 2006-02-28 19:49 ` Sam Vilain 2006-02-28 20:01 ` David Weinehall 2006-02-28 20:53 ` Sam Vilain 2006-03-01 16:17 ` Joerg Schilling 2006-03-01 17:39 ` Matthias Andree 2006-02-21 23:37 ` CD writing in future Linux (stirring up a hornets' nest) D. Hazelton 2006-02-22 17:13 ` Joerg Schilling 2006-02-22 17:30 ` Matthias Andree 2006-02-13 16:13 ` Matthias Andree 2006-02-13 23:18 ` D. Hazelton 2006-02-14 13:39 ` Joerg Schilling 2006-02-13 0:50 ` Alexander Samad 2006-02-13 14:33 ` Joerg Schilling 2006-02-13 22:12 ` Lennart Sorensen 2006-02-13 23:21 ` D. Hazelton 2006-02-14 8:06 ` Jan Engelhardt 2006-02-09 17:36 ` Jan Engelhardt 2006-02-10 11:02 ` Joerg Schilling 2006-02-10 13:13 ` Jan Engelhardt 2006-02-10 17:32 ` Michael Buesch 2006-02-09 17:15 ` Matthias Andree 2006-02-10 4:49 ` Alexander Samad 2006-02-08 22:52 ` Martin Mares [not found] ` <43EA2A58.9070501@gmx.de> [not found] ` <43EB1067.nail52A2154ZR@burner> 2006-02-09 10:50 ` Matthias Andree 2006-02-09 13:40 ` Joerg Schilling 2006-02-09 15:11 ` DervishD 2006-02-09 15:46 ` Joerg Schilling 2006-02-09 16:32 ` Jan Engelhardt 2006-02-08 21:02 ` DervishD 2006-02-08 21:14 ` Lennart Sorensen 2006-02-08 21:26 ` Matthias Andree 2006-02-09 17:54 ` Lennart Sorensen 2006-02-09 9:02 ` DervishD 2006-02-09 13:31 ` Joerg Schilling 2006-02-09 15:02 ` DervishD 2006-02-09 15:45 ` Joerg Schilling 2006-02-09 15:57 ` Jim Crilly 2006-02-10 5:05 ` Alexander Samad 2006-02-09 10:29 ` Joerg Schilling 2006-02-09 10:53 ` Matthias Andree 2006-02-09 13:42 ` Joerg Schilling 2006-02-09 15:33 ` Matthias Andree 2006-02-09 14:57 ` DervishD 2006-02-09 15:42 ` Joerg Schilling 2006-02-09 16:32 ` Matthias Andree 2006-02-09 17:33 ` DervishD 2006-02-10 10:57 ` Joerg Schilling 2006-02-10 11:45 ` DervishD 2006-02-10 12:33 ` Joerg Schilling 2006-02-10 12:58 ` DervishD 2006-02-09 16:00 ` Jim Crilly 2006-02-09 16:01 ` Joerg Schilling 2006-02-09 16:10 ` Jim Crilly 2006-02-09 16:13 ` Joerg Schilling 2006-02-09 16:26 ` Matthias Andree 2006-02-09 16:30 ` Jim Crilly 2006-02-09 10:27 ` Joerg Schilling 2006-02-09 10:58 ` Matthias Andree 2006-02-09 14:55 ` DervishD 2006-02-06 17:25 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Joerg Schilling 2006-02-07 10:57 ` Matthias Andree 2006-02-06 17:40 ` Luke-Jr 2006-01-23 21:33 ` Rationale for RLIMIT_MEMLOCK? Joerg Schilling 2006-01-23 19:57 ` Lee Revell 2006-01-23 21:34 ` Theodore Ts'o 2006-01-24 11:06 ` Matthias Andree [not found] <5y7B5-1dw-15@gated-at.bofh.it> [not found] ` <5y7KL-1DZ-31@gated-at.bofh.it> [not found] ` <5yddh-1pA-47@gated-at.bofh.it> [not found] ` <5ydni-1Qq-3@gated-at.bofh.it> [not found] ` <5yek1-3iP-53@gated-at.bofh.it> [not found] ` <5yeth-3us-33@gated-at.bofh.it> [not found] ` <5yf5O-4iF-19@gated-at.bofh.it> [not found] ` <5yfI4-5kU-11@gated-at.bofh.it> [not found] ` <5ygE4-6LK-35@gated-at.bofh.it> [not found] ` <5yhqg-7ZR-5@gated-at.bofh.it> [not found] ` <5yi2X-zm-7@gated-at.bofh.it> 2006-01-24 9:14 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Bodo Eggert 2006-01-24 14:38 ` Joerg Schilling
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).