missing build functionality?

missing build functionality?

[Bruce Korb]

Hi all,

I do hope this is the right forum.  I didn't see a "linux-kernel-build" list.
Anyway, I do not see an obvious way to construct an object archive library
that I wish to use for multiple drivers.  There are two problems.  This:

> ifeq ($(ARCH),ia64) 
> 	CFLAGS_KERNEL = 
> endif

because I am making the archive for a loadable driver.  This is not right
because I am digging around in kernel make files to figure out how to
do this and I'm guessing it might be subject to change.  :-}

The other "problem" is merely a nuisance:

> WARNING: Symbol version dump /usr/src/Kernel/SLES9/linux-2.6.5-7.97-debug/Module
> .symvers is  missing, modules will have CONFIG_MODVERSIONS disabled.

this, presumably, 'cuz I'm not actually making a module.

Your help is greatly appreciated.

Regards, Bruce

Re: missing build functionality?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

On Tue, 23 Nov 2004 12:33:39 PST, Bruce Korb said:

> Anyway, I do not see an obvious way to construct an object archive library
> that I wish to use for multiple drivers.  There are two problems.  This:
> 
> > ifeq ($(ARCH),ia64) 
> > 	CFLAGS_KERNEL = 
> > endif
> 
> because I am making the archive for a loadable driver. 

The usual solution for 2 modules that share an archive would be to create
*three* modules driver-a, driver-b, and driver-core - and then have the
appropriate depmod magic so a 'modprobe driver-a' does an insmode driver-core,
as does a 'modprobe driver-b'.

Otherwise, you're just loading the entire library into memory twice,
once for each driver...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: missing build functionality?

[Bruce Korb]

On Tuesday 23 November 2004 01:02 pm, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 23 Nov 2004 12:33:39 PST, Bruce Korb said:
> 
> > Anyway, I do not see an obvious way to construct an object archive library
> > that I wish to use for multiple drivers.  There are two problems.  This:
> > 
> > > ifeq ($(ARCH),ia64) 
> > > 	CFLAGS_KERNEL = 
> > > endif
> > 
> > because I am making the archive for a loadable driver. 
> 
> The usual solution for 2 modules that share an archive would be to create
> *three* modules driver-a, driver-b, and driver-core - and then have the
> appropriate depmod magic so a 'modprobe driver-a' does an insmode
> driver-core,
> as does a 'modprobe driver-b'.
> 
> Otherwise, you're just loading the entire library into memory twice,
> once for each driver...

If the library is actually a glue layer that smooths out the differences
between kernel API's, then that is exactly what I want to do.  There
is not a substantial amount of functionality.  In fact, it is mostly
macros.  The key word being, "mostly".  There is enough code in what
is not done in macros that it should not be compiled with every driver,
but not so much that it is worth making a separate driver library driver.  :)

So, it would still be very useful to know how to link against a "libmumble.a"
file built in another directory.  Copying all sources and libraries into
a build directory before kicking off the build is kludgey.  (Linux being the
only platform where that seems to be necessary.)

Thanks - Bruce

Re: missing build functionality?

[Sam Ravnborg]

> 
> So, it would still be very useful to know how to link against a "libmumble.a"
> file built in another directory.
You can specify a .o file in another directory. Do you really need a .a
file? oprofile for ones does this. xfs is another example.

> Copying all sources and libraries into
> a build directory before kicking off the build is kludgey.  (Linux being the
> only platform where that seems to be necessary.)
Assuming you are talking about the kernel then the kernel build system
is optimised for buiding the kernel.
And the kernel source keep relevant files together as much as possible.
See for example drivers/net. A lot of files, but most of them is a net
driver so no value gained introducing a directory for a simple driver.

And experience has shown that usage of libaries has resulted in more
problems than it has solved in most cases. Thats why libraries are so
seldom used in the kernel.
When do you need to include crc32.o in the kernel for instance.


	Sam