Re: [autofs] [RFC] Towards a Modern Autofs

[Mike Waychison <Michael.Waychison _at_ xxxxxxx>]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig12CF335458B0A93714ACE66E
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jeff Garzik wrote:
> Mike Waychison wrote:
> 
>> To put it into perspective, the I'm calling for the following major 
>> changes:
> 
> [...]
> 
>> 2) move the loop that used to spin around and ask kernelspace if there 
>> was anything to expire into the VFS as well, where it won't be killed.
> 
> [...]
> 
>> (1) and (2) shouldn't be hard at all to do considering David Howells 
>> has done the majority of this already. (3) is needed in order to 
>> manage direct mounts properly for when they are 'covered'.  
>> Admittedly, (4) comes off as an ugly hack.
>>
>> Also, (2) was the only 'active' task the automount daemon was doing. 
>> Everything else it did can be rewritten in the form of a usermode 
>> helper that runs only when it is needed.  This simplifies the 
>> userspace code a lot.
> 
> 
> Just going by your own explanation here, #2 should not be in the kernel.
> 
> If we moving daemons into the kernel just because they won't be killed, 
> we'll have Oracle in-kernel before you know it.  Completely spurious 
> reason.
> 

You wouldn't put a bdflush daemon in userspace either would you?  The 
loop in question is just that; (overly simplified):

while (1) {
	f = ask_kernel_if_anything_looks_inactive();
	if (f) {
		try_to_umount(f);
		continue;
	} else {
		sleep(x seconds);
	}
}

My point is, if this is the only active action done by userspace, why 
open it up to being broken?

-- 
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison _at_ Sun.COM
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--------------enig12CF335458B0A93714ACE66E
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE//Jp7dQs4kOxk3/MRAnHVAJ0VNqJb2V4PMu24d8PS+KkhWvw5ygCglCqU
G9lvx4I2FmwtBQNzOWaY4jI=
=rxqP
-----END PGP SIGNATURE-----

--------------enig12CF335458B0A93714ACE66E--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/