Kernel decontextualization -- idea and little proof-of-concept

[Attilio Rao]

Looking at VFS (but this is not a VFS-only e-mail), what immediately
pops up is that KPI is rather heavy, someway complicated and too
little user-friendly (in particular in regard of locking). Some of
this heaviness cames from direct approaching some peculiar problems
(vnodes recycling in primis) but another part is totally old-standing
and cames out from wrong (or anyways acrossed) assumptions.
One of this latter case is the widespread presence of "thread"
arguments in the whole kernel. Among all the subsystems, the most
plagued is the VFS. You can see a lot of unuseful (or partially,
better explained later) thread passed all over the VOP_* functions,
their consumers and their callee and this reflects on a lot of key
structures too (uio, componentname, namei, etc.).

My idea is that we should drop totally this thread bloat from our
subsystems (and in particular from VFS) because it is nosense and it
adds just obfuscation and overhead for eventual consumer of the KPI.
This also will prepare a better ground for further VFS improvements
like, for example, namei KPI refactoring and reorganization, file
accessings, etc.

Small Q&A about possible concerns:
Q: Sometimes we need to pass a thread in order to get his credentials,
how you will handle this?
A: We will simply get the ucred pointed and will switch the thread
argument to be a credential

Q: curthread accesses are heavy, will this work penalyze kernel performances?
A: This work is intended in order to drastically reduce thread
pointers movement. This means that, ideally, this will get in having a
lot less curthread accesses than the old code.

Q: Ideally, you have to complete the whole work fastly but still
keeping patches in mealpieces that people can review and test, how do
you plan to handle this?
A: There is not a simple solution for this. I will try to put a lot of
effort in order to have good-sized patches and to do it as fast as I
can.
For an example, please, look at this patch:
http://www.freebsd.org/~attilio/vfsattr.diff

which does remove the thread argument from VOP_GETATTR / VOP_SETATTR
couplet. There is still room for refinements here, but I need to
cleanup other VOP_* functions before.

Q: You have been good in avoiding the biggest concern, but here we go!
What about MFC troubles caming from a massive KPI breakage?
A: I know that MFC to 7 and 6 will became a PITA (in particular for
VFS consumers) but this is a good moment in order to decide if we want
to keep catering a old-standing (bogus) approach like that or if we
want to operate a full cleanup. This will mean working also in the
variety of consumers filesystem but with the help of a good line-up of
testers I think I can handle this.

Let me know what do you think about.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein