[DGD]Core library and initd.c

[Jason Cone]

> -----Original Message-----
> From: Par Winzell [mailto:zell at skotos.net]
> Sent: Friday, April 20, 2001 12:27 PM
> To: dgd at list.imaginary.com
> Subject: RE: [DGD]Core library and initd.c
> 
> In my opinion Dworkin's great strength is he masters the full spectrum,
> from tinkering in near-optimal assembly code to intuiting architectural
> designs, and through this mastery is the slave of neither extreme. This
> results in code and design that is a very unusual mix of flexible and
> generic on one hand, and finalized and settled on the other.


Agreed.


> I think ~System is one of these cases. For the kernel library to fully
> stand alone, it is appropriate for it to perform one well-defined call,
> placing the onus of integration entirely in the hands of the integrator.


Agreed.


> Modifying an include file in /kernel has a very different feel; it has
> the effect of 'pointing' the kernel library at your code. Sometimes, for
> some designs, that is a useful thing: e.g. DGD itself works that way.


Agreed.  Again, I correct my mistake; my intention was to use
'/include/kernel' instead of '/kernel/include'.  To further correct myself,
though, I think it quite reasonable to allow for "#define INITD
"/usr/System/initd" to be added to /include/config.h.


> But for the kernel library it it inappropriate. The self-containedness
> of the kernel library is the main reason it is interesting to me. When
> every piece of code I ever wrote has crashed, I can still log into the
> emergency admin port and fix the problem using code that I know has not
> been touched through my frenzied development. It's a great boundary to
> have -- to be able to rely on: no files go in /kernel. period.


Agreed.  Would the following in driver.c compromise the integrity of the
core system?

#ifdef INITD
	if (file_size(INITD + ".c") != 0)
	{
		catch
		{
			initd = load(INITD);
		}
	}
#endif

I fail to see how the above is any different than what currently exists.
There are, of course, those that would erroneously try and place initd.c in
a location such as /usr/System/obj/init.c, but such an irresponsible
configuration could be checked for in the above code.


> If you really wanted to change System to something else, the place for
> it would probably be in /include/config.h, but I advice against that.


I'm curious about your advice.  Given that the mudlib author is required to
modify config.h anyway (to enable persistence), I don't see how adding
another configurable value would cause any harm (under the assumption that
driver.c could check for the legitimacy of the defined INITD value).


JC

List config page:  http://list.imaginary.com/mailman/listinfo/dgd