Re: Updated ATAPI/CAM patches
hi, there! On Thu, Feb 28, 2002 at 09:58:00PM +0100, Søren Schmidt wrote: Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did patches for this long ago, but noone picked it up as a port... what about cdrdao? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Max Khon wrote: On Thu, Feb 28, 2002 at 09:58:00PM +0100, S?ren Schmidt wrote: Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did patches for this long ago, but noone picked it up as a port... what about cdrdao? Since cdrdao uses the cdrecord backend (at least it did last time I looked), that should be an easy one... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
According to Thomas Quinot: is one known pending issue with this code: on *some* machines, patched kernels hang at boot time, immediately after registering Thomas knows it already but I'd to mention that one of these machines is a dual PIII/800 running 4.4-STABLE/SMP. I haven't tried the patch recently but will do soon. I wasn't able to give a backtrace as DDB is not reachable when the machine hangs. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
This is definitly something that is needed.. The question is whether the CAM and ATAPI authors feel it is right. We are guided by them (even though we desperatly need this). Personally even if not perfect.. it's better than nothing and we should probably commit something like it. or based on it.. (having looked at it I think it seems fine.) So here's my vote for a quick commit. On Thu, 28 Feb 2002, Thomas Quinot wrote: An updated version of the ATAPI/CAM patches is available from http://www.cuivre.fr.eu.org/~thomas/atapicam/ This version contains no functional changes, but synchronize with recent modifications to the generic ATAPI code. As always, I would be interested in any feedback. Specifically, there is one known pending issue with this code: on *some* machines, patched kernels hang at boot time, immediately after registering the new CAM sim. If it hangs on your machine and you can provide a backtrace of the point where the freeze occurs, it would be most helpful. Enjoy, Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
On Thu, Feb 28, 2002 at 10:49:18 -0800, Julian Elischer wrote: This is definitly something that is needed.. The question is whether the CAM and ATAPI authors feel it is right. We are guided by them (even though we desperatly need this). Personally even if not perfect.. it's better than nothing and we should probably commit something like it. or based on it.. (having looked at it I think it seems fine.) I think it's a good idea as well. So here's my vote for a quick commit. No. See below. There are still problems with it. It probably also needs to be reviewed before it goes in. But yes, it is a good idea. On Thu, 28 Feb 2002, Thomas Quinot wrote: An updated version of the ATAPI/CAM patches is available from http://www.cuivre.fr.eu.org/~thomas/atapicam/ This version contains no functional changes, but synchronize with recent modifications to the generic ATAPI code. As always, I would be interested in any feedback. Specifically, there is one known pending issue with this code: on *some* machines, patched kernels hang at boot time, immediately after registering the new CAM sim. If it hangs on your machine and you can provide a backtrace of the point where the freeze occurs, it would be most helpful. Enjoy, Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-scsi in the body of the message Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Kenneth D. Merry wrote: On Thu, Feb 28, 2002 at 10:49:18 -0800, Julian Elischer wrote: This is definitly something that is needed.. The question is whether the CAM and ATAPI authors feel it is right. We are guided by them (even though we desperatly need this). Personally even if not perfect.. it's better than nothing and we should probably commit something like it. or based on it.. (having looked at it I think it seems fine.) I think it's a good idea as well. Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? So here's my vote for a quick commit. No. See below. There are still problems with it. I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. There are alot of issues here that needs solutions. It will need a *serious* maintainer that handles all aspects of it, especially dealing with error reports for one thing, technically it needs to be brought to a state where it works on alot more HW that seems to be the case for now, and the integration into the ATA driver should be dealt with a bit differently. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
I think it's better to commit it now and have it fixed in situ. It's new functionality so committing it with bugs will not break anyone. it will however get more work done on it and more testing. On Thu, 28 Feb 2002, Kenneth D. Merry wrote: On Thu, Feb 28, 2002 at 10:49:18 -0800, Julian Elischer wrote: This is definitly something that is needed.. The question is whether the CAM and ATAPI authors feel it is right. We are guided by them (even though we desperatly need this). Personally even if not perfect.. it's better than nothing and we should probably commit something like it. or based on it.. (having looked at it I think it seems fine.) I think it's a good idea as well. So here's my vote for a quick commit. No. See below. There are still problems with it. It probably also needs to be reviewed before it goes in. Well you are one of the main CAM peopel.. we are relying on you and Soeren. But yes, it is a good idea. On Thu, 28 Feb 2002, Thomas Quinot wrote: An updated version of the ATAPI/CAM patches is available from http://www.cuivre.fr.eu.org/~thomas/atapicam/ This version contains no functional changes, but synchronize with recent modifications to the generic ATAPI code. As always, I would be interested in any feedback. Specifically, there is one known pending issue with this code: on *some* machines, patched kernels hang at boot time, immediately after registering the new CAM sim. If it hangs on your machine and you can provide a backtrace of the point where the freeze occurs, it would be most helpful. Enjoy, Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-scsi in the body of the message Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
On Thu, 28 Feb 2002, Søren Schmidt wrote: I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. What? Are you looking at the same patches that everyone else is? I'd expect this sort of foot-dragging if the patch were intrusive to the ATA drivers but its not. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
In message [EMAIL PROTECTED], Jul ian Elischer writes: I think it's better to commit it now and have it fixed in situ. It's new functionality so committing it with bugs will not break anyone. it will however get more work done on it and more testing. [...] Well you are one of the main CAM peopel.. we are relying on you and Soeren. Hmm, let me try that line of logic for a moment: I think we should have an Amdahl 6600 port of FreeBSD and we should commit it right now. [...] Well, you (Julian) you seem to have nothing to do.. we are relying on you and some other random people we can think of. Sounds weird, doesn't it ? I don't know what axe you are grinding Julian, but if you are not the one to do the work, I don't think you are in a position to ask for commit it now and have it fixed in situ. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Matthew N. Dodd wrote: On Thu, 28 Feb 2002, Søren Schmidt wrote: I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. What? Are you looking at the same patches that everyone else is? Read the rest of my mail, the problem is not the patches as much as it is all the issues getting it to work and helping users that has problems with it. I have more than enough to do already, getting X mails extra a day asking why app XX doesn't work with drive YY is not what I'm looking for. I'd expect this sort of foot-dragging if the patch were intrusive to the ATA drivers but its not. As I have stated several times, I have no problem with ATAPI being sent through CAM as long as the usual way stays (some of us cannot afford the weight of those extra layers, nor loose functionality). I'd do the integration somewhat differently to even further minimise the diffs, but that is really not the issue here... So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
On Thu, Feb 28, 2002 at 02:45:04PM -0500, Matthew N. Dodd wrote: On Thu, 28 Feb 2002, Søren Schmidt wrote: I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. What? Are you looking at the same patches that everyone else is? I'd expect this sort of foot-dragging if the patch were intrusive to the ATA drivers but its not. FWIW, I'll volunteer as a tester. I need this functionality. I've applied the patch to -stable and used it extensively with not even the slightest hint of problems. I'd offer to help maintain it, but a) I'm not a committer, b) I don't think I have the time right now, and c) I'm not familiar enough with ATA/ATAPI, CAM, or the patches to be an effective maintainer. Not to mention it's not my code. :-) -- Christopher Nielsen - Metal-wielding pyro techie [EMAIL PROTECTED] Those who are willing to trade freedom for security deserve neither freedom nor security. --Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) What functionality is lost by this ability? So here's my vote for a quick commit. No. See below. There are still problems with it. I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. There are alot of issues here that needs solutions. It will need a *serious* maintainer that handles all aspects of it, especially dealing with error reports for one thing, technically it needs to be brought to a state where it works on alot more HW that seems to be the case for now, and the integration into the ATA driver should be dealt with a bit differently. If it has so many problems... why not just clean it up? Just curious... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
Poul-henning. What crack are you on? Have you looked at the patches in question? They are small and non-intrusive. We are relying on the ATA maintainer to tell us whether they are dangerous, but they are so small that we should look at fast-tracking them if possible. Even if it was broken, it's new amd non intrusive so it wouldn't break anything except itself. It's functionalityu that we've wanted for a long time but haven't had. Now it's handed to us on a plate and somehow you don't like that? On Thu, 28 Feb 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Jul ian Elischer writes: I think it's better to commit it now and have it fixed in situ. It's new functionality so committing it with bugs will not break anyone. it will however get more work done on it and more testing. [...] Well you are one of the main CAM peopel.. we are relying on you and Soeren. Hmm, let me try that line of logic for a moment: I think we should have an Amdahl 6600 port of FreeBSD and we should commit it right now. [...] Well, you (Julian) you seem to have nothing to do.. we are relying on you and some other random people we can think of. Sounds weird, doesn't it ? No, Have some KSE suggestions? or some for a fully working correct DEVFS (unlike the one we have now)? let me know.. I don't know what axe you are grinding Julian, but if you are not the one to do the work, I don't think you are in a position to ask for commit it now and have it fixed in situ. Poul, I've reviewed it and find it ok. The only reason to have the ATA reviewer look at it is because he is just that: teh ATA maintainer. It's a low risk commit. what axe are you grinding? Since you have nothing whatsoever to add? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
where dod sis post his email..? I never saw it On Thu, 28 Feb 2002, Kenneth Culver wrote: Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) What functionality is lost by this ability? So here's my vote for a quick commit. No. See below. There are still problems with it. I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. There are alot of issues here that needs solutions. It will need a *serious* maintainer that handles all aspects of it, especially dealing with error reports for one thing, technically it needs to be brought to a state where it works on alot more HW that seems to be the case for now, and the integration into the ATA driver should be dealt with a bit differently. If it has so many problems... why not just clean it up? Just curious... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
On Thu, 2002-02-28 at 12:57, Sxren Schmidt wrote: It seems Matthew N. Dodd wrote: On Thu, 28 Feb 2002, Søren Schmidt wrote: I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. What? Are you looking at the same patches that everyone else is? Read the rest of my mail, the problem is not the patches as much as it is all the issues getting it to work and helping users that has problems with it. I have more than enough to do already, getting X mails extra a day asking why app XX doesn't work with drive YY is not what I'm looking for. I'd expect this sort of foot-dragging if the patch were intrusive to the ATA drivers but its not. As I have stated several times, I have no problem with ATAPI being sent through CAM as long as the usual way stays (some of us cannot afford the weight of those extra layers, nor loose functionality). I'd do the integration somewhat differently to even further minimise the diffs, but that is really not the issue here... So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) -Søren I'll raise my hand here. I've been keenly interested in this for a while, since it will make my UDF work much simpler. I'm also getting my feet wet in CAM, and I have the two CAM gurus nearby if things get too hairy. I fully indend for this to be a cooperative effort with Thomas; I'm mainly raising my hand to take the abuse that will no doubt happen once in a while. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Kenneth Culver wrote: Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did patches for this long ago, but noone picked it up as a port... What functionality is lost by this ability? Compare the features of the ATAPI vs SCSI CD drivers.. If it has so many problems... why not just clean it up? Just curious... Fine by me, but do you also volounteer the time and expertise to do that ? This is the usual case of we want it all but noone is willing to invest the time and energy to keep it floating. I'll state it again, I have no problem with having ATAPI being available through CAM, I'll even do the initial commit to ensure integration is done in a way I can live with in the ATA/ATAPI driver. But I do have a problem with what comes after that, I do *not* have the time nor motivation for keeping this working and upto date, let alone answering end user questions about what works and what doesn't. Do you guys have any idea what amount of time it takes to keep modern device drivers etc up to date on HW that gets new versions and types by the week ? I could use the hours I put into this each and every week (and have done for the past 3 years in case of the ATA/ATAPI driver mind you) for playing with my kids or take the vife for a dinner in town, so excuse me for beeing a little bit pissed when you say why not just clean it up... Now, I ask for someone with the time, the knowledge and the motivation to do the maintenance work on this when/if it gets into the sources, thats all. This is a volounteer driven project guys, you give some and then you may be getting some.. I'm getting tired of giving and only getting requests for more in return... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Scott Long wrote: As I have stated several times, I have no problem with ATAPI being sent through CAM as long as the usual way stays (some of us cannot afford the weight of those extra layers, nor loose functionality). I'd do the integration somewhat differently to even further minimise the diffs, but that is really not the issue here... So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) I'll raise my hand here. I've been keenly interested in this for a while, since it will make my UDF work much simpler. I'm also getting my Hmm, your UDF code should know nothing about the lower layers, but we've been over that already :) feet wet in CAM, and I have the two CAM gurus nearby if things get too hairy. I fully indend for this to be a cooperative effort with Thomas; I'm mainly raising my hand to take the abuse that will no doubt happen once in a while. Sure, maybe we should make Thomas a committer so he could look after it himself ? Interested ? Got the time ? I'm all ears for volounteers... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
On Thu, 2002-02-28 at 14:06, Søren Schmidt wrote: It seems Scott Long wrote: As I have stated several times, I have no problem with ATAPI being sent through CAM as long as the usual way stays (some of us cannot afford the weight of those extra layers, nor loose functionality). I'd do the integration somewhat differently to even further minimise the diffs, but that is really not the issue here... So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) I'll raise my hand here. I've been keenly interested in this for a while, since it will make my UDF work much simpler. I'm also getting my Hmm, your UDF code should know nothing about the lower layers, but we've been over that already :) Yes, and hopefully the filesystem won't have to care, but tools like newfs_udf will. feet wet in CAM, and I have the two CAM gurus nearby if things get too hairy. I fully indend for this to be a cooperative effort with Thomas; I'm mainly raising my hand to take the abuse that will no doubt happen once in a while. Sure, maybe we should make Thomas a committer so he could look after it himself ? Interested ? Got the time ? I'm all ears for volounteers... Ummm, I'm volunteering to shepherd these initiatives. The thought of making Thomas a committer had crossed my mind, but I hadn't brought it up with anyone yet. If you're not comfortable with me volunteering for this, please say so. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
What functionality is lost by this ability? Compare the features of the ATAPI vs SCSI CD drivers.. This is exactly why I'd like to see this code merged. The hardware changes too rapidly. The specs change too rapidly but MMC is MMC. More of us are getting wives we need to take out to dinner and children to play with, so having duplicated functionality like this just ensures that too many of us are sacrificing our free time instead of working together to get a clean solution. I will go on record right now and as I've said before, there are changes that are needed in CAM land in order for me to accept this change. Due to the growing pressure to get this stuff in, I'll work with Scott and Ken to make sure we have *the right* solution for this in the next couple of weeks. Thomas' code is a great prototype, but we need to do this right so that Soren can concentrate on making X, Y, and Z new ATA chip work, we can collaborate on making our MMC device support the best in the OpenSource world, and we all have free time left over to tend to our personal lives. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Justin T. Gibbs wrote: What functionality is lost by this ability? Compare the features of the ATAPI vs SCSI CD drivers.. This is exactly why I'd like to see this code merged. The hardware changes too rapidly. The specs change too rapidly but MMC is MMC. Exactly. More of us are getting wives we need to take out to dinner and children to play with, so having duplicated functionality like this just ensures that too many of us are sacrificing our free time instead of working together to get a clean solution. I will go on record right now and as I've said before, there are changes that are needed in CAM land in order for me to accept this change. Due to the growing pressure to get this stuff in, I'll work with Scott and Ken to make sure we have *the right* solution for this in the next couple of weeks. Thomas' code is a great prototype, but we need to do this right so that Soren can concentrate on making X, Y, and Z new ATA chip work, we can collaborate on making our MMC device support the best in the OpenSource world, and we all have free time left over to tend to our personal lives. Agreed, but that means that not only CAM but also the SCSI CD driver needs to learn lots of new tricks, but if that can be done I'm all ears.. Are we done with the commit it quickly now ? :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Scott Long wrote: I'm mainly raising my hand to take the abuse that will no doubt happen once in a while. Sure, maybe we should make Thomas a committer so he could look after it himself ? Interested ? Got the time ? I'm all ears for volounteers... Ummm, I'm volunteering to shepherd these initiatives. The thought of making Thomas a committer had crossed my mind, but I hadn't brought it up with anyone yet. If you're not comfortable with me volunteering for this, please say so. I have no problem with you doing it, I was just fishing for getting Thomas into the net also, we need all the hands we can get :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
Wow /that's/ a thread ;) On Thu, 28 Feb 2002, Søren Schmidt wrote: I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. First of all I'd like to make two points: * Søren is doing a great job as ATA maintainer, and it would be a Bad Thing to have him quit; * I am not particularly pushing for quick integration of the code into the system. Quite some review and debugging is in order, as well as some discussion with the CAM team as to how to properly handle variations in devices' command sets (the current patch intercepts and translates some SCSI commands on the fly -- this is working, but a ugly hack.) Read the rest of my mail, the problem is not the patches as much as it is all the issues getting it to work and helping users I have been maintaining the patch and helping users with it since the time I first published it. It is none of my intentions to impose upon anyone else the burden of taking care of it. As I have stated several times, I have no problem with ATAPI being sent through CAM as long as the usual way stays As far as I was able to determine, my patch does not prevent the use of the existing ATAPI devices. If it does break them, I'd be more than willing to make any necessary changes to remedy that. So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) What I can offer is serious commitment from a non-presently-committer. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
Le 2002-02-28, Søren Schmidt écrivait : I have no problem with you doing it, I was just fishing for getting Thomas into the net also, we need all the hands we can get :) As I mentioned I am entirely willing to take charge of the care and feeding of the bugs I wrote. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Updated ATAPI/CAM patches
I think Thomas is doing here a quite good job and it is also to him to decide to include his sources and maybe maintain them. The ata sources have changed a lot the last weeks, so until Thomas thinks his sources are under heavy development too, both should do their jobs and we've some patches from Thomas. If you include it now one depends of the other and you may get into the problem of both altering the code from the other at the same time. The (somewhat selfish) behavior to include it and give maintainership to someone else leads to a originator stopping his work or the creation of 2 parallel solutions. Isn't it better the core team (or someone else thinking (s)he's a better idea) supports Thomas and a stable and good solution is integrated later (maybe with maintainership of Thomas)? Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Updated ATAPI/CAM patches
We have CVS Why not commit the prototype now and update it as people get the corner cases worked out? The code doesn't interfere with either the CAM system or the ATAPI system that I can see. On Thu, 28 Feb 2002, Jan Stocker wrote: I think Thomas is doing here a quite good job and it is also to him to decide to include his sources and maybe maintain them. The ata sources have changed a lot the last weeks, so until Thomas thinks his sources are under heavy development too, both should do their jobs and we've some patches from Thomas. If you include it now one depends of the other and you may get into the problem of both altering the code from the other at the same time. The (somewhat selfish) behavior to include it and give maintainership to someone else leads to a originator stopping his work or the creation of 2 parallel solutions. Isn't it better the core team (or someone else thinking (s)he's a better idea) supports Thomas and a stable and good solution is integrated later (maybe with maintainership of Thomas)? Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Updated ATAPI/CAM patches
On Thu, 2002-02-28 at 23:15, Julian Elischer wrote: We have CVS Okay.. thats a piece software.. Why not commit the prototype now and update it as people get the corner cases worked out? If Thomas can and will maintain it, ok... else read my comment from my last mail... The code doesn't interfere with either the CAM system or the ATAPI system that I can see. So lately atapi_softc disapperead (o.k. has been renamed). So what to do... is the person who made the change responsible to change the affected code (maybe changing this struct causes something more than find/replace the old name) or do you want to wait for the maintainer to fix it and kernel is broken for this time. So you need a person who really want this, have time and the knowledge to do it. You cant check it in and lets see what happens. Jan On Thu, 28 Feb 2002, Jan Stocker wrote: I think Thomas is doing here a quite good job and it is also to him to decide to include his sources and maybe maintain them. The ata sources have changed a lot the last weeks, so until Thomas thinks his sources are under heavy development too, both should do their jobs and we've some patches from Thomas. If you include it now one depends of the other and you may get into the problem of both altering the code from the other at the same time. The (somewhat selfish) behavior to include it and give maintainership to someone else leads to a originator stopping his work or the creation of 2 parallel solutions. Isn't it better the core team (or someone else thinking (s)he's a better idea) supports Thomas and a stable and good solution is integrated later (maybe with maintainership of Thomas)? Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-scsi in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
Umm, I don't remember where he posted it, but it wasn't posted privately. Most likely since I'm using pine, it was posted to freebsd-current and freebsd-scsi. Ken On Thu, 28 Feb 2002, Julian Elischer wrote: where dod sis post his email..? I never saw it On Thu, 28 Feb 2002, Kenneth Culver wrote: Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) What functionality is lost by this ability? So here's my vote for a quick commit. No. See below. There are still problems with it. I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. There are alot of issues here that needs solutions. It will need a *serious* maintainer that handles all aspects of it, especially dealing with error reports for one thing, technically it needs to be brought to a state where it works on alot more HW that seems to be the case for now, and the integration into the ATA driver should be dealt with a bit differently. If it has so many problems... why not just clean it up? Just curious... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did patches for this long ago, but noone picked it up as a port... I remember you saying that you had these, but you weren't willing to release them for some reason; something to do with the GPL... What functionality is lost by this ability? Compare the features of the ATAPI vs SCSI CD drivers.. Yes, but the way the author implements this, he's not using the scsi cd drivers... he's just using the SCSI pass interfaces. If it has so many problems... why not just clean it up? Just curious... Fine by me, but do you also volounteer the time and expertise to do that ? This is the usual case of we want it all but noone is willing to invest the time and energy to keep it floating. Well, I'd be glad to maintain it if I had 3 things... commiter status, knowledge of the ATA subsystem, and knowledge of the CAM subsystem. Right now I don't know much about any of these mainly because I havn't had time to look. I'll state it again, I have no problem with having ATAPI being available through CAM, I'll even do the initial commit to ensure integration is done in a way I can live with in the ATA/ATAPI driver. But I do have a problem with what comes after that, I do *not* have the time nor motivation for keeping this working and upto date, let alone answering end user questions about what works and what doesn't. Do you guys have any idea what amount of time it takes to keep modern device drivers etc up to date on HW that gets new versions and types by the week ? I could use the hours I put into this each and every week (and have done for the past 3 years in case of the ATA/ATAPI driver mind you) for playing with my kids or take the vife for a dinner in town, so excuse me for beeing a little bit pissed when you say why not just clean it up... Well, I didn't mean it to piss anyone off... just a question really... Now, I ask for someone with the time, the knowledge and the motivation to do the maintenance work on this when/if it gets into the sources, thats all. This is a volounteer driven project guys, you give some and then you may be getting some.. I'm getting tired of giving and only getting requests for more in return... As I've said before, I'd love to contribute to FreeBSD in anyplace that needs contributed to, I really just don't know where to start. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
