| From | Sent On | Attachments |
|---|
| Subject: | Expanding vops in vop_vectors during startup | |
|---|---|---|
| From: | Ed Schouten (ed...@80386.nl) | |
| Date: | Sep 12, 2008 11:26:59 am | |
| List: | org.freebsd.freebsd-arch | |
Refine Search
| From | Sent On | Attachments |
|---|---|---|
| Ed Schouten | Sep 12, 2008 11:26 am | |
| Ed Schouten | Oct 1, 2008 12:07 pm | .diff |
| Poul-Henning Kamp | Oct 1, 2008 12:46 pm | |
| Ed Schouten | Oct 1, 2008 1:20 pm |
| Subject: | Expanding vops in vop_vectors during startup | |
|---|---|---|
| From: | Ed Schouten (ed...@80386.nl) | |
| Date: | Sep 12, 2008 11:26:59 am | |
| List: | org.freebsd.freebsd-arch | |
Hello everyone,
Yesterday I was talking with some friends of mine about the FreeBSD VFS layer. As an exercise, Jille was trying to patch nullfs to hide .svn directories (see hackers@), so that's how we got to the subject.
After talking about the way our vop_vector works (vop_bypass and vop_default), we were wondering why we don't propagate all pointers in the vop_vector to its children to save the unneeded function pointer resolving inside the VOP_* calls.
I've created a patch that adds a new routine to the kernel, vop_vector_init(), which recursively expands the vops. A new macro (DECLARE_VOP_VECTOR) is used to automatically perform this when loading modules/booting.
There is no need to reference default_vnodeops anymore, because it is now used implicitly (when vop_vector == NULL).
Any comments on the attached patch? I've only tested it with ufs, nullfs, devfs, etc. yet. I haven't tested `make universe' yet, but I suspect it shouldn't break hard.
URL:
http://80386.nl/files/vnode-vop-expand.diff
Thanks!
-- Ed Schouten <ed...@80386.nl> WWW: http://80386.nl/

