lkml.org 
[lkml]   [2001]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: crc32 cleanups
Date
From
Jeff Garzik <jgarzik@mandrakesoft.com> said:
> On Fri, 12 Oct 2001, Horst von Brand wrote:
> > Jeff Garzik <jgarzik@mandrakesoft.com> said:
> > > We must consider the case where the kernel is built, and then a random
> > > 3rd party module comes along that needs crc32 features. An ar library
> > > won't cut it, and neither will [the existing crc32 method of] patching
> > > linux/lib/crc32.c. That leaves (a) unconditionally building it into the
> > > kernel, or (b) Makefile and Config.in rules.

> > (b) won't work if my kernel has no CRC32 modules, and a random 3rd party
> > module needs it. So it looks like firm builtin is the only real option (a).

> Sure it will. (b) not only will work, but it is the preferred option.

3rd party module, added _after_ the fact?

In any case, either this stuff is small (so adding it into the base kernel
is no big deal if needed somewhere) or it is large (in which case the
overhead of a module is no big deal). I'd vote for using the existing
infrastructure for handling transient code/data if needed, not adding yet
another scheme with refcounting &c just for this particular use.
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
-
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    [from the cache]
©2003-2011 Jasper Spaans