Anders wrote:

> > > 	All major numbers are kept in an include file; machine/conf.h
> > > 	for example. [..]

I answered:

> > This doesn't work out for third-party stuff.
> >
> > There needs to be a "files" file anyway, so better only declare
> it there.
> > Second, lets add a keyword to config to let it add an arbitrary
> "files" file
> > as if it was included at the  end of "arch/$ARCH/conf/files.$ARCH".

And Anders replied:

> I think you are speaking about something else here, or I have
> misunderstood
> what you mean :-)

The latter. Right now third-party-stuff has to

 (a) patch arch/$ARCH/conf/files.$ARCH for each supported $ARCH
 (b) patch some "files" file(s)
 (c) let the user add something to his config file.

Your proposal eliminates (a). My suggestion would eliminate (b) too.

If you put the major numbers in machine/conf.h, the third-party stuff has to
patch this file to add his own majors. If you keep the majors in some
"files" file and allow a config file to specify additional "files" files to
include, the third-party stuff would deliver its own "files" file, the user
would request config to add this file (without patching anything) in his
kernel config file and thats all.

Another (related) point is: how are majors allocated. We had discussions
about allocating them at autoconfig (i.e. boot-) time via devfs, and someone
from BSDI suggested allocating them at config time. If config knows about
majors, it could provide two escape sequenceces for
"next-free-major-for-c/b-dev" and automatically track them. It the could
write a shell include file used by MAKEDEV to pick the allocated majors up.


Martin