wrote:
> I guess something like following change is necessary so that when both
> tv_nsec is set to UTIME_NOW,
>
> 1) to perform same permission check as when NULL is passed to 2nd
> arg.
> 2) to set same value for both atime and mtime.
I think you are right.
--
Emmanuel Dre
Emmanuel Dreyfus writes:
> Module Name: src
> Committed By: manu
> Date: Wed Aug 17 07:22:35 UTC 2011
>
> Modified Files:
> src/distrib/sets/lists/comp: mi
> src/lib/libc/sys: Makefile.inc utimes.2
> src/sys/kern: syscalls.master vfs_syscalls.c
>
> Log Message:
> Add fu
On Mon, Aug 22, 2011 at 03:13:29AM +0200, Joerg Sonnenberger wrote:
> On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote:
> > On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote:
> > > > Modified Files:
> > > > src/common/lib/libc/string: popcount32.c popcount6
On Sun, Aug 21, 2011 at 11:37:08PM +, David Holland wrote:
> On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote:
> > > Modified Files:
> > > src/common/lib/libc/string: popcount32.c popcount64.c
> > >
> > > Log Message:
> > > Requires stdint.h.
> >
> > No?
>
> uh what
On Mon, Aug 22, 2011 at 01:31:31AM +0200, Joerg Sonnenberger wrote:
> > Modified Files:
> >src/common/lib/libc/string: popcount32.c popcount64.c
> >
> > Log Message:
> > Requires stdint.h.
>
> No?
uh what?
--
David A. Holland
dholl...@netbsd.org
On Sun, Aug 21, 2011 at 09:25:04PM +, David A. Holland wrote:
> Module Name: src
> Committed By: dholland
> Date: Sun Aug 21 21:25:04 UTC 2011
>
> Modified Files:
> src/common/lib/libc/string: popcount32.c popcount64.c
>
> Log Message:
> Requires stdint.h.
>
>
> To generate a
On Sun, Aug 21, 2011 at 12:38:06PM +0200, Jean-Yves Migeon wrote:
> On 21.08.2011 12:26, Jean-Yves Migeon wrote:
> > - second, the lock is not placed at the correct abstraction level IMHO,
> > it is way too high in the caller/callee hierarchy. It should remain
> > hidden from most consumers of the
On 21.08.2011 21:39, Cherry G. Mathew wrote:
> JM> An alternative would be to have per-CPU xpq_queue[] also. This
> JM> is not completely stupid, xpq_queue is meant as a way to put
> JM> multiple MMU operations in a queue asynchronously before issuing
> JM> only one hypercall to han
> "JM" == Jean-Yves Migeon writes:
JM> On 21.08.2011 12:26, Jean-Yves Migeon wrote:
>> - second, the lock is not placed at the correct abstraction level
>> IMHO, it is way too high in the caller/callee hierarchy. It
>> should remain hidden from most consumers of the xpq_queue
NAKAJIMA Yoshihiro wrote:
> Because new function calls were added to libc.
> I think new APIs bring minor version bumping, under a NetBSD policy.
Um, what should be done in distribs/sets/lists?
Would s/libc.so.12.178/libc.so.12.179/ eveywhere be enough?
--
Emmanuel Dreyfus
http://hcpnet.free.f
On Sat, 20 Aug 2011 22:10:13 +0200,
m...@netbsd.org (Emmanuel Dreyfus) wrote:
> NAKAJIMA Yoshihiro wrote:
>
>> > Add futimens(2) and part of utimnsat(2)
>> Isn't shlib_version bumped?
>
> Perhaps, but I must confess I do not know the rules for that. What are
> they?
Because new function calls
On 21.08.2011 12:26, Jean-Yves Migeon wrote:
> - second, the lock is not placed at the correct abstraction level IMHO,
> it is way too high in the caller/callee hierarchy. It should remain
> hidden from most consumers of the xpq_queue API, and should only be used
> to protect the xpq_queue array to
On 10.08.2011 11:50, Cherry G. Mathew wrote:
> Module Name: src
> Committed By: cherry
> Date: Wed Aug 10 09:50:37 UTC 2011
>
> Modified Files:
> src/sys/arch/xen/include: xenpmap.h
> src/sys/arch/xen/x86: x86_xpmap.c
>
> Log Message:
> Introduce locking primitives for Xen pt
13 matches
Mail list logo
