cvs commit: src/sys/sys msg.h sem.h shm.h

Robert Watson rwatson at freebsd.org
Sat Nov 20 14:49:47 GMT 2004


On Sat, 20 Nov 2004, Alexander Leidinger wrote:

> On Sat, 20 Nov 2004 13:14:32 +0000 (GMT)
> Robert Watson <rwatson at freebsd.org> wrote:
> 
> > > Are you talking about the userland API, or about the in-kernel API? 
> > 
> > Userland API; implementing the kernel side, modulo dealing with the
> > loading and unloading issue, is relatively straight forward.
> > 
> > > If you are talking about the userland API: wouldn't it be more easy if
> > > we use the following constraints?
> > >  - The admin of the host has no direct access to the jails IPC, only an 
> > >    admin in the jail can manage it (the host admin can use jexec to  
> > >    manage IPC).
> > >  - If a jail gets shut down, all IPC resources of this jail are removed.
> > 
> > Sure.  But that makes it fairly inconvenient to track resource usage over
> > a large number of jails.
> 
> One step after another... :-) First we get the feature "everyone" is
> asking about, then we look how to improve it. We don't have to keep
> those restrictions, but in the mean time having them is better than the
> actual way of doing things with System V IPC. 

One of the primary virtues of Jail is that it is not only every convenient
to use and manage, but that the implementation is easy to comprhend and
conservaitive, maximizing the chances that the implementation is correct. 
These virtues generally don't apply to System V IPC, which is why it is
hard to wedge into Jail in a sensible manner.  While a solution is clearly
desired, attempting to implement a consistent and sensible solution is a
much better idea than hacking it together and leaving us with an
unmaintable and barely usable implementation.  A little bit of time spent
now considering the implications of an approach can save a lot of time
later that will be wasted chasing obscure bugs or haivng users trying to
work around difficult to solve problems that are a property of a poor
design.  In particular, if you introduce APIs and tools now that work
poorly, we will be obligated to continue supporting them for compatibility
reasons in the future for a substantial period of time.  My feeling is
that adopting a model that lends itself to easy mangement is critical to
the success of any additions to Jail, and should be a primary concern up
front.  Let's not turn Jail into a pile of hacks...

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research




More information about the cvs-src mailing list