On 06/17/13 15:02, Robert N. M. Watson wrote:
On 16 Jun 2013, at 23:48, Kirk McKusick wrote:
I suppose it's safe to say further comment isn't forthcoming. So with
one vote for and one against (or at least questioning), I'll humbly
leave it up to myself to be the tie-breaker :-).
Here's a prop
On 06/16/13 00:20, Konstantin Belousov wrote:
On Sat, Jun 15, 2013 at 05:23:50PM -0600, Jamie Gritton wrote:
Index: sys/dev/mem/memdev.c
===
--- sys/dev/mem/memdev.c(revision 251793)
+++ sys/dev/mem/memdev.c(working
On 05/20/13 16:56, Kirk McKusick wrote:
I pointed Robert and Pawel at your discussion on creating a new
PRIV_KMEM and adding a check for it in memopen(). I am of the opinion
that this is a good idea, but I am hoping that one of Robert or Pawel
will comment since they are much more active in this
On 05/26/13 07:33, Joe wrote:
Alexander Leidinger wrote:
On Sat, 18 May 2013 07:36:01 -0600
Jamie Gritton wrote:
On 05/18/13 05:43, Konstantin Belousov wrote:
On Fri, May 17, 2013 at 01:14:23PM -0600, Jamie Gritton wrote:
I'm considering Alexander Leidinger's patch to make X11 w
On 05/18/13 05:43, Konstantin Belousov wrote:
On Fri, May 17, 2013 at 01:14:23PM -0600, Jamie Gritton wrote:
I'm considering Alexander Leidinger's patch to make X11 work inside a
jail (http://leidinger.net/FreeBSD/current-patches/0_jail.diff). It
allows a jail to optionally have acce
I'm considering Alexander Leidinger's patch to make X11 work inside a
jail (http://leidinger.net/FreeBSD/current-patches/0_jail.diff). It
allows a jail to optionally have access to /dev/io and DRI (provided the
requisite device files are visible in the devfs ruleset).
I'm planning on putting
On 01/30/12 10:55, Daniel Shahaf wrote:
Jamie Gritton wrote on Mon, Jan 30, 2012 at 10:38:16 -0700:
On 01/28/12 15:47, Daniel Shahaf wrote:
P.S. As an aside, the provision in projects/jailconf/'s jail(8) that
it's not possible for 'jail -r' to remove all jails _unless_ th
On 01/28/12 15:47, Daniel Shahaf wrote:
P.S. As an aside, the provision in projects/jailconf/'s jail(8) that
it's not possible for 'jail -r' to remove all jails _unless_ the '*'
syntax is used seems unusual to me: I expect 'jail -r foo bar' to remove
those two jails regardless of whether any oth
stent jails may also be created (won't be started) but will
be removed on a "stop"
http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.patch
http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.nowhitespace.patch
On 31. 7. 2011 0:32, Jamie Gritton wrote:
Yes, that looks
also set jid=xxx in params to have a "static" jail id for
this jail.
Also stopping a persistent jail doesn't delete it (but you cannot start
it again).
Dňa 28. 7. 2011 20:47, Jamie Gritton wrote / napísal(a):
Yes, it was intentional to move away from the global sysctls and to
the
;create" and "remove" in addition to
"start" and "stop"? Create would just make a processless jail, remove
would wipe out a jail and start/stop would just deal with the processes
(if persist=0 the old way, of course)?
Cheers,
mm
Dňa 28. 7. 2011 18:25, Jamie Gritto
There's a curious asymmetry here: enforce_statfs==1 is checked for
munging the name on unmounting, but not on mounting. I see the point on
the unmount side, as statfs would give the full un-jailed pathname and
an admin would naturally want to unmount what he sees mounted, but
without the same logi
Since I missed the 9.0 boat with jail config file capability, something
like this seems necessary; rc.d/jail has long been unable to handle the
full scale of what jail(8) can do.
I gather that setting persist is necessary for the ZFS operation. As
long as we're making the parameter setting more g
On 08/03/10 03:34, pluknet wrote:
I looked into sys/kern/* files to fix a bunch of common w/s style issues (221):
- leading space before label;
- leading space(s) before;
- space(s) instead of(s);
- space(s) in blank like.
I tried to be conservative and didn't touch semi-contrib files and
those
14 matches
Mail list logo
