> >> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc
> >> > > routines in NetBSD point to error routines.
> >> >
> >> > In FreeBSD, they now point to default routines that are *not* error
> >> > routines. This is the problem. I admit the change was very well
> >> > intentioned, since it made the code a hell of a lot more readable,
> >> > but choosing between readable and additional function, I take function
> >> > over form (I think the way I would have "fixed" the readability is by
> >> > making the operations that result in the descriptor set for a mounted
> >> > FS instance be both discrete, and named for their specific function).
> >>
> >> As I recall most of FBSD's default routines are also error routines, if
> >> the exceptions were a problem it would would be trivial to fix.
> >
> >You would have to de-collapse several VOP lists that have been
> >pre-collapsed.
>
> You are talking gibberish here. Please show code where this is
> a problem.
When you write a proxy stacking layer, such as John Heidemann's
network proxy stacking layer (an NFS alternative), VOP's which
would normally be handled by vfs_default have to be handled on
the other end of the proxy, instead, in the same way that they
would be handled by the vfs_default stuff.
Some VOP's, like advisory locking, need both local assertion and
remote proxy of the VOP to avoid introducing race windows.
The result of this is that, if you rely on the vfs_default stuff,
then you can't proxy those VOP's into a different address space,
either on another machine, or to a user space VFS stacking layer
developement environment.
This is the same problem that embedding VM references directly
into any FS causes, and that vm_object_t aliases would exacerbate.
John has, in the past, sent me a number of stacking layers done
by various people, with the requirement that I not redistribute
them, as they are not what he would consider to be properly
representative of finished work.
Since John himself did the network proxy, you could perhaps get
him to send you a copy, so you could have direct access to code
where this was a problem.
Make sure that the system you are talking to over the proxy is
not assumed to be a FreeBSD system (e.g. don't assume that the
vfs_default stuff exists on the other end of the proxy, or that
it would be functional).
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
