[ovs-dev] ideas for improving kernel module build

Jesse Gross jesse at nicira.com
Thu Jun 23 02:12:56 UTC 2011


On Wed, Jun 22, 2011 at 2:38 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Wed, Jun 22, 2011 at 02:14:55PM -0700, Jesse Gross wrote:
>> On Wed, Jun 22, 2011 at 10:35 AM, Ben Pfaff <blp at nicira.com> wrote:
>> > I've been thinking a bit about the Linux kernel module build. ??It
>> > doesn't look all that much like how other Linux kernel modules build
>> > themselves. ??The "configure" step is really odd in that context.
>> >
>> > I think that we could get rid of the "configure" step. ??All of the
>> > Linux-related configure pieces are really simple. ??I think that we
>> > could embed them all into GNU make code within a Makefile. ??And then
>> > you could just run "make", possibly pointing an environment variable
>> > to the right directory. ??This would be much more like how other
>> > external kernel modules typically build. ??I think that proper
>> > dependencies would even be possible, so that it wouldn't be necessary
>> > to rerun a configuration step when KSRC changed or when some other
>> > kernel got checked out in the directory that KSRC pointed to.
>>
>> What about all of the checks for backported functions?  It seems like
>> that's a fairly large chunk of code that's part of the configure step.
>> Or do you mean something else?
>
> I think that those checks could be done right in the Makefile with
> proper dependencies.  For example,
>
>  OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [raw],
>                  [OVS_DEFINE([HAVE_MAC_RAW])])
>
> could become something like:
>
>  CHECKS =
>
>  ...other checks...
>
>  CHECKS += checks/have_mac_raw.inc
>  checks/have_mac_raw.inc: $(KSRC)/include/linux/skbuff.h
>        if grep raw $? >/dev/null; then echo '#define HAVE_MAC_RAW 1'; fi > $@
>
>  kcompat.h: $(CHECKS)
>        cat $(CHECKS) > $@
>
> Use of GNU make macros and syntax would probably make it more maintainable.

I don't feel too strongly about this.  I could see how it would make
things faster in event of a kernel change but I'm not sure that it
would be much more maintainable.  I'm ambivalent though.



More information about the dev mailing list