tech-kern archive

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

config(1) ioconf doesn't seem good enough for pseudo-devices?

We have a fairly large number of device driver modules which use the (undocumented?) "ioconf" statement in config(1) to generate the various data structures needed by the config(9) mechanisms. This seems to work just fine for "real" devices, but for pseudo-devices the generated files don't quite work as expected.

As an example, we have src/sys/modules/crypto/crypto.ioconf

        ioconf crypto

        include "config/files"

        pseudo-device crypto

The generated file contains

        static struct cfdriver * const cfdriver_ioconf_crypto[] = {

        #define NORM FSTATE_NOTFOUND
        #define STAR FSTATE_STAR

        static struct cfdata cfdata_ioconf_crypto[] = {
            /* driver     attachment   unit state loc   flags pspec */
            { NULL,       NULL,           0, 0,    NULL,      0, NULL }

        static const struct cfattachinit cfattach_ioconf_crypto[] = {
                { NULL, NULL }

The problem arises when one attempts to pass the struct cfdata [] to config_attach_pseudo(). config_attach_pseudo() passes its argument to config_devalloc() which dereferences the .cf_driver member which is used as an argument to config_cfdriver_lookup(). Since the .cf_driver is NULL, we trap and panic.

So, is this a bug in config's ioconf processing? Or are my expectations of passing the generated cfdata to config_attach_pseudo invalid?

Side comment: Is it really necessary for config/ioconf to really generate 300+ lines of *_iattrdata[] related to devices/attributes not otherwise referenced in the ioconf device tree?

| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at |
| Kernel Developer |                          | pgoyette at  |

Home | Main Index | Thread Index | Old Index