Am 06.04.2025 um 03:24 schrieb Taylor R Campbell:
>> Date: Sat, 5 Apr 2025 19:18:20 +0200
>> From: Roland Illig
>>
>> Would it be narrow enough to add /*CONSTCOND*/ to the definition of
>> ALIGNED_POINTER on i386 and amd64? Or would you consider this still too
>> broad?
>
> Might be reasonable. B
> Date: Sat, 5 Apr 2025 19:18:20 +0200
> From: Roland Illig
>
> Would it be narrow enough to add /*CONSTCOND*/ to the definition of
> ALIGNED_POINTER on i386 and amd64? Or would you consider this still too
> broad?
Might be reasonable. But then we have a lot of predicates that might
be used in
Am 05.04.2025 um 02:07 schrieb Taylor R Campbell:
>> Module Name:src
>> Committed By: rillig
>> Date: Fri Apr 4 20:52:32 UTC 2025
>>
>> Modified Files:
>> src/sys/sys: cdefs.h
>>
>> Log Message:
>> sys/cdefs.h: fix __predict_true and __predict_false for lint
>>
>> -#define
> Module Name:src
> Committed By: rillig
> Date: Fri Apr 4 20:52:32 UTC 2025
>
> Modified Files:
> src/sys/sys: cdefs.h
>
> Log Message:
> sys/cdefs.h: fix __predict_true and __predict_false for lint
>
> -#define __predict_true(exp) __builtin_expect((exp) ? 1 :
Hi,
Christos Zoulas writes:
> And committed.
Thank you very much for your quick fix.
It works fine for me now.
> christos
>
>
--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
And committed.
christos
On 2024-09-11 11:18 am, Taylor R Campbell wrote:
Date: Thu, 12 Sep 2024 00:05:24 +0900
From: Ryo ONODERA
"Taylor R Campbell" writes:
> sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
>
> These are non-standard extensions, so they should not be exposed by,
> e.g., _XOPEN_SOURCE=70
> Date: Thu, 12 Sep 2024 00:05:24 +0900
> From: Ryo ONODERA
>
> "Taylor R Campbell" writes:
>
> > sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
> >
> > These are non-standard extensions, so they should not be exposed by,
> > e.g., _XOPEN_SOURCE=700.
> >
> > PR standards/57807: #i
Hi,
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Mon Sep 9 18:17:14 UTC 2024
>
> Modified Files:
> src/sys/sys: endian.h
>
> Log Message:
> sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
>
> These are non-standard extensions, so t
Hi,
Thanks for your fix.
It works fine for me.
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Sat May 25 13:44:48 UTC 2024
>
> Modified Files:
> src/sys/sys: ucontext.h
>
> Log Message:
> ucontext.h: Expose __UCONTEXT_SIZE to userland.
>
> But do
In article <2017973.usquhbg...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Jan 2 19:27:57 UTC 2024
>>
>> Modified Files:
>> src/sys/sys: rbt
Date:Tue, 2 Jan 2024 21:20:42 -0500
From:Jason Thorpe
Message-ID:
| seems safe
Safe probably, but also wrong. It looks to be there puerly
for the __BEGIN_DECLS / __END_DECLS definitions - which are
needed just beause has prototypes for lseek()
truncate() and f
> On Jan 2, 2024, at 8:41 PM, Robert Elz wrote:
>
> I doubt that should really be including
> and almost certainly not , and shouldn't have prototypes
> for any functions at all.
seems safe — all of that stuff is in the implementation namespace.
-- thorpej
Date:Wed, 3 Jan 2024 03:15:39 +0300
From:Valery Ushakov
Message-ID:
| for userland uses should include stddef.h where size_t is supposed
| to come from
Unfortunately, while is defined to specify size_t it
isn't specified to include ssize_t - and many things tha
On Wed, Jan 03, 2024 at 01:06:57 +0100, Joerg Sonnenberger wrote:
> Date: Wed, 03 Jan 2024 01:06:57 +0100
> From: Joerg Sonnenberger
> Subject: Re: CVS commit: src/sys/sys
> To: source-changes-d@netbsd.org
>
> On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrot
On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Jan 2 19:27:57 UTC 2024
>
> Modified Files:
> src/sys/sys: rbtree.h
>
> Log Message:
> This uses size_t, so it always needs , remove ifdefs.
sys/types.h is on
> On Jan 26, 2021, at 6:49 PM, Valery Ushakov wrote:
>
> It's hardly fair to characterize three people politely inquiring about
> that choice and pointing out a more standard way to spell what you
> want to express (that is perfectly in rhyme with the preceding table
> and is only one character
On Wed, Jan 27, 2021 at 01:00:05 +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Wed Jan 27 01:00:05 UTC 2021
>
> Modified Files:
> src/sys/sys: device.h
>
> Log Message:
> Define a macro to terminate the common usage of device_compatible_entry
> ar
On Wed, 29 Jan 2020, Andrew Doran wrote:
| Log Message:
| Put pri_t back to an int. It looks like there might be a sign extension
| issue somewhere but it's not worth the hassle trying to find it.
This changes the kernel internal ABI doesn't it? It would have needed
a kernel version bu
On Wed, Jan 29, 2020 at 12:58:52AM +0700, Robert Elz wrote:
> Date:Tue, 28 Jan 2020 16:40:27 +
> From:"Andrew Doran"
> Message-ID: <20200128164027.8558bf...@cvs.netbsd.org>
>
> | Log Message:
> | Put pri_t back to an int. It looks like there might be a sign
In article ,
Christos Zoulas wrote:
>In article <4251.1580234...@jinx.noi.kre.to>,
>Robert Elz wrote:
>>Date:Tue, 28 Jan 2020 16:40:27 +
>>From:"Andrew Doran"
>>Message-ID: <20200128164027.8558bf...@cvs.netbsd.org>
>>
>> | Log Message:
>> | Put pri_t back to a
In article <4251.1580234...@jinx.noi.kre.to>,
Robert Elz wrote:
>Date:Tue, 28 Jan 2020 16:40:27 +
>From:"Andrew Doran"
>Message-ID: <20200128164027.8558bf...@cvs.netbsd.org>
>
> | Log Message:
> | Put pri_t back to an int. It looks like there might be a sign e
Date:Tue, 28 Jan 2020 16:40:27 +
From:"Andrew Doran"
Message-ID: <20200128164027.8558bf...@cvs.netbsd.org>
| Log Message:
| Put pri_t back to an int. It looks like there might be a sign extension
| issue somewhere but it's not worth the hassle trying to fin
On Sun, Jan 12, 2020 at 01:30:57PM +, Nick Hudson wrote:
> On 12/01/2020 13:19, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sun Jan 12 13:19:32 UTC 2020
> >
> > Modified Files:
> > src/sys/sys: param.h
> >
> > Log Message:
> > Bump MI
On 12/01/2020 13:19, Andrew Doran wrote:
Module Name:src
Committed By: ad
Date: Sun Jan 12 13:19:32 UTC 2020
Modified Files:
src/sys/sys: param.h
Log Message:
Bump MIN_LWP_ALIGNMENT to 64.
Should aarch64/mips define MIN_LWP_ALIGNMENT as 128 as they have CPUs
that have
On Dec 23, 3:06pm, Warner Losh wrote:
} On Mon, Dec 23, 2019, 2:37 PM Kamil Rytarowski wrote:
} > On 23.12.2019 18:14, Greg Troxel wrote:
} > > Warner Losh writes:
} > >
} > >> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt
} > the
} > >> wumpus' for all the autoconfig s
On Mon, Dec 23, 2019, 2:37 PM Kamil Rytarowski wrote:
> On 23.12.2019 18:14, Greg Troxel wrote:
> > Warner Losh writes:
> >
> >> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt
> the
> >> wumpus' for all the autoconfig scripts that suddenly thought they were
> >> configur
Warner Losh writes:
> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt the
> wumpus' for all the autoconfig scripts that suddenly thought they were
> configuring for FreeBSD 1.0.
>
> If you can arrange it, it might make sense to do a pkgsrc run on an
> experimental system t
On 23.12.2019 18:14, Greg Troxel wrote:
> Warner Losh writes:
>
>> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt the
>> wumpus' for all the autoconfig scripts that suddenly thought they were
>> configuring for FreeBSD 1.0.
>>
>> If you can arrange it, it might make sense
On Mon, Dec 23, 2019 at 9:33 AM Greg Troxel wrote:
> Martin Husemann writes:
>
> > On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
> >> Well, we are coming up on a year since netbsd-9 was branched, or at
> >> least will arrive there before this discussion resolves. So cutting
> >>
On Dec 23, 11:33am, Greg Troxel wrote:
} Martin Husemann writes:
} > On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
} >> Well, we are coming up on a year since netbsd-9 was branched, or at
} >> least will arrive there before this discussion resolves. So cutting
} >> -10 before we h
Martin Husemann writes:
> On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
>> Well, we are coming up on a year since netbsd-9 was branched, or at
>> least will arrive there before this discussion resolves. So cutting
>> -10 before we hit 100 works for me :-)
>
> Nitpicking (and I do
On 23.12.2019 16:57, Martin Husemann wrote:
> On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
>> Well, we are coming up on a year since netbsd-9 was branched, or at
>> least will arrive there before this discussion resolves. So cutting
>> -10 before we hit 100 works for me :-)
>
> N
On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
> Well, we are coming up on a year since netbsd-9 was branched, or at
> least will arrive there before this discussion resolves. So cutting
> -10 before we hit 100 works for me :-)
Nitpicking (and I don't know for the discussion resolv
Kamil Rytarowski writes:
> On 23.12.2019 01:54, Roy Marples wrote:
>> On 22/12/2019 22:24, Andrew Doran wrote:
>>> NetBSD 9.99.29 - struct mount changed.
>>
>> Just curious - does our build software cope with 3 digit for the last
>> number?
>>
>> Roy
>
> At least from the __NetBSD_Version__ poi
On 23.12.2019 01:54, Roy Marples wrote:
> On 22/12/2019 22:24, Andrew Doran wrote:
>> NetBSD 9.99.29 - struct mount changed.
>
> Just curious - does our build software cope with 3 digit for the last
> number?
>
> Roy
At least from the __NetBSD_Version__ point of view there are 4 digits
unused, b
Roy Marples wrote:
> On 22/12/2019 22:24, Andrew Doran wrote:
> > NetBSD 9.99.29 - struct mount changed.
>
> Just curious - does our build software cope with 3 digit for the last number?
https://twitter.com/needydev/status/1205585787095519234?s=20
--
Alex
On 22/12/2019 22:24, Andrew Doran wrote:
NetBSD 9.99.29 - struct mount changed.
Just curious - does our build software cope with 3 digit for the last number?
Roy
On 22.12.2019 23:27, Andrew Doran wrote:
> On Sat, Dec 21, 2019 at 05:23:23PM +, Alexander Nasonov wrote:
>
>> Andrew Doran wrote:
>>> Log Message:
>>> NetBSD 9.99.28 - cpu_data & UVM changes.
>>
>> Wow, you bump versions faster than I compile new releases. At this
>> pace, we'll get to 9.99.9
On Sat, Dec 21, 2019 at 05:23:23PM +, Alexander Nasonov wrote:
> Andrew Doran wrote:
> > Log Message:
> > NetBSD 9.99.28 - cpu_data & UVM changes.
>
> Wow, you bump versions faster than I compile new releases. At this
> pace, we'll get to 9.99.99 in a month or two ;-)
There are quite a few p
Andrew Doran wrote:
> Log Message:
> NetBSD 9.99.28 - cpu_data & UVM changes.
Wow, you bump versions faster than I compile new releases. At this
pace, we'll get to 9.99.99 in a month or two ;-)
--
Alex
In article <20190911145625.450a3f...@cvs.netbsd.org>,
Christos Zoulas wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: christos
>Date: Wed Sep 11 14:56:25 UTC 2019
>
>Modified Files:
> src/sys/sys: atomic.h
>
>Log Message:
>Be consistent about semicolons in macros: always
On Sun, Aug 11, 2019 at 03:46:02PM +0200, Kamil Rytarowski wrote:
> Not usable in C++, we shipped with patches in 3rd party code.
Patches in 3rd party code means to me: the system header is usable
(but maybe awkward).
Martin
On 11.08.2019 09:17, Martin Husemann wrote:
> On Sat, Aug 10, 2019 at 11:37:28PM +0200, Kamil Rytarowski wrote:
>>> can we go back to the drawing board on this one and discuss the original
>>> problem?
>>>
>>
>> C++ and cast rules.
>
> The question is whether we really should play this game in our
In article <20190810203301.be06bf...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Sat Aug 10 20:33:01 UTC 2019
>
>Modified Files:
> src/sys/sys: event.h
>
>Log Message:
>Use common macro for _EV_SET() for integer types
>
>D
On Sun, Aug 11, 2019 at 09:17:05AM +0200, Martin Husemann wrote:
> On Sat, Aug 10, 2019 at 11:37:28PM +0200, Kamil Rytarowski wrote:
> > > can we go back to the drawing board on this one and discuss the original
> > > problem?
> > >
> >
> > C++ and cast rules.
>
> The question is whether we real
On Sat, Aug 10, 2019 at 11:37:28PM +0200, Kamil Rytarowski wrote:
> > can we go back to the drawing board on this one and discuss the original
> > problem?
> >
>
> C++ and cast rules.
The question is whether we really should play this game in our system headers.
The original state was usable in
On 10.08.2019 22:37, m...@netbsd.org wrote:
> On Sat, Aug 10, 2019 at 08:33:01PM +, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Aug 10 20:33:01 UTC 2019
>>
>> Modified Files:
>> src/sys/sys: event.h
>>
>> Log Message:
>> Use common
On Sat, Aug 10, 2019 at 08:33:01PM +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Sat Aug 10 20:33:01 UTC 2019
>
> Modified Files:
> src/sys/sys: event.h
>
> Log Message:
> Use common macro for _EV_SET() for integer types
>
> Deduplicate code.
>
>
In article <20190429231212.b1b55f...@cvs.netbsd.org>,
Valeriy E. Ushakov wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: uwe
>Date: Mon Apr 29 23:12:12 UTC 2019
>
>Modified Files:
> src/sys/sys: mman.h
>
>Log Message:
>Format MAP_FMT so that it's more humanly readable.
>Sa
On 07.11.2018 00:55, m...@netbsd.org wrote:
> On Tue, Nov 06, 2018 at 11:15:11PM +0300, Valery Ushakov wrote:
>> On Tue, Nov 06, 2018 at 16:26:44 +, Maya Rashish wrote:
>>
>>> Module Name:src
>>> Committed By: maya
>>> Date: Tue Nov 6 16:26:44 UTC 2018
>>>
>>> Modif
On Nov 6, 4:26pm, "Maya Rashish" wrote:
}
} Module Name: src
} Committed By: maya
} Date: Tue Nov 6 16:26:44 UTC 2018
}
} Modified Files:
} src/sys/sys: stdint.h types.h
}
} Log Message:
} Guard from type redefinition (needed by pre-C11 C) in a safer way.
Why was this comm
On Tue, Nov 06, 2018 at 11:15:11PM +0300, Valery Ushakov wrote:
> On Tue, Nov 06, 2018 at 16:26:44 +, Maya Rashish wrote:
>
> > Module Name:src
> > Committed By: maya
> > Date: Tue Nov 6 16:26:44 UTC 2018
> >
> > Modified Files:
> > src/sys/sys: stdint.h types
On Tue, Nov 06, 2018 at 16:26:44 +, Maya Rashish wrote:
> Module Name: src
> Committed By: maya
> Date: Tue Nov 6 16:26:44 UTC 2018
>
> Modified Files:
> src/sys/sys: stdint.h types.h
>
> Log Message:
> Guard from type redefinition (needed by pre-C11 C) in a safer way.
>
> T
Maxime Villard writes:
| Shouldn't we make kern_malloc take a size_t? In the end it calls kmem_alloc
| which does take a size_t.
Someone else's decision, I am not sure of all of the ramifications.
| The reason we should not use __nothing is because it leaves unused
| variables, and cause
In article ,
Maxime Villard wrote:
>
>The reason we should not use __nothing is because it leaves unused
>variables, and causes warnings.
Yes, and depending on the compiler and optimization level also leaves
code behind, or might have side effects. This is why everywhere else
we use empty macro
On Wed, Aug 22, 2018 at 02:24:09PM +0200, Maxime Villard wrote:
> Shouldn't we make kern_malloc take a size_t? In the end it calls kmem_alloc
> which does take a size_t.
Lots of builds are broken, can we back it out untill we know what to do?
Martin
Le 22/08/2018 à 14:14, Robert Elz a écrit :
Module Name:src
Committed By: kre
Date: Wed Aug 22 12:14:29 UTC 2018
Modified Files:
src/sys/sys: asan.h
Log Message:
Temporarily disable the dummy inline funcs, and replace them with
__nothing until maxv sorts out the type iss
On Sun, 8 Jul 2018, Christos Zoulas wrote:
On Jul 9, 5:56am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys/sys
| > Yes, the double evaluation is a show-stopper, please revert.
|
| A quick inspection shows that no additional code is generated, at least
| w
On Jul 9, 5:56am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys/sys
| > Yes, the double evaluation is a show-stopper, please revert.
|
| A quick inspection shows that no additional code is generated, at least
| when using gcc. For example:
Not if the value
On Sun, 8 Jul 2018, Christos Zoulas wrote:
Committed By: pgoyette
Date: Sun Jul 8 06:21:42 UTC 2018
Modified Files:
src/sys/sys: types.h
Log Message:
Use a different, type-insensitive idiom for CLR().
As discussed on IRC and proposed by dholland@, the existing idiom is
ty
In article <20180708092258.ga13...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Sun, Jul 08, 2018 at 06:21:42AM +, Paul Goyette wrote:
>> Module Name: src
>> Committed By:pgoyette
>> Date:Sun Jul 8 06:21:42 UTC 2018
>>
>> Modified Files:
>> src/sys/sys: typ
On Sun, Jul 08, 2018 at 06:21:42AM +, Paul Goyette wrote:
> Module Name: src
> Committed By: pgoyette
> Date: Sun Jul 8 06:21:42 UTC 2018
>
> Modified Files:
> src/sys/sys: types.h
>
> Log Message:
> Use a different, type-insensitive idiom for CLR().
>
> As discussed on IRC a
On Wed, Apr 18, 2018 at 07:51:01AM +0200, Kamil Rytarowski wrote:
>
> OK, so assuming that shall not be exposed to userland - I
> propose this patch:
>
> http://netbsd.org/~kamil/patch-00047-pmf_h.txt
It's all gross
Exposing sys/pmf.h to userland is probably necessary.
Greetings,
--
On 18.04.2018 07:30, Michael van Elst wrote:
> On Wed, Apr 18, 2018 at 07:09:34AM +0200, Kamil Rytarowski wrote:
>
>>> Anyway, I think sys/pmf.h is only included for the declaration of
>>> pmf_qual_t and that is only used for some function declarations that
>>> are for _KERNEL only. Can you please
On Wed, Apr 18, 2018 at 07:09:34AM +0200, Kamil Rytarowski wrote:
> > Anyway, I think sys/pmf.h is only included for the declaration of
> > pmf_qual_t and that is only used for some function declarations that
> > are for _KERNEL only. Can you please try:
Maybe this:
Index: sys/device.h
On 18.04.2018 06:56, Michael van Elst wrote:
> On Wed, Apr 18, 2018 at 01:36:23AM +0200, Kamil Rytarowski wrote:
>
>> Looking at other users, everyone except include
>> in the _KERNEL namespace.
>
> It defines internal kernel data structures. Normal programs must
> not see it, that's why it was
On Wed, Apr 18, 2018 at 01:36:23AM +0200, Kamil Rytarowski wrote:
> Looking at other users, everyone except include
> in the _KERNEL namespace.
It defines internal kernel data structures. Normal programs must
not see it, that's why it was hidden and finally all uses were removed
from userland,
On 18.04.2018 01:29, Kamil Rytarowski wrote:
> On 17.04.2018 23:50, Michael van Elst wrote:
>> On Tue, Apr 17, 2018 at 05:45:13PM +0200, Kamil Rytarowski wrote:
>>> On 04.03.2018 08:13, Michael van Elst wrote:
Module Name: src
Committed By: mlelstv
Date: Sun M
On 17.04.2018 23:50, Michael van Elst wrote:
> On Tue, Apr 17, 2018 at 05:45:13PM +0200, Kamil Rytarowski wrote:
>> On 04.03.2018 08:13, Michael van Elst wrote:
>>> Module Name:src
>>> Committed By: mlelstv
>>> Date: Sun Mar 4 07:13:11 UTC 2018
>>>
>>> Modified Files:
>
On Tue, Apr 17, 2018 at 05:45:13PM +0200, Kamil Rytarowski wrote:
> On 04.03.2018 08:13, Michael van Elst wrote:
> > Module Name:src
> > Committed By: mlelstv
> > Date: Sun Mar 4 07:13:11 UTC 2018
> >
> > Modified Files:
> > src/sys/sys: device.h
> >
> > Log Messa
On 04.03.2018 08:13, Michael van Elst wrote:
> Module Name: src
> Committed By: mlelstv
> Date: Sun Mar 4 07:13:11 UTC 2018
>
> Modified Files:
> src/sys/sys: device.h
>
> Log Message:
> Expose device structures to _KMEMUSER
>
>
This broke building device.h with _KMEMUSER.
> @
On Thu, Mar 08, 2018 at 10:25:45PM +, Christos Zoulas wrote:
> In article <20180308215453.gb22...@britannica.bec.de>,
> Joerg Sonnenberger wrote:
> >On Thu, Mar 08, 2018 at 03:32:33PM -0500, Christos Zoulas wrote:
> >> Module Name: src
> >> Committed By: christos
> >> Date:
In article <20180308215453.gb22...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Thu, Mar 08, 2018 at 03:32:33PM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Mar 8 20:32:33 UTC 2018
>>
>> Modified Files:
>> src/sys/sys:
On Thu, Mar 08, 2018 at 03:32:33PM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Thu Mar 8 20:32:33 UTC 2018
>
> Modified Files:
> src/sys/sys: bitops.h
>
> Log Message:
> PR/53081: Fix size of the shift to depend on the type of the bitmap so th
On 2017/10/23 18:35, SAITOH Masanobu wrote:
Welcome to 8.99.4
s/8.99.4/8.99.5/
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
On Mon, Jun 12, 2017 at 07:45:37AM -0700, Chuck Silvers wrote:
> On Mon, Jun 12, 2017 at 02:54:46PM +0200, Joerg Sonnenberger wrote:
> > On Thu, Jun 08, 2017 at 10:24:59PM +, Chuck Silvers wrote:
> > > Module Name: src
> > > Committed By: chs
> > > Date: Thu Jun 8 22:24:59
On Mon, Jun 12, 2017 at 02:54:46PM +0200, Joerg Sonnenberger wrote:
> On Thu, Jun 08, 2017 at 10:24:59PM +, Chuck Silvers wrote:
> > Module Name:src
> > Committed By: chs
> > Date: Thu Jun 8 22:24:59 UTC 2017
> >
> > Modified Files:
> > src/sys/sys: disk.h
> >
On Thu, Jun 08, 2017 at 10:24:59PM +, Chuck Silvers wrote:
> Module Name: src
> Committed By: chs
> Date: Thu Jun 8 22:24:59 UTC 2017
>
> Modified Files:
> src/sys/sys: disk.h
>
> Log Message:
> do not expose kernel-internal structure definitions to userland.
> needed for ZFS.
On Tue, Jan 17, 2017 at 08:11:08PM +, Christos Zoulas wrote:
> Anyway, what they did is a gross hack with unintended consequences. If
> we want to encourage bugs and abuse in the system headers, we should
> turn it back off.
More warnings is always good as long as the s/n rate is not absurd.
I
In article <20170117155009.ga13...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tue, Jan 17, 2017 at 01:13:07PM +, Maya Rashish wrote:
>> Module Name: src
>> Committed By:maya
>> Date:Tue Jan 17 13:13:07 UTC 2017
>>
>> Modified Files:
>> src/sys/sys: time.h
On Tue, Jan 17, 2017 at 01:13:07PM +, Maya Rashish wrote:
> Module Name: src
> Committed By: maya
> Date: Tue Jan 17 13:13:07 UTC 2017
>
> Modified Files:
> src/sys/sys: time.h
>
> Log Message:
> define constants as being wider than int when needed, instead of casting
> them at
On Fri, 6 Jan 2017, matthew green wrote:
Paul Goyette writes:
Yeah, I managed to type -m instead of -f
Should already be fixed (via cvs admin) in the repo.
can you update the mailing list with the fixed text please?
that's the normal method as well.
Sorry, here's the revised commit message
Paul Goyette writes:
> Yeah, I managed to type -m instead of -f
>
> Should already be fixed (via cvs admin) in the repo.
can you update the mailing list with the fixed text please?
that's the normal method as well.
thanks.
.mrg.
> On Fri, 6 Jan 2017, matthew green wrote:
>
> > "Paul Goyette"
Yeah, I managed to type -m instead of -f
Should already be fixed (via cvs admin) in the repo.
On Fri, 6 Jan 2017, matthew green wrote:
"Paul Goyette" writes:
Module Name:src
Committed By: pgoyette
Date: Thu Jan 5 22:51:15 UTC 2017
Modified Files:
src/sys/sys: time.h
"Paul Goyette" writes:
> Module Name: src
> Committed By: pgoyette
> Date: Thu Jan 5 22:51:15 UTC 2017
>
> Modified Files:
> src/sys/sys: time.h
>
> Log Message:
> /home/paul/time.msg
interesting!
In article <20170105232440.032b1f...@cvs.netbsd.org>,
Paul Goyette wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: pgoyette
>Date: Thu Jan 5 23:24:39 UTC 2017
>
>Modified Files:
> src/sys/sys: time.h
>
>Log Message:
>Define macros for the time conversion magic numbers.
S
On Thu, 5 Jan 2017, Christos Zoulas wrote:
In article <20170105225115.78e7df...@cvs.netbsd.org>,
Paul Goyette wrote:
-=-=-=-=-=-
Module Name:src
Committed By: pgoyette
Date: Thu Jan 5 22:51:15 UTC 2017
Modified Files:
src/sys/sys: time.h
Log Message:
/home/paul/time
In article <20170105225115.78e7df...@cvs.netbsd.org>,
Paul Goyette wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: pgoyette
>Date: Thu Jan 5 22:51:15 UTC 2017
>
>Modified Files:
> src/sys/sys: time.h
>
>Log Message:
>/home/paul/time.msg
>
Perhaps #define some BINTIME_SCA
On Mon, Dec 12, 2016 at 10:07:12PM +, co...@sdf.org wrote:
>
> This unfortunately presents a problem with pulling up
> the fix to -7.
on icb someone mentioned 7.1 is a different version anyway.
so it shouldn't be an issue here, yay.
On Mon, Dec 12, 2016 at 09:56:00PM +, Maya Rashish wrote:
> Bump for drm2 da_fb_linebytes
>
This unfortunately presents a problem with pulling up
the fix to -7.
it's not normally a module. thoughts?
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Thu Nov 10 18:35:17 UTC 2016
>
> Modified Files:
> src/sys/sys: wait.h
>
> Log Message:
> - Move WUNTRACED outside the _NETBSD_SOURCE ifdef because waitpid()
> needs it (kre)
> - Reformat the comments
(from a while back)
On Sun, Jan 24, 2016 at 02:11:56PM +0100, Joerg Sonnenberger wrote:
> On Fri, Jan 22, 2016 at 11:31:30PM +, David A. Holland wrote:
> > Module Name: src
> > Committed By: dholland
> > Date: Fri Jan 22 23:31:30 UTC 2016
> >
> > Modified Files:
On Mon, Mar 21, 2016 at 09:21:20AM +0100, Martin Husemann wrote:
> On Mon, Mar 21, 2016 at 01:36:22AM +0100, Joerg Sonnenberger wrote:
> > In short, this is a real problem and the assumption is not specific to
> > clang. Revert now, please.
>
> Is there any other hack around the issue? Marking the
On Mon, Mar 21, 2016 at 02:34:25PM +, David Holland wrote:
> On Mon, Mar 21, 2016 at 01:36:22AM +0100, Joerg Sonnenberger wrote:
> > Here is a trivial test case showing that the basic problem exists for
> > both clang and gcc:
> >
> >int a, b
> >
> >int f(void) {
> > retur
On Mon, Mar 21, 2016 at 01:36:22AM +0100, Joerg Sonnenberger wrote:
> Here is a trivial test case showing that the basic problem exists for
> both clang and gcc:
>
>int a, b
>
>int f(void) {
> return &a != &b;
>}
Do you perhaps mean "extern int a, b;"? That's an importan
On Mon, Mar 21, 2016 at 01:36:22AM +0100, Joerg Sonnenberger wrote:
> In short, this is a real problem and the assumption is not specific to
> clang. Revert now, please.
Is there any other hack around the issue? Marking the symbol weak is a
very strange way to stop the compiler making this assumpt
On Sun, Mar 20, 2016 at 04:13:25PM +, Nick Hudson wrote:
> On 03/20/16 14:41, Joerg Sonnenberger wrote:
> >On Fri, Mar 18, 2016 at 04:29:15PM +, Nick Hudson wrote:
>
> >>Is there a PR that describes the clang problem?
> >I gave you a detailed explination why the old version is a problem. S
On 03/20/16 14:41, Joerg Sonnenberger wrote:
On Fri, Mar 18, 2016 at 04:29:15PM +, Nick Hudson wrote:
Is there a PR that describes the clang problem?
I gave you a detailed explination why the old version is a problem. So
far I have seen no real justification for the change, other than som
On Fri, Mar 18, 2016 at 04:29:15PM +, Nick Hudson wrote:
> On 03/18/16 16:19, Joerg Sonnenberger wrote:
> >On Fri, Mar 18, 2016 at 10:52:27AM +, Christos Zoulas wrote:
> >>In article <20160318030154.gb12...@britannica.bec.de>,
> >>Joerg Sonnenberger wrote:
> >>>On Thu, Mar 10, 2016 at 07:
1 - 100 of 194 matches
Mail list logo
