Remigiusz Modrzejewski wrote: > But in the end, it would invariably mean a lot of work, swinging patches back > and forth and convincing people that you're right about this code. And it > would probably end up being accepted in less than 100%. Then, Herbert > explicitly stated that maintaining 80% in-tree and 20% out-tree is exactly > the thing he's trying to avoid... > > Anyways, you're welcome to try. And it would be a great thing if you > succeeded. 80% in-tree and 20% out-tree is much better than 100% out tree. I don't understand the argument that this would be worse. It will *never* happen that 100% of the patch will go into the kernel tree in one linux release, or even 2 or 3. I've seen that already with a driver ivtv. First they needed to implement necessary kernel API and get that included. Then the driver started moving into the kernel. It took about about a dozen kernel releases to get all the stuff in there, but it is done now. This is how kernel development works - small changes. This is why monolithic patches like grsecurity, PaX or vserver can't be accepted. Patches have to come in some kind of a logical sequence. Now if we get vserver into the kernel, you will not see a lot of kernel changes that would break vserver per-say. This also mean that vserver would have to use standard API for most of the isolation instead of intrusive patches. - Adam