Surely you could trace the X11 IPC in dtrace or something, and see
what the actual messages are?
(Surely there's X11 protocol profiling stuff out there?)
Adrian
On 28 July 2011 10:12, Sean C. Farley s...@freebsd.org wrote:
On Wed, 27 Jul 2011, Gleb Kurtsou wrote:
On (27/07/2011 00:48),
$ fgrep -w -r CS drm
...
drm/include/drm/drm_mode.h:#define DRM_MODE_FLAG_NCSYNC (18)
$ fgrep -w -r CSY drm
...
drm/include/drm/drm_mode.h:#define DRM_MODE_FLAG_NCSYNC (18)
$ fgrep -w -r CSYN drm
nothing (exit 1)
$ fgrep -w -r NCS drm
nothing (exit 1)
$ fgrep -w CS drm/include/drm/drm_mode.h
The attached patch allows better fine-tuning of jails started via
/etc/rc.d, uses the new jail(8) flags (-c -m), the persist parameter and
adds ZFS support.
Patch is fully backward compatible.
Please review, comment and/or test my attached patch.
Cheers,
mm
--
Martin Matuska
FreeBSD committer
Please review my attached patch.
The patch fixes f_mntonname with mount/unmount inside a jail with allow.mount
enabled.
Filesystems mountable in a jail require the VFCF_JAIL flag (currently only ZFS).
With this patch, mount and unmount works both with enforce_statfs = 0 and
enforce_statfs = 1.
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
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
If you start jail(8) witth -c (the new param way,) the values of the
actual security.jail. variables are not initialized inside the jail,
default values are used instead. I don't know if this is intentional,
but probably yes. Default enforce_statfs=2, allow.mount=0.
As of me we can leave
Yes, it was intentional to move away from the global sysctls and to the
per-jail parameters instead. It makes more sense once config files come
into play, which can do a better job of providing global defaults as
well as per-jail parameters.
The connection between ZFS and persist makes
Hi there, my apologies in advance if this is the wrong mailing list for
this type of question. I have a problem with a previously-RAID1'd
FreeBSD filesystem I was hoping someone could help me with. The
background is this:
The disks originally belong to a client of a friend running an old
obsolete
On Wed Jul 27 11, René Ladan wrote:
2011/7/27 Alexander Best arun...@freebsd.org:
On Wed Jul 27 11, René Ladan wrote:
2011/7/27 Gleb Kurtsou gleb.kurt...@gmail.com:
On (27/07/2011 00:48), Alexander Best wrote:
On Mon Jul 25 11, Matthias Andree wrote:
Am 25.07.2011 09:21, schrieb
For vfs_mount, the easiest way to look at this is to follow the path of
the realfspath argument.
It goes to vfs_domount_first() and ends up in vfs_mount_alloc() where is
the only place it is consumed:
strlcpy(mp-mnt_stat.f_mntonname, fspath, MNAMELEN);
The original fspath (not realfspath) is
11 matches
Mail list logo
