[okl4-developer] adding a wombat driver

[Hal Ashburner]

On Tue, 2007-08-07 at 01:16 -0400, Jorge Torres wrote:
> Hi okl4.org,
> 
> Just in case someone ever has the same question, this are some basic
> conclusions on OKlinux driver writing, please correct me if I'm
> wrong: 
> 
> *As Ben said sometime ago, Making a driver to bridge between l4, and
> wombat is MUCH MUCH more easier than adding new wombat syscalls.
> *The easier way is to simply add the new .c driver file in
> linux/kernel/arch/l4/drivers folder (say
> linux/kernel/arch/l4/drivers/testrv.c). 
> *Then add obj-$(CONFIG_TESTSRV) += testsrv.o to the
> linux/kernel/arch/l4/drivers/Makefile
> *Then somewhere on linux/kernel/arch/l4/Kconfig add something like:
> menu "TESTSRV"
> config TESTSRV
>     bool "Use testsrv" 
>     default y
> endmenu
Or avoid all that by adding obj-y += testsrv.o to the makefile.
You can make it configurable later once you have the driver actually
working.

> As Hal explained:
> *Comment line 106 of linux/kernel/arch/l4/Makefile the one that says: 
> "include $(KBUILD_SRC)/$(ARCH_DIR)/sys-$(SYSTEM)/Makefile"
> *make a kernel configuration file 
> $ cp linux/kernel/l4linux_config_<arch> linux/kernel/.config
> *backup config file:
> $ cp linux/kernel/l4linux_config_<arch>
> linux/kernel/l4linux_config_<arch>_B
> $ make menuconfig (one must have libncurses installed to do so) 
> * just save, since new config is default y. 
> * Uncomment line 106 of linux/kernel/arch/l4/Makefile
> 
> WARNING: remove any linux/kernel/.config* file or else build will
> error fail (don't know why??)

Yes, like I said, you need to move the .config file to something like
l4linux_config_$arch_$config
Then you need to edit the SConscript file in linux/kernel to use that
linux configuration file. I probably should have spelled that out more
clearly rather than just writing out the commands, sorry.

The linux make based build system is invoked from scons with the -C
switch which copies the specified configuration file to your build
directory and renames it  to .config. Having two .config files (one in
the build directory and one in the source directory) obviously would
confuse things, which should the build system use? The linux build
system deciding that it will fail in that case is actually IMHO a good
thing, if you forget to move the .config generated by make menuconfig it
fails, rather than leaving you to spend a bunch of time working out why
your changes weren't respected. Obviously the design of the linux build
system was such that you can build a bunch of different configurations
from the same source tree, easily, without them conflicting. We like,
use and endorse this feature. :-)

> 
> And thats it, 
> 
> A simple driver testdrv.c: 
> 
> #include <linux/module.h>   
> #include <linux/kernel.h>   
> #include <linux/moduleparam.h>
> #include <linux/init.h>
> MODULE_LICENSE("Dual BSD/GPL");
> static int __init mp_init_module(void) 
> {
>     printk(KERN_INFO "This should be printed on Wombat
> initialization...\n");
> }
> 
> static void __exit mp_cleanup_module(void)
> {
>     printk(KERN_INFO "ci vediamo!\n");   
> }
> module_init(mp_init_module);
> module_exit(mp_cleanup_module);
> 

-- 
Kind regards,
Hal Ashburner