Re: config(5) break down

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

config(5) has 4 ways to define a collection of sources:

                        initialization  interface       dependency      
configurable
        device          autoconf(9)     bdev/cdev       y               y
        defpseudodev    xxxattach       bdev/cdev       n               y
        defpseudo       xxxattach       -               n               y
        define          -               -               y               n

I think "device" part is fine.  Device drivers are configured by autoconf(9),
and defined as "device".  Used with interface attributes (define xxx {}),
most of problems can be resolved.  (Some complex ones like scsipi / wscons
are their problems, not config(5).)

In sys/net* and some sys/kern there're some code that can be modular.  Most
of them are defined as either defpseudo or define.  If it's user configurable,
it should be defpseudo.  If it's simply a shared code, define.

There're lots of confusions in sys/conf/files; some are defflag or defparam.
Anything which _owns_ *.c, AND user-configurable should be defpseudo.  We'll
have "defpseudo inet" or "defpseudo ipsec" eventually.

defpseudo lacks some points:

- No dependency.
- No detach.

I think defpseudo's initialization and module's one can be merged.  Dependency
is also addressed naturally if defpseudo is always handled as modules.  
config(1)
is taught about defpseudo's dependency.  If config fragment like:

        defpseudo inet
        :
        defpseudo gif
        file if_gif.c gif

is passed, config(1) generates *.c and *.mk to build if_gif.kmod, which
depends on inet.kmod.

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635