cgd wrote:
> And, finally, as I've expressed before, I'm of a mind to have the
> tables defined neither statically nor at config time, but rather
> dynamically at run time from linker-assembled tables defined by
> drivers that need them.  there are a few reasons for this:
> 
> (1) you need good mechanism to add majors at run-time for
>     loadable drivers.  The "lkm dummy" garbage is simply
>     not sufficient, as far as i'm concerned.  Given that,
>     you should be able to use it for 'normal' devices too.
> 
> (2) you can actually use the same mechanism for loaded drivers as
>     normal ones, making conversion to loadable drivers slightly easier
>     -- there's a lot of other stuff to be done.

I agreed with these issues.

But this can be done without a linker generated table, by the following way:
	static configuration case:
		config(8) generates the table from the information
		supplied by metafiles like files.*
	dynamic configuration case:
		in-kernel configuration framework generates the
		table from either
			- information supplied from binary metafiles
			  which are generated from the metafiles 
			  in static configration case.
		or
			- random free major number which is not currently 
			  assigned to any devices, if major number is 
			  not supplied by the metafiles.
			  (in this case, major number is dynamically
			   assigned).
		Users can choose either way (metafile specified
		constant number, or configuration framework generated
		dynamic number for device major number) dynamically.

> (3) in fact, it's not technically hard, nor confusing, nor
>     unpredictable, despite FUD to the contrary.  And some mechanisms
>     for doing it are easily accomodated by some features that have to
>     be present in every modern linker.  
>     And you need constructors
>     for other desirable desirable kernel features anyway.

The constructor/destructor feature also can be implemented 
without a linker generated table in a way which gereralize 
current vfs initialization/termination method.
No non-ISO-C feature is needed in this way.
--
soda