[DGD] Kernel library updates

Raymond Jennings shentino at gmail.com
Sat Nov 17 10:28:39 CET 2018


On Fri, Aug 21, 2015 at 11:17 AM Raymond Jennings <shentino at gmail.com>
wrote:

> New updates pushed to git://github.org/shentino/kernellib
>
> Changes:
>
> * General work on resources
>
> I backed out a change allowing system resources to be removed.  My first
> attempt wound up making kernel code unclear and in some cases deceptive by
> implying resources where none existed.
>
> For now, they're back in and cannot be removed.
>
> Also, there is now stricter checking on resource manipulation.  Now,
> attempting to manipulate a resource that doesn't exist, or for a user that
> doesn't exist, now causes an error.
>
> * Patch function to restore system resources.
>
> I added a patch function to reinstate any system resources that were
> removed in the past.  Just recompile the kernel library, then call
> RSRCD->patch() from a System object.
>
> * Ownerless /usr directories are now accounted as Ecru
>
> I noticed that it was in fact possible to have a /usr directory
> corresponding to a user that does not exist in rsrcd.  Those directories
> are now accounted as Ecru.
>
> * Recompilation of an object now does not require object resource
>
> Since recompiling an object doesn't actually affect how many objects
> exist, it now no longer requires resource checks.
>

This change has been reverted.

Recompiling an object can still occupy a slot in the object table for
upgrades.


> * Creation of kernel objects is now exempt from resource checks
>
> Blocking the compilation or cloning of a kernel object can actually cause
> complications if for example the kernel library is being rebuilt and kernel
> inheritables cannot be compiled.
>
> Previously only telnet connections, binary connections, and resource
> objects were exempt, now the entire kernel is.
>
> * Admin wiztool is now exempt from resource limits
>
> Makes it possible to recover from accidentally killing the admin with
> resource limits.
>

This change has been reverted.  Admins can cause infinite loops just as
easily.


> * Simplify swap rate reporting in status command
>
> The old method was a bit more complicated than it needed to be, and could
> actually get messed up formatting if the swap rate got really high.
>
> * Don't pass infinite rlimits to user code
>
> There were a few places where an internal usage of infinite rlimits was
> passed back out to non kernel code.  One example was logging out a user
> when a connection was closed.
>
>
>
>



More information about the DGD mailing list