tech-kern archive

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

Re: config(5) break down



Update:

cube@ taught me that the only thing which can be depended is "attribute" (==
something which is "define"'ed).  This answered most part of questions I had
yesterday.

I've found that the difficulty of understanding config(5) is due to its
flexibility; it can do one thing in many ways.  You can define a collection
of sources with define, defflag, device, defpseudo{,dev}, devfs.  OTOH you
can only write dependency on attributes (define).  Another example is, you
can write interface with define, device, defpseudodev.

I'd propose to make a rule to simplify things (at the cost of a little
redundancy of config(5) files).


a) Always use "define" to define a collection of sources

If device, def* have collection of sources, use dependency on define.  For
example, instead of writing:

        device  joy
        file    dev/ic/joy.c    joy

Write this way:

        define  joy
        file    dev/ic/joy.c    joy
        device  joy: joy

This can be read as:

        define  joy
        -> define a collection "joy"

        file    dev/ic/joy.c    joy
        -> file "dev/ic/joy.c" belongs to the collection "joy"

        device  joy: joy
        -> define a user-configurable device entry "joy" for the collection 
"joy"


b) Always use "define {}" to define an interface

Instead of writing:

        device  pci {[dev = -1], [function = -1]}
        attach  pci at pcibus
        file    dev/pci/pci.c   pci

Write this way:

        define  pciif {[dev = -1], [function = -1]}

        define  pci
        file    dev/pci/pci.c   pci
        device  pci: pciif, pci
        attach  pci at pcibus

This can be read as:

        define  pciif {[dev = -1], [function = -1]}
        -> define an interface "pciif" (where pci devices are attached)

        define  pci
        -> define a collection "pci"

        file    dev/pci/pci.c   pci
        -> file "dev/pci/pci.c" belongs to the collection "pci"

        device  pci: pciif, pci
        -> define a user-configurable device entry "pci" for the collection 
"pci"
        -> device "pci" implements the interface "pciif"

        attach  pci at pcibus
        -> device "pci" attaches at "pcibus"


By following these rules, config(5) components can be classified like this:

- module
  - collection (define)
    - device
    - defpseudodev
    - defpseudo
    - deffs
    - defflag
    - no entry
  - interface (define {})
- option
  - defflag
  - defparam
- others


Note that:

- defflag is used in two ways: one is to define a module, another is to define
  an option.  Module is a collection of sources that don't need initialization
  and don't provide pre-defined services (like devices or filesystems).  
Example is
  COMPAT_LINUX.

  Option is to change part of code.  Of course there's lots of confusions of
  the uses of them.  There're defflag/defparam that adds collection AND change
  code.  We have to *fix* these instances.

- define with no entry (device / def*) is just a collection of sources, which
  user don't need user-configurable entry.  These are commonly used by other
  parts & pulled in implicitly.


Masao

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


Home | Main Index | Thread Index | Old Index