Messages in this thread | | | Date | Thu, 15 Jan 2004 12:17:54 -0500 | From | Bill Davidsen <> | Subject | Re: smp dead lock of io_request_lock/queue_lock patch |
| |
Doug Ledford wrote:
> More or less. But part of it also is that a lot of the patches I've > written are on top of other patches that people don't want (aka, the > iorl patch). I've got a mlqueue patch that actually *really* should go > into mainline because it solves a slew of various problems in one go, > but the current version of the patch depends on some semantic changes > made by the iorl patch. So, sorting things out can sometimes be > difficult. But, I've been told to go ahead and do what I can as far as > getting the stuff out, so I'm taking some time to try and get a bk tree > out there so people can see what I'm talking about. Once I've got the > full tree out there, then it might be possible to start picking and > choosing which things to port against mainline so that they don't depend > on patches like the iorl patch.
If it leads to a more stable kernel, I don't see why iorl can't go in (user perspective) because RH is going to maintain it instead of trying to find a developer who is competent and willing to do the boring task of backfitting bugfixes to sub-optimal code.
The only problem I see would be getting testing before calling it stable. Putting out a "giant SCSI patch" for test, then into a -test kernel should solve that. The fact that RH is stuck supporting this for at least five years is certainly both motivation and field test for any changes ;-)
Clearly Marcello has the decision, but it looks from here as if stability would be improved by something like this. Assuming that no other vendor objects, of course.
-- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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/
| |