Messages in this thread | | | Date | Sat, 07 Oct 2000 20:14:30 -0400 | From | Jeff Garzik <> | Subject | Re: [KBUILD] Re: Adding vendor drivers... |
| |
Pavel Machek wrote: > > Hi! > > > So, when a vendor has to add a new driver, especially with the new-style > > makefiles, you have a one-line patch to a makefile, a one-line patch to > > a Config.in, and a patch which adds the driver to the tree. > > > > It would make adding new drivers to vendor kernel packages a whole lot > > easier and more modular if you could add a driver simply by doing: > > > > cp driver.c driver.config.in driver.mak linux/extras > > > > ...and then the makefile and config system automatically slurps this > > data. extras/Makefile could look something like: > > > > ...new style init.. > > include *.mak > > ...new style obj-x handling... > > include Rules.make > > > > Something similar would have to be worked out for Config.in. > > > > Of course, for anything complex, patching is still an option. > > > > Comments? Suggested implementation? :) > > Well, having .in and .mak files with single lines in them seems ugly > to me. What about make dep scanning for > > /* Makefile: obj-$(CONFIG_MY_DRIVER) += mydriver.o */ > /* Config.in: bool CONFIG_MY_DRIVER */ > > in .c files?
Don Becker has a similar solution in his newer net drivers. For single-c-file drivers it is wholly sufficient. For anything remotely complex, like a multi-file driver in its own directory, makefile fragments of some sort are necessary.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |