> 	devices -- cdevsw, bdevsw, chrtoblk (and a corresponding
> 	blktochr might be nice 8-), devnametobdevmaj.
		:
> the devices thing is extra special, actually: there's the
> [bc]dev.*_{init,decl} crap that is scattered all over when there's
> really no reason it has to be that way, there's always the fact that
> new devices are added and nobody bothers add them to conf.c files (and
> that when they do get added the chartoblktbl is always screwed up),
> and i've even seen stuff like mem_no screwed up.
> 
> If there are more sticking points, i'd love to hear more about them
> (and then we can see about making them better 8-).

UCHIYAMA Yasushi, MAEKAWA Masahide and Atsushi FURUTA are working
on this issue. (including dynamic device driver loading and dynamic
meta information -- files file -- treatment)

> a pointer to the structure is placed in a global list of like
> structure pointers, which is run through at kernel init time to set up
> lists and tables as appropriate.
> 
> something like:
> 
> struct devdesc {
> 	TAILQ_ENTRY(devdesc) link;
> 	const char *name; /* useful for root device stuff, at least */
> 	int bdevnum, cdevnum;
> 	struct bdevsw *bdev;
> 	struct cdevsw *cdev;
> }

Yeah, structure like this is needed.

> then something like:
> 
> 	static struct devdesc sd_dd = {
> 		{}, "sd", BDEV_MAJOR_SD, CDEV_MAJOR_SD, &..., &...
> 	};
> 	ADD_DEVDESC(&sd_dd);
> 
> where [BC]DEV_MAJOR_* are defined by an MD header file which can be
> included by drivers.  ADD_DEVDESC() would add the pointer to a
> ctor/dtor-like list which would be processed at kernel init time using
> a simple loop.  (This is doable without difficulty on both a.out and
> ELF, and simply requires a file to be added each as first and last file in
> the kernel link.  With a bit of care, a hack could even be done for
> new ports which don't use GNU tools or ELF to have the lists generated
> by the kernel build Makefile rather than the toolchain.)

They are planning different approach about this.
Rather than describing cdev/bdev <-> device name mapping in C source,
They are going to describe this in "files.*" (and dynamic loading
"files.*" information)

In this way, 
- we don't have to make a hack which depends on GNU toolchian.
- we don't have to describe same information in 3 places
  (conf.c, MAKEDEV, "files.*" file for devices which may become root device).
  cdevsw/bdevsw will be created by configuration framework
  automatically (even if dynamic loading case) via the "files.*"
  file iformation.
  MAKEDEV also can be created from the "files.*" file and MAKEDEV
  templates.
--
soda