PATCH: cdrecord: avoiding scsi device numbering for ide devices
Quoted 2 lines · Joerg Schilling
Linux users like to call cdrecord -scanbus and they like to see _all_ SCSI devices from a single call to cdrecord.
If you really think so, you've been smoking crack. Users _hate_ to call "cdrecord -scanbus". They don't see why it should be needed. The normal reaction to reading your documentation goes something like this:
"What the fuck? Can't I just give it a device name?"
Alternately:
"Uh... I don't have SCSI. I guess I need a different program."
Heck, you could do the silly -scanbus thing internally if you must. Then users wouldn't get it wrong and wouldn't have to screw with it.
Quoted 6 lines
Looks like a typical answer from somebody who's thoughts are limited to a Linux environment. Take into account, that cdrecord runs on more than 30 different platforms and that several of these platforms do not have device nodes like UNIX has. Cdrecord has been implemented to use a portable addressing method.
I'm sure a Windows user would want to use something like a drive letter. So... give it to them. Not even a Solaris user would really want to use raw SCSI notation. On all platforms, people want to use the native naming system.
Quoted 3 lines
The fact that the Linux kernel does not return instance numbers for
/dev/hd*SCSI devices makes it impossible to implement a unique address space :-(
We have a unique address space: the /dev directory
We don't need a second address space.
Quoted 4 lines
If you like to compile an application that uses kernel interfaces, you need to make sure that both, the application and the kernel are compiled with the same "interface description" which is just the kernel include files.
No change to the kernel headers would allow you to produce a binary on an old system that makes use of new features. The only way this can work is if you bring your own headers.
I use kernel interfaces all the time in procps. For the old and standard ones, I rely on the C library. For all the rest, I have my own header files. This works great.
I can compile procps on a system with the 2.4.xx kernel and 2.4.xx headers. Then, I can take this binary to a system with the 2.2.xx or 2.6.x kernel and expect it to work great. That's 3 major kernel revisions: 2.2.xx, 2.4.xx, and 2.6.x. Really, it's not hard.
Quoted 2 lines
I wish that discussions with the Linux kernel hackers would be as easy and fruitful as they are with the Solaris kernel hackers.
You're trying to force Linux developers to comply with Solaris interfaces. You should try things the other way and see how far you get. If you don't get far, you're being unfair. If you do get far, well, isn't that good?
Quoted 1 line
Just make sure not to use a broken version from the SuSE source tree....
I wonder why SuSE felt they needed to patch your code. While I've found that some vendors are really crazy about breaking things, SuSE has been pretty good.
If everyone around you seems to be insane, maybe it's you.
Quoted 2 lines
Let's see whether "Linux" is open enough to listen to the demands of the users......
How about cdrecord? Demands of the users:
1. tools built with headers derived from Linux 2.2.xx will take full advantage of Linux 2.6.xx features
2. tools built with headers derived from Linux 2.6.x will still work on the oldest Linux you support
3. in all cases, including SCSI, the /dev/* name is used (the Solaris and Windows users would love that as well)
Quoted 5 lines · Albert Cahalan
Quoted 2 lines · Joerg Schilling
Linux users like to call cdrecord -scanbus and they like to see _all_ SCSI devices from a single call to cdrecord.
If you really think so, you've been smoking crack.
Please, no insults. I like this cdrecord -scanbus too, but I would like it more, if it would also print pure ide devices ;)
On the other hand I usually also don't care since k3b does all this stuff for me.
Quoted 5 lines
Users _hate_ to call "cdrecord -scanbus". They don't see why it should be needed. The normal reaction to reading your documentation goes something like this:
"What the fuck? Can't I just give it a device name?"
Well, the usual reaction is 'cdrecord whats that? Commandline interface, parameters? Hey, I want to burn a CD and don't like reading manpages for stuff like that'. I guess that at least 95% of all people who would like to burn a CD will prefer (and also use) a grahical interface.
The hole discussion which cdrecord -dev parameter to use is completely useless, it only effects a clear minority of developers and guys who probably don't like graphical interfaces at at all. Those guys should be able to adopt to whatever -dev option is possible.
Please, calm down and return to usefull technical discussions.
Bernd