Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/lib

2010-07-26 Thread Alistair Crooks
On Mon, Jul 26, 2010 at 03:56:07AM -0700, Tom Spindler wrote: > > Modified Files: > > src/crypto/external/bsd/netpgp/dist/src/lib: keyring.h packet-print.c > > Added Files: > > src/crypto/external/bsd/netpgp/dist/src/lib: mj.c mj.h > > > > Log Message: > > add a minimalist JSON implementat

Re: CVS commit: src/sys/kern

2010-07-26 Thread Antti Kantee
On Mon Jul 26 2010 at 18:15:33 +0200, Juergen Hannken-Illjes wrote: > Commit message changed as: > > When both vget() and vrelel() call vn_lock() we know VI_XLOCK is clear. > No need to use LK_INTERLOCK or LK_RETRY here. > The return value of vn_lock() is already examined here. > >

Re: CVS commit: src/sys/kern

2010-07-26 Thread Juergen Hannken-Illjes
On Mon, Jul 26, 2010 at 06:33:57PM +0300, Antti Kantee wrote: > On Mon Jul 26 2010 at 15:22:17 +, Juergen Hannken-Illjes wrote: > > Module Name:src > > Committed By: hannken > > Date: Mon Jul 26 15:22:16 UTC 2010 > > > > Modified Files: > > src/sys/kern: vfs_sub

Re: CVS commit: src/sys/kern

2010-07-26 Thread Antti Kantee
On Mon Jul 26 2010 at 15:22:17 +, Juergen Hannken-Illjes wrote: > Module Name: src > Committed By: hannken > Date: Mon Jul 26 15:22:16 UTC 2010 > > Modified Files: > src/sys/kern: vfs_subr.c > > Log Message: > When both vget() and vrelel() call vn_lock() we know VI_XLOCK is cle

Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/lib

2010-07-26 Thread Tom Spindler
> Modified Files: > src/crypto/external/bsd/netpgp/dist/src/lib: keyring.h packet-print.c > Added Files: > src/crypto/external/bsd/netpgp/dist/src/lib: mj.c mj.h > > Log Message: > add a minimalist JSON implementation, and add a new function to access the > data, and serialise it using

Re: CVS commit: src/sys/arch

2010-07-26 Thread Matthias Drochner
c...@cubidou.net said: > > keep out paddr_t from the kernel ABI relevant to modules. > You won't keep bus_addr_t out of the ABI any time soon, so this is not > a fix. It is not correct anyway to tie bus_addr_t to paddr_t -- the semantics of the buses don't depend on the CPU but on chipsets, or ar