Subject: Re: Port independent cdevsw
To: None <firstname.lastname@example.org, email@example.com>
From: Noriyuki Soda <firstname.lastname@example.org>
Date: 10/16/2000 20:13:07
> 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.
- 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
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.