[Cbe-oss-dev] automount support

[William Chung]

Arnd,

I appreciate your quick response.

On Wednesday 13 September 2006 13:35 EDT, Arnd Bergmann wrote:
> While there are no technical reasons against it, it increases build
> time on my development system, and I generally try to avoid
> adding modules that are not generally needed.

Fortunately, the autofs modules aren't large so they don't add 
significantly to the build time.  The motivation for including some form 
of automounter support in the cell kernel is because cell blades are 
usually used in groups of more than one.  So, it's often desirable to have 
a common filesystem between them.

> I guess having one of them is pretty common, but not both.
> Which one do you prefer?

autofs4 is supposedly backwardly compatible with autofs (v3), so I'd 
prefer autofs4.  I hear that having only autofs4 as a module can require 
adding the line "alias autofs autofs4" to /etc/modprobe.conf to let 
modutils look for autofs4 when the kernel needs autofs.  I'm not sure that 
this line is necessary though because I built a kernel with both autofs 
and autofs4 enabled as modules and it looks like only autofs4 gets loaded, 
without any changes to my /etc/modprobe.conf file.  Hopefully, someone 
more experienced with autofs can give some guidance here.

I refer to autofs4 as a module above because I'm going to tentatively say 
that it'd be better to build autofs4 as a module, rather than into the 
kernel (CONFIG_AUTOFS4_FS=m).  Once again, those more experienced with 
kernel configuration and autofs should confirm how autofs4 should be 
enabled.

Regards,
- Bill.

*****************
William Chung
IBM T.J. Watson Research Center
Hawthorne, New York, USA
Tel: 1-914-784-7552    whchung at us.ibm.com




Arnd Bergmann <arnd.bergmann at de.ibm.com> 
Sent by: cbe-oss-dev-bounces+whchung=us.ibm.com at ozlabs.org
09/13/2006 01:35 PM

To
cbe-oss-dev at ozlabs.org
cc
linuxppc-dev at ozlabs.org
Subject
Re: [Cbe-oss-dev] automount support






On Wednesday 13 September 2006 17:01, William Chung wrote:
> I noticed that the stock cell kernel does not enable the autofs and 
> autofs4 modules.  The stock Fedora Core 5 kernel does have these modules 

> enabled.  What is the reason for disabling automount support?  Would 
there 
> be any issues to changing arch/powerpc/configs/cell_defconfig to enable 
> the autofs and autofs4 modules?

While there are no technical reasons against it, it increases build
time on my development system, and I generally try to avoid
adding modules that are not generally needed.

The other defconfig files are inconsistent in this regard:

arch/powerpc/configs/cell_defconfig:# CONFIG_AUTOFS_FS is not set
arch/powerpc/configs/cell_defconfig:# CONFIG_AUTOFS4_FS is not set
arch/powerpc/configs/chrp32_defconfig:# CONFIG_AUTOFS_FS is not set
arch/powerpc/configs/chrp32_defconfig:# CONFIG_AUTOFS4_FS is not set
arch/powerpc/configs/g5_defconfig:CONFIG_AUTOFS_FS=m
arch/powerpc/configs/g5_defconfig:# CONFIG_AUTOFS4_FS is not set
arch/powerpc/configs/iseries_defconfig:CONFIG_AUTOFS_FS=m
arch/powerpc/configs/iseries_defconfig:# CONFIG_AUTOFS4_FS is not set
arch/powerpc/configs/maple_defconfig:# CONFIG_AUTOFS_FS is not set
arch/powerpc/configs/maple_defconfig:# CONFIG_AUTOFS4_FS is not set
arch/powerpc/configs/pmac32_defconfig:# CONFIG_AUTOFS_FS is not set
arch/powerpc/configs/pmac32_defconfig:CONFIG_AUTOFS4_FS=m
arch/powerpc/configs/ppc64_defconfig:CONFIG_AUTOFS_FS=y
arch/powerpc/configs/ppc64_defconfig:# CONFIG_AUTOFS4_FS is not set
arch/powerpc/configs/pseries_defconfig:# CONFIG_AUTOFS_FS is not set
arch/powerpc/configs/pseries_defconfig:CONFIG_AUTOFS4_FS=m

I guess having one of them is pretty common, but not both.
Which one do you prefer?

                 Arnd <><
_______________________________________________
cbe-oss-dev mailing list
cbe-oss-dev at ozlabs.org
https://ozlabs.org/mailman/listinfo/cbe-oss-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20060913/b8c868c2/attachment.htm>