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
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
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
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:
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
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
> 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
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
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
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
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
11 matches
Mail list logo