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().

  You cannot statically check something that you dynamically load, and you
can certainly not handle all of something when you do not have information
on all somethings.  This is one thing you must sacrifice if you make
something dynamic.  Instead, you make the dynamic object contain all
necessary information (which is often faster anyway).  Instead of pointing
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.

  Major numbers are evil and should die.  Even if devfs must have
permissions reset early in the boot cycle each time, it is better than id
by number.

> 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.

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

> I agree with CGD: appealing to tool chain compatibility is a
>red-herring. GCC is already the most widely ported and used C-compiler, 
>to the point that I'm not really sure why Sun, HP and IBM still ship
>their own. I know that 3/4 of win32 environments that I've seen at
>customer sites are using MINGW32 now :-)
  
  Actually, some vendor compilers are much better then GCC and should
ideally be supported.  However, they almost certainly have some way to do
the same thing.

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

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

Matthew Orgass
darkstar@pgh.net