[good explanation deleted]
Yeah, that part I did get. But:
The question is *where* new kauth_cred_t instance
should be created and assigned to the process:
1) Inside chroot/fchroot(2) (this is in my patch)
2) Modules that adds credential private data.
Is the kauth_t passed to the
On Tue, Aug 30, 2011 at 10:24:08AM +0300, Aleksey Cheusov wrote:
If all listerners unshare kauth_cred_t *unconditionally*, we lost data
set by kauth_cred_setdata. As I said later there is a workaround
(kauth_cred_getrefcnt or kauth_cred_copy) but I don't like it.
Ok, I got it now - thanks for
On Mon, Aug 29, 2011 at 07:08:06PM +, David Holland wrote:
So hold on. kauth_cred_t (ignoring some silly typedef issues) is the
process credentials structure, with the uids and gids in it. Right?
In the normal world, each process should have its own, so all sharing
is purely an
On Mon, Aug 29, 2011 at 04:28:00PM +, Christos Zoulas wrote:
In article 20110829151339.ga24...@asim.lip6.fr,
Manuel Bouyer bou...@antioche.eu.org wrote:
Hello,
I'm working on getting bpf(4) in a 64bit kernel play with a 32bit userland.
I've translated the ioctls, but I'm now stuck with
On Aug 30, 3:18pm, bou...@antioche.eu.org (Manuel Bouyer) wrote:
-- Subject: Re: netbsd32 emulation in driver open() or read()
| Yes, look at PK_32 in the process flags. If you are going to do this, please
| look at what FreeBSD did with bpf_ts/bpf_xhdr and the time format changes
| and do
On Tue, 30 Aug 2011, Manuel Bouyer wrote:
That may be nice to have, but won't help with my problem which is
getting a N32 mips binary to talk to a N64 kernel.
Hm, MIPS. In this case you may need to check the struct emul to
differentiate o32 and n32. Or do they have the exact same structure
On Tue, Aug 30, 2011 at 04:51:51PM +0100, David Brownlee wrote:
If the structure was versioned to have 64 bit fixed sized timestamps, then
the problem goes away for new code, though it does leave a COMPAT50 issue
for older code...
For new code that uses bpf_xhdr. If you don't change userland
On Tue, Aug 30, 2011 at 03:41:25PM +, Eduardo Horvath wrote:
On Tue, 30 Aug 2011, Manuel Bouyer wrote:
That may be nice to have, but won't help with my problem which is
getting a N32 mips binary to talk to a N64 kernel.
Hm, MIPS. In this case you may need to check the struct emul to
On Mon, Aug 29, 2011 at 09:33:50PM +, John Klos wrote:
Hi, all,
Is there any support for the Areca 1880, be it in -current or
someone's not-yet-checked-in tree?
It probably works. That's been the case with new Areca controllers in
the past. They are reasonably friendly, and would
[good explanation deleted]
Yeah, that part I did get. But:
The question is *where* new kauth_cred_t instance
should be created and assigned to the process:
1) Inside chroot/fchroot(2) (this is in my patch)
2) Modules that adds credential private data.
Is the kauth_t passed to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/19/11 22:04, Mindaugas Rasiukevicius wrote:
Lars Heidieker l...@heidieker.de wrote:
i uploaded a new version of the kmem-pool-vmem-uvm patch:
ftp://ftp.netbsd.org/pub/NetBSD/misc/para/kmem-pool-vmem-uvm.patch
Lars, can you generate
11 matches
Mail list logo
