I consider that overengineering. I like the idea of being able to copy
any old foo.c into the directory and have it just picked up -- no
special makefile, no Config.in, just foo.c.
For modules more complex than a single .c file, a subdirectory with a
Makefile makes sense. But, for example, most of Donald's network
drivers are single .c files.
> > 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?
For modules consisting of a single file, there is usually only one
config option: CONFIG_FOO=m. And this is already implied by the fact
that the user copied the file into the directory. Other config options
are typically handled by module parameters instead.
> > * 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.
This autodetection breaks down if you use versioned dir names -- who
needs bar-1.02.o? Somehow I still like having extras/Makefile take
care of installation rather than extras/bar-1.02/Makefile having to do
it. Perhaps extras/Makefile would look in turn for
${dirname}/${dirname}.o and ${dirname}/${dirname%-*}.o. Not sure about
that one.
> 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...
> otoh, maybe this is too easy. We're talking about kernel code here.
> (Thinking kernel module virus)
Yeah, I don't know why it needs to be *totally* automatic. Anyone who
can wield `cp' can wield `tar', given a README. I distrust things that
untar behind my back, and I *really* distrust things that clean out old
version directories behind my back. What if I made local
modifications? What if I want to keep two sources around for diffing?
But either way it's a lot less hassle than driver writers have now,
where they each have to write a Makefile, figure out a way to get the
right -I/usr/src/... worry that if you compile the driver standalone
you might not have built version.h yet, etc. (Or, like Donald does,
supply a compile command for the user to cut 'n' paste.)
> 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 just don't like the idea of making bar-1.02/Makefile do anything it
doesn't have to. Maybe it should include ../Rules.extra rather than
the usual $(TOPDIR)/Rules.make. Then extras/Rules.extra would handle
"MOD_LIST_NAME := EXTRA_MODULES" und so weiter.
-- Peter Samuelson <sampo.creighton.edu!psamuels>- 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/