ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Shlomi Fis » Sat, 18 Jan 2003 14:40:09



LKMB version 0.1.16 is the humble codeware beginning of the CLAN project.
It is essentially a Perl package (proper with Makefile.PL and all, but not
CPANed yet), which enables one to process LKMB packages.

The latter ones are packages that LKMB can create installation and
compilation packages for kernel modules that can run in any enviornment
the Linux kernel can be compiled and installed on. (a GNU environment).

It contains an example module for the Ethernet DMFE module. Currently, the
makefile for the kernel module's package supports only the "all" and
"install" targets.

I will upload it to CPAN soon, but would like to get some initial feedback
beforehand.

Regards,

        Shlomi Fish

----------------------------------------------------------------------

Home Page:         http://t2.technion.ac.il/~shlomif/

He who re-invents the wheel, understands much better how a wheel works.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Shlomi Fis » Sat, 18 Jan 2003 14:40:14


Ooop! Forgot the URL:

http://fc-solve.berlios.de/CLAN/download/arcs/Linux-Kernel-Modules-Bu...

And the CLAN temporary homepage is at:

http://fc-solve.berlios.de/CLAN/

Sorry about that.

Regards,

        Shlomi Fish

----------------------------------------------------------------------

Home Page:         http://t2.technion.ac.il/~shlomif/

He who re-invents the wheel, understands much better how a wheel works.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by David Woodhous » Sat, 18 Jan 2003 15:20:10


Quote:>   print MAKEFILE "CFLAGS = -I/usr/src/linux/include -O2 -Wall -DMODULE -D__KERNEL__ -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2\n\n";

That's broken. you need to get the proper kernel CFLAGS, and you shouldn't
assume there's anything useful in /usr/src/linux.

Use "/lib/modules/`uname -r`/build" as a default kernel directory, but
allow it to be overridden somehow from the command line. Then do something
like...

        make -C $(LINUXDIR) SUBDIRS=`pwd` modules

... to build your module. That way, all the kernel build stuff will be
correct; it'll be just as if you were in a normal subdirectory of the
kernel tree during a 'make modules' run.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Shlomi Fis » Sat, 18 Jan 2003 19:10:10


Wow! My first patch suggestion! Thanks.


> >   print MAKEFILE "CFLAGS = -I/usr/src/linux/include -O2 -Wall -DMODULE -D__KERNEL__ -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2\n\n";

> That's broken. you need to get the proper kernel CFLAGS, and you shouldn't
> assume there's anything useful in /usr/src/linux.

Ahah. What do you suggest me to do instead? The LKMB package needs to
compile on every system it was intended to. It's still a source package
that has to compile on any GNU system that has the Linux kernel headers.

Quote:> Use "/lib/modules/`uname -r`/build" as a default kernel directory, but
> allow it to be overridden somehow from the command line. Then do something
> like...

>    make -C $(LINUXDIR) SUBDIRS=`pwd` modules

> ... to build your module. That way, all the kernel build stuff will be
> correct; it'll be just as if you were in a normal subdirectory of the
> kernel tree during a 'make modules' run.

Do you mean I'll need a live Linux kernel to build the kernel module
package?

I'm not a big kbuild expert and it show.

Regards,

        Shlomi Fish

Quote:> --
> dwmw2

----------------------------------------------------------------------

Home Page:         http://t2.technion.ac.il/~shlomif/

He who re-invents the wheel, understands much better how a wheel works.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Sam Ravnbor » Sat, 18 Jan 2003 20:10:08



> Do you mean I'll need a live Linux kernel to build the kernel module
> package?

Yes, you fundamentally need the full kernel to compile a module.
Modules may refer to different headers, and some may even be arch specific.

The trick dwmw2 gave you is the only _sane_ way to build a module.

        Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Shlomi Fis » Sat, 18 Jan 2003 20:30:18




> > Do you mean I'll need a live Linux kernel to build the kernel module
> > package?

> Yes, you fundamentally need the full kernel to compile a module.
> Modules may refer to different headers, and some may even be arch specific.

> The trick dwmw2 gave you is the only _sane_ way to build a module.

Yes I gathered it from him and #kernelnewbies. In the future I want
CLAN to be able to package entire kernels. But I'll guess I'll cross the
bridge when I get there, and there's no need to overengineer now.

Regards,

        Shlomi Fish

Quote:>    Sam

----------------------------------------------------------------------

Home Page:         http://t2.technion.ac.il/~shlomif/

He who re-invents the wheel, understands much better how a wheel works.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Olaf Tit » Mon, 20 Jan 2003 00:50:11


Quote:> > Use "/lib/modules/`uname -r`/build" as a default kernel directory, but
> > allow it to be overridden somehow from the command line. Then do something
> > like...
>...
> Do you mean I'll need a live Linux kernel to build the kernel module
> package?

Whoever invented this /lib/modules/... scheme should have known that
it provokes this sort of misunderstandings, not to mention is broken
in other ways too.

You need the _source_ of the kernel the module will run on to compile
modules. You don't need to _run_ this kernel while compiling. Putting
build infrastructure into a deployment directory at the least causes
confusion, not to mention that the deployment directory might not even
exist on the development machine. (I routinely compile kernels and
modules of different configurations for three boxes on one of them,
the other two don't even have a complete development toolset.)

Compiling modules is one of the things which always have been among
the most broken things in the kernel build systems, can this please be
fixed and properly documented?

Olaf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by John Levo » Mon, 20 Jan 2003 02:20:06



> Compiling modules is one of the things which always have been among
> the most broken things in the kernel build systems, can this please be
> fixed and properly documented?

  ^^^^^

Some actual bug reports would be good.

regards
john

--
"This is just the kind of crackpot scheme I've been looking to champion!!!"
        - P.M. Hartke on 6U campaign
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Arjan van de Ve » Mon, 20 Jan 2003 14:20:08



> > > Use "/lib/modules/`uname -r`/build" as a default kernel directory, but
> > > allow it to be overridden somehow from the command line. Then do something
> > > like...
> >...
> > Do you mean I'll need a live Linux kernel to build the kernel module
> > package?

> Whoever invented this /lib/modules/... scheme should have known that
> it provokes this sort of misunderstandings, not to mention is broken
> in other ways too.

it was Linus who decreed this to be the standard;)

Quote:

> You need the _source_ of the kernel the module will run on to compile
> modules. You don't need to _run_ this kernel while compiling. Putting
> build infrastructure into a deployment directory at the least causes
> confusion, not to mention that the deployment directory might not even
> exist on the development machine. (I routinely compile kernels and
> modules of different configurations for three boxes on one of them,
> the other two don't even have a complete development toolset.)

yes, and most of the time you want to compile against the currently
running kernel, at which point `uname -r` comes in handy; for other
kernels you just change the path a bit.
make install and make modules_install make the symlink right already....
it's a 99% solution, sure, but it's ok for all but a few cases.

  signature.asc
< 1K Download
 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Olaf Tit » Mon, 20 Jan 2003 15:00:17


Quote:> > Compiling modules is one of the things which always have been among
> > the most broken things in the kernel build systems, can this please be
> > fixed and properly documented?
>   ^^^^^

> Some actual bug reports would be good.

The general bug is that there is incomplete infrastructure for
building modules outside of the kernel. You see the problem when
looking at the CIPE configure scripts, or the ALSA configure scripts.
Up to kernel version 2.4, it takes considerable effort to find out
just what compiler options to use. This is information which belongs
in some easily accessed location.

The desirable situation for module developers would be that a kernel
tree after configure run contains a Makefile (or equivalent) with all
necessary definitions which can be called from an outside module
source tree and just DTRT. The 2.5 kbuild stuff is close, but not
complete.

It is a bug that Documentation/modules.txt is so outdated that it
contains little useful information any more. It is a bug that
Documentation/kbuild/makefiles.txt is at least a bit outdated.

It is a bug that the build process outside of the kernel tree changes
files inside the kernel tree when MODVERSIONS is enabled. (At least
this was the case last time I checked.) This means the kernel tree
can't be mounted read-only, or at least you would have to do dirty
tricks with symlinks.

It is a bug that the current Makefile can't compile modules in an
object directory different from the source directory. This means the
module source tree can't be mounted read-only (again, without
resorting to symlinks).

It is also a bug that parts of the development infrastructure are
installed in /lib/modules/<version> and it's somewhat documented that
compiling modules needs this /lib/modules/<version> stuff. That may be
true for the ideal, simplified Red Hat world but in reality the
machine and running OS version of the development machine is likely
different from the box it will run on. Mixing development environment
and install target only causes confusion.

I don't know if real cross-compilation (i.e. for a different
architecture than the compiler runs on) of modules is possible
yet. If not, that's a bug too.[1]

Olaf

[1] Okay, on this count I'm guilty too with CIPE (just trying to sort
that out...)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Arjan van de Ve » Mon, 20 Jan 2003 15:30:11



> It is also a bug that parts of the development infrastructure are
> installed in /lib/modules/<version> and it's somewhat documented that
> compiling modules needs this /lib/modules/<version> stuff. That may be
> true for the ideal, simplified Red Hat world but in reality the
> machine and running OS version of the development machine is likely
> different from the box it will run on. Mixing development environment
> and install target only causes confusion.

you make a series of good points before this. However
/lib/modules/<version>/build is nothing Red Hat specific. It's something
that is the result of a similar discussion long ago where Linus finally
decreed this location for finding the full source of modules.
Combine that with the makefile dwmw2 showed and you can compile external
modules EVERYWHERE on ANY distribution (assuming said distribution
doesn't go out of the way to break the decree). Afaik RHL, SuSE,
Mandrake, Debian and Slackware at least have this correct.

Yes it breaks if you move around your source after doing make
modules_install. Yes it breaks if you don't have the tree at all. But
both situations are "invalid" wrt the decree, and need a fixed symlink.

  signature.asc
< 1K Download
 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Sam Ravnbor » Mon, 20 Jan 2003 20:30:15



> It is a bug that Documentation/modules.txt is so outdated that it
> contains little useful information any more.

An updated version that at least describe how to build modules sanely
outside the kernel tree is queued for inclusion[1].

Quote:> It is a bug that
> Documentation/kbuild/makefiles.txt is at least a bit outdated.

A totally revised makefiles.txt is queued for inclusion[1].

Quote:> It is a bug that the build process outside of the kernel tree changes
> files inside the kernel tree when MODVERSIONS is enabled. (At least
> this was the case last time I checked.) This means the kernel tree
> can't be mounted read-only, or at least you would have to do dirty
> tricks with symlinks.

I have posted 2-3 version of a "separate src-tree" patch.
But due to the existence of such weird things as oprofile and xfs it did
not work in all cases. I symlinked all makefiles, but wanted to avoid
catching the rest of the directories.
I want my queued stuff applied before revisiting this though.
Main usage has been to build kernels based on different configurations,
not to mount src on a read-only media, that's sort of a side-effect.

Quote:> It is a bug that the current Makefile can't compile modules in an
> object directory different from the source directory. This means the
> module source tree can't be mounted read-only (again, without
> resorting to symlinks).

make -C path/to/kernel/src SUBDIRS=$PWD modules
So simple when you know the trick. That what I have documented
in modules.txt.

[1] Most of what I have done has been submitted to lkml within the
past month. It can be found at http://linux-sam.bkbits.net in
the kbuild repository, where it is queued for inclusion.

        Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Paul Zimmerma » Mon, 20 Jan 2003 23:20:23


Quote:>> It is also a bug that parts of the development infrastructure are
>> installed in /lib/modules/<version> and it's somewhat documented that
>> compiling modules needs this /lib/modules/<version> stuff. That may be
>> true for the ideal, simplified Red Hat world but in reality the
>> machine and running OS version of the development machine is likely
>> different from the box it will run on. Mixing development environment
>> and install target only causes confusion.

> you make a series of good points before this. However
> /lib/modules/<version>/build is nothing Red Hat specific. It's something
> that is the result of a similar discussion long ago where Linus finally
> decreed this location for finding the full source of modules.
> Combine that with the makefile dwmw2 showed and you can compile external
> modules EVERYWHERE on ANY distribution (assuming said distribution
> doesn't go out of the way to break the decree). Afaik RHL, SuSE,
> Mandrake, Debian and Slackware at least have this correct.

> Yes it breaks if you move around your source after doing make
> modules_install. Yes it breaks if you don't have the tree at all. But
> both situations are "invalid" wrt the decree, and need a fixed symlink.

Try "make modules INSTALL_MOD_PATH=<whatever>". Then modules
will use <whatever>/lib/modules instead of /lib/modules. This works in 2.4
and early 2.5, I haven't tried it with the new kbuild system in recent 2.5.
And
I don't know if this is properly documented anywhere.

Paul

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Paul Zimmerma » Mon, 20 Jan 2003 23:30:21


Quote:> Try "make modules INSTALL_MOD_PATH=<whatever>".

Oops, that should have been:

"make modules_install INSTALL_MOD_PATH=<whatever>"

Paul

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

ANN: LKMB (Linux Kernel Module Builder) version 0.1.16

Post by Olaf Tit » Tue, 21 Jan 2003 22:20:13


Quote:> > It is a bug that the current Makefile can't compile modules in an
> > object directory different from the source directory. This means the
> > module source tree can't be mounted read-only (again, without
> > resorting to symlinks).

> make -C path/to/kernel/src SUBDIRS=$PWD modules
> So simple when you know the trick. That what I have documented

no, this doesn't work when you have the source and object files _of
the module_ in separate directories. You'd have to run make in the
object directory, but there seems no way to tell it where the source
is. (At least I have not found any.)

The reason to do this is compiling one module for different kernel
configurations as well as compiling one kernel for different
configurations. I.e. I want to have a tree like this:

first the kernel:

/usr/src/linux/2.5.99/              this is directory X
/var/obj/linux/2.5.99/boxa          here is X compiled for boxa
/var/obj/linux/2.5.99/boxb          here is X compiled for boxb

(this doesn't work either at the moment, another bug/missing feature...)

then the external module:

/usr/src/cipe                       this is directory Y
/var/obj/cipe/2.5.99/boxa           here is Y compiled against X for boxa
/var/obj/cipe/2.5.99/boxb           here is Y compiled against X for boxb

and /usr/src might be mounted read-only.

Olaf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Module Programming: module version vs. kernel version

Dear all,

I've just started learning kernel programming on Linux. I just tried an
example "hello, world" module program. The program looks like:
#define MODULE
#include <linux/module.h>
int init_module(void)
{ print out a hello message}
void cleanup_module(void)
{print out a goodbye message}

It can be compiled into .o but when I tried to insmod, I got this error
message:
module compiled for kernel version 2.4.0-xxx
kernel version is 2.2.16-xxx

I have no clue how to fix it. Please help. Thank you very much.

Crystal

2. process limits?

3. beginner module question: kernel-module version mismatch

4. Reading is much more interesting than TV (1382/1708)

5. loading version nonsensitive module into version sensitive kernel?

6. Solaris 8 Evolution

7. load module error--kernel-module version mismatch

8. setfacl usage

9. SoundBlaster 16 (Vibra 16) Problem with kernel 2.4.0

10. Ft. Worth - Linux Kernel Module Programmer - Unix kernel modules & Unix device drivers

11. Application Builder (like Borland C++Builder) for LINUX ?

12. HOT!! 16 different versions of linux CD download