Hi, Jens opened a packet-cd project at Sourceforge.Net but it's out of date ... What about setting up a CVS tree here? Gerald -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
On Wed, Mar 28 2001, Gerald Haese wrote:
Hi,
Jens opened a packet-cd project at Sourceforge.Net but it's out of date ... What about setting up a CVS tree here?
It's out of date because the project has been dormit for some time. A CVS tree is a PITA to maintain for something that is essentially just a kernel patch, so that won't happen. The method of distribution will be patches only. -- Jens Axboe
On Wed, 28 Mar 2001, Jens Axboe wrote:
On Wed, Mar 28 2001, Gerald Haese wrote:
Hi,
Jens opened a packet-cd project at Sourceforge.Net but it's out of date ... What about setting up a CVS tree here?
It's out of date because the project has been dormit for some time. A CVS tree is a PITA to maintain for something that is essentially just a kernel patch, so that won't happen. The method of distribution will be patches only.
Actually, CVS was originally written by a company that was tracking their own modified version of a Sun kernel source tree. You wouldn't need to go to the trouble of actually tracking the entire kernel source tree, though. You could import just the kernel files you're changing (tagged with the Linux kernel version each came from) and have CVS generate patches that people can apply to their kernel source trees. (It would also be easier to keep parallel branches from different base kernel versions.) What would it take to get this project to the point where you only need to distribute a kernel module (which you could then pre-compile) and not need to patch the kernel at all? (This probably would require getting certain patches integrated into the mainstream kernel distribution, but that's not uncommon...) On a separate note, is there any packet-writing code available that does NOT require a kernel patch, but does everything from application space in user mode? This would avoid the risk of crashing, and allow an application (such as a backup utility) to be created without requiring a special kernel to run. If this doesn't exist, could it be adapted from the existing patch or would it be impossible for some reason? Deven
On Fri, Mar 30 2001, Deven T. Corzine wrote:
On Wed, Mar 28 2001, Gerald Haese wrote:
Hi,
Jens opened a packet-cd project at Sourceforge.Net but it's out of date ... What about setting up a CVS tree here?
It's out of date because the project has been dormit for some time. A CVS tree is a PITA to maintain for something that is essentially just a kernel patch, so that won't happen. The method of distribution will be patches only.
Actually, CVS was originally written by a company that was tracking their own modified version of a Sun kernel source tree. You wouldn't need to go to the trouble of actually tracking the entire kernel source tree, though. You could import just the kernel files you're changing (tagged with the Linux kernel version each came from) and have CVS generate patches that people can apply to their kernel source trees. (It would also be easier to keep parallel branches from different base kernel versions.)
That may very well be, but from my maintenance standpoint it would be a hassle. And that pretty much in itself means it's not going to happen :-)
What would it take to get this project to the point where you only need to distribute a kernel module (which you could then pre-compile) and not need to patch the kernel at all? (This probably would require getting certain patches integrated into the mainstream kernel distribution, but that's not uncommon...)
Hard to say at this point. It is actually pretty independent now, so it's shouldn't be too hard.
On a separate note, is there any packet-writing code available that does NOT require a kernel patch, but does everything from application space in user mode? This would avoid the risk of crashing, and allow an application (such as a backup utility) to be created without requiring a special kernel to run. If this doesn't exist, could it be adapted from the existing patch or would it be impossible for some reason?
Not to my knowledge. You can take a look at cdrwtool though, it has an option to write a file with packet writing to a disc, using the CDROM_SEND_PACKET ioctl. Writing a user app to do it all and using the same backend should not be too hard :) -- Jens Axboe
On Wed, 4 Apr 2001, Jens Axboe wrote:
On Fri, Mar 30 2001, Deven T. Corzine wrote:
Actually, CVS was originally written by a company that was tracking their own modified version of a Sun kernel source tree. You wouldn't need to go to the trouble of actually tracking the entire kernel source tree, though. You could import just the kernel files you're changing (tagged with the Linux kernel version each came from) and have CVS generate patches that people can apply to their kernel source trees. (It would also be easier to keep parallel branches from different base kernel versions.)
That may very well be, but from my maintenance standpoint it would be a hassle. And that pretty much in itself means it's not going to happen :-)
I understand. I'm just saying it's not necessarily as bad as you might think it would be...
What would it take to get this project to the point where you only need to distribute a kernel module (which you could then pre-compile) and not need to patch the kernel at all? (This probably would require getting certain patches integrated into the mainstream kernel distribution, but that's not uncommon...)
Hard to say at this point. It is actually pretty independent now, so it's shouldn't be too hard.
Well, it certainly would be nice if people could work with the code without having to recompile their kernel to do so...
On a separate note, is there any packet-writing code available that does NOT require a kernel patch, but does everything from application space in user mode? This would avoid the risk of crashing, and allow an application (such as a backup utility) to be created without requiring a special kernel to run. If this doesn't exist, could it be adapted from the existing patch or would it be impossible for some reason?
Not to my knowledge. You can take a look at cdrwtool though, it has an option to write a file with packet writing to a disc, using the CDROM_SEND_PACKET ioctl. Writing a user app to do it all and using the same backend should not be too hard :)
Is cdrwtool in the Linux-UDF package, or is there a better place to look? Can CDROM_SEND_PACKET be used for variable-length packets? Where could I find documentation on this and other CDROM ioctls? What other information would I need to write such an application in user space? (Should I try to combine code from cdrecord and cdrwtool, maybe?) I'm very interested in making some sort of backup application using variable-length packets, and I'd rather not force the use of a kernel module or patches... Deven
On Wed, Apr 04 2001, Deven T. Corzine wrote:
That may very well be, but from my maintenance standpoint it would be a hassle. And that pretty much in itself means it's not going to happen :-)
I understand. I'm just saying it's not necessarily as bad as you might think it would be...
Oh I understand that, I've just never been a big fan of cvs for a lot of things.
What would it take to get this project to the point where you only need to distribute a kernel module (which you could then pre-compile) and not need to patch the kernel at all? (This probably would require getting certain patches integrated into the mainstream kernel distribution, but that's not uncommon...)
Hard to say at this point. It is actually pretty independent now, so it's shouldn't be too hard.
Well, it certainly would be nice if people could work with the code without having to recompile their kernel to do so...
Exactly.
Not to my knowledge. You can take a look at cdrwtool though, it has an option to write a file with packet writing to a disc, using the CDROM_SEND_PACKET ioctl. Writing a user app to do it all and using the same backend should not be too hard :)
Is cdrwtool in the Linux-UDF package, or is there a better place to look?
Yes
Can CDROM_SEND_PACKET be used for variable-length packets? Where could I
You can use CDROM_SEND_PACKET for _anything_, it's basically a simple interface to submit packet commands to a CDROM.
find documentation on this and other CDROM ioctls? What other information
drivers/cdrom/cdrom.c is probably the best place to look, the documentation is out of date...
would I need to write such an application in user space? (Should I try to combine code from cdrecord and cdrwtool, maybe?) I'm very interested in making some sort of backup application using variable-length packets, and I'd rather not force the use of a kernel module or patches...
Stay far away from cdrecord... You may be able to get some hints from what it does, you may or may not need that depending on how much you know about CDROM's and packet writing already. I can't really way what else you would need, it depends heavily on how you want to design this thing. -- Jens Axboe
On Wed, 4 Apr 2001, Jens Axboe wrote:
Oh I understand that, I've just never been a big fan of cvs for a lot of things.
I have some mixed feelings about CVS, but mostly I think it's a good thing. There are some hassles involved, though.
Well, it certainly would be nice if people could work with the code without having to recompile their kernel to do so...
Exactly.
So why aren't we there now? ;-)
Can CDROM_SEND_PACKET be used for variable-length packets? Where could I
You can use CDROM_SEND_PACKET for _anything_, it's basically a simple interface to submit packet commands to a CDROM.
Is CDROM_SEND_PACKET only for packet-writing commands, or does it send generic packets to the CDROM to implement any command at all?
find documentation on this and other CDROM ioctls? What other information
drivers/cdrom/cdrom.c is probably the best place to look, the documentation is out of date...
What if I'm using IDE-SCSI emulation? How does that change things?
would I need to write such an application in user space? (Should I try to combine code from cdrecord and cdrwtool, maybe?) I'm very interested in making some sort of backup application using variable-length packets, and I'd rather not force the use of a kernel module or patches...
Stay far away from cdrecord... You may be able to get some hints from what it does, you may or may not need that depending on how much you know about CDROM's and packet writing already.
What's wrong with cdrecord? Why should I stay away? I'm familiar with the concepts behind CD burning and packet writing, but not the API-level details.
I can't really way what else you would need, it depends heavily on how you want to design this thing.
All I want is an "ultimate" CD backup system. See my message of 8 Sep 2000 for a lot more detail about what I've been thinking of. I don't know if I'll ever write this application I'm visualizing, but I think it would be worthwhile. I don't know for certain whether I would make it free software or maybe try to sell it -- it would take a lot of work to implement, and if it could generate a revenue stream, I might be able to make more software with that support. (Even if I were to sell it, I'd include source code...) If you can't find my old message, I can re-send it to you (or the list)... Deven
On Wed, Apr 04 2001, Deven T. Corzine wrote:
Well, it certainly would be nice if people could work with the code without having to recompile their kernel to do so...
Exactly.
So why aren't we there now? ;-)
Why don't I have a date with Kate Moss? Seriously, right now the patch isn't exactly rock solid. And having the whole patch thing is a good mechanism to weed out folks who wouldn't be able to help out anyway.
Can CDROM_SEND_PACKET be used for variable-length packets? Where could I
You can use CDROM_SEND_PACKET for _anything_, it's basically a simple interface to submit packet commands to a CDROM.
Is CDROM_SEND_PACKET only for packet-writing commands, or does it send generic packets to the CDROM to implement any command at all?
Look at it! It's a _generic_ interface for any _generic_ packet command.
find documentation on this and other CDROM ioctls? What other information
drivers/cdrom/cdrom.c is probably the best place to look, the documentation is out of date...
What if I'm using IDE-SCSI emulation? How does that change things?
No
would I need to write such an application in user space? (Should I try to combine code from cdrecord and cdrwtool, maybe?) I'm very interested in making some sort of backup application using variable-length packets, and I'd rather not force the use of a kernel module or patches...
Stay far away from cdrecord... You may be able to get some hints from what it does, you may or may not need that depending on how much you know about CDROM's and packet writing already.
What's wrong with cdrecord? Why should I stay away?
If you need to ask, you clearly haven't looked.
I'm familiar with the concepts behind CD burning and packet writing, but not the API-level details.
The concepts? Are you familiar with how it works at the drive level, how you set it up, etc? If not, then you probably need to either study some source or find documents describing how it works in general. -- Jens Axboe
On Thu, 5 Apr 2001, Jens Axboe wrote:
So why aren't we there now? ;-)
Why don't I have a date with Kate Moss?
Don't ask me, ask her! :-)
Seriously, right now the patch isn't exactly rock solid. And having the whole patch thing is a good mechanism to weed out folks who wouldn't be able to help out anyway.
True, but it also weeds out people who might be able to help. I haven't tested the patch yet because I haven't had time to recompile my kernel, and I don't want to take down my machine while it's running some services. (And given the probability of crashing, I may wait until those services move back to the machine they belong on.)
Is CDROM_SEND_PACKET only for packet-writing commands, or does it send generic packets to the CDROM to implement any command at all?
Look at it! It's a _generic_ interface for any _generic_ packet command.
I assume you mean the latter by "packet" then, not just commands that happen to be specific to packet-writing functionality.
What if I'm using IDE-SCSI emulation? How does that change things?
No
No, it doesn't change things, or no, don't use IDE-SCSI emulation? The problem is that cdparanoia and/or cdrecord _really_ wanted IDE-SCSI emulation mode, which is why I have it turned on. Shouldn't it be more or less equivalent to use the SCSI-generic-packet mechanisms?
What's wrong with cdrecord? Why should I stay away?
If you need to ask, you clearly haven't looked.
Of course I haven't. Did I ever suggest that I had? In any case, I take it from your response that you consider cdrecord poorly written. If that's the case, I'm sure I would have discovered that as soon as I got around to looking at the code. Still, it does work, so there may be insights to be gained from it. (For example, it knows how to support the "BURN-Proof" feature of my Plextor burner...) My more fundamental concern about cdrecord is simply that it's so low-level and not integrated with the data-generating side of things. It would be clumsy to create an ext2fs filesystem in a file and use "dd" to copy it to a floppy or ZIP drive, yet creating an ISO filesystem and using cdrecord is routine practice with CD burners. There's nothing wrong with the approach, but I'd sure prefer something more transparent and better integrated...
I'm familiar with the concepts behind CD burning and packet writing, but not the API-level details.
The concepts? Are you familiar with how it works at the drive level, how you set it up, etc? If not, then you probably need to either study some source or find documents describing how it works in general.
I understand the concepts -- the differences between DAO, SAO, TAO and packet-writing, the difference between fixed-length and variable-length packets, how finalizing works, etc. I know how to make and burn ISO images or rip and burn audio CD's under Linux. I'm familiar with the process in general (most of which can be found at cdrfaq.org) and specifics at the application level as a user of the software. As I said, I'm not familiar with the API-level details. To write programs doing any of this stuff, I'd obviously need some reference materials at hand, which is exactly why I asked where such documentation might be found. I'm a very capable programmer; this just happens to be a niche I've never done any programming in. I never considered doing it blindly. I can probably get pretty far just from studying the code in cdrwtool, cdrecord, cdparanoia, the Linux kernel, your patch, and anything else relevant that I can turn up. I'd prefer to also have some canonical reference material about what commands the drives are supposed to support and how they're supposed to work, since I'm sure some of the existing code has bugs that would be difficult to discover solely through inspection without reference to canonical sources. But, in the worst-case scenario, I'll can do some trial-and-error and hope for the best... I have no concern about my ability to write the code I'm contemplating (assuming I can find the necessary references), but I'm very concerned that I may never find the time. My life is terribly busy, and will remain so for the foreseeable future. I have many interesting projects I'd like to be able to pay attention to, but they can't all get my full attention. I'll just have to wait and see how it turns out. Deven
participants (3)
-
Deven T. Corzine -
Gerald Haese -
Jens Axboe