lkml.org 
[lkml]   [2001]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: crc32 cleanups
On Sat, 13 Oct 2001, Keith Owens wrote:
> On Fri, 12 Oct 2001 21:36:45 -0500 (CDT),
> Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
> >On Sat, 13 Oct 2001, Keith Owens wrote:
> >> It is better to define CONFIG_CRC32 and have the Config.in files set
> >> CONFIG_CRC32 for selected drivers. That avoids the problem of lots of
> >> drivers wanting to patch the same Makefile, instead the selection of
> >> crc32 is kept with the driver selection.
> >
> >No, because that doesn't take care of the module case (CONFIG_CRC32=m).
>
> Don't build crc32.o as a module, if it is required at all then make it
> built in. Building small service routines as modules is a waste of
> space, they take up complete pages when they are loaded.

If a page matters then CONFIG_CRC32=y can always be chosen by the user.

I prefer not to take away choice from the users unnecessarily, in this
case because you (as I read it) find the case of a library module too
ugly to deal with in Config.in language. This type of case is going to
pop up again and again. To me for example it seems reasonable to make
bzlib or zlib into a support module, if a similar case arose.

The easy solution to all this is obviously to build crc32 into the
kernel unconditionally, and live with the kernel bloat. I don't like
kernel bloat, so I prefer the non-easy option.

Jeff



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

\
 
 \ /
  Last update: 2005-03-22 13:08    [W:0.052 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site