Re: VFS ROADMAP (and vfs01.patch stage 1 available for testing)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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
:party modules.
:
:I have to think about the rest of the mail today :)
:
:Joerg

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>