> BK> Really? So how do the "venus" daemons of AFS, Arla, Coda, and Intermezzo
> BK> handle this?
>
> Via kernel-space component AFAIK :-) Please read before respond. Yes,
> kernel-space component CAN be reduced, but you can not eliminate it.
Thank you, that is exactly my point: even if you have your heart set on
making /dev a virtual filesystem, you can significantly reduce the kernel
portion of devfs. So it doesn't necessarily have to introduce any policy
into the kernel.
It seems that there's a lot more acceptance over the "notify userspace
about new devices" part of devfs than the "virtual filesystem" part of
devfs. For one, there are a lot of neat things you can do with the
notification part that don't require the virtual filesystem part, such as
wizards to ask the user what to do with new hardware, etc.
Also, the "virtual filesystem" part could be implemented in userspace
using Coda's cfs (along the lines of Pavel Machek's "podfuk"). I don't
expect either the devfs or the anti-devfs people to accept such a twisted
solution, but it shows that there is room for a compromise (devfs with no
policy in the kernel).
>
> BK> AFAIK, all four filesystems depend on user-space daemons to
> BK> fetch files from the fileserver, so I think there must be some way to
> BK> notify the daemon that a non-existing file is being accessed.
>
> Notify from kernel-space part -- yes, without such -- no (or more correct:
> no without ugly hacks like tracing all syscalls and such)...
The small kernel-space portion of Coda doesn't open up network connections
to the server and download files, does it? It seems to be completely
"policy-free" to me.
Brad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/