On Thu, 27 Feb 2014, Joerg Sonnenberger wrote:
Modified Files:
src/sys/dev/pci: if_ti.c
Log Message:
Remove impossible checks.
If new bugs are introduced in the future, then these tests might
no longer be impossible. So I'd prefer to change them to KASSERT
or KDASSERT rather than de
On Wed, 26 Feb 2014, Matt Thomas wrote:
Modified Files:
src/sys/uvm: uvm_meter.c uvm_param.h
Log Message:
Add vm.min_address and vm.max_address which return VM_MIN_ADDRESS and
VM_MAXUSER_ADDRESS.
Do these need to use the old style #define constants
instead of the new style (since 2005)
On Feb 27, 2014, at 4:56 PM, Joerg Sonnenberger wrote:
> Module Name: src
> Committed By: joerg
> Date: Thu Feb 27 15:56:12 UTC 2014
>
> Modified Files:
> src/distrib/sets/lists/comp: md.sparc64
>
> Log Message:
> Use gcc,compat, directory creation only depends on the MKCOMPAT sw
On Feb 27, 2014, at 12:43 PM, matthew green wrote:
> remove the GCC 4 EXTERNAL_GCC_SUBDIR, and switch GCC 4.8 to use gcc.old.
huh?
> putting any marker (like gcc, or compat) on these subdirs means
> that they'll always be removed on some build types, ie, that
> means that the obsolete phase will *always* do something for a
> fresh build.
actually, they should be marked just "compat" as they're only
created for compat builds.
On Fri, Feb 28, 2014 at 06:34:10AM +1100, matthew green wrote:
> putting any marker (like gcc, or compat) on these subdirs means
> that they'll always be removed on some build types, ie, that
> means that the obsolete phase will *always* do something for a
> fresh build.
But they are only created
Martin Husemann writes:
> On Thu, Feb 27, 2014 at 10:07:36AM +0100, J. Hannken-Illjes wrote:
> > ./usr/include/g++/bits/sparc
> > ./usr/include/g++/bits/sparc64
>
> I asked Jörg to try (his MKCOMPAT=no clang build) with
>
> ./usr/include/g++/bits/sparc gcc,compat
> ./usr/include/g++/bit
On Feb 27, 2014, at 7:01 PM, Mindaugas Rasiukevicius wrote:
> "J. Hannken-Illjes" wrote:
>>> I have not had time to follow your VFS changes, but can you explain why
>>> did you remove VOP_LOCK/VOP_UNLOCK in tmpfs_reclaim()? It was added to
>>> prevent from the racy access of tn_links.
>>
>> H
"J. Hannken-Illjes" wrote:
> > I have not had time to follow your VFS changes, but can you explain why
> > did you remove VOP_LOCK/VOP_UNLOCK in tmpfs_reclaim()? It was added to
> > prevent from the racy access of tn_links.
>
> Hopefully a vnode lock is needed to access tn_links -- otherwise the
On Feb 27, 2014, at 6:06 PM, Mindaugas Rasiukevicius wrote:
> "Juergen Hannken-Illjes" wrote:
>> Module Name: src
>> Committed By:hannken
>> Date:Thu Feb 27 16:51:39 UTC 2014
>>
>> <...>
>>
>> Log Message:
>> The current implementation of vn_lock() is racy. Modificatio
"Juergen Hannken-Illjes" wrote:
> Module Name: src
> Committed By: hannken
> Date: Thu Feb 27 16:51:39 UTC 2014
>
> <...>
>
> Log Message:
> The current implementation of vn_lock() is racy. Modification of
> the vnode operations vector for active vnodes is unsafe because it
> is not kn
On Thu, Feb 27, 2014 at 10:07:36AM +0100, J. Hannken-Illjes wrote:
> ./usr/include/g++/bits/sparc
> ./usr/include/g++/bits/sparc64
I asked Jörg to try (his MKCOMPAT=no clang build) with
./usr/include/g++/bits/sparcgcc,compat
./usr/include/g++/bits/sparc64 gcc
(the old state was
On Feb 24, 2014, at 10:14 PM, Joerg Sonnenberger wrote:
> Module Name: src
> Committed By: joerg
> Date: Mon Feb 24 21:14:13 UTC 2014
>
> Modified Files:
> src/distrib/sets/lists/comp: md.sparc64
>
> Log Message:
> Fix compat entries.
>
>
> To generate a diff of this commit:
>
13 matches
Mail list logo
