Tim Hockin wrote:
> On Tue, Jan 06, 2004 at 02:06:34PM -0800, H. Peter Anvin wrote:
>
>>>Can you maybe share some details? I think this deign moves MORE state to
>>>userspace (expiry aside). The "state" in kernel is really mostly sent back
>>>to userspace. No more passing pipes into the kernel (state) or tracking the
>>>pgid of the daemon (state).
>>
>>If you want to fire up a new daemon, all that state that was supposed to
>>be kept in userspace has to be reconstructed. That means the kernel has
>>to have all that information; this would include stuff like what kind of
>>umount policy you want for each key entry (the current daemon doesn't do
>>that because it doesn't have the proper state.)
>
> I'm not really sure what you're saying., here. I'm sorry. Not trying to be
> thick, just not understanding.
>
> What umount policy? What state is supposed to be kept in userspace that isn't?
>
The current autofs daemon, for example, does not handle different
procedures on umount. This is particularly important when you have
mount trees.
>
>>>The daemon as it stands does NOT handle namespaces, does NOT handle expiry
>>>well, and is a pretty sad copy of an old design.
>>
>>First of all, I'll be blunt: namespaces currently provide zero benefit
>>in Linux, and virtually noone uses them. I have discussed this with
>>Linus in the past, and neither one of us see namespaces as being worth
>
> Let's get rid of them, then. Make life that much easier.
>
That's what the Linux community is doing, de facto. The Linux userspace
simply is not set up to handle namespaces, and the autofs daemon is no
exception. Consider such a simple thing as /etc/mtab - /proc/mounts
which is necessary for most of the mount(8) functionality to work. It
doesn't support namespaces and really cannot be made to.
namespace support in Linux is at the best a far-off future goal. It is
one thing to put in infrastructure, especially since it has some other
nice benefits; it's another thing to revamp all of userspace to use it;
it's nowhere close and autofs is no exception.
-hpa
H. Peter Anvin wrote:
> Tim Hockin wrote:
>
>>On Tue, Jan 06, 2004 at 02:06:34PM -0800, H. Peter Anvin wrote:
>>
>>>
>>>First of all, I'll be blunt: namespaces currently provide zero benefit
>>>in Linux, and virtually noone uses them. I have discussed this with
>>>Linus in the past, and neither one of us see namespaces as being worth
>>
>>Let's get rid of them, then. Make life that much easier.
>>
>
>
> That's what the Linux community is doing, de facto. The Linux userspace
> simply is not set up to handle namespaces, and the autofs daemon is no
> exception. Consider such a simple thing as /etc/mtab - /proc/mounts
> which is necessary for most of the mount(8) functionality to work. It
> doesn't support namespaces and really cannot be made to.
>
> namespace support in Linux is at the best a far-off future goal. It is
> one thing to put in infrastructure, especially since it has some other
> nice benefits; it's another thing to revamp all of userspace to use it;
> it's nowhere close and autofs is no exception.
>
This is clearly not 'all of userspace'. Autofs is an exception. As is
/etc/mtab. The way I see it, automounting is a 'mount facility', as are
namespaces. The two should be made to work together. Yes, mount(8)
should probably be fixed one way or another as well due to /etc/mtab
breakage. Why? Because it too is a mount facility.
There are a couple problems inherent with namespaces. Most of these are
mount facilities that are broken such as mentioned above. They *should*
be fixed to work nicely.
Other parts of userspace get confused with namespaces, eg: cron and atd.
These programs clearly need infrastructure added that somehow allows
for arbitrary namespace joining/saving. If you have suggestions for how
we can solve this issue, please do let me know. I'm stumped :\ I'd be
more than happy to discuss this with you.
One not-so-far fetched approach would be to associate cron/at jobs with
automount configurations so that a namespace can be re-constructed at
runtime.
--
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: [email protected]
http://www.sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~