But a simple user with no rights can mlock (64kb by default) why a jail would
not be able?
From: Xin LI<mailto:delp...@gmail.com>
Sent: Thursday, February 2, 2017 1:13 PM
To: Pavel Timofeev<mailto:tim...@gmail.com>
Cc: Bruno Lauzé<mailto:brunola...@msn.com>;
freebsd-curr
ary 1, 2017 8:31:35 PM
To: Bruno Lauzé
Cc: freebsd-current
Subject: Re: mlock and jail
I like this idea.
Note that potentially your patch would make it possible for a jailed
root to DoS the whole system by locking too much of pages in memory.
I think it would be sensible to provide a per-jail fl
I would like to ask if there is a reason I would have to applythe patch below
to make an application work in a jail.
And who's bad? the app too intrusive or the bsd not flexible enough
(allow.mlock?)
Index: sys/kern/kern_jail.c
=
Revision 285139 broke "options ZFS" because of filename collisionCan we rename
.c files in sys/contrib/libnv to avoid zfs libnv files
dnvlist.c -> ldnvlist.c nvlist.c -> lnvlist.cnvpair.c -> lnvpair.c
There is already bug 201356 for this. I confirmed it's working...
Is there a reason for this:
@wheeluser: rebootOperation not permitted@wheeluser: shutdown -r nowSystem halt
What's the difference?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/
I was looking at dragonfly and why they have libdevattr and we don'tI really
think having udev compatible api would open the door to a lot of software,
imho.I feel it wouldn't be so complicated to port dragonfly kern_udev, libprop
and libdevattr from dragonfly bsd.
Am i missing a point or is thi
building from trunk:
usr.sbin/bhyve/pci_emul.c is picking up old vmmapi.h from /usr/include/vmmapi.h
instead source one:
for me it results vm_get_lowmem_size and vm_get_highmem_size missing...
any ideas? I think we need to include lib/libvmmapi folder so includes are kept
from /usr/include ones
> On Wed, 2014-05-07 at 08:39 -0400, Bruno Lauzé wrote:
>> One thing I feel FreeBSD always ignored is instrumentation frameworks.
>> I am talking about wbem, cim model and implementation like OpenPegasus. Why
>> is that?
>> I ported OpenPegasus to work in FreeBSD with
One thing I feel FreeBSD always ignored is instrumentation frameworks.
I am talking about wbem, cim model and implementation like OpenPegasus. Why is
that?
I ported OpenPegasus to work in FreeBSD with few patches.
However, of course without providers a wbem doesn't go far. I started to see
how t
I am experiencing issue related to r263638.During a ZFS Install, it does create
a new volume for /root but bsdinstall cannot copy "root/.cshrc" during base.txz
extraction.Would we want to but ",canmount=off" or change the way root profile
gets created for zfs install?
What could be the cause?
nola...@msn.com; a...@freebsd.org
>
> On Wednesday, March 12, 2014 5:13:28 pm Bruno Lauzé wrote:
>> The two defines in vm/vm_map.h
>>
>> #define min_offset header.start /* (c) */
>> #define max_offset header.end /* (c) */
>>
>>
>> are really ge
The two defines in vm/vm_map.h
#define min_offset header.start /* (c) */
#define max_offset header.end /* (c) */
are really getting in the way because those words are most likely to be used
downstream.
I would suggest renaming those defines to:
#define vm_min_offset header.star
It's really good to read the comments and see people point of view on this
topic.
I totally agree RC system is really good and stable, easy and extensible.
The main concern I have here is performance. Starting a system is really slow.
Boot to X (with simple xdm) is minimum 25 secs and I just feel
https://github.com/brunolauze/libnit
I know there's really big debate about init system but here's my tentative to
propose a new model to replace rc.
Let's call it libinit but the name as no significance for now.
I started coding a library with the following architecture.
the main idea is to r
root@pcbsd:/dev # stat /dev/ada0
1895890688 97 crw-rw-rw- 1 root operator 97 0 "Feb 18 10:52:11 2014" "Feb 17
09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 0 /dev/ada0
root@pcbsd:/dev # stat /dev/ada0p2
1895890688 103 crw-rw-rw- 1 root operator 103 0 "Feb 18 10:52:05 2014" "
I am compiling zfs in-kernel and it's working pretty well. However to succeed
building a kernel
with :
options zfs
device crypto
device cryptodev
a patch is needed to rename sys/opencrypto/deflate.c which enter in conflict
with deflate.c from zfs
After renaming sys/opencrypto/deflate.c to s
16 matches
Mail list logo
