At Thu, 13 Sep 2007 13:34:24 +0200,
Martin Husemann wrote:
> 
> There are two parts to this:
> 
>  - generate the module - I don't see how config(1) is involved here
> 
  I think Quentin has answered better to this.  config(1) knows how to
build all parts of the kernel, so it also knows how to build an LKM
once it is told (with new syntax) which part of the kernel goes to the
module.  Which means, you don't need to hand-craft files like
sys/dev/BUS/DEV/{Makefile,DEV_lkm.c} everytime you want the LKM
version of a device driver.


>  - load the right modules with proper args (modload/lkm.conf) - and
>    I don't quite see how config(1) would be usefull there either,
>    sounds more like we need some extensions to config(9)
> 
> (Side remark: we should ignore indirect configuration busses and always require
> manual lkm.conf editing for them, IMHO.)
> 

  Hmm, I may miss some points about loading LKMs, but what extra
information do we need to modload device driver LKMs other than we can
get from config(5)?

> Sorry, but I guess I did not quite understand what you are proposing,
> could you please explain?
> 
  In the linux camp, building a module of a device driver (or a
subsystem of the kernel) is very easy and just mark [M] instead of [X]
in menuconfig (as far as the device driver code supports module and
in-kernl forms).  What I want is to do the same thing with config(1)
and config(5).


> Martin

--
bsh.