Eric W. Biederman wrote:
>I certainly have not. I do feel that developing this just from the
>top down is the wrong way to do this.
>
>
OK, you said "just" the top down. That's fine, I can agree with that.
Obviously if any of the implementation of the top down features hits
ugliness that needs refactoring, that refactoring has to go first.
>In some of the preliminary
>patches we have found several pieces of code that we will have to
>touch that is currently in need of a cleanup. That is why I have
>been cleaning up /proc. sysctl is in need of similar treatment
>but is in less bad shape.
>
>
I made a preliminary attempt to rebase the /proc hooks atop of your
work. I looked forward to being ready for if a patchset like this got
adopted to -mm to be able to hand that piece over :-).
The reason I didn't persue that to completion was I wasn't sure how I
would then submit it - relative to the -mm tree? I didn't want to
include your patches in my series.
It would be nice if someone could make a git branch on kernel.org for
each -mm release so it can be more easily imported to a git tree. Sure,
`stg import' might take a while for all 1,400 patches, but that's OK -
so long as Andrew's not waiting for it :-).
>I don't think that is the case on the fundamentals. I think with pids
>I am an inch away from implementing a pid namespace that is both
>recursive, efficient, and can map all of the pids into another pid
>space if that is desirable. Plus I can merge most of it incrementally
>in the existing kernel, before I even allow for multiple pid spaces.
>
>Which should reduce the patch for multiple pid namespaces to something
>reasonable to talk about.
>
>
Well I see pids as just another virtualisable entity, but OK... if you
come up with anything I'm happy to rebase atop it.
>>What about going back to the very simple "struct container" on which to
>>build?
>>
>>
>
>I guess my problem there is that isn't something on which to build
>that is something to hang things off of.
>
>
Yes, hanging things off is the intention, but they are both starting
points, just from different perspectives.
Sam.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
