Hi Derrick,
> There are valid reasons to allow a PAG to be specified, but only with
> priviledge. e.g. user mode protocol translator (afs to nfs)
I suppose I can do that... I can add a hook to the security framework or add a
an extra capability to allow a finer degree of control.
Perhaps:
newpag() <--- new PAG
setpag(0) <--- no PAG
setpag(>0) <--- join PAG if permitted
> > I suppose I could give both the PAG and the user lists, and search the PAG
> > first, then the user, but what detemines the user? The PAG, the opener of a
> > file or the current process?
>
> The uid of the current process. Again, if you're in a PAG you don't get
> uid tokens. You could create 2 PAG number spaces, 1 using uid
> and one sequential alloc, but then you need more management I guess (or to
> assume kernel code will be able to provide hooks for accepting tokens
> regardless of PAG and just let people who care deal in their code)
Getting the per-user PAG data from the current process becomes a little
trickier when worker kernel threads become involved:-/
Maybe each user_struct should _also_ have a normal PAG associated with
it. Asking for "no PAG" joins the calling process into its owner user's
PAG. Then you only need one number space...
However, doing this would affect authentication tokens for every FS that
stored them in this way, not just AFS (Samba for instance).
> > I don't have documentation on VIOCPREFETCH, but if it's anything like the
> > other two, then it shouldn't be a problem either.
>
> Takes a path to attempt to prefetch as a text string.
I take it that "prefetch" means try and fetch the entire file into the cache?
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:32 EST