On Wed, Jun 22, 2011 at 2:38 PM, Ben Pfaff <[email protected]> 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 <[email protected]> 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. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
