[DGD] microkernel philosophy: how not to make ravioli code

Dread Quixadhal quixadhal at gmail.com
Mon Mar 3 21:04:49 CET 2014


Yes.  Basically, if it's something that's required by most of the entire
system, there's not much to be gained by trying to isolate it, as
everything has to end up funneling through it anyways.

There's also the question of how often it may have to escalate privs.  In
the case of an object manager, I'd expect it to need privs frequenly, since
it has to manage objects which will be owned by other users.


On Mon, Mar 3, 2014 at 1:54 PM, Raymond Jennings <shentino at gmail.com> wrote:

> So dread, your argument for stuff being kept in System has more to do with
> depended essential code and not so much minimizing the privileged
> footprint?
>
>
>
> On Mon, Mar 3, 2014 at 8:53 AM, Noah Gibbs <noah_gibbs at yahoo.com> wrote:
>
> > Speaking about non-DGD settings for a moment, it's quite common to run
> > many parts as entirely separate processes where possible.  You could do
> > this in DGD as well, though it's not standard practice.
> >
> > Quixadhal's point is a good one -- isolate as much as you can, but not
> > more :-)
> >
> >
> >
> >
> > On Monday, March 3, 2014 7:55 AM, Raymond Jennings <shentino at gmail.com>
> > wrote:
> >
> > 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
> > >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>



More information about the DGD mailing list