[DGD]Initializing problem

Mikael Lind z94lind at mtek.chalmers.se
Fri Apr 20 10:59:55 CEST 2001


Quoting Stephen Schmidt from 00:30, 2001-04-20:

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

Not really lots of coding. Probably several lines spread amongst a
couple of objects. Please remember that the kernel library was
designed to have its default user object replaced in the simple yet
elegant way recently described on this list. Think of /kernel as a
directory that you can touch if you want to. If you do, you will be
cursed in the following ways:

  - The admin backdoor on the binary port uses the default user
    object. If this object is broken, you have no command
    access. Your last line of defence has been breached. Time for a
    reboot.

  - Errors in /kernel can, as you have noticed, damage DGD's
    debugging support in form of error logging. In fact, since most
    parts of /kernel rely on other parts feeling OK, a lot of
    unexpected problems are to be expected. Take a walk in the 
    dark. Try not to bump into anything ... again.

Your solution is not that much simpler than the standard one and it
can easily turn the solid highland of the kernel into a mudslide.
What are you going to stand on then, the driver? To me, that is
simplicity taken across the border to stupidity.

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

For the backdoor functionality to work, it makes perfect sense to
have a kernel user in /kernel. The customized user you are referring
to should perhaps be outside of /kernel. How about ~System/obj?

On a more serious note, I think it could be a very good idea to
supply minimal implementations of ~System/initd, ~System/sys/telnetd
and ~System/obj/user with the kernel library. This will give new
developers a good place to start hacking at. Any comments on this?

// Mikael / Elemel

--
Give up yourself unto the moment / The time is now / Give up yourself
unto the moment / Let's make this moment last // Moloko


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



More information about the DGD mailing list