2002-02-01 10:08:28

by Horst von Brand

[permalink] [raw]
Subject: Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

"David S. Miller" <[email protected]> said:

[...]

> However this isn't a driver, the crc library stuff is more akin to
> "strlen()". Are you suggesting to provide a CONFIG_STRINGOPS=n
> too? I wish you luck building that kernel :-)

libc.a was invented precisely to handle such stuff automatically when
linking... if it doesn't work, it should be fixed. I.e., making .a --> .o
is a step in the wrong direction IMVHO.
--
Horst von Brand http://counter.li.org # 22616


2002-02-01 10:29:39

by Keith Owens

[permalink] [raw]
Subject: Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

On Fri, 01 Feb 2002 11:07:42 +0100,
Horst von Brand <[email protected]> wrote:
>"David S. Miller" <[email protected]> said:
>> However this isn't a driver, the crc library stuff is more akin to
>> "strlen()". Are you suggesting to provide a CONFIG_STRINGOPS=n
>> too? I wish you luck building that kernel :-)
>
>libc.a was invented precisely to handle such stuff automatically when
>linking... if it doesn't work, it should be fixed. I.e., making .a --> .o
>is a step in the wrong direction IMVHO.

There are two contradictory requirements. crc32.o must only be linked
if anything in the kernel needs it, linker puts crc32.o after the code
that uses it. crc32.o must be linked before anything that uses it so
the crc32 __init code can initialize first.

2002-02-01 11:05:53

by David Miller

[permalink] [raw]
Subject: Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

From: Keith Owens <[email protected]>
Date: Fri, 01 Feb 2002 21:28:52 +1100

On Fri, 01 Feb 2002 11:07:42 +0100,
Horst von Brand <[email protected]> wrote:
>libc.a was invented precisely to handle such stuff automatically when
>linking... if it doesn't work, it should be fixed. I.e., making .a --> .o
>is a step in the wrong direction IMVHO.

There are two contradictory requirements. crc32.o must only be linked
if anything in the kernel needs it, linker puts crc32.o after the code
that uses it. crc32.o must be linked before anything that uses it so
the crc32 __init code can initialize first.

Horst isn't even talking about the initcall issues, he's talking about
how linking with libc works in that it only brings in the routines you
actually reference.

Will you get over the initcall thing already, you must be dreaming
about it at this point. I mean really, just GET OVER IT. :-)

2002-02-01 11:26:03

by Keith Owens

[permalink] [raw]
Subject: Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

On Fri, 01 Feb 2002 03:03:45 -0800 (PST),
"David S. Miller" <[email protected]> wrote:
> From: Keith Owens <[email protected]>
> Date: Fri, 01 Feb 2002 21:28:52 +1100
>
> On Fri, 01 Feb 2002 11:07:42 +0100,
> Horst von Brand <[email protected]> wrote:
> >libc.a was invented precisely to handle such stuff automatically when
> >linking... if it doesn't work, it should be fixed. I.e., making .a --> .o
> >is a step in the wrong direction IMVHO.
>
> There are two contradictory requirements. crc32.o must only be linked
> if anything in the kernel needs it, linker puts crc32.o after the code
> that uses it. crc32.o must be linked before anything that uses it so
> the crc32 __init code can initialize first.
>
>Horst isn't even talking about the initcall issues, he's talking about
>how linking with libc works in that it only brings in the routines you
>actually reference.

Go back and read the entire thread Dave. It started with

http://www.lib.uaa.alaska.edu/linux-kernel/archive/2002-Week-04/1235.html

"Besides problem with segfaulting crc32 (it is initialized after
net/ipv4/ipconfig.c due to lib/lib.a being a library... I had to
hardcode lib/crc32.o before --start-group in main Makefile, but it is
another story)"

http://www.lib.uaa.alaska.edu/linux-kernel/archive/2002-Week-04/1384.html

"included patch (for 2.5.3) fixes problems with late initialization
of lib/crc32.o - as it was part of .a library file, it was picked by
link process AFTER at least one .o file required it - for example
when ipv4 autoconfiguration file needed it. So crc32's initalization
function was invoked after ipconfig's one - and it crashed inside of
ipconfig due to this problem."

Horst was not talking about initcall but his suggestion of using lib.a
for crc32.o had already been proven not to work, because of the
(surprise) initcall problem. I was merely pointing out to Horst why
lib.a was not working and why other options had to be considered.

>Will you get over the initcall thing already, you must be dreaming
>about it at this point. I mean really, just GET OVER IT. :-)

Nightmare is more like it.

2002-02-01 14:57:02

by Jeff Garzik

[permalink] [raw]
Subject: Re: [PATCH] Re: crc32 and lib.a (was Re: [PATCH] nbd in 2.5.3 does

On Fri, Feb 01, 2002 at 10:25:20PM +1100, Keith Owens wrote:
> On Fri, 01 Feb 2002 03:03:45 -0800 (PST),
> "David S. Miller" <[email protected]> wrote:
> >Will you get over the initcall thing already, you must be dreaming
> >about it at this point. I mean really, just GET OVER IT. :-)
>
> Nightmare is more like it.

Exaggeration is more like it :)

Jeff