[DGD]Initializing problem

[Stephen Schmidt]

On Fri, 20 Apr 2001, Erwin Harte wrote:
> * In ~System/ create initd.c.
> * In ~System/sys/ create telnetd.c
> * In ~System/initd.c compile and initialize ~System/sys/telnetd.c
> * From either ~System/initd.c or ~System/sys/telnetd.c register the
>   newly created alternative telnet-manager as _the_ telnet-manager by
>   the call of USERD->set_telnet_manager(...object...).
> * From ~System/sys/telnetd.c you can now clone whichever user.c object
>   you please....

That's a lot of coding that I was hoping to avoid. Somewhat
more importantly (I enjoy this, so my coding time isn't such
a big deal) it's a lot of complexity, a lot of places where
I might mess up, and a lot of code a hypothetical end user
might get lost in. As anyone who's seen Melville knows,
I usually prefer the simple solution over the elegant one
wherever an end user is concerned.
 
> It is of course entirely up to you to replace
> bits and pieces of the /kernel structure...

Sure, but in this case, whether I bypass /kernel/obj/user.c
via the initd and the telnetd, or whether I just blast it
out of my way directly, either way I'm replacing it. Either
way, if there are changes to /kernel/obj/user.c in future
kernel libs, my mudlib won't pick them up until or unless I
rewrite my version of user.c. So I'm not sure that I really
gain any extra forward compatibility by going through the
two daemons.

If you want to apply patches cleanly, all you need do is:

1) keep a copy of the original kernel user.c;
2) at patch time, copy your user.c out of the mudlib and
   copy the original back in;
3) run the patch;
4) copy your user.c back into the mudlib;
5) make any changes to your user.c you feel are required.

You lose any changes made to the kernel's user.c, but you
weren't using it anyway, so nothing meaningful is lost.

Pull a similar routine if you want to replace the old kernel
with a new one. I am pretty sure that /kernel/obj/user.c is
the only file that will need to be so handled. 

Does this suggest that perhaps, /kernel/obj/user.c should
not be under /kernel? I do not feel qualified to hold an
opinion on that matter; but it does seem to me that 
/kernel/obj/user.c is different from other kernel files
in significant ways.

Steve


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