[arch-projects] [mkinitcpio][PATCH 03/10] functions: refactor add_module

[Dave Reisner]

On Mon, Jun 06, 2011 at 09:05:14PM +0200, Tom Gundersen wrote:
> On Mon, Jun 6, 2011 at 5:30 PM, Dave Reisner <d at falconindy.com> wrote:
> > Simplify and fix a few bugs in the process. We rely solely on modinfo
> > for obtaining information about module location, dependencies and
> > firmware. Add a small wrapper function for modinfo that will always
> > specify our $BASEDIR and $KERNELVERSION for us.
> >
> > Also, kill off HAS_MODULES. Since we have ADDED_MODULES, which contains
> > all currently added modules, we can count the elements in this when it
> > comes time to decide to create depmod files.
> >
> > Signed-off-by: Dave Reisner <d at falconindy.com>
> 
> > +    #explicit module depends
> > +    case "$module" in
> > +        fat) add_module "nls_cp437" ;;
> > +        ocfs2) add_module "configfs" ;;
> > +        libcrc32c) add_module "crc32c"; add_module "crc32c_intel" ;;
> > +    esac
> 
> Are these workaround for kernel bugs? Maybe a comment to explain would
> be in order? Is it fixed, in what version? Link to bugzilla?
> 
> -t

No, these are things that intentionally a pain in the butt. In the case
of libcrc32c, there's multiple providers of crc32c -- the C version as
well as the intel hardware version. By putting a hard dependency on
crc32c, you never get to use the hardware version (assuming your CPU
supports it)[1]. Similar scenario for fat -- you need _a_ codepage, but
there's no hard dependency on any particular codepage as it depends on
how you mount the volume. I'm not at all familiar with the configfs
requirement for ocfs2, but googling around, it seems that the two are
often referred to in tandem.

dave

[1] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg02730.html