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/
This archive was generated by hypermail 2b29 : Mon Oct 15 2001 - 21:00:48 EST