On Sun, 17 Aug 2003, Jeremy Fitzhardinge wrote:
> On Sat, 2003-08-16 at 02:46, Ian Kent wrote:
> > Thanks for your support.
> >
> > Unfortuneately the functionality I need very much relies on changes to the
> > kernel module. Can we cooperate on this some how?
>
> That seems to be jumping the gun a bit. I think the procedure should
> be:
>
> 1. release a final 4.0.0 stable release, which is more or less -pre10
> with bug fixes
> 2. maintain the 4.0 branch as stable (ie, bugfix only)
> 3. start a 4.1 branch with your new changes
>
Right you are Jeremy.
Ignorant of me to ignore existing 4.0.0 users. I appologise.
It's been a long time since I have worked with the original 4.0.0
distribution so I will need input from people that are using it.
Could everyone post bug reports and send any patches to me. Please
include some indication of priority such as show stopper, nice to have
etc. I will attempt to solve the problems and merge any patches.
It is important that problem reports be accompanied by a description of
the problem that will enable me to reproduce it in order to fix it.
At some point I will draw a line in the sand and any outstanding bugs or
problems will be fixed as minor version increments.
It is essential that 4.0.0 move to a release and this will be my main
focus.
> Part of the 4.1 tree should be a kernel patch. We can look at rolling
> it into the kernel when everyone is happy that it's stable.
Yep. Sounds like a good plan to me.
>
> > This is on my list. I believe that it can be addressed by bringing the
> > parsing of the master map into the daemon. This will enable a much more
> > generic init script to be written.
>
> The approach I was thinking about was to factor all the init scripts
> into two parts: one set of functions for doing autofs specific things
> (parsing maps, starting and stopping daemons, etc), and a set of
> per-distro scripts which use the autofs functions to do their work. The
> per-distro scripts should have very little real code in them, just
> whatever the distro needs an init script to do.
>
> Why would moving the map parsing into the C code make things more
> generic?
OK. Point taken.
My thinking on this has been influenced by a feature I think is needed in
the daemon. This is the ability to handle multiple occurences of keys
by merging the maps. This enables a global map to be maintained and local
execptions to be handled by a different map. Also the direct map
implementation I have done has a problem in that it reads the map more
often than it should. I believe that taking this parsing into the daemon
will be part of a solution for that.
Also I think that taking generic processing of the master map into the
daemon will simplify the disto specific init script and make it more
managable.
--
,-._|\ Ian Kent
/ \ Perth, Western Australia
*_.--._/ E-mail: [EMAIL PROTECTED]
v Web: http://themaw.net/
_______________________________________________
autofs mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/autofs
