Why thank you! :)
> But I don't like the "unpacked
> automatically" part -- would it unpack *each* time you run the build?
Actually I was thinking having all modules unpack into their own
directory with the same name. For example: mymodule-1.02.tar.gz
unpacks to mymodule-1.02 directory. My reasoning for this is that
every module will have to have a Config.in (maybe not) and some
documentation to appear when you press '?' in the config screen.
By including the version number in the directory you can automatically
weed out old versions of things. I was basically thinking that
when you recurse into the extras/ subdir, before looking for all
the modules to compile, run handle-extras.pl or something to go
through, weed out old versions and unpack new tar balls.
> Here's my variation on the above:
>
> * Makefile in extras/ assumes that any file foo.c is a standalone
> module to be installed as foo.o in the "extras" section
Good idea, but what about docs. Header in C file?
> * Makefile further assumes that directory bar/ is a standalone module
> to be compiled with its own Makefile; said Makefile is responsible
> for creating bar/bar.o, which will of course be installed in the
> "extras" section
Yes.
> * other files (baz.h etc) are ignored by extras/Makefile
>
> * user is responsible for untarring things
See above. I think that not having the end user need to
know how to untar things would be good. OTOH, if the know
how to move the file there...
A good gui/text frontend to it would make it all irrelevent
though.
<dream> you could go to a website and download mymodule.kmod,
it would ask if you want to install this module. It would
unpack, compile and install it. </dream>
otoh, maybe this is too easy. We're talking about kernel code here.
(Thinking kernel module virus) You could even have a file that
indexed pci/cardbus/pnp identifiers to driver names and make
finding drivers easy.
> * hmmm, what to do with MODVERSIONS / genksyms?
Well, i think that the makefiles that come with the modules
should look similar to the ones used elsewhere in the kernel
source. ie: use M_OBJS and MI_OBJS, etc. and include ../../Rules.make
This will handle versioning and possibly installation for you.
> > I got as far as getting it to unpack before my limited knowledge of
> > the kernel makefile and build system became a problem and I ran out
> > of time.
>
> I think I could code it. Anyone interested?
Well, I'm interested, dunno about anyone else.
> > You could even run a mini version of xconfig on the subdirectory to
> > allow users to configure it.
>
> I can't think of a real clean way to do *that*. For the same reason, I
> can't think of a real clean way to use this scheme for non-module code.
Well, I don't know anything about the *config things, but surely
it would be possible to pass a commandline argument to them telling
them what directory to start in.
Ofcourse, to make this work in its most advanced for (ie: config
help, docs, etc) you'd have to set down a standard so that the
Makefile can find them and clue them together appropriately.
Martijn van Oosterhout
Australia
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/