Subject: Re: dynamic configuration (was Re: PR#4094)
To: Matthew Orgass <darkstar@pgh.net>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
List: tech-kern
Date: 10/08/2000 19:47:36
>>>>> "Matthew" == Matthew Orgass <darkstar@pgh.net> writes:
    Matthew> On Fri, 29 Sep 2000, Michael Richardson wrote:

    >> In answer to CGD's question of what other things get in my way... well,
    >> I've only once had to define a new M_* type, and I think it may have been
    >> a mistake. I have never defined a new mount option, but I can see that
    >> might be a problem. Soda's solution is quite ingenious, except that it  
    >> loses the ability for the compiler to check that all enum's are handled
    >> in a switch().

    Matthew>   You cannot statically check something that you dynamically load, and you
    Matthew> can certainly not handle all of something when you do not have information
    Matthew> on all somethings.  This is one thing you must sacrifice if you make
    Matthew> something dynamic.  Instead, you make the dynamic object contain
  
  yes, this is a good point.
  My desire is to be able to build *static* kernels from CD. While being able 
to load modules for devices is nice during testing, the infrastructure for
adding things to autoconf is not that at present. I'd dearly like to add it,
but I think this will be a tempest in a teacup...

    Matthew> necessary information (which is often faster anyway).  Instead of pointing
    Matthew> to a string, point to a structure.  Problem solved. 

    >> I know that my proposed solution does not solve all problems. It solves
    >> a specific problem for me, is very simple, and is easily done. Yes, it is
    >> fragile, but it is no worse that the status quo.

    Matthew>   Major numbers are evil and should die.  Even if devfs must

  Fine. Who is getting rid of them?
  I'm agree that the best solution is good, but I'd like some solution soon.

    >> I am less enthusiastic about CGD's solution of scanning the .o files
    >> for constructor-like things. I've never been a fan of that kind of
    >> thing. I didn't like it when C++ did this, and I still don't.

    Matthew>   This is actually exceptionally useful.  The only thing C++ did wrong was
    Matthew> to not guarantee that initializers are called before main.  It is quite
    Matthew> reasonable to depend on init sections being available.

  It just seems messy to me. While I recall ROMTAGs on the Amiga exec and
even wrote a couple of apps that even survived reboots (not that we are
proposing to that!), I still prefer a config file that I can send to someone.

    >> But, I'd rather have all of this explicit in a config file

    Matthew>   If you use init sections properly, you don't need config files at all.

  I *LIKE* the config files. They are very useful. It needs to be easier to,
e.g. remove all PCMCIA devices for a machine that doesn't have that bus, but 
that is still nice.
  I also like things that are simple, because if they are complicated, I
can't delegate them to co-ops :-)

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [