Date: Sat, 20 Nov 2004 14:48:06 +0000 (GMT) From: Robert Watson <rwatson@freebsd.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/sys msg.h sem.h shm.h Message-ID: <Pine.NEB.3.96L.1041120144353.17641A-100000@fledge.watson.org> In-Reply-To: <20041120152558.342d5eac@Magellan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 20 Nov 2004, Alexander Leidinger wrote: > On Sat, 20 Nov 2004 13:14:32 +0000 (GMT) > Robert Watson <rwatson@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@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041120144353.17641A-100000>