tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: config(5) break down

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

                        initialization  interface       dependency      
        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.  
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 Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635

Home | Main Index | Thread Index | Old Index