public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Keith Owens <kaos@ocs.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Moving zlib so that others may use it
Date: Wed, 09 Jan 2002 22:23:31 -0600	[thread overview]
Message-ID: <3C3D1743.40900@acm.org> (raw)
In-Reply-To: <25006.1010627525@kao2.melbourne.sgi.com>

Keith Owens wrote:

>On Wed, 09 Jan 2002 17:32:20 -0600, 
>Corey Minyard <minyard@acm.org> wrote:
>
>>I'm working on a function that uses zlib in the kernel, and I know of 
>>other places zlib is used (ppp_deflate, jffs2, mcore).  I would expect 
>>more users to come along.
>>
>>I would like to propose putting zlib in the lib directory and making it 
>>optionally compile if it is needed.  It's pretty easy to move the files 
>>around and make a few small changes to the code.  However, how do I 
>>configure such a thing?  I could add something like:
>>
>
>I am assuming that you can satisfy hpa's concerns about using a single
>version of zlib for everybody.  Also note that arch/ppc/boot/lib has
>its own version of zlib which is quite different to the others.  First
>make sure that you can build one version of zlib that works for
>everybody.
>
Every version I found was practically the same (only comment differences 
and one that variable that was initialized in one and not initialized in 
the other).  I think (actually, I know, because I have tested it) 
everyone can use the same one.  I'm not talking about the ones in the 
boot directories, nor the one for inflate_fs, either, just the ones in 
the kernel proper that are named zlib.c and zlib.h.

>Configuring and linking zlib is a problem.  lib/lib.a is an archive
>which means that the linker will only include zlib from lib.a if some
>other code refers to zlib.  That breaks when all users of zlib are in
>modules and nothing in vmlinux refers to zlib, the zlib code is not
>linked into the kernel and modules get unresolved errors.  Linking
>lib.a into the affected modules is not the solution either, the modules
>would pick up all the code from lib.a instead of using the code in the
>kernel with undefined result
>
>The best option is to build zlib.o for the kernel (not module) and
>store it in lib.a.  Compile zlib.o if any consumer of zlib has been
>selected and add a dummy reference to zlib code in vmlinux to ensure
>that zlib is pulled from the archive if anybody needs it, even if all
>the consumers are in modules.  Some of the zlib symbols will need to be
>exported, I will leave that to you.
>
Why not just create zlib as a module if all the users are modules (so 
depmod and modprobe load it)?  That's what everything else does.  And 
that way, if it's already in the kernel, the module just won't get 
loaded, but if it's not the module gets loaded.  What you are suggesting 
seems rather convoluted.

I guess one other option would be to have an explicit user-set tristate 
like CONFIG_ZLIB, and if anything uses zlib, it could only be modules if 
CONFIG_ZLIB was a module, etc.

>
>
>This should do the trick, completely untested.  It assumes that zlib.h
>has been moved to to include/linux and zlib.c to lib.  Against 2.4.17.
>
I already have patches to do all this, actually, I was just trying to 
get some feedback on it and see if the kernel maintainers would be 
interested in this.  I should have said that earlier.

Thanks,

-Corey


  reply	other threads:[~2002-01-10  4:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-09 23:32 Moving zlib so that others may use it Corey Minyard
2002-01-09 23:36 ` H. Peter Anvin
2002-01-10  1:52 ` Keith Owens
2002-01-10  4:23   ` Corey Minyard [this message]
2002-01-10  4:44     ` Keith Owens
2002-01-10  5:13       ` Corey Minyard
2002-01-10  5:40         ` Keith Owens
2002-01-10 10:55           ` Thomas Capricelli
2002-01-10 14:40             ` Corey Minyard
2002-01-10 15:22             ` Corey Minyard
2002-01-10  9:37         ` Zygo Blaxell
2002-01-10 15:30           ` Tom Rini
2002-01-10 15:36       ` Tom Rini
2002-01-10 16:20         ` Corey Minyard
2002-01-10 16:35           ` Tom Rini
2002-01-10  4:33   ` Corey Minyard
2002-01-10  6:08     ` H. Peter Anvin
2002-01-10 14:13   ` David Woodhouse

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=3C3D1743.40900@acm.org \
    --to=minyard@acm.org \
    --cc=kaos@ocs.com.au \
    --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