DragonFly kernel List (threaded) for 2004-08
Re: VFS ROADMAP (and vfs01.patch stage 1 available for testing)
:On Thu, Aug 12, 2004 at 06:19:40PM -0700, Matthew Dillon wrote:
:> This patch rips out the nearly unreadable and hugely inlined VOP
:> operations vector code and replaces it with a fixed structure and
:> wrapper procedures.
:Have you thought about using the kobj framework instead? It would might
:make the invidiual call a bit slower (hash table lookup + comparison +
:indirect call vs. array lookup + indirect call), but it could make
:the system more extensible and possible less error prone e.g. for third
:I have to think about the rest of the mail today :)
I considered it but the KOBJ framework is a direct-call framework
and is not really all that suitable for a hybrid messaging API.
For all intents and purposes there is no point in trying to keep
the flexibility of having an extensible VFS call interface (verses
manually adding new calls to the kernel), because the kernel needs
to be aware of all the VFS functions anyway. In the last decade I
have not seen a single new interface added that does not also
require huge amounts of manual kernel interfacing work, despite the
supposed extensibility of the old framework.
The new framework is also supplying a (basically mandatory) kernel
layer which will be responsible for the messaging interface but,
more importantly, will also be responsible for implementing the
kernel cache layer.
Plus look how easy it was for me to convert it to a fixed structure?
It took just one day. Adding new function support in the new framework
is going to be a matter of ~5 minutes per function and we will
automatically get a hook for a kernel caching layer for free.
I have been pondering what to do about struct fileops. We have an
opportunity with struct fileops that I feel we are currently not
taking advantage of. Basically, struct fileops has always been a
'fast synchronous' API for file descriptor operations. I am
seriously considering ripping out struct fileops and replacing it
with a vop_ops structure, then implementing the kernel caching
layer there. I look at our specfs code and the specfs drivers
(which use the VOP interface) are no more difficult to write then
fileops drivers (e.g. the pipe code).
In particular, consider a function like open() which does not
(normally) take a file descriptor as an argument, and hence one
would not normally associate it with the use of a struct file/fileops.
But one thing open() *DOES* need is the concept of the 'current
directory' (in fact, any namei() operation requires the concept of
the 'current direcotry')... and what is the current directory? Yup,
you guessed it, it's a struct file pointer.
So I feel that it not only may be possible to merge the functionality
of struct fileops and struct vop_ops, but that in fact doing so would
result in a much, much cleaner API for the whole system.