Splitting <fs>_access to two internal routines

[Elad Efrat <elad%NetBSD.org@localhost>]

Hi,

Currently, each <fs>_access routine has two kinds of logic inside it:
the first tells whether the operation is at all possible, and the second
checks for permissions.

I would like to separate them -- internally -- to two functions that do
the same, making it easier to distinguish where we can flip the decision
and where we can't. To illustrate, consider the following example:

        int
        somefs_access(...)
        {
                /* No write support (yet). */
                if (mode & VWRITE)
                        return EROFS;
                        
                return vaccess(...);
        }

Obviously, if we don't have write support, it doesn't matter what the
permissions say, or whether the user's root or not: writing is not
possible. Working on the above example, I suggest the following:

        static int
        somefs_is_possible(...)
        {
                /* No write support (yet). */
                if (mode & VWRITE)
                        return EROFS;

                return 0;
        }

        static int
        somefs_is_permitted(...)
        {
                return vaccess(...);
        }
                
        int
        somefs_access(...)
        {
                [...]

                error = somefs_is_possible(...);
                if (error)
                        return error;

                return somefs_is_permitted(...);
        }

As you can see, the functionality remains the same, only that now it
is possible to tell the decision for each "logic".

The reason for the addition of somefs_is_permitted, even though it only
calls vaccess, is that often file-system code is copy/pasted, and if
that happens in the context of a file-system that performs non-standard
access control checks (e.g., has ACLs, etc.), we might lose the common
code structure and "quantification" of the file-system's access control
decision.

Are there any objections for such restructuring? if not, I'll follow-up
with a diff implementing the changes for review.

Thanks,

-e.