[DGD] microkernel philosophy: how not to make ravioli code
Raymond Jennings
shentino at gmail.com
Mon Mar 3 16:52:02 CET 2014
Thanks.
Mostly I was worried about how much code I have in System that is
consequently privileged.
On Mon, Mar 3, 2014 at 7:25 AM, Dread Quixadhal <quixadhal at gmail.com> wrote:
> Usually, it's a question of dependance.
>
> The I3 subsystem, for example, is pretty much independant of the rest of
> the mudlib. If it goes down, it can be restarted with minimal impact on
> anything else, so having it run in a way that allows it to be easily
> updated and restarted is a good idea.
>
> The object manager, OTOH, seems likely to be entwined and used through the
> entire system. So ask yourself, what happens to the mudlib when you shut
> it down? If the answer is something like "the mudlib grinds to a halt
> until it comes back up", then it probably should stay as a System thing.
>
>
> On Mon, Mar 3, 2014 at 10:04 AM, Raymond Jennings <shentino at gmail.com
> >wrote:
>
> > So I've taken a shine to skotos's approach of putting subsystems (which
> > they call modules) into separate klib users to isolate them.
> >
> > I've since used this method to allow them to be nuked and rebooted on
> > demand, which is a nice sledgehammer for when my i3 daemon goes netdead.
> >
> > Is it going too far to have code isolated? Like for example, my next
> idea
> > is segregating the object manager away from System so that it can run as
> > unprivileged code.
> >
> > How far is too far before you stop making good code and start making
> > ravioli?
> >
> > I know this is a silly question but I'm new to good modularity.
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>
More information about the DGD
mailing list