* Re: CD writing in future Linux (stirring up a hornets' nest) @ 2006-01-25 2:58 Albert Cahalan 2006-01-25 16:31 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: Albert Cahalan @ 2006-01-25 2:58 UTC (permalink / raw) To: linux-kernel, schilling, rlrevell, matthias.andree Joerg Schilling writes: > Matthias Andree <matthias.andree@gmx.de> wrote: >> S3 Device enumeration/probing is a sore spot. Unprivileged >> "cdrecord dev=ATA: -scandisk" doesn't work, and recent >> discussions on the cdwrite@ list didn't make any progress. >> My observation is that cdrecord stops probing /dev/hd* devices >> as soon as one yields EPERM, on the assumption "if I cannot >> access /dev/hda, I will not have sufficient privilege to >> write a CD anyways". I find this wrong, Joerg finds it correct >> and argues "if you can access /dev/hdc as unprivileged user, >> that's a security problem". > > This are two problems: > > - users of cdrecord like to run cdrecord -scanbus in order > to find all SCSI devices. This no longer works since the > non-orthogonal /dev/hd* SCSI transport has been added. > > As Linux already implements a Generic SCSI transport > interface (/dev/sg*) people would asume to be able to > talk to _all_ SCSI devices using this interface. > To allows this, there is a need for a SCSI HBA driver > that sends SCSI commands via a ATA interface. > > - some people seem to set the permissions of some of the > /dev/hd* nodes to unsafe values and then complain that > the other /dev/hd* nodes cannot be opened. **sigh** Matthias Andree said "(Joerg, please don't talk about layer violations here)", yet you do. We Linux users will forever patch your software to work the way every Linux app is supposed to work. (well, assuming nobody succumbs to a well-caffeinated urge to fork the code) Really, "users of cdrecord like to run cdrecord -scanbus"??? They LIKE running a command to generate phony SCSI addresses? That's news to me. To better protect users from terrible accidents, Linux should avoid assigning a /dev/sg* device for anything with a regular device file. This, along with elimination of the obsolete ide-scsi crud, would make things a lot more safe and sane. BTW, before Joerg mentions portability, I'd like to remind everyone that all modern OSes support the use of normal device names for SCSI. The most awkward is FreeBSD, where you have to do a syscall or two to translate the name to Joerg's very non-hotplug non-iSCSI way of thinking. Windows, MacOS X, and even Solaris all manage to handle device names just fine. In numerous cases, not just Linux, cdrecord is inventing crap out of thin air to satisfy a pre-hotplug worldview. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 2:58 CD writing in future Linux (stirring up a hornets' nest) Albert Cahalan @ 2006-01-25 16:31 ` Joerg Schilling 2006-01-25 16:56 ` Kyle Moffett 2006-01-26 2:26 ` Albert Cahalan 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-25 16:31 UTC (permalink / raw) To: schilling, rlrevell, matthias.andree, linux-kernel, acahalan Albert Cahalan <acahalan@gmail.com> wrote: > We Linux users will forever patch your software to work the Looks like you are not a native English speaker. "We" is incorrect here, as you only speak for yourself. > BTW, before Joerg mentions portability, I'd like to remind > everyone that all modern OSes support the use of normal device > names for SCSI. The most awkward is FreeBSD, where you have > to do a syscall or two to translate the name to Joerg's very > non-hotplug non-iSCSI way of thinking. Windows, MacOS X, and > even Solaris all manage to handle device names just fine. In > numerous cases, not just Linux, cdrecord is inventing crap out > of thin air to satisfy a pre-hotplug worldview. Looks like you are badly informed, so I encourage you to get yourself informed properly before sending your next postig.... libscg includes 22 different SCSI low level transport implementations. - Only 5 of them allow a /dev/hd* device name related access. - 11 of them use file descriptors as handles for sending SCSI commands but do not have a name <-> fs relation and thus _need_ a SCSI device naming scheme as libscg offers. This is because there is no 1:1 relation between SCSI addressing and a fd retrieved from a /dev/* entry. - 6 of them not even allow to get a file descriptors as handles for sending SCSI commands. These platforms of course need the SCSI device naming scheme as libscg offers. Conclusion: 17 Platforms _need_ the addressing scheme libscg offers 5 Platforms _may_ use a different access method too. NOTE: Amongst the 6 plaforms that do not allow to even get a file descriptor there is a modern OS like MacOS X BTW: the wording of your posting did give you a negative score. If you continue the same way, it may be that your next posting will remain unanswered even though it may be wring and needs a correction like this one. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 16:31 ` Joerg Schilling @ 2006-01-25 16:56 ` Kyle Moffett 2006-01-25 17:08 ` Matthias Andree 2006-01-25 17:14 ` Joerg Schilling 2006-01-26 2:26 ` Albert Cahalan 1 sibling, 2 replies; 717+ messages in thread From: Kyle Moffett @ 2006-01-25 16:56 UTC (permalink / raw) To: Joerg Schilling; +Cc: rlrevell, matthias.andree, linux-kernel, acahalan On Jan 25, 2006, at 11:31, Joerg Schilling wrote: > Albert Cahalan <acahalan@gmail.com> wrote: >> We Linux users will forever patch your software to work the > > Looks like you are not a native English speaker. "We" is incorrect > here, as you only speak for yourself. I agree completely with his statements, therefore he speaks for at least two people and "we" is proper usage. I suspect given the posts on this list the last time this flamewar came up that there are more as well, but 2 is enough. > libscg includes... Irrelevant to the discussion at hand, we are talking only about linux and what should be done on linux. > - Only 5 of them allow a /dev/hd* device name related access. No, you have this wrong: - One of them (IE: Linux) requires a /dev/[hs]d* device-name related access - Only 4 others allow /dev/hd* However, the later is _completely_ _irrelevant_ to the discussion, as we are talking about Linux *only*. > [irrelevant discussion of other platforms] > 17 Platforms _need_ the addressing scheme libscg offers > 5 Platforms _may_ use a different access method too. Wrong again: 17 platforms need libscg's addressing 4 platforms offer /dev/* access 1 platform (Linux) _requires_ /dev/* access You are perfectly free to adjust your compatibility layer accordingly. > BTW: the wording of your posting [...] Personal attacks are offtopic, irrelevant, and rude. Please refrain from doing so. If you don't plan to respond to somebody's email, just don't, no reason to shout about it to a world who doesn't care. Cheers, Kyle Moffett -- Premature optimization is the root of all evil in programming -- C.A.R. Hoare ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 16:56 ` Kyle Moffett @ 2006-01-25 17:08 ` Matthias Andree 2006-01-25 17:18 ` Joerg Schilling 2006-01-25 17:14 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-01-25 17:08 UTC (permalink / raw) To: Kyle Moffett; +Cc: Joerg Schilling, rlrevell, linux-kernel, acahalan Kyle Moffett wrote: > On Jan 25, 2006, at 11:31, Joerg Schilling wrote: >> Albert Cahalan <acahalan@gmail.com> wrote: >>> We Linux users will forever patch your software to work the >> >> Looks like you are not a native English speaker. "We" is incorrect >> here, as you only speak for yourself. > > I agree completely with his statements, therefore he speaks for at > least two people and "we" is proper usage. I suspect given the posts > on this list the last time this flamewar came up that there are more as > well, but 2 is enough. > >> libscg includes... > > Irrelevant to the discussion at hand, we are talking only about linux > and what should be done on linux. Well, cdrecord relies on libscg, so in effect most of the portability code that is affected is in libscg; some of the real-time code however is specific to cdrecord. >> - Only 5 of them allow a /dev/hd* device name related access. > > No, you have this wrong: > > - One of them (IE: Linux) requires a /dev/[hs]d* device-name related > access /dev/sd* for CD writing? I think you're off track here. AFAICS cdrecord uses /dev/sg* to access the writer. > - Only 4 others allow /dev/hd* > > However, the later is _completely_ _irrelevant_ to the discussion, as > we are talking about Linux *only*. This, and if the code can then be used on other platforms, then there is little point in calling the Linux /dev/hd* device "badly designed", unless there were problems with it that prevented cdrecord (or libscg, for pxupdate or something like that) from working properly. So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count. The numbers we get from ide-scsi for ATAPI writers are skewed anyhow, I'm getting 1,0,0 for a SATA hard disk, 2,0,0 for secondary master DVD-RAM/±R[W], 3,0,0 for secondary slave CD-RW... I wonder why these could be desirable, and if they are really as static as they pretend to be. I doubt that, their numbers depend on the order of driver loading. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:08 ` Matthias Andree @ 2006-01-25 17:18 ` Joerg Schilling 2006-01-25 17:30 ` Matthias Andree 2006-01-25 18:17 ` Jens Axboe 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-25 17:18 UTC (permalink / raw) To: mrmacman_g4, matthias.andree; +Cc: schilling, rlrevell, linux-kernel, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > > Irrelevant to the discussion at hand, we are talking only about linux > > and what should be done on linux. > > Well, cdrecord relies on libscg, so in effect most of the portability code > that is affected is in libscg; some of the real-time code however is > specific to cdrecord. This is correct, as (looking at other programs from cdrtools) cdrecord is the only program that needs realtime scheduling. > So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via > ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count. But device enumeration is the central point when implementing -scanbus. Note that all OS that I am aware of internally use a device enumeration scheme that is close to what libscg uses. This ie even true for Linux. If Linux did not hide this information for /dev/hd* based fd's, I could implement an abstraction layer..... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:18 ` Joerg Schilling @ 2006-01-25 17:30 ` Matthias Andree 2006-01-26 9:50 ` Joerg Schilling 2006-01-25 18:17 ` Jens Axboe 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-01-25 17:30 UTC (permalink / raw) To: Joerg Schilling; +Cc: mrmacman_g4, rlrevell, linux-kernel, acahalan Joerg Schilling wrote: >> So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via >> ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count. > > But device enumeration is the central point when implementing -scanbus. Again: Is there anything *besides* (<German>: außer) device enumeration that does not work with the current /dev/hd* SG_IO interface? ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:30 ` Matthias Andree @ 2006-01-26 9:50 ` Joerg Schilling 2006-01-26 10:34 ` jerome lacoste 2006-01-26 11:09 ` Matthias Andree 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 9:50 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: rlrevell, mrmacman_g4, linux-kernel, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling wrote: > > >> So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via > >> ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count. > > > > But device enumeration is the central point when implementing -scanbus. > > Again: Is there anything *besides* (<German>: außer) device enumeration that > does not work with the current /dev/hd* SG_IO interface? This is the main point. People like to run cdrecord -scanbus in order to find a list of usable devices. People like to see all SCSI devices in a single name space as they are all using the same protocol for communication. A sane way to send SCSI commands to _any_ type of devices would be to have a SCSI generic transport layer that is independent from the high-level features of the OS and that is independent from whether there is a high-level driver for this device at all. This is what I designed the scg driver interface for in 1986 and this is what Adaptec did in 1988 with ASPI. This is of course also why the SCSI standard commitee made a proposal for the CAM SCSI interface. http://www.t10.org/ftp/t10/drafts/cam/cam-r12b.pdf http://www.t10.org/ftp/t10/drafts/cam3/cam3r03.pdf Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 9:50 ` Joerg Schilling @ 2006-01-26 10:34 ` jerome lacoste 2006-01-26 14:03 ` Joerg Schilling 2006-01-26 11:09 ` Matthias Andree 1 sibling, 1 reply; 717+ messages in thread From: jerome lacoste @ 2006-01-26 10:34 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, rlrevell, mrmacman_g4, linux-kernel, acahalan On 1/26/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: [...] > People like to run cdrecord -scanbus in order to find a list of usable devices. > People like to see all SCSI devices in a single name space as they are all > using the same protocol for communication. If by people you mean developer, I might agree. If by people you mean user, I disagree. As a Linux user, the only reason I do cdrecord -scanbus is to comply to the cdrecord way of doing likes. I don't personally like it. I'd rather use /dev/cdrw, in a machine independent way, as in: ssh user@host cdrecord dev=/dev/cdrw /path/to/file.iso Jerome ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 10:34 ` jerome lacoste @ 2006-01-26 14:03 ` Joerg Schilling 2006-01-26 18:23 ` Gene Heskett ` (2 more replies) 0 siblings, 3 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 14:03 UTC (permalink / raw) To: schilling, jerome.lacoste Cc: rlrevell, mrmacman_g4, matthias.andree, linux-kernel, acahalan jerome lacoste <jerome.lacoste@gmail.com> wrote: > As a Linux user, the only reason I do cdrecord -scanbus is to comply > to the cdrecord way of doing likes. I don't personally like it. > > I'd rather use /dev/cdrw, in a machine independent way, as in: > > ssh user@host cdrecord dev=/dev/cdrw /path/to/file.iso On the vast majority of OS this does not work. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 14:03 ` Joerg Schilling @ 2006-01-26 18:23 ` Gene Heskett 2006-01-26 19:38 ` jerome lacoste 2006-01-27 5:24 ` Valdis.Kletnieks 2 siblings, 0 replies; 717+ messages in thread From: Gene Heskett @ 2006-01-26 18:23 UTC (permalink / raw) To: linux-kernel On Thursday 26 January 2006 09:03, Joerg Schilling wrote: >jerome lacoste <jerome.lacoste@gmail.com> wrote: >> As a Linux user, the only reason I do cdrecord -scanbus is to comply >> to the cdrecord way of doing likes. I don't personally like it. >> >> I'd rather use /dev/cdrw, in a machine independent way, as in: >> >> ssh user@host cdrecord dev=/dev/cdrw /path/to/file.iso > >On the vast majority of OS this does not work. > >Jörg But from the Joe SixPack user standpoint, he should be able to click to launch the program, and click on the file he wants to put on the cd. The leds on the face of the drive should come on and the cd should come out. All he knows is its that thing with the coffee holder sticking out of the front of the box that he had to remove his beer from to put in the blank cd & he doesn't care, *as long as it works*. You have been offered a way to simplify your interface by many many lines of code, yet you resist, insisting that all other platforms do it your way, when in fact they don't either according to several lengthy threads I've now read on this subject. There are far more winderz users than linux so far, and the winderz interface, except for the actual names used (drive F, what a strange moniker that is) is no more nor less complex, and both _just work_ if properly used. A simple case: statement should handle it all. So whats the problem? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 14:03 ` Joerg Schilling 2006-01-26 18:23 ` Gene Heskett @ 2006-01-26 19:38 ` jerome lacoste 2006-01-27 5:24 ` Valdis.Kletnieks 2 siblings, 0 replies; 717+ messages in thread From: jerome lacoste @ 2006-01-26 19:38 UTC (permalink / raw) To: Joerg Schilling Cc: rlrevell, mrmacman_g4, matthias.andree, linux-kernel, acahalan On 1/26/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > > > As a Linux user, the only reason I do cdrecord -scanbus is to comply > > to the cdrecord way of doing likes. I don't personally like it. > > > > I'd rather use /dev/cdrw, in a machine independent way, as in: > > > > ssh user@host cdrecord dev=/dev/cdrw /path/to/file.iso > > On the vast majority of OS this does not work. 1- I don't care if that works or not on other OSes. This is a fonctionality I expect to work on my target host. 2- cdrecord locks the user inside its own terminology, instead of a being open to the platform, for 'cross-platform compatibility reasons' Sorry but I don't buy any of that. Now, if someone was to provide you with patches to support the Linux way of doing things, keeping all your functionality as it is today, just reorganizing the code in a slightly different way, would you consider looking at the patches? Jerome ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 14:03 ` Joerg Schilling 2006-01-26 18:23 ` Gene Heskett 2006-01-26 19:38 ` jerome lacoste @ 2006-01-27 5:24 ` Valdis.Kletnieks 2006-01-27 13:15 ` Joerg Schilling 2 siblings, 1 reply; 717+ messages in thread From: Valdis.Kletnieks @ 2006-01-27 5:24 UTC (permalink / raw) To: Joerg Schilling Cc: jerome.lacoste, rlrevell, mrmacman_g4, matthias.andree, linux-kernel, acahalan [-- Attachment #1: Type: text/plain, Size: 1034 bytes --] On Thu, 26 Jan 2006 15:03:11 +0100, Joerg Schilling said: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > ssh user@host cdrecord dev=/dev/cdrw /path/to/file.iso > > On the vast majority of OS this does not work. OK.. If "vast majority" is the proper way to decide this issue.. .. What does WinXP call the CD writer device? What's wrong with this picture? Maybe "vast majority" is the wrong criteria... 'cdrecord -scanbus' tells me I'm supposed to use 'dev=0,1,0', which has *zero* meaning to me, since my laptop has no SCSI in it. Fortunately, I also have a /dev/hdb, and 'dev=/dev/hdb' works the way one would expect if they weren't attached to a 1986-style naming scheme for some transport mechanism that isn't present on my hardware. And you know what? I really don't give a flying <fornicate> in a rolling donut what FreeBSD calls the device. If I did, I'd have installed FreeBSD. But I installed a Fedora distro of Linux, and the only sane naming scheme is the one that Fedora uses... [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 5:24 ` Valdis.Kletnieks @ 2006-01-27 13:15 ` Joerg Schilling 2006-01-27 14:09 ` Kyle Moffett 2006-01-27 23:28 ` Matthias Andree 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-27 13:15 UTC (permalink / raw) To: Valdis.Kletnieks, schilling Cc: rlrevell, mrmacman_g4, matthias.andree, linux-kernel, jerome.lacoste, acahalan Valdis.Kletnieks@vt.edu wrote: > And you know what? I really don't give a flying <fornicate> in a rolling donut > what FreeBSD calls the device. If I did, I'd have installed FreeBSD. But I It has been mentioned here many times, you only need to read it. FreeBSD comes with a T-10 (SCSI) compliant CAM interface that uses a multiplex device and dev=b,t,l to address the devices. This is true for _all_ kind of SCSI devices and thus includes ATAPI transport. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 13:15 ` Joerg Schilling @ 2006-01-27 14:09 ` Kyle Moffett 2006-01-27 23:28 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Kyle Moffett @ 2006-01-27 14:09 UTC (permalink / raw) To: Joerg Schilling Cc: Valdis.Kletnieks, rlrevell, matthias.andree, linux-kernel, jerome.lacoste, acahalan On Jan 27, 2006, at 08:15:02, Joerg Schilling wrote: > Valdis.Kletnieks@vt.edu wrote: >> And you know what? I really don't give a flying <fornicate> in a >> rolling donut what FreeBSD calls the device. If I did, I'd have >> installed FreeBSD. > > It has been mentioned here many times, you only need to read it. > > FreeBSD comes with [desc of freebsd SCSI]. Jörg, can you read English properly? Did you read what he wrote at *ALL*? This is EXACTLY why people have been flaming you on this list. He just wrote in sufficiently graphic detail how he doesn't care what FreeBSD does. You promptly replied with a description of FreeBSD. ARE YOU READING WHAT WE TYPE?!?!?! This is it, I give up; you cannot have a reasonable discussion on this list and therefore are only contributing to the noise. Plonk! Cheers, Kyle Moffett ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 13:15 ` Joerg Schilling 2006-01-27 14:09 ` Kyle Moffett @ 2006-01-27 23:28 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-01-27 23:28 UTC (permalink / raw) To: linux-kernel On Fri, 27 Jan 2006, Joerg Schilling wrote: > Valdis.Kletnieks@vt.edu wrote: > > > And you know what? I really don't give a flying <fornicate> in a rolling donut > > what FreeBSD calls the device. If I did, I'd have installed FreeBSD. But I > > It has been mentioned here many times, you only need to read it. > > FreeBSD comes with a T-10 (SCSI) compliant CAM interface that uses a multiplex > device and dev=b,t,l to address the devices. This is true for _all_ kind of > SCSI devices and thus includes ATAPI transport. Is CAM relevant at all for ATAPI, USB, IEEE1394, parport and other transports? Where is the link between ATAPI's SCSI/MMC command set and SCSI CAM standard applying to ATAPI devices? (File name of the standard or latest draft and chapter is sufficient.) -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 9:50 ` Joerg Schilling 2006-01-26 10:34 ` jerome lacoste @ 2006-01-26 11:09 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-01-26 11:09 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, mrmacman_g4, linux-kernel, acahalan Joerg Schilling schrieb am 2006-01-26: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > Joerg Schilling wrote: > > > > >> So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via > > >> ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count. > > > > > > But device enumeration is the central point when implementing -scanbus. > > > > Again: Is there anything *besides* (<German>: außer) device enumeration that > > does not work with the current /dev/hd* SG_IO interface? > > This is the main point. So there is no real reason. > People like to run cdrecord -scanbus in order to find a list of usable devices. > People like to see all SCSI devices in a single name space as they are all > using the same protocol for communication. I find -scanbus rather annoying, particularly since it doesn't scan all buses, I need to query cdrecord for the implemented transports, run -scanbus for each of them again, and everything. I know what device my writer has, SG_IO is sufficiently capable to write CDs, is the declared standard for Linux parallel ATA-PI devices and I want cdrecord to stop pissing at my leg for knowing the device up front. > A sane way to send SCSI commands to _any_ type of devices would be to have a > SCSI generic transport layer that is independent from the high-level features > of the OS and that is independent from whether there is a high-level driver for > this device at all. It appears as though the high-level driver gave you exactly that generic mid-level access. If Linux violates design principles, is none of your business as long as your application works. > This is what I designed the scg driver interface for in 1986 and this is what Yes, 20 years ago. How relevant is this for OSes that needed to be updated in 2005 to support cdrecord again? And what has this got to do with libscg's bogus assumptions ("If I cannot have /dev/hda, I don't need to probe /dev/hdc anyways") after you've agreed that resmgr and similar to allow console users access to ONLY the writer were no major security risk? > Adaptec did in 1988 with ASPI. This is of course also why the SCSI standard > commitee made a proposal for the CAM SCSI interface. We don't have ASPI on Linux, you're digressing. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:18 ` Joerg Schilling 2006-01-25 17:30 ` Matthias Andree @ 2006-01-25 18:17 ` Jens Axboe 1 sibling, 0 replies; 717+ messages in thread From: Jens Axboe @ 2006-01-25 18:17 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, rlrevell, linux-kernel, acahalan On Wed, Jan 25 2006, Joerg Schilling wrote: > > So I'll repeat my question: is there anything that SG_IO to /dev/hd* (via > > ide-cd) cannot do that it can do via /dev/sg*? Device enumeration doesn't count. > > But device enumeration is the central point when implementing > -scanbus. And that's why I state it's useless on Linux. > Note that all OS that I am aware of internally use a device > enumeration scheme that is close to what libscg uses. This ie even > true for Linux. If Linux did not hide this information for /dev/hd* > based fd's, I could implement an abstraction layer..... Not true, Linux has nothing of the sort internally for eg ATAPI devices. I don't know why you think that, but it's simply not true at all. -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 16:56 ` Kyle Moffett 2006-01-25 17:08 ` Matthias Andree @ 2006-01-25 17:14 ` Joerg Schilling 2006-01-25 18:05 ` Kyle Moffett 2006-01-25 23:08 ` Matthias Andree 1 sibling, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-25 17:14 UTC (permalink / raw) To: schilling, mrmacman_g4; +Cc: rlrevell, matthias.andree, linux-kernel, acahalan Kyle Moffett <mrmacman_g4@mac.com> wrote: > > [irrelevant discussion of other platforms] Incorrect, sorry. Do you really make Linux incompatible to the rest of the world? > > 17 Platforms _need_ the addressing scheme libscg offers > > 5 Platforms _may_ use a different access method too. > > Wrong again: > 17 platforms need libscg's addressing > 4 platforms offer /dev/* access > 1 platform (Linux) _requires_ /dev/* access Your last line is wrong > You are perfectly free to adjust your compatibility layer accordingly. The Linux Kernel fols unfortunately artificially hides information for the /dev/hd* interface making exactly this compatibility impossible. > Personal attacks are offtopic, irrelevant, and rude. Please refrain > from doing so. If you don't plan to respond to somebody's email, > just don't, no reason to shout about it to a world who doesn't care. If you are against personal attacks, why didn't you intercede for the postings from Jens Axboe and Albert Cahalan? I am against personal attacks and this is the first time where it tooks more than a day before LKML people started with personal attacks against me. So in principle this is some sort of progress compared to former times. If you like to continue this discussion, I would like you to stay reasonable and help to keep the discussion stay based on technical based arguments. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:14 ` Joerg Schilling @ 2006-01-25 18:05 ` Kyle Moffett 2006-01-26 10:06 ` Joerg Schilling 2006-01-25 23:08 ` Matthias Andree 1 sibling, 1 reply; 717+ messages in thread From: Kyle Moffett @ 2006-01-25 18:05 UTC (permalink / raw) To: Joerg Schilling; +Cc: rlrevell, matthias.andree, linux-kernel, acahalan On Jan 25, 2006, at 12:14:15, Joerg Schilling wrote: > Incorrect, sorry. Do you really make Linux incompatible to the rest > of the world? Why should we care about compatibility with those interfaces? Half our networking stack includes interfaces (like IPTables) that aren't compatible with _BSD_ from which parts of it were derived, let alone with Windows or Solaris. >> 1 platform (Linux) _requires_ /dev/* access > Your last line is wrong No, it is correct. We require /dev/* access. The fact that we included /dev/sg* devices for /dev/[sh]d* was a mistake, and should be fixed, but those are still /dev/* access. >> You are perfectly free to adjust your compatibility layer >> accordingly. > The Linux Kernel fols unfortunately artificially hides information > for the /dev/hd* interface making exactly this compatibility > impossible. We provide enough information for everybody else to be happy, including the dvd+rw-tools package. What else do you need and why? >> Personal attacks are offtopic, irrelevant, and rude. Please >> refrain from doing so. If you don't plan to respond to somebody's >> email, just don't, no reason to shout about it to a world who >> doesn't care. > > If you are against personal attacks, why didn't you intercede for > the postings from Jens Axboe and Albert Cahalan? Because I didn't see them. > I am against personal attacks and this is the first time where it > tooks more than a day before LKML people started with personal > attacks against me. I would encourage you to ignore all personal attacks. The people making them are doing so frequently because either (A) they feel they have been attacked and are retaliating or (B) they don't have a valid technical point to make. In either case the signal-to-noise ratio is better if you ignore the attack and don't respond in turn, which will frequently cause the offending party to cease their attacks as well. One other note: Please do not tell Linux kernel developers that you know what is best for the Linux kernel. If you have a specific bug or a proposed patch it will be thoroughly considered, but vague declarations of problems are insufficient. Cheers, Kyle Moffett ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 18:05 ` Kyle Moffett @ 2006-01-26 10:06 ` Joerg Schilling 2006-01-26 10:40 ` Matthias Andree 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 10:06 UTC (permalink / raw) To: schilling, mrmacman_g4; +Cc: rlrevell, matthias.andree, linux-kernel, acahalan Kyle Moffett <mrmacman_g4@mac.com> wrote: > On Jan 25, 2006, at 12:14:15, Joerg Schilling wrote: > > Incorrect, sorry. Do you really make Linux incompatible to the rest > > of the world? .. > >> 1 platform (Linux) _requires_ /dev/* access > > Your last line is wrong > > No, it is correct. We require /dev/* access. The fact that we > included /dev/sg* devices for /dev/[sh]d* was a mistake, and should > be fixed, but those are still /dev/* access. Looks like you missunderstood /dev/* here. Even with /dev/scg* on Solaris or with CAM on FreeBSD, you open a device. But this is not a /dev/ entry for a high level device like a disk, it is a SCSI nexus device that allows you to send SCSI commands on any SCSI transport. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 10:06 ` Joerg Schilling @ 2006-01-26 10:40 ` Matthias Andree 2006-01-26 14:05 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-01-26 10:40 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, rlrevell, matthias.andree, linux-kernel, acahalan Joerg Schilling schrieb am 2006-01-26: > Even with /dev/scg* on Solaris or with CAM on FreeBSD, you open a device. > But this is not a /dev/ entry for a high level device like a disk, it is > a SCSI nexus device that allows you to send SCSI commands on any SCSI > transport. As long as the device you open allows you to send SCSI commands on any suitable (not just SCSI) transport, why bother? -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 10:40 ` Matthias Andree @ 2006-01-26 14:05 ` Joerg Schilling [not found] ` <20060126103004.07e02876.seanlkml@sympatico.ca> 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 14:05 UTC (permalink / raw) To: schilling, matthias.andree Cc: rlrevell, mrmacman_g4, matthias.andree, linux-kernel, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-01-26: > > > Even with /dev/scg* on Solaris or with CAM on FreeBSD, you open a device. > > But this is not a /dev/ entry for a high level device like a disk, it is > > a SCSI nexus device that allows you to send SCSI commands on any SCSI > > transport. > > As long as the device you open allows you to send SCSI commands on any > suitable (not just SCSI) transport, why bother? If you open e.g. /dev/cam or /dev/scg?, you open device that is not related to a high level service like /dev/hd* and this unfortunately is unable to talk to other devices in the same entity (e.g. ATAPI tapes). With /dev/cam or similar you get a single handle for a group of devices that than are addressed via something very similar to dev=b,t,l Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
[parent not found: <20060126103004.07e02876.seanlkml@sympatico.ca>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <20060126103004.07e02876.seanlkml@sympatico.ca> @ 2006-01-26 15:30 ` sean 0 siblings, 0 replies; 717+ messages in thread From: sean @ 2006-01-26 15:30 UTC (permalink / raw) To: Joerg Schilling Cc: schilling, matthias.andree, rlrevell, mrmacman_g4, linux-kernel, acahalan On Thu, 26 Jan 2006 15:05:42 +0100 Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > If you open e.g. /dev/cam or /dev/scg?, you open device that is not related > to a high level service like /dev/hd* and this unfortunately is unable to talk > to other devices in the same entity (e.g. ATAPI tapes). > > With /dev/cam or similar you get a single handle for a group of devices that > than are addressed via something very similar to dev=b,t,l > So what? Why is it so important to have just a single handle in this case as opposed to multiple handles? Sean ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:14 ` Joerg Schilling 2006-01-25 18:05 ` Kyle Moffett @ 2006-01-25 23:08 ` Matthias Andree 2006-01-26 12:27 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-01-25 23:08 UTC (permalink / raw) To: Joerg Schilling; +Cc: mrmacman_g4, linux-kernel, acahalan Joerg Schilling schrieb am 2006-01-25: > > You are perfectly free to adjust your compatibility layer accordingly. > > The Linux Kernel fols unfortunately artificially hides information for the > /dev/hd* interface making exactly this compatibility impossible. What information is actually missing? You keep talking about phantoms, without naming them. Again: device enumeration doesn't count, libscg already does that. > If you are against personal attacks, why didn't you intercede for the > postings from Jens Axboe and Albert Cahalan? Because ignoring attacks is more efficient. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 23:08 ` Matthias Andree @ 2006-01-26 12:27 ` Joerg Schilling 2006-01-26 16:10 ` Vojtech Pavlik 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 12:27 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: mrmacman_g4, linux-kernel, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-01-25: > > > > You are perfectly free to adjust your compatibility layer accordingly. > > > > The Linux Kernel fols unfortunately artificially hides information for the > > /dev/hd* interface making exactly this compatibility impossible. > > What information is actually missing? You keep talking about phantoms, > without naming them. Again: device enumeration doesn't count, libscg > already does that. I am not talking about phantoms, I am always requestung the same things. It only seems that people here ignore these issues. The only integrative (and this useful for libscg) interface on Linux is /dev/sg* /dev/hd* may look nice if you only look skin-deep How do you e.g. like send SCSI commands to ATAPI tape drives on Linux? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 12:27 ` Joerg Schilling @ 2006-01-26 16:10 ` Vojtech Pavlik 2006-01-26 17:55 ` Olivier Galibert 2006-01-27 14:30 ` Joerg Schilling 0 siblings, 2 replies; 717+ messages in thread From: Vojtech Pavlik @ 2006-01-26 16:10 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, mrmacman_g4, linux-kernel, acahalan On Thu, Jan 26, 2006 at 01:27:59PM +0100, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > Joerg Schilling schrieb am 2006-01-25: > > > > > > You are perfectly free to adjust your compatibility layer accordingly. > > > > > > The Linux Kernel fols unfortunately artificially hides information for the > > > /dev/hd* interface making exactly this compatibility impossible. > > > > What information is actually missing? You keep talking about phantoms, > > without naming them. Again: device enumeration doesn't count, libscg > > already does that. > > I am not talking about phantoms, I am always requestung the same things. > It only seems that people here ignore these issues. > > The only integrative (and this useful for libscg) interface on Linux is /dev/sg* > > /dev/hd* may look nice if you only look skin-deep > > How do you e.g. like send SCSI commands to ATAPI tape drives on Linux? I see you asking this again and again, and you seem to want to hear this answer: "You don't." I haven't checked the code, but I guess the SG_IO interface isn't available there. And I don't think this is a problem, because a) if it was needed, it can be added trivially with minimum added code, b) ATAPI tapes are dead, much the way ATAPI floppies are. So can you now stop repeating this question, please? It has no relevance to CD burning. I admit I can see the elegance in your /dev/scg solution on Solaris, but you should accept that you're not going to get anything like that on Linux, because it simply doesn't fit in the Linux frame of doing things. In Linux we have devices and operate on them. They can be hotplugged and assigned stable names via udev. A tunnel into the transport layer, like your /dev/scg on Solaris, simply doesn't have place in Linux. I believe that if you added Linux 2.6 support code in libscg/cdrecord, that'd simply accept the device name as an argument and didn't use *any* scanning code at all, you'd make a lot of people happy (*). Quite possibly everyone minus one man. Which would be a great achievement. (*) It'd be impossible to burn CDs in a tape drive on Linux then, but, I don't think that'll cause a lot of grief. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 16:10 ` Vojtech Pavlik @ 2006-01-26 17:55 ` Olivier Galibert 2006-01-26 18:10 ` Vojtech Pavlik 2006-01-27 14:30 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Olivier Galibert @ 2006-01-26 17:55 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-kernel On Thu, Jan 26, 2006 at 05:10:28PM +0100, Vojtech Pavlik wrote: > I believe that if you added Linux 2.6 support code in libscg/cdrecord, > that'd simply accept the device name as an argument and didn't use *any* > scanning code at all, you'd make a lot of people happy (*). Quite possibly > everyone minus one man. Which would be a great achievement. Since Jens does not seem available anymore do you know how one is supposed to do the cdrom-ish device enumeration at that point? Is HAL the official kernel interface to that now? OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 17:55 ` Olivier Galibert @ 2006-01-26 18:10 ` Vojtech Pavlik 2006-01-26 18:28 ` Olivier Galibert 0 siblings, 1 reply; 717+ messages in thread From: Vojtech Pavlik @ 2006-01-26 18:10 UTC (permalink / raw) To: Olivier Galibert, linux-kernel On Thu, Jan 26, 2006 at 06:55:07PM +0100, Olivier Galibert wrote: > > I believe that if you added Linux 2.6 support code in libscg/cdrecord, > > that'd simply accept the device name as an argument and didn't use *any* > > scanning code at all, you'd make a lot of people happy (*). Quite possibly > > everyone minus one man. Which would be a great achievement. > > Since Jens does not seem available anymore do you know how one is > supposed to do the cdrom-ish device enumeration at that point? Is HAL > the official kernel interface to that now? The kernel interface is sysfs and hotplug. Udev interfaces that and can be set up so that it assigns /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing the userspace interface. HAL interfaces the above and implements the desktop interface. So for a GUI application it's appropriate to use HAL, while a command line program doesn't need any enumeration, as 'ls /dev/cdrecorder*' should be enough for an experienced user. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 18:10 ` Vojtech Pavlik @ 2006-01-26 18:28 ` Olivier Galibert 2006-01-26 18:38 ` Jan Engelhardt ` (2 more replies) 0 siblings, 3 replies; 717+ messages in thread From: Olivier Galibert @ 2006-01-26 18:28 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-kernel On Thu, Jan 26, 2006 at 07:10:34PM +0100, Vojtech Pavlik wrote: > The kernel interface is sysfs and hotplug. Hotplug, of course, can't be used from a program. As for sysfs, as said in the mail to Jens, I'm not sure how to: - find the devices, what should I scan/filter on. udev seems likes it needs to run a program (/sbin/cdrom_id) or scan /proc/sys/dev/cdrom/info just to know if a device is a cdrom... - find the /dev name associated to a sysfs-found device. > Udev interfaces that and can be set up so that it assigns > /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing > the userspace interface. Problem is, udev doesn't. Or at least it varies from distribution to distribution. For instance recent gentoo creates /dev/cdrom*, /dev/cdrw*, /dev/dvd*, /dev/dvdrw*. Fedora core 3 creates /dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*. I guess from your email that SuSE does /dev/cdrecorder*. And I'm not able to guess what fedora core 5, mandrake, debian, slackware and infinite number of derivatives do. > HAL interfaces the above and implements the desktop interface. I'm not sure how trustable HAL is at that point given what's going on with udev and I'm not too happy to have to require to daemons (dbus system and hald) to run to find the devices, but heh... OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 18:28 ` Olivier Galibert @ 2006-01-26 18:38 ` Jan Engelhardt 2006-01-26 19:07 ` Dmitry Torokhov 2006-01-26 19:22 ` Vojtech Pavlik 2006-01-26 19:21 ` Vojtech Pavlik 2006-01-26 19:28 ` Diego Calleja 2 siblings, 2 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-01-26 18:38 UTC (permalink / raw) To: Olivier Galibert; +Cc: Vojtech Pavlik, linux-kernel >> Udev interfaces that and can be set up so that it assigns >> /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing >> the userspace interface. > >Problem is, udev doesn't. Or at least it varies from distribution to >distribution. For instance recent gentoo creates /dev/cdrom*, >/dev/cdrw*, /dev/dvd*, /dev/dvdrw*. Fedora core 3 creates >/dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*. I guess from >your email that SuSE does /dev/cdrecorder*. And I'm not able to >guess what fedora core 5, mandrake, debian, slackware and infinite >number of derivatives do. Plus you have to think about systems not using udev at all. Cheers, chaos preprogrammed. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 18:38 ` Jan Engelhardt @ 2006-01-26 19:07 ` Dmitry Torokhov 2006-01-26 19:24 ` Vojtech Pavlik 2006-01-26 19:22 ` Vojtech Pavlik 1 sibling, 1 reply; 717+ messages in thread From: Dmitry Torokhov @ 2006-01-26 19:07 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Olivier Galibert, Vojtech Pavlik, linux-kernel On 1/26/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >> Udev interfaces that and can be set up so that it assigns > >> /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing > >> the userspace interface. > > > >Problem is, udev doesn't. Or at least it varies from distribution to > >distribution. For instance recent gentoo creates /dev/cdrom*, > >/dev/cdrw*, /dev/dvd*, /dev/dvdrw*. Fedora core 3 creates > >/dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*. I guess from > >your email that SuSE does /dev/cdrecorder*. And I'm not able to > >guess what fedora core 5, mandrake, debian, slackware and infinite > >number of derivatives do. > The above can be standatrisized (sp?). How is it different from notmal filesystem naming layout? > Plus you have to think about systems not using udev at all. > Cheers, chaos preprogrammed. > We might want to add a new class in sysfs, except we do not allow a device to belong to several classes (we require splittiing it into sub-devices which is not entirely correct in case of DVD+-RW which should belong to classes CD, DVD, DVD-RW, OTOH maybe it is sane to treat it as 3 different sub-devices in one physical package). -- Dmitry ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 19:07 ` Dmitry Torokhov @ 2006-01-26 19:24 ` Vojtech Pavlik 2006-01-26 19:51 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Vojtech Pavlik @ 2006-01-26 19:24 UTC (permalink / raw) To: dtor_core; +Cc: Jan Engelhardt, Olivier Galibert, linux-kernel On Thu, Jan 26, 2006 at 02:07:53PM -0500, Dmitry Torokhov wrote: > On 1/26/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > >> Udev interfaces that and can be set up so that it assigns > > >> /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing > > >> the userspace interface. > > > > > >Problem is, udev doesn't. Or at least it varies from distribution to > > >distribution. For instance recent gentoo creates /dev/cdrom*, > > >/dev/cdrw*, /dev/dvd*, /dev/dvdrw*. Fedora core 3 creates > > >/dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*. I guess from > > >your email that SuSE does /dev/cdrecorder*. And I'm not able to > > >guess what fedora core 5, mandrake, debian, slackware and infinite > > >number of derivatives do. > > > > The above can be standatrisized (sp?). How is it different from notmal > filesystem naming layout? > > > Plus you have to think about systems not using udev at all. > > Cheers, chaos preprogrammed. > > We might want to add a new class in sysfs, except we do not allow a > device to belong to several classes (we require splittiing it into > sub-devices which is not entirely correct in case of DVD+-RW which > should belong to classes CD, DVD, DVD-RW, OTOH maybe it is sane to > treat it as 3 different sub-devices in one > physical package). I don't think there is a reason for a new class. Maybe some attributes, but not a class - they're all the same kind of devices, only plain CD-ROMs can only write CDs at speed 0 ;). -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 19:24 ` Vojtech Pavlik @ 2006-01-26 19:51 ` Jan Engelhardt 0 siblings, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-01-26 19:51 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: dtor_core, Olivier Galibert, linux-kernel >I don't think there is a reason for a new class. Maybe some attributes, >but not a class - they're all the same kind of devices, only plain >CD-ROMs can only write CDs at speed 0 ;). CDROMs incapable of handling unknown media sometimes try to spin them with insane speed, so +Inf would be more accurate. ^_^ Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 18:38 ` Jan Engelhardt 2006-01-26 19:07 ` Dmitry Torokhov @ 2006-01-26 19:22 ` Vojtech Pavlik 1 sibling, 0 replies; 717+ messages in thread From: Vojtech Pavlik @ 2006-01-26 19:22 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Olivier Galibert, linux-kernel On Thu, Jan 26, 2006 at 07:38:37PM +0100, Jan Engelhardt wrote: > >> Udev interfaces that and can be set up so that it assigns > >> /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing > >> the userspace interface. > > > >Problem is, udev doesn't. Or at least it varies from distribution to > >distribution. For instance recent gentoo creates /dev/cdrom*, > >/dev/cdrw*, /dev/dvd*, /dev/dvdrw*. Fedora core 3 creates > >/dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*. I guess from > >your email that SuSE does /dev/cdrecorder*. And I'm not able to > >guess what fedora core 5, mandrake, debian, slackware and infinite > >number of derivatives do. > > Plus you have to think about systems not using udev at all. > Cheers, chaos preprogrammed. Nope. Just let the user specify it. Either the user is experienced enough to know what is the name of the CD recorder on his distro, or he'll use precompiled distribution packages which will have the correct default. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 18:28 ` Olivier Galibert 2006-01-26 18:38 ` Jan Engelhardt @ 2006-01-26 19:21 ` Vojtech Pavlik 2006-01-26 19:28 ` Diego Calleja 2 siblings, 0 replies; 717+ messages in thread From: Vojtech Pavlik @ 2006-01-26 19:21 UTC (permalink / raw) To: Olivier Galibert, linux-kernel On Thu, Jan 26, 2006 at 07:28:18PM +0100, Olivier Galibert wrote: > On Thu, Jan 26, 2006 at 07:10:34PM +0100, Vojtech Pavlik wrote: > > The kernel interface is sysfs and hotplug. > > Hotplug, of course, can't be used from a program. As for sysfs, as > said in the mail to Jens, I'm not sure how to: > > - find the devices, what should I scan/filter on. udev seems likes it > needs to run a program (/sbin/cdrom_id) or scan > /proc/sys/dev/cdrom/info just to know if a device is a cdrom... > > - find the /dev name associated to a sysfs-found device. That's why I said that sysfs/hotplug are kernel interfaces. They are the interfaces the kernel uses to tell the rest of the system what devices are there. They are by no means interfaces that common tools should use. > > Udev interfaces that and can be set up so that it assigns > > /dev/cdrecorder0, 1, ... to evey recorder in the system, implementing > > the userspace interface. > > Problem is, udev doesn't. Or at least it varies from distribution to > distribution. Yes. That is something that can be fixed, though. It's some work, but it's just that - no controversies involved. > For instance recent gentoo creates /dev/cdrom*, > /dev/cdrw*, /dev/dvd*, /dev/dvdrw*. Fedora core 3 creates > /dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*. I guess from > your email that SuSE does /dev/cdrecorder*. And I'm not able to > guess what fedora core 5, mandrake, debian, slackware and infinite > number of derivatives do. That's what LSB and other standards are for. Defining standard filesystem layout for programs to use (this includes /dev !). And that's what also distros are for - setting correct defaults in the programs when they package them. In the end, on a well done distribution it works. And some time after one is created, the distributions do follow the standard, too. > > HAL interfaces the above and implements the desktop interface. > > I'm not sure how trustable HAL is at that point given what's going on > with udev and I'm not too happy to have to require to daemons (dbus > system and hald) to run to find the devices, but heh... It's mostly required if you run GNOME or KDE, so for desktop applications it makes perfect sense. -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 18:28 ` Olivier Galibert 2006-01-26 18:38 ` Jan Engelhardt 2006-01-26 19:21 ` Vojtech Pavlik @ 2006-01-26 19:28 ` Diego Calleja 2006-01-26 19:44 ` Olivier Galibert 2 siblings, 1 reply; 717+ messages in thread From: Diego Calleja @ 2006-01-26 19:28 UTC (permalink / raw) To: Olivier Galibert; +Cc: vojtech, linux-kernel El Thu, 26 Jan 2006 19:28:18 +0100, Olivier Galibert <galibert@pobox.com> escribió: > - find the devices, what should I scan/filter on. udev seems likes it > needs to run a program (/sbin/cdrom_id) or scan > /proc/sys/dev/cdrom/info just to know if a device is a cdrom... Not at all - /sys/devices/pci0000:00/0000:00:0f.1/ide1/1.0/media tells that in my box. cdrom_id is, AFAICS, a way to find the capabilities of the drive (ie, look if it's a cdrom or a dvd, etc) You can get the info even with a fancy output: root@estel# systool -v -b ide Bus = "ide" Device = "0.0" Device path = "/sys/devices/pci0000:00/0000:00:0f.1/ide0/0.0" drivename = "hda" media = "disk" modalias = "ide:m-disk" uevent = <store method only> Device = "1.0" Device path = "/sys/devices/pci0000:00/0000:00:0f.1/ide1/1.0" drivename = "hdc" media = "cdrom" modalias = "ide:m-cdrom" uevent = <store method only> I guess the cdrom driver could in the future be taught to export more data (the previus cdrom drive is really a dvd drive...) to the sysfs interface to know if it's a dvd so that cdrom_id is unnecesary in some cases. > - find the /dev name associated to a sysfs-found device. HAL tells you that the sysfs path associated to a device. root@estel # hal-get-property --udi '/org/freedesktop/Hal/devices/block_HL-DT-ST DVDRAM GSA-4163B-K01544H0250' --key 'block.device' /dev/cd-rw root@estel # (yes, that "udi" path sucks) > /dev/cdrw*, /dev/dvd*, /dev/dvdrw*. Fedora core 3 creates > /dev/cdrom*, /dev/cdwriter*, /dev/dvd*, /dev/dvdwriter*. I guess from > your email that SuSE does /dev/cdrecorder*. And I'm not able to > guess what fedora core 5, mandrake, debian, slackware and infinite > number of derivatives do. Although that sucks, IMO the whole point of udev/hal & friends is to be able to make programs work regardless of what the name of the device is (or at least, if I had to use a program, I would like that the program design is good enought that it just ask the system what cd recorders are connected to the system). ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 19:28 ` Diego Calleja @ 2006-01-26 19:44 ` Olivier Galibert 2006-01-26 20:13 ` Diego Calleja 0 siblings, 1 reply; 717+ messages in thread From: Olivier Galibert @ 2006-01-26 19:44 UTC (permalink / raw) To: Diego Calleja; +Cc: vojtech, linux-kernel On Thu, Jan 26, 2006 at 08:28:32PM +0100, Diego Calleja wrote: > El Thu, 26 Jan 2006 19:28:18 +0100, > Olivier Galibert <galibert@pobox.com> escribió: > > > - find the devices, what should I scan/filter on. udev seems likes it > > needs to run a program (/sbin/cdrom_id) or scan > > /proc/sys/dev/cdrom/info just to know if a device is a cdrom... > > Not at all - /sys/devices/pci0000:00/0000:00:0f.1/ide1/1.0/media > tells that in my box. cdrom_id is, AFAICS, a way to find the > capabilities of the drive (ie, look if it's a cdrom or a dvd, etc) Hmmm, since when? The most recent kernel with a cdrom attached I have handy is a 2.6.14-rc2, and it does not give a "media" entry. /proc/ide has it though. Of course, I'd hoped the point of sysfs and SG_IO was not to have to care whether it's scsi, ide, usb or something else underlying... > > - find the /dev name associated to a sysfs-found device. > > HAL tells you that the sysfs path associated to a device. > > root@estel # hal-get-property --udi '/org/freedesktop/Hal/devices/block_HL-DT-ST DVDRAM GSA-4163B-K01544H0250' --key 'block.device' > /dev/cd-rw > root@estel # > > (yes, that "udi" path sucks) Indeed, since the model is not given in sysfs, at least with 2.6.14-rc2 or previous. There too, /proc/ide has it. I also have no idea what that "GSA" thing is either. > Although that sucks, IMO the whole point of udev/hal & friends is to > be able to make programs work regardless of what the name of the device > is (or at least, if I had to use a program, I would like that the program > design is good enought that it just ask the system what cd recorders are > connected to the system). Me too. But at this point it looks like we have to go back to the good old "scan /dev/hd?, /dev/scd*, /dev/sr*, /dev/sg* and pray". Pity. OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 19:44 ` Olivier Galibert @ 2006-01-26 20:13 ` Diego Calleja 0 siblings, 0 replies; 717+ messages in thread From: Diego Calleja @ 2006-01-26 20:13 UTC (permalink / raw) To: Olivier Galibert; +Cc: vojtech, gregkh, linux-kernel El Thu, 26 Jan 2006 20:44:02 +0100, Olivier Galibert <galibert@pobox.com> escribió: > Hmmm, since when? The most recent kernel with a cdrom attached I have > handy is a 2.6.14-rc2, and it does not give a "media" entry. 2.6.16-rc1 here > Indeed, since the model is not given in sysfs, at least with > 2.6.14-rc2 or previous. There too, /proc/ide has it. I also have no > idea what that "GSA" thing is either. Oops, I got the command wrong, it can tell you the block device *and* the sysfs path if you use the linux.sysfs_path key (which is non portable key I guess from the name). But anyway, it just looked at udev and it can do the same: root@estel 4/home/diego # udevinfo -q path -n /dev/cd-rw /block/hdc (IOW: /sys/block/hdc) ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 16:10 ` Vojtech Pavlik 2006-01-26 17:55 ` Olivier Galibert @ 2006-01-27 14:30 ` Joerg Schilling 2006-01-27 16:44 ` James Courtier-Dutton 1 sibling, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-01-27 14:30 UTC (permalink / raw) Cc: mrmacman_g4, matthias.andree, linux-kernel, acahalan Vojtech Pavlik <vojtech@suse.cz> wrote: > > The only integrative (and this useful for libscg) interface on Linux is /dev/sg* > > > > /dev/hd* may look nice if you only look skin-deep > > > > How do you e.g. like send SCSI commands to ATAPI tape drives on Linux? > > I see you asking this again and again, and you seem to want to hear this > answer: "You don't." I haven't checked the code, but I guess the SG_IO > interface isn't available there. And I don't think this is a problem, > because a) if it was needed, it can be added trivially with minimum > added code, b) ATAPI tapes are dead, much the way ATAPI floppies are. Nice to see that agree that sending SCSI via /dev/hd* is a hack with limited benefit. Maybe (now that we did agree about the way to go) it makes sense to start discussing which bugs in Linux need to be fixed in order to close e.g. the Bugs in the Debian bug tracking system for cdrtools that are related to the Linux kernel. This are the three most important Linux kernel bugs: - ide-scsi does not do DMA if the DMAsize is not a multiple of 512 A person who knows internal Linux structures shoule be able to fix this (and allow any multiple of 4) in less than one hour. If we sum up the time spend on this discussoion, I really cannot understand why this has not been fixed earlier. - /dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN SCSI_IOCTL_GET_BUS_NUMBER from returning useful values. As long as this bug is present, there is no way to see SG_IO via /dev/hd* as integral part of the Linux SCSI transport concept. - If sending SCSI sia ATAPI, Linux under certain unknown conditions bastardizes the content of SCSI commands. A possible reason may be that it sends random data in the remainder between the actual SCSI cdb size and the ATAPI SCSI cdb size. ATAPI drives that verify SCSI cdb's for correctness fail in this case. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 14:30 ` Joerg Schilling @ 2006-01-27 16:44 ` James Courtier-Dutton 2006-01-27 17:01 ` Jan Engelhardt 2006-01-30 11:25 ` Joerg Schilling 0 siblings, 2 replies; 717+ messages in thread From: James Courtier-Dutton @ 2006-01-27 16:44 UTC (permalink / raw) To: Joerg Schilling Cc: no To-header on input, mrmacman_g4, matthias.andree, linux-kernel, acahalan Joerg Schilling wrote: > This are the three most important Linux kernel bugs: > > - ide-scsi does not do DMA if the DMAsize is not a multiple of 512 > A person who knows internal Linux structures shoule be able > to fix this (and allow any multiple of 4) in less than one hour. > If we sum up the time spend on this discussoion, I really cannot > understand why this has not been fixed earlier. > > - /dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN > SCSI_IOCTL_GET_BUS_NUMBER from returning useful values. > As long as this bug is present, there is no way to see SG_IO > via /dev/hd* as integral part of the Linux SCSI transport concept. > > - If sending SCSI sia ATAPI, Linux under certain unknown conditions > bastardizes the content of SCSI commands. A possible reason may be > that it sends random data in the remainder between the actual > SCSI cdb size and the ATAPI SCSI cdb size. > > ATAPI drives that verify SCSI cdb's for correctness fail in this > case. > > Jörg > Would you be able to add the appropriate kernel bugzilla numbers? I think it might also be useful to make a list of all the SCSI commands that cdrecord uses. Including all the vendor specific ones. One could then verify that the Linux kernel is passing them onto the device correctly. James ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 16:44 ` James Courtier-Dutton @ 2006-01-27 17:01 ` Jan Engelhardt 2006-01-30 11:43 ` Joerg Schilling 2006-01-30 11:25 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-01-27 17:01 UTC (permalink / raw) To: James Courtier-Dutton Cc: Joerg Schilling, no To-header on input, mrmacman_g4, matthias.andree, linux-kernel, acahalan >> This are the three most important Linux kernel bugs: >> >> - ide-scsi does not do DMA if the DMAsize is not a multiple of 512 >> A person who knows internal Linux structures shoule be able >> to fix this (and allow any multiple of 4) in less than one hour. >> If we sum up the time spend on this discussoion, I really cannot >> understand why this has not been fixed earlier. Unfortunately, ide-scsi is deemed obsolete in 2.6, so it looks like no one seems to be willing to do that. About 2.4 I'm just as unsure, because it's in it's way to deep freeze. It might go through as a bugfix, though. >> - /dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN >> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values. >> As long as this bug is present, there is no way to see SG_IO via >> /dev/hd* as integral part of the Linux SCSI transport concept. Now you're talking shop ;-) Hm, this ATAPI stuff makes me a headache. Well, anyway, out of curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked for bus number, id or lun - independent of OS and/or cdrecord? >> - If sending SCSI sia ATAPI, Linux under certain unknown conditions >> bastardizes the content of SCSI commands. A possible reason may be >> that it sends random data in the remainder between the actual SCSI >> cdb size and the ATAPI SCSI cdb size. Not so good (the content freakup). IMO, if one can play around with the scsi tunnel (SG_IO) from userspace, commands should get through unmodified. If it's not cdrecord/libscg making my writer do coffee, it must be this modification step. > I think it might also be useful to make a list of all the SCSI commands that > cdrecord uses. Including all the vendor specific ones. One could then verify > that the Linux kernel is passing them onto the device correctly. Or not, for that matter. There is surely a reason for the OS to do something to userspace-provided SG_IO packets to prevent the worst. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 17:01 ` Jan Engelhardt @ 2006-01-30 11:43 ` Joerg Schilling 2006-01-30 12:04 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-30 11:43 UTC (permalink / raw) To: jengelh, James Cc: schilling, mrmacman_g4, matthias.andree, linux-kernel, acahalan, unlisted-recipients:; Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >> This are the three most important Linux kernel bugs: > >> > >> - ide-scsi does not do DMA if the DMAsize is not a multiple of 512 > >> A person who knows internal Linux structures shoule be able > >> to fix this (and allow any multiple of 4) in less than one hour. > >> If we sum up the time spend on this discussoion, I really cannot > >> understand why this has not been fixed earlier. > > Unfortunately, ide-scsi is deemed obsolete in 2.6, so it looks like no one > seems to be willing to do that. About 2.4 I'm just as unsure, because it's > in it's way to deep freeze. It might go through as a bugfix, though. Well, Linux offers a generic SCSI (/dev/sg*) transport, so it should be able to do this in a way that is independent from the SCSI transport. > >> - /dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN > >> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values. > >> As long as this bug is present, there is no way to see SG_IO via > >> /dev/hd* as integral part of the Linux SCSI transport concept. > > Now you're talking shop ;-) > > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked > for bus number, id or lun - independent of OS and/or cdrecord? The drive does not return this information, but the SCSI subsystem creates these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to be known to the SCSI sub-system and thus needs to have a SCSI subsystem related instance number. > >> - If sending SCSI sia ATAPI, Linux under certain unknown conditions > >> bastardizes the content of SCSI commands. A possible reason may be > >> that it sends random data in the remainder between the actual SCSI > >> cdb size and the ATAPI SCSI cdb size. > > Not so good (the content freakup). IMO, if one can play around with the > scsi tunnel (SG_IO) from userspace, commands should get through unmodified. > If it's not cdrecord/libscg making my writer do coffee, it must be this > modification step. ???? > > I think it might also be useful to make a list of all the SCSI commands that > > cdrecord uses. Including all the vendor specific ones. One could then verify > > that the Linux kernel is passing them onto the device correctly. > > Or not, for that matter. There is surely a reason for the OS to do > something to userspace-provided SG_IO packets to prevent the worst. Cdrecord is a program that needs to be able to send any SCSI command as it needs to be able to add new vendor unique commands for new drive/feature support. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 11:43 ` Joerg Schilling @ 2006-01-30 12:04 ` Matthias Andree 2006-01-30 12:23 ` Christoph Hellwig 2006-01-30 16:12 ` Joerg Schilling 2006-01-30 17:38 ` Jürg Billeter 2006-01-30 21:02 ` Bill Davidsen 2 siblings, 2 replies; 717+ messages in thread From: Matthias Andree @ 2006-01-30 12:04 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, James, mrmacman_g4, matthias.andree, linux-kernel, acahalan, unlisted-recipients:; Joerg Schilling schrieb am 2006-01-30: > > >> - /dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN > > >> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values. > > >> As long as this bug is present, there is no way to see SG_IO via > > >> /dev/hd* as integral part of the Linux SCSI transport concept. > > > > Now you're talking shop ;-) > > > > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of > > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked > > for bus number, id or lun - independent of OS and/or cdrecord? > > The drive does not return this information, but the SCSI subsystem creates > these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to > be known to the SCSI sub-system and thus needs to have a SCSI subsystem > related instance number. We are talking about ATA and ATAPI drives here. They may use SCSI commands, but the transport is different. My take is: the Kernel guys have been refusing to invent a non-native enumeration scheme for non-SCSI transports, and you have not provided evidence why this is indispensable. Why is it a *kernel* task to invent SCSI identifier for a non-SCSI transport that does not have such identifiers, in addition to the device name? libscg is already doing it for /dev/hd* and /dev/pg*. How about USB or Firewire or SATA? Do they have ID or LUN? Why isn't libscg simply scanning all transports exhaustively (i. e. not stopping at EPERM) and inventing this itself? You're failing to answer this questions for week now, even though you agreed resmgr or similar setups were safe. How is a user going to tell apart two devices of the same make and model from -scanbus output? The answer is (s)he cannot. Sounds unrealistic? Well, some orchestras sell fresh recordings half an hour after the final chord, with some dozen CD writers... > Cdrecord is a program that needs to be able to send any SCSI command as > it needs to be able to add new vendor unique commands for new drive/feature > support. Right, but evidently it does not need the kernel to invent numbering. dev=/dev/hdc works today. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 12:04 ` Matthias Andree @ 2006-01-30 12:23 ` Christoph Hellwig 2006-01-30 16:15 ` Joerg Schilling 2006-01-30 16:12 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Christoph Hellwig @ 2006-01-30 12:23 UTC (permalink / raw) To: Joerg Schilling, jengelh, James, mrmacman_g4, linux-kernel, acahalan, unlisted-recipients:; On Mon, Jan 30, 2006 at 01:04:08PM +0100, Matthias Andree wrote: > Why is it a *kernel* task to invent SCSI identifier for a non-SCSI > transport that does not have such identifiers, in addition to the device > name? libscg is already doing it for /dev/hd* and /dev/pg*. > How about USB or Firewire or SATA? Do they have ID or LUN? Nothing but SPI (parallel scsi) has a target id. Everything that broadly falls under SAM has luns. Because SPI is dying transport the scsi midlayer will get rid of having a mandatory target id mid-term. Relying on the target id to have any useful meaning is dangerous, it doesn't have a really useful meaning on anything but SPI. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 12:23 ` Christoph Hellwig @ 2006-01-30 16:15 ` Joerg Schilling 2006-02-04 11:17 ` Christoph Hellwig 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-01-30 16:15 UTC (permalink / raw) To: schilling, mrmacman_g4, linux-kernel, jengelh, James, hch, acahalan, unlisted-recipients:; Christoph Hellwig <hch@infradead.org> wrote: > On Mon, Jan 30, 2006 at 01:04:08PM +0100, Matthias Andree wrote: > > Why is it a *kernel* task to invent SCSI identifier for a non-SCSI > > transport that does not have such identifiers, in addition to the device > > name? libscg is already doing it for /dev/hd* and /dev/pg*. > > How about USB or Firewire or SATA? Do they have ID or LUN? > > Nothing but SPI (parallel scsi) has a target id. Everything that broadly > falls under SAM has luns. Because SPI is dying transport the scsi > midlayer will get rid of having a mandatory target id mid-term. Relying > on the target id to have any useful meaning is dangerous, it doesn't > have a really useful meaning on anything but SPI. And now please tell me how you believe this will be inplemented..... Every kernel implementation I am aware of uses device instance numbers and BTW: I am open for any non-dogmatic discussion. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 16:15 ` Joerg Schilling @ 2006-02-04 11:17 ` Christoph Hellwig 0 siblings, 0 replies; 717+ messages in thread From: Christoph Hellwig @ 2006-02-04 11:17 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, linux-kernel, jengelh, James, hch, acahalan, unlisted-recipients:; On Mon, Jan 30, 2006 at 05:15:20PM +0100, Joerg Schilling wrote: > > Nothing but SPI (parallel scsi) has a target id. Everything that broadly > > falls under SAM has luns. Because SPI is dying transport the scsi > > midlayer will get rid of having a mandatory target id mid-term. Relying > > on the target id to have any useful meaning is dangerous, it doesn't > > have a really useful meaning on anything but SPI. > > And now please tell me how you believe this will be inplemented..... There's very little places left that need to know about the target id. A few month ago we had a detailed list on linux-scsi, but off my head these are: - sdev_printk prints the device identifier which right now includes the target id. this will become a transport class callout so the transport can print transport-specific information - various scanning interfaces (scsi_scan_host_selected, scsi_scan_target, scsi_add_device) require a channel id. scsi_scan_target will lose the id parameter because it doesn't even need it, the others will move out of the core into the spi transport class or another module for all spi-like drivers, as lots of RAID HBAs want SPI-like scanning - starget_for_each_device does id comparims currently, but it can be changed to iterate the targets parent devices list easily. with those smaller bits the scsi core doesn't need to know about the target id anymore. now all this is rather pointless as you really love your scheme and don't want to change anyway, so let's stop this discussion ;-) ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 12:04 ` Matthias Andree 2006-01-30 12:23 ` Christoph Hellwig @ 2006-01-30 16:12 ` Joerg Schilling 2006-01-30 16:30 ` Matthias Andree 2006-01-30 16:35 ` Jeff Garzik 1 sibling, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-30 16:12 UTC (permalink / raw) To: schilling, matthias.andree Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan, unlisted-recipients:; Matthias Andree <matthias.andree@gmx.de> wrote: > > Cdrecord is a program that needs to be able to send any SCSI command as > > it needs to be able to add new vendor unique commands for new drive/feature > > support. > > Right, but evidently it does not need the kernel to invent numbering. > dev=/dev/hdc works today. Maybe, I will need to enforce to use official libscg device names in future.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 16:12 ` Joerg Schilling @ 2006-01-30 16:30 ` Matthias Andree 2006-01-30 16:34 ` Joerg Schilling 2006-01-30 16:35 ` Jeff Garzik 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-01-30 16:30 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, acahalan Joerg Schilling schrieb am 2006-01-30: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > Cdrecord is a program that needs to be able to send any SCSI command as > > > it needs to be able to add new vendor unique commands for new drive/feature > > > support. > > > > Right, but evidently it does not need the kernel to invent numbering. > > dev=/dev/hdc works today. > > Maybe, I will need to enforce to use official libscg device names in future.... If you deem fighting your own user base the appropriate behavior to enforce your distorted view on groups that outnumber you by at least five orders of magnitude, go right ahead. But don't complain if you're losing control that way because Albert or somebody else really forks cdrecord then and the fork becomes more popular than the original. cdrecord wouldn't be the first package to see such things happen. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 16:30 ` Matthias Andree @ 2006-01-30 16:34 ` Joerg Schilling 2006-01-30 17:05 ` Matthias Andree 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-01-30 16:34 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: matthias.andree, linux-kernel, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > > > Right, but evidently it does not need the kernel to invent numbering. > > > dev=/dev/hdc works today. > > > > Maybe, I will need to enforce to use official libscg device names in future.... > > If you deem fighting your own user base the appropriate behavior to > enforce your distorted view on groups that outnumber you by at least > five orders of magnitude, go right ahead. > > But don't complain if you're losing control that way because Albert or > somebody else really forks cdrecord then and the fork becomes more > popular than the original. Many people announced forks in the past, nobody so far did contribute real work... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 16:34 ` Joerg Schilling @ 2006-01-30 17:05 ` Matthias Andree 2006-02-01 15:01 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-01-30 17:05 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, acahalan Joerg Schilling schrieb am 2006-01-30: > Many people announced forks in the past, nobody so far did contribute real > work... Only the DVD patches... -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 17:05 ` Matthias Andree @ 2006-02-01 15:01 ` Jan Engelhardt 0 siblings, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-01 15:01 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, linux-kernel, acahalan >> Many people announced forks in the past, nobody so far did contribute real >> work... > >Only the DVD patches... > Which don't always work. I remember SUSE Linux's pomped-up cdrecord-blahdvd thing can't even do DVD-Plus-*, not to mention DVD-DL (some sort of DVD-Plus). Jan Engelhardt -- | Software Engineer and Linux/Unix Network Administrator | Alphagate Systems, http://alphagate.hopto.org/ | jengelh's site, http://jengelh.hopto.org/ ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 16:12 ` Joerg Schilling 2006-01-30 16:30 ` Matthias Andree @ 2006-01-30 16:35 ` Jeff Garzik 2006-01-30 16:46 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Jeff Garzik @ 2006-01-30 16:35 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, mrmacman_g4, linux-kernel, jengelh, James, acahalan, unlisted-recipients:; Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > >>>Cdrecord is a program that needs to be able to send any SCSI command as >>>it needs to be able to add new vendor unique commands for new drive/feature >>>support. >> >>Right, but evidently it does not need the kernel to invent numbering. >>dev=/dev/hdc works today. > > > Maybe, I will need to enforce to use official libscg device names in future.... To burden users with yet another naming policy? Jeff ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 16:35 ` Jeff Garzik @ 2006-01-30 16:46 ` Joerg Schilling 2006-02-01 15:06 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-01-30 16:46 UTC (permalink / raw) To: schilling, jgarzik Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan, unlisted-recipients:; Jeff Garzik <jgarzik@pobox.com> wrote: > >>>Cdrecord is a program that needs to be able to send any SCSI command as > >>>it needs to be able to add new vendor unique commands for new drive/feature > >>>support. > >> > >>Right, but evidently it does not need the kernel to invent numbering. > >>dev=/dev/hdc works today. > > > > > > Maybe, I will need to enforce to use official libscg device names in future.... > > To burden users with yet another naming policy? Well, I am open to have an unbiased discussion that may have any result but the parties should allow each other to convince by arguments. The main problem currently is that changes in the Linux kernel did burden cdrecord users and did not cause real benefit. The longer this discussion lasts, the more I lose the hope that it may end in useful results. If you believe that there is still a chance, let us start with a useful discussion or stop it now. I am just tired to see that none of the Linux kernel bugs that cause problems for the cdrecord users have been fixed within the last ~ 3 years. Please understand that I really could use my time for better things than wasting it with useless discussions with people that don't even understand the problems. If you have a proposal that could help, you are welcome. But if there is no way to have an unbiased discussion, just let os stop now. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 16:46 ` Joerg Schilling @ 2006-02-01 15:06 ` Jan Engelhardt 2006-02-01 17:01 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-02-01 15:06 UTC (permalink / raw) To: Joerg Schilling Cc: jgarzik, mrmacman_g4, matthias.andree, linux-kernel, James, acahalan, unlisted-recipients:; >> >>>Cdrecord is a program that needs to be able to send any SCSI command as >> >>>it needs to be able to add new vendor unique commands for new drive/feature >> >>>support. >> >> >> >>Right, but evidently it does not need the kernel to invent numbering. >> >>dev=/dev/hdc works today. >> > >> > Maybe, I will need to enforce to use official libscg device names in future.... >> >> To burden users with yet another naming policy? > >Well, I am open to have an unbiased discussion that may have any result but >the parties should allow each other to convince by arguments. > The user should use what the OS uses. Cdrecord, or libscg, respectively, can invent any numbers it wants. IOW, "we" (read: I) would like to see cdrecord -dev=/dev/hdc on Linux I am not sure if I understood your other mail on the cdrecord ML, but if the proper syntax would be cdrecord -dev=/dev/hdc:@ then /dev/hdc could just be transparently turned into /dev/hdc:@ somewhere within the getopt part. for other OS: cdrecord -dev=/dev/acd0 on FreeBSD cdrecord -dev=E: on Win32 cdrecord -dev=\\cdrom0 if someone really wants for Win32 cdrecord -dev=/dev/c0t0s0d0 on Solaris (Don't shoot me. I unfortunately have to make a guess, since I have not done yet any cdrecord'ing[1] on OS other than Linux.) [1] Well with Nero, but that's not cdrecord, as in "cdrecord'ing". :) Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 15:06 ` Jan Engelhardt @ 2006-02-01 17:01 ` Joerg Schilling 2006-02-02 16:17 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-01 17:01 UTC (permalink / raw) To: schilling, jengelh Cc: mrmacman_g4, matthias.andree, linux-kernel, jgarzik, James, acahalan, unlisted-recipients:; Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > The user should use what the OS uses. Cdrecord, or libscg, respectively, > can invent any numbers it wants. IOW, "we" (read: I) would like to see > cdrecord -dev=/dev/hdc on Linux Unsupported > I am not sure if I understood your other mail on the cdrecord ML, but if > the proper syntax would be > cdrecord -dev=/dev/hdc:@ > then > /dev/hdc > could just be transparently turned into > /dev/hdc:@ > somewhere within the getopt part. See complete description, the :@ is not just for fun.... > for other OS: > cdrecord -dev=/dev/acd0 on FreeBSD Will not work > cdrecord -dev=E: on Win32 Will only wbe doable with mapping effort in a few cases. > cdrecord -dev=\\cdrom0 if someone really wants for Win32 cdrecord dev=cdrom0 works on Solaris because "cdrom0" is a valid nick name for the drive. > cdrecord -dev=/dev/c0t0s0d0 on Solaris May work sometimes. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 17:01 ` Joerg Schilling @ 2006-02-02 16:17 ` Jan Engelhardt 2006-02-03 11:32 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-02-02 16:17 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, jgarzik, James, acahalan, unlisted-recipients:; [-- Attachment #1: Type: TEXT/PLAIN, Size: 949 bytes --] > >> I am not sure if I understood your other mail on the cdrecord ML, but if >> the proper syntax would be >> cdrecord -dev=/dev/hdc:@ >> then >> /dev/hdc >> could just be transparently turned into >> /dev/hdc:@ >> somewhere within the getopt part. > >See complete description, the :@ is not just for fun.... > "If the name of the device node that has been speci■ fied on such a system refers to exactly one SCSI device, a shorthand in the form dev= devicename:@ or dev= devicename:@,lun may be used instead of dev= devicename:scsibus,target,lun." So @ is equal to 0,0,0 or 0,0? Threads indicated that every device under linux is "exactly one SCSI device", which is why I was asking for this behind-the-scenes translation of /dev/hdc into /dev/hdc:@. >> for other OS: >> cdrecord -dev=/dev/acd0 on FreeBSD > >Will not work > I think mount uses this syntax (`mount /dev/acd0 /mnt`). Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 16:17 ` Jan Engelhardt @ 2006-02-03 11:32 ` Joerg Schilling 2006-02-03 13:45 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 11:32 UTC (permalink / raw) To: schilling, jengelh Cc: mrmacman_g4, matthias.andree, linux-kernel, jgarzik, James, acahalan, unlisted-recipients:; Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > >> I am not sure if I understood your other mail on the cdrecord ML, but if > >> the proper syntax would be > >> cdrecord -dev=/dev/hdc:@ > >> then > >> /dev/hdc > >> could just be transparently turned into > >> /dev/hdc:@ > >> somewhere within the getopt part. > > > >See complete description, the :@ is not just for fun.... > > > > "If the name of the device node that has been speciâ? > fied on such a system refers to exactly one SCSI device, a shorthand in > the form dev= devicename:@ or dev= devicename:@,lun may be used instead > of dev= devicename:scsibus,target,lun." > > So @ is equal to 0,0,0 or 0,0? ":@" is a shorthand for ":@,0" which is a shorthand for ":@0,0" There are cases where you may like to use e.g. ":@,3" Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 11:32 ` Joerg Schilling @ 2006-02-03 13:45 ` Jan Engelhardt 0 siblings, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-03 13:45 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, jgarzik, James, acahalan, unlisted-recipients:; >> >> So @ is equal to 0,0,0 or 0,0? > >":@" is a shorthand for ":@,0" which is a shorthand for ":@0,0" > >There are cases where you may like to use e.g. ":@,3" > So, since Linux currently does not have anything but ":@,0" per device (device file)... Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 11:43 ` Joerg Schilling 2006-01-30 12:04 ` Matthias Andree @ 2006-01-30 17:38 ` Jürg Billeter 2006-01-31 10:30 ` Joerg Schilling 2006-01-30 21:02 ` Bill Davidsen 2 siblings, 1 reply; 717+ messages in thread From: Jürg Billeter @ 2006-01-30 17:38 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, James, mrmacman_g4, matthias.andree, linux-kernel, acahalan Hi Jörg On Mon, 2006-01-30 at 12:43 +0100, Joerg Schilling wrote: > > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of > > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked > > for bus number, id or lun - independent of OS and/or cdrecord? > > The drive does not return this information, but the SCSI subsystem creates > these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to > be known to the SCSI sub-system and thus needs to have a SCSI subsystem > related instance number. Whenever someone talks about ATAPI drives, you respond with s/ATAPI/SCSI/. Why do you insist that every transport should be used as it was a SCSI bus? ATAPI drives use the same SCSI command set as SCSI drives do, but that won't change the fact that ATAPI drives are not connected to a SCSI bus. It makes sense to address parallel SCSI devices via target id. If an operating system likes to simulate virtual SCSI buses for other bus types as well, ok, I have no objections. But if the operating system doesn't like to simulate virtual SCSI buses and allows applications to address devices by a filename, you should have no objections, too. You and the linux developers just look at the same thing from two perspectives. You seem to like SCSI buses, so you want to look at every bus as it is was a SCSI bus. The linux developers seem to like the principle of looking at single devices without obvious connection to a physical or virtual bus from the application. There is no right or wrong, here, that are just two different perspectives. As the linux developers seem to like their approach - I do as well -, they won't change their system and recommend application developers to use SG_IO on device nodes and ignore the physical bus the devices are connected with. Whatever the interface between cdrecord and libscg is, is obviously your choice. But the libscg backend for linux should follow the recommendations of the linux kernel developers and they recommend to use SG_IO on device nodes, AFAICT. The command line interface of cdrecord is obviously your choice again but IMO it should integrate in the system it currently runs on and as linux command line users know how to deal with device nodes, they want to use them. As you were having the SCSI-only perspective in mind when writing the scanbus functionality, it obviously doesn't fit well in the scheme of the device-based perspective of linux. As there is no virtual parent of all real and virtual SCSI buses in linux, libscg shouldn't try to find one. The linux backend of libscg should just use HAL to enumerate the devices. It would be nice to get a comment whether this makes sense or which statements you don't agree with. Schönen Abend Jürg -- Jürg Billeter <j@bitron.ch> ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 17:38 ` Jürg Billeter @ 2006-01-31 10:30 ` Joerg Schilling 2006-01-31 11:11 ` Martin Mares ` (4 more replies) 0 siblings, 5 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-31 10:30 UTC (permalink / raw) To: schilling, j Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan Jürg Billeter <j@bitron.ch> wrote: > Hi Jörg > > On Mon, 2006-01-30 at 12:43 +0100, Joerg Schilling wrote: > > > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of > > > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked > > > for bus number, id or lun - independent of OS and/or cdrecord? > > > > The drive does not return this information, but the SCSI subsystem creates > > these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to > > be known to the SCSI sub-system and thus needs to have a SCSI subsystem > > related instance number. > > Whenever someone talks about ATAPI drives, you respond with > s/ATAPI/SCSI/. Why do you insist that every transport should be used as > it was a SCSI bus? ATAPI drives use the same SCSI command set as SCSI > drives do, but that won't change the fact that ATAPI drives are not > connected to a SCSI bus. Well, this is simple: it is SCSI. When SCSI started from modifying the SASI (Shugart Asociated System Interface) system around 1984 and at that time come with it's own transport only (a 50 wire cable), this did change soon (around 1986) by introducing transports that use one or two 68 wire cable(s) (16 resp. 32 Bit SCSI). Around 1990, even this did change while ATAPI (ATA Packet Interface) was introduced. Around 1995, the T10 standard group (SCSI) did split up the SCSI standard into a transport specific part and a protocol specific part. SCSI is now using many different transport mechanisms. This is a list of some known SCSI transports: - Good old Parallel SCSI 50/68 pin (what most people call SCSI) - SCSI over fiber optics (e.g. FACL - there are others too) - SCSI over a copper variant of FCAL (used in modern servers) - SCSI over IEEE 1394 (Fire Wire) - SCSI over USB - SCSI over IDE/ATA (ATAPI) - SCSI over TCI/IP (iSCSI) - SCSI over SSCSI (see below) SCSI over Serial SCSI cabling uses the same transport (cable type) as SATA uses. If you buy a SATA HBA card for your PC, you may connect SSCSI & SATA disks to this HBA using the same cables and connectors. So the circle is closing again.... > It makes sense to address parallel SCSI devices via target id. If an > operating system likes to simulate virtual SCSI buses for other bus > types as well, ok, I have no objections. But if the operating system > doesn't like to simulate virtual SCSI buses and allows applications to > address devices by a filename, you should have no objections, too. It seems that you missunderstand this. No operating system uses file names internally. OS instead typically handle SCSI devices that are not connected via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system by asuming they are all on separate SCSI busses that only have one single drive conected each. What Linux does is to artificially prevent this view to been seen from outside the Linux kernel, or to avoid integrating a particular device into a unique SCSI driver system although it would be apropriate. Users like to be able to get a list of posible targets for a single protocol. Nobody would ever think about trying to prevent people from getting a unified view on the list possible hosts that talk TCP/IP. What cdrecord does with -scanbus is nothing really different. In addition, nobody would ever think about implementing a separate TCP/IP stack for network interfaces that are PPP connections via a modem vs. network interfaces that go via a Ethernet adaptor. Nobody would ever try to convince me that you could save code in the kernel by avoiding the usual network stack as a specific machine may not have Ethernet but a Modem connection only. So why do people try to convince me that there is a need to avoid the standard SCSI protocol stack because a PC might have only ATAPI? Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, ...). Why do people believe that Linux needs to be different? What does it buy you to go this way? *] MS-WIN-NT even includes SCSI emulation (it allows you to connect to the SCSI subsystem, set the Address and use SCSI commands from a limited list to read/write sector from ATA only hard disks). If the Linux folks could give technical based explanations for the questions from above and if they would create a new completely orthogonal view on SCSI [*] I had no problem. But up to now, the only answer was: "We do it this way because we do it this way". *] Note that this would need to implement SCSI Generic support for drives that have no native driver in the system. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 10:30 ` Joerg Schilling @ 2006-01-31 11:11 ` Martin Mares 2006-01-31 13:27 ` Joerg Schilling 2006-01-31 12:10 ` Bartlomiej Zolnierkiewicz ` (3 subsequent siblings) 4 siblings, 1 reply; 717+ messages in thread From: Martin Mares @ 2006-01-31 11:11 UTC (permalink / raw) To: Joerg Schilling Cc: j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan Hello Jörg! > It seems that you missunderstand this. No operating system uses file names > internally. That's right. OS kernels usually use pointers for that, which are surely not a reasonable user-space API. On Linux, the user-space API is to address devices by their names. > OS instead typically handle SCSI devices that are not connected > via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system > by asuming they are all on separate SCSI busses that only have one single drive > conected each. > > What Linux does is to artificially prevent this view to been seen from outside the > Linux kernel, or to avoid integrating a particular device into a unique SCSI > driver system although it would be apropriate. How exactly does Linux prevent this??? The devices _are_ integrated in a single driver system, at least from the user-space point of view. You can call open() on the device name and then send the appropriate ioctl's. The device names are just strings you shouldn't assume anything about. Feel free to imagine that every device is on its own bus, nothing in the kernel steps in your way. > Users like to be able to get a list of posible targets for a single protocol. > Nobody would ever think about trying to prevent people from getting a unified > view on the list possible hosts that talk TCP/IP. How do you perform -scanbus for TCP/IP? :-) > In addition, nobody would ever think about implementing a separate TCP/IP stack > for network interfaces that are PPP connections via a modem vs. network > interfaces that go via a Ethernet adaptor. Nobody would ever try to convince > me that you could save code in the kernel by avoiding the usual network stack > as a specific machine may not have Ethernet but a Modem connection only. There is an interesting similarity: in the TCP/IP stack, you also shouldn't assume anything about names of network interfaces, they are just opaque identifiers (in many times assigned by the administrator, not by the kernel). The right way of addressing is by IP addresses or DNS names, which is pretty similar to the addressing of SCSI devices on Linux, isn't it? > If the Linux folks could give technical based explanations for the questions > from above and if they would create a new completely orthogonal view on SCSI [*] > I had no problem. But up to now, the only answer was: "We do it this > way because we do it this way". We do it this way, because we see no sense in fabricating virtual SCSI buses, which do not exist in reality. Also, I don't see a single reason why should I refer to my CD drive by different names depending on whether I am mounting a CDROM and if I am burning a CD. The device is still the same and so should be its name. Scanning for all available CD burners is of course a nice feature, but I don't think it should be implemented by asking all existing SCSI-like devices if they are a CD burner (for example because there can be an almost infinite number of them, given that you can do SCSI-over-IP and other similar tricks). The problem of presenting devices to the users is in no way limited to CD burners or SCSI devices, it's a general problem and I think we should try to find a complete solution. However, the approach libscg uses is clearly not applicable to other domains. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 11:11 ` Martin Mares @ 2006-01-31 13:27 ` Joerg Schilling 2006-01-31 13:41 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-31 13:27 UTC (permalink / raw) To: schilling, mj Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan Martin Mares <mj@ucw.cz> wrote: > > What Linux does is to artificially prevent this view to been seen from outside the > > Linux kernel, or to avoid integrating a particular device into a unique SCSI > > driver system although it would be apropriate. > > How exactly does Linux prevent this??? By not treating ATAPI the same as all other SCSI devices. > > Users like to be able to get a list of posible targets for a single protocol. > > Nobody would ever think about trying to prevent people from getting a unified > > view on the list possible hosts that talk TCP/IP. > > How do you perform -scanbus for TCP/IP? :-) There are various programs that do that for you. You could e.g. send a ping to the broadcast address in order to find hosts that are on the local network. > > In addition, nobody would ever think about implementing a separate TCP/IP stack > > for network interfaces that are PPP connections via a modem vs. network > > interfaces that go via a Ethernet adaptor. Nobody would ever try to convince > > me that you could save code in the kernel by avoiding the usual network stack > > as a specific machine may not have Ethernet but a Modem connection only. > > There is an interesting similarity: in the TCP/IP stack, you also shouldn't > assume anything about names of network interfaces, they are just opaque > identifiers (in many times assigned by the administrator, not by the kernel). > The right way of addressing is by IP addresses or DNS names, which is > pretty similar to the addressing of SCSI devices on Linux, isn't it? If you understand this, why then insists other people in using names like /dev/hd*? > Scanning for all available CD burners is of course a nice feature, but > I don't think it should be implemented by asking all existing SCSI-like > devices if they are a CD burner (for example because there can be an > almost infinite number of them, given that you can do SCSI-over-IP > and other similar tricks). The problem of presenting devices to the And while this kind of scanning works in case that you have all devices integrated inside a single SCSI implementation, it does not work for ATAPI because someont artificially decided to exclude one single SCSI transport from the global view. And regarding iSCSI, If you like to talk to such a device, you need to authentificate first. This is typically done by the kernel that in turn trnaferres the remote iSCSI device into a virtual local SCSI device. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 13:27 ` Joerg Schilling @ 2006-01-31 13:41 ` Matthias Andree 2006-01-31 13:42 ` Martin Mares 2006-02-01 15:19 ` Jan Engelhardt 2 siblings, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-01-31 13:41 UTC (permalink / raw) To: Joerg Schilling; +Cc: mj, linux-kernel, acahalan [stripping Cc: list] Joerg Schilling schrieb am 2006-01-31: > Martin Mares <mj@ucw.cz> wrote: > > > > What Linux does is to artificially prevent this view to been seen from outside the > > > Linux kernel, or to avoid integrating a particular device into a unique SCSI > > > driver system although it would be apropriate. > > > > How exactly does Linux prevent this??? > > By not treating ATAPI the same as all other SCSI devices. Nonsense. cdrecord can access ATAPI devices, fix your libscg device enumeration. > > How do you perform -scanbus for TCP/IP? :-) > > There are various programs that do that for you. > You could e.g. send a ping to the broadcast address in order to find hosts > that are on the local network. Responding to broadcast ping, at least when outside the LAN, is considered a security issue. > > Scanning for all available CD burners is of course a nice feature, but > > I don't think it should be implemented by asking all existing SCSI-like > > devices if they are a CD burner (for example because there can be an > > almost infinite number of them, given that you can do SCSI-over-IP > > and other similar tricks). The problem of presenting devices to the > > And while this kind of scanning works in case that you have all devices > integrated inside a single SCSI implementation, it does not work for ATAPI > because someont artificially decided to exclude one single SCSI transport > from the global view. You need to work around this anyhow because the already-released 2.6 kernels will not be going away in the next 2 - 3 years even if 2.6 were fixed today. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 13:27 ` Joerg Schilling 2006-01-31 13:41 ` Matthias Andree @ 2006-01-31 13:42 ` Martin Mares 2006-02-01 15:19 ` Jan Engelhardt 2 siblings, 0 replies; 717+ messages in thread From: Martin Mares @ 2006-01-31 13:42 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan Hello! > > How exactly does Linux prevent this??? > > By not treating ATAPI the same as all other SCSI devices. Sorry, but that's false. Not treating ATAPI the same can at most complicate it, but in no way prevent. > > How do you perform -scanbus for TCP/IP? :-) > > There are various programs that do that for you. > You could e.g. send a ping to the broadcast address in order to find hosts > that are on the local network. Eh, so you are just going to treate the local network differently? ;-) > If you understand this, why then insists other people in using names like > /dev/hd*? Because at least on Linux, the NAMES are the primary identifier for user space, not numbers of some virtual SCSI buses which don't exist in the real world anyway. For everything else (well, except network interfaces, but that's a different story), we refer by names. Even when using the SCSI devices for other purposes, we refer to them by names. Why should burning a CD be different? I believe that this is the crucial question and the one you should answer first, before trying to force others to share your view of the world. > And while this kind of scanning works in case that you have all devices > integrated inside a single SCSI implementation, it does not work for ATAPI > because someont artificially decided to exclude one single SCSI transport > from the global view. No, you are just wrongly considering something to be a global view, which it in fact isn't. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth How do I type 'for i in *.dvi ; do xdvi $i ; done' in a GUI? ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 13:27 ` Joerg Schilling 2006-01-31 13:41 ` Matthias Andree 2006-01-31 13:42 ` Martin Mares @ 2006-02-01 15:19 ` Jan Engelhardt 2006-02-01 21:49 ` Ian Kester-Haney 2006-02-02 9:42 ` Joerg Schilling 2 siblings, 2 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-01 15:19 UTC (permalink / raw) To: Joerg Schilling Cc: mj, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan >> > Users like to be able to get a list of posible targets for a single protocol. >> > Nobody would ever think about trying to prevent people from getting a unified >> > view on the list possible hosts that talk TCP/IP. >> >> How do you perform -scanbus for TCP/IP? :-) > >There are various programs that do that for you. >You could e.g. send a ping to the broadcast address in order to find hosts >that are on the local network. ping is ICMP/IP, therefore is not relevant to the question ;) `nmap -sT` would probably do more TCP. >If you understand this, why then insists other people in using names like >/dev/hd*? It's shorter than /dev/c0t0d0s0? Well, I think it's because people think in terms of connectors (my drive is IDE therefore it must be hdc) rather than protocol (my drive does ATAPI therefore it must be /dev/scsi/c0t0d0s0). Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 15:19 ` Jan Engelhardt @ 2006-02-01 21:49 ` Ian Kester-Haney 2006-02-02 9:42 ` Joerg Schilling 1 sibling, 0 replies; 717+ messages in thread From: Ian Kester-Haney @ 2006-02-01 21:49 UTC (permalink / raw) To: linux-kernel Shouldn't actively developed applications use the current methods for accessing ddevices on target operating systems. It seems to me that linux/gnu users are moving away from cdrecord and it ilk because of the artificial limitations imposed by its libscg counterpart. Backward compatibility is being phased out in the linux kernel to allow for better ways to access and use devices in the system. While the technical nature of transport specifications might be tracked down to an underlying SCSI mechanism, it is by no means an exclusive deal. Perhaps linux doesn't need cdrecord and this whole mess will go away. Real users don't care as long as it works, even the old kernel used /dev/* names. Give it up. --------------------------------------------- Only morons respond to flames guilty as charged ---------------------------------------------- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 15:19 ` Jan Engelhardt 2006-02-01 21:49 ` Ian Kester-Haney @ 2006-02-02 9:42 ` Joerg Schilling 2006-02-02 9:54 ` Martin Mares 2006-02-02 10:14 ` Matthias Andree 1 sibling, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-02 9:42 UTC (permalink / raw) To: schilling, jengelh Cc: mrmacman_g4, mj, matthias.andree, linux-kernel, James, j, acahalan Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > It's shorter than /dev/c0t0d0s0? Well, I think it's because people think > in terms of connectors (my drive is IDE therefore it must be hdc) rather > than protocol (my drive does ATAPI therefore it must be > /dev/scsi/c0t0d0s0). Is there any reason why the people with small PCs should dominate the people with big machines? If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks. The systematical attempt is easy to remember even with a big amount of external hardware. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 9:42 ` Joerg Schilling @ 2006-02-02 9:54 ` Martin Mares 2006-02-02 10:14 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Martin Mares @ 2006-02-02 9:54 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan Hello! > Is there any reason why the people with small PCs should dominate the > people with big machines? > > If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks. And this is why the current Linux naming scheme (udev etc.) gives you the possibility to use both types of names. When I have a single CD writer, it's silly to have to think about where exactly it is connected. I refer to it as /dev/cdrw and everything is easy. When I have multiple writers, I start to care about more -- but usually it's still better to avoid using bus addresses (they are not too stable -- after changing disks, I often end up with connecting my 2 CDWR's to different controllers) and use udev to maintain stable naming. I use /dev/cdrom-upper and /dev/cdrom-lower, which are assigned based on manufacturer and serial number. This is even easier to remember with a big amount of hardware :-) And, which is more important, this scheme works for everything -- drives, mice, network interfaces and so on. I don't see any reason why cdrecord on Linux should invent a different naming scheme, especially as nobody has so far demonstrated any of its advantages. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth MIPS: Meaningless Indicator of Processor Speed. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 9:42 ` Joerg Schilling 2006-02-02 9:54 ` Martin Mares @ 2006-02-02 10:14 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-02 10:14 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, mrmacman_g4, mj, matthias.andree, linux-kernel, James, j, acahalan Joerg Schilling schrieb am 2006-02-02: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > It's shorter than /dev/c0t0d0s0? Well, I think it's because people think > > in terms of connectors (my drive is IDE therefore it must be hdc) rather > > than protocol (my drive does ATAPI therefore it must be > > /dev/scsi/c0t0d0s0). > > Is there any reason why the people with small PCs should dominate the > people with big machines? No side should dominate. > If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks. I don't see how a letter such as /dev/hdo /dev/hdp /dev/hdq is much different than an opaque number tuple as 1,15,0 1,16,0 1,17,0... either is a string with systematic generation, and that's about it. I'm still wondering why mtst (mid-layer access to control tape drives) is happy with /dev/nst0 nst1 ... (device name) and cdrecord (or its author) isn't. cdrecord or libscg should be agnostic of these schemas and take any opaque string that works properly for the given system without complaining. It can invent any numbering scheme it likes, but requesting that the kernel does it if it has no further use for it is barking up the wrong tree. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 10:30 ` Joerg Schilling 2006-01-31 11:11 ` Martin Mares @ 2006-01-31 12:10 ` Bartlomiej Zolnierkiewicz 2006-01-31 13:35 ` Joerg Schilling 2006-01-31 12:24 ` jerome lacoste ` (2 subsequent siblings) 4 siblings, 1 reply; 717+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2006-01-31 12:10 UTC (permalink / raw) To: Joerg Schilling Cc: j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Jürg Billeter <j@bitron.ch> wrote: > > > Hi Jörg > > > > On Mon, 2006-01-30 at 12:43 +0100, Joerg Schilling wrote: > > > > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of > > > > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked > > > > for bus number, id or lun - independent of OS and/or cdrecord? > > > > > > The drive does not return this information, but the SCSI subsystem creates > > > these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to > > > be known to the SCSI sub-system and thus needs to have a SCSI subsystem > > > related instance number. > > > > Whenever someone talks about ATAPI drives, you respond with > > s/ATAPI/SCSI/. Why do you insist that every transport should be used as > > it was a SCSI bus? ATAPI drives use the same SCSI command set as SCSI > > drives do, but that won't change the fact that ATAPI drives are not > > connected to a SCSI bus. > > Well, this is simple: it is SCSI. > > When SCSI started from modifying the SASI (Shugart Asociated System Interface) > system around 1984 and at that time come with it's own transport only > (a 50 wire cable), this did change soon (around 1986) by introducing > transports that use one or two 68 wire cable(s) (16 resp. 32 Bit SCSI). > > Around 1990, even this did change while ATAPI (ATA Packet Interface) was > introduced. > > Around 1995, the T10 standard group (SCSI) did split up the SCSI standard > into a transport specific part and a protocol specific part. SCSI is now using > many different transport mechanisms. > > This is a list of some known SCSI transports: > > - Good old Parallel SCSI 50/68 pin (what most people call SCSI) > - SCSI over fiber optics (e.g. FACL - there are others too) > - SCSI over a copper variant of FCAL (used in modern servers) > - SCSI over IEEE 1394 (Fire Wire) > - SCSI over USB > - SCSI over IDE/ATA (ATAPI) > - SCSI over TCI/IP (iSCSI) > - SCSI over SSCSI (see below) > > SCSI over Serial SCSI cabling uses the same transport (cable type) as SATA uses. > If you buy a SATA HBA card for your PC, you may connect SSCSI & SATA > disks to this HBA using the same cables and connectors. > > So the circle is closing again.... > > > > It makes sense to address parallel SCSI devices via target id. If an > > operating system likes to simulate virtual SCSI buses for other bus > > types as well, ok, I have no objections. But if the operating system > > doesn't like to simulate virtual SCSI buses and allows applications to > > address devices by a filename, you should have no objections, too. > > It seems that you missunderstand this. No operating system uses file names > internally. OS instead typically handle SCSI devices that are not connected > via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system > by asuming they are all on separate SCSI busses that only have one single drive > conected each. > > What Linux does is to artificially prevent this view to been seen from outside the > Linux kernel, or to avoid integrating a particular device into a unique SCSI > driver system although it would be apropriate. > > Users like to be able to get a list of posible targets for a single protocol. > Nobody would ever think about trying to prevent people from getting a unified > view on the list possible hosts that talk TCP/IP. What cdrecord does with > -scanbus is nothing really different. Yes and it is Linux limitation (lets face it). There are 2 problems: * no generic block layer transport infrastructure so that you cannot specify in the low-level driver which transport types your device does support (this information would be exported to the applications). Jens, maybe sysfs attribute "transports" will be sufficient so that application can use libsysfs to get full list of devices supporting "SCSI" transport (/dev/hd* is fine with this scheme). Does it make sense? Having block layer sysfs attributes for device type (disk, tape, cd etc) would have additional bonus of not needing to inquire wrong device types. This would probably simplify other applications (HAL?). [ These are just quick ideas... ] Joerg, I don't see any sense in providing users with fake SCSI lun and bus numbers for ATAPI devices. I think that what users would like is the list of devices consisting of "fd" and actual vendor name of device (+ optionally serial no + optionally "x:y:z" for real SCSI). Nobody wants to see some artificial "x:y:z" for her/his ATAPI device (it has always annoyed me in Windows), not to say that the majority of desktop users have absolutely no idea of meaning of these numbers. * ide-* drivers for ATAPI devices are needed (some devices just doesn't work with ide-scsi ATM) so please accept this fact that we cannot just now simply switch over everything to using ide-scsi and we have to use SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add support for it). I'm not saying this won't change in future but this requires doing actual work and people seem to be more interested in discussing stupid naming issues than doing it so... > In addition, nobody would ever think about implementing a separate TCP/IP stack > for network interfaces that are PPP connections via a modem vs. network > interfaces that go via a Ethernet adaptor. Nobody would ever try to convince > me that you could save code in the kernel by avoiding the usual network stack > as a specific machine may not have Ethernet but a Modem connection only. > > So why do people try to convince me that there is a need to avoid the standard > SCSI protocol stack because a PC might have only ATAPI? SCSI protocol stack is far too Parallel SCSI centric (vide SAS flamewar). Once again this is Linux problem which will get fixed with time or will fix itself if we switch to libata for PATA. > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, > ...). Why do people believe that Linux needs to be different? What does it buy > you to go this way? Linux needs to be better, no? ;-) > *] MS-WIN-NT even includes SCSI emulation (it allows you to connect to the > SCSI subsystem, set the Address and use SCSI commands from a limited list > to read/write sector from ATA only hard disks). > > If the Linux folks could give technical based explanations for the questions > from above and if they would create a new completely orthogonal view on SCSI [*] > I had no problem. But up to now, the only answer was: "We do it this > way because we do it this way". The answer is - we do this this way because of historical reasons and we simply lack resources to change it immediately (be it your "everything is SCSI" or mine "block layer devices claiming supported transport types"). Please also note things don't change because you say so - they require somebody doing actual work and work/time is not free (despite what some people think). If you think that badmouthing Linux will motivate people to work, you are wrong (it has the opposite effect of time wasting flamewars). I would like you to ask to remove warnings from about /dev/hd* interface from cdrecored - they are just confusing users. This is the current way of doing things in Linux and applications have to deal with it for now. Thanks, Bartlomiej > *] Note that this would need to implement SCSI Generic support for drives that > have no native driver in the system. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 12:10 ` Bartlomiej Zolnierkiewicz @ 2006-01-31 13:35 ` Joerg Schilling 2006-01-31 13:42 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-31 13:35 UTC (permalink / raw) To: schilling, bzolnier Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote: > Joerg, I don't see any sense in providing users with fake SCSI > lun and bus numbers for ATAPI devices. I think that what users > would like is the list of devices consisting of "fd" and actual vendor > name of device (+ optionally serial no + optionally "x:y:z" for real > SCSI). Nobody wants to see some artificial "x:y:z" for her/his > ATAPI device (it has always annoyed me in Windows), not to say > that the majority of desktop users have absolutely no idea of meaning > of these numbers. This is called integration and it is done by Linux e.g. for 1394 and USB SCSI devices. So why not for ATAPI? > * ide-* drivers for ATAPI devices are needed (some devices just doesn't > work with ide-scsi ATM) so please accept this fact that we cannot just > now simply switch over everything to using ide-scsi and we have to use > SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add > support for it). I'm not saying this won't change in future but this requires > doing actual work and people seem to be more interested in discussing > stupid naming issues than doing it so... Well, the problem with ide-scsi is not a general one but caused by a simple bug that needs to be fixed. > > So why do people try to convince me that there is a need to avoid the standard > > SCSI protocol stack because a PC might have only ATAPI? > > SCSI protocol stack is far too Parallel SCSI centric (vide SAS flamewar). > Once again this is Linux problem which will get fixed with time or will fix > itself if we switch to libata for PATA. If this is true for Linux, it should be fixed. But this is not a general problem. > > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, > > ...). Why do people believe that Linux needs to be different? What does it buy > > you to go this way? > > Linux needs to be better, no? ;-) In case that Linux would offer better methods, I would not complain. > > If the Linux folks could give technical based explanations for the questions > > from above and if they would create a new completely orthogonal view on SCSI [*] > > I had no problem. But up to now, the only answer was: "We do it this > > way because we do it this way". > > The answer is - we do this this way because of historical reasons and we > simply lack resources to change it immediately (be it your "everything is > SCSI" or mine "block layer devices claiming supported transport types"). This is obviously not true: There _was_ (and still is) a useful implementation with minor bugs. But instead of fixing the minor bugs, a lot of work has been done to introduce a new and unneded new interface. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 13:35 ` Joerg Schilling @ 2006-01-31 13:42 ` Matthias Andree 2006-01-31 13:49 ` Martin Mares 2006-01-31 14:23 ` Bartlomiej Zolnierkiewicz 2 siblings, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-01-31 13:42 UTC (permalink / raw) To: Joerg Schilling Cc: bzolnier, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan Joerg Schilling schrieb am 2006-01-31: > > Linux needs to be better, no? ;-) > > In case that Linux would offer better methods, I would not complain. Well, you are closing your eyes before these methods. I'm not going to repeat that. I suggest that the discussion end here because you are evidently unwilling to look at the pointers you were given. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 13:35 ` Joerg Schilling 2006-01-31 13:42 ` Matthias Andree @ 2006-01-31 13:49 ` Martin Mares 2006-01-31 14:23 ` Bartlomiej Zolnierkiewicz 2 siblings, 0 replies; 717+ messages in thread From: Martin Mares @ 2006-01-31 13:49 UTC (permalink / raw) To: Joerg Schilling Cc: bzolnier, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan Hello! > This is obviously not true: There _was_ (and still is) a useful implementation > with minor bugs. But instead of fixing the minor bugs, a lot of work has been > done to introduce a new and unneded new interface. Some would say that ide-scsi is the thing which was new and unneeded. The ide-cd driver was there first. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Even nostalgia isn't what it used to be. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 13:35 ` Joerg Schilling 2006-01-31 13:42 ` Matthias Andree 2006-01-31 13:49 ` Martin Mares @ 2006-01-31 14:23 ` Bartlomiej Zolnierkiewicz 2006-02-01 15:34 ` Jan Engelhardt 2 siblings, 1 reply; 717+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2006-01-31 14:23 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote: > > > Joerg, I don't see any sense in providing users with fake SCSI > > lun and bus numbers for ATAPI devices. I think that what users > > would like is the list of devices consisting of "fd" and actual vendor > > name of device (+ optionally serial no + optionally "x:y:z" for real > > SCSI). Nobody wants to see some artificial "x:y:z" for her/his > > ATAPI device (it has always annoyed me in Windows), not to say > > that the majority of desktop users have absolutely no idea of meaning > > of these numbers. > > This is called integration and it is done by Linux e.g. for 1394 and USB SCSI > devices. So why not for ATAPI? Because we have native drivers which do not require SCSI stack et all. > > * ide-* drivers for ATAPI devices are needed (some devices just doesn't > > work with ide-scsi ATM) so please accept this fact that we cannot just > > now simply switch over everything to using ide-scsi and we have to use > > SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add > > support for it). I'm not saying this won't change in future but this requires > > doing actual work and people seem to be more interested in discussing > > stupid naming issues than doing it so... > > Well, the problem with ide-scsi is not a general one but caused by a simple > bug that needs to be fixed. Please _reread_ this paragraph: * some devices (not cd-writers) doesn't work with ide-scsi * they require quirks which are in ide-cd so it ide-cd needs to stay as a driver * if is very useful if cd-writing can be done with ide-cd and without SCSI stack (a hack but very useful one) [ more below ] > > > If the Linux folks could give technical based explanations for the questions > > > from above and if they would create a new completely orthogonal view on SCSI [*] > > > I had no problem. But up to now, the only answer was: "We do it this > > > way because we do it this way". > > > > The answer is - we do this this way because of historical reasons and we > > simply lack resources to change it immediately (be it your "everything is > > SCSI" or mine "block layer devices claiming supported transport types"). > > This is obviously not true: There _was_ (and still is) a useful implementation > with minor bugs. But instead of fixing the minor bugs, a lot of work has been > done to introduce a new and unneded new interface. >From technical point of view: pros: * you don't need SCSI stack (a lot of code saved!) * you use subsystem native driver (a lot of complexity with locking etc avoided!) * you don't need to provide users with fake data (SCSI lun and bus) cons: * user-space applications need to support it What are the _technical_ problems with SG_IO interface besides issue with enumaration of devices available in the system? I know that you don't like SG_IO but it is hardly technical argument. Thanks, Bartlomiej ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 14:23 ` Bartlomiej Zolnierkiewicz @ 2006-02-01 15:34 ` Jan Engelhardt 2006-02-01 15:49 ` Bartlomiej Zolnierkiewicz 2006-02-02 9:49 ` Joerg Schilling 0 siblings, 2 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-01 15:34 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz Cc: Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan >> >> This is called integration and it is done by Linux e.g. for 1394 and USB SCSI >> devices. So why not for ATAPI? > >Because we have native drivers which do not require SCSI stack et all. > >* if [ED: it] is very useful if cd-writing can be done with ide-cd and without > SCSI stack (a hack but very useful one) >* you don't need SCSI stack (a lot of code saved!) Which unfortunately leads us back to one of the early questions. If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code floating around? Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 15:34 ` Jan Engelhardt @ 2006-02-01 15:49 ` Bartlomiej Zolnierkiewicz 2006-02-02 9:49 ` Joerg Schilling 1 sibling, 0 replies; 717+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2006-02-01 15:49 UTC (permalink / raw) To: Jan Engelhardt Cc: Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan On 2/1/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >> > >> This is called integration and it is done by Linux e.g. for 1394 and USB SCSI > >> devices. So why not for ATAPI? > > > >Because we have native drivers which do not require SCSI stack et all. > > > >* if [ED: it] is very useful if cd-writing can be done with ide-cd and without > > SCSI stack (a hack but very useful one) > >* you don't need SCSI stack (a lot of code saved!) > > > Which unfortunately leads us back to one of the early questions. > > If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used > without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code > floating around? No, because this code belongs to the block layer (scsi_ioctl.c) and is shared between SCSI and IDE drivers. BTW This was already at least once explained in this thread. Bartlomiej ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 15:34 ` Jan Engelhardt 2006-02-01 15:49 ` Bartlomiej Zolnierkiewicz @ 2006-02-02 9:49 ` Joerg Schilling 2006-02-02 10:20 ` Matthias Andree ` (3 more replies) 1 sibling, 4 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-02 9:49 UTC (permalink / raw) To: jengelh, bzolnier Cc: schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > Which unfortunately leads us back to one of the early questions. > > If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used > without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code > floating around? CONFIG_SCSI??? Why not using fully dynamical loadable kernel modules as done with Solaris since 1992? Since that time nobody cares because what you need is auto-loaded on demand and there is absolutely no need for a manual configuration. BTW: Introducing an orthogonal SCSI based implementation would save a lot of code. The model currently used on Linux is duplicating a lot of unneeded code in target drivers and the SCSI glue code is only a few KB (less than 30k on Solaris). Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 9:49 ` Joerg Schilling @ 2006-02-02 10:20 ` Matthias Andree 2006-02-02 11:28 ` Joerg Schilling 2006-02-02 10:21 ` Martin Mares ` (2 subsequent siblings) 3 siblings, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-02 10:20 UTC (permalink / raw) To: Joerg Schilling; +Cc: bzolnier, linux-kernel Joerg Schilling schrieb am 2006-02-02: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > Which unfortunately leads us back to one of the early questions. > > > > If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used > > without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code > > floating around? > > CONFIG_SCSI??? > > Why not using fully dynamical loadable kernel modules as done with Solaris > since 1992? Since that time nobody cares because what you need is auto-loaded > on demand and there is absolutely no need for a manual configuration. You mean: Module Size Used by ... scsi_transport_spi 20864 1 sym53c8xx scsi_mod 131304 7 st,sr_mod,sg,sym53c8xx,scsi_transport_spi,libata,sd_mod ... autoloaded on boot, and scsi_mod has verbose sense strings built in (call it bloat, but on a Peeceeh a few kB don't hurt). libata is Linux's SATA driver, still under development but quite solid for some chips, such as via 82*. Chances are that adding PATA to libata (which is planned or in the works) obsoletes your whole ATAPI ide-* module arguments, sym53c8xx - no surprise - the host adaptor driver, sr/sd_mod the CD-ROM and disk block drivers, st and sg tape and generic drivers. > BTW: Introducing an orthogonal SCSI based implementation would save a lot of > code. The model currently used on Linux is duplicating a lot of unneeded code > in target drivers and the SCSI glue code is only a few KB (less than 30k on > Solaris). You've been stating this oft enough now. It won't change in a day even if you post this every hour. Please cease posting the same stuff over and over again. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 10:20 ` Matthias Andree @ 2006-02-02 11:28 ` Joerg Schilling 2006-02-02 12:46 ` Martin Mares 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-02 11:28 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel, bzolnier Matthias Andree <matthias.andree@gmx.de> wrote: > > BTW: Introducing an orthogonal SCSI based implementation would save a lot of > > code. The model currently used on Linux is duplicating a lot of unneeded code > > in target drivers and the SCSI glue code is only a few KB (less than 30k on > > Solaris). > > You've been stating this oft enough now. It won't change in a day even > if you post this every hour. Please cease posting the same stuff over > and over again. Why do you repeat posting false claims over and over? May be we should really stop this thread. Unless I see any move towards a more realistic way of looking at things it does not make sense to repeat things and short time later I will see the same unadequate replies as I did see days before. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 11:28 ` Joerg Schilling @ 2006-02-02 12:46 ` Martin Mares 0 siblings, 0 replies; 717+ messages in thread From: Martin Mares @ 2006-02-02 12:46 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, bzolnier Hello Joerg! > > > BTW: Introducing an orthogonal SCSI based implementation would save a lot of > > > code. The model currently used on Linux is duplicating a lot of unneeded code > > > in target drivers and the SCSI glue code is only a few KB (less than 30k on > > > Solaris). > > > > You've been stating this oft enough now. It won't change in a day even > > if you post this every hour. Please cease posting the same stuff over > > and over again. > > Why do you repeat posting false claims over and over? This is getting ridiculous. Point to a single false claim in the mail you were replying to. The only claim there was that you are posting the same stuff again and again, and it is obviously true, as can be demostrated by anybody who can use grep. > Unless I see any move towards a more realistic way of looking at things > it does not make sense to repeat things and short time later I will see > the same unadequate replies as I did see days before. Yes. You have been repeatedly asked to produce any sound arguments why the current interface is bad. So far, you have produced none. You have only written about Linux not following your personal model of virtual SCSI buses, which is maybe a good argument for supporting your dislike for Linux, but nothing else. Also, you mentioned several phantoms like IDE tapes, which nobody seems to care about, a couple of bugs which the driver developers were willing to fix if you tell how to reproduce them. Finally, you mentioned problems with scanning and you were told that: (1) the current scanning code in libscg works at least for all currently existing transports, if a trivial bug is fixed, (2) for a complete view of the available HW, you should use the HAL, (3) most people prefer either using a GUI interface which converges to using HAL anyway, or refer to devices by their names. The rest was just hand-waving. The interface preferred by Linux has changed for very good reasons, and a number of such reasons has been demonstrated. Also, it's not changing daily, the switchover from emulating SCSI to performing SG_IO directly on /dev/hd* was the only big change in last 10 years. So unless anybody has any new arguments for either approach, let's end this thread. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Outside of a dog, a book is man's best friend. Inside a dog, it's too dark to read. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 9:49 ` Joerg Schilling 2006-02-02 10:20 ` Matthias Andree @ 2006-02-02 10:21 ` Martin Mares 2006-02-02 13:18 ` Jens Axboe 2006-02-02 16:12 ` Jan Engelhardt 3 siblings, 0 replies; 717+ messages in thread From: Martin Mares @ 2006-02-02 10:21 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan Hello! > Why not using fully dynamical loadable kernel modules as done with Solaris > since 1992? Since that time nobody cares because what you need is auto-loaded > on demand and there is absolutely no need for a manual configuration. Yes, but it still eats the memory if loaded. > BTW: Introducing an orthogonal SCSI based implementation would save a lot of > code. The model currently used on Linux is duplicating a lot of unneeded code > in target drivers and the SCSI glue code is only a few KB (less than 30k on > Solaris). Please stop beating a dead horse and diverting this discussion to irrelevant implementation details. What we were (and should be) discussing are the interfaces. If you have any sound arguments against the current interface, speak up. Whether the interface leads to code duplication is neither yours nor mine to judge -- the only people who should care are the maintainers of the drivers and they seem to be happy with the current approach and they are willing to improve it to simplify scanning. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Beware of bugs in the above code; I have only proved it correct, not tried it." -- D.E.K. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 9:49 ` Joerg Schilling 2006-02-02 10:20 ` Matthias Andree 2006-02-02 10:21 ` Martin Mares @ 2006-02-02 13:18 ` Jens Axboe 2006-02-02 16:12 ` Jan Engelhardt 3 siblings, 0 replies; 717+ messages in thread From: Jens Axboe @ 2006-02-02 13:18 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan On Thu, Feb 02 2006, Joerg Schilling wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > Which unfortunately leads us back to one of the early questions. > > > > If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used > > without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code > > floating around? > > CONFIG_SCSI??? > > Why not using fully dynamical loadable kernel modules as done with > Solaris since 1992? Since that time nobody cares because what you need > is auto-loaded on demand and there is absolutely no need for a manual > configuration. > > BTW: Introducing an orthogonal SCSI based implementation would save a > lot of code. The model currently used on Linux is duplicating a lot of > unneeded code in target drivers and the SCSI glue code is only a few > KB (less than 30k on Solaris). I have to comment on that... Your original gripe was the we should not have so much duplicated code - which of course was shot down, we don't have much duplicated code, basically a few hundred lines at most. And that solely remains because /dev/sg* still exists and isn't fully integrated with bsg (the block layer sg, which is probably misnamed as it could be used char devices as well). So this mail from you basically shoots huge holes in your original gripe. The whole SCSI stack is redundant code in this scheme. A quick check over my current tree shows over 23 _thousand_ lines of code (SCSI stack + ide-scsi)! Auto-loading modules has _nothing_ to do with it, it's still redundant code. I could go on, but the point should be crystal clear already so I'll stop. Joerg, unless you have any technical arguments please stop this thread. And here I do mean ones that are correct. You repeatedly either ignore mails asking you to backup your claims - or you reply to them saying "Please stop making false claims!". Honestly, I have no idea why you are doing that. -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 9:49 ` Joerg Schilling ` (2 preceding siblings ...) 2006-02-02 13:18 ` Jens Axboe @ 2006-02-02 16:12 ` Jan Engelhardt 3 siblings, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-02 16:12 UTC (permalink / raw) To: Joerg Schilling Cc: bzolnier, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan >> Which unfortunately leads us back to one of the early questions. >> >> If ATAPI is some sort of SCSI [command set] over ATA, and ide-cd can be used >> without the "Big Bad" SCSI layer (CONFIG_SCSI), don't we have redundant code >> floating around? > >CONFIG_SCSI??? > What else? >Why not using fully dynamical loadable kernel modules as done with Solaris Do you think I have scsi built-in? Not at all. lsmod:: sg 20120 0 sd_mod 12304 0 usb_storage 73408 0 usbcore 108256 5 uhci_hcd,ohci_hcd,ehci_hcd,usb_storage scsi_mod 103496 3 sg,sd_mod,usb_storage /proc/config.gz: CONFIG_SCSI=m CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_CONSTANTS=y that's about all. >since 1992? Since that time nobody cares because what you need is auto-loaded >on demand and there is absolutely no need for a manual configuration. Jan Engelhardt -- | Software Engineer and Linux/Unix Network Administrator | Alphagate Systems, http://alphagate.hopto.org/ | jengelh's site, http://jengelh.hopto.org/ ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 10:30 ` Joerg Schilling 2006-01-31 11:11 ` Martin Mares 2006-01-31 12:10 ` Bartlomiej Zolnierkiewicz @ 2006-01-31 12:24 ` jerome lacoste 2006-01-31 12:33 ` Oliver Neukum 2006-01-31 12:32 ` Juerg Billeter 2006-01-31 16:43 ` Paul Jakma 4 siblings, 1 reply; 717+ messages in thread From: jerome lacoste @ 2006-01-31 12:24 UTC (permalink / raw) To: Joerg Schilling Cc: j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Jürg Billeter <j@bitron.ch> wrote: [...] > Users like to be able to get a list of posible targets for a single protocol. The Linux users (I know of) like to be able to reference their drives the way their Operating System names them. If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'. Should we make a poll ? Jerome ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 12:24 ` jerome lacoste @ 2006-01-31 12:33 ` Oliver Neukum 2006-01-31 12:44 ` Denis Vlasenko 2006-02-02 7:59 ` Xavier Bestel 0 siblings, 2 replies; 717+ messages in thread From: Oliver Neukum @ 2006-01-31 12:33 UTC (permalink / raw) To: jerome lacoste Cc: Joerg Schilling, j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan Am Dienstag, 31. Januar 2006 13:24 schrieb jerome lacoste: > On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > Jürg Billeter <j@bitron.ch> wrote: > [...] > > Users like to be able to get a list of posible targets for a single protocol. > > The Linux users (I know of) like to be able to reference their drives > the way their Operating System names them. > > If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'. > > Should we make a poll ? It is entirely possible that the people you know are far from a representative sample. Most people likely prefer clicking on a description in a GUI. There needs to be a way to get this list and if possible it should not be specific to Linux. Regards Oliver ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 12:33 ` Oliver Neukum @ 2006-01-31 12:44 ` Denis Vlasenko 2006-02-01 15:37 ` Jan Engelhardt 2006-02-02 7:59 ` Xavier Bestel 1 sibling, 1 reply; 717+ messages in thread From: Denis Vlasenko @ 2006-01-31 12:44 UTC (permalink / raw) To: Oliver Neukum Cc: jerome lacoste, Joerg Schilling, j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan On Tuesday 31 January 2006 14:33, Oliver Neukum wrote: > Am Dienstag, 31. Januar 2006 13:24 schrieb jerome lacoste: > > On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > > Jürg Billeter <j@bitron.ch> wrote: > > [...] > > > Users like to be able to get a list of posible targets for a single protocol. > > > > The Linux users (I know of) like to be able to reference their drives > > the way their Operating System names them. > > > > If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'. > > > > Should we make a poll ? > > It is entirely possible that the people you know are far from a representative > sample. Most people likely prefer clicking on a description in a GUI. There > needs to be a way to get this list and if possible it should not be specific > to Linux. Do we need to expose IDE master/slave, primary/secondary concepts in Linux? So far I was perfectly happy with just /dev/hd[a-z][0-9]* -- vda ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 12:44 ` Denis Vlasenko @ 2006-02-01 15:37 ` Jan Engelhardt 2006-02-01 15:55 ` Bernd Petrovitsch 2006-02-01 15:56 ` Bartlomiej Zolnierkiewicz 0 siblings, 2 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-01 15:37 UTC (permalink / raw) To: Denis Vlasenko Cc: Oliver Neukum, jerome lacoste, Joerg Schilling, j, mrmacman_g4, matthias.andree, linux-kernel, James, acahalan >> > If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'. >> > >> > Should we make a poll ? select(), poll(), epoll(), anyone? (SCNR) >Do we need to expose IDE master/slave, primary/secondary concepts in Linux? > AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's (surprisingly) the other way round, sda just happens to be the first disk inserted (SCA, USB, etc.) Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 15:37 ` Jan Engelhardt @ 2006-02-01 15:55 ` Bernd Petrovitsch 2006-02-02 15:24 ` Albert Cahalan 2006-02-01 15:56 ` Bartlomiej Zolnierkiewicz 1 sibling, 1 reply; 717+ messages in thread From: Bernd Petrovitsch @ 2006-02-01 15:55 UTC (permalink / raw) To: Jan Engelhardt Cc: Denis Vlasenko, Oliver Neukum, jerome lacoste, Joerg Schilling, j, mrmacman_g4, matthias.andree, linux-kernel, James, acahalan On Wed, 2006-02-01 at 16:37 +0100, Jan Engelhardt wrote: [...] > >Do we need to expose IDE master/slave, primary/secondary concepts in Linux? > > > AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's > (surprisingly) the other way round, sda just happens to be the first disk > inserted (SCA, USB, etc.) The (historical) reason was: There were not enough major/minor numbers (IIRC 8 bit for each of them) for a sane (and static) SCSI device number mapping (similar to IDE) - just multiply the possible # of partitions * # of LUNs * # IDs for a few controllers. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 15:55 ` Bernd Petrovitsch @ 2006-02-02 15:24 ` Albert Cahalan 0 siblings, 0 replies; 717+ messages in thread From: Albert Cahalan @ 2006-02-02 15:24 UTC (permalink / raw) To: Bernd Petrovitsch; +Cc: Joerg Schilling, matthias.andree, linux-kernel On 2/1/06, Bernd Petrovitsch <bernd@firmix.at> wrote: > On Wed, 2006-02-01 at 16:37 +0100, Jan Engelhardt wrote: > [...] > > >Do we need to expose IDE master/slave, primary/secondary concepts in Linux? > > > > > AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's > > (surprisingly) the other way round, sda just happens to be the first disk > > inserted (SCA, USB, etc.) > > The (historical) reason was: There were not enough major/minor numbers > (IIRC 8 bit for each of them) for a sane (and static) SCSI device number > mapping (similar to IDE) - just multiply the possible # of partitions * > # of LUNs * # IDs for a few controllers. It's a hashing problem, and should have originally been seen as such. The constraints are that you'd like some stability as devices come and go. Splitting /dev into fields could have worked nicely: 1. the partition 2. dev type: disk, CD-ROM, built-in (ramdisk,loop), other 3. physical: master/slave, SCSI target, IDE 1/2/other, "is USB"... 4. volatile+rare stuff: PCI slot, ISA address, USB position, LUN (needlessly crammed into 16 bits: 5:2:4:5 or 5:2:5:4) For the physical stuff, per-driver values are assigned explicitly in the source code. Collisions are determined by humans. We make USB collide with something old, like XT disks and Atari disks. Collisions are chosen so that normal machines are unlikely to suffer from them. Note that I use "IDE 1/2/other". Only an x86 PC can have a primary or secondary controller, as determined by IO port location. Macs just have "other", as a single value. (they differentiate based on the rare and volatile stuff as needed) USB is distinguished from SCSI, FireWire, and IDE unless delibrately made to collide because of a bit shortage. Collisions found at run-time are resolved by mucking with the field for volatile and rare stuff. Adding a new USB device can will probably not mess up a different USB device, because the hashing is not too likely to pick the same number. Adding a new USB device will certainly not mess up a non-USB device unless the non-USB device is in a class of physical devices that was delibrately made to collide with USB. Adding a SCSI device with target ID 4 will only stand a chance of messing up other SCSI devices with target ID 4, on other busses or with other LUNs. It wouldn't mess up SCSI target ID 3, FireWire, USB, or anything else UNLESS those share the "physical" field ID. Not that Joerg would like this: LUN values and bus numbers get tossed into a hash function. You can't recover the individual numbers. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 15:37 ` Jan Engelhardt 2006-02-01 15:55 ` Bernd Petrovitsch @ 2006-02-01 15:56 ` Bartlomiej Zolnierkiewicz 2006-02-01 16:28 ` Jan Engelhardt 1 sibling, 1 reply; 717+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2006-02-01 15:56 UTC (permalink / raw) To: Jan Engelhardt Cc: Denis Vlasenko, Oliver Neukum, jerome lacoste, Joerg Schilling, j, mrmacman_g4, matthias.andree, linux-kernel, James, acahalan On 2/1/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >> > If it's /dev/cdrw, then it's /dev/cdrw, not '1,0,0'. > >> > > >> > Should we make a poll ? > > select(), poll(), epoll(), anyone? (SCNR) > > >Do we need to expose IDE master/slave, primary/secondary concepts in Linux? > > > AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's Ehm, primary master and it is not true if you are using host drivers as modules. Moreover providing ordering by IDE driver has been nightmare to maintain and can't be done correctly for 100% weird cases. > (surprisingly) the other way round, sda just happens to be the first disk > inserted (SCA, USB, etc.) Which is much saner approach from developers' POV. Bartlomiej ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 15:56 ` Bartlomiej Zolnierkiewicz @ 2006-02-01 16:28 ` Jan Engelhardt 2006-02-01 17:51 ` Kyle Moffett 0 siblings, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-02-01 16:28 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz Cc: Denis Vlasenko, Oliver Neukum, jerome lacoste, Joerg Schilling, j, mrmacman_g4, matthias.andree, linux-kernel, James, acahalan >> >Do we need to expose IDE master/slave, primary/secondary concepts in Linux? >> > >> AFAICS, we do. hda is always primary slave, etc. With the SCSI layer it's > >Ehm, primary master and it is not true if you are using host drivers as modules. > Whoops, you are right. However, even with, say, an extra PCI IDE controller, the ordering of the drives within that controller is "as usual", e.g. the order is "pri ma","pri sl","sec ma","sec sl", of course relative to the start of the respective controller. >Moreover providing ordering by IDE driver has been nightmare to maintain >and can't be done correctly for 100% weird cases. So how much weird cases do we have? >> (surprisingly) the other way round, sda just happens to be the first disk >> inserted (SCA, USB, etc.) > >Which is much saner approach from developers' POV. > Developer... and about the user/admin? With a sparcbox (ran suse linux 7.3 the last time it was powered on - 2.4 kernel, no udev - don't complain :), replugging disks in put them at the end of the 'sd*' naming chain, effectively killing the features of hotplug the machine itself offered. (Oh, that OS starting with S.. managed it with the help of the behated/-loved c?d?t?s? scheme, but that's OT.) Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 16:28 ` Jan Engelhardt @ 2006-02-01 17:51 ` Kyle Moffett 0 siblings, 0 replies; 717+ messages in thread From: Kyle Moffett @ 2006-02-01 17:51 UTC (permalink / raw) To: Jan Engelhardt Cc: Bartlomiej Zolnierkiewicz, Denis Vlasenko, Oliver Neukum, jerome lacoste, Joerg Schilling, j, matthias.andree, linux-kernel, James, acahalan On Feb 01, 2006, at 11:28, Jan Engelhardt wrote: >> Moreover providing ordering by IDE driver has been nightmare to >> maintain and can't be done correctly for 100% weird cases. > > So how much weird cases do we have? Speaking from personal experience, _waay_ too many. On my old G4 which now serves as a fileserver, I have 5 IDE busses out of 3 controllers (Onboard ATA-66 with 2 busses, onboard ATA-33 with one bus, add-in PCI ATA-100 with 2 busses) There's a _config_ option to control probe order specific to the two Apple onboard interfaces, and it used to be (before udev) that option was a nightmare to ensure that my new kernel has the same probe order as the old one. Once you throw PCI hotplug into the mix, reliable probing order is impossible, and you should just use udev to dynamically assign names. >>> (surprisingly) the other way round, sda just happens to be the >>> first disk >>> inserted (SCA, USB, etc.) >> >> Which is much saner approach from developers' POV. > > Developer... and about the user/admin? With a sparcbox (ran suse > linux 7.3 the last time it was powered on - 2.4 kernel, no udev - > don't complain :), replugging disks in put them at the end of the > 'sd*' naming chain, effectively killing the features of hotplug the > machine itself offered. (Oh, that OS starting with S.. managed it > with the help of the behated/-loved c?d?t?s? scheme, but that's OT.) Yeah, 2.4 was bad at hotplug, everybody knows that already. This is why the changes were made for 2.6 to add udev and hal and make it much saner. Cheers, Kyle Moffett -- I lost interest in "blade servers" when I found they didn't throw knives at people who weren't supposed to be in your machine room. -- Anthony de Boer ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 12:33 ` Oliver Neukum 2006-01-31 12:44 ` Denis Vlasenko @ 2006-02-02 7:59 ` Xavier Bestel 2006-02-02 11:19 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Xavier Bestel @ 2006-02-02 7:59 UTC (permalink / raw) To: Oliver Neukum Cc: jerome lacoste, Joerg Schilling, j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan On Tue, 2006-01-31 at 13:33, Oliver Neukum wrote: > It is entirely possible that the people you know are far from a representative > sample. Most people likely prefer clicking on a description in a GUI. There > needs to be a way to get this list and if possible it should not be specific > to Linux. As repeated over and over here, there is such a way, it's called HAL and it is cross-platform. And it's what's used by some GUIs out there (e.g. nautilus-cd-burner). Xav ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 7:59 ` Xavier Bestel @ 2006-02-02 11:19 ` Joerg Schilling 2006-02-02 11:34 ` Xavier Bestel 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-02 11:19 UTC (permalink / raw) To: xavier.bestel, oliver Cc: schilling, mrmacman_g4, matthias.andree, linux-kernel, jerome.lacoste, jengelh, James, j, acahalan Xavier Bestel <xavier.bestel@free.fr> wrote: > On Tue, 2006-01-31 at 13:33, Oliver Neukum wrote: > > It is entirely possible that the people you know are far from a representative > > sample. Most people likely prefer clicking on a description in a GUI. There > > needs to be a way to get this list and if possible it should not be specific > > to Linux. > > As repeated over and over here, there is such a way, it's called HAL and > it is cross-platform. And it's what's used by some GUIs out there (e.g. > nautilus-cd-burner). The fact that people here repeat unadquate proposals forces me to repeat my proposals. Name a list fo OS that implement HAL and then look at the list of crecord supported platforms Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 11:19 ` Joerg Schilling @ 2006-02-02 11:34 ` Xavier Bestel 2006-02-02 12:51 ` Joerg Schilling 2006-02-02 16:20 ` Jan Engelhardt 0 siblings, 2 replies; 717+ messages in thread From: Xavier Bestel @ 2006-02-02 11:34 UTC (permalink / raw) To: Joerg Schilling Cc: oliver, mrmacman_g4, matthias.andree, linux-kernel, jerome.lacoste, jengelh, James, j, acahalan On Thu, 2006-02-02 at 12:19, Joerg Schilling wrote: > Xavier Bestel <xavier.bestel@free.fr> wrote: > > > On Tue, 2006-01-31 at 13:33, Oliver Neukum wrote: > > > It is entirely possible that the people you know are far from a representative > > > sample. Most people likely prefer clicking on a description in a GUI. There > > > needs to be a way to get this list and if possible it should not be specific > > > to Linux. > > > > As repeated over and over here, there is such a way, it's called HAL and > > it is cross-platform. And it's what's used by some GUIs out there (e.g. > > nautilus-cd-burner). > > The fact that people here repeat unadquate proposals forces me to repeat my > proposals. Name a list fo OS that implement HAL and then look at the list > of crecord supported platforms Well ... from your sayings it seems Linux is supported by HAL but not by libscg. Xav ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 11:34 ` Xavier Bestel @ 2006-02-02 12:51 ` Joerg Schilling 2006-02-02 13:02 ` Xavier Bestel 2006-02-02 13:24 ` grundig 2006-02-02 16:20 ` Jan Engelhardt 1 sibling, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-02 12:51 UTC (permalink / raw) To: xavier.bestel, schilling Cc: oliver, mrmacman_g4, matthias.andree, linux-kernel, jerome.lacoste, jengelh, James, j, acahalan Xavier Bestel <xavier.bestel@free.fr> wrote: > > > As repeated over and over here, there is such a way, it's called HAL and > > > it is cross-platform. And it's what's used by some GUIs out there (e.g. > > > nautilus-cd-burner). > > > > The fact that people here repeat unadquate proposals forces me to repeat my > > proposals. Name a list fo OS that implement HAL and then look at the list > > of crecord supported platforms > > Well ... from your sayings it seems Linux is supported by HAL but not by > libscg. Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since 10 years. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 12:51 ` Joerg Schilling @ 2006-02-02 13:02 ` Xavier Bestel 2006-02-03 9:55 ` Joerg Schilling 2006-02-02 13:24 ` grundig 1 sibling, 1 reply; 717+ messages in thread From: Xavier Bestel @ 2006-02-02 13:02 UTC (permalink / raw) To: Joerg Schilling Cc: oliver, mrmacman_g4, matthias.andree, linux-kernel, jerome.lacoste, jengelh, James, j, acahalan Hi Jörg, On Thu, 2006-02-02 at 13:51, Joerg Schilling wrote: > Xavier Bestel <xavier.bestel@free.fr> wrote: > > Well ... from your sayings it seems Linux is supported by HAL but not by > > libscg. > > Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since > 10 years. I understand your point, but believe me, *nobody* wants one HAL per application. There need to be only one HAL for all, and as freedesktop's HAL has the functionnality necessary for cdrecord (minus perhaps a few fixable bugs), but libscg is SCSI-only (and for the matter, can't work with Linux IDE devices), cdrecord would better move to HAL for its CD writer discovery. Of course, the perfect outcome of this would be you turning cdrecord into a shared library which could be used by apps as they see fit, using their own means of selecting a CD writer and reporting errors and completion. Regards, Xav ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 13:02 ` Xavier Bestel @ 2006-02-03 9:55 ` Joerg Schilling 2006-02-03 10:05 ` Matthias Andree 2006-02-03 10:57 ` Xavier Bestel 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 9:55 UTC (permalink / raw) To: xavier.bestel, schilling Cc: oliver, mrmacman_g4, matthias.andree, linux-kernel, jerome.lacoste, jengelh, James, j, acahalan Xavier Bestel <xavier.bestel@free.fr> wrote: > On Thu, 2006-02-02 at 13:51, Joerg Schilling wrote: > > Xavier Bestel <xavier.bestel@free.fr> wrote: > > > Well ... from your sayings it seems Linux is supported by HAL but not by > > > libscg. > > > > Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since > > 10 years. > > I understand your point, but believe me, *nobody* wants one HAL per > application. There need to be only one HAL for all, and as freedesktop's > HAL has the functionnality necessary for cdrecord (minus perhaps a few If people don't want this confusion, why do they start with a new system? libscg & cdrecord have been available long before Linux HAL was there. And the most important argument here is that it is extremely unlikely that this Linux HAL will handle all oddities of all CD/DVD-writers, do it is unapropriate to use this interface in case that you like to get more information than just "the drive is there". Note that UNIX people usually believe that is is best practice to have this kind of software intergrated in the kernel (or at leat in the system). This is what FreeBSD did try for some years, and FreeBSD has failed with this attempt. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 9:55 ` Joerg Schilling @ 2006-02-03 10:05 ` Matthias Andree 2006-02-03 13:57 ` Jan Engelhardt 2006-02-03 15:50 ` Joerg Schilling 2006-02-03 10:57 ` Xavier Bestel 1 sibling, 2 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-03 10:05 UTC (permalink / raw) To: Joerg Schilling; +Cc: xavier.bestel, linux-kernel, acahalan Joerg Schilling schrieb am 2006-02-03: > libscg & cdrecord have been available long before Linux HAL was there. Perhaps libscg was too arcane and too badly integrated into Linux? > And the most important argument here is that it is extremely unlikely that > this Linux HAL will handle all oddities of all CD/DVD-writers, do it is > unapropriate to use this interface in case that you like to get more > information than just "the drive is there". > > Note that UNIX people usually believe that is is best practice to have this > kind of software intergrated in the kernel (or at leat in the system). This is > what FreeBSD did try for some years, and FreeBSD has failed with this attempt. So why would Linux want to have it in the kernel if it hasn't worked for FreeBSD either? Thanks for proving it doesn't belong there BTW. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 10:05 ` Matthias Andree @ 2006-02-03 13:57 ` Jan Engelhardt 2006-02-03 15:50 ` Joerg Schilling 1 sibling, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-03 13:57 UTC (permalink / raw) To: Matthias Andree; +Cc: Joerg Schilling, xavier.bestel, linux-kernel, acahalan >> >> Note that UNIX people usually believe that is is best practice to have this >> kind of software intergrated in the kernel (or at leat in the system). This is >> what FreeBSD did try for some years, and FreeBSD has failed with this attempt. > >So why would Linux want to have it in the kernel if it hasn't worked for >FreeBSD either? Thanks for proving it doesn't belong there BTW. > There's also something in the FreeBSD kernel that does work there, but has not worked out as good for Linux ;-) [devfs] Therefore I would not generalize it and say "if it did not work on <x>, we don't need to implement it for our <y>". Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 10:05 ` Matthias Andree 2006-02-03 13:57 ` Jan Engelhardt @ 2006-02-03 15:50 ` Joerg Schilling 1 sibling, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 15:50 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: xavier.bestel, linux-kernel, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-03: > > > libscg & cdrecord have been available long before Linux HAL was there. > > Perhaps libscg was too arcane and too badly integrated into Linux? >From a cdrecord point of view, this seems to rather apply to Linux HAL. > > Note that UNIX people usually believe that is is best practice to have this > > kind of software intergrated in the kernel (or at leat in the system). This is > > what FreeBSD did try for some years, and FreeBSD has failed with this attempt. > > So why would Linux want to have it in the kernel if it hasn't worked for > FreeBSD either? Thanks for proving it doesn't belong there BTW. Please try to understand my text before answering. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 9:55 ` Joerg Schilling 2006-02-03 10:05 ` Matthias Andree @ 2006-02-03 10:57 ` Xavier Bestel 1 sibling, 0 replies; 717+ messages in thread From: Xavier Bestel @ 2006-02-03 10:57 UTC (permalink / raw) To: Joerg Schilling Cc: oliver, mrmacman_g4, matthias.andree, linux-kernel, jerome.lacoste, jengelh, James, j, acahalan On Fri, 2006-02-03 at 10:55, Joerg Schilling wrote: > Xavier Bestel <xavier.bestel@free.fr> wrote: > > I understand your point, but believe me, *nobody* wants one HAL per > > application. There need to be only one HAL for all, and as freedesktop's > > HAL has the functionnality necessary for cdrecord (minus perhaps a few > > If people don't want this confusion, why do they start with a new system? > > libscg & cdrecord have been available long before Linux HAL was there. Because libscg handles only SCSI, whereas HAL does work for all disk types, floppies, serial ports, PCI buses, graphics cards, processors, etc. Imagine there was one library per peripheral type - oh the pain. > And the most important argument here is that it is extremely unlikely that > this Linux HAL will handle all oddities of all CD/DVD-writers, do it is > unapropriate to use this interface in case that you like to get more > information than just "the drive is there". For now, it sure doesn't equal cdrecord in that area. But give it time and it will progress. After all, there's no reason HAL can't gain from your expertise on the matter. > Note that UNIX people usually believe that is is best practice to have this > kind of software intergrated in the kernel (or at leat in the system). This is > what FreeBSD did try for some years, and FreeBSD has failed with this attempt. AFAIR this was deemed too complex to live in kernelspace. Maybe FreeBSD's failure is a good indication it's true. Xav ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 12:51 ` Joerg Schilling 2006-02-02 13:02 ` Xavier Bestel @ 2006-02-02 13:24 ` grundig 2006-02-03 10:06 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: grundig @ 2006-02-02 13:24 UTC (permalink / raw) To: Joerg Schilling Cc: xavier.bestel, schilling, oliver, mrmacman_g4, matthias.andree, linux-kernel, jerome.lacoste, jengelh, James, j, acahalan El Thu, 02 Feb 2006 13:51:19 +0100, Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since > 10 years. libscg being there for 10 years doesn't means that it's the right or the better way of doing things. Hal is _the_ HAL for linux, in fact HAL is targetted to become _the_ "standard" (freedesktop standard) HAL for open operative systems. HAL should be already available on solaris, at least there's a @sun.com guy who created a hald/solaris/ directory (gnome is already using HAL and sun is interested in gnome). It doesn't seem to do nothing today but I bet that sun is interested in getting HAL working in solaris (there're at least people in the opensolaris mailing lists interested). I guess the BSD guys will end up implementing BSD support some day aswell - desktop is not as important for them as it is for linux. So the fact is that HAL is quickly becoming _the_ HAL for unix systems. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 13:24 ` grundig @ 2006-02-03 10:06 ` Joerg Schilling 2006-02-03 10:39 ` Matthias Andree 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 10:06 UTC (permalink / raw) To: schilling, grundig Cc: xavier.bestel, schilling, oliver, mrmacman_g4, matthias.andree, linux-kernel, jerome.lacoste, jengelh, James, j, acahalan <grundig@teleline.es> wrote: > El Thu, 02 Feb 2006 13:51:19 +0100, > Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > > > Libscg is _the_ HAL for cdrecord. It is availaible the same way as today since > > 10 years. > > > libscg being there for 10 years doesn't means that it's the right or the > better way of doing things. Any new implementation first needs to prove that it is durable and (more important) that it is actively maintained. I am sure that this kind of software will never handle all oddities in drive firmware we know from CD/DVD-writers. > Hal is _the_ HAL for linux, in fact HAL is targetted to become _the_ > "standard" (freedesktop standard) HAL for open operative systems. HAL > should be already available on solaris, at least there's a @sun.com guy > who created a hald/solaris/ directory (gnome is already using HAL and > sun is interested in gnome). It doesn't seem to do nothing today but I I know this person, but Sun is creating reliable software for customers and for this reason, it is most unlikely that an incompatible change like this will be intregrated before Solaris 11 GA is available to the end of 2007. It may appear earlier in Solaris 11 beta's, but this is a different thing. > bet that sun is interested in getting HAL working in solaris (there're > at least people in the opensolaris mailing lists interested). I guess > the BSD guys will end up implementing BSD support some day aswell - desktop > is not as important for them as it is for linux. > > So the fact is that HAL is quickly becoming _the_ HAL for unix systems. I hope that Sun will not base Sun's implementations on ideas on the Linux implementaion which is known to be an "unfriendly" program as it causes problems with CD/DVD-writing. Since 1992, Sun has vold and vold is rock solid. Vold nicely coexists with cdrecord in the right way: It does not send inapropriate SCSI commnds to the drives and it does not send too many of them in a certain period of time. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 10:06 ` Joerg Schilling @ 2006-02-03 10:39 ` Matthias Andree 0 siblings, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-03 10:39 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-03: > Any new implementation first needs to prove that it is durable and (more > important) that it is actively maintained. I am sure that this kind of software > will never handle all oddities in drive firmware we know from CD/DVD-writers. The suggestion was to use it for device enumeration and then talking ioctl(...SG_IO...) to the device so obtained. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 11:34 ` Xavier Bestel 2006-02-02 12:51 ` Joerg Schilling @ 2006-02-02 16:20 ` Jan Engelhardt 2006-02-03 8:11 ` Alexander Samad 1 sibling, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-02-02 16:20 UTC (permalink / raw) To: Xavier Bestel Cc: Joerg Schilling, oliver, mrmacman_g4, matthias.andree, linux-kernel, jerome.lacoste, James, j, acahalan >> > >> > As repeated over and over here, there is such a way, it's called HAL and >> > it is cross-platform. And it's what's used by some GUIs out there (e.g. >> > nautilus-cd-burner). >> >> The fact that people here repeat unadquate proposals forces me to repeat my >> proposals. Name a list fo OS that implement HAL and then look at the list >> of crecord supported platforms > >Well ... from your sayings it seems Linux is supported by HAL but not by >libscg. > But sounds like freedesktop-hal is not available for all platforms libscg currently works on! Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 16:20 ` Jan Engelhardt @ 2006-02-03 8:11 ` Alexander Samad 0 siblings, 0 replies; 717+ messages in thread From: Alexander Samad @ 2006-02-03 8:11 UTC (permalink / raw) To: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1124 bytes --] On Thu, Feb 02, 2006 at 05:20:13PM +0100, Jan Engelhardt wrote: > >> > > >> > As repeated over and over here, there is such a way, it's called HAL and > >> > it is cross-platform. And it's what's used by some GUIs out there (e.g. > >> > nautilus-cd-burner). > >> > >> The fact that people here repeat unadquate proposals forces me to repeat my > >> proposals. Name a list fo OS that implement HAL and then look at the list > >> of crecord supported platforms > > > >Well ... from your sayings it seems Linux is supported by HAL but not by > >libscg. > > > But sounds like freedesktop-hal is not available for all platforms libscg > currently works on! I presume that the system api are not the same between OS either, so why can't there be different methods of interacting with the cdburners/cddrives! > > > Jan Engelhardt > -- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 10:30 ` Joerg Schilling ` (2 preceding siblings ...) 2006-01-31 12:24 ` jerome lacoste @ 2006-01-31 12:32 ` Juerg Billeter 2006-01-31 13:37 ` Joerg Schilling 2006-02-01 15:39 ` [OT] " Jan Engelhardt 2006-01-31 16:43 ` Paul Jakma 4 siblings, 2 replies; 717+ messages in thread From: Juerg Billeter @ 2006-01-31 12:32 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan Thanks for your detailed response. On Die, 2006-01-31 at 11:30 +0100, Joerg Schilling wrote: > Jürg Billeter <j@bitron.ch> wrote: > > It makes sense to address parallel SCSI devices via target id. If an > > operating system likes to simulate virtual SCSI buses for other bus > > types as well, ok, I have no objections. But if the operating system > > doesn't like to simulate virtual SCSI buses and allows applications to > > address devices by a filename, you should have no objections, too. > > It seems that you missunderstand this. No operating system uses file names > internally. OS instead typically handle SCSI devices that are not connected > via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system > by asuming they are all on separate SCSI busses that only have one single drive > conected each. Are you sure about that? I don't doubt that many operating systems handle all devices, that are able to understand the SCSI command set, exactly as you describe it, but Linux doesn't assume such separate virtual SCSI buses for non good old Parallel SCSI drives, not even internally, as far as I understand it. Of course it doesn't use file names internally, it uses major and minor numbers, but that shouldn't matter, the major and minor numbers get exported to userspace via sysfs. > > What Linux does is to artificially prevent this view to been seen from outside the > Linux kernel, or to avoid integrating a particular device into a unique SCSI > driver system although it would be apropriate. That's the point where you're not quite right, if I understand it correctly. The Linux kernel does not artificially prevent userspace applications viewing virtual SCSI buses, these virtual SCSI buses don't exist internally in the Linux kernel at all. So Linux doesn't artificially prevent anything, it just doesn't artificially _create_ virtual SCSI buses. > Users like to be able to get a list of posible targets for a single protocol. > Nobody would ever think about trying to prevent people from getting a unified > view on the list possible hosts that talk TCP/IP. What cdrecord does with > -scanbus is nothing really different. Well, please show me how to get the list of all possible hosts that talk TCP/IP and are directly or indirectly connected to my computer. As my computer is attached to the internet, the list would get pretty long... And even if only considering hosts in the local network, how do you get a unified view of all TCP/IP hosts conected to any of my two network adapters? > So why do people try to convince me that there is a need to avoid the standard > SCSI protocol stack because a PC might have only ATAPI? > > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, > ...). Why do people believe that Linux needs to be different? What does it buy > you to go this way? Why do you believe that Linux needs to do the same as every other OS? I'd agree with you if Linux would violate a standard but AFAIK the bus view with target ids is not part of the ATAPI or a dependant standard. Please correct me if I'm wrong but the bus/target/lun combination is only a standard for some SCSI transports, at least it is for good old Parallel SCSI, yes, but SCSI over ATA doesn't define target-based addressing. > *] MS-WIN-NT even includes SCSI emulation (it allows you to connect to the > SCSI subsystem, set the Address and use SCSI commands from a limited list > to read/write sector from ATA only hard disks). Great, I have no objections but you shouldn't mandate the Linux kernel developers to implement a copy of implementations other operating systems provide. If the virtual SCSI bus and/or full SCSI emulation would be part of POSIX or an other standard Linux tries to follow, Linux should implement it, of course, but last time I checked, it's not in POSIX. > > If the Linux folks could give technical based explanations for the questions > from above and if they would create a new completely orthogonal view on SCSI [*] > I had no problem. But up to now, the only answer was: "We do it this > way because we do it this way". Linux' device nodes is such an orthogonal view that should include all devices able to speak SCSI among others. Enumeration is possible via sysfs (low-level) or much easier via the userspace HAL library from freedesktop.org. > > *] Note that this would need to implement SCSI Generic support for drives that > have no native driver in the system. If there is a device that supports the SCSI command set and the device can't be accessed with SG_IO in linux, I'd call this a Linux kernel bug. You mentioned ATAPI tapes before; if that's really the case, it's a Linux bug, yes, but it seems that nobody cares about speaking SCSI with these device types. That happens in projects with limited resources. My point is that this shouldn't matter to cdrecord. It does matter to tape drive applications that use libscg, of course. File a bug in bugzilla about that and if ATAPI tapes are important to a Linux developer, he will probably implement it. But a Linux bug affecting some device or bus types doesn't automatically mean that the whole Linux kernel device addressing is broken by design. Jürg -- Juerg Billeter <j@bitron.ch> ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 12:32 ` Juerg Billeter @ 2006-01-31 13:37 ` Joerg Schilling 2006-01-31 13:44 ` Martin Mares 2006-02-02 6:28 ` Jim Crilly 2006-02-01 15:39 ` [OT] " Jan Engelhardt 1 sibling, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-31 13:37 UTC (permalink / raw) To: schilling, j Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan Juerg Billeter <j@bitron.ch> wrote: > > So why do people try to convince me that there is a need to avoid the standard > > SCSI protocol stack because a PC might have only ATAPI? > > > > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, > > ...). Why do people believe that Linux needs to be different? What does it buy > > you to go this way? > > Why do you believe that Linux needs to do the same as every other OS? Why do you believe that Linux needs to be worse than other OS? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 13:37 ` Joerg Schilling @ 2006-01-31 13:44 ` Martin Mares 2006-02-02 6:28 ` Jim Crilly 1 sibling, 0 replies; 717+ messages in thread From: Martin Mares @ 2006-01-31 13:44 UTC (permalink / raw) To: Joerg Schilling Cc: j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan Hello! > > Why do you believe that Linux needs to do the same as every other OS? > > Why do you believe that Linux needs to be worse than other OS? Sorry, but so far you have failed to produce a single plausible argument why the way chosen by Linux is worse. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth The number of UNIX installations has grown to 10, with more expected. (6/72) ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 13:37 ` Joerg Schilling 2006-01-31 13:44 ` Martin Mares @ 2006-02-02 6:28 ` Jim Crilly 2006-02-02 11:17 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Jim Crilly @ 2006-02-02 6:28 UTC (permalink / raw) To: Joerg Schilling Cc: j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan On 01/31/06 02:37:22PM +0100, Joerg Schilling wrote: > Juerg Billeter <j@bitron.ch> wrote: > > > > So why do people try to convince me that there is a need to avoid the standard > > > SCSI protocol stack because a PC might have only ATAPI? > > > > > > Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris, > > > ...). Why do people believe that Linux needs to be different? What does it buy > > > you to go this way? > > > > Why do you believe that Linux needs to do the same as every other OS? > > Why do you believe that Linux needs to be worse than other OS? > Every other method to access those devices uses the device name, i.e. mount, fsck, etc, so why should cdrecord be different? > Jörg Jim. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 6:28 ` Jim Crilly @ 2006-02-02 11:17 ` Joerg Schilling 2006-02-02 11:37 ` grundig ` (3 more replies) 0 siblings, 4 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-02 11:17 UTC (permalink / raw) To: schilling, jim Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan Jim Crilly <jim@why.dont.jablowme.net> wrote: > Every other method to access those devices uses the device name, i.e. > mount, fsck, etc, so why should cdrecord be different? inadequateness on Linux did force libscg to go this way. The current method used by libscg is well established since 10 years. Now Linux likes to confuse people by trying to enforce a completely incompatible access method. Note that I need to avoid unneeded efforts and for this reason, I need to wait 5 years until is is forseable that a recent incompatible change in Linux will survive long enough to spent time on it. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 11:17 ` Joerg Schilling @ 2006-02-02 11:37 ` grundig 2006-02-02 12:15 ` Martin Mares ` (2 subsequent siblings) 3 siblings, 0 replies; 717+ messages in thread From: grundig @ 2006-02-02 11:37 UTC (permalink / raw) To: Joerg Schilling Cc: schilling, jim, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan El Thu, 02 Feb 2006 12:17:09 +0100, Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > Note that I need to avoid unneeded efforts and for this reason, I need to wait > 5 years until is is forseable that a recent incompatible change in Linux will > survive long enough to spent time on it. Woah. No comments. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 11:17 ` Joerg Schilling 2006-02-02 11:37 ` grundig @ 2006-02-02 12:15 ` Martin Mares 2006-02-02 12:24 ` Matthias Andree 2006-02-02 16:18 ` Jim Crilly 3 siblings, 0 replies; 717+ messages in thread From: Martin Mares @ 2006-02-02 12:15 UTC (permalink / raw) To: Joerg Schilling Cc: jim, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan Hello! > Now Linux likes to confuse people by trying to enforce a completely > incompatible access method. Completely incompatible? For years, cdrecord works with it and it only prints an utterly silly warning and also has a trivial bug in the scanning code, causing it to stop too early. > Note that I need to avoid unneeded efforts and for this reason, I need to wait > 5 years until is is forseable that a recent incompatible change in Linux will > survive long enough to spent time on it. If this is reason, I will send you a patch fixing the trivial bugs and annoyances, sparing you the work. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "I don't give a damn for a man that can only spell a word one way." -- M. Twain ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 11:17 ` Joerg Schilling 2006-02-02 11:37 ` grundig 2006-02-02 12:15 ` Martin Mares @ 2006-02-02 12:24 ` Matthias Andree 2006-02-02 16:18 ` Jim Crilly 3 siblings, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-02 12:24 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-02: > Jim Crilly <jim@why.dont.jablowme.net> wrote: > > > Every other method to access those devices uses the device name, i.e. > > mount, fsck, etc, so why should cdrecord be different? > > inadequateness on Linux did force libscg to go this way. > > The current method used by libscg is well established since 10 years. > > Now Linux likes to confuse people by trying to enforce a completely > incompatible access method. > > Note that I need to avoid unneeded efforts and for this reason, I need to wait > 5 years until is is forseable that a recent incompatible change in Linux will > survive long enough to spent time on it. It is incompatible? Looks like the code is already implemented and ATA: is in the regular device name space (where RSCSI and the other options reside as well). -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 11:17 ` Joerg Schilling ` (2 preceding siblings ...) 2006-02-02 12:24 ` Matthias Andree @ 2006-02-02 16:18 ` Jim Crilly 2006-02-02 17:17 ` Albert Cahalan 3 siblings, 1 reply; 717+ messages in thread From: Jim Crilly @ 2006-02-02 16:18 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan On 02/02/06 12:17:09PM +0100, Joerg Schilling wrote: > Jim Crilly <jim@why.dont.jablowme.net> wrote: > > > Every other method to access those devices uses the device name, i.e. > > mount, fsck, etc, so why should cdrecord be different? > > inadequateness on Linux did force libscg to go this way. > And inadequacies are what's causing libscg and 'cdrecord -scanbus' to fail to list all IDE devices on Linux. Unless the comments about it stopping the scan after getting -EPERM on one device are wrong. > The current method used by libscg is well established since 10 years. So? Change isn't always a bad thing. > Now Linux likes to confuse people by trying to enforce a completely > incompatible access method. >From my point of view it's cdrecord that's confusing Linux users by trying to force a completely different device naming method on users for no good reason. > Note that I need to avoid unneeded efforts and for this reason, I need to wait > 5 years until is is forseable that a recent incompatible change in Linux will > survive long enough to spent time on it. I could be wrong, but don't all of the other OSes that cdrecord and libscg support access the device via the device node? When I mount a device on Solaris I use /dev/c0t0d0s0 (or whatever it is)and not 0:0:0, right? So it would be safe to assume that users are used to using that form of names for their devices, so why should cdrecord be the odd man out? Jim. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 16:18 ` Jim Crilly @ 2006-02-02 17:17 ` Albert Cahalan 2006-02-02 20:39 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Albert Cahalan @ 2006-02-02 17:17 UTC (permalink / raw) To: Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan On 2/2/06, Jim Crilly <jim@why.dont.jablowme.net> wrote: > On 02/02/06 12:17:09PM +0100, Joerg Schilling wrote: > > Jim Crilly <jim@why.dont.jablowme.net> wrote: > > > > > Every other method to access those devices uses the device name, i.e. > > > mount, fsck, etc, so why should cdrecord be different? > > > > inadequateness on Linux did force libscg to go this way. > > > > And inadequacies are what's causing libscg and 'cdrecord -scanbus' to fail > to list all IDE devices on Linux. Unless the comments about it stopping the > scan after getting -EPERM on one device are wrong. I'm seeing even worse behavior. Since /dev/hda is a disk with mounted filesystems, my kernel refuses access even for root. Thus, even root is unable to scan the /dev/hd* devices! ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 17:17 ` Albert Cahalan @ 2006-02-02 20:39 ` Jan Engelhardt 2006-02-02 21:09 ` Jim Crilly 0 siblings, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-02-02 20:39 UTC (permalink / raw) To: Albert Cahalan Cc: Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j > >I'm seeing even worse behavior. Since /dev/hda is a disk with mounted >filesystems, my kernel refuses access even for root. Thus, even root >is unable to scan the /dev/hd* devices! > What sort of kernel patch do you have turned on? I'd be scared if I could not even do a (read-only!) hexdump of my drive while mounted. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 20:39 ` Jan Engelhardt @ 2006-02-02 21:09 ` Jim Crilly 2006-02-02 21:20 ` Joerg Schilling ` (2 more replies) 0 siblings, 3 replies; 717+ messages in thread From: Jim Crilly @ 2006-02-02 21:09 UTC (permalink / raw) To: Jan Engelhardt Cc: Albert Cahalan, Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j On 02/02/06 09:39:02PM +0100, Jan Engelhardt wrote: > > > >I'm seeing even worse behavior. Since /dev/hda is a disk with mounted > >filesystems, my kernel refuses access even for root. Thus, even root > >is unable to scan the /dev/hd* devices! > > > What sort of kernel patch do you have turned on? I'd be scared if I could > not even do a (read-only!) hexdump of my drive while mounted. > I see the same thing with, the only external kernel patch I have applied is Suspend2. The ATA scanbus code tries to open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since the scanning code stops once one device fails to open the whole scan aborts. Apparently O_EXCL was added by Ubuntu and Debian to stop burns being corrupted by hald polling the device while a disc is being burned. If you want to read the entire thread it's bug #262678 in Debian. Jim. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:09 ` Jim Crilly @ 2006-02-02 21:20 ` Joerg Schilling 2006-02-02 21:46 ` Jim Crilly 2006-02-03 2:27 ` Albert Cahalan 2006-02-02 21:25 ` Lee Revell 2006-02-03 13:25 ` Joerg Schilling 2 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-02 21:20 UTC (permalink / raw) To: jim, jengelh Cc: schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > I see the same thing with, the only external kernel patch I have > applied is Suspend2. The ATA scanbus code tries to > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since This is not cdrecord but a bastardized version...... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:20 ` Joerg Schilling @ 2006-02-02 21:46 ` Jim Crilly 2006-02-03 13:36 ` Joerg Schilling 2006-02-03 2:27 ` Albert Cahalan 1 sibling, 1 reply; 717+ messages in thread From: Jim Crilly @ 2006-02-02 21:46 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan On 02/02/06 10:20:18PM +0100, Joerg Schilling wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > I see the same thing with, the only external kernel patch I have > > applied is Suspend2. The ATA scanbus code tries to > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since > > This is not cdrecord but a bastardized version...... > > Jörg I know it's not your official version, I was merely pointing out where the 'problem' was coming from. Jim. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:46 ` Jim Crilly @ 2006-02-03 13:36 ` Joerg Schilling 0 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 13:36 UTC (permalink / raw) To: schilling, jim Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since > > > > This is not cdrecord but a bastardized version...... > I know it's not your official version, I was merely pointing out where the > 'problem' was coming from. This was only a short reply.... see also my longer reply from today. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:20 ` Joerg Schilling 2006-02-02 21:46 ` Jim Crilly @ 2006-02-03 2:27 ` Albert Cahalan 2006-02-03 13:47 ` Jan Engelhardt 2006-02-03 15:20 ` Joerg Schilling 1 sibling, 2 replies; 717+ messages in thread From: Albert Cahalan @ 2006-02-03 2:27 UTC (permalink / raw) To: Joerg Schilling Cc: jim, jengelh, mrmacman_g4, matthias.andree, linux-kernel, James, j On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > I see the same thing with, the only external kernel patch I have > > applied is Suspend2. The ATA scanbus code tries to > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since > > This is not cdrecord but a bastardized version...... True enough, but it would work great if you'd fix that bug that makes cdrecord give up while scanning. I guess that's one more patch Debian will be applying. Using O_EXCL is kind of broken, because you'll need to retry any failures, but that's life. You hacked cdrecord to properly interact with the Solaris volume manager. You can do the same for HAL. Giving up while scanning is a problem for other reasons. Let me introduce you to SE Linux. One can have RAWIO capability, RT capability, mlock() capability, and still not have the right to access all devices. You might not even be able to get stat() to succeed, but you could burn a CD if you use the correct device file. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 2:27 ` Albert Cahalan @ 2006-02-03 13:47 ` Jan Engelhardt 2006-02-03 15:20 ` Joerg Schilling 1 sibling, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-03 13:47 UTC (permalink / raw) To: Albert Cahalan Cc: Joerg Schilling, jim, mrmacman_g4, matthias.andree, linux-kernel, James, j >Giving up while scanning is a problem for other reasons. >Let me introduce you to SE Linux. One can have RAWIO >capability, RT capability, mlock() capability, and still not >have the right to access all devices. You might not even >be able to get stat() to succeed, but you could burn a CD >if you use the correct device file. > Unfortunately, setting up SELinux is currently not easy. Jan Engelhardt -- | Software Engineer and Linux/Unix Network Administrator | Alphagate Systems, http://alphagate.hopto.org/ | jengelh's site, http://jengelh.hopto.org/ ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 2:27 ` Albert Cahalan 2006-02-03 13:47 ` Jan Engelhardt @ 2006-02-03 15:20 ` Joerg Schilling 2006-02-03 15:53 ` Jim Crilly ` (2 more replies) 1 sibling, 3 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 15:20 UTC (permalink / raw) To: schilling, acahalan Cc: mrmacman_g4, matthias.andree, linux-kernel, jim, jengelh, James, j Albert Cahalan <acahalan@gmail.com> wrote: > On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > > > I see the same thing with, the only external kernel patch I have > > > applied is Suspend2. The ATA scanbus code tries to > > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since > > > > This is not cdrecord but a bastardized version...... > > True enough, but it would work great if you'd fix that bug > that makes cdrecord give up while scanning. I guess > that's one more patch Debian will be applying. As including O_EXCL would disallow to use more than one cdrecord program at the same time, there is no chance for the mains stream source. > Using O_EXCL is kind of broken, because you'll need to > retry any failures, but that's life. You hacked cdrecord to > properly interact with the Solaris volume manager. You > can do the same for HAL. Well the big difference with Solaris is that several modifications have been applied by Sun to the vold sub-system on Solaris in order to decently support cdrecord. The last change was done with Nevada Build 21 in August 2005. It makes sense for Linux not to ignore CD/DVD writing. Solaris also did chose not to ignore cdrecord. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 15:20 ` Joerg Schilling @ 2006-02-03 15:53 ` Jim Crilly 2006-02-03 16:54 ` Joerg Schilling ` (2 more replies) 2006-02-03 16:10 ` Phillip Susi 2006-02-03 18:20 ` [cdrtools PATCH (GPL)] " Matthias Andree 2 siblings, 3 replies; 717+ messages in thread From: Jim Crilly @ 2006-02-03 15:53 UTC (permalink / raw) To: Joerg Schilling Cc: acahalan, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j On 02/03/06 04:20:47PM +0100, Joerg Schilling wrote: > Albert Cahalan <acahalan@gmail.com> wrote: > > > On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > > > > > I see the same thing with, the only external kernel patch I have > > > > applied is Suspend2. The ATA scanbus code tries to > > > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since > > > > > > This is not cdrecord but a bastardized version...... > > > > True enough, but it would work great if you'd fix that bug > > that makes cdrecord give up while scanning. I guess > > that's one more patch Debian will be applying. > > As including O_EXCL would disallow to use more than one cdrecord > program at the same time, there is no chance for the mains stream source. Maybe I'm just being thick, but wouldn't that only prevent you from using cdrecord on the same device multiple times? The only thing I can see being opened with O_EXCL is the target device. > > Using O_EXCL is kind of broken, because you'll need to > > retry any failures, but that's life. You hacked cdrecord to > > properly interact with the Solaris volume manager. You > > can do the same for HAL. > > Well the big difference with Solaris is that several modifications have been > applied by Sun to the vold sub-system on Solaris in order to decently > support cdrecord. > > The last change was done with Nevada Build 21 in August 2005. > > It makes sense for Linux not to ignore CD/DVD writing. Solaris also did > chose not to ignore cdrecord. > > Jörg A bug in HAL is not a bug in Linux. If the HAL people need to make some changes to their daemon to make it play nice with cdrecord and the like that's fine, but telling people here makes no sense. Jim. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 15:53 ` Jim Crilly @ 2006-02-03 16:54 ` Joerg Schilling 2006-02-03 17:49 ` Krzysztof Halasa 2006-02-03 18:04 ` Olivier Galibert 2 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 16:54 UTC (permalink / raw) To: schilling, jim Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > A bug in HAL is not a bug in Linux. If the HAL people need to make some > changes to their daemon to make it play nice with cdrecord and the like > that's fine, but telling people here makes no sense. Please let us either asume that it is in or not.... If you tell me it is not in, then cdrecord definitely needs everything it currently does just because Linux is missing any needed feature. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 15:53 ` Jim Crilly 2006-02-03 16:54 ` Joerg Schilling @ 2006-02-03 17:49 ` Krzysztof Halasa 2006-02-03 18:35 ` Jim Crilly 2006-02-03 18:57 ` Joerg Schilling 2006-02-03 18:04 ` Olivier Galibert 2 siblings, 2 replies; 717+ messages in thread From: Krzysztof Halasa @ 2006-02-03 17:49 UTC (permalink / raw) To: Joerg Schilling Cc: acahalan, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j "Jim Crilly" <jim@why.dont.jablowme.net> writes: > A bug in HAL is not a bug in Linux. If the HAL people need to make some > changes to their daemon to make it play nice with cdrecord and the like > that's fine, but telling people here makes no sense. Does that mean that hald doesn't actually play nice with cdrecord? -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 17:49 ` Krzysztof Halasa @ 2006-02-03 18:35 ` Jim Crilly 2006-02-03 18:57 ` Joerg Schilling 1 sibling, 0 replies; 717+ messages in thread From: Jim Crilly @ 2006-02-03 18:35 UTC (permalink / raw) To: Krzysztof Halasa Cc: Joerg Schilling, acahalan, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j On 02/03/06 06:49:21PM +0100, Krzysztof Halasa wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> writes: > > > A bug in HAL is not a bug in Linux. If the HAL people need to make some > > changes to their daemon to make it play nice with cdrecord and the like > > that's fine, but telling people here makes no sense. > > Does that mean that hald doesn't actually play nice with cdrecord? > -- > Krzysztof Halasa > - That's what the bug reports in Debian and Ubuntu say, the periodic polling that hald does on the CD devices causes interruptions in the burning process. Jim. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 17:49 ` Krzysztof Halasa 2006-02-03 18:35 ` Jim Crilly @ 2006-02-03 18:57 ` Joerg Schilling 1 sibling, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 18:57 UTC (permalink / raw) To: schilling, khc Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan Krzysztof Halasa <khc@pm.waw.pl> wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> writes: > > > A bug in HAL is not a bug in Linux. If the HAL people need to make some > > changes to their daemon to make it play nice with cdrecord and the like > > that's fine, but telling people here makes no sense. > > Does that mean that hald doesn't actually play nice with cdrecord? I cannot speak from own experiences on Linux here, but this is what I see: - If you check Linux distributions for related bug reports, you find many problems with hald. - If you try to find similar bug reports for Solaris vold, there is no report I am aware of. Trying to rate this would make me asume that hald could be changed to play better with cdrecord. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 15:53 ` Jim Crilly 2006-02-03 16:54 ` Joerg Schilling 2006-02-03 17:49 ` Krzysztof Halasa @ 2006-02-03 18:04 ` Olivier Galibert 2006-02-03 18:13 ` Kay Sievers ` (2 more replies) 2 siblings, 3 replies; 717+ messages in thread From: Olivier Galibert @ 2006-02-03 18:04 UTC (permalink / raw) To: linux-kernel On Fri, Feb 03, 2006 at 10:53:50AM -0500, Jim Crilly wrote: > A bug in HAL is not a bug in Linux. If the HAL people need to make some > changes to their daemon to make it play nice with cdrecord and the like > that's fine, but telling people here makes no sense. Actually, since at that point in time HAL is the only way to do device discovery with the linux kernel, problems in HAL are problems in linux. There is *no* other way than HAL to do the mapping between a point in the sysfs tree and a device node in /dev[1]. OG. [1] Unless you consider stating every node in /dev acceptable just to find the correct major/minor. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 18:04 ` Olivier Galibert @ 2006-02-03 18:13 ` Kay Sievers 2006-02-03 18:45 ` Olivier Galibert 2006-02-03 18:37 ` Jim Crilly 2006-02-03 19:50 ` Phillip Susi 2 siblings, 1 reply; 717+ messages in thread From: Kay Sievers @ 2006-02-03 18:13 UTC (permalink / raw) To: Olivier Galibert, linux-kernel On Fri, Feb 03, 2006 at 07:04:21PM +0100, Olivier Galibert wrote: > On Fri, Feb 03, 2006 at 10:53:50AM -0500, Jim Crilly wrote: > > A bug in HAL is not a bug in Linux. If the HAL people need to make some > > changes to their daemon to make it play nice with cdrecord and the like > > that's fine, but telling people here makes no sense. > > Actually, since at that point in time HAL is the only way to do device > discovery with the linux kernel, problems in HAL are problems in > linux. There is *no* other way than HAL to do the mapping between a > point in the sysfs tree and a device node in /dev[1]. That's all nonsense! $ udevinfo -r -q name -p /block/sr0 /dev/sr0 $ udevinfo -q path -n /dev/sr0 /block/sr0 $ udevinfo -q all -p /block/sr0 P: /block/sr0 N: sr0 S: disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0 S: cdrecorder S: cdrom E: ID_VENDOR=MATSHITA E: ID_MODEL=DVD-RAM_UJ-822S E: ID_REVISION=1.61 E: ID_SERIAL= E: ID_TYPE=cd E: ID_BUS=scsi E: ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0 Kay ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 18:13 ` Kay Sievers @ 2006-02-03 18:45 ` Olivier Galibert 0 siblings, 0 replies; 717+ messages in thread From: Olivier Galibert @ 2006-02-03 18:45 UTC (permalink / raw) To: Kay Sievers; +Cc: linux-kernel On Fri, Feb 03, 2006 at 07:13:14PM +0100, Kay Sievers wrote: > That's all nonsense! > > $ udevinfo -r -q name -p /block/sr0 > /dev/sr0 Ok, I couldn't find it for love or money. But it's exactly what's needed. I see all the useful information is in /dev/.udev.tdb. I need to have a look at that TDB format, but exporting the database to other programs works. OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 18:04 ` Olivier Galibert 2006-02-03 18:13 ` Kay Sievers @ 2006-02-03 18:37 ` Jim Crilly 2006-02-04 15:35 ` Krzysztof Halasa 2006-02-03 19:50 ` Phillip Susi 2 siblings, 1 reply; 717+ messages in thread From: Jim Crilly @ 2006-02-03 18:37 UTC (permalink / raw) To: Olivier Galibert, linux-kernel On 02/03/06 07:04:21PM +0100, Olivier Galibert wrote: > On Fri, Feb 03, 2006 at 10:53:50AM -0500, Jim Crilly wrote: > > A bug in HAL is not a bug in Linux. If the HAL people need to make some > > changes to their daemon to make it play nice with cdrecord and the like > > that's fine, but telling people here makes no sense. > > Actually, since at that point in time HAL is the only way to do device > discovery with the linux kernel, problems in HAL are problems in > linux. There is *no* other way than HAL to do the mapping between a > point in the sysfs tree and a device node in /dev[1]. > > OG. > > [1] Unless you consider stating every node in /dev acceptable just to > find the correct major/minor. It's not about device discovery, hald is polling removable devices every 2s to see if new media was inserted and when it polls a CD drive that's currently burning a disc it causes problems. It's documented in Debian bug #262678. Jim. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 18:37 ` Jim Crilly @ 2006-02-04 15:35 ` Krzysztof Halasa 2006-02-04 15:43 ` Matthias Andree 2006-02-05 7:40 ` Jan Engelhardt 0 siblings, 2 replies; 717+ messages in thread From: Krzysztof Halasa @ 2006-02-04 15:35 UTC (permalink / raw) To: Olivier Galibert; +Cc: linux-kernel "Jim Crilly" <jim@why.dont.jablowme.net> writes: > It's not about device discovery, hald is polling removable devices every 2s > to see if new media was inserted and when it polls a CD drive that's > currently burning a disc it causes problems. It's documented in Debian bug > #262678. Ok. So what's wrong with cdrecord using O_EXCL (and maybe retrying for few seconds) so no other program (hald or, say, a user mistaking a device) can interrupt it? And, if we are here, what's wrong with hald using O_EXCL to not interrupt any other program (does hald need to check the media if it's in use)? I assume the problem wouldn't exist with hald using O_EXCL and cdrecord not (yet) using it, would it? -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-04 15:35 ` Krzysztof Halasa @ 2006-02-04 15:43 ` Matthias Andree 2006-02-04 18:33 ` Jan Engelhardt 2006-02-05 7:40 ` Jan Engelhardt 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-04 15:43 UTC (permalink / raw) To: Krzysztof Halasa; +Cc: Olivier Galibert, linux-kernel On Sat, 04 Feb 2006, Krzysztof Halasa wrote: > And, if we are here, what's wrong with hald using O_EXCL to not > interrupt any other program (does hald need to check the media > if it's in use)? I assume the problem wouldn't exist with hald > using O_EXCL and cdrecord not (yet) using it, would it? Let me throw in a stupid question: Is O_EXCL cooperative, in that other access is only blocked if both tasks use open(...O_EXCL...)? -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-04 15:43 ` Matthias Andree @ 2006-02-04 18:33 ` Jan Engelhardt 0 siblings, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-04 18:33 UTC (permalink / raw) To: Matthias Andree; +Cc: Krzysztof Halasa, Olivier Galibert, linux-kernel > >> And, if we are here, what's wrong with hald using O_EXCL to not >> interrupt any other program (does hald need to check the media >> if it's in use)? I assume the problem wouldn't exist with hald >> using O_EXCL and cdrecord not (yet) using it, would it? > >Let me throw in a stupid question: Is O_EXCL cooperative, in that other >access is only blocked if both tasks use open(...O_EXCL...)? > That would be some sort of "shared" what you describe. O_EXCL basically means that there may only be one file descriptor open on it across the whole kernel. "if both tasks" already includes multiple file descriptors. (Note that dup() does not really make a new filedescriptor.) Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-04 15:35 ` Krzysztof Halasa 2006-02-04 15:43 ` Matthias Andree @ 2006-02-05 7:40 ` Jan Engelhardt 2006-02-05 16:04 ` Krzysztof Halasa 2006-02-05 16:15 ` Phillip Susi 1 sibling, 2 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-05 7:40 UTC (permalink / raw) To: Krzysztof Halasa; +Cc: Olivier Galibert, linux-kernel >> It's not about device discovery, hald is polling removable devices every 2s >> to see if new media was inserted and when it polls a CD drive that's >> currently burning a disc it causes problems. It's documented in Debian bug >> #262678. > >Ok. So what's wrong with cdrecord using O_EXCL (and maybe retrying >for few seconds) so no other program (hald or, say, a user mistaking >a device) can interrupt it? > I would say we all forgot to RTFM. Because O_EXCL does nothing *unless* O_CREAT is specified, which probably *is not* specified in cdrecord or hal. There is no reason to have hal or cdrecord create a device node - which you can't do with open() anyway. Jan Engelhardt -- | Software Engineer and Linux/Unix Network Administrator | Alphagate Systems, http://alphagate.hopto.org/ | jengelh's site, http://jengelh.hopto.org/ ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-05 7:40 ` Jan Engelhardt @ 2006-02-05 16:04 ` Krzysztof Halasa 2006-02-05 16:15 ` Phillip Susi 1 sibling, 0 replies; 717+ messages in thread From: Krzysztof Halasa @ 2006-02-05 16:04 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Olivier Galibert, linux-kernel Jan Engelhardt <jengelh@linux01.gwdg.de> writes: > I would say we all forgot to RTFM. Because O_EXCL does nothing *unless* > O_CREAT is specified, which probably *is not* specified in cdrecord or > hal. That would be the case if the CD writter wasn't a block device. For a block device fs/block_dev.c: static int blkdev_open(struct inode * inode, struct file * filp) { ... if (!(filp->f_flags & O_EXCL) ) return 0; if (!(res = bd_claim(bdev, filp))) return 0; blkdev_put(bdev); return res; -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-05 7:40 ` Jan Engelhardt 2006-02-05 16:04 ` Krzysztof Halasa @ 2006-02-05 16:15 ` Phillip Susi 2006-02-05 17:50 ` Kyle Moffett 1 sibling, 1 reply; 717+ messages in thread From: Phillip Susi @ 2006-02-05 16:15 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Krzysztof Halasa, Olivier Galibert, linux-kernel Jan Engelhardt wrote: > I would say we all forgot to RTFM. Because O_EXCL does nothing *unless* > O_CREAT is specified, which probably *is not* specified in cdrecord or > hal. There is no reason to have hal or cdrecord create a device node - > which you can't do with open() anyway. > I think you are misinterpreting the man page, because it isn't worded very clearly. It should not even mention O_CREAT because it has nothing to do with O_EXCL; it is just repeating the semantics of O_CREAT ( if the file already exists, the call fails ) which would of course, apply if you do use O_CREAT in conjunction with any other flag including O_EXCL. It does not say that you must use O_EXCL with O_CREAT. The rest of the description talks about using lockfiles as an alternative to ensure exclusive access to the file on NFS where O_EXCL is broken. The intent of O_EXCL is clearly to provide the caller with exclusive access to the file. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-05 16:15 ` Phillip Susi @ 2006-02-05 17:50 ` Kyle Moffett 2006-02-05 21:15 ` Jan Engelhardt 2006-02-05 22:27 ` Neil Brown 0 siblings, 2 replies; 717+ messages in thread From: Kyle Moffett @ 2006-02-05 17:50 UTC (permalink / raw) To: Phillip Susi Cc: Jan Engelhardt, Krzysztof Halasa, Olivier Galibert, linux-kernel On Feb 05, 2006, at 11:15, Phillip Susi wrote: > Jan Engelhardt wrote: >> I would say we all forgot to RTFM. Because O_EXCL does nothing >> *unless* O_CREAT is specified, which probably *is not* specified >> in cdrecord or hal. There is no reason to have hal or cdrecord >> create a device node - which you can't do with open() anyway. > > I think you are misinterpreting the man page, because it isn't > worded very clearly. It should not even mention O_CREAT because it > has nothing to do with O_EXCL; it is just repeating the semantics > of O_CREAT ( if the file already exists, the call fails ) which > would of course, apply if you do use O_CREAT in conjunction with > any other flag including O_EXCL. It does not say that you must use > O_EXCL with O_CREAT. The rest of the description talks about using > lockfiles as an alternative to ensure exclusive access to the file > on NFS where O_EXCL is broken. The intent of O_EXCL is clearly to > provide the caller with exclusive access to the file. You don't have this right either. The way open() works: If you specify O_CREAT (and not O_EXCL), it will create the file if it does not exist, and open the existing file otherwise. If you specify O_EXCL (and not O_CREAT), it is implementation defined what will happen (in the Linux case, this opens a block device for exclusive access). If you specify O_CREAT|O_EXCL, it will atomically create the file if it does not exist, otherwise it will return the error -EEXIST. Cheers, Kyle Moffett -- Q: Why do programmers confuse Halloween and Christmas? A: Because OCT 31 == DEC 25. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-05 17:50 ` Kyle Moffett @ 2006-02-05 21:15 ` Jan Engelhardt 2006-02-05 22:27 ` Neil Brown 1 sibling, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-05 21:15 UTC (permalink / raw) To: Kyle Moffett Cc: Phillip Susi, Krzysztof Halasa, Olivier Galibert, linux-kernel > > If you specify O_EXCL (and not O_CREAT), it is implementation defined what will > happen (in the Linux case, this opens a block device for exclusive access). > And with plain files, I supose it's free-for-all, right? 'Cause that's what my testcase yielded. :/ Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-05 17:50 ` Kyle Moffett 2006-02-05 21:15 ` Jan Engelhardt @ 2006-02-05 22:27 ` Neil Brown 2006-02-06 11:15 ` Krzysztof Halasa 1 sibling, 1 reply; 717+ messages in thread From: Neil Brown @ 2006-02-05 22:27 UTC (permalink / raw) To: Kyle Moffett Cc: Phillip Susi, Jan Engelhardt, Krzysztof Halasa, Olivier Galibert, linux-kernel On Sunday February 5, mrmacman_g4@mac.com wrote: > > If you specify O_EXCL (and not O_CREAT), it is implementation defined > what will happen (in the Linux case, this opens a block device for > exclusive access). With Linux, O_EXCL on a block devices isn't *exactly* exclusive access. It only provided you exclusive access against other people who ask for exclusive access, which includes in-kernel usage like mount, md, dm, and swap. So if you open a block device O_EXCL, it will fail if the block device is already open O_EXCL or is mounted, or in use by the kernel in some other way (including if a partition is open O_EXCL). An if you succeed in getting an O_EXCL open, then no-one else will be able to get an O_EXCL open, or mount the filesystem etc. Bit on open without O_EXCL will always succeed no matter whether someone has it O_EXCL or not. So it is a lot like an advisory exclusive lock on the whole block device. NeilBrown ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-05 22:27 ` Neil Brown @ 2006-02-06 11:15 ` Krzysztof Halasa 2006-02-06 14:58 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Krzysztof Halasa @ 2006-02-06 11:15 UTC (permalink / raw) To: Neil Brown Cc: Kyle Moffett, Phillip Susi, Jan Engelhardt, Olivier Galibert, linux-kernel Neil Brown <neilb@suse.de> writes: > Bit on open without O_EXCL will always succeed no matter whether > someone has it O_EXCL or not. Ok. That means hald has no use for it, but cdrecord and similar programs could use it. -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-06 11:15 ` Krzysztof Halasa @ 2006-02-06 14:58 ` Jan Engelhardt 2006-02-06 18:17 ` Krzysztof Halasa 0 siblings, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-02-06 14:58 UTC (permalink / raw) To: Krzysztof Halasa Cc: Neil Brown, Kyle Moffett, Phillip Susi, Olivier Galibert, linux-kernel > >> Bit on open without O_EXCL will always succeed no matter whether >> someone has it O_EXCL or not. > >Ok. That means hald has no use for it, but cdrecord and similar >programs could use it. But that again sounds like hald won't use O_EXCL, therefore could always be able to open the device and potentially send commands which interrupt cd writing. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-06 14:58 ` Jan Engelhardt @ 2006-02-06 18:17 ` Krzysztof Halasa 2006-02-06 18:37 ` Phillip Susi 0 siblings, 1 reply; 717+ messages in thread From: Krzysztof Halasa @ 2006-02-06 18:17 UTC (permalink / raw) To: Jan Engelhardt Cc: Neil Brown, Kyle Moffett, Phillip Susi, Olivier Galibert, linux-kernel Jan Engelhardt <jengelh@linux01.gwdg.de> writes: > But that again sounds like hald won't use O_EXCL, therefore could always be > able to open the device and potentially send commands which interrupt cd > writing. Yep. Both need that. And I need some coffee to recover from non-logical thinking. -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-06 18:17 ` Krzysztof Halasa @ 2006-02-06 18:37 ` Phillip Susi 2006-02-09 16:09 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Phillip Susi @ 2006-02-06 18:37 UTC (permalink / raw) To: Krzysztof Halasa Cc: Jan Engelhardt, Neil Brown, Kyle Moffett, Olivier Galibert, linux-kernel Out of curiosity, what commands does hal send the drive that can interrupt burning? I've been reading the MMC-5 standard lately and it looks like while the drive is burning, attempts to send it other commands that would interfere with the burn are supposed to be failed with an error code indicating that a burn is in progress, and thus, avoid making a coaster. Krzysztof Halasa wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> writes: > > >> But that again sounds like hald won't use O_EXCL, therefore could always be >> able to open the device and potentially send commands which interrupt cd >> writing. >> > > Yep. Both need that. And I need some coffee to recover from > non-logical thinking. > ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-06 18:37 ` Phillip Susi @ 2006-02-09 16:09 ` Jan Engelhardt 0 siblings, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-09 16:09 UTC (permalink / raw) To: Phillip Susi Cc: Krzysztof Halasa, Neil Brown, Kyle Moffett, Olivier Galibert, linux-kernel > > Out of curiosity, what commands does hal send the drive that can interrupt > burning? I've been reading the MMC-5 standard lately and it looks like while > the drive is burning, attempts to send it other commands that would interfere > with the burn are supposed to be failed with an error code indicating that a > burn is in progress, and thus, avoid making a coaster. > At least there needs to be a command that is not ignored to stop a burn. Though, hald would not be /that/ evil. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 18:04 ` Olivier Galibert 2006-02-03 18:13 ` Kay Sievers 2006-02-03 18:37 ` Jim Crilly @ 2006-02-03 19:50 ` Phillip Susi 2006-02-03 20:47 ` Olivier Galibert 2 siblings, 1 reply; 717+ messages in thread From: Phillip Susi @ 2006-02-03 19:50 UTC (permalink / raw) To: Olivier Galibert, linux-kernel Olivier Galibert wrote: > Actually, since at that point in time HAL is the only way to do device > discovery with the linux kernel, problems in HAL are problems in > linux. There is *no* other way than HAL to do the mapping between a > point in the sysfs tree and a device node in /dev[1]. That information is available in /sys, which is how HAL discovers it. If you wanted to, you could bypass HAL and go directly to /sys to perform your own discovery. Also HAL is not a part of the linux kernel, therefore a problem in HAL is NOT a problem in linux, even if there were no other way to get the information as you ( wrongly ) asserted. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 19:50 ` Phillip Susi @ 2006-02-03 20:47 ` Olivier Galibert 2006-02-03 21:06 ` Phillip Susi 0 siblings, 1 reply; 717+ messages in thread From: Olivier Galibert @ 2006-02-03 20:47 UTC (permalink / raw) To: Phillip Susi; +Cc: linux-kernel On Fri, Feb 03, 2006 at 02:50:11PM -0500, Phillip Susi wrote: > Olivier Galibert wrote: > >Actually, since at that point in time HAL is the only way to do device > >discovery with the linux kernel, problems in HAL are problems in > >linux. There is *no* other way than HAL to do the mapping between a > >point in the sysfs tree and a device node in /dev[1]. > > That information is available in /sys, which is how HAL discovers it. No, it isn't. OTOH, udev maintains it, so I guess that's good enough. It makes udev the kernel interface though. I hope they now care about compatibility (/dev/.udev.pdb vs. /dev/.udev/db/* anyone?). > If you wanted to, you could bypass HAL and go directly to /sys to > perform your own discovery. Also HAL is not a part of the linux kernel, > therefore a problem in HAL is NOT a problem in linux, even if there were > no other way to get the information as you ( wrongly ) asserted. Bullshit. If <x> is the only interface available to a kernel service, then <x> is part of the kernel whether you like it or not. Case in point, the ALSA library. OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 20:47 ` Olivier Galibert @ 2006-02-03 21:06 ` Phillip Susi 2006-02-04 0:02 ` Olivier Galibert 0 siblings, 1 reply; 717+ messages in thread From: Phillip Susi @ 2006-02-03 21:06 UTC (permalink / raw) To: Olivier Galibert, Phillip Susi, linux-kernel Olivier Galibert wrote: > No, it isn't. OTOH, udev maintains it, so I guess that's good enough. > It makes udev the kernel interface though. I hope they now care about > compatibility (/dev/.udev.pdb vs. /dev/.udev/db/* anyone?). > Yes, it is, where do you think udev gets it's information from? That's right, from /sys. Sysfs is the kernel interface, not udev; the 'u' in udev is for 'user', as in NOT part of the kernel. > > Bullshit. If <x> is the only interface available to a kernel service, > then <x> is part of the kernel whether you like it or not. Case in > point, the ALSA library. Bullshit yourself. If cdrecord is the only application for burning cds, that does not make it the kernel interface for cds, and certainly does not make it part of the kernel. The kernel interface is the point of interaction between user and kernel code, which is sysfs. Udev and HAL are two user mode ( NOT parts of the kernel ) components built to put the information from sysfs to use in user space, and other applications are encouraged to utilize the services those daemons provide. By no stretch of the imagination does that make them part of the kernel. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 21:06 ` Phillip Susi @ 2006-02-04 0:02 ` Olivier Galibert 2006-02-04 16:56 ` Phillip Susi 0 siblings, 1 reply; 717+ messages in thread From: Olivier Galibert @ 2006-02-04 0:02 UTC (permalink / raw) To: Phillip Susi; +Cc: linux-kernel On Fri, Feb 03, 2006 at 04:06:13PM -0500, Phillip Susi wrote: > Olivier Galibert wrote: > >No, it isn't. OTOH, udev maintains it, so I guess that's good enough. > >It makes udev the kernel interface though. I hope they now care about > >compatibility (/dev/.udev.pdb vs. /dev/.udev/db/* anyone?). > > > > Yes, it is, where do you think udev gets it's information from? The device node name? From the rules in /etc/udev/rules.d/*. Udev is the one which creates it in the first place, deriving it in a user-defined way from the sysfs information. It does _not_ give back that information to the kernel. Maybe it should. > >Bullshit. If <x> is the only interface available to a kernel service, > >then <x> is part of the kernel whether you like it or not. Case in > >point, the ALSA library. > > Bullshit yourself. If cdrecord is the only application for burning cds, > that does not make it the kernel interface for cds, and certainly does > not make it part of the kernel. The kernel interface is the point of > interaction between user and kernel code, which is sysfs. The kernel does not provide a cd burning service, only a scsi packet transport service called SG_IO. The kernel *does* provide a device enumeration service, only it does it at this point through udev for reasons that are 50% technical and 50% political. If you want to be able to use a 2.6 kernel with hotplug devices udev[1] is mandatory. As such, from an engineering point of view, udev is part of the kernel even if it isn't in the source tarball on kernel.org. And for now it is the lowest level interface to device enumeration. OG. [1] Or hotplug, maybe. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-04 0:02 ` Olivier Galibert @ 2006-02-04 16:56 ` Phillip Susi 0 siblings, 0 replies; 717+ messages in thread From: Phillip Susi @ 2006-02-04 16:56 UTC (permalink / raw) To: Olivier Galibert, Phillip Susi, linux-kernel Olivier Galibert wrote: > The device node name? From the rules in /etc/udev/rules.d/*. Udev is > the one which creates it in the first place, deriving it in a > user-defined way from the sysfs information. It does _not_ give back > that information to the kernel. Maybe it should. > > Ohh, I see what you are saying now. Yes, it is up to udev to create the device nodes, and the kernel does not know or care about the nodes. If an application wants to find existing nodes it can open it needs to query udev or hal. If it wants to find out what devices the kernel exports, it can look in /sys and make its own devnode to access them. > The kernel does not provide a cd burning service, only a scsi packet > transport service called SG_IO. > > The kernel *does* provide a device enumeration service, only it does > it at this point through udev for reasons that are 50% technical and > What part of the user/kernel separation don't you understand? udev is user mode code which interfaces with the kernel via sysfs. Other user mode code is free to do that as well, or just use udev. Either way, the only kernel interface involved is sysfs. The kernel does not know or care about udev or what it does, only sysfs. The kernel provides enumeration through sysfs, and that is all. > 50% political. If you want to be able to use a 2.6 kernel with > hotplug devices udev[1] is mandatory. As such, from an engineering > point of view, udev is part of the kernel even if it isn't in the > source tarball on kernel.org. And for now it is the lowest level > interface to device enumeration. > > Your logic is flawed. X + Y = Z does NOT mean that X ( linux ) and Y ( udev ) are one and the same even if Z ( a usable GNU/Linux system with hotplug support ) is desirable. The kernel provides sysfs as it's interface, and udev and hal provide higher level interfaces. In much the same way, the kernel frame buffer driver provides one interface, and Xorg provides higher level interface built on top of the kernel interface. By no stretch of the imagination is Xorg the kernel interface to the video card, which is what you are arguing. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 15:20 ` Joerg Schilling 2006-02-03 15:53 ` Jim Crilly @ 2006-02-03 16:10 ` Phillip Susi 2006-02-03 16:56 ` Joerg Schilling 2006-02-03 18:20 ` [cdrtools PATCH (GPL)] " Matthias Andree 2 siblings, 1 reply; 717+ messages in thread From: Phillip Susi @ 2006-02-03 16:10 UTC (permalink / raw) To: Joerg Schilling Cc: acahalan, mrmacman_g4, matthias.andree, linux-kernel, jim, jengelh, James, j Joerg Schilling wrote: > As including O_EXCL would disallow to use more than one cdrecord > program at the same time, there is no chance for the mains stream source. > > You CAN'T have multiple cdrecord processes burning the same disc at the same time; the very idea makes no sense. The O_EXCL just prevents you from trying such foolishness and creating a coaster. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 16:10 ` Phillip Susi @ 2006-02-03 16:56 ` Joerg Schilling 2006-02-03 19:06 ` Jan Engelhardt 2006-02-03 20:01 ` Phillip Susi 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 16:56 UTC (permalink / raw) To: schilling, psusi Cc: mrmacman_g4, matthias.andree, linux-kernel, jim, jengelh, James, j, acahalan Phillip Susi <psusi@cfl.rr.com> wrote: > You CAN'T have multiple cdrecord processes burning the same disc at the > same time; the very idea makes no sense. The O_EXCL just prevents you > from trying such foolishness and creating a coaster. It does not prevent you from creatig a coaster in case you connect e.g. two ATAPI writers to the same ATA cable. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 16:56 ` Joerg Schilling @ 2006-02-03 19:06 ` Jan Engelhardt 2006-02-03 19:15 ` Joerg Schilling 2006-02-03 19:22 ` Matthias Andree 2006-02-03 20:01 ` Phillip Susi 1 sibling, 2 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-03 19:06 UTC (permalink / raw) To: Joerg Schilling Cc: psusi, mrmacman_g4, matthias.andree, linux-kernel, jim, James, j, acahalan > >> You CAN'T have multiple cdrecord processes burning the same disc at the >> same time; the very idea makes no sense. The O_EXCL just prevents you >> from trying such foolishness and creating a coaster. > >It does not prevent you from creatig a coaster in case you connect e.g. >two ATAPI writers to the same ATA cable. > Apart from transfer speed issues and potential buffer underruns coming along with that, is there anything technically impossible with writing to two ATAPI drives at the same time? Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 19:06 ` Jan Engelhardt @ 2006-02-03 19:15 ` Joerg Schilling 2006-02-04 11:08 ` Jan Engelhardt 2006-02-03 19:22 ` Matthias Andree 1 sibling, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 19:15 UTC (permalink / raw) To: schilling, jengelh Cc: psusi, mrmacman_g4, matthias.andree, linux-kernel, jim, James, j, acahalan Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > >> You CAN'T have multiple cdrecord processes burning the same disc at the > >> same time; the very idea makes no sense. The O_EXCL just prevents you > >> from trying such foolishness and creating a coaster. > > > >It does not prevent you from creatig a coaster in case you connect e.g. > >two ATAPI writers to the same ATA cable. > > > Apart from transfer speed issues and potential buffer underruns coming > along with that, is there anything technically impossible with writing to > two ATAPI drives at the same time? It depends on what type of drive you use. If you chose a drive that blocks the ATA cable while processing a START/STOP/UNIT, you are out of luck. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 19:15 ` Joerg Schilling @ 2006-02-04 11:08 ` Jan Engelhardt 0 siblings, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-04 11:08 UTC (permalink / raw) To: Joerg Schilling Cc: psusi, mrmacman_g4, matthias.andree, linux-kernel, jim, James, j, acahalan >> >It does not prevent you from creatig a coaster in case you connect e.g. >> >two ATAPI writers to the same ATA cable. >> > >> Apart from transfer speed issues and potential buffer underruns coming >> along with that, is there anything technically impossible with writing to >> two ATAPI drives at the same time? > >It depends on what type of drive you use. > >If you chose a drive that blocks the ATA cable while processing a >START/STOP/UNIT, you are out of luck. > That may be what I experienced with that aopen writer. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 19:06 ` Jan Engelhardt 2006-02-03 19:15 ` Joerg Schilling @ 2006-02-03 19:22 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-03 19:22 UTC (permalink / raw) To: Jan Engelhardt; +Cc: linux-kernel Jan Engelhardt schrieb am 2006-02-03: > > > >> You CAN'T have multiple cdrecord processes burning the same disc at the > >> same time; the very idea makes no sense. The O_EXCL just prevents you > >> from trying such foolishness and creating a coaster. > > > >It does not prevent you from creatig a coaster in case you connect e.g. > >two ATAPI writers to the same ATA cable. > > > Apart from transfer speed issues and potential buffer underruns coming > along with that, is there anything technically impossible with writing to > two ATAPI drives at the same time? Bus locking while waiting for command completion. If you start a long-lasting operation on one device, the other device on the same cable is blocked so you cannot feed the other. Same holds for SCSI if one of the devices involved doesn't disconnect from the bus for that long-lasting command. Try for instance "eject /dev/hdc" while writing to /dev/hdd, or same stuff with sr0 and sr1. Been there, done that, got a coaster. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 16:56 ` Joerg Schilling 2006-02-03 19:06 ` Jan Engelhardt @ 2006-02-03 20:01 ` Phillip Susi 1 sibling, 0 replies; 717+ messages in thread From: Phillip Susi @ 2006-02-03 20:01 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, jim, jengelh, James, j, acahalan Joerg Schilling wrote: >> You CAN'T have multiple cdrecord processes burning the same disc at the >> same time; the very idea makes no sense. The O_EXCL just prevents you >> from trying such foolishness and creating a coaster. >> > > It does not prevent you from creatig a coaster in case you connect e.g. > two ATAPI writers to the same ATA cable. So what? What does that have to do with my rebutting your statement that O_EXCL prevents multiple cdrecords? O_EXCL also does not prevent you from kicking the plug out of the wall while burning, but it DOES prevent another process from trying to mess with the drive while cdrecord is and clobbering things up, which is a good thing. It does not prevent you from using cdrecord at the same time on different drives. ^ permalink raw reply [flat|nested] 717+ messages in thread
* [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 15:20 ` Joerg Schilling 2006-02-03 15:53 ` Jim Crilly 2006-02-03 16:10 ` Phillip Susi @ 2006-02-03 18:20 ` Matthias Andree 2006-02-03 18:31 ` Joerg Schilling 2 siblings, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-03 18:20 UTC (permalink / raw) To: Joerg Schilling; +Cc: acahalan, linux-kernel, cdwrite Joerg Schilling schrieb am 2006-02-03: > Albert Cahalan <acahalan@gmail.com> wrote: > > > On 2/2/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > > > > > I see the same thing with, the only external kernel patch I have > > > > applied is Suspend2. The ATA scanbus code tries to > > > > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since > > > > > > This is not cdrecord but a bastardized version...... > > > > True enough, but it would work great if you'd fix that bug > > that makes cdrecord give up while scanning. I guess > > that's one more patch Debian will be applying. > > As including O_EXCL would disallow to use more than one cdrecord > program at the same time, there is no chance for the mains stream source. Nobody suggested O_EXCL as a fix for the scanning bug. It seems your capabilities to follow a complex discussion are generally overtaxed a bit... sorry for overestimating you. So patches to the rescue -- please review the patch below (for 2.01.01a05). Note that GPL 2a and 2c apply, so you cannot merge a modified version of my patch without adding a tag that you goofed my fixes. If deemed safe, please apply and test. It appears to work for me (as in: blanks and writes CD-RW when setuid root) on SUSE Linux 10.0 (kernel 2.6.13-15.7 i686 bigmem 4kstacks blah sülz) and it compiles properly on FreeBSD 6-STABLE i686. (Sorry for the off-topic bloat, but as we've had so many messages, a few KB patching won't add much to the pain any more.) And no, I am not going to read Solaris sources. Linux does not have to care how Solaris works, but your Linux interface code has to work properly on Linux and not put up artificial obstacles. > Well the big difference with Solaris is that several modifications have been > applied by Sun to the vold sub-system on Solaris in order to decently > support cdrecord. For the 100th time, you need to substantiate your bug claims or feature requests with good reasons. "Somebody else is doing it." is not sufficient. > The last change was done with Nevada Build 21 in August 2005. Is this part of the Solaris 10 update shipped earlier this year? Now for the patch diff, diffstat and comments first: # cdrecord/cdrecord.c | 114 2 + 105 - 7 ! # mkisofs/write.c | 4 0 + 0 - 4 ! # libscg/scsi-linux-sg.c | 82 3 + 54 - 25 ! # 3 files changed, 5 insertions(+), 159 deletions(-), 36 modifications(!) - The cdrecord patch removes bogus Linux warnings and adds the GPL 2a/2c guacamole. - The write.c patch fixes trigraph, a patch Jörg keeps losing. - The libscg patch removes bogus warnings, kills the ATA transport -- this is an alpha version, not stable code (it can be autodetected by looking at the device name, I'm not sure if the LF_ATA is really useful nowaday), fixes the scanning bugs and unifies Linux SG_IO device namespaces. Further observations: - Jörg wants the kernel to add junk for device enumeration when removing artificial barriers from libscg does the same job? Now that's impressive after all his bold claims. I think Jens and a few other people deserve apologies. - the code should glob /dev/sg* and probe everything and filter out dupes by looking at major/minor. - linuxcheck() was broken and assuming fixed-format, the changed-interface warning disappeared with linux 2.6.10 ('1' < '8'), and is obsolete anyhow since 2.01.01a05. Nevermind the whining :-P - Jörg makes a big fuss about duplicated code in Linux kernel, but this appears more of a "not in my back-yard" kind complaint... duplicated code in cdrecord anyone? Two screenful removed by the patch, help yourself. How does this look (setuid root, the kernel appears to refuse the obsolete "REZERO UNIT" which breaks f.i. cdrecord -toc)? $ bins/i686-linux-cc/cdrecord -scanbus Cdrecord-Clone 2.01.01a04 (i686-pc-linux-gnu) Copyright (C) 1995-2006 Joerg Schilling, 2006 Matthias Andree NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord that removed some bogus whining of the original author. Although unlikely, it may have bugs that are not present in the original version. Please send bug reports and support requests to <matthias.andree@gmx.de>. The original author should not be bothered with problems of this version. Linux sg driver version: 3.5.27 Using libscg version 'schily-0.8'. bins/i686-linux-cc/cdrecord: Warning: using inofficial libscg transport code version (-scsi-linux-sg.c-1.86+ma '@(#)scsi-linux-sg.c 1.86 05/11/22 Copyright 1997 J. Schilling'). scsibus0: 0,0,0 0) 'ATA ' 'SAMSUNG SP2004C ' 'VM10' Disk 0,1,0 1) * ... scsibus1: 1,0,0 100) '_NEC ' 'DVD_RW ND-4550A ' '1.07' Removable CD-ROM 1,1,0 101) 'PLEXTOR ' 'CD-R PX-W4824A' '1.06' Removable CD-ROM 1,2,0 102) * ... scsibus2: 2,0,0 200) * 2,1,0 201) * 2,2,0 202) 'PLEXTOR ' 'CD-ROM PX-32TS ' '1.02' Removable CD-ROM 2,3,0 203) * ... 0,0,0 is /dev/sda /dev/sg0, driven by sd and sg (libata) 1,*,0 are /dev/hdc /dev/hdd, driven by ide-cd (via82cxxx) 2,2,0 is /dev/sr0 /dev/sg1, driven by sr and sg (sym53c8xx_2) Sorry 'bout posting this as bloated context patch, this is for Jörg-Schilling-compliance and perhaps Solaris 2.6 too. *** ./cdrecord/cdrecord.c.orig Sun Jan 29 19:52:03 2006 --- ./cdrecord/cdrecord.c Fri Feb 3 17:17:08 2006 *************** *** 245,251 **** LOCAL void print_wrmodes __PR((cdr_t *dp)); LOCAL BOOL check_wrmode __PR((cdr_t *dp, int wmode, int tflags)); LOCAL void set_wrmode __PR((cdr_t *dp, int wmode, int tflags)); - LOCAL void linuxcheck __PR((void)); struct exargs { SCSI *scgp; --- 245,250 ---- *************** *** 352,368 **** # define CLONE_TITLE "" #endif if ((flags & F_MSINFO) == 0 || lverbose || flags & F_VERSION) { ! printf("Cdrecord%s%s %s (%s-%s-%s) Copyright (C) 1995-2006 Jörg Schilling\n", PRODVD_TITLE, CLONE_TITLE, cdr_version, HOST_CPU, HOST_VENDOR, HOST_OS); #if defined(SOURCE_MODIFIED) || !defined(IS_SCHILY_XCONFIG) ! #define INSERT_YOUR_EMAIL_ADDRESS_HERE #define NO_SUPPORT 0 printf("NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord\n"); ! printf(" and thus may have bugs that are not present in the original version.\n"); #if NO_SUPPORT printf(" The author of the modifications decided not to provide a support e-mail\n"); printf(" address so there is absolutely no support for this version.\n"); --- 351,370 ---- # define CLONE_TITLE "" #endif if ((flags & F_MSINFO) == 0 || lverbose || flags & F_VERSION) { ! printf("Cdrecord%s%s %s (%s-%s-%s) Copyright (C) 1995-2006 Joerg Schilling, 2006 Matthias Andree\n", PRODVD_TITLE, CLONE_TITLE, cdr_version, HOST_CPU, HOST_VENDOR, HOST_OS); + #define SOURCE_MODIFIED 1 + #if defined(SOURCE_MODIFIED) || !defined(IS_SCHILY_XCONFIG) ! #define INSERT_YOUR_EMAIL_ADDRESS_HERE "matthias.andree@gmx.de" #define NO_SUPPORT 0 printf("NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord\n"); ! printf(" that removed some bogus whining of the original author. Although unlikely,\n"); ! printf(" it may have bugs that are not present in the original version.\n"); #if NO_SUPPORT printf(" The author of the modifications decided not to provide a support e-mail\n"); printf(" address so there is absolutely no support for this version.\n"); *************** *** 380,410 **** #endif } - /* - * I am sorry that even for version 1.308 of cdrecord.c, I am forced to do - * things like this, but defective versions of cdrecord cause a lot of - * work load to me and it seems to be impossible to otherwise convince - * SuSE to cooperate. - * As people contact me and bother me with the related problems, - * it is obvious that SuSE is violating subsection 6 in the preamble of - * the GPL. - * - * The reason for including a test against SuSE's private - * distribution environment is only that SuSE violates the GPL for - * a long time and seems not to be willing to follow the requirements - * imposed by the GPL. If SuSE starts to ship non defective versions - * of cdrecord or informs their customers that they would need to - * compile cdrecord themselves in order to get a working cdrecord, - * they should contact me for a permission to change the related test. - * - * Note that although the SuSE test is effective only for SuSE, the - * intention to have non bastardized versions out is not limited - * to SuSE. It is bad to see that in special in the "Linux" business, - * companies prefer a model with many proprietary differing programs - * instead of cooperating with the program authors. - */ - linuxcheck(); /* For version 1.308 of cdrecord.c */ - if (flags & F_VERSION) exit(0); /* --- 382,387 ---- *************** *** 4699,4780 **** } dsp->ds_wrmode = WM_NONE; } - - /* - * I am sorry that even for version 1.308 of cdrecord.c, I am forced to do - * things like this, but defective versions of cdrecord cause a lot of - * work load to me and it seems to be impossible to otherwise convince - * SuSE to cooperate. - * As people contact me and bother me with the related problems, - * it is obvious that SuSE is violating subsection 6 in the preamble of - * the GPL. - * - * The reason for including a test against SuSE's private - * distribution environment is only that SuSE violates the GPL for - * a long time and seems not to be willing to follow the requirements - * imposed by the GPL. If SuSE starts to ship non defective versions - * of cdrecord or informs their customers that they would need to - * compile cdrecord themselves in order to get a working cdrecord, - * they should contact me for a permission to change the related test. - * - * Note that although the SuSE test is effective only for SuSE, the - * intention to have non bastardized versions out is not limited - * to SuSE. It is bad to see that in special in the "Linux" business, - * companies prefer a model with many proprietary differing programs - * instead of cooperating with the program authors. - */ - #if defined(linux) || defined(__linux) || defined(__linux__) - #ifdef HAVE_UNAME - #include <sys/utsname.h> - #endif - #endif - - LOCAL void - linuxcheck() /* For version 1.308 of cdrecord.c */ - { - #if defined(linux) || defined(__linux) || defined(__linux__) - #ifdef HAVE_UNAME - struct utsname un; - - if (uname(&un) >= 0) { - /* - * I really hope that the Linux kernel developers will soon - * fix the most annoying bugs (as promised). Linux-2.6.8 - * has still much more reported problems than Linux-2.4. - */ - if ((un.release[0] == '2' && un.release[1] == '.') && - (un.release[2] == '5' || un.release[2] == '6')) { - errmsgno(EX_BAD, - "Warning: Running on Linux-%s\n", un.release); - errmsgno(EX_BAD, - "There are unsettled issues with Linux-2.5 and newer.\n"); - errmsgno(EX_BAD, - "If you have unexpected problems, please try Linux-2.4 or Solaris.\n"); - } - if ((un.release[0] == '2' && un.release[1] == '.') && - (un.release[2] > '6' || - (un.release[2] == '6' && un.release[3] == '.' && un.release[4] >= '8'))) { - errmsgno(EX_BAD, - "Warning: Linux-2.6.8 introduced incompatible interface changes.\n"); - errmsgno(EX_BAD, - "Warning: SCSI transport does no longer work for suid root programs.\n"); - errmsgno(EX_BAD, - "Warning: if cdrecord fails, try to run it from a root account.\n"); - } - } - #endif - #if 0 - if (streql(HOST_VENDOR, "suse")) { /* For version 1.308 of cdrecord.c */ - /* 1.308 */ errmsgno(EX_BAD, - /* 1.308 */ "SuSE Linux is known to ship bastardized and defective versions of cdrecord.\n"); - /* 1.308 */ errmsgno(EX_BAD, - /* 1.308 */ "SuSE is unwilling to cooperate with the authors.\n"); - /* 1.308 */ errmsgno(EX_BAD, - /* 1.308 */ "If you like to have a working version of cdrtools, get the\n"); - /* 1.308 */ errmsgno(EX_BAD, - /* 1.308 */ "original source from ftp://ftp.berlios.de/pub/cdrecord/\n"); - - } - #endif - #endif - } --- 4676,4678 ---- *** ./mkisofs/write.c.orig Fri Feb 3 15:49:23 2006 --- ./mkisofs/write.c Fri Feb 3 15:49:25 2006 *************** *** 834,843 **** if (dcount < 2) { #ifdef USE_LIBSCHILY errmsgno(EX_BAD, ! "Directory size too small (. or .. missing ???)\n"); #else fprintf(stderr, ! "Directory size too small (. or .. missing ???)\n"); #endif sort_goof = 1; --- 834,843 ---- if (dcount < 2) { #ifdef USE_LIBSCHILY errmsgno(EX_BAD, ! "Directory size too small (. or .. missing ??\077)\n"); #else fprintf(stderr, ! "Directory size too small (. or .. missing ??\077)\n"); #endif sort_goof = 1; *** ./libscg/scsi-linux-sg.c.orig Fri Feb 3 15:44:39 2006 --- ./libscg/scsi-linux-sg.c Fri Feb 3 16:31:03 2006 *************** *** 120,126 **** * Choose your name instead of "schily" and make clear that the version * string is related to a modified source. */ ! LOCAL char _scg_trans_version[] = "scsi-linux-sg.c-1.86"; /* The version for this transport*/ #ifndef SCSI_IOCTL_GET_BUS_NUMBER #define SCSI_IOCTL_GET_BUS_NUMBER 0x5386 --- 120,126 ---- * Choose your name instead of "schily" and make clear that the version * string is related to a modified source. */ ! LOCAL char _scg_trans_version[] = "scsi-linux-sg.c-1.86+ma"; /* The version for this transport*/ #ifndef SCSI_IOCTL_GET_BUS_NUMBER #define SCSI_IOCTL_GET_BUS_NUMBER 0x5386 *************** *** 273,279 **** * return "schily" for the SCG_AUTHOR request. */ case SCG_AUTHOR: ! return (_scg_auth_schily); case SCG_SCCS_ID: return (__sccsid); case SCG_KVERSION: --- 273,279 ---- * return "schily" for the SCG_AUTHOR request. */ case SCG_AUTHOR: ! return (""); case SCG_SCCS_ID: return (__sccsid); case SCG_KVERSION: *************** *** 308,315 **** #ifdef USE_ATA scgo_ahelp(scgp, f); #endif - __scg_help(f, "ATA", "ATA Packet specific SCSI transport using sg interface", - "ATA:", "bus,target,lun", "1,2,0", TRUE, FALSE); return (0); } --- 308,313 ---- *************** *** 328,334 **** register int l; register int nopen = 0; char devname[64]; - BOOL use_ata = FALSE; if (busno >= MAX_SCG || tgt >= MAX_TGT || tlun >= MAX_LUN) { errno = EINVAL; --- 326,331 ---- *************** *** 338,381 **** busno, tgt, tlun); return (-1); } - if (device != NULL && *device != '\0') { #ifdef USE_ATA if (strncmp(device, "ATAPI", 5) == 0) { scgp->ops = &ata_ops; return (SCGO_OPEN(scgp, device)); } - #endif - if (strcmp(device, "ATA") == 0) { - /* - * Sending generic SCSI commands via /dev/hd* is a - * really bad idea when there also is a generic - * SCSI driver interface - it breaks the protocol - * layering model. A better idea would be to - * have a SCSI host bus adapter driver that sends - * the SCSI commands via the ATA hardware. This way, - * the layering model would be honored. - * - * People like Jens Axboe should finally fix the DMA - * bugs in the ide-scsi hostadaptor emulation module - * from Linux instead of publishing childish patches - * to the comment above. - */ - use_ata = TRUE; - device = NULL; - if (scgp->overbose) { - /* - * I strongly encourage people who believe that - * they need to patch this message away to read - * the messages in the Solaris USCSI libscg - * layer instead of wetting their tissues while - * being unwilling to look besides their - * own belly button. - */ - js_fprintf((FILE *)scgp->errfile, - "Warning: Using badly designed ATAPI via /dev/hd* interface.\n"); - } - } } if (scgp->local == NULL) { scgp->local = malloc(sizeof (struct scg_local)); --- 335,348 ---- busno, tgt, tlun); return (-1); } #ifdef USE_ATA + if (device != NULL && *device != '\0') { if (strncmp(device, "ATAPI", 5) == 0) { scgp->ops = &ata_ops; return (SCGO_OPEN(scgp, device)); } } + #endif if (scgp->local == NULL) { scgp->local = malloc(sizeof (struct scg_local)); *************** *** 389,396 **** scglocal(scgp)->drvers = -1; scglocal(scgp)->isold = -1; scglocal(scgp)->flags = 0; - if (use_ata) - scglocal(scgp)->flags |= LF_ATA; scglocal(scgp)->xbufsize = 0L; scglocal(scgp)->xbuf = NULL; --- 356,361 ---- *************** *** 403,415 **** } } - if (use_ata) - goto scanopen; - if ((device != NULL && *device != '\0') || (busno == -2 && tgt == -2)) goto openbydev; - scanopen: /* * Note that it makes no sense to scan less than all /dev/hd* devices * as even /dev/hda may be a device that talks SCSI (e.g. a ATAPI --- 368,376 ---- *************** *** 417,423 **** * look silly but there may be users that did boot from a SCSI hdd * and connected 4 CD/DVD writers to both IDE cables in the PC. */ ! if (use_ata) for (i = 0; i <= 25; i++) { js_snprintf(devname, sizeof (devname), "/dev/hd%c", i+'a'); /* O_NONBLOCK is dangerous */ f = open(devname, O_RDWR | O_NONBLOCK); --- 378,384 ---- * look silly but there may be users that did boot from a SCSI hdd * and connected 4 CD/DVD writers to both IDE cables in the PC. */ ! for (i = 0; i <= 25; i++) { js_snprintf(devname, sizeof (devname), "/dev/hd%c", i+'a'); /* O_NONBLOCK is dangerous */ f = open(devname, O_RDWR | O_NONBLOCK); *************** *** 433,439 **** if (scgp->errstr) js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE, "Cannot open '%s'", devname); ! return (0); } } else { int iparm; --- 394,400 ---- if (scgp->errstr) js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE, "Cannot open '%s'", devname); ! continue; } } else { int iparm; *************** *** 446,463 **** continue; } sg_clearnblock(f); /* Be very proper about this */ if (sg_setup(scgp, f, busno, tgt, tlun, i)) return (++nopen); if (busno < 0 && tgt < 0 && tlun < 0) nopen++; } } ! if (use_ata && nopen == 0) ! return (0); if (nopen > 0 && scgp->errstr) scgp->errstr[0] = '\0'; ! if (nopen == 0) for (i = 0; i < 32; i++) { js_snprintf(devname, sizeof (devname), "/dev/sg%d", i); /* O_NONBLOCK is dangerous */ f = open(devname, O_RDWR | O_NONBLOCK); --- 407,424 ---- continue; } sg_clearnblock(f); /* Be very proper about this */ + scglocal(scgp)->flags |= LF_ATA; if (sg_setup(scgp, f, busno, tgt, tlun, i)) return (++nopen); if (busno < 0 && tgt < 0 && tlun < 0) nopen++; } } ! if (nopen > 0 && scgp->errstr) scgp->errstr[0] = '\0'; ! for (i = 0; i < 32; i++) { js_snprintf(devname, sizeof (devname), "/dev/sg%d", i); /* O_NONBLOCK is dangerous */ f = open(devname, O_RDWR | O_NONBLOCK); *************** *** 473,479 **** if (scgp->errstr) js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE, "Cannot open '%s'", devname); ! return (0); } } else { sg_clearnblock(f); /* Be very proper about this */ --- 434,440 ---- if (scgp->errstr) js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE, "Cannot open '%s'", devname); ! continue; } } else { sg_clearnblock(f); /* Be very proper about this */ *************** *** 502,508 **** if (scgp->errstr) js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE, "Cannot open '%s'", devname); ! return (0); } } else { sg_clearnblock(f); /* Be very proper about this */ --- 463,469 ---- if (scgp->errstr) js_snprintf(scgp->errstr, SCSI_ERRSTR_SIZE, "Cannot open '%s'", devname); ! continue; } } else { sg_clearnblock(f); /* Be very proper about this */ *************** *** 523,541 **** if (b < 0 || b > 25) b = -1; } - if (scgp->overbose) { - /* - * Before you patch this away, are you sure that you - * know what you are going to to? - * - * Note that this is a warning that helps users from - * cdda2wav, mkisofs and other programs (that - * distinguish SCSI addresses from file names) from - * getting unexpected results. - */ - js_fprintf((FILE *)scgp->errfile, - "Warning: Open by 'devname' is unintentional and not supported.\n"); - } /* O_NONBLOCK is dangerous */ f = open(device, O_RDWR | O_NONBLOCK); /* if (f < 0 && errno == ENOENT)*/ --- 484,489 ---- *************** *** 634,645 **** } /* ! * The Linux kernel becomes more and more unmaintainable. ! * Every year, a new incompatible SCSI transport interface is added. ! * Each of them has it's own contradictory constraints. ! * While you cannot have O_NONBLOCK set during operation, at least one ! * of the drivers requires O_NONBLOCK to be set during open(). ! * This is used to clear O_NONBLOCK immediately after open() succeeded. */ LOCAL void sg_clearnblock(f) --- 582,588 ---- } /* ! * This is used to clear O_NONBLOCK immediately after open() succeeded. */ LOCAL void sg_clearnblock(f) -- Matthias Andree "Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher." A. de Saint-Exupéry ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 18:20 ` [cdrtools PATCH (GPL)] " Matthias Andree @ 2006-02-03 18:31 ` Joerg Schilling 2006-02-03 18:42 ` Jim Crilly 2006-02-03 19:14 ` Matthias Andree 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 18:31 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel, cdwrite, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > So patches to the rescue -- please review the patch below (for 2.01.01a05). > Note that GPL 2a and 2c apply, so you cannot merge a modified version of > my patch without adding a tag that you goofed my fixes. OK, I did not look at it and I never will! Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (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] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 18:31 ` Joerg Schilling @ 2006-02-03 18:42 ` Jim Crilly 2006-02-03 19:10 ` Joerg Schilling 2006-02-03 19:14 ` Matthias Andree 1 sibling, 1 reply; 717+ messages in thread From: Jim Crilly @ 2006-02-03 18:42 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, cdwrite, acahalan On 02/03/06 07:31:58PM +0100, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > So patches to the rescue -- please review the patch below (for 2.01.01a05). > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of > > my patch without adding a tag that you goofed my fixes. > > OK, I did not look at it and I never will! > > Jörg This is an excellent example to verify how bad cdrecord developent is done..... Jim. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 18:42 ` Jim Crilly @ 2006-02-03 19:10 ` Joerg Schilling 2006-02-03 19:18 ` Jim Crilly 2006-02-03 19:28 ` Matthias Andree 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 19:10 UTC (permalink / raw) To: schilling, jim; +Cc: matthias.andree, linux-kernel, cdwrite, acahalan "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > On 02/03/06 07:31:58PM +0100, Joerg Schilling wrote: > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > So patches to the rescue -- please review the patch below (for 2.01.01a05). > > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of > > > my patch without adding a tag that you goofed my fixes. > > > > OK, I did not look at it and I never will! > > > > Jörg > > This is an excellent example to verify how bad cdrecord developent > is done..... Well, cdrecord is done as good as possible. Note that if peope send a patch together with personal infringements or untrue claims, the best I can do is to ignore alltogether. I did spend a lot of time with a fruitful discussion with Matthias. Then Matthias started this thread.... It now seems like Matthias does not like to be serious anymore. I am of course interested to make cdrecord better, but for the price of spending an ridiculously amount of time ob 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] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 19:10 ` Joerg Schilling @ 2006-02-03 19:18 ` Jim Crilly 2006-02-03 19:28 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Jim Crilly @ 2006-02-03 19:18 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, cdwrite, acahalan On 02/03/06 08:10:13PM +0100, Joerg Schilling wrote: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > On 02/03/06 07:31:58PM +0100, Joerg Schilling wrote: > > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > > > So patches to the rescue -- please review the patch below (for 2.01.01a05). > > > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of > > > > my patch without adding a tag that you goofed my fixes. > > > > > > OK, I did not look at it and I never will! > > > > > > Jörg > > > > This is an excellent example to verify how bad cdrecord developent > > is done..... > > Well, > > cdrecord is done as good as possible. The fact that you seem to sling mud at everyone that doesn't agree with you makes that seem questionable. > Note that if peope send a patch together with personal infringements or > untrue claims, the best I can do is to ignore alltogether. > > I did spend a lot of time with a fruitful discussion with Matthias. > Then Matthias started this thread.... It now seems like Matthias > does not like to be serious anymore. It's hard to have a serious discussion with you because you just keep parotting the same things and pointing fingers over and over. > I am of course interested to make cdrecord better, but for the price > of spending an ridiculously amount of time ob LKML. > > Jörg > And you never did answer my question about why cdrecord is the only app on any OS to use devicename:scsibus,target,lun to specify the target device. Every other tool out there, e.g. mount, fsck, tar, etc, all use the device name exported by the OS, e.g. /dev/c0t0s0d0, /dev/hda1, /dev/nst0, etc, so why is it necessary for cdrecord to be different? Jim. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 19:10 ` Joerg Schilling 2006-02-03 19:18 ` Jim Crilly @ 2006-02-03 19:28 ` Matthias Andree 2006-02-08 22:13 ` Pavel Machek 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-03 19:28 UTC (permalink / raw) To: Joerg Schilling; +Cc: jim, matthias.andree, linux-kernel, cdwrite, acahalan Joerg Schilling schrieb am 2006-02-03: > "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > > > On 02/03/06 07:31:58PM +0100, Joerg Schilling wrote: > > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > > > So patches to the rescue -- please review the patch below (for 2.01.01a05). > > > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of > > > > my patch without adding a tag that you goofed my fixes. > > > > > > OK, I did not look at it and I never will! > > > > > > Jörg > > > > This is an excellent example to verify how bad cdrecord developent > > is done..... > > Well, > > cdrecord is done as good as possible. Untrue. Proof: My patch makes it operate more smoothly on Linux. > Note that if peope send a patch together with personal infringements or > untrue claims, the best I can do is to ignore alltogether. Look who's talking, and what. Personal infringements? If you're sensitive, my apologies, I didn't mean to insult you. > I did spend a lot of time with a fruitful discussion with Matthias. > Then Matthias started this thread.... It now seems like Matthias > does not like to be serious anymore. I am absolutely serious about the patch and about my recent findings after looking at libscg. I just don't want my name tainted with accidents that happen during integration because you don't have a recent Linux installation. The RLIMIT_MEMLOCK was enough of an effort, my first patch would've worked, too, hence the GPL. > I am of course interested to make cdrecord better, but for the price > of spending an ridiculously amount of time ob LKML. Well, if you'd listened and attempted to understand our scanning concerns, you'd probably have had libscg use a unified ATA:/SCSI: namespace in Linux for 1½ years. OK, spilled milk. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 19:28 ` Matthias Andree @ 2006-02-08 22:13 ` Pavel Machek 2006-02-09 20:10 ` jerome lacoste 2006-02-09 22:38 ` Matthias Andree 0 siblings, 2 replies; 717+ messages in thread From: Pavel Machek @ 2006-02-08 22:13 UTC (permalink / raw) To: Joerg Schilling, jim, linux-kernel, cdwrite, acahalan Hi! > > > > > So patches to the rescue -- please review the patch below (for 2.01.01a05). > > > > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of > > > > > my patch without adding a tag that you goofed my fixes. > > > > > > > > OK, I did not look at it and I never will! > > > > > > > > Jörg > > > > > > This is an excellent example to verify how bad cdrecord developent > > > is done..... > > > > Well, > > > > cdrecord is done as good as possible. > > Untrue. Proof: My patch makes it operate more smoothly on Linux. ... > I just don't want my name tainted with accidents that happen during > integration because you don't have a recent Linux installation. The > RLIMIT_MEMLOCK was enough of an effort, my first patch would've worked, > too, hence the GPL. Well, mailing patch with notice that it is not okay to modify it is strange behaviour, and if I was Joerg, I'd just drop that patch, too. If you really want the patch applied, submit it anonymously or something like that. Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 22:13 ` Pavel Machek @ 2006-02-09 20:10 ` jerome lacoste 2006-02-09 22:38 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: jerome lacoste @ 2006-02-09 20:10 UTC (permalink / raw) To: Pavel Machek; +Cc: Joerg Schilling, jim, linux-kernel, cdwrite, acahalan On 2/8/06, Pavel Machek <pavel@ucw.cz> wrote: [...] > > I just don't want my name tainted with accidents that happen during > > integration because you don't have a recent Linux installation. The > > RLIMIT_MEMLOCK was enough of an effort, my first patch would've worked, > > too, hence the GPL. > > Well, mailing patch with notice that it is not okay to modify it is > strange behaviour, and if I was Joerg, I'd just drop that patch, too. That would be true except if Joerg hadn't started with the exact same behavior. It would seem that Joerg would be capable of understanding the irony there. But maybe if Joerg would move his pride out of the way for 30 seconds, have a decent look at the patch, return a technical commentary (or point to an existing one), we could move on. I am sure that Matthias would be pretty happy to return a better patch. That would make everybody happy. Matthias, can you resend the patch, without your notice? Let's see if Joerg look at it this time. > If you really want the patch applied, submit it anonymously or > something like that. Anonymous submission is not good for tracability reasons... Jerome ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-08 22:13 ` Pavel Machek 2006-02-09 20:10 ` jerome lacoste @ 2006-02-09 22:38 ` Matthias Andree 2006-02-10 12:11 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-09 22:38 UTC (permalink / raw) To: Pavel Machek; +Cc: Joerg Schilling, jim, linux-kernel, cdwrite, acahalan On Wed, 08 Feb 2006, Pavel Machek wrote: > > I just don't want my name tainted with accidents that happen during > > integration because you don't have a recent Linux installation. The > > RLIMIT_MEMLOCK was enough of an effort, my first patch would've worked, > > too, hence the GPL. > > Well, mailing patch with notice that it is not okay to modify it is > strange behaviour, and if I was Joerg, I'd just drop that patch, too. You have apparently missed that I offered to relicense the patch under MIT license (which is liberal, allows modifications and everything) after I'd confirmed the integration went OK; and I was just returning the buck of being forced to change interface identifications all over the map from "mustn't modify" sections. The first step would be to look at the patch nonetheless, because it conveys information that Jörg has not extracted from messages since the first time SG_IO in ide-cd cropped up. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 22:38 ` Matthias Andree @ 2006-02-10 12:11 ` Joerg Schilling 2006-02-10 12:24 ` jerome lacoste 2006-02-10 22:20 ` Matthias Andree 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-10 12:11 UTC (permalink / raw) To: pavel, matthias.andree; +Cc: schilling, linux-kernel, jim, cdwrite, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > You have apparently missed that I offered to relicense the patch under > MIT license (which is liberal, allows modifications and everything) It seems that you still miss the point that you don't have the right to require a license for your patch (check the UrhG for more information). And please finally note that you did already cause a mail thread that did cost more time than your patch is worth. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (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] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:11 ` Joerg Schilling @ 2006-02-10 12:24 ` jerome lacoste 2006-02-10 22:20 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: jerome lacoste @ 2006-02-10 12:24 UTC (permalink / raw) To: Joerg Schilling Cc: pavel, matthias.andree, linux-kernel, jim, cdwrite, acahalan On 2/10/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: [...] > And please finally note that you did already cause a mail thread that > did cost more time than your patch is worth. How can you know that if you didn't look at it? J ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 12:11 ` Joerg Schilling 2006-02-10 12:24 ` jerome lacoste @ 2006-02-10 22:20 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-10 22:20 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-10: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > You have apparently missed that I offered to relicense the patch under > > MIT license (which is liberal, allows modifications and everything) > > It seems that you still miss the point that you don't have the right > to require a license for your patch (check the UrhG for more information). Why do care then? > And please finally note that you did already cause a mail thread that > did cost more time than your patch is worth. Nobody forces you to answer every side note someone makes, and nobody ask you to reiterate identical replies over and over. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 18:31 ` Joerg Schilling 2006-02-03 18:42 ` Jim Crilly @ 2006-02-03 19:14 ` Matthias Andree 2006-02-03 20:08 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-03 19:14 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel, cdwrite, acahalan Joerg Schilling schrieb am 2006-02-03: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > So patches to the rescue -- please review the patch below (for 2.01.01a05). > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of > > my patch without adding a tag that you goofed my fixes. > > OK, I did not look at it and I never will! Perhaps you should -- the patch impairs your changes to get needless device enumeration changes into the kernel... Enforcing your strict interpretation of GPL v2 §§ 2a, 2c to the letter was your own idea. I had to touch "modification prohibited" sections to remove obsolete (bogus) warnings. I'll amend the license: Show me your integrated patch. If it works properly on my computer and without false warnings, you add a note to the changelog and the AN-2.01.01a06 file, I will demote the patch's license to the MIT license as in <http://opensource.org/licenses/mit-license.php>. Yes, this is a license contract offer as per the BGB. Just write you're accepting it, or accept implicitly by sending the integration patch against 2.01.01a05. I just want to make sure that it doesn't bear my name if the integration breaks it again. The code can probably be simplified even more with readdir() on /dev and filtering it (avoiding glob() buffer issues), my patch doesn't even attempt to do that. And if you explain the use of LF_ATA, the kernel drivers might even be fixes so that /dev/hd* looks confusably similar to /dev/sg*. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 19:14 ` Matthias Andree @ 2006-02-03 20:08 ` Joerg Schilling 2006-02-03 21:17 ` Matthias Andree 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 20:08 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel, cdwrite, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-03: > > > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > So patches to the rescue -- please review the patch below (for 2.01.01a05). > > > Note that GPL 2a and 2c apply, so you cannot merge a modified version of > > > my patch without adding a tag that you goofed my fixes. > > > > OK, I did not look at it and I never will! > > Perhaps you should -- the patch impairs your changes to get > needless device enumeration changes into the kernel... Well, the problem with your last mail is that it is full of idioligy. I am of course willing to discuss useful ideas, but believe me that you will have no luck if you leave a technical based discussion. > I'll amend the license: Show me your integrated patch. If it works > properly on my computer and without false warnings, you add a note to > the changelog and the AN-2.01.01a06 file, I will demote the patch's > license to the MIT license as in See: http://bundesrecht.juris.de/urhg/ I hope this helps you to understand things better.Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (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] 717+ messages in thread
* Re: [cdrtools PATCH (GPL)] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 20:08 ` Joerg Schilling @ 2006-02-03 21:17 ` Matthias Andree 0 siblings, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-03 21:17 UTC (permalink / raw) To: Joerg Schilling, Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-03: > Well, the problem with your last mail is that it is full of idioligy. It is not my patch's or the discussion's fault if you cannot accept the same rules as you are trying to impose on others. > I am of course willing to discuss useful ideas, but believe me that you > will have no luck if you leave a technical based discussion. Then have a look at the patch, we'll discuss the license later. My offer to relicense under MIT license if the integration works out for me stands. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:09 ` Jim Crilly 2006-02-02 21:20 ` Joerg Schilling @ 2006-02-02 21:25 ` Lee Revell 2006-02-02 21:49 ` Jim Crilly 2006-02-03 13:29 ` Joerg Schilling 2006-02-03 13:25 ` Joerg Schilling 2 siblings, 2 replies; 717+ messages in thread From: Lee Revell @ 2006-02-02 21:25 UTC (permalink / raw) To: Jim Crilly Cc: Jan Engelhardt, Albert Cahalan, Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote: > Apparently O_EXCL was added by Ubuntu and Debian to stop > burns being corrupted by hald polling the device while a disc is > being burned. IO priorities are the correct solution... Lee ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:25 ` Lee Revell @ 2006-02-02 21:49 ` Jim Crilly 2006-02-02 21:54 ` Lee Revell 2006-02-02 21:56 ` Lee Revell 2006-02-03 13:29 ` Joerg Schilling 1 sibling, 2 replies; 717+ messages in thread From: Jim Crilly @ 2006-02-02 21:49 UTC (permalink / raw) To: Lee Revell Cc: Jan Engelhardt, Albert Cahalan, Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j On 02/02/06 04:25:50PM -0500, Lee Revell wrote: > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote: > > Apparently O_EXCL was added by Ubuntu and Debian to stop > > burns being corrupted by hald polling the device while a disc is > > being burned. > > IO priorities are the correct solution... > > Lee Is this something that's available now? Jim. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:49 ` Jim Crilly @ 2006-02-02 21:54 ` Lee Revell 2006-02-02 21:56 ` Lee Revell 1 sibling, 0 replies; 717+ messages in thread From: Lee Revell @ 2006-02-02 21:54 UTC (permalink / raw) To: Jim Crilly Cc: Jan Engelhardt, Albert Cahalan, Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j On Thu, 2006-02-02 at 16:49 -0500, Jim Crilly wrote: > On 02/02/06 04:25:50PM -0500, Lee Revell wrote: > > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote: > > > Apparently O_EXCL was added by Ubuntu and Debian to stop > > > burns being corrupted by hald polling the device while a disc is > > > being burned. > > > > IO priorities are the correct solution... > > > > Lee > > Is this something that's available now? > Yes but only in the CFQ IO scheduler, and a pre-release util-linux is required to get the docs and command line utils. Lee ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:49 ` Jim Crilly 2006-02-02 21:54 ` Lee Revell @ 2006-02-02 21:56 ` Lee Revell 2006-02-03 8:54 ` Jens Axboe 1 sibling, 1 reply; 717+ messages in thread From: Lee Revell @ 2006-02-02 21:56 UTC (permalink / raw) To: Jim Crilly Cc: Jan Engelhardt, Albert Cahalan, Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j On Thu, 2006-02-02 at 16:49 -0500, Jim Crilly wrote: > On 02/02/06 04:25:50PM -0500, Lee Revell wrote: > > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote: > > > Apparently O_EXCL was added by Ubuntu and Debian to stop > > > burns being corrupted by hald polling the device while a disc is > > > being burned. > > > > IO priorities are the correct solution... > > > > Lee > > Is this something that's available now? > Hmm, actually I'm not sure it would make a difference, as I don't think CD writing goes through the regular IO scheduler. Lee ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:56 ` Lee Revell @ 2006-02-03 8:54 ` Jens Axboe 0 siblings, 0 replies; 717+ messages in thread From: Jens Axboe @ 2006-02-03 8:54 UTC (permalink / raw) To: Lee Revell Cc: Jim Crilly, Jan Engelhardt, Albert Cahalan, Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j On Thu, Feb 02 2006, Lee Revell wrote: > On Thu, 2006-02-02 at 16:49 -0500, Jim Crilly wrote: > > On 02/02/06 04:25:50PM -0500, Lee Revell wrote: > > > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote: > > > > Apparently O_EXCL was added by Ubuntu and Debian to stop > > > > burns being corrupted by hald polling the device while a disc is > > > > being burned. > > > > > > IO priorities are the correct solution... > > > > > > Lee > > > > Is this something that's available now? > > > > Hmm, actually I'm not sure it would make a difference, as I don't think > CD writing goes through the regular IO scheduler. Right, you can only prioritize "regular" io, not stuff sent with SG_IO. So it'll help burning only for the case of getting the data required to the buffer, not in getting that data out to the burner. The latter is usually not a problem though, as these requests take a 'short cut' directly to the dispatch queue. -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:25 ` Lee Revell 2006-02-02 21:49 ` Jim Crilly @ 2006-02-03 13:29 ` Joerg Schilling 2006-02-03 13:51 ` Jan Engelhardt 1 sibling, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 13:29 UTC (permalink / raw) To: rlrevell, jim Cc: schilling, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, j, acahalan Lee Revell <rlrevell@joe-job.com> wrote: > On Thu, 2006-02-02 at 16:09 -0500, Jim Crilly wrote: > > Apparently O_EXCL was added by Ubuntu and Debian to stop > > burns being corrupted by hald polling the device while a disc is > > being burned. > > IO priorities are the correct solution... No, they are not. The correct solution is to implement "hald" in a _cooperative_ way like e.g. vold on Solaris. The main point is not to poll to frequent (Solaris does once everz 3 seconds) and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 13:29 ` Joerg Schilling @ 2006-02-03 13:51 ` Jan Engelhardt 2006-02-03 14:05 ` Kay Sievers 2006-02-03 16:47 ` Joerg Schilling 0 siblings, 2 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-03 13:51 UTC (permalink / raw) To: Joerg Schilling Cc: rlrevell, jim, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan > >The main point is not to poll to frequent (Solaris does once everz 3 seconds) >and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing. > I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although hal [seems to] probes more often than once/3sec, it did not interrupt any of my cd writing processes. Maybe that's already a feature of cdrecord*, I don't know. (With an older drive (AOpen CRW1232), the whole IDE bus was even blocked when blanking, leaving no option but to wait.) Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 13:51 ` Jan Engelhardt @ 2006-02-03 14:05 ` Kay Sievers 2006-02-03 16:48 ` Joerg Schilling 2006-02-03 16:47 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Kay Sievers @ 2006-02-03 14:05 UTC (permalink / raw) To: Jan Engelhardt Cc: Joerg Schilling, rlrevell, jim, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan On Fri, Feb 03, 2006 at 02:51:10PM +0100, Jan Engelhardt wrote: > > > >The main point is not to poll to frequent (Solaris does once everz 3 seconds) > >and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing. > > > > I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although > hal [seems to] probes more often than once/3sec, It polls every 2 seconds. > it did not interrupt any > of my cd writing processes. Maybe that's already a feature of cdrecord*, I > don't know. I don't know of any problem in that area and almost every modern Linux desktop has HAL running these days, so I'm sure somebody would have complained. Kay ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 14:05 ` Kay Sievers @ 2006-02-03 16:48 ` Joerg Schilling 0 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 16:48 UTC (permalink / raw) To: kay.sievers, jengelh Cc: schilling, rlrevell, mrmacman_g4, matthias.andree, linux-kernel, jim, James, j, acahalan Kay Sievers <kay.sievers@vrfy.org> wrote: > On Fri, Feb 03, 2006 at 02:51:10PM +0100, Jan Engelhardt wrote: > > > > > >The main point is not to poll to frequent (Solaris does once everz 3 seconds) > > >and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing. > > > > > > > I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although > > hal [seems to] probes more often than once/3sec, > > It polls every 2 seconds. What SCSI commands does it use? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 13:51 ` Jan Engelhardt 2006-02-03 14:05 ` Kay Sievers @ 2006-02-03 16:47 ` Joerg Schilling 1 sibling, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 16:47 UTC (permalink / raw) To: schilling, jengelh Cc: rlrevell, mrmacman_g4, matthias.andree, linux-kernel, jim, James, j, acahalan Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > >The main point is not to poll to frequent (Solaris does once everz 3 seconds) > >and to use SCSI commands only that to not interrupt or disturb CD/DVD-writing. > > > > I do not have any problems with resmgr/hal ATM (SUSE Linux 10.0). Although > hal [seems to] probes more often than once/3sec, it did not interrupt any > of my cd writing processes. Maybe that's already a feature of cdrecord*, I > don't know. > (With an older drive (AOpen CRW1232), the whole IDE bus was even > blocked when blanking, leaving no option but to wait.) If you like to investigate on this, you would need to e.g. use cdrecord to write a DVD on a Pioneer DVD writer of check a notebook with only one ATA cable for both HDD and DVD-writer. The fact that it does work for you does not prove that there is no problem. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 21:09 ` Jim Crilly 2006-02-02 21:20 ` Joerg Schilling 2006-02-02 21:25 ` Lee Revell @ 2006-02-03 13:25 ` Joerg Schilling 2 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 13:25 UTC (permalink / raw) To: jim, jengelh Cc: schilling, mrmacman_g4, matthias.andree, linux-kernel, James, j, acahalan "Jim Crilly" <jim@why.dont.jablowme.net> wrote: > I see the same thing with, the only external kernel patch I have > applied is Suspend2. The ATA scanbus code tries to > open("/dev/hda", O_RDWR|O_NONBLOCK|O_EXCL) and that fails, and since > the scanning code stops once one device fails to open the whole scan > aborts. Apparently O_EXCL was added by Ubuntu and Debian to stop > burns being corrupted by hald polling the device while a disc is > being burned. If you want to read the entire thread it's bug #262678 > in Debian. This is an excellent example to verify how bad Linux distribution developent is done..... Note that the main problem here is an applicaion unfriendly service on Linux that disturbes other applications like cdrecord. As there is a bug in this service, I would expect that this bug should be fixed. Instead of doing this or at least trying to get help from experienced people like me, some people did prefer to change cdrecord in a way that caused more problems than it pretends to fix. Note that the "requirement" for O_EXCL is a bad idea and needs fixing. If you believe that this is impossible, just have a look at the OpenSolaris vold and volfs subsystem..... Note that Linux distributors apply other changes to cdrecord that causes problems in the same area: patching cdrecord to allow a grace time < 3 seconds of course disallows a useful solution in this area. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* [OT] Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 12:32 ` Juerg Billeter 2006-01-31 13:37 ` Joerg Schilling @ 2006-02-01 15:39 ` Jan Engelhardt 1 sibling, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-01 15:39 UTC (permalink / raw) To: Juerg Billeter Cc: Joerg Schilling, mrmacman_g4, matthias.andree, linux-kernel, James, acahalan >> Users like to be able to get a list of posible targets for a single protocol. >> Nobody would ever think about trying to prevent people from getting a unified >> view on the list possible hosts that talk TCP/IP. What cdrecord does with >> -scanbus is nothing really different. > >Well, please show me how to get the list of all possible hosts that talk >TCP/IP and are directly or indirectly connected to my computer. As my >computer is attached to the internet, the list would get pretty long... >And even if only considering hosts in the local network, how do you get >a unified view of all TCP/IP hosts conected to any of my two network >adapters? > For direct connections (0 hop inbetween), spew pings around the local network, look into the ARP table and try to TCP-connect to everyone listed. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 10:30 ` Joerg Schilling ` (3 preceding siblings ...) 2006-01-31 12:32 ` Juerg Billeter @ 2006-01-31 16:43 ` Paul Jakma 2006-02-01 5:07 ` Albert Cahalan 4 siblings, 1 reply; 717+ messages in thread From: Paul Jakma @ 2006-01-31 16:43 UTC (permalink / raw) To: Joerg Schilling Cc: j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James, acahalan On Tue, 31 Jan 2006, Joerg Schilling wrote: > What Linux does is to artificially prevent this view to been seen > from outside the Linux kernel, or to avoid integrating a particular > device into a unique SCSI driver system although it would be > apropriate. So let's get this straight: Linux is artificially limiting userspace from viewing devices in terms of parallel SCSI address (B/T/L) because it does not create such B/T/L addresses, ones which would hence be *artificial* themselves, for non-parallel-SCSI devices? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: zeal, n.: Quality seen in new graduates -- if you're quick. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 16:43 ` Paul Jakma @ 2006-02-01 5:07 ` Albert Cahalan 2006-02-01 21:45 ` Paul Jakma 0 siblings, 1 reply; 717+ messages in thread From: Albert Cahalan @ 2006-02-01 5:07 UTC (permalink / raw) To: paul Cc: Joerg Schilling, j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James On 1/31/06, Paul Jakma <paul@clubi.ie> wrote: > On Tue, 31 Jan 2006, Joerg Schilling wrote: > > > What Linux does is to artificially prevent this view to been seen > > from outside the Linux kernel, or to avoid integrating a particular > > device into a unique SCSI driver system although it would be > > apropriate. > > So let's get this straight: Linux is artificially limiting userspace > from viewing devices in terms of parallel SCSI address (B/T/L) > because it does not create such B/T/L addresses, ones which would > hence be *artificial* themselves, for non-parallel-SCSI devices? There is a slim chance that Joerg might really believe that Linux has an internal B/T/L view of everything. That would be odd to us of course. He has clearly been spending time with the Solaris kernel. If his only kernel experience comes from systems that do make up a phony B/T/L view, then he might just assume that all operating systems are designed this way. For Joerg's reference, open() goes like this: 1. the /dev name 2. the inode 3. the device number 4. pointers to structs full of function pointers Nowhere is it in B/T/L form. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-01 5:07 ` Albert Cahalan @ 2006-02-01 21:45 ` Paul Jakma 0 siblings, 0 replies; 717+ messages in thread From: Paul Jakma @ 2006-02-01 21:45 UTC (permalink / raw) To: Albert Cahalan Cc: Joerg Schilling, j, mrmacman_g4, matthias.andree, linux-kernel, jengelh, James On Wed, 1 Feb 2006, Albert Cahalan wrote: > For Joerg's reference, open() goes like this: > > 1. the /dev name > 2. the inode > 3. the device number > 4. pointers to structs full of function pointers > > Nowhere is it in B/T/L form. And, for whatever it's worth, TTBOMK Solaris does not arrange SCSI into a B/T/L address hierarchy internally either. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Mystics always hope that science will some day overtake them. -- Booth Tarkington ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 11:43 ` Joerg Schilling 2006-01-30 12:04 ` Matthias Andree 2006-01-30 17:38 ` Jürg Billeter @ 2006-01-30 21:02 ` Bill Davidsen 2 siblings, 0 replies; 717+ messages in thread From: Bill Davidsen @ 2006-01-30 21:02 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, acahalan, unlisted-recipients:; > Cdrecord is a program that needs to be able to send any SCSI command as > it needs to be able to add new vendor unique commands for new drive/feature > support. On this we do agree, drive vendors seem to add every new feature with a vendor code. Some are NOT required to write CD, but some are needed to write "better" CDs, for some definition of better which could mean faster, more reliable, special modes, etc. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 16:44 ` James Courtier-Dutton 2006-01-27 17:01 ` Jan Engelhardt @ 2006-01-30 11:25 ` Joerg Schilling 1 sibling, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-30 11:25 UTC (permalink / raw) To: schilling, James Cc: mrmacman_g4, matthias.andree, linux-kernel, acahalan, unlisted-recipients:; James Courtier-Dutton <James@superbug.co.uk> wrote: > Would you be able to add the appropriate kernel bugzilla numbers? As before people from LKML did not like to even talk about these bugs, I did stop after sending bug reports to LKML. > I think it might also be useful to make a list of all the SCSI commands > that cdrecord uses. Including all the vendor specific ones. One could > then verify that the Linux kernel is passing them onto the device correctly. It is simple to find the SCSI commands that cdrecord by scanning the source (*), but this is something that is subject to frequent change in case cdrecord needs to add new MMC-4711 commands or in case that I need to add a new vendor unique command in order to support special features. *) Just grep for "cdb.cmd" Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 16:31 ` Joerg Schilling 2006-01-25 16:56 ` Kyle Moffett @ 2006-01-26 2:26 ` Albert Cahalan 2006-01-26 8:19 ` Matthias Andree 2006-01-26 13:50 ` Joerg Schilling 1 sibling, 2 replies; 717+ messages in thread From: Albert Cahalan @ 2006-01-26 2:26 UTC (permalink / raw) To: Joerg Schilling; +Cc: rlrevell, matthias.andree, linux-kernel On 1/25/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Albert Cahalan <acahalan@gmail.com> wrote: > > BTW, before Joerg mentions portability, I'd like to remind > > everyone that all modern OSes support the use of normal device > > names for SCSI. The most awkward is FreeBSD, where you have > > to do a syscall or two to translate the name to Joerg's very > > non-hotplug non-iSCSI way of thinking. Windows, MacOS X, and > > even Solaris all manage to handle device names just fine. In > > numerous cases, not just Linux, cdrecord is inventing crap out > > of thin air to satisfy a pre-hotplug worldview. > > Looks like you are badly informed, so I encourage you to get yourself informed > properly before sending your next postig.... > > libscg includes 22 different SCSI low level transport implementations. > > - Only 5 of them allow a /dev/hd* device name related access. > > - 11 of them use file descriptors as handles for sending SCSI > commands but do not have a name <-> fs relation and thus > _need_ a SCSI device naming scheme as libscg offers. > This is because there is no 1:1 relation between SCSI addressing > and a fd retrieved from a /dev/* entry. > > - 6 of them not even allow to get a file descriptors as handles for > sending SCSI commands. These platforms of course need the SCSI device > naming scheme as libscg offers. > > Conclusion: > > 17 Platforms _need_ the addressing scheme libscg offers > > 5 Platforms _may_ use a different access method too. > > NOTE: Amongst the 6 plaforms that do not allow to even get a file descriptor > there is a modern OS like MacOS X You can't fool me, because I looked at the cdrecord source code and at the documented APIs for various OSes. It's misleading to say that MacOS doesn't allow a file descriptor. MacOS has something similar to what Linux has, but not in the normal filesystem namespace. You specify a name to get a handle. Of course, on MacOS, Joerg also uses -scanbus to create nonsense. Names can be handled by Windows, FreeBSD, MacOS X, Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX. That's everything that isn't end-of-lifed. The rest of your 22 platforms are dead and dying things that are unlikely to be upgrading to the latest software or hardware, assuming they survived the Y2K bug. It's old stuff like the Amiga, the NeXT, etc. Using numbers for CD burners is like trying to send email to the IP address of the recipient, which half-way worked until DHCP was invented. Wait, we could have all email clients offer a -scannet option. :-) ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 2:26 ` Albert Cahalan @ 2006-01-26 8:19 ` Matthias Andree 2006-01-26 13:53 ` Joerg Schilling 2006-01-26 13:50 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-01-26 8:19 UTC (permalink / raw) To: Albert Cahalan; +Cc: Joerg Schilling, matthias.andree, linux-kernel On Wed, 25 Jan 2006, Albert Cahalan wrote: > It's misleading to say that MacOS doesn't allow a file > descriptor. MacOS has something similar to what Linux > has, but not in the normal filesystem namespace. You > specify a name to get a handle. Of course, on MacOS, > Joerg also uses -scanbus to create nonsense. OK, so Jörg created this "nonsense", i. e. a triple of stupid numbers, and claims he's using them to provide device lists to applications. What prevents any of these GUIs from treating the "name" as an opaque string? How would ATA:4,0,0 be different from 2,2,0 or /dev/hdc? And how is the phantom GUI application obtaining the data? It needs to scan all buses anyhow, and run -scanbus for each and every "transport identifier" to get a grip of all devices, because cdrecord-with-libscg is too stupid to do that by itself and unlist inferior (in its view, or in the public view) identifiers (such as the PIO-only ATAPI:). Here's an idea: recognizing cdrecord may be portable, I wonder if it (or libscg for that matter) is extensible or made decisions where it can decouple its devices from the GUI application. Stating that the device ID no matter how it looks today would be an opaque string not to be processed by the GUI might be a first step to gain the necessary degrees of freedom to change to ATA:/dev/hdc or just /dev/hdc (I don't mind which). > Using numbers for CD burners is like trying to send email > to the IP address of the recipient, which half-way worked > until DHCP was invented. Wait, we could have all email > clients offer a -scannet option. :-) Well, in PeeCees, the BIOS presents that list of primary/secondary master/slave, so there's /some/ point in it. Once hotplug comes into play, it's all vain though. (removing Lee from the Cc: list) -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 8:19 ` Matthias Andree @ 2006-01-26 13:53 ` Joerg Schilling 0 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 13:53 UTC (permalink / raw) To: matthias.andree, acahalan; +Cc: schilling, matthias.andree, linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > On Wed, 25 Jan 2006, Albert Cahalan wrote: > > > It's misleading to say that MacOS doesn't allow a file > > descriptor. MacOS has something similar to what Linux > > has, but not in the normal filesystem namespace. You > > specify a name to get a handle. Of course, on MacOS, > > Joerg also uses -scanbus to create nonsense. > > OK, so Jörg created this "nonsense", i. e. a triple of stupid numbers, > and claims he's using them to provide device lists to applications. More than 2/3 of all current OS use this way of adressing and it is a standard: (CAM). > Well, in PeeCees, the BIOS presents that list of primary/secondary > master/slave, so there's /some/ point in it. Once hotplug comes into > play, it's all vain though. Hotplug is only a problem when implemented in a sub-optimal way. Please have a look at Solaris for hot plug support with stable interface names.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 2:26 ` Albert Cahalan 2006-01-26 8:19 ` Matthias Andree @ 2006-01-26 13:50 ` Joerg Schilling 2006-01-26 16:56 ` Matan Peled ` (2 more replies) 1 sibling, 3 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 13:50 UTC (permalink / raw) To: schilling, acahalan; +Cc: rlrevell, matthias.andree, linux-kernel Albert Cahalan <acahalan@gmail.com> wrote: > > Conclusion: > > > > 17 Platforms _need_ the addressing scheme libscg offers > > > > 5 Platforms _may_ use a different access method too. > > > > NOTE: Amongst the 6 plaforms that do not allow to even get a file descriptor > > there is a modern OS like MacOS X > > You can't fool me, because I looked at the cdrecord source > code and at the documented APIs for various OSes. I am sorry to see that you did not look close enough... > It's misleading to say that MacOS doesn't allow a file > descriptor. MacOS has something similar to what Linux > has, but not in the normal filesystem namespace. You > specify a name to get a handle. Of course, on MacOS, > Joerg also uses -scanbus to create nonsense. > > Names can be handled by Windows, FreeBSD, MacOS X, > Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX. > That's everything that isn't end-of-lifed. Aha, so you like to state that MS-WIN is end-of-lifed? Is this secret new information from Microsoft? Solaris is not on this list, because the only way to send SCSI commands to any kind of SCSI target is by using my /dev/scg driver. AIX is not on this list because the only way to send SCSI commands to any target is by using the /dev/gsc driver from Mathew Jacob who is a former Sun employee and who did get the idea for this driver from a talk with me during a visit at Sun in 1987. FreeBSD is not on the list as it uses CAM, similar to BeOS (Zeta), OSF1 (True 64) and QNX. IRIX is not on this list because it uses the same kind of interface as e.g. HP-UX does snprintf(devname, sizeof (devname), "/dev/scsi/sc%dd%dl%d", busno, tgt, tlun); Next try please.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 13:50 ` Joerg Schilling @ 2006-01-26 16:56 ` Matan Peled 2006-01-27 11:05 ` Joerg Schilling 2006-01-26 18:42 ` Jan Engelhardt 2006-01-27 0:19 ` Albert Cahalan 2 siblings, 1 reply; 717+ messages in thread From: Matan Peled @ 2006-01-26 16:56 UTC (permalink / raw) To: Joerg Schilling; +Cc: acahalan, rlrevell, matthias.andree, linux-kernel Joerg Schilling wrote: > Albert Cahalan <acahalan@gmail.com> wrote: >> Names can be handled by Windows, FreeBSD, MacOS X, >> Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX. >> That's everything that isn't end-of-lifed. > Aha, so you like to state that MS-WIN is end-of-lifed? > Is this secret new information from Microsoft? I'm not an expert in SCSI implementation quirks across varying platfroms, but you made a mistake here, Joerg. Albert put Windows (==MS-WIN) in that list. First one, even. -- [Name ] :: [Matan I. Peled ] [Location ] :: [Israel ] [Public Key] :: [0xD6F42CA5 ] [Keyserver ] :: [keyserver.kjsl.com] encrypted/signed plain text preferred ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 16:56 ` Matan Peled @ 2006-01-27 11:05 ` Joerg Schilling 0 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-27 11:05 UTC (permalink / raw) To: schilling, chaosite; +Cc: rlrevell, matthias.andree, linux-kernel, acahalan Matan Peled <chaosite@gmail.com> wrote: > Joerg Schilling wrote: > > Albert Cahalan <acahalan@gmail.com> wrote: > >> Names can be handled by Windows, FreeBSD, MacOS X, > >> Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX. > >> That's everything that isn't end-of-lifed. > > Aha, so you like to state that MS-WIN is end-of-lifed? > > Is this secret new information from Microsoft? > > I'm not an expert in SCSI implementation quirks across varying platfroms, but > you made a mistake here, Joerg. > > Albert put Windows (==MS-WIN) in that list. First one, even. I encourage you to inform yourself about MS-WIN and to find you that you are wrong. Under MS-WIN, you use either ASPI -> no open fd at all or you use something that is very similar to my /dev/scg* device on Solaris which uses/defines abstract SCSI transport devices instead of possibly unknown high level devices like a disk driver. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 13:50 ` Joerg Schilling 2006-01-26 16:56 ` Matan Peled @ 2006-01-26 18:42 ` Jan Engelhardt 2006-01-27 0:19 ` Albert Cahalan 2 siblings, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-01-26 18:42 UTC (permalink / raw) To: Joerg Schilling; +Cc: acahalan, rlrevell, matthias.andree, linux-kernel >IRIX is not on this list because it uses the same kind of interface as >e.g. HP-UX does > > snprintf(devname, sizeof (devname), > "/dev/scsi/sc%dd%dl%d", busno, tgt, tlun); So, would you want something like (free format string imagination) "/dev/sg-%d-%d-%d", busno, tgt, lun on Linux? Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 13:50 ` Joerg Schilling 2006-01-26 16:56 ` Matan Peled 2006-01-26 18:42 ` Jan Engelhardt @ 2006-01-27 0:19 ` Albert Cahalan 2006-01-27 0:40 ` Kyle Moffett ` (3 more replies) 2 siblings, 4 replies; 717+ messages in thread From: Albert Cahalan @ 2006-01-27 0:19 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel On 1/26/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Albert Cahalan <acahalan@gmail.com> wrote: > > You can't fool me, because I looked at the cdrecord source > > code and at the documented APIs for various OSes. > > I am sorry to see that you did not look close enough... ... > > Names can be handled by Windows, FreeBSD, MacOS X, > > Linux, OpenBSD, Solaris, HP-UX, AIX, and IRIX. > > That's everything that isn't end-of-lifed. OK, this is getting silly and downright offensive. I encourage everyone else to look over the code to see that I am right. I may just be crazy enough to fork this project. I very nearly did about 18 months ago. I can't very well do this alone, because I don't have all the hardware. (It's either cdrecord or Asterisk -- I'm not sure which one pisses me off the most) Me: * was an RTOS developer * day job is all about secure software * the procps maintainer * running Linux 2.6.xx only * using FireWire, which is totally hot-plug Perhaps the first thing to do would be to find a list of all the apps that depend on cdrecord. Their interface to cdrecord needs to be documented so that a compatibility script can be made. Matthias, can you give me a hand with this? I'll need a way to sort and publish incoming patches, letting them sit for a while. (like what Andrew Morton does for the kernel) This can't work like procps because the hardware varies too much. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 0:19 ` Albert Cahalan @ 2006-01-27 0:40 ` Kyle Moffett 2006-01-27 8:21 ` Xavier Bestel ` (2 subsequent siblings) 3 siblings, 0 replies; 717+ messages in thread From: Kyle Moffett @ 2006-01-27 0:40 UTC (permalink / raw) To: Albert Cahalan; +Cc: Joerg Schilling, matthias.andree, linux-kernel On Jan 26, 2006, at 19:19, Albert Cahalan wrote: > I may just be crazy enough to fork this project. I very nearly did > about 18 months ago. I can't very well do this alone, because I > don't have all the hardware I will gladly test your fork on my various hardware here. I have a desktop with Apple CD/RW+DVDROM and generic DVD+/-RW DL drive, and a laptop with Apple DVD+/-RW drive. Just send or post patches somewhere and I'll take a look. I suggest starting by looking at some of the various distro patches, IIRC some of them have already make significant cleanups. > Matthias, can you give me a hand with this? I'll need a way to sort > and publish incoming patches, letting them sit for a while. (like > what Andrew Morton does for the kernel) This can't work like procps > because the hardware varies too much. Might I suggest quilt or stgit? Both allow you to maintain an unstable and highly variable stack of patches based off a more stable branch, from which some patches percolate down into stable occasionally. Good luck with this! Cheers, Kyle Moffett -- Simple things should be simple and complex things should be possible -- Alan Kay ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 0:19 ` Albert Cahalan 2006-01-27 0:40 ` Kyle Moffett @ 2006-01-27 8:21 ` Xavier Bestel 2006-01-27 8:26 ` DervishD 2006-01-30 21:49 ` Bill Davidsen 3 siblings, 0 replies; 717+ messages in thread From: Xavier Bestel @ 2006-01-27 8:21 UTC (permalink / raw) To: Albert Cahalan; +Cc: Joerg Schilling, matthias.andree, linux-kernel On Fri, 2006-01-27 at 01:19, Albert Cahalan wrote: > I may just be crazy enough to fork this project. I very nearly > did about 18 months ago. I can't very well do this alone, > because I don't have all the hardware. Then contribute code to libburn: <http://icculus.org/burn/> Xav ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 0:19 ` Albert Cahalan 2006-01-27 0:40 ` Kyle Moffett 2006-01-27 8:21 ` Xavier Bestel @ 2006-01-27 8:26 ` DervishD 2006-01-30 21:49 ` Bill Davidsen 3 siblings, 0 replies; 717+ messages in thread From: DervishD @ 2006-01-27 8:26 UTC (permalink / raw) To: Albert Cahalan; +Cc: Joerg Schilling, matthias.andree, linux-kernel Hi Albert :) * Albert Cahalan <acahalan@gmail.com> dixit: > I may just be crazy enough to fork this project. I very nearly > did about 18 months ago. I can't very well do this alone, > because I don't have all the hardware. You can count on a Plextor Premium and a AOpen 1616ARR here. I also have another Plextor DVD708 but it no longer writes CDs :(( I will gladly test your fork here. And of course, you can count on any writer I can put my hands on. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 0:19 ` Albert Cahalan ` (2 preceding siblings ...) 2006-01-27 8:26 ` DervishD @ 2006-01-30 21:49 ` Bill Davidsen 2006-01-30 21:57 ` Matthias Andree 2006-01-30 22:12 ` Lee Revell 3 siblings, 2 replies; 717+ messages in thread From: Bill Davidsen @ 2006-01-30 21:49 UTC (permalink / raw) To: Albert Cahalan; +Cc: matthias.andree, linux-kernel Albert Cahalan wrote: > OK, this is getting silly and downright offensive. I encourage > everyone else to look over the code to see that I am right. > > I may just be crazy enough to fork this project. I very nearly > did about 18 months ago. I can't very well do this alone, > because I don't have all the hardware. (It's either cdrecord > or Asterisk -- I'm not sure which one pisses me off the most) I can test on various 2.6 kernel ATAPI CD and DVD burners, and on 2.4 kernel even a real SCSI CD burner as long as it lasts. I would love to see some mutual cooperation, but I doubt it's going to happen. Just to be clear, Joerg is not the only one I think has been a problem here, he pissed off some of the developers who don't seem overly eager to do things which would be helpful for any burner software. From here it looks like a pissing content, with users well within splash range. > > * was an RTOS developer > * day job is all about secure software > * the procps maintainer > * running Linux 2.6.xx only > * using FireWire, which is totally hot-plug > > Perhaps the first thing to do would be to find a list of all the > apps that depend on cdrecord. Their interface to cdrecord > needs to be documented so that a compatibility script can > be made. Do you plan on changing the interface, then? Removing the SCSI stuff completely? Do bear in mind that there are still SCSI burners and people using them, and cdrecord is currently portable to many operating systems. > > Matthias, can you give me a hand with this? I'll need a way > to sort and publish incoming patches, letting them sit for a > while. (like what Andrew Morton does for the kernel) This > can't work like procps because the hardware varies too much. Look a year down the road, when we have have two (or more) new 25GB optical formats coming out, probably with new features and commands and several vendors building drives for them. Both formats have DRM stuff in them, and GPL 3 forbids implementing DRM (simplification). Better you than me, but it will be exciting. To the extent that I have the hardware I'll be glad to test. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 21:49 ` Bill Davidsen @ 2006-01-30 21:57 ` Matthias Andree 2006-01-30 22:12 ` Lee Revell 1 sibling, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-01-30 21:57 UTC (permalink / raw) To: Bill Davidsen; +Cc: Albert Cahalan, matthias.andree, linux-kernel On Mon, 30 Jan 2006, Bill Davidsen wrote: > Just to be clear, Joerg is not the only one I think has been a problem > here, he pissed off some of the developers who don't seem overly eager > to do things which would be helpful for any burner software. From here > it looks like a pissing content, with users well within splash range. Well, Jörg is not giving us answers to the extent that might convince a Linux kernel hacker to change things, except for a few handrails besides the staircase, such as Ted's suggestion WRT RLIMIT_MEMLOCK, or people offering to fix ide-tape to talk SG_IO - Jörg however has not yet documented how ide-tape fixes are relevant for the CD writing application (no doubt that a SCSI /GENERAL/ interface library has interest in such, it does not matter to the CD writing topic). > Look a year down the road, when we have have two (or more) new 25GB > optical formats coming out, probably with new features and commands and > several vendors building drives for them. Both formats have DRM stuff in > them, and GPL 3 forbids implementing DRM (simplification). I find it fascinating that everyone talks about the first public GPL v3 draft as though it were the final version. Now is the time to express concerns, for instance, the GPL's incompatibility, to the FSF. And no, I do not have current plans to work on a cdrecord fork as it is. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 21:49 ` Bill Davidsen 2006-01-30 21:57 ` Matthias Andree @ 2006-01-30 22:12 ` Lee Revell 2006-02-16 16:15 ` Bill Davidsen 1 sibling, 1 reply; 717+ messages in thread From: Lee Revell @ 2006-01-30 22:12 UTC (permalink / raw) To: Bill Davidsen; +Cc: Albert Cahalan, matthias.andree, linux-kernel On Mon, 2006-01-30 at 16:49 -0500, Bill Davidsen wrote: > Look a year down the road, when we have have two (or more) new 25GB > optical formats coming out, probably with new features and commands > and several vendors building drives for them. Both formats have DRM > stuff in them, and GPL 3 forbids implementing DRM (simplification). Who cares what GPL 3 says, the kernel is GPL2. Lee ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 22:12 ` Lee Revell @ 2006-02-16 16:15 ` Bill Davidsen 0 siblings, 0 replies; 717+ messages in thread From: Bill Davidsen @ 2006-02-16 16:15 UTC (permalink / raw) To: Lee Revell; +Cc: Albert Cahalan, matthias.andree, linux-kernel Lee Revell wrote: >On Mon, 2006-01-30 at 16:49 -0500, Bill Davidsen wrote: > > >>Look a year down the road, when we have have two (or more) new 25GB >>optical formats coming out, probably with new features and commands >>and several vendors building drives for them. Both formats have DRM >>stuff in them, and GPL 3 forbids implementing DRM (simplification). >> >> > >Who cares what GPL 3 says, the kernel is GPL2. > Did you miss the subject? My reply was to a suggestion that cdrecord (it's not the kernel!) be forked, and discussion of what license MIGHT apply. I was making an information point about an application which is very important to a lot of people. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 ^ permalink raw reply [flat|nested] 717+ messages in thread
[parent not found: <515e525f0602141110r7a96568av4705c2a353407e6@mail.gmail.com>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] <515e525f0602141110r7a96568av4705c2a353407e6@mail.gmail.com> @ 2006-02-14 19:13 ` Joerg Schilling 2006-02-14 19:51 ` Anders Karlsson 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-14 19:13 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: > It would appear that every time someone pose a question, you are > deliberately rude and avoid answering the question, yet when you ask a > question, the entire list is supposed to stand to attention and follow > you every little whim. My mother taught me a very good thing, when > everyone else appear to be wrong - they probably are right. Remember > where you are debating the issue Jörg. You are not on a Solaris > mailing list now. What would you do if you write things and a few minutes later someone replies with something that either does not aply at all or is wrong? This happens since 2 weeks now and I cannot see any progress. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 19:13 ` Joerg Schilling @ 2006-02-14 19:51 ` Anders Karlsson 0 siblings, 0 replies; 717+ messages in thread From: Anders Karlsson @ 2006-02-14 19:51 UTC (permalink / raw) To: Joerg Schilling Cc: Valdis.Kletnieks, peter.read, mj, matthias.andree, linux-kernel, jim, jerome.lacoste, jengelh, dhazelton On Tue, 14 Feb 2006 19:13:19 -0000, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Anders Karlsson <trudheim@gmail.com> wrote: > >> It would appear that every time someone pose a question, you are >> deliberately rude and avoid answering the question, yet when you ask a >> question, the entire list is supposed to stand to attention and follow >> you every little whim. My mother taught me a very good thing, when >> everyone else appear to be wrong - they probably are right. Remember >> where you are debating the issue Jörg. You are not on a Solaris >> mailing list now. > > What would you do if you write things and a few minutes later someone > replies with something that either does not aply at all or is wrong? The code I have written has mainly been Perl or shell script, and while it is not used by tens of thousands of people around the globe I have a few users that ask why I do things this way or that way. I explain why, I encourage them to look at the code and I *want* them to come with suggestions - because *I will learn things if they do*. cdrecord is a very useful tool, I have used it before, I will probably use it again. However, people are pointing out quirks in the user interface, they have offered patches, they have offered to work on problems in the Linux kernel and yet you insist that cdrecord/libscg is right and Linux users are wrong. What people have asked here is no more and no less than that you consider altering the user interface of cdrecord to take the device-name of a writer instead of the BTL address. They have even offered to do the work. I am sure you are as sick of this debate as everyone else is. If you were to just consider the proposals that has been made, for a minute ignoring the past two weeks aggravation, I am sure that you can see the merits of them. No-one is asking you to accept anything and everything patch-like thrown your way. What we are saying is that in modern Linux distributions, users access devices through /dev/devicename - that limits confusion. So far, the _only_ programs I have encountered that does not use devices in /dev is SANE - and cdrecord. > This happens since 2 weeks now and I cannot see any progress. To be fair, I have been more than a little sarcastic in this discussion. I apologise if that has offended you or anyone else. If you are fair to yourself, you will look back over the discussion, see how you have responded to people and you may understand their reactions as well. There has been far to much pride and hot-headedness in this discussion. Are we not all supposed to be on the same side? F/OSS vs Big Bad Corporations? How about we all calm down, admit our own failings and look at how we all can compromise and get a solution that all can agree on - without letting our own pride and egos get in the way? Kind regards, PS, sorry about the essay. -- Anders Karlsson <anders@trudheim.com> QA Engineer | GnuPG Key ID - 0x4B20601A ^ permalink raw reply [flat|nested] 717+ messages in thread
[parent not found: <5E0mO-7c4-25@gated-at.bofh.it>]
[parent not found: <5E0wj-7nC-1@gated-at.bofh.it>]
[parent not found: <5E0Q5-7Nq-37@gated-at.bofh.it>]
[parent not found: <5EgBc-5nU-9@gated-at.bofh.it>]
[parent not found: <5En0E-6QU-27@gated-at.bofh.it>]
[parent not found: <5En9R-73g-13@gated-at.bofh.it>]
[parent not found: <5EnCS-7Qt-35@gated-at.bofh.it>]
[parent not found: <5EnW8-8go-3@gated-at.bofh.it>]
[parent not found: <5EnWo-8go-31@gated-at.bofh.it>]
[parent not found: <5EEkg-7AS-41@gated-at.bofh.it>]
[parent not found: <5EEX1-8py-41@gated-at.bofh.it>]
[parent not found: <5EFJk-1bU-31@gated-at.bofh.it>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <5EFJk-1bU-31@gated-at.bofh.it> @ 2006-02-12 16:03 ` Bodo Eggert 0 siblings, 0 replies; 717+ messages in thread From: Bodo Eggert @ 2006-02-12 16:03 UTC (permalink / raw) To: Joerg Schilling, matthias.andree, peter.read, mj, matthias.andree, linux-kernel, jim, jengelh Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: >> > > Nonsense. The b,t,l addresses are NOT stable (at least for transports >> > >> > Dou you like to verify that you have no clue on SCSI? >> >> How does, for instance, libscg make sure that the b,t,l mappings are >> hotplug invariant? >> >> How does libscg make sure that two external writers, say USB, retain >> their b,t,l mappings if both are unplugged and then replugged in reverse >> order, perhaps into different USB hubs? > > Well, this is a deficit of the Linux kernel - not libscg. > > If you are unhappy with Hot plug support on Linux, I recommend you to > check Solaris. I see only support for 16*16*8=2048 devices in scsi-sun.c. Therefore you need at most 2049 devices to have no possibility for stable device<->b,t,l relation. Asume 2048 devices had been plugged into USB, so that you have the mapping 0,0,0 -> yellow burner .. 15,15,7 -> purple burner. If you reuse any of these IDs, also plugging in the corresponding device would result in a non-stable ID. (One broken device with serial number = `dd if=/dev/random` will do the trick, too.) So if you can't create a stable mapping using b,t,l, why should you bother trying and mislead your users into asuming a stable mapping? And why should you impose a btl mapping if it's possible to allow naming the device whatever the user likes, causing the number of stable device names to be limited only by it's lifetime? The only things you need is a list of devices and a way to map a unique ID to a device name. I posted scripts that will so that. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest)
@ 2006-02-11 8:59 Andrey Borzenkov
0 siblings, 0 replies; 717+ messages in thread
From: Andrey Borzenkov @ 2006-02-11 8:59 UTC (permalink / raw)
To: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[Sorry for crippled Cc I'm answering off web archive]
> Joerg Schilling schrieb am 2006-02-09:
> > DervishD <lkml@dervishd.net> wrote:
> > > other half doesn't have it probably has a bad user interface. You
> > > know that if a program uses a naming convention different from ALL
> > > the rest of programs is because the program has a problem. You know
> > > that if the only UNIX program out there that doesn't use /dev entries
> > > to talk to devices is cdrecord, the problem *probably* is in
> > > cdrecord, and not in UNIX...
> >
> > So why do you like to introduce a different naming scheme?
>
> It is striking that Jіrg Schilling's code alone uses this naming scheme,
> and nothing else appears to be. If there is, perhaps naming a few
> typical real-world applications could enlighten us. You haven't
> mentioned examples yet, so there isn't even a faint hint cdrecord is
> consistent with the so-called real-world.
Legato Networker (now belongs to EMC) is using the same enumeration scheme to
access media changer (but not the drivers themselves). In this case I can
speak for Solaris, Windows and Linux. I must admit I would have preferred to
use something like /dev/sgen on Solaris because even Networker documentation
warns that adapter number that is shown by configuration bears no relation to
adapter instance numbers as can be seen by user. So almost the only way to
make sure you are speaking to correct physical device is to use inquire
command and check device type and may be even serial number. The only
consolation is that you usually do not have dozens of media changers
connected ;)
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD7aeNR6LMutpd94wRAguxAJ97zFNUyinXEc7yQwqP7pgU+ZHQaACgsbti
eu6TLSAFR7KHVgUErhjaIZc=
=8J0V
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest)
@ 2006-02-09 17:38 Zoltan Boszormenyi
2006-02-09 22:33 ` Sam Vilain
0 siblings, 1 reply; 717+ messages in thread
From: Zoltan Boszormenyi @ 2006-02-09 17:38 UTC (permalink / raw)
To: linux-kernel
Hi!
>DervishD <lkml@dervishd.net> wrote:
>
>> Could you please clarify which things are broken by Matthias
>> patch? This way he (or other developer) can prepare a better patch
>> and maintain it. BTW, I patched my cdrecord with Matthias patch and
>> nothing seems to be broken :? Maybe am I missing something?
>
>It is completely broken and thus makes no sense at all.
>
>As I did write it looks lie a dentist drills a hole into an aking tooth
>and then claims to be complete with the whole treatment.
>
>Jörg
>
>
It is a nicely written metaphor but hardly qualifies as a technical
argument.
Sorry, -1 point for you for being such a bully. You obviously didn't look at
Matthias' patch, you even expressed unwillingness to look at it.
I would be _very_ surprised if at the end you actually read or
(oh, the horror!) test it.
I have followed every such threads that ended in a flamefest.
Folks, please, cdrecord is GPL, at least up to 2.01.01a06.
Take this version and ask for help from the wizards at forum.rpc1.org
in forking. They drink, eat and breath CD-R[W] and DVD+-R[W] firmwares,
they surely know vendor commands, they must be able to understand
Jörg's software and maybe improve upon it. They can validate the
ossdvd patch, and fix it if it's buggy. For those who don't know,
there even exists a firmware updater for Pioneer DVD+-RW
drives that work on Linux with /dev entries, on a live system,
without the need for a reboot... http://lasvegas.rpc1.org/
Look, Jörg, they don't need HOST/TARGET/LUN triplets for this task!
Best regards,
Zoltán Böszörményi
^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-09 17:38 Zoltan Boszormenyi @ 2006-02-09 22:33 ` Sam Vilain 0 siblings, 0 replies; 717+ messages in thread From: Sam Vilain @ 2006-02-09 22:33 UTC (permalink / raw) To: Zoltan Boszormenyi; +Cc: linux-kernel Zoltan Boszormenyi wrote: > Folks, please, cdrecord is GPL, at least up to 2.01.01a06. > Take this version and ask for help from the wizards at forum.rpc1.org > in forking. They drink, eat and breath CD-R[W] and DVD+-R[W] firmwares, > they surely know vendor commands, they must be able to understand > Jörg's software and maybe improve upon it. They can validate the > ossdvd patch, and fix it if it's buggy. For those who don't know, > there even exists a firmware updater for Pioneer DVD+-RW > drives that work on Linux with /dev entries, on a live system, > without the need for a reboot... http://lasvegas.rpc1.org/ This sounds like a sensible idea. I honestly don't understand why people let themselves get all worked up and spend so much energy on someone who's clearly diverging in their ideals from the spirit of the community. I also don't know why they think they have a right to demand things of a volunteer in the first place. The only difference between this troll and any other troll is that the troll is the original author and copyright holder, but he appears to have stepped down as a Free Software author. Why spend effort on trolls when you can instead branch/fork the code base and spend that effort productively? Sam. ^ permalink raw reply [flat|nested] 717+ messages in thread
[parent not found: <5yJ3h-6er-11@gated-at.bofh.it>]
[parent not found: <5yVQR-8bI-39@gated-at.bofh.it>]
[parent not found: <5yWah-99-29@gated-at.bofh.it>]
[parent not found: <5yWjN-Bl-13@gated-at.bofh.it>]
[parent not found: <5yWDl-111-23@gated-at.bofh.it>]
[parent not found: <5yWML-1ea-5@gated-at.bofh.it>]
[parent not found: <5zc5f-6pi-3@gated-at.bofh.it>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <5zc5f-6pi-3@gated-at.bofh.it> @ 2006-01-26 14:27 ` Heikki Orsila 2006-01-27 2:25 ` Robert Hancock 1 sibling, 0 replies; 717+ messages in thread From: Heikki Orsila @ 2006-01-26 14:27 UTC (permalink / raw) To: Linux Kernel Mailing List Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > People like to run cdrecord -scanbus in order to find a list of usable > devices. People like to see all SCSI devices in a single name space as > they are all using the same protocol for communication. Not me. I would just like to see a list of /dev/name entries, rather than know anything about scsi. Better yet, I wouldn't want to know anything about the devices. It should just work. -- Heikki Orsila Barbie's law: heikki.orsila@iki.fi "Math is hard, let's go shopping!" http://www.iki.fi/shd ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <5zc5f-6pi-3@gated-at.bofh.it> 2006-01-26 14:27 ` Heikki Orsila @ 2006-01-27 2:25 ` Robert Hancock 1 sibling, 0 replies; 717+ messages in thread From: Robert Hancock @ 2006-01-27 2:25 UTC (permalink / raw) To: linux-kernel Joerg Schilling wrote: > People like to run cdrecord -scanbus in order to find a list of usable devices. > People like to see all SCSI devices in a single name space as they are all > using the same protocol for communication. Except that the majority of CD writers today are NOT SCSI devices. They may use the MMC command set from SCSI for interface purposes, but they are on an ATA or USB bus. cdrecord tries to fabricate some kind of device numbering assigning SCSI-like bus and LUN numbers for the devices when such a numbering has no basis in any kind of reality. We have all SCSI devices in a single namespace, that is what /dev is for. That is the name that the system/kernel provides for applications to use, and that is what the application should use, not some kind of bizarre invented numbering scheme built on top of that. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 717+ messages in thread
[parent not found: <5yWts-OZ-21@gated-at.bofh.it>]
[parent not found: <5z1Wj-TN-31@gated-at.bofh.it>]
[parent not found: <5zer2-1BC-29@gated-at.bofh.it>]
[parent not found: <5AFHY-5jd-23@gated-at.bofh.it>]
[parent not found: <5ALb5-5kV-43@gated-at.bofh.it>]
[parent not found: <5B15G-39W-17@gated-at.bofh.it>]
[parent not found: <5B1Im-4cW-7@gated-at.bofh.it>]
[parent not found: <5B3TN-7AV-9@gated-at.bofh.it>]
[parent not found: <5Bs5Z-1BT-17@gated-at.bofh.it>]
[parent not found: <5BJgx-1fE-13@gated-at.bofh.it>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <5BJgx-1fE-13@gated-at.bofh.it> @ 2006-02-02 23:29 ` Bodo Eggert 2006-02-03 13:54 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: Bodo Eggert @ 2006-02-02 23:29 UTC (permalink / raw) To: Joerg Schilling, schilling, jengelh, mrmacman_g4, mj, matthias.andree, linux-kernel, James, j, acahalan Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: >> It's shorter than /dev/c0t0d0s0? Well, I think it's because people think >> in terms of connectors (my drive is IDE therefore it must be hdc) rather >> than protocol (my drive does ATAPI therefore it must be >> /dev/scsi/c0t0d0s0). > > Is there any reason why the people with small PCs should dominate the > people with big machines? > > If you use /dev/hd*, you loose control after you add more than ~ 6-10 disks. So you'll create a symlink. (If you're Ingvar Kamprad, it will be named bjørn.) > The systematical attempt is easy to remember even with a big amount of > external hardware. If you - add a SCSI controler - add an USB burner - connect to an aoe/iscsi-device(?), it will get a random ID. If you reboot (or just plug out/plug in), it will be randomly different. The same thing may happen after a system upgrade, possibly depending on the linker. In these cases, there is nothing you can remember, and you'll have to run -scanbus in order to find out if your burner is 0.8.15 or maybe 32.16.8 _each_ time you want to burn a CD. But you _can_ remember (or write into your config files) that it will be named /udev/cdr/LITE-ON_LTR-48246K. Having to find out the magic number of the day is usurally worse than using the very same name you usurally use to identify an object. If you see an advantage, let the ATAPI bus be -3, translate -3,$n,0.0 to "/dev/hd".chr(96+$n) and everybody will be happy. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-02 23:29 ` Bodo Eggert @ 2006-02-03 13:54 ` Joerg Schilling 2006-02-03 19:30 ` Matthias Andree 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-03 13:54 UTC (permalink / raw) To: schilling, mrmacman_g4, mj, matthias.andree, linux-kernel, jengelh, James, j, acahalan, 7eggert Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote: > If you > - add a SCSI controler > - add an USB burner > - connect to an aoe/iscsi-device(?), > it will get a random ID. If you reboot (or just plug out/plug in), it will > be randomly different. The same thing may happen after a system upgrade, > possibly depending on the linker. This is a limitation of the implementation used on Linux and not true for e.g. Solaris. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 13:54 ` Joerg Schilling @ 2006-02-03 19:30 ` Matthias Andree 2006-02-06 14:46 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-03 19:30 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, mj, matthias.andree, linux-kernel, jengelh, James, j, acahalan, 7eggert Joerg Schilling schrieb am 2006-02-03: > This is a limitation of the implementation used on Linux and not true for e.g. > Solaris. Linux is not Solaris. Do you want your application to work with Linux, because it brings customers? If yes, listen to kernel developers if they say "you don't need that feature". Note I do not consider myself kernel developer. I'm a bystander who's trying to help out. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-03 19:30 ` Matthias Andree @ 2006-02-06 14:46 ` Joerg Schilling 2006-02-06 17:37 ` René Rebe ` (2 more replies) 0 siblings, 3 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-06 14:46 UTC (permalink / raw) To: schilling, matthias.andree Cc: mrmacman_g4, mj, matthias.andree, linux-kernel, jengelh, James, j, acahalan, 7eggert Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-03: > > > This is a limitation of the implementation used on Linux and not true for e.g. > > Solaris. > > Linux is not Solaris. > > Do you want your application to work with Linux, > because it brings customers? > > If yes, listen to kernel developers if they say "you don't need that > feature". Note I do not consider myself kernel developer. I'm a > bystander who's trying to help out. ???? Kernel developers should listen to the right application developers (in special when they may have more kernel skills) to find out what's needed. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-06 14:46 ` Joerg Schilling @ 2006-02-06 17:37 ` René Rebe 2006-02-06 17:43 ` Bodo Eggert 2006-02-07 10:56 ` Matthias Andree 2 siblings, 0 replies; 717+ messages in thread From: René Rebe @ 2006-02-06 17:37 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, mrmacman_g4, mj, linux-kernel, jengelh, James, j, acahalan, 7eggert Hi, On Monday 06 February 2006 15:46, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > Joerg Schilling schrieb am 2006-02-03: > > > > > This is a limitation of the implementation used on Linux and not true for e.g. > > > Solaris. > > > > Linux is not Solaris. > > > > Do you want your application to work with Linux, > > because it brings customers? > > > > If yes, listen to kernel developers if they say "you don't need that > > feature". Note I do not consider myself kernel developer. I'm a > > bystander who's trying to help out. > > ???? > > Kernel developers should listen to the right application developers Yes, to the _right_ ones. You are soo right. > (in special when they may have more kernel skills) to find out > what's needed. ... Have a nice day, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45 ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-06 14:46 ` Joerg Schilling 2006-02-06 17:37 ` René Rebe @ 2006-02-06 17:43 ` Bodo Eggert 2006-02-07 10:56 ` Matthias Andree 2 siblings, 0 replies; 717+ messages in thread From: Bodo Eggert @ 2006-02-06 17:43 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, mrmacman_g4, mj, linux-kernel, jengelh, James, j, acahalan, 7eggert On Mon, 6 Feb 2006, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > Joerg Schilling schrieb am 2006-02-03: > > > This is a limitation of the implementation used on Linux and not true for e.g. > > > Solaris. > > > > Linux is not Solaris. > > > > Do you want your application to work with Linux, > > because it brings customers? > > > > If yes, listen to kernel developers if they say "you don't need that > > feature". Note I do not consider myself kernel developer. I'm a > > bystander who's trying to help out. > > ???? > > Kernel developers should listen to the right application developers > (in special when they may have more kernel skills) to find out > what's needed. >From what I read, you need a way to map a short ID (possibly formed like \mathbb{N}^4) to a (devicename, ID')-tupel, where ID' may be ID, a dummy value or something completely different. With the old /dev/sg-scheme, you had a hard time assigning /dev/sg_num_of_the_day to a device, and you had to enqure each for the ID in order to at least give a stable name. Obviously this was bad, therefore it was superseded by the current method, making /dev/sg obsolete. It is still supported, but nobody will enheance it to include IDE. With the current mechanism, you can assign a user-defined name like /dev/scsi/host1/bus2/id3/lun4/cd, /dev/scsi/1.2.3.4, /dev/bjørn or /dev/cdr/vendor_model. Obviously some are hard to type, and some are designed to be typed by the user. In the later case, the user should be allowed to use these names even if it isn't portable, and in the former cases, having a nice thing. For systems using /dev/scsi/1.2.3.4 etc., you can enumerate all devices by walking a list of paths and trying each device in turn, and you can find the device node using a regular expression. On systems using /dev/cdr/vendor_model or /dev/bjørn, you can't list all devices yourself, but maybe you can exec a user-defined program doing this work for you. In order to find the device again, you can either make the list be (device node, ID), or define a reverse switch giving you just the device node. I'd prefer the later, since that'd let you handle device names containing spaces. I'd use a script for both cases, and since many systems will use the numeric scheme, maybe provide a default script for them. If the user or the distribution doesn't use numeric IDs, they can create their own script. (Off cause you'll still need the sg-scanning for 2.4 kernels). Example for my system, obviously slightly untested: ---/etc/default/cdrecord:--- #aliases toshiba TOSHIBA_XM-6201TA -1 -1 liteon LITE-ON_LTR-48246K 40 16m apple MATSHITA_CR-8004 -1 -1 CDR_DEVICE = LITE-ON_LTR-48246K enumerate_devices_bin = /usr/lib/cdrecord-scandevices.sh --- ---/usr/lib/cdrecord-scandevices.sh--- #!/bin/sh if [ "$1" == "-r" ]; then # reverse mapping exec /usr/bin/find /dev/cd{,r} -follow -name "$2" else exec /usr/bin/find /dev/cd{,r} -follow -type b -printf "%f\n" fi --- ---default script--- #!/bin/sh if [ "$1" == "-r" ]; then # reverse mapping case "$2" in -1.* ) a="`echo "$2"|sed -e \ 's,\(.*\)\.\(.*\)\.\(.*\)\.\(.*\),.*[^0-9]\2[^0-9]+\3[^0-9]*,'`" /usr/bin/find /dev/ide/ -regex "$a" -type b ;; *) a="`echo "$2"|sed -e \ 's,\(.*\)\.\(.*\)\.\(.*\)\.\(.*\),.*[^0-9]\1[^0-9]+\2[^0-9]+\3[^0-9]+\4[^0-9]*,'`" /usr/bin/find /dev/scsi/ -regex "$a" -type b ;; esac else /usr/bin/find /dev/ide/ -type b \! -regex '.*part[0-9]+' \ | sed -e \ 's/[^0-9]/./g;s/\.\.*/\./g;s/^\.*//;s/\.*$//;s/^/-1./;s/$/.0/' /usr/bin/find /dev/scsi/ \! -regex '.*part[0-9]+' -type b \ | sed -e 's/[^0-9]/./g;s/\.\.*/\./g;s/^\.*//;s/\.*$//' fi --- -- One enemy soldier is never enough, but two is entirely too many. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-06 14:46 ` Joerg Schilling 2006-02-06 17:37 ` René Rebe 2006-02-06 17:43 ` Bodo Eggert @ 2006-02-07 10:56 ` Matthias Andree 2 siblings, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-07 10:56 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, mrmacman_g4, mj, linux-kernel, jengelh, James, j, acahalan, 7eggert Joerg Schilling schrieb am 2006-02-06: > Kernel developers should listen to the right application developers > (in special when they may have more kernel skills) to find out > what's needed. Your skills are misrepresenting facts, ignoring uncomfortable questions, and shifting the blame you have to take on others. These are skills that make you belong to the "wrong" application developers that a kernel developer will not listen to. You demand cooperation, but you only see it as cooperation if people do as _you_ say. You put up artificial limits in your applications to "prove" some kernel is wrong. Is there anyone who does not see this as some kind of campaign of yours? -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest)
@ 2006-01-25 3:23 Albert Cahalan
2006-01-25 14:26 ` Jan Engelhardt
0 siblings, 1 reply; 717+ messages in thread
From: Albert Cahalan @ 2006-01-25 3:23 UTC (permalink / raw)
To: linux-kernel, rlrevell, schilling, matthias.andree, jengelh
Jan Engelhardt writes:
> Where is the difference between SG_IO-on-hdx and sg0?
It's like the /dev/ttyS* and /dev/cua* situation, where
we also ended up with multiple device files. This is bad.
SG_IO-on-hdx is modern. It properly associates everything
with one device, which you may name as desired.
sg0 is useful for devices that are not disk, tape, or CD.
A decade ago, it was also the proper way to send raw SCSI
commands to other devices. For nasty compatibility reasons,
Linux still assigns /dev/sg* devices for disk, tape, and CD.
^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 3:23 Albert Cahalan @ 2006-01-25 14:26 ` Jan Engelhardt 2006-01-25 14:45 ` Jens Axboe 0 siblings, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-01-25 14:26 UTC (permalink / raw) To: Albert Cahalan Cc: Linux Kernel Mailing List, rlrevell, schilling, matthias.andree >> Where is the difference between SG_IO-on-hdx and sg0? > >It's like the /dev/ttyS* and /dev/cua* situation, where >we also ended up with multiple device files. This is bad. > >SG_IO-on-hdx is modern. It properly associates everything >with one device, which you may name as desired. Let's analyze a case: if /dev/sg0 would always be associated with /dev/hda, /dev/sg1 always with /dev/hdb, no matter if there was actually a hda/sg0 device present in the system - would that simplify the problem? Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 14:26 ` Jan Engelhardt @ 2006-01-25 14:45 ` Jens Axboe 2006-01-25 15:13 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Jens Axboe @ 2006-01-25 14:45 UTC (permalink / raw) To: Jan Engelhardt Cc: Albert Cahalan, Linux Kernel Mailing List, rlrevell, schilling, matthias.andree On Wed, Jan 25 2006, Jan Engelhardt wrote: > > >> Where is the difference between SG_IO-on-hdx and sg0? > > > >It's like the /dev/ttyS* and /dev/cua* situation, where > >we also ended up with multiple device files. This is bad. > > > >SG_IO-on-hdx is modern. It properly associates everything > >with one device, which you may name as desired. > > Let's analyze a case: > if /dev/sg0 would always be associated with /dev/hda, > /dev/sg1 always with /dev/hdb, no matter if there was actually a > hda/sg0 device present in the system - would that simplify > the problem? Forget /dev/sg0, it's meaningless and confusing to try and bind two unrelated names to each other. You want to talk to /dev/hda, use /dev/hda. Don't try and create a pseudo mapping between the two. That's also where cdrecord gets it wrong on Linux - you don't need -scanbus. If users think they do, it's either because Joerg brain washed them or because they have been used to that bad interface since years ago when it was unfortunately needed. -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 14:45 ` Jens Axboe @ 2006-01-25 15:13 ` Jan Engelhardt 2006-01-25 15:30 ` Jens Axboe 2006-01-25 17:10 ` are added/removed - which 0 siblings, 2 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-01-25 15:13 UTC (permalink / raw) To: Jens Axboe Cc: Albert Cahalan, Linux Kernel Mailing List, rlrevell, schilling, matthias.andree > >- you don't need -scanbus. If >users think they do, it's either because Joerg brain washed them or >because they have been used to that bad interface since years ago when >it was unfortunately needed. Now you're unfair. -scanbus does a nice output of what cdwriters (and other capable devices) are present. For me, that lists the cd writer and a CF slot from the multitype usb flash reader. There's one kind of not-so-advanced linux newbies that just go to walmart, buy a computer and whack a linux system on it for fun, and they still don't know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is usually a nightmare for them, and apart that -scanbus lists scsi host,id,lun instead of /dev/hd* (don't comment on this kthx), it is convenient for this sort of users to find out what's available. So, and what about that compactflash reader? It is subject to dynamic usb->scsi device association (depending on when you connect it, it may either become sda, or sdb, or sdc, etc.), and -scanbus yet again provides some way (albeit not useful, because it lists scsi,id,lun rather than /dev/sd* - don't comment either) to see where it actually is. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 15:13 ` Jan Engelhardt @ 2006-01-25 15:30 ` Jens Axboe 2006-01-25 17:03 ` Joerg Schilling ` (2 more replies) 2006-01-25 17:10 ` are added/removed - which 1 sibling, 3 replies; 717+ messages in thread From: Jens Axboe @ 2006-01-25 15:30 UTC (permalink / raw) To: Jan Engelhardt Cc: Albert Cahalan, Linux Kernel Mailing List, rlrevell, schilling, matthias.andree On Wed, Jan 25 2006, Jan Engelhardt wrote: > > > > >- you don't need -scanbus. If > >users think they do, it's either because Joerg brain washed them or > >because they have been used to that bad interface since years ago when > >it was unfortunately needed. > > Now you're unfair. > -scanbus does a nice output of what cdwriters (and other capable devices) > are present. For me, that lists the cd writer and a CF slot from the > multitype usb flash reader. > > There's one kind of not-so-advanced linux newbies that just go to walmart, > buy a computer and whack a linux system on it for fun, and they still don't > know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is > usually a nightmare for them, and apart that -scanbus lists scsi > host,id,lun instead of /dev/hd* (don't comment on this kthx), it is > convenient for this sort of users to find out what's available. > > So, and what about that compactflash reader? It is subject to dynamic > usb->scsi device association (depending on when you connect it, it may > either become sda, or sdb, or sdc, etc.), and -scanbus yet again provides > some way (albeit not useful, because it lists scsi,id,lun rather than > /dev/sd* - don't comment either) to see where it actually is. You just want the device naming to reflect that. The user should not need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would likely be using k3b or something graphical though, and just click on his Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could help do this dynamically even. If you are using cdrecord on the command line, you are by definition an advanced user and know how to find out where that writer is. -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 15:30 ` Jens Axboe @ 2006-01-25 17:03 ` Joerg Schilling 2006-01-25 17:11 ` Matthias Andree ` (2 more replies) 2006-01-25 22:01 ` jerome lacoste 2006-01-26 20:42 ` Jan Engelhardt 2 siblings, 3 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-25 17:03 UTC (permalink / raw) To: jengelh, axboe Cc: schilling, rlrevell, matthias.andree, linux-kernel, acahalan Jens Axboe <axboe@suse.de> wrote: > You just want the device naming to reflect that. The user should not > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would > likely be using k3b or something graphical though, and just click on his > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could > help do this dynamically even. Guess why cdrecord -scanbus is needed. It serves the need of GUI programs for cdrercord and allows them to retrieve and list possible drives of interest in a platform independent way. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:03 ` Joerg Schilling @ 2006-01-25 17:11 ` Matthias Andree 2006-01-25 17:18 ` grundig 2006-01-25 19:00 ` Tomasz Torcz 2 siblings, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-01-25 17:11 UTC (permalink / raw) To: Joerg Schilling; +Cc: jengelh, axboe, rlrevell, linux-kernel, acahalan Joerg Schilling wrote: > Jens Axboe <axboe@suse.de> wrote: > >> You just want the device naming to reflect that. The user should not >> need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would >> likely be using k3b or something graphical though, and just click on his >> Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could >> help do this dynamically even. > > Guess why cdrecord -scanbus is needed. > > It serves the need of GUI programs for cdrercord and allows them to retrieve > and list possible drives of interest in a platform independent way. There are bugs in the implementation that prevent -scanbus from working properly, and they are not Linux bugs. Once -scanbus really scans all devices and skips those it cannot access (rather than quitting), you might have a point. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:03 ` Joerg Schilling 2006-01-25 17:11 ` Matthias Andree @ 2006-01-25 17:18 ` grundig 2006-01-25 17:31 ` Jens Axboe 2006-01-26 9:38 ` Joerg Schilling 2006-01-25 19:00 ` Tomasz Torcz 2 siblings, 2 replies; 717+ messages in thread From: grundig @ 2006-01-25 17:18 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, axboe, schilling, rlrevell, matthias.andree, linux-kernel, acahalan El Wed, 25 Jan 2006 18:03:18 +0100, Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > Guess why cdrecord -scanbus is needed. > > It serves the need of GUI programs for cdrercord and allows them to retrieve > and list possible drives of interest in a platform independent way. But this is not neccesary at all, since linux platform already provides ways to retrieve and list possible drives.... ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:18 ` grundig @ 2006-01-25 17:31 ` Jens Axboe 2006-01-25 18:22 ` Matthias Andree 2006-01-25 19:04 ` Olivier Galibert 2006-01-26 9:38 ` Joerg Schilling 1 sibling, 2 replies; 717+ messages in thread From: Jens Axboe @ 2006-01-25 17:31 UTC (permalink / raw) To: grundig Cc: Joerg Schilling, jengelh, rlrevell, matthias.andree, linux-kernel, acahalan On Wed, Jan 25 2006, grundig@teleline.es wrote: > El Wed, 25 Jan 2006 18:03:18 +0100, > Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > > > Guess why cdrecord -scanbus is needed. > > > > It serves the need of GUI programs for cdrercord and allows them to retrieve > > and list possible drives of interest in a platform independent way. > > But this is not neccesary at all, since linux platform already > provides ways to retrieve and list possible drives.... In fact it would be a _lot_ easier to just scan sysfs and do an inquiry on potentially useful devices. -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:31 ` Jens Axboe @ 2006-01-25 18:22 ` Matthias Andree 2006-01-25 18:25 ` Jens Axboe ` (2 more replies) 2006-01-25 19:04 ` Olivier Galibert 1 sibling, 3 replies; 717+ messages in thread From: Matthias Andree @ 2006-01-25 18:22 UTC (permalink / raw) To: Jens Axboe Cc: grundig, Joerg Schilling, jengelh, rlrevell, linux-kernel, acahalan Jens Axboe wrote: > In fact it would be a _lot_ easier to just scan sysfs and do an inquiry > on potentially useful devices. Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather complicated and non-portable. I understand that applications that can just open every device and send SCSI INQUIRY might want to do that on Linux, too. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 18:22 ` Matthias Andree @ 2006-01-25 18:25 ` Jens Axboe 2006-01-25 23:14 ` Matthias Andree 2006-01-26 0:36 ` Nix 2006-01-26 10:11 ` Joerg Schilling 2 siblings, 1 reply; 717+ messages in thread From: Jens Axboe @ 2006-01-25 18:25 UTC (permalink / raw) To: Matthias Andree Cc: grundig, Joerg Schilling, jengelh, rlrevell, linux-kernel, acahalan On Wed, Jan 25 2006, Matthias Andree wrote: > Jens Axboe wrote: > > > In fact it would be a _lot_ easier to just scan sysfs and do an inquiry > > on potentially useful devices. > > Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather > complicated and non-portable. I understand that applications that can just > open every device and send SCSI INQUIRY might want to do that on Linux, too. Certainly, I'm just suggesting a better way to do it on Linux. -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 18:25 ` Jens Axboe @ 2006-01-25 23:14 ` Matthias Andree 2006-01-26 1:13 ` grundig 0 siblings, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-01-25 23:14 UTC (permalink / raw) To: Jens Axboe Cc: Matthias Andree, grundig, Joerg Schilling, jengelh, linux-kernel, acahalan (stripped Lee from the Cc: list) Jens Axboe schrieb am 2006-01-25: > > Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather > > complicated and non-portable. I understand that applications that can just > > open every device and send SCSI INQUIRY might want to do that on Linux, too. > > Certainly, I'm just suggesting a better way to do it on Linux. Great. There's a better way, but it is not necessary. Let Linux-specific applications use it for their benefit, but a portable application isn't going that way because it's too much effort. If a simpler interface that can be shared with half a dozen other system exists, the portable application will use that and ignore better interfaces. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 23:14 ` Matthias Andree @ 2006-01-26 1:13 ` grundig 2006-01-26 8:23 ` Matthias Andree 2006-01-26 13:41 ` Joerg Schilling 0 siblings, 2 replies; 717+ messages in thread From: grundig @ 2006-01-26 1:13 UTC (permalink / raw) To: Matthias Andree Cc: axboe, matthias.andree, schilling, jengelh, linux-kernel, acahalan El Thu, 26 Jan 2006 00:14:22 +0100, Matthias Andree <matthias.andree@gmx.de> escribió: > Great. There's a better way, but it is not necessary. Let Linux-specific > applications use it for their benefit, but a portable application isn't > going that way because it's too much effort. If a simpler interface that > can be shared with half a dozen other system exists, the portable > application will use that and ignore better interfaces. It's too "much effort"? Basically, what linux is asking is that cdrecord stop wasting efforts trying to implement its own solution. Linux is asking cdrecord to use SG_IO and leave device discovery and data transport issues to the platform. Linux doesn't even need -scanbus for example. You could compile out that code. Device discovery is done by the platform - I find _scary_ that other "modern" operative systems don't have a way of providing device discovery services in 2006 and that a external app is needed but hey, people is free to design their operative system as they like. Linux provides it and leaves Schilling time to focus in other things. In my book, that's not "too much effort", is "less effort". If someone bugs you because SG_IO doesn't work just tell him to report the problem here - in fact cdrecord already has a "friendly" warning about "linux-2.5 and newer". The cdrecord low level scsi driver for SG_IO should be much simpler than all the others... ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 1:13 ` grundig @ 2006-01-26 8:23 ` Matthias Andree 2006-01-26 13:56 ` Joerg Schilling 2006-01-26 13:41 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-01-26 8:23 UTC (permalink / raw) To: grundig; +Cc: axboe, schilling, jengelh, linux-kernel, acahalan On Thu, 26 Jan 2006, grundig@teleline.es wrote: > It's too "much effort"? Basically, what linux is asking is that cdrecord > stop wasting efforts trying to implement its own solution. Linux is > asking cdrecord to use SG_IO and leave device discovery and data transport > issues to the platform. > > Linux doesn't even need -scanbus for example. You could compile out that > code. Device discovery is done by the platform - I find _scary_ that other > "modern" operative systems don't have a way of providing device discovery > services in 2006 and that a external app is needed but hey, people is free > to design their operative system as they like. Linux provides it and leaves > Schilling time to focus in other things. In my book, that's not "too much > effort", is "less effort". If someone bugs you because SG_IO doesn't work > just tell him to report the problem here - in fact cdrecord already has a > "friendly" warning about "linux-2.5 and newer". The cdrecord low level > scsi driver for SG_IO should be much simpler than all the others... Well, you need to implement 30 (or so) platform-specific ways to get a list of devices, and portable applications aren't going to do that. To make it explicit: no way. It is a maintenance nightmare, 30 lowly-tested pieces of code, too. This sounds like a huge difference, but I don't believe it actually is. Jörg is trying to fight the system rather than stop complaining to users about their using /dev/hd*. The scanning code is there and can be made working with little effort probably. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 8:23 ` Matthias Andree @ 2006-01-26 13:56 ` Joerg Schilling 2006-01-26 18:47 ` Jan Engelhardt 2006-01-30 21:58 ` Bill Davidsen 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 13:56 UTC (permalink / raw) To: matthias.andree, grundig Cc: schilling, linux-kernel, jengelh, axboe, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > Well, you need to implement 30 (or so) platform-specific ways to get a > list of devices, and portable applications aren't going to do that. To > make it explicit: no way. It is a maintenance nightmare, 30 lowly-tested > pieces of code, too. It already works in libscg since nearly 10 years. > This sounds like a huge difference, but I don't believe it actually is. > Jörg is trying to fight the system rather than stop complaining to users > about their using /dev/hd*. The scanning code is there and can be made > working with little effort probably. Talking about /dev/hd* ignore the basic problem. Show me a way how to send SCSI commands to a ATAPI tape drive on Linux. Please do not forget that libscg is OS _and_ device independent. Implementing /dev/hd* support at all is already a concession that did go to far. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 13:56 ` Joerg Schilling @ 2006-01-26 18:47 ` Jan Engelhardt 2006-01-30 21:58 ` Bill Davidsen 1 sibling, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-01-26 18:47 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, grundig, linux-kernel, axboe, acahalan [-- Attachment #1: Type: TEXT/PLAIN, Size: 824 bytes --] >> This sounds like a huge difference, but I don't believe it actually is. >> Jörg is trying to fight the system rather than stop complaining to users >> about their using /dev/hd*. The scanning code is there and can be made >> working with little effort probably. > >Talking about /dev/hd* ignore the basic problem. Show me a way how to >send SCSI commands to a ATAPI tape drive on Linux. ATAPI tapes writing CDs (or tapes for that amtter). It may seem possible if the scsi command is the same. Feels like making tea in a coffee machine, but hey, it's possible, and sounds like Someone want's to have it. :) >Please do not forget that libscg is OS _and_ device independent. If so, how much effort is there in having libscg building an enumeration out of all (related to cd writing) sysfs drives? Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 13:56 ` Joerg Schilling 2006-01-26 18:47 ` Jan Engelhardt @ 2006-01-30 21:58 ` Bill Davidsen 1 sibling, 0 replies; 717+ messages in thread From: Bill Davidsen @ 2006-01-30 21:58 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel, jengelh, axboe, acahalan Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > >>Well, you need to implement 30 (or so) platform-specific ways to get a >>list of devices, and portable applications aren't going to do that. To >>make it explicit: no way. It is a maintenance nightmare, 30 lowly-tested >>pieces of code, too. > > > It already works in libscg since nearly 10 years. > > >>This sounds like a huge difference, but I don't believe it actually is. >>Jörg is trying to fight the system rather than stop complaining to users >>about their using /dev/hd*. The scanning code is there and can be made >>working with little effort probably. > > > Talking about /dev/hd* ignore the basic problem. Show me a way how to > send SCSI commands to a ATAPI tape drive on Linux. > > Please do not forget that libscg is OS _and_ device independent. > Implementing /dev/hd* support at all is already a concession that did go to far. You added the feature, and a message that it was accidental and unsupported. In truth is was neither, and your little message pisses off developers and scares casual users. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 1:13 ` grundig 2006-01-26 8:23 ` Matthias Andree @ 2006-01-26 13:41 ` Joerg Schilling 1 sibling, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 13:41 UTC (permalink / raw) To: matthias.andree, grundig Cc: schilling, matthias.andree, linux-kernel, jengelh, axboe, acahalan <grundig@teleline.es> wrote: > It's too "much effort"? Basically, what linux is asking is that cdrecord > stop wasting efforts trying to implement its own solution. Linux is > asking cdrecord to use SG_IO and leave device discovery and data transport > issues to the platform. Cddrecord does not use SG_IO, cdrecord uses the platform independent libscg. If you like to talk on cdrecord, you are talking about the wrong thing. libscg is the target of interest. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 18:22 ` Matthias Andree 2006-01-25 18:25 ` Jens Axboe @ 2006-01-26 0:36 ` Nix 2006-01-26 13:39 ` Joerg Schilling 2006-02-10 21:06 ` Bill Davidsen 2006-01-26 10:11 ` Joerg Schilling 2 siblings, 2 replies; 717+ messages in thread From: Nix @ 2006-01-26 0:36 UTC (permalink / raw) To: Matthias Andree Cc: Jens Axboe, grundig, Joerg Schilling, jengelh, rlrevell, linux-kernel, acahalan On 25 Jan 2006, Matthias Andree prattled cheerily: > Jens Axboe wrote: > >> In fact it would be a _lot_ easier to just scan sysfs and do an inquiry >> on potentially useful devices. > > Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather > complicated and non-portable. I understand that applications that can just > open every device and send SCSI INQUIRY might want to do that on Linux, too. Applications (already) do this by asking HAL, which can be informed of new devices in a variety of ways: the up-and-coming one is for the kernel to notify udevd, following which a udev rule sends a dbus message to HAL. Everything from the dbus message on up is cross-OS portable. -scanbus is *totally* unnecessary. (Furthermore, it fails to work in a quite laughable fashion in the presence of hotpluggable storage media. udev handles giving hotpluggable storage media consistent device names with extreme ease, and tells HAL about them so that users see the new devices appear even if they don't have a clue that /dev even exists. The change that J. Random Nontechnical User will ever run `cdrecord -scanbus' is *nil*, and applications don't run it either because they can't judge between all the devices that are listed to pick the one which is a CD recorder (consider the consequences should they guess wrong!). Instead, they invariably ask for a device name, or, in more recent versions get the info from HAL. HAL knows if something is a CD recorder because its backend, e.g. udev, told it.) -- `Everyone has skeletons in the closet. The US has the skeletons driving living folks into the closet.' --- Rebecca Ore ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 0:36 ` Nix @ 2006-01-26 13:39 ` Joerg Schilling 2006-02-10 21:06 ` Bill Davidsen 1 sibling, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 13:39 UTC (permalink / raw) To: nix, matthias.andree Cc: schilling, rlrevell, linux-kernel, jengelh, grundig, axboe, acahalan Nix <nix@esperi.org.uk> wrote: > Applications (already) do this by asking HAL, which can be informed of > new devices in a variety of ways: the up-and-coming one is for the > kernel to notify udevd, following which a udev rule sends a dbus message > to HAL. Everything from the dbus message on up is cross-OS portable. > -scanbus is *totally* unnecessary. Interesting theory.... unfortunately this makes assumptions that cannot be proved. Where is this HAL available and more impportant: how is it related to generis transport and device independent SCSI? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 0:36 ` Nix 2006-01-26 13:39 ` Joerg Schilling @ 2006-02-10 21:06 ` Bill Davidsen [not found] ` <20060210184241.35332e78.seanlkml@sympatico.ca> ` (3 more replies) 1 sibling, 4 replies; 717+ messages in thread From: Bill Davidsen @ 2006-02-10 21:06 UTC (permalink / raw) To: Nix; +Cc: Jens Axboe, Joerg Schilling, linux-kernel red brick + atlantaNix wrote: > On 25 Jan 2006, Matthias Andree prattled cheerily: > >>Jens Axboe wrote: >>Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather >>complicated and non-portable. I understand that applications that can just >>open every device and send SCSI INQUIRY might want to do that on Linux, too. > > > Applications (already) do this by asking HAL, which can be informed of > new devices in a variety of ways: the up-and-coming one is for the > kernel to notify udevd, following which a udev rule sends a dbus message > to HAL. Everything from the dbus message on up is cross-OS portable. > -scanbus is *totally* unnecessary. I notice that the first thing people suggest is to make things like udev, hal and sysfs required instead of optional to do something as simple as burn a CD. As I mentioned before, if the kernel provided a list of devices then applications wouldn't break every time a new kernel came out which needs a new this, and new that, and a few new other support things. The kernel could provide a list of devices by category. It doesn't have to name them, run scripts, give descriptions, or paint them blue. Just a list of all block devices, tapes, by major/minor and category (ie. block, optical, floppy) would give the application layer a chance to do it's own interpretation. HAL is great, but because it's not part of the kernel it's also going to suffer from "tracking error" for some changes. I find it easier to teach someone to use -scanbus than to explain how to make rules for udev. > > (Furthermore, it fails to work in a quite laughable fashion in the > presence of hotpluggable storage media. udev handles giving hotpluggable > storage media consistent device names with extreme ease, and tells HAL > about them so that users see the new devices appear even if they don't > have a clue that /dev even exists. > > The change that J. Random Nontechnical User will ever run `cdrecord > -scanbus' is *nil*, and applications don't run it either because they > can't judge between all the devices that are listed to pick the one > which is a CD recorder (consider the consequences should they guess > wrong!). Instead, they invariably ask for a device name, or, in more > recent versions get the info from HAL. HAL knows if something is a CD > recorder because its backend, e.g. udev, told it.) > Worth repeating: I find it easier to teach someone to use -scanbus than to explain how to make rules for udev. HAL is the right answer, but *in* the kernel, where it will track changes. Since -scanbus tells you a device is a CDrecorder, or something else, *any user* is likely to be able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices... Note: my example of major/minor is just that, almost any presentation which showed all devices user applications would normally use, in a well defined way, would address the identifications issue. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 ^ permalink raw reply [flat|nested] 717+ messages in thread
[parent not found: <20060210184241.35332e78.seanlkml@sympatico.ca>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <20060210184241.35332e78.seanlkml@sympatico.ca> @ 2006-02-10 23:42 ` sean 0 siblings, 0 replies; 717+ messages in thread From: sean @ 2006-02-10 23:42 UTC (permalink / raw) To: Bill Davidsen; +Cc: nix, axboe, schilling, linux-kernel On Fri, 10 Feb 2006 16:06:39 -0500 Bill Davidsen <davidsen@tmr.com> wrote: > I notice that the first thing people suggest is to make things like > udev, hal and sysfs required instead of optional to do something as > simple as burn a CD. > [snip] All that is required is a proper device node in /dev; is this really so much of a burden? This device node can be created statically at install time or via udev or any other method. In fact if you're using udev and a device node isn't automatically created for all of your cd burners, you can file a bug report and get it fixed. So in the end all you ever have to teach a user is to pick the device they want from /dev. Sean ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 21:06 ` Bill Davidsen [not found] ` <20060210184241.35332e78.seanlkml@sympatico.ca> @ 2006-02-10 23:51 ` Christian Neumair 2006-02-13 13:24 ` Joerg Schilling 2006-02-10 23:56 ` Greg KH 2006-02-13 12:11 ` Joerg Schilling 3 siblings, 1 reply; 717+ messages in thread From: Christian Neumair @ 2006-02-10 23:51 UTC (permalink / raw) To: Bill Davidsen; +Cc: Nix, Jens Axboe, Joerg Schilling, linux-kernel Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen: > The kernel could provide a list of devices by category. It doesn't have > to name them, run scripts, give descriptions, or paint them blue. Just a > list of all block devices, tapes, by major/minor and category (ie. > block, optical, floppy) would give the application layer a chance to do > it's own interpretation. Introducing more than interface for doing the same thing can be very confusing and counter-productive. You'll create new, undocumented or semi-documented interfaces which will lead to a dependency chaos. Some random script will work with kernel 2.6.11, 2.6.12 and 2.6.13, but not 2.6.14 and later because a new device class was introduced and two typos were fixed. Especially considering that the new linux development model makes it likely that major changes go into micro releases, stability and reliability will be a huge problem. > HAL is great, but because it's not part of the > kernel it's also going to suffer from "tracking error" for some changes. > I find it easier to teach someone to use -scanbus than to explain how to > make rules for udev. Tastes are different. I think the HAL semantics are perfectly OK for doing what you want, i.e. you can use hal-find-by-capability together with hal-get-property to get the block device paths of the installed mass storage and for distinguishing them. Distributors should ship sane udev rules applicable for 99.5% of the people out there. They do, actually. > > [...] > Worth repeating: I find it easier to teach someone to use -scanbus than > to explain how to make rules for udev. > HAL is the right answer, Nice that we agree on that. > but *in* the kernel, where it will track changes. Oh, and BSDs and other target systems of interest for higher-level libraries and applications don't need libhal? What do we gain by pushing more and more functionality down the stack right into the kernel, without guaranteeing ABI/API stability? HAL was developed with portability in mind, why should one give it up for solving hypothetical problems, depending on release cycles and patch review by external projects? I thought the original plan was rather to break the kernel down and not to make it a melting pot for all kinds of specialized functionality, which to my impression was originally done because of the lack of vendor support. > Since -scanbus tells you a > device is a CDrecorder, or something else, *any user* is likely to be > able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices... Well, "any user" just opens his Windows Explorer and takes a look at the icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is interesting to see professional programmers often argue that a particular solution they like is appropriate for all users without giving proof. I can't think of a single reason why a user wants to dump all his devices without knowing the grep semantics, which in turn makes it very likely that he will write some wrapper code around any of the currently perfectly working solutions. -- Christian Neumair <chris@gnome-de.org> ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 23:51 ` Christian Neumair @ 2006-02-13 13:24 ` Joerg Schilling 2006-02-13 13:55 ` Martin Mares ` (3 more replies) 0 siblings, 4 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-13 13:24 UTC (permalink / raw) To: davidsen, chris; +Cc: schilling, nix, linux-kernel, axboe Christian Neumair <chris@gnome-de.org> wrote: > Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen: > > The kernel could provide a list of devices by category. It doesn't have > > to name them, run scripts, give descriptions, or paint them blue. Just a > > list of all block devices, tapes, by major/minor and category (ie. > > block, optical, floppy) would give the application layer a chance to do > > it's own interpretation. > > Introducing more than interface for doing the same thing can be very > confusing and counter-productive. You'll create new, undocumented or > semi-documented interfaces which will lead to a dependency chaos. So you concur with me that the fact that Linux introduced another interface for SCSI was onfusing and counter-productive. > Some random script will work with kernel 2.6.11, 2.6.12 and 2.6.13, but > not 2.6.14 and later because a new device class was introduced and two > typos were fixed. Especially considering that the new linux development > model makes it likely that major changes go into micro releases, > stability and reliability will be a huge problem. The main problem is that there is no grant that a new model will survive a time frame that makes sense to implement support. > > Since -scanbus tells you a > > device is a CDrecorder, or something else, *any user* is likely to be > > able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices... > > Well, "any user" just opens his Windows Explorer and takes a look at the > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is > interesting to see professional programmers often argue that a This is not true: a drive letter mapping does not need to exist on MS-WIN in order to be able to access it via ASPI or SPTI. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:24 ` Joerg Schilling @ 2006-02-13 13:55 ` Martin Mares 2006-02-13 15:17 ` Joerg Schilling 2006-02-13 14:07 ` jerome lacoste ` (2 subsequent siblings) 3 siblings, 1 reply; 717+ messages in thread From: Martin Mares @ 2006-02-13 13:55 UTC (permalink / raw) To: Joerg Schilling; +Cc: davidsen, chris, nix, linux-kernel, axboe Hello! > The main problem is that there is no grant that a new model will survive > a time frame that makes sense to implement support. I bet that it would take less time to implement this support than what you spend here by arguing and trying to prove you are the only sane person in the world. Unsuccessfully, of course. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "#define QUESTION ((bb) || !(bb))" -- Shakespeare ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:55 ` Martin Mares @ 2006-02-13 15:17 ` Joerg Schilling 2006-02-18 13:47 ` Bill Davidsen 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-13 15:17 UTC (permalink / raw) To: schilling, mj; +Cc: nix, linux-kernel, davidsen, chris, axboe Martin Mares <mj@ucw.cz> wrote: > Hello! > > > The main problem is that there is no grant that a new model will survive > > a time frame that makes sense to implement support. > > I bet that it would take less time to implement this support than what > you spend here by arguing and trying to prove you are the only sane > person in the world. Unsuccessfully, of course. If memory serves me correctly, the current model is the 3rd incompatible one offerend within less than 5 years. If you did ever try to write reliable code that has to deal with this kind of oddities, you would understand that it is sometimes better to wait and to inform related people about the problems they caused. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:17 ` Joerg Schilling @ 2006-02-18 13:47 ` Bill Davidsen 2006-02-19 1:10 ` D. Hazelton 2006-02-20 16:05 ` Joerg Schilling 0 siblings, 2 replies; 717+ messages in thread From: Bill Davidsen @ 2006-02-18 13:47 UTC (permalink / raw) To: Joerg Schilling; +Cc: mj, nix, linux-kernel, chris, axboe Joerg Schilling wrote: >Martin Mares <mj@ucw.cz> wrote: > > > >>Hello! >> >> >> >>>The main problem is that there is no grant that a new model will survive >>>a time frame that makes sense to implement support. >>> >>> >>I bet that it would take less time to implement this support than what >>you spend here by arguing and trying to prove you are the only sane >>person in the world. Unsuccessfully, of course. >> >> > >If memory serves me correctly, the current model is the 3rd incompatible one >offerend within less than 5 years. > > With that I agree. Not only does the interface change, the details within a given interface must change. >If you did ever try to write reliable code that has to deal with this kind of >oddities, you would understand that it is sometimes better to wait and to inform >related people about the problems they caused. > > This ground has been covered. And at least in the case of filtering commands, that had to be done quickly and you know it. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 13:47 ` Bill Davidsen @ 2006-02-19 1:10 ` D. Hazelton 2006-02-19 9:20 ` Matthias Andree 2006-02-20 16:05 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-19 1:10 UTC (permalink / raw) To: Bill Davidsen; +Cc: Joerg Schilling, mj, nix, linux-kernel, chris, axboe On Saturday 18 February 2006 08:47, Bill Davidsen wrote: > Joerg Schilling wrote: > >Martin Mares <mj@ucw.cz> wrote: > >>Hello! > >> > >>>The main problem is that there is no grant that a new model will survive > >>>a time frame that makes sense to implement support. > >> > >>I bet that it would take less time to implement this support than what > >>you spend here by arguing and trying to prove you are the only sane > >>person in the world. Unsuccessfully, of course. > > > >If memory serves me correctly, the current model is the 3rd incompatible > > one offerend within less than 5 years. > > With that I agree. Not only does the interface change, the details > within a given interface must change. At this point I seem to have stumbled across a document that has what Joerg might be looking for Linux to introduce. It's available at t10.org and is a translation layer specification for OS's to use if they want to access ATA devices like SCSI ones. Seems to me this wouldn't be a good or bad thing to add to the kernel. The problem is that introducing the layer and thereby unifying the SCSI and ATA busses into one namespace is a big task. I know I couldn't manage it, and don't think there are any people willing to take it on. Introducing it would provide a standard interface, however. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-19 1:10 ` D. Hazelton @ 2006-02-19 9:20 ` Matthias Andree 2006-02-20 1:53 ` D. Hazelton 0 siblings, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-19 9:20 UTC (permalink / raw) To: D. Hazelton Cc: Bill Davidsen, Joerg Schilling, mj, nix, linux-kernel, chris, axboe On Sat, 18 Feb 2006, D. Hazelton wrote: > At this point I seem to have stumbled across a document that has what Joerg > might be looking for Linux to introduce. It's available at t10.org and is a > translation layer specification for OS's to use if they want to access ATA > devices like SCSI ones. Is that something other than CAM? If so, please mention the exact document name. > Seems to me this wouldn't be a good or bad thing to add to the kernel. The Well, such an integration must avoid: - breaking existing conformant applications, where conformant here would apply to existing interface documentation such as the SCSI General Programming HOWTO from torque.net. This means that int fd = open("/dev/foo", O_RDWR, 0); int e = ioctl(fd, SG_IO, &cmd_block); needs to remain functional. - duplicating code which would cause immediate bit-rot... > problem is that introducing the layer and thereby unifying the SCSI and ATA > busses into one namespace is a big task. ...so it could really only be an interface layer on top of existing interfaces to avoid that. (Any other opinions?) And then that interface would only be sensible if it actually improves the situation, for instance, if applications gain source-level compatibility with NetBSD or FreeBSD. I think libata's integration of parallel ATA is already going a way that leads to unifiying all the layers. For disks, the sd driver is used with libata. I'd be surprised if it wouldn't work for CD/DVD drives, too, at least in the long run. Part of the problem is Jörg's expecting a solution the day before yesterday. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-19 9:20 ` Matthias Andree @ 2006-02-20 1:53 ` D. Hazelton 2006-02-20 16:41 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-20 1:53 UTC (permalink / raw) To: Matthias Andree Cc: Bill Davidsen, Joerg Schilling, mj, nix, linux-kernel, chris, axboe On Sunday 19 February 2006 04:20, Matthias Andree wrote: > On Sat, 18 Feb 2006, D. Hazelton wrote: > > At this point I seem to have stumbled across a document that has what > > Joerg might be looking for Linux to introduce. It's available at t10.org > > and is a translation layer specification for OS's to use if they want to > > access ATA devices like SCSI ones. > > Is that something other than CAM? If so, please mention the exact > document name. The documents title is: "Information Technology - SCSI / ATA translation (SAT) The revision I'm looking at is R08 - the most current I could find. I'll have to dig, but it doesn't appear to just be a rewrite of CAM from the quick once over I gave it. > > Seems to me this wouldn't be a good or bad thing to add to the kernel. > > The > > Well, such an integration must avoid: > > - breaking existing conformant applications, where conformant here would > apply to existing interface documentation such as the SCSI General > Programming HOWTO from torque.net. > > This means that int fd = open("/dev/foo", O_RDWR, 0); > int e = ioctl(fd, SG_IO, &cmd_block); > needs to remain functional. > > - duplicating code which would cause immediate bit-rot... Yes, true. After all Linus has said that there is to be no more breaking of userspace interfaces. In this case I think what the layer would do is allow the people that want to to use /dev/sg* to access all SCSI and ATA devices on a given system. It's purpose, from the blurb on t10.org, is to provide a SCSI interface to ATA disks for people that want to access them that way. > > problem is that introducing the layer and thereby unifying the SCSI and > > ATA busses into one namespace is a big task. > > ...so it could really only be an interface layer on top of existing > interfaces to avoid that. (Any other opinions?) > Right. Which is one reason why I did say that I thought it might be a good idea, but didn't think that anyone would bother. I also don't think it's really necessary. SG_IO happens to work great and the amount of work involved... Anyway, to me it seems like it'd just be resurrecting a deprecated module and expanding it so it has a wider scope. Only real difference would be that it wouldn't take devices from their driver, just provide a second interface to it - which also means that all the ATA drivers would need to have hooks that it could call into. (Or am I over thinking it here?) > And then that interface would only be sensible if it actually improves > the situation, for instance, if applications gain source-level > compatibility with NetBSD or FreeBSD. Well, FreeBSD implements CAM, so if someone implemented CAM that'd provide source-level compatability. In this case what it would do is hard to say - the only thing I can think it _might_ do is quiet a couple of people down a bit. > I think libata's integration of parallel ATA is already going a way that > leads to unifiying all the layers. For disks, the sd driver is used with > libata. I'd be surprised if it wouldn't work for CD/DVD drives, too, at > least in the long run. Ah, yes. I was under the impression that libata only handled PATA and SATA - is it going to be expanded to encompass the entire ATA bus? > Part of the problem is Jörg's expecting a solution the day before > yesterday. Well, from some comments he made in private mails he seems to think he was promised (by Linus, no less) that the DMA problems in ide-scsi were going to be fixed. Instead the module was deprecated and SG_IO was introduced - this seems to be one of the things he's been angry about. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 1:53 ` D. Hazelton @ 2006-02-20 16:41 ` Joerg Schilling 2006-02-20 18:40 ` D. Hazelton 2006-02-21 4:11 ` D. Hazelton 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-20 16:41 UTC (permalink / raw) To: matthias.andree, dhazelton Cc: schilling, nix, mj, linux-kernel, davidsen, chris, axboe "D. Hazelton" <dhazelton@enter.net> wrote: > > Part of the problem is Jörg's expecting a solution the day before > > yesterday. > > Well, from some comments he made in private mails he seems to think he was > promised (by Linus, no less) that the DMA problems in ide-scsi were going to > be fixed. Instead the module was deprecated and SG_IO was introduced - this > seems to be one of the things he's been angry about. Even you have become a victim of the trolls :-( SG_IO was used in ide-scsi a long time before it was needlessly introduced on top of /dev/hd* Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 16:41 ` Joerg Schilling @ 2006-02-20 18:40 ` D. Hazelton 2006-02-21 10:08 ` Joerg Schilling 2006-02-21 4:11 ` D. Hazelton 1 sibling, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-20 18:40 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, nix, mj, linux-kernel, davidsen, chris, axboe On Monday 20 February 2006 11:41, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > Part of the problem is Jörg's expecting a solution the day before > > > yesterday. > > > > Well, from some comments he made in private mails he seems to think he > > was promised (by Linus, no less) that the DMA problems in ide-scsi were > > going to be fixed. Instead the module was deprecated and SG_IO was > > introduced - this seems to be one of the things he's been angry about. > > Even you have become a victim of the trolls :-( Never a victim. I stick my nose where I choose - in this case I stuck it in here because I had hoped to turn a discussion I saw descending into a flamewar into something productive. > SG_IO was used in ide-scsi a long time before it was needlessly introduced > on top of /dev/hd* Needlessly? Not true. It was missing from the layer, as all modern ATA devices do support some form of ATAPI, which is, as you've so frequently pointed out, a form of SCSI. So why is an unneeded thing to introduce the ability to use that full capacity? And here I must parrot Martin Mares - you complain about problems when not using ide-scsi but almost all the bugs you've mentioned only occur when using ide-scsi. Now, I'll go and finish replying to all the other mails that have come into my inbox (on this thread) and not been sorted down because they were directly to me. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 18:40 ` D. Hazelton @ 2006-02-21 10:08 ` Joerg Schilling 2006-02-21 10:20 ` Matthias Andree 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-21 10:08 UTC (permalink / raw) To: schilling, dhazelton Cc: nix, mj, matthias.andree, linux-kernel, davidsen, chris, axboe "D. Hazelton" <dhazelton@enter.net> wrote: > > SG_IO was used in ide-scsi a long time before it was needlessly introduced > > on top of /dev/hd* > > Needlessly? Not true. It was missing from the layer, as all modern ATA devices > do support some form of ATAPI, which is, as you've so frequently pointed out, > a form of SCSI. So why is an unneeded thing to introduce the ability to use > that full capacity? There used to be generic support, so this way of support is unneeded. The fact that people did make ide-scsi (the generic way) impossible to use is a bug that needs to be fixed. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 10:08 ` Joerg Schilling @ 2006-02-21 10:20 ` Matthias Andree 0 siblings, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-21 10:20 UTC (permalink / raw) To: Joerg Schilling; +Cc: Linux-Kernel mailing list Joerg Schilling schrieb am 2006-02-21: > There used to be generic support, so this way of support is unneeded. It is not your business to decide what is unneeded in Linux and what isn't, and CD writing (still the Subject line!) doesn't require ide-scsi. Evidently the additional SG_IO support in ide-cd doesn't break your applications. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 16:41 ` Joerg Schilling 2006-02-20 18:40 ` D. Hazelton @ 2006-02-21 4:11 ` D. Hazelton 2006-02-21 10:36 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-21 4:11 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, nix, mj, linux-kernel, davidsen, chris, axboe Joerg, I've been thinking about your report about Linux munging CDB's sent to certian ATAPI devices. While reading the MMC-5 spec again today (my memory of it was starting to fail and I felt I had best be on top of it in this discussion) a statement made about sending SCSI commands to ATAPI devices caught me. ATAPI command packets are fixed at a 12 byte size. Is it possible you tried to send a CDB in excess of that fixed size re: those drives that get a munged CDB? Just a thought... DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 4:11 ` D. Hazelton @ 2006-02-21 10:36 ` Joerg Schilling 2006-02-24 19:46 ` Christian Neumair 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-21 10:36 UTC (permalink / raw) To: schilling, dhazelton Cc: nix, mj, matthias.andree, linux-kernel, davidsen, chris, axboe "D. Hazelton" <dhazelton@enter.net> wrote: > Joerg, I've been thinking about your report about Linux munging CDB's sent to > certian ATAPI devices. While reading the MMC-5 spec again today (my memory of > it was starting to fail and I felt I had best be on top of it in this > discussion) a statement made about sending SCSI commands to ATAPI devices > caught me. > > ATAPI command packets are fixed at a 12 byte size. Is it possible you tried to > send a CDB in excess of that fixed size re: those drives that get a munged > CDB? I did write some time ago that the most probable cause for the Linux bug is that Linux is sending uninitialized data for the amount of bytes that pad to 12 byte. Libscg is the first application ever, that always correctly deals with CDB size as it started to do so in August 1986 which is before any other SCSI generic transport has been available. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 10:36 ` Joerg Schilling @ 2006-02-24 19:46 ` Christian Neumair 2006-02-27 11:32 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: Christian Neumair @ 2006-02-24 19:46 UTC (permalink / raw) To: Joerg Schilling Cc: dhazelton, nix, mj, matthias.andree, linux-kernel, davidsen, axboe [-- Attachment #1: Type: text/plain, Size: 469 bytes --] Am Dienstag, den 21.02.2006, 11:36 +0100 schrieb Joerg Schilling: > I did write some time ago that the most probable cause for the Linux > bug is that > Linux is sending uninitialized data for the amount of bytes that pad > to 12 byte. How are they supposed to be filled? I don't have a clue on the low-level stuff involved, but isn't this as simple as initializing the rest of the c array in idescsi_pc_t to 0? -- Christian Neumair <chris@gnome-de.org> [-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --] [-- Type: application/pgp-signature, Size: 191 bytes --] ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-24 19:46 ` Christian Neumair @ 2006-02-27 11:32 ` Joerg Schilling 0 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-27 11:32 UTC (permalink / raw) To: schilling, chris Cc: nix, mj, matthias.andree, linux-kernel, dhazelton, davidsen, axboe Christian Neumair <chris@gnome-de.org> wrote: > Am Dienstag, den 21.02.2006, 11:36 +0100 schrieb Joerg Schilling: > > I did write some time ago that the most probable cause for the Linux > > bug is that > > Linux is sending uninitialized data for the amount of bytes that pad > > to 12 byte. > > How are they supposed to be filled? I don't have a clue on the low-level > stuff involved, but isn't this as simple as initializing the rest of the > c array in idescsi_pc_t to 0? They are supposed to be filled with null chars. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 13:47 ` Bill Davidsen 2006-02-19 1:10 ` D. Hazelton @ 2006-02-20 16:05 ` Joerg Schilling 2006-02-20 18:53 ` D. Hazelton 1 sibling, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-20 16:05 UTC (permalink / raw) To: schilling, davidsen; +Cc: nix, mj, linux-kernel, chris, axboe Bill Davidsen <davidsen@tmr.com> wrote: > >If you did ever try to write reliable code that has to deal with this kind of > >oddities, you would understand that it is sometimes better to wait and to inform > >related people about the problems they caused. > > > > > This ground has been covered. And at least in the case of filtering > commands, that had to be done quickly and you know it. We all know that filtering is not needeed to fix a bug. It could have been implemented completely relaxed and without any time pressure as the bug that needed fixing could have been fixed by just requiring a R/W FD to allow SG_IO. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 16:05 ` Joerg Schilling @ 2006-02-20 18:53 ` D. Hazelton 2006-02-20 22:30 ` Martin Schlemmer ` (2 more replies) 0 siblings, 3 replies; 717+ messages in thread From: D. Hazelton @ 2006-02-20 18:53 UTC (permalink / raw) To: Joerg Schilling; +Cc: davidsen, nix, mj, linux-kernel, chris, axboe On Monday 20 February 2006 11:05, Joerg Schilling wrote: > Bill Davidsen <davidsen@tmr.com> wrote: > > >If you did ever try to write reliable code that has to deal with this > > > kind of oddities, you would understand that it is sometimes better to > > > wait and to inform related people about the problems they caused. > > > > This ground has been covered. And at least in the case of filtering > > commands, that had to be done quickly and you know it. > > We all know that filtering is not needeed to fix a bug. It could have been > implemented completely relaxed and without any time pressure as the bug > that needed fixing could have been fixed by just requiring a R/W FD to > allow SG_IO. In one post you complain that SG_IO is unneeded on /dev/hd* and related devices and in this one you say that it's all that would have been needed to fix a bug! Joerg, I think it's time you stop dodging questions, shifting blame and all the tactics you've been using and admit that you just don't like Linux. After all, every time you are asked to provide a technical basis for an argument you have three main tactics - Dodge it entirely, misquote POSIX or say "But Solaris does it this way". As you well know I've asked you for quality information I could use to try and fix the bug in the kernel where it munges the CDB for certain drives and am trying to work with you to develop a patch that will let libscg scan both the SCSI and ATA/ATAPI bus on Linux. I realize I'm an unknown factor here, since I've never found any place where my skills would come in useful on a major project like cdrecord or Linux, but now I have. If you do not want the help just say such. If you just want to complain about problems and preach about how great Solaris is, then you are nothing but a feigen schweinhund and deserve to receive no more of my time. (and yes, my German is probably quite bad. It's been a very long time since I've used any of it on a regular basis) DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 18:53 ` D. Hazelton @ 2006-02-20 22:30 ` Martin Schlemmer 2006-02-21 8:32 ` Jens Axboe 2006-02-21 10:19 ` Joerg Schilling 2 siblings, 0 replies; 717+ messages in thread From: Martin Schlemmer @ 2006-02-20 22:30 UTC (permalink / raw) To: D. Hazelton; +Cc: Linux Kernel Mailing Lists [-- Attachment #1: Type: text/plain, Size: 2863 bytes --] On Mon, 2006-02-20 at 13:53 -0500, D. Hazelton wrote: > On Monday 20 February 2006 11:05, Joerg Schilling wrote: > > Bill Davidsen <davidsen@tmr.com> wrote: > > > >If you did ever try to write reliable code that has to deal with this > > > > kind of oddities, you would understand that it is sometimes better to > > > > wait and to inform related people about the problems they caused. > > > > > > This ground has been covered. And at least in the case of filtering > > > commands, that had to be done quickly and you know it. > > > > We all know that filtering is not needeed to fix a bug. It could have been > > implemented completely relaxed and without any time pressure as the bug > > that needed fixing could have been fixed by just requiring a R/W FD to > > allow SG_IO. > Pretty sure it was not to fix a bug, but to plug a possible security issue with non-root users being able to do whatever they wanted on a R/W FD. > In one post you complain that SG_IO is unneeded on /dev/hd* and related > devices and in this one you say that it's all that would have been needed to > fix a bug! > > Joerg, I think it's time you stop dodging questions, shifting blame and all > the tactics you've been using and admit that you just don't like Linux. After > all, every time you are asked to provide a technical basis for an argument > you have three main tactics - Dodge it entirely, misquote POSIX or say "But > Solaris does it this way". > > As you well know I've asked you for quality information I could use to try and > fix the bug in the kernel where it munges the CDB for certain drives and am > trying to work with you to develop a patch that will let libscg scan both the > SCSI and ATA/ATAPI bus on Linux. I realize I'm an unknown factor here, since > I've never found any place where my skills would come in useful on a major > project like cdrecord or Linux, but now I have. > > If you do not want the help just say such. If you just want to complain about > problems and preach about how great Solaris is, then you are nothing but a > feigen schweinhund and deserve to receive no more of my time. > > (and yes, my German is probably quite bad. It's been a very long time since > I've used any of it on a regular basis) > No need to waste your time .. he did not want it to work properly on Linux for years now, and the only reason Linux support have not been removed yet, is because then it will break his 'O so wonderful and only proper "schily" way for "protability to more plaforms than you get from using an GNU autoconf the way the GNU people tell you"'. Oh, and then he looses his favourite "plaform" to rant about. PS: quoted spelling mistakes are not a pun, its just to make sure I do not get accused of being a liar ... Still Amused, -- Martin Schlemmer [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 191 bytes --] ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 18:53 ` D. Hazelton 2006-02-20 22:30 ` Martin Schlemmer @ 2006-02-21 8:32 ` Jens Axboe 2006-02-21 10:19 ` Joerg Schilling 2 siblings, 0 replies; 717+ messages in thread From: Jens Axboe @ 2006-02-21 8:32 UTC (permalink / raw) To: D. Hazelton; +Cc: Joerg Schilling, davidsen, nix, mj, linux-kernel, chris On Mon, Feb 20 2006, D. Hazelton wrote: > On Monday 20 February 2006 11:05, Joerg Schilling wrote: > > Bill Davidsen <davidsen@tmr.com> wrote: > > > >If you did ever try to write reliable code that has to deal with this > > > > kind of oddities, you would understand that it is sometimes better to > > > > wait and to inform related people about the problems they caused. > > > > > > This ground has been covered. And at least in the case of filtering > > > commands, that had to be done quickly and you know it. > > > > We all know that filtering is not needeed to fix a bug. It could have been > > implemented completely relaxed and without any time pressure as the bug > > that needed fixing could have been fixed by just requiring a R/W FD to > > allow SG_IO. > > In one post you complain that SG_IO is unneeded on /dev/hd* and related > devices and in this one you say that it's all that would have been needed to > fix a bug! > > Joerg, I think it's time you stop dodging questions, shifting blame and all > the tactics you've been using and admit that you just don't like Linux. After > all, every time you are asked to provide a technical basis for an argument > you have three main tactics - Dodge it entirely, misquote POSIX or say "But > Solaris does it this way". Please stop CC'ing me on this pointless thread! Dunno who put me back, but I have absolutely ZERO interesting in reading any of it anymore. I'd rather get a root canal while listening to Michael Bolton and getting my right leg sawed off. -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-20 18:53 ` D. Hazelton 2006-02-20 22:30 ` Martin Schlemmer 2006-02-21 8:32 ` Jens Axboe @ 2006-02-21 10:19 ` Joerg Schilling 2006-02-21 10:23 ` Jens Axboe 2 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-21 10:19 UTC (permalink / raw) To: schilling, dhazelton; +Cc: nix, mj, linux-kernel, davidsen, chris, axboe "D. Hazelton" <dhazelton@enter.net> wrote: > Joerg, I think it's time you stop dodging questions, shifting blame and all > the tactics you've been using and admit that you just don't like Linux. After > all, every time you are asked to provide a technical basis for an argument > you have three main tactics - Dodge it entirely, misquote POSIX or say "But > Solaris does it this way". I did provide the details, but it is obvious that you need some basic knowledge in order to contribute useful work. You did look different than the trolls on this list, but now it seemd that you also start parroting the FUD from the trolls on this list. Note that this discussion did take many hours and it may be that it is more efficient for me to immediately stop replying because ther is no hope that this discussion would result in any result that is worh the effort. > As you well know I've asked you for quality information I could use to try and > fix the bug in the kernel where it munges the CDB for certain drives and am > trying to work with you to develop a patch that will let libscg scan both the > SCSI and ATA/ATAPI bus on Linux. I realize I'm an unknown factor here, since > I've never found any place where my skills would come in useful on a major > project like cdrecord or Linux, but now I have. Sorry, I will not fix code that is maintained by people who have mo clean and forseable rules for integration. This discussion has become a waste of time and any time I spend working on Linux is definitely a waste of time as long as decisions are comming from the belly instead of the head. Write down a constitution for Linux, create clean rules, start making is possible to have useful discussions on LKML and it may become different. For now, Linux is scaring off people who know what they are doing. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 10:19 ` Joerg Schilling @ 2006-02-21 10:23 ` Jens Axboe 0 siblings, 0 replies; 717+ messages in thread From: Jens Axboe @ 2006-02-21 10:23 UTC (permalink / raw) To: Joerg Schilling; +Cc: dhazelton, nix, mj, linux-kernel, davidsen, chris On Tue, Feb 21 2006, Joerg Schilling wrote: > Write down a constitution for Linux, create clean rules, start making is > possible to have useful discussions on LKML and it may become different. > For now, Linux is scaring off people who know what they are doing. Everyone else has fruitful discussion on lkml, except you. Clearly the problem is with lkml and the people there, not you. Now either stop writing here or at least stop cc'ing me like I asked you to. -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:24 ` Joerg Schilling 2006-02-13 13:55 ` Martin Mares @ 2006-02-13 14:07 ` jerome lacoste 2006-02-13 15:26 ` Joerg Schilling 2006-02-13 16:43 ` Jan Engelhardt 2006-02-14 0:01 ` D. Hazelton 3 siblings, 1 reply; 717+ messages in thread From: jerome lacoste @ 2006-02-13 14:07 UTC (permalink / raw) To: Joerg Schilling; +Cc: davidsen, chris, nix, linux-kernel, axboe On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: [...] > > > Since -scanbus tells you a > > > device is a CDrecorder, or something else, *any user* is likely to be > > > able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices... > > > > Well, "any user" just opens his Windows Explorer and takes a look at the > > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is > > interesting to see professional programmers often argue that a > > This is not true: a drive letter mapping does not need to exist on MS-WIN > in order to be able to access it via ASPI or SPTI. But from a user perspective, how one is supposed to identify between 2 identical burners named D: and E: on their system if cdrecord only provides b,t,l naming and "b,t,l to cd burner name" mapping? The "OS specific to b,t,l" mapping is clearly lacking although cdrecord knows it there as well. Cf. scsi-wnt.c: #ifdef _DEBUG_SCSIPT js_fprintf(scgp_errfile, "SPTI: Adding drive %c: (%d:%d:%d)\n", 'A'+i, pDrive->ha, pDrive->tgt, pDrive->lun); #endif Jerome ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 14:07 ` jerome lacoste @ 2006-02-13 15:26 ` Joerg Schilling 2006-02-13 15:42 ` jerome lacoste 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-13 15:26 UTC (permalink / raw) To: schilling, jerome.lacoste; +Cc: nix, linux-kernel, davidsen, chris, axboe jerome lacoste <jerome.lacoste@gmail.com> wrote: > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > [...] > > > > Since -scanbus tells you a > > > > device is a CDrecorder, or something else, *any user* is likely to be > > > > able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices... > > > > > > Well, "any user" just opens his Windows Explorer and takes a look at the > > > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is > > > interesting to see professional programmers often argue that a > > > > This is not true: a drive letter mapping does not need to exist on MS-WIN > > in order to be able to access it via ASPI or SPTI. > > But from a user perspective, how one is supposed to identify between 2 > identical burners named D: and E: on their system if cdrecord only > provides b,t,l naming and "b,t,l to cd burner name" mapping? Drive letters do not have real relevence from a OS view if talking about MS-WIN > The "OS specific to b,t,l" mapping is clearly lacking although > cdrecord knows it there as well. Cf. scsi-wnt.c: > > #ifdef _DEBUG_SCSIPT > js_fprintf(scgp_errfile, "SPTI: Adding drive %c: (%d:%d:%d)\n", 'A'+i, > pDrive->ha, pDrive->tgt, pDrive->lun); > #endif The is no mapping, libscg just let's the user use the addressing used inside the MS-WIN kernel. The drive letter related code was contributed by a russion guy who did try to find a way to lock a drive in use by cdrecord, preventing automount/autoexec. This is unfortunately a bit brain-dead and caused by MS-WIN oddities. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ 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:42 ` jerome lacoste 0 siblings, 0 replies; 717+ messages in thread From: jerome lacoste @ 2006-02-13 15:42 UTC (permalink / raw) To: Joerg Schilling; +Cc: nix, linux-kernel, davidsen, chris, axboe On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > [...] > > > > > Since -scanbus tells you a > > > > > device is a CDrecorder, or something else, *any user* is likely to be > > > > > able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices... > > > > > > > > Well, "any user" just opens his Windows Explorer and takes a look at the > > > > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is > > > > interesting to see professional programmers often argue that a > > > > > > This is not true: a drive letter mapping does not need to exist on MS-WIN > > > in order to be able to access it via ASPI or SPTI. > > > > But from a user perspective, how one is supposed to identify between 2 > > identical burners named D: and E: on their system if cdrecord only > > provides b,t,l naming and "b,t,l to cd burner name" mapping? > > Drive letters do not have real relevence from a OS view if talking about MS-WIN Most complaints about cdrecord are to try to make it fit with the user perspective, not the OS one. Mostly nobody complain about the results of cdrecord job (otherwise it would have been rewritten). People just complain on its command line interface. > > The "OS specific to b,t,l" mapping is clearly lacking although > > cdrecord knows it there as well. Cf. scsi-wnt.c: > > > > #ifdef _DEBUG_SCSIPT > > js_fprintf(scgp_errfile, "SPTI: Adding drive %c: (%d:%d:%d)\n", 'A'+i, > > pDrive->ha, pDrive->tgt, pDrive->lun); > > #endif > > The is no mapping, Maybe we disagree on the word "mapping". Didn't this code print out the mapping between a drive letter and a b,t,l number ? > libscg just let's the user use the addressing used inside > the MS-WIN kernel. > > The drive letter related code was contributed by a russion guy who did > try to find a way to lock a drive in use by cdrecord, preventing > automount/autoexec. This is unfortunately a bit brain-dead and caused by > MS-WIN oddities. Quote from scsi-wnt.c where I took the code extract from: /* * Initialization of SCSI Pass Through Interface code. Responsible for * setting up the array of SCSI devices. This code will be a little * different from the normal code -- it will query each drive letter from * C: through Z: to see if it is a CD. When we identify a CD, we then * send CDB with the INQUIRY command to it -- NT will automagically fill in * the PathId, TargetId, and Lun for us. */ The code I am pointing at just maps the various OS specific drives to SCSI b,t,l, like it is done on Linux. This mapping is done in every single scsi-*.c file I had a look at. E.g. openserver: if (scgp->debug > 0) { for (l = 0; l < nlm; l++) js_fprintf((FILE *)scgp->errfile, "%-4s = %5s(%d,%d,%d,%d) -> %s\n", cmtbl[l].typ, cmtbl[l].drv, cmtbl[l].hba, cmtbl[l].bus, cmtbl[l].tgt, cmtbl[l].lun, cmtbl[l].dev); js_fprintf((FILE *)scgp->errfile, "-------------------- \n"); } So can you make this 'mapping' available to wrapper applications in a parsable format? Jerome ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:24 ` Joerg Schilling 2006-02-13 13:55 ` Martin Mares 2006-02-13 14:07 ` jerome lacoste @ 2006-02-13 16:43 ` Jan Engelhardt 2006-02-13 17:27 ` Luke-Jr 2006-02-14 0:01 ` D. Hazelton 3 siblings, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-02-13 16:43 UTC (permalink / raw) To: Joerg Schilling; +Cc: davidsen, chris, nix, linux-kernel, axboe >> Well, "any user" just opens his Windows Explorer and takes a look at the >> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is >> interesting to see professional programmers often argue that a > >This is not true: a drive letter mapping does not need to exist on MS-WIN >in order to be able to access it via ASPI or SPTI. > I have to support this view. Linux filesystems do not show up in Windows Explorer (because there's obviously an fs driver lacking), but there's always a way to damage your Linux from within Windows. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:43 ` Jan Engelhardt @ 2006-02-13 17:27 ` Luke-Jr 2006-02-14 8:11 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Luke-Jr @ 2006-02-13 17:27 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Joerg Schilling, davidsen, chris, nix, linux-kernel, axboe On Monday 13 February 2006 16:43, Jan Engelhardt wrote: > >> Well, "any user" just opens his Windows Explorer and takes a look at the > >> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is > >> interesting to see professional programmers often argue that a > > > >This is not true: a drive letter mapping does not need to exist on MS-WIN > >in order to be able to access it via ASPI or SPTI. > > I have to support this view. Linux filesystems do not show up in Windows > Explorer (because there's obviously an fs driver lacking), but there's > always a way to damage your Linux from within Windows. Really? My Windows-using friend has all his Linux partitions fully visible and usable in Windows Explorer... ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:27 ` Luke-Jr @ 2006-02-14 8:11 ` Jan Engelhardt 0 siblings, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-14 8:11 UTC (permalink / raw) To: Luke-Jr; +Cc: Joerg Schilling, davidsen, chris, nix, linux-kernel, axboe >> >> Well, "any user" just opens his Windows Explorer and takes a look at the >> >> icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is >> >> interesting to see professional programmers often argue that a >> > >> >This is not true: a drive letter mapping does not need to exist on MS-WIN >> >in order to be able to access it via ASPI or SPTI. >> >> I have to support this view. Linux filesystems do not show up in Windows >> Explorer (because there's obviously an fs driver lacking), but there's >> always a way to damage your Linux from within Windows. > >Really? My Windows-using friend has all his Linux partitions fully visible and >usable in Windows Explorer... > Might depend! On DOS and Win98, there is no indication in either DOS or Explorer that there is a second harddisk (got an xfs on it) at all. Only partition entries with Win* type get a drive letter (which does not imply reading is also possible). Might be different on your Windows. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:24 ` Joerg Schilling ` (2 preceding siblings ...) 2006-02-13 16:43 ` Jan Engelhardt @ 2006-02-14 0:01 ` D. Hazelton 2006-02-14 13:59 ` Joerg Schilling 3 siblings, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-14 0:01 UTC (permalink / raw) To: Joerg Schilling; +Cc: davidsen, chris, nix, linux-kernel, axboe On Monday 13 February 2006 08:24, Joerg Schilling wrote: > Christian Neumair <chris@gnome-de.org> wrote: > > Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen: > > > The kernel could provide a list of devices by category. It doesn't have > > > to name them, run scripts, give descriptions, or paint them blue. Just > > > a list of all block devices, tapes, by major/minor and category (ie. > > > block, optical, floppy) would give the application layer a chance to do > > > it's own interpretation. > > > > Introducing more than interface for doing the same thing can be very > > confusing and counter-productive. You'll create new, undocumented or > > semi-documented interfaces which will lead to a dependency chaos. > > So you concur with me that the fact that Linux introduced another interface > for SCSI was onfusing and counter-productive. And look - ide-scsi is going away. So that "new" interface is disappearing. <snip> > > > Since -scanbus tells you a > > > device is a CDrecorder, or something else, *any user* is likely to be > > > able to tell it from DCD, CD-ROM, etc. Nice like of text for most > > > devices... > > > > Well, "any user" just opens his Windows Explorer and takes a look at the > > icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is > > interesting to see professional programmers often argue that a > > This is not true: a drive letter mapping does not need to exist on MS-WIN > in order to be able to access it via ASPI or SPTI. And only true in those cases, although I have seen (thanks to necessity, not choice) that NT (and therefore Win32) does do btl mappings internally at least at boot. But if you claim that SPTI or ASPI is necessary to burn CD's on windows you are sadly mistaken. There are a number of programs which _might_ do ASPI internally, but never export the interface, so how does Windows use it? And with XP, again, thanks to necessity (making money in both cases) I can easily state that Windows does burning _internally_ without ASPI. (which I know doesn't exist because of complaints form WinAmp about the same) DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 0:01 ` D. Hazelton @ 2006-02-14 13:59 ` Joerg Schilling 0 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-14 13:59 UTC (permalink / raw) To: schilling, dhazelton; +Cc: nix, linux-kernel, davidsen, chris, axboe "D. Hazelton" <dhazelton@enter.net> wrote: > On Monday 13 February 2006 08:24, Joerg Schilling wrote: > > Christian Neumair <chris@gnome-de.org> wrote: > > > Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen: > > > > The kernel could provide a list of devices by category. It doesn't have > > > > to name them, run scripts, give descriptions, or paint them blue. Just > > > > a list of all block devices, tapes, by major/minor and category (ie. > > > > block, optical, floppy) would give the application layer a chance to do > > > > it's own interpretation. > > > > > > Introducing more than interface for doing the same thing can be very > > > confusing and counter-productive. You'll create new, undocumented or > > > semi-documented interfaces which will lead to a dependency chaos. > > > > So you concur with me that the fact that Linux introduced another interface > > for SCSI was onfusing and counter-productive. > > And look - ide-scsi is going away. So that "new" interface is disappearing. Try to find out what's new and what's old. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 21:06 ` Bill Davidsen [not found] ` <20060210184241.35332e78.seanlkml@sympatico.ca> 2006-02-10 23:51 ` Christian Neumair @ 2006-02-10 23:56 ` Greg KH 2006-02-12 12:04 ` Olivier Galibert ` (2 more replies) 2006-02-13 12:11 ` Joerg Schilling 3 siblings, 3 replies; 717+ messages in thread From: Greg KH @ 2006-02-10 23:56 UTC (permalink / raw) To: Bill Davidsen; +Cc: Nix, Jens Axboe, Joerg Schilling, linux-kernel On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > The kernel could provide a list of devices by category. It doesn't have > to name them, run scripts, give descriptions, or paint them blue. Just a > list of all block devices, tapes, by major/minor and category (ie. > block, optical, floppy) would give the application layer a chance to do > it's own interpretation. It does so today in sysfs, that is what it is there for. thanks, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 23:56 ` Greg KH @ 2006-02-12 12:04 ` Olivier Galibert 2006-02-12 16:46 ` Greg KH 2006-02-13 5:01 ` Daniel Barkalow 2006-02-13 13:26 ` Joerg Schilling 2 siblings, 1 reply; 717+ messages in thread From: Olivier Galibert @ 2006-02-12 12:04 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel On Fri, Feb 10, 2006 at 03:56:54PM -0800, Greg KH wrote: > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > > > The kernel could provide a list of devices by category. It doesn't have > > to name them, run scripts, give descriptions, or paint them blue. Just a > > list of all block devices, tapes, by major/minor and category (ie. > > block, optical, floppy) would give the application layer a chance to do > > it's own interpretation. > > It does so today in sysfs, that is what it is there for. Except it does not provide the path to the device nodes themselves. You need to call udevinfo for that, or parse /dev/.udev/*. Do you think it would be possible to have hotplug/udev/whatever exists in the future to give that information back in the kernel and have it appear in sysfs? OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-12 12:04 ` Olivier Galibert @ 2006-02-12 16:46 ` Greg KH 2006-02-12 21:14 ` Olivier Galibert 0 siblings, 1 reply; 717+ messages in thread From: Greg KH @ 2006-02-12 16:46 UTC (permalink / raw) To: Olivier Galibert, linux-kernel On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote: > On Fri, Feb 10, 2006 at 03:56:54PM -0800, Greg KH wrote: > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > > > > > The kernel could provide a list of devices by category. It doesn't have > > > to name them, run scripts, give descriptions, or paint them blue. Just a > > > list of all block devices, tapes, by major/minor and category (ie. > > > block, optical, floppy) would give the application layer a chance to do > > > it's own interpretation. > > > > It does so today in sysfs, that is what it is there for. > > Except it does not provide the path to the device nodes themselves. That is not what Bill asked for. So there is no "except" here :) > You need to call udevinfo for that, or parse /dev/.udev/*. Do you > think it would be possible to have hotplug/udev/whatever exists in the > future to give that information back in the kernel and have it appear > in sysfs? No. Why would it when it is very simple to query udevinfo for that? thanks, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-12 16:46 ` Greg KH @ 2006-02-12 21:14 ` Olivier Galibert 2006-02-12 21:49 ` Krzysztof Halasa 2006-02-13 6:24 ` Greg KH 0 siblings, 2 replies; 717+ messages in thread From: Olivier Galibert @ 2006-02-12 21:14 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote: > On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote: > > You need to call udevinfo for that, or parse /dev/.udev/*. Do you > > think it would be possible to have hotplug/udev/whatever exists in the > > future to give that information back in the kernel and have it appear > > in sysfs? > > No. Why would it when it is very simple to query udevinfo for that? In order not to depend on a userland package for the kernel service of device enumeration? It's udevinfo now, what will it be in two years? OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-12 21:14 ` Olivier Galibert @ 2006-02-12 21:49 ` Krzysztof Halasa 2006-02-13 6:24 ` Greg KH 1 sibling, 0 replies; 717+ messages in thread From: Krzysztof Halasa @ 2006-02-12 21:49 UTC (permalink / raw) To: Olivier Galibert; +Cc: Greg KH, linux-kernel Olivier Galibert <galibert@pobox.com> writes: >> No. Why would it when it is very simple to query udevinfo for that? > > In order not to depend on a userland package for the kernel service of > device enumeration? It's udevinfo now, what will it be in two years? Come on, kernel does not need that info at all. In fact, cdrecord doesn't need it either. Some frontends, maybe, though hal may be better source if running. In fact udev isn't mandatory either. We have it because it's handy, it saves us from megatons of /dev files and keeps /dev/black-dvd in sync with black dvd. Personally I think the whole "cdrecord -scanbus" is bogus - command line utils should do what they are asked to do (e.g., write to /dev/hda1 or /dev/microcode if so requested). -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-12 21:14 ` Olivier Galibert 2006-02-12 21:49 ` Krzysztof Halasa @ 2006-02-13 6:24 ` Greg KH 2006-02-13 16:49 ` Olivier Galibert 1 sibling, 1 reply; 717+ messages in thread From: Greg KH @ 2006-02-13 6:24 UTC (permalink / raw) To: Olivier Galibert, linux-kernel On Sun, Feb 12, 2006 at 10:14:06PM +0100, Olivier Galibert wrote: > On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote: > > On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote: > > > You need to call udevinfo for that, or parse /dev/.udev/*. Do you > > > think it would be possible to have hotplug/udev/whatever exists in the > > > future to give that information back in the kernel and have it appear > > > in sysfs? > > > > No. Why would it when it is very simple to query udevinfo for that? > > In order not to depend on a userland package for the kernel service of > device enumeration? It's udevinfo now, what will it be in two years? WTF? You are depending on that same program to create your device nodes. If you don't want to use that program to do it, then use something else, or use a static device tree, which works like always. sysfs exports everything that userspace needs to know, if it wants to create a device node to talk to that specific device. udev used it to create your /dev tree, while other programs use it to create temporary device nodes to do other things to your devices. Either way, the kernel doesn't know, or care what you call those device nodes. thanks, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 6:24 ` Greg KH @ 2006-02-13 16:49 ` Olivier Galibert 2006-02-13 17:50 ` Greg KH 0 siblings, 1 reply; 717+ messages in thread From: Olivier Galibert @ 2006-02-13 16:49 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel On Sun, Feb 12, 2006 at 10:24:12PM -0800, Greg KH wrote: > On Sun, Feb 12, 2006 at 10:14:06PM +0100, Olivier Galibert wrote: > > On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote: > > > On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote: > > > > You need to call udevinfo for that, or parse /dev/.udev/*. Do you > > > > think it would be possible to have hotplug/udev/whatever exists in the > > > > future to give that information back in the kernel and have it appear > > > > in sysfs? > > > > > > No. Why would it when it is very simple to query udevinfo for that? > > > > In order not to depend on a userland package for the kernel service of > > device enumeration? It's udevinfo now, what will it be in two years? > > WTF? You are depending on that same program to create your device > nodes. If you don't want to use that program to do it, then use > something else, or use a static device tree, which works like always. Funnily enough, my, say, mp3 usb key sync system would like to run as non-root and does not want to know or care about what program creates the device nodes. Too bad this otherwise beautiful and useful sysfs is crippled by design. > sysfs exports everything that userspace needs to know, if it wants to > create a device node to talk to that specific device. udev used it to > create your /dev tree, while other programs use it to create temporary > device nodes to do other things to your devices. Either way, the kernel > doesn't know, or care what you call those device nodes. You mean root is mandatory to talk with devices, whatever they are? OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 16:49 ` Olivier Galibert @ 2006-02-13 17:50 ` Greg KH 0 siblings, 0 replies; 717+ messages in thread From: Greg KH @ 2006-02-13 17:50 UTC (permalink / raw) To: Olivier Galibert, linux-kernel On Mon, Feb 13, 2006 at 05:49:11PM +0100, Olivier Galibert wrote: > On Sun, Feb 12, 2006 at 10:24:12PM -0800, Greg KH wrote: > > On Sun, Feb 12, 2006 at 10:14:06PM +0100, Olivier Galibert wrote: > > > On Sun, Feb 12, 2006 at 08:46:33AM -0800, Greg KH wrote: > > > > On Sun, Feb 12, 2006 at 01:04:51PM +0100, Olivier Galibert wrote: > > > > > You need to call udevinfo for that, or parse /dev/.udev/*. Do you > > > > > think it would be possible to have hotplug/udev/whatever exists in the > > > > > future to give that information back in the kernel and have it appear > > > > > in sysfs? > > > > > > > > No. Why would it when it is very simple to query udevinfo for that? > > > > > > In order not to depend on a userland package for the kernel service of > > > device enumeration? It's udevinfo now, what will it be in two years? > > > > WTF? You are depending on that same program to create your device > > nodes. If you don't want to use that program to do it, then use > > something else, or use a static device tree, which works like always. > > Funnily enough, my, say, mp3 usb key sync system would like to run as > non-root and does not want to know or care about what program creates > the device nodes. Too bad this otherwise beautiful and useful sysfs > is crippled by design. Huh? What sysfs design flaw is that? You can run your mp3 usb ksy sync system as non-root just fine, I do just that. When my device is plugged in, a udev rule runs a script that changes users and resyncs my device. But that has nothing to do with sysfs at all. > > sysfs exports everything that userspace needs to know, if it wants to > > create a device node to talk to that specific device. udev used it to > > create your /dev tree, while other programs use it to create temporary > > device nodes to do other things to your devices. Either way, the kernel > > doesn't know, or care what you call those device nodes. > > You mean root is mandatory to talk with devices, whatever they are? Not at all. You only have to be root to create a device node, nothing new there. thanks, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 23:56 ` Greg KH 2006-02-12 12:04 ` Olivier Galibert @ 2006-02-13 5:01 ` Daniel Barkalow 2006-02-13 6:21 ` Greg KH 2006-02-13 13:26 ` Joerg Schilling 2 siblings, 1 reply; 717+ messages in thread From: Daniel Barkalow @ 2006-02-13 5:01 UTC (permalink / raw) To: Greg KH; +Cc: Bill Davidsen, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Fri, 10 Feb 2006, Greg KH wrote: > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > > > The kernel could provide a list of devices by category. It doesn't have > > to name them, run scripts, give descriptions, or paint them blue. Just a > > list of all block devices, tapes, by major/minor and category (ie. > > block, optical, floppy) would give the application layer a chance to do > > it's own interpretation. > > It does so today in sysfs, that is what it is there for. sysfs doesn't do quite that level of categorization; if it did, cdrom_id would be unnecessary. It would be nice if you could do "grep 1 /sys/block/*/burns_cds" and get a list of all the block devices in your system that burn cds. (You can currently get a list of all of the removable block devices in your system, but not much else.) The kernel must know a bunch of this sort of stuff, and it would be nice if the information available. (In fact, there's a lot that's in /proc/ide that isn't in /sys, which is a bit annoying, since it would be useful in /sys, especially if it would mean that you could ignore details of what kind of bus things were on.) -Daniel ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 5:01 ` Daniel Barkalow @ 2006-02-13 6:21 ` Greg KH 2006-02-13 8:05 ` Daniel Barkalow 0 siblings, 1 reply; 717+ messages in thread From: Greg KH @ 2006-02-13 6:21 UTC (permalink / raw) To: Daniel Barkalow Cc: Bill Davidsen, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote: > On Fri, 10 Feb 2006, Greg KH wrote: > > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > > > > > The kernel could provide a list of devices by category. It doesn't have > > > to name them, run scripts, give descriptions, or paint them blue. Just a > > > list of all block devices, tapes, by major/minor and category (ie. > > > block, optical, floppy) would give the application layer a chance to do > > > it's own interpretation. > > > > It does so today in sysfs, that is what it is there for. > > sysfs doesn't do quite that level of categorization; if it did, cdrom_id > would be unnecessary. What? cdrom_id queries the device directly to get some specific information about the device, much like any other type of device query (lspci, lsusb, etc.) And yes, it would be nice if some of that information was also exported through sysfs, and as always, patches are gladly accpeted. > It would be nice if you could do > "grep 1 /sys/block/*/burns_cds" and get a list of all the block devices in > your system that burn cds. (You can currently get a list of all of the > removable block devices in your system, but not much else.) Well, I can see if they are disks or cdroms through sysfs quite easily, removable or not, so you do get more information than you expect. > The kernel must know a bunch of this sort of stuff, and it would be nice > if the information available. (In fact, there's a lot that's in /proc/ide > that isn't in /sys, which is a bit annoying, since it would be useful in > /sys, especially if it would mean that you could ignore details of what > kind of bus things were on.) I agree, again, feel free to submit patches. thanks, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 6:21 ` Greg KH @ 2006-02-13 8:05 ` Daniel Barkalow 2006-02-13 17:51 ` Greg KH 0 siblings, 1 reply; 717+ messages in thread From: Daniel Barkalow @ 2006-02-13 8:05 UTC (permalink / raw) To: Greg KH; +Cc: Bill Davidsen, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Sun, 12 Feb 2006, Greg KH wrote: > On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote: > > sysfs doesn't do quite that level of categorization; if it did, cdrom_id > > would be unnecessary. > > What? cdrom_id queries the device directly to get some specific > information about the device, much like any other type of device query > (lspci, lsusb, etc.) > > And yes, it would be nice if some of that information was also exported > through sysfs, and as always, patches are gladly accpeted. Are there guidelines on having a generic cdrom export information from its block interface, rather than through its bus? I'm not finding any documentation of sys/block/, aside from that it exists. > > It would be nice if you could do > > "grep 1 /sys/block/*/burns_cds" and get a list of all the block devices in > > your system that burn cds. (You can currently get a list of all of the > > removable block devices in your system, but not much else.) > > Well, I can see if they are disks or cdroms through sysfs quite easily, > removable or not, so you do get more information than you expect. Ah, okay, this is in the current -rcs. I was only looking at 2.6.15 (and before), which is too old. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 8:05 ` Daniel Barkalow @ 2006-02-13 17:51 ` Greg KH 2006-02-13 18:03 ` Dmitry Torokhov 0 siblings, 1 reply; 717+ messages in thread From: Greg KH @ 2006-02-13 17:51 UTC (permalink / raw) To: Daniel Barkalow Cc: Bill Davidsen, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Mon, Feb 13, 2006 at 03:05:49AM -0500, Daniel Barkalow wrote: > On Sun, 12 Feb 2006, Greg KH wrote: > > > On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote: > > > sysfs doesn't do quite that level of categorization; if it did, cdrom_id > > > would be unnecessary. > > > > What? cdrom_id queries the device directly to get some specific > > information about the device, much like any other type of device query > > (lspci, lsusb, etc.) > > > > And yes, it would be nice if some of that information was also exported > > through sysfs, and as always, patches are gladly accpeted. > > Are there guidelines on having a generic cdrom export information from its > block interface, rather than through its bus? I'm not finding any > documentation of sys/block/, aside from that it exists. That information should go into the device directory, not the sys/block directory (as it referrs to the device attributes, not the block gendev attributes.) thanks, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 17:51 ` Greg KH @ 2006-02-13 18:03 ` Dmitry Torokhov 2006-02-13 19:09 ` Daniel Barkalow 0 siblings, 1 reply; 717+ messages in thread From: Dmitry Torokhov @ 2006-02-13 18:03 UTC (permalink / raw) To: Greg KH Cc: Daniel Barkalow, Bill Davidsen, Nix, Jens Axboe, Joerg Schilling, linux-kernel On 2/13/06, Greg KH <greg@kroah.com> wrote: > On Mon, Feb 13, 2006 at 03:05:49AM -0500, Daniel Barkalow wrote: > > On Sun, 12 Feb 2006, Greg KH wrote: > > > > > On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote: > > > > sysfs doesn't do quite that level of categorization; if it did, cdrom_id > > > > would be unnecessary. > > > > > > What? cdrom_id queries the device directly to get some specific > > > information about the device, much like any other type of device query > > > (lspci, lsusb, etc.) > > > > > > And yes, it would be nice if some of that information was also exported > > > through sysfs, and as always, patches are gladly accpeted. > > > > Are there guidelines on having a generic cdrom export information from its > > block interface, rather than through its bus? I'm not finding any > > documentation of sys/block/, aside from that it exists. > > That information should go into the device directory, not the sys/block > directory (as it referrs to the device attributes, not the block gendev > attributes.) > Not necessarily - it would be easier for userspace programs if we had a separate class in sysfs - /sys/class/cdrom. The problem with this approach is that we do not allow a device belong o several classes without introducing intermediate class devices (I mean a DVD+RW shoudl probably belong to classes cdrom, dvdrom, cdwriter and dvdwriter). -- Dmitry ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 18:03 ` Dmitry Torokhov @ 2006-02-13 19:09 ` Daniel Barkalow 2006-02-17 21:35 ` Bill Davidsen 0 siblings, 1 reply; 717+ messages in thread From: Daniel Barkalow @ 2006-02-13 19:09 UTC (permalink / raw) To: dtor_core Cc: Greg KH, Bill Davidsen, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Mon, 13 Feb 2006, Dmitry Torokhov wrote: > On 2/13/06, Greg KH <greg@kroah.com> wrote: > > On Mon, Feb 13, 2006 at 03:05:49AM -0500, Daniel Barkalow wrote: > > > Are there guidelines on having a generic cdrom export information from its > > > block interface, rather than through its bus? I'm not finding any > > > documentation of sys/block/, aside from that it exists. > > > > That information should go into the device directory, not the sys/block > > directory (as it referrs to the device attributes, not the block gendev > > attributes.) > > > > Not necessarily - it would be easier for userspace programs if we had > a separate class in sysfs - /sys/class/cdrom. The problem with this > approach is that we do not allow a device belong o several classes > without introducing intermediate class devices (I mean a DVD+RW shoudl > probably belong to classes cdrom, dvdrom, cdwriter and dvdwriter). I don't think it needs to be a class, but I think that there should be a single place with a directory for each device that could be what you want, with a file that tells you if it is. That's why I was looking at block/; these things must be block devices, and there aren't an huge number of block devices. I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I hadn't dug far enough in to realize that the reason I wasn't seeing anything informative in /sys/block/*/device/ was that I didn't have any devices with informative drivers, not that it was actually supposed to only have links to other things. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 19:09 ` Daniel Barkalow @ 2006-02-17 21:35 ` Bill Davidsen 2006-02-18 0:02 ` D. Hazelton ` (2 more replies) 0 siblings, 3 replies; 717+ messages in thread From: Bill Davidsen @ 2006-02-17 21:35 UTC (permalink / raw) To: Daniel Barkalow; +Cc: Greg KH, Nix, Jens Axboe, Joerg Schilling, linux-kernel Daniel Barkalow wrote: > I don't think it needs to be a class, but I think that there should be a > single place with a directory for each device that could be what you want, > with a file that tells you if it is. That's why I was looking at block/; > these things must be block devices, and there aren't an huge number of > block devices. > > I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I hadn't > dug far enough in to realize that the reason I wasn't seeing anything > informative in /sys/block/*/device/ was that I didn't have any devices > with informative drivers, not that it was actually supposed to only have > links to other things. It would be nice to have one place to go to find burners, and to have the model information in that place. I would logically think that place is sysfs, and I know the kernel has the information because if I root through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can eventually find out what the system has connected. I not entirely sure about having classes other than cdrom, just because we already have CD, DVD, DVD-DL, and are about to add blue-ray and HD-DVD, so if I can tell that it's a removable device which can read CDs, the applications have a fighting chance to looking at the device to see what it is. As a human I would like the model information because the kernel has done the work, why should people have to chase it when it could be in one place? -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 21:35 ` Bill Davidsen @ 2006-02-18 0:02 ` D. Hazelton 2006-02-18 16:56 ` Bill Davidsen 2006-02-18 0:35 ` Greg KH 2006-02-18 12:06 ` Christoph Hellwig 2 siblings, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-18 0:02 UTC (permalink / raw) To: Bill Davidsen Cc: Daniel Barkalow, Greg KH, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Friday 17 February 2006 16:35, Bill Davidsen wrote: > Daniel Barkalow wrote: > > I don't think it needs to be a class, but I think that there should be a > > single place with a directory for each device that could be what you > > want, with a file that tells you if it is. That's why I was looking at > > block/; these things must be block devices, and there aren't an huge > > number of block devices. > > > > I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I > > hadn't dug far enough in to realize that the reason I wasn't seeing > > anything informative in /sys/block/*/device/ was that I didn't have any > > devices with informative drivers, not that it was actually supposed to > > only have links to other things. > > It would be nice to have one place to go to find burners, and to have > the model information in that place. I would logically think that place > is sysfs, and I know the kernel has the information because if I root > through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can > eventually find out what the system has connected. > > I not entirely sure about having classes other than cdrom, just because > we already have CD, DVD, DVD-DL, and are about to add blue-ray and > HD-DVD, so if I can tell that it's a removable device which can read > CDs, the applications have a fighting chance to looking at the device to > see what it is. As a human I would like the model information because > the kernel has done the work, why should people have to chase it when it > could be in one place? The problem is that drives don't always cleanly report what they are in a simple to access format. All SCSI and ATAPI drives provide a model, manufacturer and serial number but usually the type of drive is buried within the Model field, and that has a lot of variations. (I have personally seen CD/CDRW, CD-ROM, CD-RW, CDR, CDRW and DVD/CDROM) Now what could be done is that said information could be exported to sysfs. Given the time I could probably manage the patch myself, but I'm currently overextended with the number of projects I have underway. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 0:02 ` D. Hazelton @ 2006-02-18 16:56 ` Bill Davidsen 2006-02-19 0:29 ` D. Hazelton 0 siblings, 1 reply; 717+ messages in thread From: Bill Davidsen @ 2006-02-18 16:56 UTC (permalink / raw) To: D. Hazelton Cc: Daniel Barkalow, Greg KH, Nix, Jens Axboe, Joerg Schilling, linux-kernel D. Hazelton wrote: >On Friday 17 February 2006 16:35, Bill Davidsen wrote: > > >>Daniel Barkalow wrote: >> >> >>>I don't think it needs to be a class, but I think that there should be a >>>single place with a directory for each device that could be what you >>>want, with a file that tells you if it is. That's why I was looking at >>>block/; these things must be block devices, and there aren't an huge >>>number of block devices. >>> >>>I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I >>>hadn't dug far enough in to realize that the reason I wasn't seeing >>>anything informative in /sys/block/*/device/ was that I didn't have any >>>devices with informative drivers, not that it was actually supposed to >>>only have links to other things. >>> >>> >>It would be nice to have one place to go to find burners, and to have >>the model information in that place. I would logically think that place >>is sysfs, and I know the kernel has the information because if I root >>through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can >>eventually find out what the system has connected. >> >>I not entirely sure about having classes other than cdrom, just because >>we already have CD, DVD, DVD-DL, and are about to add blue-ray and >>HD-DVD, so if I can tell that it's a removable device which can read >>CDs, the applications have a fighting chance to looking at the device to >>see what it is. As a human I would like the model information because >>the kernel has done the work, why should people have to chase it when it >>could be in one place? >> >> > >The problem is that drives don't always cleanly report what they are in a >simple to access format. All SCSI and ATAPI drives provide a model, >manufacturer and serial number but usually the type of drive is buried within >the Model field, and that has a lot of variations. > >(I have personally seen CD/CDRW, CD-ROM, CD-RW, CDR, CDRW and DVD/CDROM) > >Now what could be done is that said information could be exported to sysfs. >Given the time I could probably manage the patch myself, but I'm currently >overextended with the number of projects I have underway. > I would think that the model, manufacturer and serial would be useful, and just the indication that the device was CD capable would be a huge gain. There are at least two more type of drive coming soon in the 25GB media race, so identification could legitimately be left to the application as long as all CD-like devices can easily be identified for examination. Does that fit with your level of available time (and interest in resolving this issue)? -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 16:56 ` Bill Davidsen @ 2006-02-19 0:29 ` D. Hazelton 0 siblings, 0 replies; 717+ messages in thread From: D. Hazelton @ 2006-02-19 0:29 UTC (permalink / raw) To: Bill Davidsen Cc: Daniel Barkalow, Greg KH, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Saturday 18 February 2006 11:56, Bill Davidsen wrote: > D. Hazelton wrote: > >On Friday 17 February 2006 16:35, Bill Davidsen wrote: > >>Daniel Barkalow wrote: > >>>I don't think it needs to be a class, but I think that there should be a > >>>single place with a directory for each device that could be what you > >>>want, with a file that tells you if it is. That's why I was looking at > >>>block/; these things must be block devices, and there aren't an huge > >>>number of block devices. > >>> > >>>I suppose "grep 1 /sys/block/*/device/dvdwriter" is just as good; I > >>>hadn't dug far enough in to realize that the reason I wasn't seeing > >>>anything informative in /sys/block/*/device/ was that I didn't have any > >>>devices with informative drivers, not that it was actually supposed to > >>>only have links to other things. > >> > >>It would be nice to have one place to go to find burners, and to have > >>the model information in that place. I would logically think that place > >>is sysfs, and I know the kernel has the information because if I root > >>through /proc/bus/usb and /proc/scsi/scsi, and /proc/ide/hd?/model I can > >>eventually find out what the system has connected. > >> > >>I not entirely sure about having classes other than cdrom, just because > >>we already have CD, DVD, DVD-DL, and are about to add blue-ray and > >>HD-DVD, so if I can tell that it's a removable device which can read > >>CDs, the applications have a fighting chance to looking at the device to > >>see what it is. As a human I would like the model information because > >>the kernel has done the work, why should people have to chase it when it > >>could be in one place? > > > >The problem is that drives don't always cleanly report what they are in a > >simple to access format. All SCSI and ATAPI drives provide a model, > >manufacturer and serial number but usually the type of drive is buried > > within the Model field, and that has a lot of variations. > > > >(I have personally seen CD/CDRW, CD-ROM, CD-RW, CDR, CDRW and DVD/CDROM) > > > >Now what could be done is that said information could be exported to > > sysfs. Given the time I could probably manage the patch myself, but I'm > > currently overextended with the number of projects I have underway. > > I would think that the model, manufacturer and serial would be useful, > and just the indication that the device was CD capable would be a huge > gain. There are at least two more type of drive coming soon in the 25GB > media race, so identification could legitimately be left to the > application as long as all CD-like devices can easily be identified for > examination. > > Does that fit with your level of available time (and interest in > resolving this issue)? seems straightforward enough. May take me a bit, since I'll need to see what has to be done in order to make the information necessary, but I think it could all be resolved with calls to the routines the ioctl's normally access. DRH (and I think that theres even more information available, from the capabilities mode page, but I'm unsure as to how to access that) ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 21:35 ` Bill Davidsen 2006-02-18 0:02 ` D. Hazelton @ 2006-02-18 0:35 ` Greg KH 2006-02-18 12:06 ` Christoph Hellwig 2 siblings, 0 replies; 717+ messages in thread From: Greg KH @ 2006-02-18 0:35 UTC (permalink / raw) To: Bill Davidsen Cc: Daniel Barkalow, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote: > I not entirely sure about having classes other than cdrom, just because > we already have CD, DVD, DVD-DL, and are about to add blue-ray and > HD-DVD, so if I can tell that it's a removable device which can read > CDs, the applications have a fighting chance to looking at the device to > see what it is. As a human I would like the model information because > the kernel has done the work, why should people have to chase it when it > could be in one place? Sure, I don't object to that at all, as long as you can detect this kind of information easily from within the kernel. thanks, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-17 21:35 ` Bill Davidsen 2006-02-18 0:02 ` D. Hazelton 2006-02-18 0:35 ` Greg KH @ 2006-02-18 12:06 ` Christoph Hellwig 2006-02-18 13:37 ` Martin Michlmayr ` (2 more replies) 2 siblings, 3 replies; 717+ messages in thread From: Christoph Hellwig @ 2006-02-18 12:06 UTC (permalink / raw) To: Bill Davidsen Cc: Daniel Barkalow, Greg KH, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote: > It would be nice to have one place to go to find burners, and to have > the model information in that place. /proc/sys/dev/cdrom/info ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 12:06 ` Christoph Hellwig @ 2006-02-18 13:37 ` Martin Michlmayr 2006-02-18 13:52 ` Christoph Hellwig 2006-02-18 17:15 ` Gene Heskett 2006-02-18 18:36 ` Chris Adams 2 siblings, 1 reply; 717+ messages in thread From: Martin Michlmayr @ 2006-02-18 13:37 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-kernel * Christoph Hellwig <hch@infradead.org> [2006-02-18 12:06]: > > It would be nice to have one place to go to find burners, and to have > > the model information in that place. > /proc/sys/dev/cdrom/info Nice. Is that a stable interface people can rely on (seems this me it should rather be in sys)? I maintain a tool in Debian to rip/encode audio CDs with one command and we could use this file to find the CD interface if it's not specified by the user. -- Martin Michlmayr tbm@cyrius.com ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 13:37 ` Martin Michlmayr @ 2006-02-18 13:52 ` Christoph Hellwig 2006-02-19 12:04 ` Jens Axboe 0 siblings, 1 reply; 717+ messages in thread From: Christoph Hellwig @ 2006-02-18 13:52 UTC (permalink / raw) To: Martin Michlmayr, axboe; +Cc: linux-kernel On Sat, Feb 18, 2006 at 01:37:15PM +0000, Martin Michlmayr wrote: > * Christoph Hellwig <hch@infradead.org> [2006-02-18 12:06]: > > > It would be nice to have one place to go to find burners, and to have > > > the model information in that place. > > /proc/sys/dev/cdrom/info > > Nice. Is that a stable interface people can rely on (seems this me it > should rather be in sys)? I maintain a tool in Debian to rip/encode > audio CDs with one command and we could use this file to find the CD > interface if it's not specified by the user. I think it's pretty stable. Except for adding new capabilities it's been unchanged since the 2.2.x days. Maybe Jens can comment more on it? ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 13:52 ` Christoph Hellwig @ 2006-02-19 12:04 ` Jens Axboe 0 siblings, 0 replies; 717+ messages in thread From: Jens Axboe @ 2006-02-19 12:04 UTC (permalink / raw) To: Christoph Hellwig, Martin Michlmayr, linux-kernel On Sat, Feb 18 2006, Christoph Hellwig wrote: > On Sat, Feb 18, 2006 at 01:37:15PM +0000, Martin Michlmayr wrote: > > * Christoph Hellwig <hch@infradead.org> [2006-02-18 12:06]: > > > > It would be nice to have one place to go to find burners, and to have > > > > the model information in that place. > > > /proc/sys/dev/cdrom/info > > > > Nice. Is that a stable interface people can rely on (seems this me it > > should rather be in sys)? I maintain a tool in Debian to rip/encode > > audio CDs with one command and we could use this file to find the CD > > interface if it's not specified by the user. > > I think it's pretty stable. Except for adding new capabilities it's been > unchanged since the 2.2.x days. > > Maybe Jens can comment more on it? Yeah it's stable, new entries have been added at the end if necessary. I don't necessarily think it's a super way to find these things out, sometimes older SCSI drives fail some of the mode sense / capability probing and don't show correct values. So one could do better in user space. But at least it's a generic way to see which devices have been registered as CDROM's, if that is the goal. -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 12:06 ` Christoph Hellwig 2006-02-18 13:37 ` Martin Michlmayr @ 2006-02-18 17:15 ` Gene Heskett 2006-02-19 0:41 ` D. Hazelton 2006-02-19 18:50 ` Daniel Barkalow 2006-02-18 18:36 ` Chris Adams 2 siblings, 2 replies; 717+ messages in thread From: Gene Heskett @ 2006-02-18 17:15 UTC (permalink / raw) To: Christoph Hellwig, Bill Davidsen, Daniel Barkalow, Greg KH, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Saturday 18 February 2006 07:06, Christoph Hellwig wrote: cat /proc/sys/dev/cdrom/info CD-ROM information, Id: cdrom.c 3.20 2003/12/17 drive name: hdc drive speed: 48 drive # of slots: 1 Can close tray: 1 Can open tray: 1 Can lock tray: 1 Can change speed: 1 Can select disk: 0 Can read multisession: 1 Can read MCN: 1 Reports media changed: 1 Can play audio: 1 Can write CD-R: 1 Can write CD-RW: 1 Can read DVD: 1 Can write DVD-R: 1 Can write DVD-RAM: 0 Can read MRW: 1 Can write MRW: 1 Can write RAM: 1 But I fail to see where this would help to 'find' the right device to write to, other than the obvious prefixing of '/dev/' to $drive name. We already knew that, and in fact it works very well. Please explain to Joerg in one syllable words he might, if he wanted to, understand. Also, I'm fuzzy about the last 3, so defining those might help me understand. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 17:15 ` Gene Heskett @ 2006-02-19 0:41 ` D. Hazelton 2006-02-19 5:44 ` Gene Heskett 2006-02-19 9:27 ` Matthias Andree 2006-02-19 18:50 ` Daniel Barkalow 1 sibling, 2 replies; 717+ messages in thread From: D. Hazelton @ 2006-02-19 0:41 UTC (permalink / raw) To: Gene Heskett Cc: Christoph Hellwig, Bill Davidsen, Daniel Barkalow, Greg KH, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Saturday 18 February 2006 12:15, Gene Heskett wrote: > On Saturday 18 February 2006 07:06, Christoph Hellwig wrote: > > cat /proc/sys/dev/cdrom/info > CD-ROM information, Id: cdrom.c 3.20 2003/12/17 > > drive name: hdc > drive speed: 48 > drive # of slots: 1 > Can close tray: 1 > Can open tray: 1 > Can lock tray: 1 > Can change speed: 1 > Can select disk: 0 > Can read multisession: 1 > Can read MCN: 1 > Reports media changed: 1 > Can play audio: 1 > Can write CD-R: 1 > Can write CD-RW: 1 > Can read DVD: 1 > Can write DVD-R: 1 > Can write DVD-RAM: 0 > Can read MRW: 1 > Can write MRW: 1 > Can write RAM: 1 Ah, so it does already exist. Only thing left might be to stick the manufacturer, serial and misc. data into sysfs > But I fail to see where this would help to 'find' the right device to > write to, other than the obvious prefixing of '/dev/' to $drive name. > We already knew that, and in fact it works very well. Please explain to > Joerg in one syllable words he might, if he wanted to, understand. Well, in this case I'm actually trying to work with Joerg to produce a patch that unifies the ATAPI and SCSI busses inside his program. One thing this does is help to locate available drives. Negates the need to scan the entire ATA/ATAPI bus for drives. However, since, as Joerg has pointed out, libscg is a generic SCSI system, it doesn't negate it's need to scan the entire SCSI bus. It's use as a backend to cdrecord is incidental in this case. > Also, I'm fuzzy about the last 3, so defining those might help me > understand. I've seen the "MRW" stuff in some of the specs, but had to check the net to find out what it was. MRW is the Mt. Rainier format - basic support was added by Jens back in 2.4.19 according to the archives. (http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html) I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM type discs DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-19 0:41 ` D. Hazelton @ 2006-02-19 5:44 ` Gene Heskett 2006-02-19 9:27 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Gene Heskett @ 2006-02-19 5:44 UTC (permalink / raw) To: linux-kernel On Saturday 18 February 2006 19:41, D. Hazelton wrote: >On Saturday 18 February 2006 12:15, Gene Heskett wrote: >> On Saturday 18 February 2006 07:06, Christoph Hellwig wrote: >> >> cat /proc/sys/dev/cdrom/info >> CD-ROM information, Id: cdrom.c 3.20 2003/12/17 >> >> drive name: hdc >> drive speed: 48 >> drive # of slots: 1 >> Can close tray: 1 >> Can open tray: 1 >> Can lock tray: 1 >> Can change speed: 1 >> Can select disk: 0 >> Can read multisession: 1 >> Can read MCN: 1 >> Reports media changed: 1 >> Can play audio: 1 >> Can write CD-R: 1 >> Can write CD-RW: 1 >> Can read DVD: 1 >> Can write DVD-R: 1 >> Can write DVD-RAM: 0 >> Can read MRW: 1 >> Can write MRW: 1 >> Can write RAM: 1 > >Ah, so it does already exist. Only thing left might be to stick the >manufacturer, serial and misc. data into sysfs > >> But I fail to see where this would help to 'find' the right device >> to write to, other than the obvious prefixing of '/dev/' to $drive >> name. We already knew that, and in fact it works very well. Please >> explain to Joerg in one syllable words he might, if he wanted to, >> understand. > >Well, in this case I'm actually trying to work with Joerg to produce a > patch that unifies the ATAPI and SCSI busses inside his program. One > thing this does is help to locate available drives. Negates the need > to scan the entire ATA/ATAPI bus for drives. However, since, as Joerg > has pointed out, libscg is a generic SCSI system, it doesn't negate > it's need to scan the entire SCSI bus. It's use as a backend to > cdrecord is incidental in this case. Working with Joerg? sigh >> Also, I'm fuzzy about the last 3, so defining those might help me >> understand. > >I've seen the "MRW" stuff in some of the specs, but had to check the > net to find out what it was. MRW is the Mt. Rainier format - basic > support was added by Jens back in 2.4.19 according to the archives. >(http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html) > >I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM > type discs That sounds like it makes sense, thanks. I bought a spindle of rewritable dvd's, thinking about doing backups, but a 200GB drive and vtapes got in the way and its beaucoupe more convienient and speedy that the dvd's will ever be. Once setup, it Just Works(TM). That drive has since went belly up & been replaced with another that seems even more solid, liteon of course. >DRH Thanks -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-19 0:41 ` D. Hazelton 2006-02-19 5:44 ` Gene Heskett @ 2006-02-19 9:27 ` Matthias Andree 2006-02-27 20:23 ` Bill Davidsen 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-19 9:27 UTC (permalink / raw) To: D. Hazelton Cc: Gene Heskett, Christoph Hellwig, Bill Davidsen, Daniel Barkalow, Greg KH, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Sat, 18 Feb 2006, D. Hazelton wrote: > Well, in this case I'm actually trying to work with Joerg to produce a patch > that unifies the ATAPI and SCSI busses inside his program. This patch already exists, see: <http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html> It's a proof of concept and needs to be polished (I'll look into that again in March). Only it still probes all /dev/hd and /dev/sg and /dev/pg in a dumb way, rather than looking at sysfs or reading through /dev/. > I've seen the "MRW" stuff in some of the specs, but had to check the net to > find out what it was. MRW is the Mt. Rainier format - basic support was added > by Jens back in 2.4.19 according to the archives. > (http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html) > > I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM type > discs That's probably not it, since there's a separate DVD-RAM line here: CD-ROM information, Id: cdrom.c 3.20 2003/12/17 drive name: hdd hdc sr0 drive speed: 40 48 1 drive # of slots: 1 1 1 Can close tray: 1 1 1 Can open tray: 1 1 1 Can lock tray: 1 1 1 Can change speed: 1 1 0 Can select disk: 0 0 0 Can read multisession: 1 1 1 Can read MCN: 1 1 1 Reports media changed: 1 1 1 Can play audio: 1 1 1 Can write CD-R: 1 1 0 Can write CD-RW: 1 1 0 Can read DVD: 0 1 0 Can write DVD-R: 0 1 0 Can write DVD-RAM: 0 1 0 Can read MRW: 1 1 1 Can write MRW: 1 1 1 Can write RAM: 1 1 1 hdd = Plextor PX-W4824TA hdc = NEC ND-4550A sr0 = Plextor PX-32TS (Now NEC only needs to teach their drives to be more error tolerant when reading and adjust their read speed to the actual sustained transfer rate as Toshiba drives have been doing for ages...) -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-19 9:27 ` Matthias Andree @ 2006-02-27 20:23 ` Bill Davidsen 0 siblings, 0 replies; 717+ messages in thread From: Bill Davidsen @ 2006-02-27 20:23 UTC (permalink / raw) To: Linux Kernel Mailing List Matthias Andree wrote: > On Sat, 18 Feb 2006, D. Hazelton wrote: > >> Well, in this case I'm actually trying to work with Joerg to produce a patch >> that unifies the ATAPI and SCSI busses inside his program. > > This patch already exists, see: > <http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/1103.html> > > It's a proof of concept and needs to be polished (I'll look into that > again in March). > > Only it still probes all /dev/hd and /dev/sg and /dev/pg in a dumb way, > rather than looking at sysfs or reading through /dev/. > >> I've seen the "MRW" stuff in some of the specs, but had to check the net to >> find out what it was. MRW is the Mt. Rainier format - basic support was added >> by Jens back in 2.4.19 according to the archives. >> (http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1214.html) >> >> I'm not positive, but the "Can Read RAM" line might refer to DVD-RAM type >> discs > > That's probably not it, since there's a separate DVD-RAM line here: > > CD-ROM information, Id: cdrom.c 3.20 2003/12/17 > > drive name: hdd hdc sr0 > drive speed: 40 48 1 > drive # of slots: 1 1 1 > Can close tray: 1 1 1 > Can open tray: 1 1 1 > Can lock tray: 1 1 1 > Can change speed: 1 1 0 > Can select disk: 0 0 0 > Can read multisession: 1 1 1 > Can read MCN: 1 1 1 > Reports media changed: 1 1 1 > Can play audio: 1 1 1 > Can write CD-R: 1 1 0 > Can write CD-RW: 1 1 0 > Can read DVD: 0 1 0 > Can write DVD-R: 0 1 0 > Can write DVD-RAM: 0 1 0 > Can read MRW: 1 1 1 > Can write MRW: 1 1 1 > Can write RAM: 1 1 1 > > hdd = Plextor PX-W4824TA > hdc = NEC ND-4550A > sr0 = Plextor PX-32TS Other than my 2.6.15 not producing those last three lines, looks good. The names are those in /sys, which of course many distros change in udev to make things hard for the user. Hard t write an app portably to cope with /dev/scd0, /dev/sr0, /dev/cdroms/sr0, etc. I am NOT suggesting changing a stable interface, but this really should be in /sys I would think. It would be nice to have the major/minor and model info, so programs could find the "better" named in /dev or just mknod their own. > > (Now NEC only needs to teach their drives to be more error tolerant when > reading and adjust their read speed to the actual sustained transfer > rate as Toshiba drives have been doing for ages...) > This would appear to be almost all the user needs to at least find the devices. I don't know why no one mentioned it several years ago. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 17:15 ` Gene Heskett 2006-02-19 0:41 ` D. Hazelton @ 2006-02-19 18:50 ` Daniel Barkalow 1 sibling, 0 replies; 717+ messages in thread From: Daniel Barkalow @ 2006-02-19 18:50 UTC (permalink / raw) To: Gene Heskett Cc: Christoph Hellwig, Bill Davidsen, Greg KH, Nix, Jens Axboe, Joerg Schilling, linux-kernel On Sat, 18 Feb 2006, Gene Heskett wrote: > But I fail to see where this would help to 'find' the right device to > write to, other than the obvious prefixing of '/dev/' to $drive name. > We already knew that, and in fact it works very well. Please explain to > Joerg in one syllable words he might, if he wanted to, understand. Honestly, the right thing for Joerg is /dev/cdrom or /dev/cdroms/*. The principle ought to be that something in userspace will talk to the kernel and produce a /dev structure containing names the user will recognize. (FWIW, /dev/cdrom has worked on every Linux machine I've had since my first system 10 years ago, but I've heard of people having multiple drives.) Probably the right thing for getting the user to really know which thing is which is to have a configuration program that configures udev by listing all the devices that go through cdrom.c, giving some info about them, letting the user open the tray on them (to distinguish identical devices), and having the user give each a name, which then appears in /dev/cdroms (by reconfiguring udev). All of the detailed info from the kernel should go to the system configuration utility, not to cdrecord, which shouldn't need it, because either the default drive (/dev/cdrom) or the drive from /dev/cdroms that the user specifies will be right. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 12:06 ` Christoph Hellwig 2006-02-18 13:37 ` Martin Michlmayr 2006-02-18 17:15 ` Gene Heskett @ 2006-02-18 18:36 ` Chris Adams 2006-02-19 1:05 ` D. Hazelton 2006-02-27 20:24 ` Bill Davidsen 2 siblings, 2 replies; 717+ messages in thread From: Chris Adams @ 2006-02-18 18:36 UTC (permalink / raw) To: linux-kernel Once upon a time, Christoph Hellwig <hch@infradead.org> said: >On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote: >> It would be nice to have one place to go to find burners, and to have >> the model information in that place. > >/proc/sys/dev/cdrom/info Which is bad, as it is incomplete and requires the kernel be updated to know about every format just to document them. Problems with that file: - What is "drive speed" (no units); also most drives do different speeds for different modes/media. - CD-RW really covers a range of different formats ("high speed" CD-RW is different and IIRC there's also "ultra high speed" CD-RW). - Several formats are missing: DVD-RW DVD+R DVD+RW DVD-DL DVD+DL (at least). - What is the "RAM" format (not "DVD-RAM")? I haven't heard of that. The kernel really only needs to know: - how the drive can control the tray (open/close/lock/change disc) - if the drive can handle rewritable formats (for UDF support) Alternately, every known format needs to be added to that file (both read and write support). It also needs to note read and write speeds for each available format. Also, that is an annoying to parse format. What if there's a really long text column field like "Can write Blu-Ray HD dual layer v2"? Something under /sys would be better with one value per file, so if you want to burn a DVD-R, you look for /sys/block/*/cdinfo/write/dvd-r; maybe that file contains a space separated list of available speeds (so "1 2 4 8"). Also, right now as far as I can see, /sys doesn't present manufacturer, model, and/or serial number info. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 18:36 ` Chris Adams @ 2006-02-19 1:05 ` D. Hazelton 2006-02-27 20:24 ` Bill Davidsen 1 sibling, 0 replies; 717+ messages in thread From: D. Hazelton @ 2006-02-19 1:05 UTC (permalink / raw) To: Chris Adams; +Cc: linux-kernel On Saturday 18 February 2006 13:36, Chris Adams wrote: > Once upon a time, Christoph Hellwig <hch@infradead.org> said: > >On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote: > >> It would be nice to have one place to go to find burners, and to have > >> the model information in that place. > > > >/proc/sys/dev/cdrom/info > > Which is bad, as it is incomplete and requires the kernel be updated to > know about every format just to document them. > > Problems with that file: > > - What is "drive speed" (no units); also most drives do different speeds > for different modes/media. > > - CD-RW really covers a range of different formats ("high speed" CD-RW > is different and IIRC there's also "ultra high speed" CD-RW). > > - Several formats are missing: DVD-RW DVD+R DVD+RW DVD-DL DVD+DL (at > least). > > - What is the "RAM" format (not "DVD-RAM")? I haven't heard of that. > > The kernel really only needs to know: > > - how the drive can control the tray (open/close/lock/change disc) > > - if the drive can handle rewritable formats (for UDF support) > > Alternately, every known format needs to be added to that file (both > read and write support). It also needs to note read and write speeds > for each available format. > > Also, that is an annoying to parse format. What if there's a really > long text column field like "Can write Blu-Ray HD dual layer v2"? > Something under /sys would be better with one value per file, so if you > want to burn a DVD-R, you look for /sys/block/*/cdinfo/write/dvd-r; > maybe that file contains a space separated list of available speeds (so > "1 2 4 8"). Also, right now as far as I can see, /sys doesn't present > manufacturer, model, and/or serial number info. Agreed. Which is why I'll use that file as a basis for the minor bit of work I'll do in adding the capabilities and other information to sysfs. Though I was under the impression that a lot of the device specific information was being moved into sysfs anyway... The reason it just says RAM is because, contrary to my statement in an earlier mail it doesn't mean DVD-RAM, since my CD-RW also has that listed. (and DVD-RAM has it's own slot in the file) I wasn't able to locate information on what that is in the MMC docs, but in this case it might refer to the UDF format. AFAICT the names used there are what are presented by the drive in the capabilities mode page. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 18:36 ` Chris Adams 2006-02-19 1:05 ` D. Hazelton @ 2006-02-27 20:24 ` Bill Davidsen 2006-02-27 21:21 ` Chris Adams 1 sibling, 1 reply; 717+ messages in thread From: Bill Davidsen @ 2006-02-27 20:24 UTC (permalink / raw) To: Linux Kernel Mailing List Chris Adams wrote: > Once upon a time, Christoph Hellwig <hch@infradead.org> said: >> On Fri, Feb 17, 2006 at 04:35:30PM -0500, Bill Davidsen wrote: >>> It would be nice to have one place to go to find burners, and to have >>> the model information in that place. >> /proc/sys/dev/cdrom/info > > Which is bad, as it is incomplete and requires the kernel be updated to > know about every format just to document them. Document them where? In the kernel Documentation directory? I believe those strings come back from the drive, as long as the human or application can parse them the kernel operationally needs only what you mentioned below. > > Problems with that file: The main problem with that file is that it wasn't mentioned several years ago... and I hope you aren't even thinking of suggesting any changes to something which has been around for years and which applications are undoubtedly quietly using. A changed version of the same information in /sys would be a better solution if changes other than some additions are needed. > > - What is "drive speed" (no units); also most drives do different speeds > for different modes/media. Presumably the max speed mechanically possible, in the units of "x" which are used to identify both media and burners and have been since "2x" was the fast burner. > > - CD-RW really covers a range of different formats ("high speed" CD-RW > is different and IIRC there's also "ultra high speed" CD-RW). > > - Several formats are missing: DVD-RW DVD+R DVD+RW DVD-DL DVD+DL (at > least). > > - What is the "RAM" format (not "DVD-RAM")? I haven't heard of that. > > The kernel really only needs to know: > > - how the drive can control the tray (open/close/lock/change disc) > > - if the drive can handle rewritable formats (for UDF support) CD-RW seems to cover that. > > Alternately, every known format needs to be added to that file (both > read and write support). It also needs to note read and write speeds > for each available format. Why? The mmc/scsi commands work or don't, the device returns the info in the capabilities page if the application can use it, so it doesn't seem that the kernel cares, other than the cases you mentioned. > > Also, that is an annoying to parse format. What if there's a really > long text column field like "Can write Blu-Ray HD dual layer v2"? > Something under /sys would be better with one value per file, so if you > want to burn a DVD-R, you look for /sys/block/*/cdinfo/write/dvd-r; Isn't there a problem with having the same device in multiple places? Someone posted that there was, but I didn't really get into the details. In any case, why is opening dozens of files better than opening one file with all of the info. Long names can be abbreviated, complexity in the kernel to avoid complexity in the application is bad, particularly when humans parse the existing format nicely. > maybe that file contains a space separated list of available speeds (so > "1 2 4 8"). Also, right now as far as I can see, /sys doesn't present > manufacturer, model, and/or serial number info. The only applications which care about speeds other than max are already reading the capabilities page. Use cdrecord with the "-prcap" options, there is a boatload of stuff there. I agree the the three text items are useful, and major/minor to map the device to the name actually used in /dev, but that data doesn't fit the format well, and might be better presented in /sys. Preferably in a human readable format, like /proc/scsi/scsi rather than multiple file per device. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-27 20:24 ` Bill Davidsen @ 2006-02-27 21:21 ` Chris Adams 2006-02-27 21:47 ` D. Hazelton 0 siblings, 1 reply; 717+ messages in thread From: Chris Adams @ 2006-02-27 21:21 UTC (permalink / raw) To: linux-kernel Once upon a time, Bill Davidsen <davidsen@tmr.com> said: >> Which is bad, as it is incomplete and requires the kernel be updated to >> know about every format just to document them. > >Document them where? In the kernel Documentation directory? I believe >those strings come back from the drive, as long as the human or >application can parse them the kernel operationally needs only what you >mentioned below. I wasn't aware those strings actually came from the devices. What I meant was if that file is to be the documentation of the drive capabilities, it needs to be updated to list all known capabilities (and be updated promptly when new capabilities are created). It currently has many missing formats. >> - What is "drive speed" (no units); also most drives do different speeds >> for different modes/media. > >Presumably the max speed mechanically possible, in the units of "x" >which are used to identify both media and burners and have been since >"2x" was the fast burner. I've got a burner that has the following burn speeds (from memory): 16x DVD+/-R, 8x DVD+RW, 6x DVD-RW, 4x DVD+/-R DL, 48x CD-R, and 24x CD-RW. I don't even remember what the max read speeds are. Which is the "max"? The 16x DVD speed or the 48x CD speed? Why? The "x" unit is only meaningful with an associated format (since "1x" is different for different formats) and with "read" or "write" specified. Without units, the number is meaningless. >> - if the drive can handle rewritable formats (for UDF support) > >CD-RW seems to cover that. Not for DVD+RW, DVD-RW, and DVD-RAM (which is the only one there). Sometime down the road, HD-DVD and Blu-Ray versions of rewritable will also exist. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-27 21:21 ` Chris Adams @ 2006-02-27 21:47 ` D. Hazelton 2006-02-27 22:30 ` Peter Gordon 0 siblings, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-27 21:47 UTC (permalink / raw) To: Chris Adams; +Cc: linux-kernel On Monday 27 February 2006 16:21, Chris Adams wrote: > Once upon a time, Bill Davidsen <davidsen@tmr.com> said: > >> Which is bad, as it is incomplete and requires the kernel be updated to > >> know about every format just to document them. > > > >Document them where? In the kernel Documentation directory? I believe > >those strings come back from the drive, as long as the human or > >application can parse them the kernel operationally needs only what you > >mentioned below. > > I wasn't aware those strings actually came from the devices. What I > meant was if that file is to be the documentation of the drive > capabilities, it needs to be updated to list all known capabilities (and > be updated promptly when new capabilities are created). It currently > has many missing formats. No, the strings do not come from the drive. Those capabilities, IIRC, are presented as a series of bitflags packed into a 32 bit integer. This is described in the MMC spec for the "capabilities mode page". The drive _does_ supply the information as to what formats it understands, but in this case the kernel translates it into a human readable format. > >> - What is "drive speed" (no units); also most drives do different speeds > >> for different modes/media. > > > >Presumably the max speed mechanically possible, in the units of "x" > >which are used to identify both media and burners and have been since > >"2x" was the fast burner. > > I've got a burner that has the following burn speeds (from memory): 16x > DVD+/-R, 8x DVD+RW, 6x DVD-RW, 4x DVD+/-R DL, 48x CD-R, and 24x CD-RW. > I don't even remember what the max read speeds are. Which is the "max"? > The 16x DVD speed or the 48x CD speed? Why? This value is also reported by the drive. I don't know about DVD drives, but for CD drives it is a multiplier. 1x == 256K/sec transfer off the disc, 52x is 13M/sec transfer off the disc. However, in the case of all discs, all speeds beyond a certain cut-off value (I forget what the number is) the number is "Maximum/Variable" because the polycarbonate the discs are made from will deform and shatter from the centrifugal forces above a certain RPM. (And this I have witness three times myself with a 52x drive and old discs. It's a real bitch to have to take apart a CD drive and clean out the fragments of the disc.) > The "x" unit is only meaningful with an associated format (since "1x" is > different for different formats) and with "read" or "write" specified. > > Without units, the number is meaningless. It's in units as specified by the specification. The redbook spec for CDROM drives states the minimum spin speed for stable reading and that roughly translates to a 256K/sec read rate. I haven't had time to look into the DVD specification, but I'm guessing that the DVD speed is about 3x what the CDROM speed is. > >> - if the drive can handle rewritable formats (for UDF support) > > > >CD-RW seems to cover that. > > Not for DVD+RW, DVD-RW, and DVD-RAM (which is the only one there). > Sometime down the road, HD-DVD and Blu-Ray versions of rewritable will > also exist. Exactly. And these are all covered in the file. And as more formats are added the currently unused bits in the capabilities mode page will come into use. It will, at some point, be used up - and then I have a feeling a new mode page will be introduced so that the current one isn't changed in a way that would break legacy applications. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-27 21:47 ` D. Hazelton @ 2006-02-27 22:30 ` Peter Gordon 2006-02-27 22:24 ` D. Hazelton 0 siblings, 1 reply; 717+ messages in thread From: Peter Gordon @ 2006-02-27 22:30 UTC (permalink / raw) To: D. Hazelton; +Cc: linux-kernel On 2/27/06, D. Hazelton <dhazelton@enter.net> wrote: > This value is also reported by the drive. I don't know about DVD drives, but > for CD drives it is a multiplier. 1x == 256K/sec transfer off the disc [...] For CDs, 1x is actually 150 KByte/sec. > I haven't had time to look into the DVD specification, but I'm guessing that > the DVD speed is about 3x what the CDROM speed is. According to WikiPedia, the DVD speed rating is almost 9 times that of CD speeds. I.e., 1x DVD is about 1.32 MByte/sec. Just to make sure that we're all on the same page. :) ~~Peter ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-27 22:30 ` Peter Gordon @ 2006-02-27 22:24 ` D. Hazelton 2006-02-28 0:44 ` Sam Vilain 0 siblings, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-27 22:24 UTC (permalink / raw) To: Peter Gordon; +Cc: linux-kernel On Monday 27 February 2006 17:30, Peter Gordon wrote: > On 2/27/06, D. Hazelton <dhazelton@enter.net> wrote: > > This value is also reported by the drive. I don't know about DVD drives, > > but for CD drives it is a multiplier. 1x == 256K/sec transfer off the > > disc [...] > > For CDs, 1x is actually 150 KByte/sec. Well, I've been known to be wrong before, and this number was more based on the fact that I once measured a sustained transfer rate of 1M/sec on a 4x CDROM > > I haven't had time to look into the DVD specification, but I'm guessing > > that the DVD speed is about 3x what the CDROM speed is. > > According to WikiPedia, the DVD speed rating is almost 9 times that of > CD speeds. I.e., 1x DVD is about 1.32 MByte/sec. This was based on DVDx16 == CDx48 - I'm guessing someone is doing some monkey work if a DVD is 9x a CD and a 16x DVD can't hit that mystical 52x of my favorite CDRW drive in pure CD read mode. > > Just to make sure that we're all on the same page. :) > ~~Peter Thanks. Was just trying to dispel a few mis-statements and made some myself. I'm grateful for the update to my poor memory. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-27 22:24 ` D. Hazelton @ 2006-02-28 0:44 ` Sam Vilain 0 siblings, 0 replies; 717+ messages in thread From: Sam Vilain @ 2006-02-28 0:44 UTC (permalink / raw) To: D. Hazelton; +Cc: Peter Gordon, linux-kernel D. Hazelton wrote: >>>This value is also reported by the drive. I don't know about DVD drives, >>>but for CD drives it is a multiplier. 1x == 256K/sec transfer off the >>>disc [...] >>For CDs, 1x is actually 150 KByte/sec. > Well, I've been known to be wrong before, and this number was more based on > the fact that I once measured a sustained transfer rate of 1M/sec on a 4x > CDROM Think about audio. Single speed = 75 frames of 2352 bytes per second, or 176kB/s. However with data tracks you only get 2k per frame/sector, so that works out to be 153kB/s. Due to the CLV nature of CD-ROMs you may find the drive is faster reading some parts of the disc than others. >>According to WikiPedia, the DVD speed rating is almost 9 times that of >>CD speeds. I.e., 1x DVD is about 1.32 MByte/sec. > This was based on DVDx16 == CDx48 - I'm guessing someone is doing some monkey > work if a DVD is 9x a CD and a 16x DVD can't hit that mystical 52x of my > favorite CDRW drive in pure CD read mode. You can do a similar calculation with DVDs. While I can't find a reference for the maximum DVD total bitrate of ~10Mbit/s, this at 1.25 MByte/s this roughly agrees with the 1.32 quoted. Sam. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 23:56 ` Greg KH 2006-02-12 12:04 ` Olivier Galibert 2006-02-13 5:01 ` Daniel Barkalow @ 2006-02-13 13:26 ` Joerg Schilling 2006-02-13 15:49 ` Greg KH 2006-02-13 22:14 ` Nix 2 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-13 13:26 UTC (permalink / raw) To: greg, davidsen; +Cc: schilling, nix, linux-kernel, axboe Greg KH <greg@kroah.com> wrote: > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > > > The kernel could provide a list of devices by category. It doesn't have > > to name them, run scripts, give descriptions, or paint them blue. Just a > > list of all block devices, tapes, by major/minor and category (ie. > > block, optical, floppy) would give the application layer a chance to do > > it's own interpretation. > > It does so today in sysfs, that is what it is there for. Do you really whant libscg to open _every_ non-directory file under /sys? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:26 ` Joerg Schilling @ 2006-02-13 15:49 ` Greg KH 2006-02-14 18:59 ` Joerg Schilling ` (3 more replies) 2006-02-13 22:14 ` Nix 1 sibling, 4 replies; 717+ messages in thread From: Greg KH @ 2006-02-13 15:49 UTC (permalink / raw) To: Joerg Schilling; +Cc: davidsen, nix, linux-kernel, axboe On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote: > Greg KH <greg@kroah.com> wrote: > > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > > > > > The kernel could provide a list of devices by category. It doesn't have > > > to name them, run scripts, give descriptions, or paint them blue. Just a > > > list of all block devices, tapes, by major/minor and category (ie. > > > block, optical, floppy) would give the application layer a chance to do > > > it's own interpretation. > > > > It does so today in sysfs, that is what it is there for. > > Do you really whant libscg to open _every_ non-directory file under /sys? Of course not. Here's one line of bash that gets you the major:minor file of every block device in the system: block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)" The block devices are all in a specific location. And here's a way to get the cdroms of the system: media="$(echo /sys/block/*/device/media)" for i in $media; do type="$(cat $i)" if [ "${type}" == "cdrom" ] then # we have a cdrom here, at $media block device fi done If you want to do this in C, there is a libsysfs, which should help you out a bit on intregrating sysfs support into your program (although udev has recently ripped it out and replaced it with 200 lines of code that is way smaller and much faster...) Hope this helps, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:49 ` Greg KH @ 2006-02-14 18:59 ` Joerg Schilling 2006-02-14 19:53 ` Matthias Andree 2006-02-14 22:32 ` D. Hazelton 2006-02-14 18:59 ` Olivier Galibert ` (2 subsequent siblings) 3 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-14 18:59 UTC (permalink / raw) To: schilling, greg; +Cc: nix, linux-kernel, davidsen, axboe Greg KH <greg@kroah.com> wrote: > On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote: > > Greg KH <greg@kroah.com> wrote: > > > > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > > > > > > > The kernel could provide a list of devices by category. It doesn't have > > > > to name them, run scripts, give descriptions, or paint them blue. Just a > > > > list of all block devices, tapes, by major/minor and category (ie. > > > > block, optical, floppy) would give the application layer a chance to do > > > > it's own interpretation. > > > > > > It does so today in sysfs, that is what it is there for. > > > > Do you really whant libscg to open _every_ non-directory file under /sys? > > Of course not. Here's one line of bash that gets you the major:minor > file of every block device in the system: > block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)" > > The block devices are all in a specific location. Are you sure you understand the problem? It isd most unlikely that all SCSI devices are there. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 18:59 ` Joerg Schilling @ 2006-02-14 19:53 ` Matthias Andree 2006-02-14 19:58 ` Joerg Schilling 2006-02-14 22:32 ` D. Hazelton 1 sibling, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-14 19:53 UTC (permalink / raw) To: Joerg Schilling; +Cc: greg, linux-kernel Joerg Schilling schrieb am 2006-02-14: > It isd most unlikely that all SCSI devices are there. Mind the topic: "CD writing" -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 19:53 ` Matthias Andree @ 2006-02-14 19:58 ` Joerg Schilling 2006-02-14 20:25 ` Matthias Andree 2006-02-14 22:35 ` D. Hazelton 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-14 19:58 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel, greg Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-14: > > > It isd most unlikely that all SCSI devices are there. > > Mind the topic: "CD writing" You don't need to repoeat this again, I already know that you are unteachable. For the others: the topic is the device and OS independent libscg. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 19:58 ` Joerg Schilling @ 2006-02-14 20:25 ` Matthias Andree 2006-02-14 22:35 ` D. Hazelton 1 sibling, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-14 20:25 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel Joerg Schilling schrieb am 2006-02-14: > You don't need to repoeat this again, I already know that you are unteachable. Yet another insult. > For the others: the topic is the device and OS independent libscg. Check the subject line, and check the destination address. This is CD writing on Linux, and it you who is still failing to provide information about non-CD-related bugs. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 19:58 ` Joerg Schilling 2006-02-14 20:25 ` Matthias Andree @ 2006-02-14 22:35 ` D. Hazelton 1 sibling, 0 replies; 717+ messages in thread From: D. Hazelton @ 2006-02-14 22:35 UTC (permalink / raw) To: Joerg Schilling; +Cc: matthias.andree, linux-kernel, greg On Tuesday 14 February 2006 14:58, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > Joerg Schilling schrieb am 2006-02-14: > > > It isd most unlikely that all SCSI devices are there. > > > > Mind the topic: "CD writing" > > You don't need to repoeat this again, I already know that you are > unteachable. > > For the others: the topic is the device and OS independent libscg. > Jörg In your mind only This thread started out as "CD writing future in Linux" and that's where it has been. We all know that you claim all the problems cdrecord has with Linux are in libscg, but that doesn't excuse you from ignoring the posted topic and trying to change it so you can rant about how bad the SCSI subsystem in Linux was designed. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 18:59 ` Joerg Schilling 2006-02-14 19:53 ` Matthias Andree @ 2006-02-14 22:32 ` D. Hazelton 1 sibling, 0 replies; 717+ messages in thread From: D. Hazelton @ 2006-02-14 22:32 UTC (permalink / raw) To: Joerg Schilling; +Cc: greg, nix, linux-kernel, davidsen, axboe On Tuesday 14 February 2006 13:59, Joerg Schilling wrote: > Greg KH <greg@kroah.com> wrote: > > On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote: > > > Greg KH <greg@kroah.com> wrote: > > > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > > > > The kernel could provide a list of devices by category. It doesn't > > > > > have to name them, run scripts, give descriptions, or paint them > > > > > blue. Just a list of all block devices, tapes, by major/minor and > > > > > category (ie. block, optical, floppy) would give the application > > > > > layer a chance to do it's own interpretation. > > > > > > > > It does so today in sysfs, that is what it is there for. > > > > > > Do you really whant libscg to open _every_ non-directory file under > > > /sys? > > > > Of course not. Here's one line of bash that gets you the major:minor > > file of every block device in the system: > > block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)" > > > > The block devices are all in a specific location. > > Are you sure you understand the problem? > > It isd most unlikely that all SCSI devices are there. > > Jörg Which is why there is also /sys/class/scsi_host and /sys/class/scsi_device those two, together with the block device data available via /sys/block should be enough to enumerate every ATAPI and SCSI device on the system. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:49 ` Greg KH 2006-02-14 18:59 ` Joerg Schilling @ 2006-02-14 18:59 ` Olivier Galibert 2006-02-14 19:01 ` Bill Davidsen 2006-02-15 15:44 ` Jan Engelhardt 3 siblings, 0 replies; 717+ messages in thread From: Olivier Galibert @ 2006-02-14 18:59 UTC (permalink / raw) To: Greg KH; +Cc: Joerg Schilling, davidsen, nix, linux-kernel, axboe On Mon, Feb 13, 2006 at 07:49:21AM -0800, Greg KH wrote: > On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote: > > Greg KH <greg@kroah.com> wrote: > > > > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > > > > > > > The kernel could provide a list of devices by category. It doesn't have > > > > to name them, run scripts, give descriptions, or paint them blue. Just a > > > > list of all block devices, tapes, by major/minor and category (ie. > > > > block, optical, floppy) would give the application layer a chance to do > > > > it's own interpretation. > > > > > > It does so today in sysfs, that is what it is there for. > > > > Do you really whant libscg to open _every_ non-directory file under /sys? > > Of course not. Here's one line of bash that gets you the major:minor > file of every block device in the system: > block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)" Of course, that's entirely useless if you're not root. So what you _really_ have to do is to call udevinfo -e. If that fails, call udevinfo -d, that's the old name for the option which got changed along the way. The result is blocks of text lines separated by blank lines, text lines of the form: I: value Where I is a one-letter uppercase identifier, and value a value. If you get E: entries, you're lucky. All cdroms have a E: ID_CDROM=1 entry, but these entries appeared late. Otherwise, the best bet is to scan the S: entries for something matching /cdrom/. When you have a bloc of lines, get the N: entry, that's the node name, and prepend it with the result of udevinfo -r (usually /dev/, but that's not mandatory). That will give you the device node path to open (don't forget O_EXCL to avoid Hal stomping all over you), which you can then use SG_IO with. If udevinfo is not available, you'll have to try opening all /dev/hd*, /dev/sr*, /dev/scd*, /dev/sg*, /dev/cdr* and /dev/dvd* (don't stop at the first -EANYTHING though, otherwise you'll miss some). Then you can poke the device carefully with SG_IO. OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:49 ` Greg KH 2006-02-14 18:59 ` Joerg Schilling 2006-02-14 18:59 ` Olivier Galibert @ 2006-02-14 19:01 ` Bill Davidsen 2006-02-14 22:33 ` Nix 2006-02-15 15:44 ` Jan Engelhardt 3 siblings, 1 reply; 717+ messages in thread From: Bill Davidsen @ 2006-02-14 19:01 UTC (permalink / raw) To: Greg KH; +Cc: Joerg Schilling, davidsen, nix, linux-kernel, axboe On Mon, 13 Feb 2006, Greg KH wrote: > On Mon, Feb 13, 2006 at 02:26:54PM +0100, Joerg Schilling wrote: > > Greg KH <greg@kroah.com> wrote: > > > > > On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > > > > > > > > The kernel could provide a list of devices by category. It doesn't have > > > > to name them, run scripts, give descriptions, or paint them blue. Just a > > > > list of all block devices, tapes, by major/minor and category (ie. > > > > block, optical, floppy) would give the application layer a chance to do > > > > it's own interpretation. > > > > > > It does so today in sysfs, that is what it is there for. > > > > Do you really whant libscg to open _every_ non-directory file under /sys? > > Of course not. Here's one line of bash that gets you the major:minor > file of every block device in the system: > block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)" > > The block devices are all in a specific location. > > And here's a way to get the cdroms of the system: [snip] > > If you want to do this in C, there is a libsysfs, which should help you > out a bit on intregrating sysfs support into your program (although udev > has recently ripped it out and replaced it with 200 lines of code that > is way smaller and much faster...) > > Hope this helps, Just determined that at least in FC4 the udev stuff doesn't seem to create the sg devices, cdrecord doesn't work with devices which use the scsi interface AFAIK, fails with USB, Firewire, and real SCSI devices. I'm still looking at this, trying w/o udev. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with little computers since 1979 ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 19:01 ` Bill Davidsen @ 2006-02-14 22:33 ` Nix 0 siblings, 0 replies; 717+ messages in thread From: Nix @ 2006-02-14 22:33 UTC (permalink / raw) To: davidsen; +Cc: Greg KH, Joerg Schilling, linux-kernel, axboe On Tue, 14 Feb 2006, Bill Davidsen stated: > Just determined that at least in FC4 the udev stuff doesn't seem to create > the sg devices, It has done so for as long as I've been using udev (since 058). What kernel are you using? -- `... follow the bouncing internment camps.' --- Peter da Silva ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:49 ` Greg KH ` (2 preceding siblings ...) 2006-02-14 19:01 ` Bill Davidsen @ 2006-02-15 15:44 ` Jan Engelhardt 2006-02-15 16:40 ` Olivier Galibert 2006-02-15 17:07 ` Greg KH 3 siblings, 2 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-15 15:44 UTC (permalink / raw) To: Greg KH; +Cc: Joerg Schilling, davidsen, nix, linux-kernel, axboe > >Of course not. Here's one line of bash that gets you the major:minor >file of every block device in the system: > block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)" > When was that added? /sys/block/hdc/device/ only has "power", "block", "bus" and "driver" here on a 2.6.13-rc3. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 15:44 ` Jan Engelhardt @ 2006-02-15 16:40 ` Olivier Galibert 2006-02-15 17:07 ` Greg KH 1 sibling, 0 replies; 717+ messages in thread From: Olivier Galibert @ 2006-02-15 16:40 UTC (permalink / raw) To: Jan Engelhardt Cc: Greg KH, Joerg Schilling, davidsen, nix, linux-kernel, axboe On Wed, Feb 15, 2006 at 04:44:38PM +0100, Jan Engelhardt wrote: > > > >Of course not. Here's one line of bash that gets you the major:minor > >file of every block device in the system: > > block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)" > > > When was that added? /sys/block/hdc/device/ only has "power", "block", > "bus" and "driver" here on a 2.6.13-rc3. No, it's /sys/block/hdc/dev (22:0 here on 2.6.12). Makes sense to have it there if you have multiple driver-generated device node entries for the same physical device. I'm thinking of usb multi-function devices here in particular (disk+bluetooth, video+hid [dvb+remote control that is]). OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 15:44 ` Jan Engelhardt 2006-02-15 16:40 ` Olivier Galibert @ 2006-02-15 17:07 ` Greg KH 1 sibling, 0 replies; 717+ messages in thread From: Greg KH @ 2006-02-15 17:07 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Joerg Schilling, davidsen, nix, linux-kernel, axboe On Wed, Feb 15, 2006 at 04:44:38PM +0100, Jan Engelhardt wrote: > > > >Of course not. Here's one line of bash that gets you the major:minor > >file of every block device in the system: > > block_devices="$(echo /sys/block/*/dev /sys/block/*/*/dev)" > > > When was that added? /sys/block/hdc/device/ only has "power", "block", > "bus" and "driver" here on a 2.6.13-rc3. True, that's why my above "echo" didn't point to "device" but "dev". "device" is a symlink to the device that the block device is attached to. "dev" is the major:minor number of this specific block device. Hope this helps, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 13:26 ` Joerg Schilling 2006-02-13 15:49 ` Greg KH @ 2006-02-13 22:14 ` Nix 2006-02-14 0:03 ` D. Hazelton ` (2 more replies) 1 sibling, 3 replies; 717+ messages in thread From: Nix @ 2006-02-13 22:14 UTC (permalink / raw) To: Joerg Schilling; +Cc: greg, davidsen, linux-kernel, axboe On Mon, 13 Feb 2006, Joerg Schilling stated: > Greg KH <greg@kroah.com> wrote: > >> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: >> > >> > The kernel could provide a list of devices by category. It doesn't have >> > to name them, run scripts, give descriptions, or paint them blue. Just a >> > list of all block devices, tapes, by major/minor and category (ie. >> > block, optical, floppy) would give the application layer a chance to do >> > it's own interpretation. >> >> It does so today in sysfs, that is what it is there for. > > Do you really whant libscg to open _every_ non-directory file under /sys? Well, that would be overkill, but iterating across, say, /sys/class/scsi_device seems like it would be a good idea. (I doubt libscg would ever be interested in the stuff in most of the other directories: things like /dev/mem are not SCSI devices and never will be, and /sys/class/scsi_device contains *everything* Linux considers a SCSI device, no matter what transport it is on, SATA and all. However, I don't know if it handles IDE devices that you can SG_IO to because I don't have any such here. Anyone know?) -- `... follow the bouncing internment camps.' --- Peter da Silva ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 22:14 ` Nix @ 2006-02-14 0:03 ` D. Hazelton 2006-02-14 0:32 ` Nix 2006-02-14 9:22 ` Matthias Andree 2006-02-14 11:27 ` Joerg Schilling 2 siblings, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-14 0:03 UTC (permalink / raw) To: Nix; +Cc: Joerg Schilling, greg, davidsen, linux-kernel, axboe On Monday 13 February 2006 17:14, Nix wrote: > On Mon, 13 Feb 2006, Joerg Schilling stated: > > Greg KH <greg@kroah.com> wrote: > >> On Fri, Feb 10, 2006 at 04:06:39PM -0500, Bill Davidsen wrote: > >> > The kernel could provide a list of devices by category. It doesn't > >> > have to name them, run scripts, give descriptions, or paint them blue. > >> > Just a list of all block devices, tapes, by major/minor and category > >> > (ie. block, optical, floppy) would give the application layer a chance > >> > to do it's own interpretation. > >> > >> It does so today in sysfs, that is what it is there for. > > > > Do you really whant libscg to open _every_ non-directory file under /sys? > > Well, that would be overkill, but iterating across, say, > /sys/class/scsi_device seems like it would be a good idea. > > (I doubt libscg would ever be interested in the stuff in most of the > other directories: things like /dev/mem are not SCSI devices and never > will be, and /sys/class/scsi_device contains *everything* Linux > considers a SCSI device, no matter what transport it is on, SATA and > all. However, I don't know if it handles IDE devices that you can SG_IO > to because I don't have any such here. Anyone know?) Not on my system, and I have a DVD-ROM and a CDRW drive attached, both of which are capable of SG_IO. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 0:03 ` D. Hazelton @ 2006-02-14 0:32 ` Nix 0 siblings, 0 replies; 717+ messages in thread From: Nix @ 2006-02-14 0:32 UTC (permalink / raw) To: D. Hazelton; +Cc: linux-kernel On Mon, 13 Feb 2006, D. Hazelton whispered secretively: > On Monday 13 February 2006 17:14, Nix wrote: >> (I doubt libscg would ever be interested in the stuff in most of the >> other directories: things like /dev/mem are not SCSI devices and never >> will be, and /sys/class/scsi_device contains *everything* Linux >> considers a SCSI device, no matter what transport it is on, SATA and >> all. However, I don't know if it handles IDE devices that you can SG_IO >> to because I don't have any such here. Anyone know?) > > Not on my system, and I have a DVD-ROM and a CDRW drive attached, both of > which are capable of SG_IO. Blast. Well, all these SCSI-like things *should* appear in one place in /sys, dammit. Even if they don't right now. :/ -- `... follow the bouncing internment camps.' --- Peter da Silva ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 22:14 ` Nix 2006-02-14 0:03 ` D. Hazelton @ 2006-02-14 9:22 ` Matthias Andree 2006-02-14 18:09 ` Jan Engelhardt 2006-02-14 11:27 ` Joerg Schilling 2 siblings, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-14 9:22 UTC (permalink / raw) To: Nix; +Cc: linux-kernel On Mon, 13 Feb 2006, Nix wrote: > (I doubt libscg would ever be interested in the stuff in most of the > other directories: things like /dev/mem are not SCSI devices and never > will be, and /sys/class/scsi_device contains *everything* Linux > considers a SCSI device, no matter what transport it is on, SATA and > all. However, I don't know if it handles IDE devices that you can SG_IO > to because I don't have any such here. Anyone know?) My ATAPI DVD and CD writers are not listed in /sys/class/scsi_device. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 9:22 ` Matthias Andree @ 2006-02-14 18:09 ` Jan Engelhardt 2006-02-14 18:41 ` Olivier Galibert 0 siblings, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-02-14 18:09 UTC (permalink / raw) To: Matthias Andree; +Cc: Nix, linux-kernel > >> (I doubt libscg would ever be interested in the stuff in most of the >> other directories: things like /dev/mem are not SCSI devices and never >> will be, and /sys/class/scsi_device contains *everything* Linux >> considers a SCSI device, no matter what transport it is on, SATA and >> all. However, I don't know if it handles IDE devices that you can SG_IO >> to because I don't have any such here. Anyone know?) > >My ATAPI DVD and CD writers are not listed in /sys/class/scsi_device. > My IDE one is neither nowhere in /sys/class. (Maybe I did not try looking hard enough, though.) Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 18:09 ` Jan Engelhardt @ 2006-02-14 18:41 ` Olivier Galibert 2006-02-17 15:36 ` Jan Engelhardt 0 siblings, 1 reply; 717+ messages in thread From: Olivier Galibert @ 2006-02-14 18:41 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Matthias Andree, Nix, linux-kernel On Tue, Feb 14, 2006 at 07:09:19PM +0100, Jan Engelhardt wrote: > My IDE one is neither nowhere in /sys/class. (Maybe I did not try looking > hard enough, though.) Why care, official policy is that you should do device discovery through udevinfo and not touch sysfs. OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 18:41 ` Olivier Galibert @ 2006-02-17 15:36 ` Jan Engelhardt 0 siblings, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-17 15:36 UTC (permalink / raw) To: Olivier Galibert; +Cc: Matthias Andree, Nix, linux-kernel >> My IDE one is neither nowhere in /sys/class. (Maybe I did not try looking >> hard enough, though.) > >Why care, official policy is that you should do device discovery >through udevinfo and not touch sysfs. > Hm, it's in /sys/block/hdb. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 22:14 ` Nix 2006-02-14 0:03 ` D. Hazelton 2006-02-14 9:22 ` Matthias Andree @ 2006-02-14 11:27 ` Joerg Schilling 2006-02-14 22:30 ` Greg KH 2006-02-14 22:40 ` Nix 2 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-14 11:27 UTC (permalink / raw) To: schilling, nix; +Cc: linux-kernel, greg, davidsen, axboe Nix <nix@esperi.org.uk> wrote: > > Do you really whant libscg to open _every_ non-directory file under /sys? > > Well, that would be overkill, but iterating across, say, > /sys/class/scsi_device seems like it would be a good idea. > > (I doubt libscg would ever be interested in the stuff in most of the > other directories: things like /dev/mem are not SCSI devices and never > will be, and /sys/class/scsi_device contains *everything* Linux > considers a SCSI device, no matter what transport it is on, SATA and > all. However, I don't know if it handles IDE devices that you can SG_IO > to because I don't have any such here. Anyone know?) This statement is obviously not true :-( Let us start in a way that makes sense: Please send me the whitepaper that was used to define the interfaces and functionality of the /sys device Please send me the other documentation (e.g. man pages) on the /sys device Please send me a statement on how long this interface will be maintained inside Linux without breaking interfaces. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 11:27 ` Joerg Schilling @ 2006-02-14 22:30 ` Greg KH 2006-02-15 0:43 ` Matthias Andree 2006-02-14 22:40 ` Nix 1 sibling, 1 reply; 717+ messages in thread From: Greg KH @ 2006-02-14 22:30 UTC (permalink / raw) To: Joerg Schilling; +Cc: nix, linux-kernel, davidsen, axboe On Tue, Feb 14, 2006 at 12:27:18PM +0100, Joerg Schilling wrote: > > Please send me the whitepaper that was used to define the interfaces > and functionality of the /sys device I was not aware that there is now a rule that we must write whitepapers describing as to what the interface looks like in complete detail that we want to add to the Linux kernel. Will you please point me to the proper authorities that will be enforcing this newly created rule? > Please send me the other documentation (e.g. man pages) on the /sys > device What "/sys device"? sysfs is a file system, and there have been many magazine articles, and conference papers written, and talks given on the topic. If you have specific questions as to how it is structured, please let the current sysfs maintainer know. > Please send me a statement on how long this interface will be maintained > inside Linux without breaking interfaces. It will be stable and maintained until a major program depends on its structure. Then it will change in new and interesting ways and break everything :) Seriously, it isn't going away, and new information is being added all the time to it. Due to the structure of sysfs, changes in it is very easy to accomidate. thanks, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 22:30 ` Greg KH @ 2006-02-15 0:43 ` Matthias Andree 2006-02-15 5:20 ` Greg KH 0 siblings, 1 reply; 717+ messages in thread From: Matthias Andree @ 2006-02-15 0:43 UTC (permalink / raw) To: Greg KH; +Cc: Linux-Kernel mailing list On Tue, 14 Feb 2006, Greg KH wrote: > On Tue, Feb 14, 2006 at 12:27:18PM +0100, Joerg Schilling wrote: > > > > Please send me the whitepaper that was used to define the interfaces > > and functionality of the /sys device > > I was not aware that there is now a rule that we must write whitepapers > describing as to what the interface looks like in complete detail that > we want to add to the Linux kernel. Will you please point me to the > proper authorities that will be enforcing this newly created rule? Well, Jörg's questions, although ridiculously exaggerated and quixotic, show a general problem in Linux: documentation is constantly outdated, missing, and not part of the kernel package. If Linux were based in Utopia, it would ship with a complete set of kernel-related manual pages and HOWTOs. I appreciate the efforts of the old and new man-pages maintainers, and I know the problems in motivation when writing documentation and keeping it up to date distracts people from writing code -- but those people know their code best. > > Please send me the other documentation (e.g. man pages) on the /sys > > device > > What "/sys device"? sysfs is a file system, and there have been many > magazine articles, and conference papers written, and talks given on the > topic. And that is the key problem. magazine here, conference there, talk (perhaps only slides available) somewhere else -- a manual that was in /usr/src/linux/Documentation might make a real difference. Even a commented link list in Documentation/* might be a good starting point. Patrick Mochel added some bits three years ago, but they were internals and thus a bit less interesting. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 0:43 ` Matthias Andree @ 2006-02-15 5:20 ` Greg KH 2006-02-16 12:01 ` Matthias Andree 0 siblings, 1 reply; 717+ messages in thread From: Greg KH @ 2006-02-15 5:20 UTC (permalink / raw) To: Linux-Kernel mailing list On Wed, Feb 15, 2006 at 01:43:20AM +0100, Matthias Andree wrote: > > > Please send me the other documentation (e.g. man pages) on the /sys > > > device > > > > What "/sys device"? sysfs is a file system, and there have been many > > magazine articles, and conference papers written, and talks given on the > > topic. > > And that is the key problem. magazine here, conference there, talk > (perhaps only slides available) somewhere else -- a manual that was in > /usr/src/linux/Documentation might make a real difference. Even a > commented link list in Documentation/* might be a good starting point. > > Patrick Mochel added some bits three years ago, but they were internals > and thus a bit less interesting. What would be "interesting"? The sysfs and driver model chapter of the Linux Device Driver book from Oreilly, third edition? Or something oriented toward users of sysfs, not developers using it? thanks, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-15 5:20 ` Greg KH @ 2006-02-16 12:01 ` Matthias Andree 2006-02-16 16:51 ` Randy.Dunlap 2006-02-16 18:03 ` Greg KH 0 siblings, 2 replies; 717+ messages in thread From: Matthias Andree @ 2006-02-16 12:01 UTC (permalink / raw) To: Greg KH; +Cc: Linux-Kernel mailing list On Tue, 14 Feb 2006, Greg KH wrote: > > And that is the key problem. magazine here, conference there, talk > > (perhaps only slides available) somewhere else -- a manual that was in > > /usr/src/linux/Documentation might make a real difference. Even a > > commented link list in Documentation/* might be a good starting point. > > > > Patrick Mochel added some bits three years ago, but they were internals > > and thus a bit less interesting. > > What would be "interesting"? The sysfs and driver model chapter of the > Linux Device Driver book from Oreilly, third edition? Or something > oriented toward users of sysfs, not developers using it? Integrating documentation with the kernel. Documentation/* is constantly out of date and incomplete, and sometimes has non-intuitive names. -- Matthias Andree ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 12:01 ` Matthias Andree @ 2006-02-16 16:51 ` Randy.Dunlap 2006-02-16 18:03 ` Greg KH 1 sibling, 0 replies; 717+ messages in thread From: Randy.Dunlap @ 2006-02-16 16:51 UTC (permalink / raw) To: Matthias Andree; +Cc: Greg KH, Linux-Kernel mailing list On Thu, 16 Feb 2006, Matthias Andree wrote: > On Tue, 14 Feb 2006, Greg KH wrote: > > > > And that is the key problem. magazine here, conference there, talk > > > (perhaps only slides available) somewhere else -- a manual that was in > > > /usr/src/linux/Documentation might make a real difference. Even a > > > commented link list in Documentation/* might be a good starting point. > > > > > > Patrick Mochel added some bits three years ago, but they were internals > > > and thus a bit less interesting. > > > > What would be "interesting"? The sysfs and driver model chapter of the > > Linux Device Driver book from Oreilly, third edition? Or something > > oriented toward users of sysfs, not developers using it? > > Integrating documentation with the kernel. Documentation/* is constantly > out of date and incomplete, and sometimes has non-intuitive names. I mostly agree and I'm trying to update it -- in my spare time. Help is accepted. 8:) -- ~Randy ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 12:01 ` Matthias Andree 2006-02-16 16:51 ` Randy.Dunlap @ 2006-02-16 18:03 ` Greg KH 1 sibling, 0 replies; 717+ messages in thread From: Greg KH @ 2006-02-16 18:03 UTC (permalink / raw) To: Linux-Kernel mailing list On Thu, Feb 16, 2006 at 01:01:29PM +0100, Matthias Andree wrote: > On Tue, 14 Feb 2006, Greg KH wrote: > > > > And that is the key problem. magazine here, conference there, talk > > > (perhaps only slides available) somewhere else -- a manual that was in > > > /usr/src/linux/Documentation might make a real difference. Even a > > > commented link list in Documentation/* might be a good starting point. > > > > > > Patrick Mochel added some bits three years ago, but they were internals > > > and thus a bit less interesting. > > > > What would be "interesting"? The sysfs and driver model chapter of the > > Linux Device Driver book from Oreilly, third edition? Or something > > oriented toward users of sysfs, not developers using it? > > Integrating documentation with the kernel. What kind of documentation? user oriented documentation like how to find specific stuff in sysfs? Or developer oriented documentation, like we have there now. > Documentation/* is constantly out of date and incomplete, and > sometimes has non-intuitive names. It's not always out of date. And patches are always gladly accepted. Also, what non-intuitive names are you referring to? thanks, greg k-h ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 11:27 ` Joerg Schilling 2006-02-14 22:30 ` Greg KH @ 2006-02-14 22:40 ` Nix 2006-02-16 12:09 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: Nix @ 2006-02-14 22:40 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel, greg, davidsen, axboe On Tue, 14 Feb 2006, Joerg Schilling wrote: > Please send me the whitepaper that was used to define the interfaces > and functionality of the /sys device If you seriously think that development of *anything* in the free software world happens by means of whitepapers preceding definition, or indeed that anything major in the Unix world has ever worked that way, you're seriously deluded. > Please send me the other documentation (e.g. man pages) on the /sys > device Oh, I thought you had *access* to the kernel source. A trivial grep under the Documentation directory would find it (hint: Documentation/filesystems/ is a good place to start.) If you actually wanted to *fix* your program --- if you cared more about users than being proved right no matter what --- then you'd have been able to determine that for yourself in seconds. (But then we all know that's not what you're actually after.) > Please send me a statement on how long this interface will be maintained > inside Linux without breaking interfaces. What a ridiculous request. If people use it, it won't be broken. If it proves unusable due to flaws, it will change. Sheesh. (It is not as robust as the syscall interface, but it is still subject to some degree of change. A trivial google would have made this clear.) You appear not to understand the difference between development roadmapped for years in advance by a sclerotic corporation and free software development. Or perhaps you do understand, and are just being pointlessly contrary. (I expect the latter is true. You're not stupid. Just nasty.) -- `... follow the bouncing internment camps.' --- Peter da Silva ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 22:40 ` Nix @ 2006-02-16 12:09 ` Joerg Schilling 2006-02-16 12:36 ` Martin Mares 2006-02-16 12:55 ` Marc Koschewski 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-16 12:09 UTC (permalink / raw) To: schilling, nix; +Cc: linux-kernel, greg, davidsen, axboe Nix <nix@esperi.org.uk> wrote: > > Please send me a statement on how long this interface will be maintained > > inside Linux without breaking interfaces. > > What a ridiculous request. If people use it, it won't be broken. If it > proves unusable due to flaws, it will change. Sheesh. Looks like you are a Linux newby and did not yet relize how Linux is maintained :-( ide-scsi is used and needed but made unsusable. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 12:09 ` Joerg Schilling @ 2006-02-16 12:36 ` Martin Mares 2006-02-17 0:38 ` Nix [not found] ` <43F746B8.6080607@tmr.com> 2006-02-16 12:55 ` Marc Koschewski 1 sibling, 2 replies; 717+ messages in thread From: Martin Mares @ 2006-02-16 12:36 UTC (permalink / raw) To: Joerg Schilling; +Cc: nix, linux-kernel, greg, davidsen, axboe Hello! > ide-scsi is used and needed but made unsusable. Used maybe, but needed by whom? Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Top ten reasons to procrastinate: 1. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 12:36 ` Martin Mares @ 2006-02-17 0:38 ` Nix [not found] ` <43F746B8.6080607@tmr.com> 1 sibling, 0 replies; 717+ messages in thread From: Nix @ 2006-02-17 0:38 UTC (permalink / raw) To: Martin Mares; +Cc: linux-kernel On Thu, 16 Feb 2006, Martin Mares noted: > Hello! > >> ide-scsi is used and needed but made unsusable. > > Used maybe, but needed by whom? Why, by Joerg of course, with his magic telepathy helmet which enables him to tell exactly how long people he doesn't know have been using Linux, and lets him determine exactly how broken all patches written by other people are without even looking at them, and his great genius which enables him to tell exactly how Linux must work (i.e., exactly like Solaris), regardless of what any of those fools who actually *wrote* it may think. How could you possibly think anything else? Nothing else would be *rational*. You of course should not respond until you agree with Joerg in all matters. (I was wondering how Joerg managed to unilaterally impose new licensing terms on cdrecord without going through lots of trouble asking all the other contributors. I guess I know now: there *are* no other contributors, because nobody else can bear to work with him.) ^ permalink raw reply [flat|nested] 717+ messages in thread
[parent not found: <43F746B8.6080607@tmr.com>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <43F746B8.6080607@tmr.com> @ 2006-02-18 21:04 ` Martin Mares 2006-02-18 22:00 ` Ondrej Zary 0 siblings, 1 reply; 717+ messages in thread From: Martin Mares @ 2006-02-18 21:04 UTC (permalink / raw) To: Bill Davidsen; +Cc: Joerg Schilling, nix, linux-kernel, greg, axboe Hello! > MO, WORM, {ZIP,ls120} drives if you are using the full capabilities, IDE > tape drives, etc. > > Sorry, I don't remember what capability the ls120 was using, but as of > 2.6.12 it didn't work through the ide-floppy interface. Then it's a bug in ide-floppy which should be fixed. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Immanuel doesn't pun, he Kant. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-18 21:04 ` Martin Mares @ 2006-02-18 22:00 ` Ondrej Zary 0 siblings, 0 replies; 717+ messages in thread From: Ondrej Zary @ 2006-02-18 22:00 UTC (permalink / raw) To: Martin Mares Cc: Bill Davidsen, Joerg Schilling, nix, linux-kernel, greg, axboe Martin Mares wrote: > Hello! > >> MO, WORM, {ZIP,ls120} drives if you are using the full capabilities, IDE >> tape drives, etc. >> >> Sorry, I don't remember what capability the ls120 was using, but as of >> 2.6.12 it didn't work through the ide-floppy interface. > > Then it's a bug in ide-floppy which should be fixed. > I fixed something in ide-floppy some time ago - when I bought LS-120 drive and software eject did not work. See http://lkml.org/lkml/2005/9/4/83 -- Ondrej Zary ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 12:09 ` Joerg Schilling 2006-02-16 12:36 ` Martin Mares @ 2006-02-16 12:55 ` Marc Koschewski 1 sibling, 0 replies; 717+ messages in thread From: Marc Koschewski @ 2006-02-16 12:55 UTC (permalink / raw) To: Joerg Schilling; +Cc: nix, linux-kernel, greg, davidsen, axboe * Joerg Schilling <schilling@fokus.fraunhofer.de> [2006-02-16 13:09:53 +0100]: > Nix <nix@esperi.org.uk> wrote: > > > > Please send me a statement on how long this interface will be maintained > > > inside Linux without breaking interfaces. > > > > What a ridiculous request. If people use it, it won't be broken. If it > > proves unusable due to flaws, it will change. Sheesh. > > Looks like you are a Linux newby and did not yet relize how Linux > is maintained :-( > > ide-scsi is used and needed but made unsusable. I remember a time when I used it in order to be able to burn CDs. Nowadays it works, however, without the module. Don't know who is using it. Or what for.. Marc ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-10 21:06 ` Bill Davidsen ` (2 preceding siblings ...) 2006-02-10 23:56 ` Greg KH @ 2006-02-13 12:11 ` Joerg Schilling [not found] ` <515e525f0602130446s1091f09ande10910f65a0f5f0@mail.gmail.com> 3 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-13 12:11 UTC (permalink / raw) To: nix, davidsen; +Cc: schilling, linux-kernel, axboe Bill Davidsen <davidsen@tmr.com> wrote: > I notice that the first thing people suggest is to make things like > udev, hal and sysfs required instead of optional to do something as > simple as burn a CD. As I mentioned before, if the kernel provided a > list of devices then applications wouldn't break every time a new kernel > came out which needs a new this, and new that, and a few new other > support things. This would make sense in case that a useful definition with a granted lifetime of at least 10 years would be implemented. > The kernel could provide a list of devices by category. It doesn't have What if the kernel does not understand the cetegory? Common oddities: - Mac OS X tries to distinct between CD/DVD writers and CD/DVD-ROM although there is only one device class. - Older CD-writers identified as WORM although a CD-R is not a WORM. > to name them, run scripts, give descriptions, or paint them blue. Just a > list of all block devices, tapes, by major/minor and category (ie. > block, optical, floppy) would give the application layer a chance to do > it's own interpretation. HAL is great, but because it's not part of the > kernel it's also going to suffer from "tracking error" for some changes. > I find it easier to teach someone to use -scanbus than to explain how to > make rules for udev. As this categorisation does not work, we need a way to find all devices that talk SCSI and let the application decicde what device is supported. > Worth repeating: I find it easier to teach someone to use -scanbus than > to explain how to make rules for udev. HAL is the right answer, but *in* > the kernel, where it will track changes. Since -scanbus tells you a > device is a CDrecorder, or something else, *any user* is likely to be > able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices... So you seem to agree with me. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
[parent not found: <515e525f0602130446s1091f09ande10910f65a0f5f0@mail.gmail.com>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <515e525f0602130446s1091f09ande10910f65a0f5f0@mail.gmail.com> @ 2006-02-13 15:12 ` Joerg Schilling 2006-02-13 16:40 ` Jan Engelhardt 2006-02-13 23:24 ` D. Hazelton 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-02-13 15:12 UTC (permalink / raw) To: trudheim, schilling; +Cc: nix, linux-kernel, davidsen, axboe Anders Karlsson <trudheim@gmail.com> wrote: > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > [snip] > > - Older CD-writers identified as WORM although a CD-R is not a WORM. > > Nitpicking I know, but technically, CD-R is WORM in the case of single > session write. And as long as the writer works, who cares if it is > labled WORM, CD-R or Earthworm.. If you did know what a worm is, you would know that you are not correct: A WORM allows you to randomly write any sector once. A CD-R does not allows you to do this. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:12 ` Joerg Schilling @ 2006-02-13 16:40 ` Jan Engelhardt 2006-02-13 23:24 ` D. Hazelton 1 sibling, 0 replies; 717+ messages in thread From: Jan Engelhardt @ 2006-02-13 16:40 UTC (permalink / raw) To: Joerg Schilling; +Cc: trudheim, nix, linux-kernel, davidsen, axboe >> Nitpicking I know, but technically, CD-R is WORM in the case of single >> session write. And as long as the writer works, who cares if it is >> labled WORM, CD-R or Earthworm.. > >If you did know what a worm is, you would know that you are not correct: > >A WORM allows you to randomly write any sector once. >A CD-R does not allows you to do this. > Nitpicking2, the CD-R case is a limitation of the cd writer ;) Sadly there is no packet mode for CDRs. It would outbeat multisession. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 15:12 ` Joerg Schilling 2006-02-13 16:40 ` Jan Engelhardt @ 2006-02-13 23:24 ` D. Hazelton 2006-02-14 13:55 ` Joerg Schilling 1 sibling, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-13 23:24 UTC (permalink / raw) To: Joerg Schilling; +Cc: trudheim, nix, linux-kernel, davidsen, axboe On Monday 13 February 2006 10:12, Joerg Schilling wrote: > Anders Karlsson <trudheim@gmail.com> wrote: > > On 2/13/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > [snip] > > > > > - Older CD-writers identified as WORM although a CD-R is not a > > > WORM. > > > > Nitpicking I know, but technically, CD-R is WORM in the case of single > > session write. And as long as the writer works, who cares if it is > > labled WORM, CD-R or Earthworm.. > > If you did know what a worm is, you would know that you are not correct: > > A WORM allows you to randomly write any sector once. > > A CD-R does not allows you to do this. Joerg, the practical definition of WORM is "Write Once, Read Many" - whether or not it supports writes to random sectors is a moot point, a CDR does seem to fit the bill of a "write once, read many" medium. DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 23:24 ` D. Hazelton @ 2006-02-14 13:55 ` Joerg Schilling 2006-02-14 21:59 ` D. Hazelton 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-02-14 13:55 UTC (permalink / raw) To: schilling, dhazelton; +Cc: trudheim, nix, linux-kernel, davidsen, axboe "D. Hazelton" <dhazelton@enter.net> wrote: > > If you did know what a worm is, you would know that you are not correct: > > > > A WORM allows you to randomly write any sector once. > > > > A CD-R does not allows you to do this. > > Joerg, the practical definition of WORM is "Write Once, Read Many" - whether > or not it supports writes to random sectors is a moot point, a CDR does seem > to fit the bill of a "write once, read many" medium. What you believe is irrelevent as long as it does not match the WORM device definition. See www.t10.org Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-14 13:55 ` Joerg Schilling @ 2006-02-14 21:59 ` D. Hazelton [not found] ` <43F74884.50904@tmr.com> 0 siblings, 1 reply; 717+ messages in thread From: D. Hazelton @ 2006-02-14 21:59 UTC (permalink / raw) To: Joerg Schilling; +Cc: trudheim, nix, linux-kernel, davidsen, axboe On Tuesday 14 February 2006 08:55, Joerg Schilling wrote: > "D. Hazelton" <dhazelton@enter.net> wrote: > > > If you did know what a worm is, you would know that you are not > > > correct: > > > > > > A WORM allows you to randomly write any sector once. > > > > > > A CD-R does not allows you to do this. > > > > Joerg, the practical definition of WORM is "Write Once, Read Many" - > > whether or not it supports writes to random sectors is a moot point, a > > CDR does seem to fit the bill of a "write once, read many" medium. > > What you believe is irrelevent as long as it does not match the WORM device > definition. > > See www.t10.org > > Jörg Joerg, I didn't say it was what _I_ believed. What I said was "WORM" means "Wrint One, Read Many" - since a CDR can be described in that fashion, it does match the description. Since it matches the description, most people lump the CDR medium in with all "WORM" medium. Is that clear enough? DRH ^ permalink raw reply [flat|nested] 717+ messages in thread
[parent not found: <43F74884.50904@tmr.com>]
* Re: CD writing in future Linux (stirring up a hornets' nest) [not found] ` <43F74884.50904@tmr.com> @ 2006-02-18 20:00 ` Nix 0 siblings, 0 replies; 717+ messages in thread From: Nix @ 2006-02-18 20:00 UTC (permalink / raw) To: Bill Davidsen; +Cc: D. Hazelton, Joerg Schilling, linux-kernel, axboe On Sat, 18 Feb 2006, Bill Davidsen gibbered uncontrollably: > There was a time when packet writing on CD-RW worked on Linux and > people stopped using WORM for the most part. I haven't tried since > udev became standard on most distros, I don't know if it still works > or not. If it doesn't work then the backup I'm now running is a mirage, but I'm so thick with cold that it might well be illusory ;} -- `... follow the bouncing internment camps.' --- Peter da Silva ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 18:22 ` Matthias Andree 2006-01-25 18:25 ` Jens Axboe 2006-01-26 0:36 ` Nix @ 2006-01-26 10:11 ` Joerg Schilling 2 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 10:11 UTC (permalink / raw) To: matthias.andree, axboe Cc: schilling, rlrevell, linux-kernel, jengelh, grundig, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > Jens Axboe wrote: > > > In fact it would be a _lot_ easier to just scan sysfs and do an inquiry > > on potentially useful devices. > > Hm. sysfs, procfs, udev, hotplug, netlink (for IPv6) - this all looks rather > complicated and non-portable. I understand that applications that can just > open every device and send SCSI INQUIRY might want to do that on Linux, too. Another problem is that it is hard to find whether a new feature in Linux will still be present some time later. If I would try to immediately add support for every new feature, I would have a lot of dead code in my sources and would need to put a lot of effort in this kind of coding. It seems that it makes sense to wait untill all major Linux distributions made a new feature their default for some time..... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:31 ` Jens Axboe 2006-01-25 18:22 ` Matthias Andree @ 2006-01-25 19:04 ` Olivier Galibert 1 sibling, 0 replies; 717+ messages in thread From: Olivier Galibert @ 2006-01-25 19:04 UTC (permalink / raw) To: Jens Axboe; +Cc: linux-kernel On Wed, Jan 25, 2006 at 06:31:27PM +0100, Jens Axboe wrote: > In fact it would be a _lot_ easier to just scan sysfs and do an inquiry > on potentially useful devices. Serious question, what and how? If I scan /sys/block for example for potential candidates, that won't give me the devices or tell me the name udev decided to use for it in /dev. And I'm not sure how to know if something is cdrom-ish and SG_IO able from sysfs. Should I filter on driver name? But then, I don't know which names are acceptable (*cdrom* ?)... Or maybe I should go through the fad-of-the-day, hal/dbus? OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:18 ` grundig 2006-01-25 17:31 ` Jens Axboe @ 2006-01-26 9:38 ` Joerg Schilling 2006-01-26 9:45 ` Lee Revell 2006-01-26 15:38 ` grundig 1 sibling, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 9:38 UTC (permalink / raw) To: schilling, grundig Cc: schilling, rlrevell, matthias.andree, linux-kernel, jengelh, axboe, acahalan <grundig@teleline.es> wrote: > El Wed, 25 Jan 2006 18:03:18 +0100, > Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > > > Guess why cdrecord -scanbus is needed. > > > > It serves the need of GUI programs for cdrercord and allows them to retrieve > > and list possible drives of interest in a platform independent way. > > But this is not neccesary at all, since linux platform already provides ways to > retrieve and list possible drives.... Interesting: You claim that the Linux platform provides ways to retrieve the needed information on FreeBSD, MS-WIN, ....? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 9:38 ` Joerg Schilling @ 2006-01-26 9:45 ` Lee Revell 2006-01-26 13:58 ` Joerg Schilling 2006-01-26 15:38 ` grundig 1 sibling, 1 reply; 717+ messages in thread From: Lee Revell @ 2006-01-26 9:45 UTC (permalink / raw) To: Joerg Schilling Cc: grundig, matthias.andree, linux-kernel, jengelh, axboe, acahalan On Thu, 2006-01-26 at 10:38 +0100, Joerg Schilling wrote: > <grundig@teleline.es> wrote: > > > El Wed, 25 Jan 2006 18:03:18 +0100, > > Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > > > > > Guess why cdrecord -scanbus is needed. > > > > > > It serves the need of GUI programs for cdrercord and allows them to retrieve > > > and list possible drives of interest in a platform independent way. > > > > But this is not neccesary at all, since linux platform already provides ways to > > retrieve and list possible drives.... > > Interesting: You claim that the Linux platform provides ways to retrieve > the needed information on FreeBSD, MS-WIN, ....? > What do FreeBSD and MS-WIN have to do with Linux? Lee ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 9:45 ` Lee Revell @ 2006-01-26 13:58 ` Joerg Schilling 2006-01-26 14:09 ` Nick Piggin 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 13:58 UTC (permalink / raw) To: schilling, rlrevell Cc: matthias.andree, linux-kernel, jengelh, grundig, axboe, acahalan Lee Revell <rlrevell@joe-job.com> wrote: > > Interesting: You claim that the Linux platform provides ways to retrieve > > the needed information on FreeBSD, MS-WIN, ....? > > > > What do FreeBSD and MS-WIN have to do with Linux? What is the relevence of /dev/hd* for a device independent library like libscg? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 13:58 ` Joerg Schilling @ 2006-01-26 14:09 ` Nick Piggin 2006-01-26 14:32 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: Nick Piggin @ 2006-01-26 14:09 UTC (permalink / raw) To: Joerg Schilling Cc: rlrevell, matthias.andree, linux-kernel, jengelh, grundig, axboe, acahalan Joerg Schilling wrote: > Lee Revell <rlrevell@joe-job.com> wrote: > > >>>Interesting: You claim that the Linux platform provides ways to retrieve >>>the needed information on FreeBSD, MS-WIN, ....? >>> >> >>What do FreeBSD and MS-WIN have to do with Linux? > > > What is the relevence of /dev/hd* for a device independent library like libscg? > Isn't it good practice to adhere to the naming conventions of the system to which a program is ported to? (even if 100 of them do it one way and 1 does it another) I don't claim to be an expert in the area at all, but it seems like the best way to do it IMHO. Thanks, Nick -- Send instant messages to your online friends http://au.messenger.yahoo.com ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 14:09 ` Nick Piggin @ 2006-01-26 14:32 ` Joerg Schilling 2006-01-26 15:16 ` Nick Piggin 2006-01-26 16:04 ` Matthias Andree 0 siblings, 2 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 14:32 UTC (permalink / raw) To: schilling, nickpiggin Cc: rlrevell, matthias.andree, linux-kernel, jengelh, grundig, axboe, acahalan Nick Piggin <nickpiggin@yahoo.com.au> wrote: > Joerg Schilling wrote: > > Lee Revell <rlrevell@joe-job.com> wrote: > > > > > >>>Interesting: You claim that the Linux platform provides ways to retrieve > >>>the needed information on FreeBSD, MS-WIN, ....? > >>> > >> > >>What do FreeBSD and MS-WIN have to do with Linux? > > > > > > What is the relevence of /dev/hd* for a device independent library like libscg? > > > > Isn't it good practice to adhere to the naming conventions > of the system to which a program is ported to? (even if 100 > of them do it one way and 1 does it another) Well, the problem is that (in special if you include the ATAPI tape drives) Linux likes to enforce inapropriate naming conventions. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 14:32 ` Joerg Schilling @ 2006-01-26 15:16 ` Nick Piggin 2006-01-26 16:04 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Nick Piggin @ 2006-01-26 15:16 UTC (permalink / raw) To: Joerg Schilling Cc: rlrevell, matthias.andree, linux-kernel, jengelh, grundig, axboe, acahalan Joerg Schilling wrote: > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > >>Isn't it good practice to adhere to the naming conventions >>of the system to which a program is ported to? (even if 100 >>of them do it one way and 1 does it another) > > > Well, the problem is that (in special if you include the ATAPI tape drives) > Linux likes to enforce inapropriate naming conventions. > But making up a new naming scheme which you happen to consider more appropriate doesn't sound to me like a good solution. Not even if you have good reasons for your likes/dislikes. If I ported some Linux program to Windows I would not ask the user if they wanted to save to /dev/hda5, or /mnt/c_drive because I consider C: bad naming. -- Send instant messages to your online friends http://au.messenger.yahoo.com ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 14:32 ` Joerg Schilling 2006-01-26 15:16 ` Nick Piggin @ 2006-01-26 16:04 ` Matthias Andree 1 sibling, 0 replies; 717+ messages in thread From: Matthias Andree @ 2006-01-26 16:04 UTC (permalink / raw) To: Joerg Schilling; +Cc: nickpiggin, linux-kernel, jengelh, grundig, acahalan Joerg Schilling wrote: > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > >> Joerg Schilling wrote: >>> Lee Revell <rlrevell@joe-job.com> wrote: >>> >>> >>>>> Interesting: You claim that the Linux platform provides ways to retrieve >>>>> the needed information on FreeBSD, MS-WIN, ....? >>>>> >>>> What do FreeBSD and MS-WIN have to do with Linux? >>> >>> What is the relevence of /dev/hd* for a device independent library like libscg? >>> >> Isn't it good practice to adhere to the naming conventions >> of the system to which a program is ported to? (even if 100 >> of them do it one way and 1 does it another) > > Well, the problem is that (in special if you include the ATAPI tape drives) > Linux likes to enforce inapropriate naming conventions. Nope. Naming conventions are not subject here. What OTHER libscg operations do not work for a particular ATAPI tape drive? -scanbus does NOT count, don't mention it. What is the drive manufacturer and type? What is the failing or inaccessible operation? Please remember to remove Jens Axboe and Lee Revell from the Cc: list! ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 9:38 ` Joerg Schilling 2006-01-26 9:45 ` Lee Revell @ 2006-01-26 15:38 ` grundig 1 sibling, 0 replies; 717+ messages in thread From: grundig @ 2006-01-26 15:38 UTC (permalink / raw) To: Joerg Schilling Cc: schilling, rlrevell, matthias.andree, linux-kernel, jengelh, axboe, acahalan El Thu, 26 Jan 2006 10:38:23 +0100, Joerg Schilling <schilling@fokus.fraunhofer.de> escribió: > > > It serves the need of GUI programs for cdrercord and allows them to retrieve > > > and list possible drives of interest in a platform independent way. > > > > But this is not neccesary at all, since linux platform already provides ways to > > retrieve and list possible drives.... > > Interesting: You claim that the Linux platform provides ways to retrieve > the needed information on FreeBSD, MS-WIN, ....? No. I claim that linux does have ways of retrieving the needed information. You can keep providing your own solution on freebsd, win & friends if you want, but _why_ do you want to do it in linux when linux can do it by itself?? There's no reason why cdrecord should care about duplicating existing functionality when the platform can provide that functionality for free. Let cdrecord (name it libscg) use SG_IO and let users use the /dev/hd*. The case of cdrecord remembers me of X.org, which used/is poking /dev/mem directly to discover PCI devices and/or play with framebuffers instead of using the available APIs in linux. Except that the X.org people wants to solve (or has already solved) such problems using the native available APIS instead of keeping their own solutions. Well-written cross-platform software implements all the features when needed by all the platforms as a whole but only uses such features when a particular platform needs it, unless using one of those features is a nightmare (which is not the case of SG_IO IMHO) ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 17:03 ` Joerg Schilling 2006-01-25 17:11 ` Matthias Andree 2006-01-25 17:18 ` grundig @ 2006-01-25 19:00 ` Tomasz Torcz 2006-01-26 10:25 ` Joerg Schilling 2 siblings, 1 reply; 717+ messages in thread From: Tomasz Torcz @ 2006-01-25 19:00 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, axboe, rlrevell, matthias.andree, linux-kernel, acahalan [-- Attachment #1: Type: text/plain, Size: 904 bytes --] On Wed, Jan 25, 2006 at 06:03:18PM +0100, Joerg Schilling wrote: > Jens Axboe <axboe@suse.de> wrote: > > > You just want the device naming to reflect that. The user should not > > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would > > likely be using k3b or something graphical though, and just click on his > > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could > > help do this dynamically even. > > Guess why cdrecord -scanbus is needed. > > It serves the need of GUI programs for cdrercord and allows them to retrieve > and list possible drives of interest in a platform independent way. GUI programs tend to retrieve this kind of info form HAL (http://freedesktop.org/wiki/Software_2fhal) -- Tomasz Torcz "Funeral in the morning, IDE hacking zdzichu@irc.-nie.spam-.pl in the afternoon and evening." - Alan Cox [-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --] ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 19:00 ` Tomasz Torcz @ 2006-01-26 10:25 ` Joerg Schilling 2006-01-26 10:56 ` Tomasz Torcz 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 10:25 UTC (permalink / raw) To: zdzichu, schilling Cc: rlrevell, matthias.andree, linux-kernel, jengelh, axboe, acahalan Tomasz Torcz <zdzichu@irc.pl> wrote: > > > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would > > > likely be using k3b or something graphical though, and just click on his > > > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could > > > help do this dynamically even. > > > > Guess why cdrecord -scanbus is needed. > > > > It serves the need of GUI programs for cdrercord and allows them to retrieve > > and list possible drives of interest in a platform independent way. > > GUI programs tend to retrieve this kind of info form HAL > (http://freedesktop.org/wiki/Software_2fhal) I am not sure what you like to tell with this. Programs that depend on specific Linux behavior tend to be non-portable (see e.g. nautilus on GNOME). Nautilus tries to get e.g. the drive write speeds by reading /prov/scsi/******. Besides the fact that this is not available elsewhere, it gives incorrect results because there are a lot of DVD writers with broken firmware. Cdrecord implements workarounds for this kind of problems and for this reason, the most portable solution for a GUI is to use cdrecord to retrieve the information. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 10:25 ` Joerg Schilling @ 2006-01-26 10:56 ` Tomasz Torcz 2006-01-26 14:11 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: Tomasz Torcz @ 2006-01-26 10:56 UTC (permalink / raw) To: Joerg Schilling Cc: rlrevell, matthias.andree, linux-kernel, jengelh, axboe, acahalan On Thu, Jan 26, 2006 at 11:25:49AM +0100, Joerg Schilling wrote: > Tomasz Torcz <zdzichu@irc.pl> wrote: > > > > > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would > > > > likely be using k3b or something graphical though, and just click on his > > > > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could > > > > help do this dynamically even. > > > > > > Guess why cdrecord -scanbus is needed. > > > > > > It serves the need of GUI programs for cdrercord and allows them to retrieve > > > and list possible drives of interest in a platform independent way. > > > > GUI programs tend to retrieve this kind of info form HAL > > (http://freedesktop.org/wiki/Software_2fhal) > > I am not sure what you like to tell with this. > > Programs that depend on specific Linux behavior tend to be non-portable (see > e.g. nautilus on GNOME). Nautilus tries to get e.g. the drive write speeds > by reading /prov/scsi/******. Besides the fact that this is not available > elsewhere, it gives incorrect results because there are a lot of DVD writers > with broken firmware. This is a fallback if HAL isn't available. Normally this is done by: drive->max_speed_write = libhal_device_get_property_int (ctx, device_names [i], "storage.cdrom.write_speed", NULL) / CD_ROM_SPEED; (natilus-burn-drive.c:1368 from version 2.12.0). > Cdrecord implements workarounds for this kind of problems and for this reason, > the most portable solution for a GUI is to use cdrecord to retrieve the > information. Yeah, sure. /* FIXME we don't have any way to guess the real device * from the info we get from CDRecord */ (the only FIXME in above mentioned file). -- Tomasz Torcz 72->| 80->| zdzichu@irc.-nie.spam-.pl 72->| 80->| ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 10:56 ` Tomasz Torcz @ 2006-01-26 14:11 ` Joerg Schilling 0 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 14:11 UTC (permalink / raw) To: zdzichu, schilling Cc: rlrevell, matthias.andree, linux-kernel, jengelh, axboe, acahalan Tomasz Torcz <zdzichu@irc.pl> wrote: > This is a fallback if HAL isn't available. Normally this is done by: > > drive->max_speed_write = libhal_device_get_property_int > (ctx, device_names [i], > "storage.cdrom.write_speed", > NULL) > / CD_ROM_SPEED; > > (natilus-burn-drive.c:1368 from version 2.12.0). Even if this works under good conditions, it will fail in many cases because the related software is not up to date with recent device formware bugs. Cdrecord is kept up to date as it either deals with a new drive or not. Delegating things to other instances only works ar long as there are clean ans stable interfaces. This unfortunately does not apply to CD/DVD/HD-DVD. > > Cdrecord implements workarounds for this kind of problems and for this reason, > > the most portable solution for a GUI is to use cdrecord to retrieve the > > information. > > Yeah, sure. > /* FIXME we don't have any way to guess the real device > * from the info we get from CDRecord */ > > (the only FIXME in above mentioned file). And guess why Sun is currently working on a work around this nautilus problem. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 15:30 ` Jens Axboe 2006-01-25 17:03 ` Joerg Schilling @ 2006-01-25 22:01 ` jerome lacoste 2006-01-26 12:13 ` Joerg Schilling 2006-01-26 20:42 ` Jan Engelhardt 2 siblings, 1 reply; 717+ messages in thread From: jerome lacoste @ 2006-01-25 22:01 UTC (permalink / raw) To: Jens Axboe Cc: Jan Engelhardt, Albert Cahalan, Linux Kernel Mailing List, rlrevell, schilling, matthias.andree On 1/25/06, Jens Axboe <axboe@suse.de> wrote: > On Wed, Jan 25 2006, Jan Engelhardt wrote: > > > > > > > >- you don't need -scanbus. If > > >users think they do, it's either because Joerg brain washed them or > > >because they have been used to that bad interface since years ago when > > >it was unfortunately needed. > > > > Now you're unfair. > > -scanbus does a nice output of what cdwriters (and other capable devices) > > are present. For me, that lists the cd writer and a CF slot from the > > multitype usb flash reader. > > > > There's one kind of not-so-advanced linux newbies that just go to walmart, > > buy a computer and whack a linux system on it for fun, and they still don't > > know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is > > usually a nightmare for them, and apart that -scanbus lists scsi > > host,id,lun instead of /dev/hd* (don't comment on this kthx), it is > > convenient for this sort of users to find out what's available. > > > > So, and what about that compactflash reader? It is subject to dynamic > > usb->scsi device association (depending on when you connect it, it may > > either become sda, or sdb, or sdc, etc.), and -scanbus yet again provides > > some way (albeit not useful, because it lists scsi,id,lun rather than > > /dev/sd* - don't comment either) to see where it actually is. > > You just want the device naming to reflect that. The user should not > need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would > likely be using k3b or something graphical though, and just click on his > Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could > help do this dynamically even. > > If you are using cdrecord on the command line, you are by definition an > advanced user and know how to find out where that writer is. > > -- > Jens Axboe As an non expert who just wants his boxes to work out of the box, I feel that the above message best represents the issue at end. Joerg seems to be concerned by 2 things: - the portability of his application accross various platforms - provide an end-to-end application for writing CDs from both the command line and to various 3rd party front ends. Providing a cross platform way to reference the devices seems to help him achieve that goal. Linux developers seem to see the world in a different way. Their main requirements: - compliance with the linux way of doing things - ultimately a front end should hide all the dirty details. That doesn't mean a command line version has to hide them as well, nor that cdrecord should be the interface to ask things the operating system can provide So it looks like: - from a cdrecord point ov view, Linux is broken. - from a Linux developers point of view, cdrecord is doing too much and forces things up. <very naively> As a developper with absolutely no competence in this area, I wonder something: I don't see why the way to refer to a device affects the ability to perform the functionality (write to it). Isn't it possible to reorganize the code in such a way that the burning part can be independent of the way the devices are referred to? I downloaded the code and quickly looked at it. If I am looking at the right version, it seems that the cdrecord code that relates to both cd burning + the Linux specific part is not that big (and very readable, thanks Joerg). So I really don't understand why this issue doesn't get fixed. </very naively> As with the communication problems between Joerg and the Linux developers, if someone was stepping up to be the bridge betweem the 2 parties, couldn't that minimize the risk of flame wars? cdrecord, how important is Linux to you? Linux, how important is cdrecord to you? If you 2 can't get along, just divorce! It's 2006 after all. And the code is open. Otherwise, talk together or use a counsellor and make this relationship work. Jerome ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 22:01 ` jerome lacoste @ 2006-01-26 12:13 ` Joerg Schilling 2006-01-26 12:39 ` Martin Mares 0 siblings, 1 reply; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 12:13 UTC (permalink / raw) To: jerome.lacoste, axboe Cc: schilling, rlrevell, matthias.andree, linux-kernel, jengelh, acahalan jerome lacoste <jerome.lacoste@gmail.com> wrote: > Joerg seems to be concerned by 2 things: > - the portability of his application accross various platforms > - provide an end-to-end application for writing CDs from both the > command line and to various 3rd party front ends. > Providing a cross platform way to reference the devices seems to help > him achieve that goal. Correct. > Linux developers seem to see the world in a different way. Their main > requirements: > - compliance with the linux way of doing things Which is unfortunately (in contrary to what cdrecord does) a moving target. > - ultimately a front end should hide all the dirty details. That > doesn't mean a command line version has to hide them as well, nor that > cdrecord should be the interface to ask things the operating system > can provide The best way of making a GUI portable is by making the underlying command line application portable and using the same CLI for every OS. > So it looks like: > - from a cdrecord point ov view, Linux is broken. > - from a Linux developers point of view, cdrecord is doing too much > and forces things up. BTW: There are still many people who run Linux-2.2 and many people told me that they will probably never upgrade from 2.4 to 2.6. On Linux-2.4, cdrecord's abstraction is the only way to hide the security relevent non-stable /dev/sg* <-> device relation. > <very naively> > > As a developper with absolutely no competence in this area, I wonder > something: I don't see why the way to refer to a device affects the > ability to perform the functionality (write to it). > > Isn't it possible to reorganize the code in such a way that the > burning part can be independent of the way the devices are referred > to? This is what cdrecord does! Cdrecord uses the OS and transport independent libscg/ > I downloaded the code and quickly looked at it. If I am looking at the > right version, it seems that the cdrecord code that relates to both cd > burning + the Linux specific part is not that big (and very readable, > thanks Joerg). So I really don't understand why this issue doesn't get > fixed. > > </very naively> I was never talking about cdrecord in special here but rather talkign about libscg which does not only deal with CD/DVD-writers but with any (even unknown) kind of SCSI devices. The real problen with many people on this list is that they ague in a way that might be correct in case that cdrecord would not use a anstracting library as libscg. In that case, some of the arguments may ne right....but we need to talk abut a generic SCSI transport - independent from the SCSI device type and from the SCSI transport that is used for that device. > cdrecord, how important is Linux to you? Linux was important between 1996 and ~ 2000. In that time, I got a lot of really exciting and valuable feedback from various kernel developers and in that time, Linux was the only way to use CD/DVD-writers with strange exotic transport interfaces. But the times are changing. During the past few years, some Linux kernel developers started a rather aggressive campaign against crecord and Linux did become less usable for CD/DVD writing than it has been before. Meanwhile other OS did step into the right direction. FreeBSD and Solaris added support for other SCSI transports and I now recommend to use FreeBSd or Solaris because things are a lot smoother on these OS. As an example: USB on Solaris is a lot more stable than on Linux. Timeout problems to not appear, I have been able to connect and mount my Nikon D70 out of the box on Solaris 9 (from November 2002) while Linux does not even see the camera on USB. Solaris has a device cache for removable media and offers stable /dev/* entries and stable major/minor numbers for hot plugged USB and other devices while Linux happyli creates new device entries for every reconnect. Discussions with FreeBSD and Solaris people are always friutful because these discussions stay technical. Solaris did fix all remaining issues with CD/DVD writing during the past 2 years and Solaris now is the free OS where CD/DVD writing works most smoothly. It seems that cdrecord does not need Linux anymore. Does Linux need cdrecord? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 12:13 ` Joerg Schilling @ 2006-01-26 12:39 ` Martin Mares 2006-01-26 14:14 ` Joerg Schilling 0 siblings, 1 reply; 717+ messages in thread From: Martin Mares @ 2006-01-26 12:39 UTC (permalink / raw) To: Joerg Schilling Cc: jerome.lacoste, axboe, rlrevell, matthias.andree, linux-kernel, jengelh, acahalan Hello! > > Linux developers seem to see the world in a different way. Their main > > requirements: > > - compliance with the linux way of doing things > > Which is unfortunately (in contrary to what cdrecord does) a moving target. Which is *fortunately* a moving target, because what served well 20 years ago is unlikely to serve equally well *now*. Having a stable naming of devices is a good goal, but in no way restricted to SCSI-like devices. What you suggest works only there, what Linux currently uses (udev etc.) works for all devices. Guess which is better for most users. > BTW: There are still many people who run Linux-2.2 and many people told me that > they will probably never upgrade from 2.4 to 2.6. Fine, so feel free consider Linux <2.6 and Linux 2.6 two completely separate operating systems. I did the same with the IP stack interface in the BIRD project and I consider it a very good step -- the old interface provided by Linux 2.0 and cluttered with BSD compatibility is almost unusable when compared to Netlink, but for sake of users who don't want to upgrade their kernel, BIRD is able to use the old one, though with limited functionality. > On Linux-2.4, cdrecord's abstraction is the only way to hide the security > relevent non-stable /dev/sg* <-> device relation. OK. So welcome to year 2006. And to Linux 2.6. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth How do I type 'for i in *.dvi ; do xdvi $i ; done' in a GUI? ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 12:39 ` Martin Mares @ 2006-01-26 14:14 ` Joerg Schilling 0 siblings, 0 replies; 717+ messages in thread From: Joerg Schilling @ 2006-01-26 14:14 UTC (permalink / raw) To: schilling, mj Cc: rlrevell, matthias.andree, linux-kernel, jerome.lacoste, jengelh, axboe, acahalan Martin Mares <mj@ucw.cz> wrote: > > On Linux-2.4, cdrecord's abstraction is the only way to hide the security > > relevent non-stable /dev/sg* <-> device relation. > > OK. So welcome to year 2006. And to Linux 2.6. When will Linux arrive in 2006 and support ATAPI and SCSI in general, not just ATAPI for hard disk drives and CD-ROMS? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 15:30 ` Jens Axboe 2006-01-25 17:03 ` Joerg Schilling 2006-01-25 22:01 ` jerome lacoste @ 2006-01-26 20:42 ` Jan Engelhardt 2006-01-27 8:00 ` Jens Axboe 2 siblings, 1 reply; 717+ messages in thread From: Jan Engelhardt @ 2006-01-26 20:42 UTC (permalink / raw) To: Jens Axboe Cc: Albert Cahalan, Linux Kernel Mailing List, rlrevell, schilling, matthias.andree >You just want the device naming to reflect that. The user should not >need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would >likely be using k3b or something graphical though, and just click on his >Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could >help do this dynamically even. And if you have multiple cdwriters? Then (cf. other posts) one has /dev/cdrecorder0 /dev/cdrecrder1, etc. To me, that's just as bad as having /dev/sg0 and /dev/sg1, because you don't have a clue at first sight what it maps to. "ls -l"? Sure, if cdrecorder0 was a symlink, but it does not work when it's not (= a block device in essence then). And I'm sure there's an analog program to "ls" to find what sg0 maps to. >If you are using cdrecord on the command line, you are by definition an >advanced user and know how to find out where that writer is. And GUIs could use arbitrary names like S:I:L. Ugly, but as long as it works... sigh. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-26 20:42 ` Jan Engelhardt @ 2006-01-27 8:00 ` Jens Axboe 2006-01-30 22:52 ` Bill Davidsen 0 siblings, 1 reply; 717+ messages in thread From: Jens Axboe @ 2006-01-27 8:00 UTC (permalink / raw) To: Jan Engelhardt Cc: Albert Cahalan, Linux Kernel Mailing List, rmatthias.andree On Thu, Jan 26 2006, Jan Engelhardt wrote: > > >You just want the device naming to reflect that. The user should not > >need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would > >likely be using k3b or something graphical though, and just click on his > >Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could > >help do this dynamically even. > > And if you have multiple cdwriters? Then (cf. other posts) one has > /dev/cdrecorder0 /dev/cdrecrder1, etc. To me, that's just as bad as having > /dev/sg0 and /dev/sg1, because you don't have a clue at first sight what it > maps to. /dev/plextorwriter and /dev/hpwriter or whatever, it's just naming. > "ls -l"? Sure, if cdrecorder0 was a symlink, but it does not work when it's > not (= a block device in essence then). > And I'm sure there's an analog program to "ls" to find what sg0 maps to. You expect the gui user to follow symlinks to find out? -- Jens Axboe ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-27 8:00 ` Jens Axboe @ 2006-01-30 22:52 ` Bill Davidsen 2006-01-31 2:04 ` Kyle Moffett 0 siblings, 1 reply; 717+ messages in thread From: Bill Davidsen @ 2006-01-30 22:52 UTC (permalink / raw) To: Jens Axboe; +Cc: Albert Cahalan, Linux Kernel Mailing List, rmatthias.andree Jens Axboe wrote: > On Thu, Jan 26 2006, Jan Engelhardt wrote: > >>>You just want the device naming to reflect that. The user should not >>>need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would >>>likely be using k3b or something graphical though, and just click on his >>>Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could >>>help do this dynamically even. >> >>And if you have multiple cdwriters? Then (cf. other posts) one has >>/dev/cdrecorder0 /dev/cdrecrder1, etc. To me, that's just as bad as having >>/dev/sg0 and /dev/sg1, because you don't have a clue at first sight what it >>maps to. > > > /dev/plextorwriter and /dev/hpwriter or whatever, it's just naming. > > >>"ls -l"? Sure, if cdrecorder0 was a symlink, but it does not work when it's >>not (= a block device in essence then). >>And I'm sure there's an analog program to "ls" to find what sg0 maps to. > > > You expect the gui user to follow symlinks to find out? > As opposed to? That's not a rhetorical question, please don't blow it off, what is the way for a user to go from /dev/sg0 to find out what device is really there? What is not easily available in Linux is a nice single place to find out what mass storage (disk/optical/floppy/ZIP/LS120/tape) devices are on the system, and what the system calls them. Because for low tech users udev is the problem, not the solution. The user doesn't want to tell the system what to call the device, he wants to see what's there, and that includes serial numbers of drives (where available) because if a user has several drives it's likely that they are identical. Telling the users to "cat /proc/scsi/scsi" and for n in /proc/ide/hd?; do echo -n "$n: "; cat $n/model; done is not a substitute for a presentation useful to programs and people alike. It could be in /proc or /sys or wherever is flavor of the day, but it would sure make things easier for the users. And before someone suggests that a program could generate this, a program would constantly chase the changing presentation of the information, a documented "file" in /proc or /sys would allow all applications to look in one place for the information. Instead of having the user tell the system what to call a device, let the system tell the user what it is called. Then the kernel could change without breaking anything in application land. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-30 22:52 ` Bill Davidsen @ 2006-01-31 2:04 ` Kyle Moffett 2006-02-16 16:20 ` Bill Davidsen 0 siblings, 1 reply; 717+ messages in thread From: Kyle Moffett @ 2006-01-31 2:04 UTC (permalink / raw) To: Bill Davidsen Cc: Jens Axboe, Albert Cahalan, Linux Kernel Mailing List, rmatthias.andree On Jan 30, 2006, at 17:52, Bill Davidsen wrote: > What is not easily available in Linux is a nice single place to > find out what mass storage (disk/optical/floppy/ZIP/LS120/tape) > devices are on the system, and what the system calls them. Yes it is available, and a whole slew of GUI applications use it. It's called "hal", or Hardware Abstraction Layer, and it has small hooks into udev and a bit of sysfs code so that it has a list of all devices of various types and knows what their associated udev-created device nodes are. This means that I can configure udev to put my CD drive on /dev/burner and correctly written GUI programs will just find it and work. > Because for low tech users udev is the problem, not the solution. > The user doesn't want to tell the system what to call the device, > he wants to see what's there, and that includes serial numbers of > drives (where available) because if a user has several drives it's > likely that they are identical. Your average low-tech user installing stock Debian (Not even something targeted at user-friendliness like Ubuntu), will end up with udev/hal installed. When he plugs in his burner, it will get the name /dev/cdrom[0-9] behind the scenes, and hal will notice. When he starts up k3b, it will use hal and automatically notice his drive, showing him brand, serial number, etc. > Instead of having the user tell the system what to call a device, > let the system tell the user what it is called. Uhh, both happen. The system tells userspace "I just got/have a device with brand 'foo', specs 'bar', serial 'baz', etc". Userspace (behind the scenes, without your low-tech user caring) creates a device node "/dev/cdrom[0-9]" and alerts hal, which sends it to your application, which nicely alerts the user. As an admin who does a lot on the command line, I can tie certain drive serial numbers to / dev/blue_burner and /dev/red_burner for my own ease-of-command-line- use without breaking the aforementioned hal system. Cheers, Kyle Moffett -- I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated. -- Poul Anderson ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-31 2:04 ` Kyle Moffett @ 2006-02-16 16:20 ` Bill Davidsen 2006-02-16 17:45 ` Olivier Galibert 0 siblings, 1 reply; 717+ messages in thread From: Bill Davidsen @ 2006-02-16 16:20 UTC (permalink / raw) To: Kyle Moffett Cc: Jens Axboe, Albert Cahalan, Linux Kernel Mailing List, rmatthias.andree Kyle Moffett wrote: > On Jan 30, 2006, at 17:52, Bill Davidsen wrote: > >> What is not easily available in Linux is a nice single place to find >> out what mass storage (disk/optical/floppy/ZIP/LS120/tape) devices >> are on the system, and what the system calls them. > > > Yes it is available, and a whole slew of GUI applications use it. > It's called "hal", or Hardware Abstraction Layer, and it has small > hooks into udev and a bit of sysfs code so that it has a list of all > devices of various types and knows what their associated udev-created > device nodes are. This means that I can configure udev to put my CD > drive on /dev/burner and correctly written GUI programs will just > find it and work. I was really talking about something stable. HAL is an application, and as such has to be changed avery time some developer has a bad dream and changes the interface, moves a comtrol or report from /proc to /sys, or otherwise requires a new way of interpreting the data. If you will, HAL *in* the kernel where it must work. > -- > I have yet to see any problem, however complicated, which, when you > looked at it in the right way, did not become still more complicated. > -- Poul Anderson -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-16 16:20 ` Bill Davidsen @ 2006-02-16 17:45 ` Olivier Galibert 0 siblings, 0 replies; 717+ messages in thread From: Olivier Galibert @ 2006-02-16 17:45 UTC (permalink / raw) To: Bill Davidsen Cc: Kyle Moffett, Jens Axboe, Albert Cahalan, Linux Kernel Mailing List, rmatthias.andree On Thu, Feb 16, 2006 at 11:20:02AM -0500, Bill Davidsen wrote: > I was really talking about something stable. HAL is an application, and > as such has to be changed avery time some developer has a bad dream and > changes the interface, moves a comtrol or report from /proc to /sys, or > otherwise requires a new way of interpreting the data. If you will, HAL > *in* the kernel where it must work. Sorry, the era of stability is over. Anything older than a year and half or so is obsolete and should be upgraded. To their honor Linus, Andrew and a small minority of others tried to keep stability as important, but given that the vast majority of the other developpers don't care they lost. For the kernel that means syscalls are stable, but everything filesystem isn't (proc and sysfs in particular) and change on a whim, and also ioctls, especially on vonluntarily undocumented kernel interfaces, are rather unstable. OG. ^ permalink raw reply [flat|nested] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-25 15:13 ` Jan Engelhardt 2006-01-25 15:30 ` Jens Axboe @ 2006-01-25 17:10 ` are added/removed - which 1 sibling, 0 replies; 717+ messages in thread From: are added/removed - which @ 2006-01-25 17:10 UTC (permalink / raw) To: Jan Engelhardt Cc: axboe, acahalan, linux-kernel, rlrevell, schilling, matthias.andree El Wed, 25 Jan 2006 16:13:46 +0100 (MET), Jan Engelhardt <jengelh@linux01.gwdg.de> escribió: > There's one kind of not-so-advanced linux newbies that just go to walmart, > buy a computer and whack a linux system on it for fun, and they still don't > know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is > usually a nightmare for them, and apart that -scanbus lists scsi > host,id,lun instead of /dev/hd* (don't comment on this kthx), it is > convenient for this sort of users to find out what's available. Wait - Looking at dmesg is a nightmare for newbies, but cdrecord -scanbus is not? Users should be show the available devices in a pretty GUI and for that to be possible, the kernel needs to provide a unified way to show userspace the available devices and notify them when they are added/removed - which happens to be sysfs + udev etc. libscg seems to want to replace the operative system for some tasks in the name of cross-platform compatibility. Sorry, but libscg is not the center of the world. It's fine that cdrecord does what it does for the apps for all those platforms where -scanbus and friends has sense, but linux just has SG_IO. libscg wanting to offer access to the "transport layer below /dev/hd*" looks like a layering design violation in operative systems like linux, but it is fine that cdrecord has it because it _is_ neccesary in other operative system which do things differently. Using the native features of a platform is a Good Thing when writing cross-platform software, ie: glib provides a "threading emulation" where threads are not available, but it uses the native pthreads if it's available. libscg wants to do everything everywhere, and that'd have sense if SG_IO weren't able to do what cdrecord needs, but AFAIK from the multiple flamewars I've seen, SG_IO does everything that cdrecord needs. I've not had a problem with SG_IO in years... ^ permalink raw reply [flat|nested] 717+ 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; 717+ 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] 717+ 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 2006-01-24 17:44 ` CD writing in future Linux (stirring up a hornets' nest) Bodo Eggert 0 siblings, 1 reply; 717+ 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] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-01-24 14:38 ` Joerg Schilling @ 2006-01-24 17:44 ` Bodo Eggert 0 siblings, 0 replies; 717+ messages in thread From: Bodo Eggert @ 2006-01-24 17:44 UTC (permalink / raw) To: Joerg Schilling; +Cc: rlrevell, matthias.andree, linux-kernel, 7eggert On Tue, 24 Jan 2006, Joerg Schilling wrote: > Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote: > > Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > [...] > > > On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh) > > > that calls getexecuser() in order to find whether there is a specific > > > treatment needed. If this specific treatment is needed, then the shell calls > > > execve(/usr/bin/pfexec cmd <args>) > > > else it calls execve(cmd <args>) > > > > > > I did recently voted to require all shells to be profile enabled by default. > > > > Why? I asume there will only be few programs requiring to be run by a > > wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo; > > echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo; > > chmod 755 /usr/bin/foo > > should be easier than patching e.g. all callers of cdrecord, and it won't > > slow down starting non-profiled applications. > > Because the architecture review commitee decided this would be the right way. > > Note that we are on a migration from the classical root/non-root UNIX to a fine > grained privileges handling. The current documentation says that you need to > have a profile enabled shell as your SHELL in order to be able to use a > root-less Solaris. If the shell was the only program calling cdrecord, this would work out as expected. -- My mail reader can beat up your mail reader. ^ permalink raw reply [flat|nested] 717+ 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; 717+ 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] 717+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 11:05 Rationale for RLIMIT_MEMLOCK? Arjan van de Ven @ 2006-01-23 16:54 ` Matthias Andree 2006-01-23 17:00 ` Arjan van de Ven 0 siblings, 1 reply; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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:38 ` Joerg Schilling 0 siblings, 1 reply; 717+ 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] 717+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 18:55 ` Matthias Andree @ 2006-01-23 19:38 ` Joerg Schilling 2006-01-23 20:30 ` Lee Revell 0 siblings, 1 reply; 717+ 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] 717+ messages in thread
* Re: Rationale for RLIMIT_MEMLOCK? 2006-01-23 19:38 ` Joerg Schilling @ 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 0 siblings, 1 reply; 717+ 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] 717+ 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-24 17:42 ` Jan Engelhardt 0 siblings, 1 reply; 717+ 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] 717+ 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-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 0 siblings, 2 replies; 717+ 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] 717+ 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 1 sibling, 2 replies; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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 1 sibling, 1 reply; 717+ 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] 717+ 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 0 siblings, 1 reply; 717+ 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] 717+ 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 0 siblings, 1 reply; 717+ 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] 717+ 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 17:00 ` Joerg Schilling 0 siblings, 1 reply; 717+ 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] 717+ 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 17:00 ` Joerg Schilling 2006-01-25 17:10 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 0 siblings, 1 reply; 717+ 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] 717+ 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) 0 siblings, 3 replies; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ messages in thread
* Rationale for RLIMIT_MEMLOCK? @ 2006-01-23 10:56 Matthias Andree 2006-02-02 17:17 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Luke-Jr 0 siblings, 1 reply; 717+ 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] 717+ 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-02-02 17:17 ` Luke-Jr 2006-02-03 14:08 ` Jan Engelhardt 2006-01-25 14:04 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Joerg Schilling 1 sibling, 1 reply; 717+ 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] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) 2006-02-02 17:17 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Luke-Jr @ 2006-02-03 14:08 ` Jan Engelhardt 2006-02-03 17:24 ` Luke-Jr 0 siblings, 1 reply; 717+ 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] 717+ 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 17:24 ` Luke-Jr 2006-02-06 13:51 ` Joerg Schilling 0 siblings, 1 reply; 717+ 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] 717+ 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 15:06 ` Peter Read 0 siblings, 1 reply; 717+ 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] 717+ 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 15:06 ` Peter Read 2006-02-06 15:15 ` CD writing in future Linux (stirring up a hornets' nest) Matthias Andree 0 siblings, 1 reply; 717+ 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] 717+ 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 0 siblings, 1 reply; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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 ` Joerg Schilling 2006-02-09 17:36 ` Martin Mares 2006-02-09 17:36 ` Jan Engelhardt 2 siblings, 2 replies; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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 ` Joerg Schilling 2 siblings, 1 reply; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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 2 siblings, 0 replies; 717+ 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] 717+ 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; 717+ 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] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:40 ` 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:40 ` 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-13 10:40 ` 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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 ` (2 more replies) 1 sibling, 3 replies; 717+ 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] 717+ 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-13 23:35 ` D. Hazelton 2 siblings, 0 replies; 717+ 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] 717+ 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 23:35 ` D. Hazelton 2 siblings, 1 reply; 717+ 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] 717+ 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; 717+ 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] 717+ 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-13 23:35 ` D. Hazelton 2 siblings, 0 replies; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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 ` D. Hazelton 0 siblings, 2 replies; 717+ 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] 717+ 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 ` D. Hazelton 1 sibling, 1 reply; 717+ 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] 717+ 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 0 siblings, 0 replies; 717+ 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] 717+ 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; 717+ 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] 717+ messages in thread
* Re: CD writing in future Linux (stirring up a hornets' nest) 2006-02-21 23:37 ` D. Hazelton @ 2006-02-22 17:13 ` Joerg Schilling 2006-02-22 17:30 ` Matthias Andree 0 siblings, 1 reply; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ 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; 717+ 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] 717+ messages in thread
end of thread, other threads:[~2006-02-28 0:44 UTC | newest] Thread overview: 717+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-25 2:58 CD writing in future Linux (stirring up a hornets' nest) Albert Cahalan 2006-01-25 16:31 ` Joerg Schilling 2006-01-25 16:56 ` Kyle Moffett 2006-01-25 17:08 ` Matthias Andree 2006-01-25 17:18 ` Joerg Schilling 2006-01-25 17:30 ` Matthias Andree 2006-01-26 9:50 ` Joerg Schilling 2006-01-26 10:34 ` jerome lacoste 2006-01-26 14:03 ` Joerg Schilling 2006-01-26 18:23 ` Gene Heskett 2006-01-26 19:38 ` jerome lacoste 2006-01-27 5:24 ` Valdis.Kletnieks 2006-01-27 13:15 ` Joerg Schilling 2006-01-27 14:09 ` Kyle Moffett 2006-01-27 23:28 ` Matthias Andree 2006-01-26 11:09 ` Matthias Andree 2006-01-25 18:17 ` Jens Axboe 2006-01-25 17:14 ` Joerg Schilling 2006-01-25 18:05 ` Kyle Moffett 2006-01-26 10:06 ` Joerg Schilling 2006-01-26 10:40 ` Matthias Andree 2006-01-26 14:05 ` Joerg Schilling [not found] ` <20060126103004.07e02876.seanlkml@sympatico.ca> 2006-01-26 15:30 ` sean 2006-01-25 23:08 ` Matthias Andree 2006-01-26 12:27 ` Joerg Schilling 2006-01-26 16:10 ` Vojtech Pavlik 2006-01-26 17:55 ` Olivier Galibert 2006-01-26 18:10 ` Vojtech Pavlik 2006-01-26 18:28 ` Olivier Galibert 2006-01-26 18:38 ` Jan Engelhardt 2006-01-26 19:07 ` Dmitry Torokhov 2006-01-26 19:24 ` Vojtech Pavlik 2006-01-26 19:51 ` Jan Engelhardt 2006-01-26 19:22 ` Vojtech Pavlik 2006-01-26 19:21 ` Vojtech Pavlik 2006-01-26 19:28 ` Diego Calleja 2006-01-26 19:44 ` Olivier Galibert 2006-01-26 20:13 ` Diego Calleja 2006-01-27 14:30 ` Joerg Schilling 2006-01-27 16:44 ` James Courtier-Dutton 2006-01-27 17:01 ` Jan Engelhardt 2006-01-30 11:43 ` Joerg Schilling 2006-01-30 12:04 ` Matthias Andree 2006-01-30 12:23 ` Christoph Hellwig 2006-01-30 16:15 ` Joerg Schilling 2006-02-04 11:17 ` Christoph Hellwig 2006-01-30 16:12 ` Joerg Schilling 2006-01-30 16:30 ` Matthias Andree 2006-01-30 16:34 ` Joerg Schilling 2006-01-30 17:05 ` Matthias Andree 2006-02-01 15:01 ` Jan Engelhardt 2006-01-30 16:35 ` Jeff Garzik 2006-01-30 16:46 ` Joerg Schilling 2006-02-01 15:06 ` Jan Engelhardt 2006-02-01 17:01 ` Joerg Schilling 2006-02-02 16:17 ` Jan Engelhardt 2006-02-03 11:32 ` Joerg Schilling 2006-02-03 13:45 ` Jan Engelhardt 2006-01-30 17:38 ` Jürg Billeter 2006-01-31 10:30 ` Joerg Schilling 2006-01-31 11:11 ` Martin Mares 2006-01-31 13:27 ` Joerg Schilling 2006-01-31 13:41 ` Matthias Andree 2006-01-31 13:42 ` Martin Mares 2006-02-01 15:19 ` Jan Engelhardt 2006-02-01 21:49 ` Ian Kester-Haney 2006-02-02 9:42 ` Joerg Schilling 2006-02-02 9:54 ` Martin Mares 2006-02-02 10:14 ` Matthias Andree 2006-01-31 12:10 ` Bartlomiej Zolnierkiewicz 2006-01-31 13:35 ` Joerg Schilling 2006-01-31 13:42 ` Matthias Andree 2006-01-31 13:49 ` Martin Mares 2006-01-31 14:23 ` Bartlomiej Zolnierkiewicz 2006-02-01 15:34 ` Jan Engelhardt 2006-02-01 15:49 ` Bartlomiej Zolnierkiewicz 2006-02-02 9:49 ` Joerg Schilling 2006-02-02 10:20 ` Matthias Andree 2006-02-02 11:28 ` Joerg Schilling 2006-02-02 12:46 ` Martin Mares 2006-02-02 10:21 ` Martin Mares 2006-02-02 13:18 ` Jens Axboe 2006-02-02 16:12 ` Jan Engelhardt 2006-01-31 12:24 ` jerome lacoste 2006-01-31 12:33 ` Oliver Neukum 2006-01-31 12:44 ` Denis Vlasenko 2006-02-01 15:37 ` Jan Engelhardt 2006-02-01 15:55 ` Bernd Petrovitsch 2006-02-02 15:24 ` Albert Cahalan 2006-02-01 15:56 ` Bartlomiej Zolnierkiewicz 2006-02-01 16:28 ` Jan Engelhardt 2006-02-01 17:51 ` Kyle Moffett 2006-02-02 7:59 ` Xavier Bestel 2006-02-02 11:19 ` Joerg Schilling 2006-02-02 11:34 ` Xavier Bestel 2006-02-02 12:51 ` Joerg Schilling 2006-02-02 13:02 ` Xavier Bestel 2006-02-03 9:55 ` Joerg Schilling 2006-02-03 10:05 ` Matthias Andree 2006-02-03 13:57 ` Jan Engelhardt 2006-02-03 15:50 ` Joerg Schilling 2006-02-03 10:57 ` Xavier Bestel 2006-02-02 13:24 ` grundig 2006-02-03 10:06 ` Joerg Schilling 2006-02-03 10:39 ` Matthias Andree 2006-02-02 16:20 ` Jan Engelhardt 2006-02-03 8:11 ` Alexander Samad 2006-01-31 12:32 ` Juerg Billeter 2006-01-31 13:37 ` Joerg Schilling 2006-01-31 13:44 ` Martin Mares 2006-02-02 6:28 ` Jim Crilly 2006-02-02 11:17 ` Joerg Schilling 2006-02-02 11:37 ` grundig 2006-02-02 12:15 ` Martin Mares 2006-02-02 12:24 ` Matthias Andree 2006-02-02 16:18 ` Jim Crilly 2006-02-02 17:17 ` Albert Cahalan 2006-02-02 20:39 ` Jan Engelhardt 2006-02-02 21:09 ` Jim Crilly 2006-02-02 21:20 ` Joerg Schilling 2006-02-02 21:46 ` Jim Crilly 2006-02-03 13:36 ` Joerg Schilling 2006-02-03 2:27 ` Albert Cahalan 2006-02-03 13:47 ` Jan Engelhardt 2006-02-03 15:20 ` Joerg Schilling 2006-02-03 15:53 ` Jim Crilly 2006-02-03 16:54 ` Joerg Schilling 2006-02-03 17:49 ` Krzysztof Halasa 2006-02-03 18:35 ` Jim Crilly 2006-02-03 18:57 ` Joerg Schilling 2006-02-03 18:04 ` Olivier Galibert 2006-02-03 18:13 ` Kay Sievers 2006-02-03 18:45 ` Olivier Galibert 2006-02-03 18:37 ` Jim Crilly 2006-02-04 15:35 ` Krzysztof Halasa 2006-02-04 15:43 ` Matthias Andree 2006-02-04 18:33 ` Jan Engelhardt 2006-02-05 7:40 ` Jan Engelhardt 2006-02-05 16:04 ` Krzysztof Halasa 2006-02-05 16:15 ` Phillip Susi 2006-02-05 17:50 ` Kyle Moffett 2006-02-05 21:15 ` Jan Engelhardt 2006-02-05 22:27 ` Neil Brown 2006-02-06 11:15 ` Krzysztof Halasa 2006-02-06 14:58 ` Jan Engelhardt 2006-02-06 18:17 ` Krzysztof Halasa 2006-02-06 18:37 ` Phillip Susi 2006-02-09 16:09 ` Jan Engelhardt 2006-02-03 19:50 ` Phillip Susi 2006-02-03 20:47 ` Olivier Galibert 2006-02-03 21:06 ` Phillip Susi 2006-02-04 0:02 ` Olivier Galibert 2006-02-04 16:56 ` Phillip Susi 2006-02-03 16:10 ` Phillip Susi 2006-02-03 16:56 ` Joerg Schilling 2006-02-03 19:06 ` Jan Engelhardt 2006-02-03 19:15 ` Joerg Schilling 2006-02-04 11:08 ` Jan Engelhardt 2006-02-03 19:22 ` Matthias Andree 2006-02-03 20:01 ` Phillip Susi 2006-02-03 18:20 ` [cdrtools PATCH (GPL)] " Matthias Andree 2006-02-03 18:31 ` Joerg Schilling 2006-02-03 18:42 ` Jim Crilly 2006-02-03 19:10 ` Joerg Schilling 2006-02-03 19:18 ` Jim Crilly 2006-02-03 19:28 ` Matthias Andree 2006-02-08 22:13 ` Pavel Machek 2006-02-09 20:10 ` jerome lacoste 2006-02-09 22:38 ` Matthias Andree 2006-02-10 12:11 ` Joerg Schilling 2006-02-10 12:24 ` jerome lacoste 2006-02-10 22:20 ` Matthias Andree 2006-02-03 19:14 ` Matthias Andree 2006-02-03 20:08 ` Joerg Schilling 2006-02-03 21:17 ` Matthias Andree 2006-02-02 21:25 ` Lee Revell 2006-02-02 21:49 ` Jim Crilly 2006-02-02 21:54 ` Lee Revell 2006-02-02 21:56 ` Lee Revell 2006-02-03 8:54 ` Jens Axboe 2006-02-03 13:29 ` Joerg Schilling 2006-02-03 13:51 ` Jan Engelhardt 2006-02-03 14:05 ` Kay Sievers 2006-02-03 16:48 ` Joerg Schilling 2006-02-03 16:47 ` Joerg Schilling 2006-02-03 13:25 ` Joerg Schilling 2006-02-01 15:39 ` [OT] " Jan Engelhardt 2006-01-31 16:43 ` Paul Jakma 2006-02-01 5:07 ` Albert Cahalan 2006-02-01 21:45 ` Paul Jakma 2006-01-30 21:02 ` Bill Davidsen 2006-01-30 11:25 ` Joerg Schilling 2006-01-26 2:26 ` Albert Cahalan 2006-01-26 8:19 ` Matthias Andree 2006-01-26 13:53 ` Joerg Schilling 2006-01-26 13:50 ` Joerg Schilling 2006-01-26 16:56 ` Matan Peled 2006-01-27 11:05 ` Joerg Schilling 2006-01-26 18:42 ` Jan Engelhardt 2006-01-27 0:19 ` Albert Cahalan 2006-01-27 0:40 ` Kyle Moffett 2006-01-27 8:21 ` Xavier Bestel 2006-01-27 8:26 ` DervishD 2006-01-30 21:49 ` Bill Davidsen 2006-01-30 21:57 ` Matthias Andree 2006-01-30 22:12 ` Lee Revell 2006-02-16 16:15 ` Bill Davidsen [not found] <515e525f0602141110r7a96568av4705c2a353407e6@mail.gmail.com> 2006-02-14 19:13 ` Joerg Schilling 2006-02-14 19:51 ` Anders Karlsson [not found] <5E0mO-7c4-25@gated-at.bofh.it> [not found] ` <5E0wj-7nC-1@gated-at.bofh.it> [not found] ` <5E0Q5-7Nq-37@gated-at.bofh.it> [not found] ` <5EgBc-5nU-9@gated-at.bofh.it> [not found] ` <5En0E-6QU-27@gated-at.bofh.it> [not found] ` <5En9R-73g-13@gated-at.bofh.it> [not found] ` <5EnCS-7Qt-35@gated-at.bofh.it> [not found] ` <5EnW8-8go-3@gated-at.bofh.it> [not found] ` <5EnWo-8go-31@gated-at.bofh.it> [not found] ` <5EEkg-7AS-41@gated-at.bofh.it> [not found] ` <5EEX1-8py-41@gated-at.bofh.it> [not found] ` <5EFJk-1bU-31@gated-at.bofh.it> 2006-02-12 16:03 ` Bodo Eggert -- strict thread matches above, loose matches on Subject: below -- 2006-02-11 8:59 Andrey Borzenkov 2006-02-09 17:38 Zoltan Boszormenyi 2006-02-09 22:33 ` Sam Vilain [not found] <5yJ3h-6er-11@gated-at.bofh.it> [not found] ` <5yVQR-8bI-39@gated-at.bofh.it> [not found] ` <5yWah-99-29@gated-at.bofh.it> [not found] ` <5yWjN-Bl-13@gated-at.bofh.it> [not found] ` <5yWDl-111-23@gated-at.bofh.it> [not found] ` <5yWML-1ea-5@gated-at.bofh.it> [not found] ` <5zc5f-6pi-3@gated-at.bofh.it> 2006-01-26 14:27 ` Heikki Orsila 2006-01-27 2:25 ` Robert Hancock [not found] ` <5yWts-OZ-21@gated-at.bofh.it> [not found] ` <5z1Wj-TN-31@gated-at.bofh.it> [not found] ` <5zer2-1BC-29@gated-at.bofh.it> [not found] ` <5AFHY-5jd-23@gated-at.bofh.it> [not found] ` <5ALb5-5kV-43@gated-at.bofh.it> [not found] ` <5B15G-39W-17@gated-at.bofh.it> [not found] ` <5B1Im-4cW-7@gated-at.bofh.it> [not found] ` <5B3TN-7AV-9@gated-at.bofh.it> [not found] ` <5Bs5Z-1BT-17@gated-at.bofh.it> [not found] ` <5BJgx-1fE-13@gated-at.bofh.it> 2006-02-02 23:29 ` Bodo Eggert 2006-02-03 13:54 ` Joerg Schilling 2006-02-03 19:30 ` Matthias Andree 2006-02-06 14:46 ` Joerg Schilling 2006-02-06 17:37 ` René Rebe 2006-02-06 17:43 ` Bodo Eggert 2006-02-07 10:56 ` Matthias Andree 2006-01-25 3:23 Albert Cahalan 2006-01-25 14:26 ` Jan Engelhardt 2006-01-25 14:45 ` Jens Axboe 2006-01-25 15:13 ` Jan Engelhardt 2006-01-25 15:30 ` Jens Axboe 2006-01-25 17:03 ` Joerg Schilling 2006-01-25 17:11 ` Matthias Andree 2006-01-25 17:18 ` grundig 2006-01-25 17:31 ` Jens Axboe 2006-01-25 18:22 ` Matthias Andree 2006-01-25 18:25 ` Jens Axboe 2006-01-25 23:14 ` Matthias Andree 2006-01-26 1:13 ` grundig 2006-01-26 8:23 ` Matthias Andree 2006-01-26 13:56 ` Joerg Schilling 2006-01-26 18:47 ` Jan Engelhardt 2006-01-30 21:58 ` Bill Davidsen 2006-01-26 13:41 ` Joerg Schilling 2006-01-26 0:36 ` Nix 2006-01-26 13:39 ` Joerg Schilling 2006-02-10 21:06 ` Bill Davidsen [not found] ` <20060210184241.35332e78.seanlkml@sympatico.ca> 2006-02-10 23:42 ` sean 2006-02-10 23:51 ` Christian Neumair 2006-02-13 13:24 ` Joerg Schilling 2006-02-13 13:55 ` Martin Mares 2006-02-13 15:17 ` Joerg Schilling 2006-02-18 13:47 ` Bill Davidsen 2006-02-19 1:10 ` D. Hazelton 2006-02-19 9:20 ` Matthias Andree 2006-02-20 1:53 ` D. Hazelton 2006-02-20 16:41 ` Joerg Schilling 2006-02-20 18:40 ` D. Hazelton 2006-02-21 10:08 ` Joerg Schilling 2006-02-21 10:20 ` Matthias Andree 2006-02-21 4:11 ` D. Hazelton 2006-02-21 10:36 ` Joerg Schilling 2006-02-24 19:46 ` Christian Neumair 2006-02-27 11:32 ` Joerg Schilling 2006-02-20 16:05 ` Joerg Schilling 2006-02-20 18:53 ` D. Hazelton 2006-02-20 22:30 ` Martin Schlemmer 2006-02-21 8:32 ` Jens Axboe 2006-02-21 10:19 ` Joerg Schilling 2006-02-21 10:23 ` Jens Axboe 2006-02-13 14:07 ` jerome lacoste 2006-02-13 15:26 ` Joerg Schilling 2006-02-13 15:42 ` jerome lacoste 2006-02-13 16:43 ` Jan Engelhardt 2006-02-13 17:27 ` Luke-Jr 2006-02-14 8:11 ` Jan Engelhardt 2006-02-14 0:01 ` D. Hazelton 2006-02-14 13:59 ` Joerg Schilling 2006-02-10 23:56 ` Greg KH 2006-02-12 12:04 ` Olivier Galibert 2006-02-12 16:46 ` Greg KH 2006-02-12 21:14 ` Olivier Galibert 2006-02-12 21:49 ` Krzysztof Halasa 2006-02-13 6:24 ` Greg KH 2006-02-13 16:49 ` Olivier Galibert 2006-02-13 17:50 ` Greg KH 2006-02-13 5:01 ` Daniel Barkalow 2006-02-13 6:21 ` Greg KH 2006-02-13 8:05 ` Daniel Barkalow 2006-02-13 17:51 ` Greg KH 2006-02-13 18:03 ` Dmitry Torokhov 2006-02-13 19:09 ` Daniel Barkalow 2006-02-17 21:35 ` Bill Davidsen 2006-02-18 0:02 ` D. Hazelton 2006-02-18 16:56 ` Bill Davidsen 2006-02-19 0:29 ` D. Hazelton 2006-02-18 0:35 ` Greg KH 2006-02-18 12:06 ` Christoph Hellwig 2006-02-18 13:37 ` Martin Michlmayr 2006-02-18 13:52 ` Christoph Hellwig 2006-02-19 12:04 ` Jens Axboe 2006-02-18 17:15 ` Gene Heskett 2006-02-19 0:41 ` D. Hazelton 2006-02-19 5:44 ` Gene Heskett 2006-02-19 9:27 ` Matthias Andree 2006-02-27 20:23 ` Bill Davidsen 2006-02-19 18:50 ` Daniel Barkalow 2006-02-18 18:36 ` Chris Adams 2006-02-19 1:05 ` D. Hazelton 2006-02-27 20:24 ` Bill Davidsen 2006-02-27 21:21 ` Chris Adams 2006-02-27 21:47 ` D. Hazelton 2006-02-27 22:30 ` Peter Gordon 2006-02-27 22:24 ` D. Hazelton 2006-02-28 0:44 ` Sam Vilain 2006-02-13 13:26 ` Joerg Schilling 2006-02-13 15:49 ` Greg KH 2006-02-14 18:59 ` Joerg Schilling 2006-02-14 19:53 ` Matthias Andree 2006-02-14 19:58 ` Joerg Schilling 2006-02-14 20:25 ` Matthias Andree 2006-02-14 22:35 ` D. Hazelton 2006-02-14 22:32 ` D. Hazelton 2006-02-14 18:59 ` Olivier Galibert 2006-02-14 19:01 ` Bill Davidsen 2006-02-14 22:33 ` Nix 2006-02-15 15:44 ` Jan Engelhardt 2006-02-15 16:40 ` Olivier Galibert 2006-02-15 17:07 ` Greg KH 2006-02-13 22:14 ` Nix 2006-02-14 0:03 ` D. Hazelton 2006-02-14 0:32 ` Nix 2006-02-14 9:22 ` Matthias Andree 2006-02-14 18:09 ` Jan Engelhardt 2006-02-14 18:41 ` Olivier Galibert 2006-02-17 15:36 ` Jan Engelhardt 2006-02-14 11:27 ` Joerg Schilling 2006-02-14 22:30 ` Greg KH 2006-02-15 0:43 ` Matthias Andree 2006-02-15 5:20 ` Greg KH 2006-02-16 12:01 ` Matthias Andree 2006-02-16 16:51 ` Randy.Dunlap 2006-02-16 18:03 ` Greg KH 2006-02-14 22:40 ` Nix 2006-02-16 12:09 ` Joerg Schilling 2006-02-16 12:36 ` Martin Mares 2006-02-17 0:38 ` Nix [not found] ` <43F746B8.6080607@tmr.com> 2006-02-18 21:04 ` Martin Mares 2006-02-18 22:00 ` Ondrej Zary 2006-02-16 12:55 ` Marc Koschewski 2006-02-13 12:11 ` Joerg Schilling [not found] ` <515e525f0602130446s1091f09ande10910f65a0f5f0@mail.gmail.com> 2006-02-13 15:12 ` Joerg Schilling 2006-02-13 16:40 ` Jan Engelhardt 2006-02-13 23:24 ` D. Hazelton 2006-02-14 13:55 ` Joerg Schilling 2006-02-14 21:59 ` D. Hazelton [not found] ` <43F74884.50904@tmr.com> 2006-02-18 20:00 ` Nix 2006-01-26 10:11 ` Joerg Schilling 2006-01-25 19:04 ` Olivier Galibert 2006-01-26 9:38 ` Joerg Schilling 2006-01-26 9:45 ` Lee Revell 2006-01-26 13:58 ` Joerg Schilling 2006-01-26 14:09 ` Nick Piggin 2006-01-26 14:32 ` Joerg Schilling 2006-01-26 15:16 ` Nick Piggin 2006-01-26 16:04 ` Matthias Andree 2006-01-26 15:38 ` grundig 2006-01-25 19:00 ` Tomasz Torcz 2006-01-26 10:25 ` Joerg Schilling 2006-01-26 10:56 ` Tomasz Torcz 2006-01-26 14:11 ` Joerg Schilling 2006-01-25 22:01 ` jerome lacoste 2006-01-26 12:13 ` Joerg Schilling 2006-01-26 12:39 ` Martin Mares 2006-01-26 14:14 ` Joerg Schilling 2006-01-26 20:42 ` Jan Engelhardt 2006-01-27 8:00 ` Jens Axboe 2006-01-30 22:52 ` Bill Davidsen 2006-01-31 2:04 ` Kyle Moffett 2006-02-16 16:20 ` Bill Davidsen 2006-02-16 17:45 ` Olivier Galibert 2006-01-25 17:10 ` are added/removed - which [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 2006-01-24 17:44 ` CD writing in future Linux (stirring up a hornets' nest) Bodo Eggert 2006-01-23 11:05 Rationale for RLIMIT_MEMLOCK? 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:38 ` Joerg Schilling 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-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 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-23 10:56 Rationale for RLIMIT_MEMLOCK? Matthias Andree 2006-02-02 17:17 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Luke-Jr 2006-02-03 14:08 ` Jan Engelhardt 2006-02-03 17:24 ` Luke-Jr 2006-02-06 13:51 ` Joerg Schilling 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-10 10:58 ` 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-13 10:40 ` 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 23:35 ` 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 23:37 ` 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
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).