Re: extended attributes and lsextattr/extattr_list_file

2012-02-02 Thread Emmanuel Dreyfus
YAMAMOTO Takashi wrote: > > We will need some macro to discover what API is available: FreeBSD-line > > in 5.x and Linux-like in 6.0. > i was assuming we have no releases on which the freebsd-style API is > actually usable. it it wrong? Yes, you are right. I committed code in glusterfs that u

Re: extended attributes and lsextattr/extattr_list_file

2012-02-02 Thread YAMAMOTO Takashi
hi, > YAMAMOTO Takashi wrote: > >> we need to decide what to be shipped for netbsd-6. (hope it isn't too late.) >> is anyone against the removal of freebsd-style syscalls? > > We will need some macro to discover what API is available: FreeBSD-line > in 5.x and Linux-like in 6.0. i was assumin

RE: rw_lock vs mutex

2012-02-02 Thread Paul Goyette
On Thu, 2 Feb 2012, paul_kon...@dell.com wrote: A rw_lock allows multiple readers, correct? If there's a non-trivial probability of concurrent reads that would make a difference. If not, then a mutex would be just as good especially if that is lower overhead. The rwlock in question is cont

RE: rw_lock vs mutex

2012-02-02 Thread Paul_Koning
A rw_lock allows multiple readers, correct? If there's a non-trivial probability of concurrent reads that would make a difference. If not, then a mutex would be just as good especially if that is lower overhead. paul -Original Message- From: tech-kern-ow...@netbsd.org [mailto:

Re: rw_lock vs mutex

2012-02-02 Thread Matt Thomas
On Feb 2, 2012, at 5:38 PM, Paul Goyette wrote: > While digging around looking into another problem, I noticed that the > piixpm(4) driver uses an rw_lock for its ic_acquire_bus/ic_release_bus > routines. ic_acquire_bus() uses rw_enter(..., RW_WRITER) and there doesn't > appear to be any use

rw_lock vs mutex

2012-02-02 Thread Paul Goyette
While digging around looking into another problem, I noticed that the piixpm(4) driver uses an rw_lock for its ic_acquire_bus/ic_release_bus routines. ic_acquire_bus() uses rw_enter(..., RW_WRITER) and there doesn't appear to be any use anywhere of RW_READER for that lock. The man page for rw

Re: kmem change related trouble

2012-02-02 Thread Matt Thomas
> kernel DSI read trap @ 0xa00011c8 by pool_cache_get_paddr+0x4c: srr1=0x9032 > r1=0xa22b9aa0 cr=0x28284084 xer=0x02000 ctr=0x1642c dsisr=0x4000 > > The backtrace: > copyright > kmem_intr_alloc > exec_elf32_makecmds > check_exec > execve1 > start_init, > setfunc_trampoline is that with th

Re: kmem change related trouble

2012-02-02 Thread Frank Wille
Lars Heidieker wrote: > I've just posted a patch ( http://www.netbsd.org/~para/fix.patch ) > - It moves uareas and buffer cache back to the kernel_map restoring > the previous behavior. Sizing the kmem_arena is changed accordingly > (Something I stepped on while checking evbmips on gxemul). > - Co

Re: Second stage bootloader (i386) hangs on ls command for ext2

2012-02-02 Thread Evgeniy Ivanov
On Sun, Dec 25, 2011 at 11:54 AM, Evgeniy Ivanov wrote: > Hi, > > On Sun, Dec 25, 2011 at 10:20 AM, Izumi Tsutsui > wrote: >> Hi, >> >> Evgeniy Ivanov wrote: >> >>> Izumi, thank you for reviewing! New patches are attached. >>  : >>> > I think it's better to use a positive LIBSA_ENABLE_LS_OP opti

Re: Question about tcp ephemeral ports

2012-02-02 Thread Olivier MATZ
Hi, Attached is a patch that makes my small test program working. I applies to 5.1 and 5.1.1 only. Porting it to current would be a bit harder due to the port randomization, as described by Eric previously. This is just a proof of concept and I would be happy to have some feedback about how to wr

SMP profiling -- patch, if someone cares to bring it up to date

2012-02-02 Thread Thor Lancelot Simon
I sent a patch considerably improving kernel profiling support to tech-kern while I was with Coyote Point. It is at: http://mail-index.netbsd.org/tech-kern/2010/12/11/msg009519.html I got a few comments about the code organization but not much else. I simply ran out of time to work on u