Anders Magnusson <ragge@ludd.luth.se> writes:

> > It's not clear what use the 'struct device *' actually is, unless it's
> > your intent to add functions to 'struct cfdriver' for a 'devfs'...
> > 
> No, it's to extract the device name and put it into the devfs, if wished.
> It's unneccessary if you're only going to register a device and not want/
> want special entries in devfs.

Uh, my point is, what does the 'struct device *' get you?

OK, so you now have '/devices/sd0' or whatever.  there are a lot more
-- driver, not unit -- dependent nodes which are necessary.

I'd say that the right way to do this is a function pointer in the cfdriver.


> > Also, i think this is a bit flawed.  you want the devsw entries to be
> > common to all instances of a single device type, and you don't really
> > represent that in this interface.
> > 
> > really, what you probably want is to have the 'struct cfdriver's for
> > devices which needs device switch entries to just have pointers to the
> > switch entries in them, then do this all under the covers.
> > 
> This requires that it is generated when compiling a kernel. I want
> to keep this away from dependencies of statically linked kernels.
> The ideal solution would be a LKM system that talks with the "normal"
> autoconf stuff and fixes this. Humm, it might be an idea... :-)

OK, yes, I overlooked the case of 'what to do with a pseudo-device,' i
think.  but for 'normal' drivers the cfdriver struct _is_ the right
place to put it.  Note that this may mean that the current location of
the cfdriver structs (generated ioconf.c) isn't the best...  8-)

yes, loadable modules need to be glued into the autoconfiguration
system.  This is not news.


thinking aloud:

maybe it makes sense to do the pseudo-device initialization as
something more like:

	{ &pdevstruct, count }

similarly to the way real drivers are currently configured.

oooh, going further:

keep a dynamically allocated device configuration table and
pseudo-device configuration table, in addition to the pdevinit and
cfdata tables.  then at startup do something like:

	foreach dev in cfdata
		cfdata[dev].cookie = add_dev_config(cfdata[dev]))
	foreach pdev in pdevinit
		pdevinit[pdev].cookie = add_pdev_config(pdevinit[pdev])

it then becomes obvious how to glue additional devices into the
kernel, and additional pdevs, and remove them... and i think it's much
less of a kludge than other ideas i've seen.

Of course, it wastes memory, though in proportion to the amount of
'configured stuff' there is in your kernel...  8-)


> This gave me lots of new ideas! Great! I'll rethink this and come up
> with a new proposal. This was the perfect type of followup :-)

Glad that I could help.  Hopefully some of the additional ideas above
will provide some more food for thought...



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.