From: Stuart Lynne <sl@lineo.com>
To: linux-kernel@vger.kernel.org
Subject: Re: crc32 cleanups
Date: Fri, 12 Oct 2001 19:09:19 -0700 [thread overview]
Message-ID: <20011012190919.J7155@fireplug.net> (raw)
vonbrand@sleipnir.valparaiso.cl said:
> Matt_Domsch@Dell.com said:
> > > That leaves (a) unconditionally building
> > > it into the kernel, or (b) Makefile and Config.in rules.
>
> > (a) is simple, but needs a 1KB malloc (or alternately, a 1KB static const
> > array - I've taken the approach that the malloc is better)
>
> Better static (less overhead in size and at runtime), initialized at build
> time (you could compute it then). In case of _dire_ kernel size problems, it
> can be left out anyway. AFAIU, there are now a _lot_ of copies of this
> around, so you'll win overall in any case.
>
> > (b) isn't that much harder, but requires drivers to be sure to call
> > init_crc32 and cleanup_crc32. If somehow they manage not to do that, Oops.
> > I don't want to add a runtime check for the existance of the array in
> > crc32().
I have to agree. A single global config that controls if CRC32 is available
as a static table, and an inline function that allows me to use it.
Any module that tries to use it will either not compile or if will not load
due an unresolved address.
Least impact. Simplest API. The lowest overhead for kernels that do or do
not need CRC.
We should probably provide CRC10 and CRC16 as well.
--
__O
Lineo - Where Open Meets Smart _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <sl@lineo.com> www.lineo.com 604-461-7532
next reply other threads:[~2001-10-13 2:09 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-13 2:09 Stuart Lynne [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-10-23 21:19 crc32 cleanups Matt_Domsch
2001-10-16 19:05 Matt_Domsch
2001-10-15 11:34 Samium Gromoff
2001-10-14 3:19 Matt_Domsch
2001-10-13 3:46 Matt_Domsch
2001-10-13 11:47 ` Kai Henningsen
2001-10-12 22:20 Matt_Domsch
2001-10-12 22:34 ` Jeff Garzik
2001-10-12 20:17 Matt_Domsch
2001-10-12 20:34 ` Jeff Garzik
2001-10-13 1:20 ` Horst von Brand
2001-10-13 15:16 ` Martin Dalecki
2001-10-13 1:09 ` Horst von Brand
2001-10-13 1:20 ` Jeff Garzik
2001-10-12 19:11 Matt Domsch
2001-10-12 19:25 ` Jeff Garzik
2001-10-12 19:37 ` Jeff Garzik
2001-10-13 1:51 ` Keith Owens
2001-10-13 2:36 ` Jeff Garzik
2001-10-13 2:45 ` Keith Owens
2001-10-13 2:56 ` Jeff Garzik
2001-10-13 3:12 ` Keith Owens
2001-10-12 19:45 ` Horst von Brand
2001-10-12 20:07 ` Jeff Garzik
2001-10-13 1:04 ` Horst von Brand
2001-10-13 1:09 ` Jeff Garzik
2001-10-13 12:45 ` Horst von Brand
2001-10-13 9:48 ` Jan-Marek Glogowski
2001-10-13 10:02 ` Andi Kleen
2001-10-13 10:07 ` Jan-Marek Glogowski
2001-10-13 23:09 ` Horst von Brand
2001-10-13 10:25 ` Keith Owens
2001-10-15 8:29 ` Bjorn Wesen
2001-10-15 11:35 ` Keith Owens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011012190919.J7155@fireplug.net \
--to=sl@lineo.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox