Re: CVS commit: src/sys/sys

[Ryo ONODERA]

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 don't expose __CTASSERT(__UCONTEXT_SIZE == sizeof(ucontext_t)) to
> userland.
>
> - __UCONTEXT_SIZE will be needed soon by libc and signal trampolines
>   in order to version ucontext so we can safely expand it with
>   architecture extensions.
>
> - __CTASSERT is not safe to use in header files in arbitrary
>   compilation environments (although in the NetBSD kernel build it is
>   safe).  Exposing the __CTASSERT in a header file used by userland
>   appears to have the side effect of breaking the Firefox build in
>   rustc, though the mechanism isn't entirely clear.
>
> Firefox/rustc discussion here:
> https://mail-index.netbsd.org/pkgsrc-users/2024/05/18/msg039578.html
>
> Let's see if this makes a difference -- if it works, great; if not,
> maybe it will help us to narrow down what's happening with rustc and
> Firefox.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.23 -r1.24 src/sys/sys/ucontext.h
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
> Modified files:
>
> Index: src/sys/sys/ucontext.h
> diff -u src/sys/sys/ucontext.h:1.23 src/sys/sys/ucontext.h:1.24
> --- src/sys/sys/ucontext.h:1.23   Fri May 24 13:50:30 2024
> +++ src/sys/sys/ucontext.hSat May 25 13:44:48 2024
> @@ -1,4 +1,4 @@
> -/*   $NetBSD: ucontext.h,v 1.23 2024/05/24 13:50:30 ryoon Exp $  */
> +/*   $NetBSD: ucontext.h,v 1.24 2024/05/25 13:44:48 riastradh Exp $  */
>  
>  /*-
>   * Copyright (c) 1999, 2003, 2024 The NetBSD Foundation, Inc.
> @@ -82,6 +82,10 @@ struct __ucontext {
>  #define _UC_UCONTEXT_ALIGN (~0)
>  #endif
>  
> +#ifndef __UCONTEXT_SIZE
> +#define  __UCONTEXT_SIZE sizeof(ucontext_t)
> +#endif
> +
>  #ifndef _UC_TLSBASE
>  #error   _UC_TLSBASE not defined.
>  #endif
> @@ -105,8 +109,6 @@ int   cpu_mcontext_validate(struct lwp *, 
>  
>  #ifdef __UCONTEXT_SIZE
>  __CTASSERT(sizeof(ucontext_t) == __UCONTEXT_SIZE);
> -#else
> -#define  __UCONTEXT_SIZE sizeof(ucontext_t)
>  #endif
>  #endif /* _KERNEL */
>  
>

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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: rbtree.h
>> 
>> Log Message:
>> This uses size_t, so it always needs , remove ifdefs.
>
>sys/types.h is one of the most polluting headers we have. This is a huge
>step backwards...

You realize of course that it was working before because it was getting
sys/types.h from sys/endian.h which had an include cycle before which I was
trying to fix. Now sys/endian.h does not include sys/types.h which is a step
forward. Yes, our headers are messy but we are trying to clean them.


Happy New Year,

christos

Re: CVS commit: src/sys/sys

[Robert Elz]

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 ftruncate() which make no sense in 
at all (beyond ancient history).

kre

Re: CVS commit: src/sys/sys

[Jason Thorpe]

> 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

Re: CVS commit: src/sys/sys

[Robert Elz]

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 that need
size_t also need ssize_t (which includes src/usr.bin/tprof one of
the users of )

All of this is horribly ugly - perhaps we'd do better to remove
stuff from  that shouldn't be there (which is probably
any definition which doesn't end in _t except probably the old u_char
u_short ... and their uchar/ushort/... variants).   In particular
I doubt that  should really be including 
and almost certainly not , and shouldn't have prototypes
for any functions at all.

kre

Re: CVS commit: src/sys/sys

[Valery Ushakov]

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 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 one of the most polluting headers we have. This is a huge
> step backwards...

Yes, I think we should keep the ifdef and for userland uses should
include stddef.h where size_t is supposed to come from (is inttypes.h
really needed there, or is it it just b/c it happens to include most
of the same stuff that stddef.h does and hence define size_t?)

-uwe

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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 one of the most polluting headers we have. This is a huge
step backwards...

Joerg

Re: CVS commit: src/sys/sys

[Jason Thorpe]

> 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 longer too) as "angry hordes objecting".

Sorry, should have added the "/s" at the end.  Was kind of a long day, and this 
was a misguided attempt at decompression humor.

-- thorpej

Re: CVS commit: src/sys/sys

[Valery Ushakov]

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
> arrays, in order to placate the angry hordes objecting to use of a GCC
> extension.

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 longer too) as "angry hordes objecting".

The point is moot anyway, since anonymous unions themselves only
officially appeared in C11.

-uwe

Re: CVS commit: src/sys/sys

[Paul Goyette]

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 bump when the reverted change was made, and now needs
one it has been removed, doesn't it?


Yes it does.  I made one later yesterday.  My changes today need another but
Jason already bumped the version earlier in the day, and I think one a day
is enough!


Yeah - ride the bump!



++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

Re: CVS commit: src/sys/sys

[Andrew Doran]

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 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 bump when the reverted change was made, and now needs
> one it has been removed, doesn't it?

Yes it does.  I made one later yesterday.  My changes today need another but
Jason already bumped the version earlier in the day, and I think one a day
is enough!

Andrew

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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 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 bump when the reverted change was made, and now needs
>>one it has been removed, doesn't it?
>
>Yes, but let's try to fix it and put it back the way it was before. It can't
>be used in too many places...

So I just took a quick look and it is non-trivial to change this
to something smaller than int, because it is used as an int in many
places, eg.   int sched_priority; (do_sched_setparam
needs fixing, sys__sched_protect needs fixing), even small issues
like:

--- kern_sleepq.c   21 Nov 2019 18:56:55 -  1.52
+++ kern_sleepq.c   28 Jan 2020 21:38:06 -
@@ -171,7 +171,7 @@
 
if ((sobj->sobj_flag & SOBJ_SLEEPQ_SORTED) != 0) {
lwp_t *l2;
-   const int pri = lwp_eprio(l);
+   const pri_t pri = lwp_eprio(l);
 
TAILQ_FOREACH(l2, sq, l_sleepchain) {
if (lwp_eprio(l2) < pri) {

christos

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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 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 bump when the reverted change was made, and now needs
>one it has been removed, doesn't it?

Yes, but let's try to fix it and put it back the way it was before. It can't
be used in too many places...

christos

Re: CVS commit: src/sys/sys

[Robert Elz]

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 find it.

This changes the kernel internal ABI doesn't it?   It would have needed
a kernel version bump when the reverted change was made, and now needs
one it has been removed, doesn't it?

kre

Re: CVS commit: src/sys/sys

[Andrew Doran]

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 MIN_LWP_ALIGNMENT to 64.
> 
> Should aarch64/mips define MIN_LWP_ALIGNMENT as 128 as they have CPUs
> that have this cache line size?

Good point - fixed!

Cheers,
Andrew

Re: CVS commit: src/sys/sys

[Nick Hudson]

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 this cache line size?

Thanks,
Nick

Re: CVS commit: src/sys/sys

[John Nemeth]

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 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 that has the version as 10.0 rather than 9.9.xx
} > before
} > >> committing to a schedule given the experience of your sister BSD
} > project.
} > >
} > > Thanks, that's a really good point.
} >
} > This issue is well known. Once we will branch -10 we will test it in
} > HEAD and -10 concurrently.
} >
} > On the other hand, clang10 broke only a single piece of software that I
} > build (nodejs).
} 
} FreeBSD 10 broke dozens of config scripts that all derived from a common
} ancestor back in the 90s... though 1.0 FreeBSD needed special treatment for
} things like a.out and such and the scripts used 1* to match. It would be

I was going to say that we could just skip 10 and go direct to
11, but 1* would catch 11 as well.  So much for the shortcut.

} easy enough to grep for that pattern in gnu software to see if it will trip
} you up. NetBSDs release version history may be such this isn't an issue,
} but it broke a heck of a lot than I'd expected at the time...
} 
}-- End of excerpt from Warner Losh

Re: CVS commit: src/sys/sys

[Warner Losh]

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
> >> configuring for FreeBSD 1.0.
> >>
> >> If you can arrange it, it might make sense to do a pkgsrc run on an
> >> experimental system that has the version as 10.0 rather than 9.9.xx
> before
> >> committing to a schedule given the experience of your sister BSD
> project.
> >
> > Thanks, that's a really good point.
> >
>
> This issue is well known. Once we will branch -10 we will test it in
> HEAD and -10 concurrently.
>
> On the other hand, clang10 broke only a single piece of software that I
> build (nodejs).
>


FreeBSD 10 broke dozens of config scripts that all derived from a common
ancestor back in the 90s... though 1.0 FreeBSD needed special treatment for
things like a.out and such and the scripts used 1* to match. It would be
easy enough to grep for that pattern in gnu software to see if it will trip
you up. NetBSDs release version history may be such this isn't an issue,
but it broke a heck of a lot than I'd expected at the time...

Warner

>

Re: CVS commit: src/sys/sys

[Greg Troxel]

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 that has the version as 10.0 rather than 9.9.xx before
> committing to a schedule given the experience of your sister BSD project.

Thanks, that's a really good point.

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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 to do a pkgsrc run on an
>> experimental system that has the version as 10.0 rather than 9.9.xx before
>> committing to a schedule given the experience of your sister BSD project.
> 
> Thanks, that's a really good point.
> 

This issue is well known. Once we will branch -10 we will test it in
HEAD and -10 concurrently.

On the other hand, clang10 broke only a single piece of software that I
build (nodejs).



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[Warner Losh]

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
> >> -10 before we hit 100 works for me :-)
> >
> > Nitpicking (and I don't know for the discussion resolving), but netbsd-9
> > was branched on 2019-07-30 (so not even 1/2 a year yes).
> >
> > The branch for netbsd-10 can happen soon after Andrew is done (we need
> > 10.0 on the build cluster ASAP).
>
> I will admit that my comment was partly humor.
>
> Thanks for pointing out the -9 branch date.  Given that we have had an
> RC, this branch is going much better than recent previous ones.  I
> realize it's always difficult, but I think we (mostly you, perhaps) are
> doing better this time.
>
> I did mean to be somewhat serious in saying it was going to be time to
> start 10, just based on calendar, because I believe releases should be
> no more than 18 months apart, and I think 12 months is ideal.  Thus I am
> in favor of starting a new branch 12 months after the last one was
> started.
>
> (I see the merits of points about lots of improvements in current vs 9
> and the reasonableness of branching late spring and releasing fall, even
> if that seems a bit aspirational.)
>

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 that has the version as 10.0 rather than 9.9.xx before
committing to a schedule given the experience of your sister BSD project.

Warner

Re: CVS commit: src/sys/sys

[John Nemeth]

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 hit 100 works for me :-)
} >
} > Nitpicking (and I don't know for the discussion resolving), but netbsd-9
} > was branched on 2019-07-30 (so not even 1/2 a year yes).
} >
} > The branch for netbsd-10 can happen soon after Andrew is done (we need
} > 10.0 on the build cluster ASAP).
} 
} I will admit that my comment was partly humor.
} 
} Thanks for pointing out the -9 branch date.  Given that we have had an
} RC, this branch is going much better than recent previous ones.  I
} realize it's always difficult, but I think we (mostly you, perhaps) are
} doing better this time.
} 
} I did mean to be somewhat serious in saying it was going to be time to
} start 10, just based on calendar, because I believe releases should be
} no more than 18 months apart, and I think 12 months is ideal.  Thus I am
} in favor of starting a new branch 12 months after the last one was
} started.

I would like to see releases being 18 to 24 months.  Releases
that come too close together are nasty for people that are running
production systems.  Having releases too close together leads to
the idea of LTS (Long Term Support) versions, which have their own
problems that very few people want.  What would be really nice is
to tighten up the release cycle.  I realise that they have been
long for a variety of reasons, but it is something that needs to
be worked on.

} (I see the merits of points about lots of improvements in current vs 9
} and the reasonableness of branching late spring and releasing fall, even
} if that seems a bit aspirational.)
} 
}-- End of excerpt from Greg Troxel

Re: CVS commit: src/sys/sys

[Greg Troxel]

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 don't know for the discussion resolving), but netbsd-9
> was branched on 2019-07-30 (so not even 1/2 a year yes).
>
> The branch for netbsd-10 can happen soon after Andrew is done (we need
> 10.0 on the build cluster ASAP).

I will admit that my comment was partly humor.

Thanks for pointing out the -9 branch date.  Given that we have had an
RC, this branch is going much better than recent previous ones.  I
realize it's always difficult, but I think we (mostly you, perhaps) are
doing better this time.

I did mean to be somewhat serious in saying it was going to be time to
start 10, just based on calendar, because I believe releases should be
no more than 18 months apart, and I think 12 months is ideal.  Thus I am
in favor of starting a new branch 12 months after the last one was
started.

(I see the merits of points about lots of improvements in current vs 9
and the reasonableness of branching late spring and releasing fall, even
if that seems a bit aspirational.)

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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 :-)
> 
> Nitpicking (and I don't know for the discussion resolving), but netbsd-9
> was branched on 2019-07-30 (so not even 1/2 a year yes).
> 
> The branch for netbsd-10 can happen soon after Andrew is done (we need
> 10.0 on the build cluster ASAP).
> 
> Martin
> 

This plan works well for LLVM-related projects. The reasons are bit
different, but quick -10 followed by quick release (like in the middle
of 2020) will cut our costs.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[Martin Husemann]

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 resolving), but netbsd-9
was branched on 2019-07-30 (so not even 1/2 a year yes).

The branch for netbsd-10 can happen soon after Andrew is done (we need
10.0 on the build cluster ASAP).

Martin

Re: CVS commit: src/sys/sys

[Greg Troxel]

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__ point of view there are 4 digits
> unused, but it is more valuable to branch -10 earlier than going to
> 3-digit patchlevel.

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 :-)

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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, but it is more valuable to branch -10 earlier than going to
3-digit patchlevel.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[Alexander Nasonov]

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

Re: CVS commit: src/sys/sys

[Roy Marples]

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

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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.99 in a month or two ;-)
> 
> There are quite a few people using modules and I don't want to screw them
> over.  We got into the MP game properly with NetBSD 5.0 but we're lagging
> badly and as someone else observed we've been in need of many of these
> changes for 10 years now.
> 
> Andrew
> 

Great work!

Personally, I am looking forward to NUMA support, it is today in ARM
embedded/servers and we are pretty marginalized. In larger x86 it is a
standard for a long time now.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[Andrew Doran]

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 people using modules and I don't want to screw them
over.  We got into the MP game properly with NetBSD 5.0 but we're lagging
badly and as someone else observed we've been in need of many of these
changes for 10 years now.

Andrew

Re: CVS commit: src/sys/sys

[Alexander Nasonov]

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

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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 put them in the macro
>definitions and in the macro invocations so that the invocations look
>like statements, and we don't and up with extra semis. Fixes lint build.

that should read:

Always put them in the macro invocations and *not* in the macro definitions.

christos

Re: CVS commit: src/sys/sys

[Martin Husemann]

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

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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 system headers.
> The original state was usable in C++ (but awkward), or do I misunderstand
> someting?
> 

Not usable in C++, we shipped with patches in 3rd party code.

Christos added casts for C to handle differences, but they do not work
in C++ and its picky cast rules.

> Martin
> 




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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
>
>Deduplicate code.
>
>No functional change change intended.
>
>
>To generate a diff of this commit:
>cvs rdiff -u -r1.35 -r1.36 src/sys/sys/event.h
>
>Please note that diffs are not public domain; they are subject to the
>copyright notices on the relevant files.
>
>
>-=-=-=-=-=-
>
>Modified files:
>
>Index: src/sys/sys/event.h
>diff -u src/sys/sys/event.h:1.35 src/sys/sys/event.h:1.36
>--- src/sys/sys/event.h:1.35   Sat Aug 10 15:02:03 2019
>+++ src/sys/sys/event.hSat Aug 10 20:33:01 2019
>@@ -1,4 +1,4 @@
>-/*$NetBSD: event.h,v 1.35 2019/08/10 15:02:03 kamil Exp $ */
>+/*$NetBSD: event.h,v 1.36 2019/08/10 20:33:01 kamil Exp $ */
> 
> /*-
>  * Copyright (c) 1999,2000,2001 Jonathan Lemon
>
>@@ -75,54 +75,21 @@ _EV_SET(struct kevent *_kevp, uintptr_t 
>   _kevp->udata = reinterpret_cast(_udata);
> }
> 
>-static __inline void
>-_EV_SET(struct kevent *_kevp, uintptr_t _ident, uint32_t _filter,
>-uint32_t _flags, uint32_t _fflags, int64_t _data, int _udata)
>-{
>-  _EV_SET(_kevp, _ident, _filter, _flags, _fflags, _data,
>-  reinterpret_cast(static_cast(_udata)));
>-}
>-
>-static __inline void
>-_EV_SET(struct kevent *_kevp, uintptr_t _ident, uint32_t _filter,
>-uint32_t _flags, uint32_t _fflags, int64_t _data, long int _udata)
>-{
>-  _EV_SET(_kevp, _ident, _filter, _flags, _fflags, _data,
>-  reinterpret_cast(static_cast(_udata)));
>+#define _EV_SET_INTEGER_TYPE(_UTYPE)  \
>+static __inline void  \
>+_EV_SET(struct kevent *_kevp, uintptr_t _ident, uint32_t _filter, \
>+uint32_t _flags, uint32_t _fflags, int64_t _data, _UTYPE _udata)  \
>+{ \
>+  _EV_SET(_kevp, _ident, _filter, _flags, _fflags, _data, \
>+  reinterpret_cast(static_cast(_udata)));   \
> }
> 
>-static __inline void
>-_EV_SET(struct kevent *_kevp, uintptr_t _ident, uint32_t _filter,
>-uint32_t _flags, uint32_t _fflags, int64_t _data, long long int _udata)
>-{
>-  _EV_SET(_kevp, _ident, _filter, _flags, _fflags, _data,
>-  reinterpret_cast(static_cast(_udata)));
>-}
>-
>-static __inline void
>-_EV_SET(struct kevent *_kevp, uintptr_t _ident, uint32_t _filter,
>-uint32_t _flags, uint32_t _fflags, int64_t _data, unsigned int _udata)
>-{
>-  _EV_SET(_kevp, _ident, _filter, _flags, _fflags, _data,
>-  reinterpret_cast(static_cast(_udata)));
>-}
>-
>-static __inline void
>-_EV_SET(struct kevent *_kevp, uintptr_t _ident, uint32_t _filter,
>-uint32_t _flags, uint32_t _fflags, int64_t _data, unsigned long int 
>_udata)
>-{
>-  _EV_SET(_kevp, _ident, _filter, _flags, _fflags, _data,
>-  reinterpret_cast(static_cast(_udata)));
>-}
>-
>-static __inline void
>-_EV_SET(struct kevent *_kevp, uintptr_t _ident, uint32_t _filter,
>-uint32_t _flags, uint32_t _fflags, int64_t _data,
>-unsigned long long int _udata)
>-{
>-  _EV_SET(_kevp, _ident, _filter, _flags, _fflags, _data,
>-  reinterpret_cast(static_cast(_udata)));
>-}
>+_EV_SET_INTEGER_TYPE(int)
>+_EV_SET_INTEGER_TYPE(long int)
>+_EV_SET_INTEGER_TYPE(long long int)
>+_EV_SET_INTEGER_TYPE(unsigned int)
>+_EV_SET_INTEGER_TYPE(unsigned long int)
>+_EV_SET_INTEGER_TYPE(unsigned long long int)
> 
> #pragma GCC diagnistic pop
> #else
>

"diagnistic"?

christos

Re: CVS commit: src/sys/sys

[maya]

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 really should play this game in our system headers.
> The original state was usable in C++ (but awkward), or do I misunderstand
> someting?
> 
> Martin

The key point seems to be:

NetBSD:

struct kevent {
...
intptr_tudata;  /* opaque user data identifier */

Everyone else (apparently)**:

struct kevent {
...
void*udata; /* opaque user data identifier */


>
doing __CAST(intptr_t, (udata)) with a static inline*

For C++, that's static_cast(udata).
This errors with nullptr as an argument.

>
Let C++ polymorphism handle it. provide a void* and a
uintptr_t case.

>
Discover the following are all valid types for
arguments for udata:

0, NULL, nullptr, 0L, 0LL, 0U, 0UL, 0ULL,
intptr_t, uintptr_t

Create an EV_SET version for all of them,
letting C++ sort out which it is.



* It's at this point I should mention that a C-style cast seems to make
C++ stop erroring in all these cases. Accidentally tested this first.
They are discouraged though for (I don't C++ a lot, so someone fill this
in).

** FreeBSD just changed their struct kevent in freebsd 12, adding an
argument.

Re: CVS commit: src/sys/sys

[Martin Husemann]

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 C++ (but awkward), or do I misunderstand
someting?

Martin

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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 macro for _EV_SET() for integer types
>>
>> Deduplicate code.
>>
>> No functional change change intended.
> 
> this looks much worse.


I actually like it now more.

> can we go back to the drawing board on this one and discuss the original
> problem?
> 

C++ and cast rules.

> thanks.
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[maya]

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.
> 
> No functional change change intended.

this looks much worse.
can we go back to the drawing board on this one and discuss the original
problem?

thanks.

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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.
>Same object code is generated for kdump.

Much nicer!

christos

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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
>>>
>>> Modified Files:
>>> src/sys/sys: stdint.h types.h
>>>
>>> Log Message:
>>> Guard from type redefinition (needed by pre-C11 C) in a safer way.
>>>
>>> The existing way causes problems like:
>>> https://mail-index.netbsd.org/tech-pkg/2018/10/25/msg020395.html
>>> https://mail-index.netbsd.org/tech-userlevel/2018/09/08/msg011381.html
>>
>> I would argue that the first example is, if not outright wrong, then
>> at the very minimum unhygienic, as it doesn't use the same
>> preprocessor nesting for the definition of the name and the use of the
>> name, i.e. it incorrectly assumes that the function will be named
>> "something_uint32_t".
>>
>> Also your change breaks redefining intN_t types with the preprocessor.
>> E.g.
>>
>> #define uint32_t unsigned long long
>> #include 
>>
>> is now broken with your change.
>>
>> -uwe
> 
> This fails with glibc too. I don't expect to find real users for that
> behaviour...
> 

intN_t is C99, C++11, POSIX/UNIX standard

Our previous behavior was barely compliant and not understood by some of
toolchain developers (it was discussed by LLVM developers just few days
ago) and they prompted me/us to switch it.

Some of new UBSan tests broke only on NetBSD because we were the only
tested OS that mangled the intN_t names and we had to deteriorate the
tests because of unrolling intN_t types to anything.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[John Nemeth]

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 committed with only one day of discussion?  When
you post something for discussion, allowing only one day is extremely
inappropriate!  It is appropriate to state when you intend to make
the commit which be an ABSOLUTE MINIMUM of one week.  Please revert
and allow for proper discussion.

}-- End of excerpt from "Maya Rashish"

Re: CVS commit: src/sys/sys

[maya]

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.h
> > 
> > Log Message:
> > Guard from type redefinition (needed by pre-C11 C) in a safer way.
> > 
> > The existing way causes problems like:
> > https://mail-index.netbsd.org/tech-pkg/2018/10/25/msg020395.html
> > https://mail-index.netbsd.org/tech-userlevel/2018/09/08/msg011381.html
> 
> I would argue that the first example is, if not outright wrong, then
> at the very minimum unhygienic, as it doesn't use the same
> preprocessor nesting for the definition of the name and the use of the
> name, i.e. it incorrectly assumes that the function will be named
> "something_uint32_t".
> 
> Also your change breaks redefining intN_t types with the preprocessor.
> E.g.
> 
> #define uint32_t unsigned long long
> #include 
> 
> is now broken with your change.
> 
> -uwe

This fails with glibc too. I don't expect to find real users for that
behaviour...

Re: CVS commit: src/sys/sys

[Valery Ushakov]

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.
> 
> The existing way causes problems like:
> https://mail-index.netbsd.org/tech-pkg/2018/10/25/msg020395.html
> https://mail-index.netbsd.org/tech-userlevel/2018/09/08/msg011381.html

I would argue that the first example is, if not outright wrong, then
at the very minimum unhygienic, as it doesn't use the same
preprocessor nesting for the definition of the name and the use of the
name, i.e. it incorrectly assumes that the function will be named
"something_uint32_t".

Also your change breaks redefining intN_t types with the preprocessor.
E.g.

#define uint32_t unsigned long long
#include 

is now broken with your change.

-uwe

Re: CVS commit: src/sys/sys

[Robert Elz]

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 causes warnings.

Yes, I was kind of expecting that - but b5 is faster doing builds than
I can do them, so I was just going to wait until the next one of those
happened, and then clean up whatever needed it,   But you did all
that already.

kre

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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 macros (aside that it is simpler). The benefit of using
inlines is that the code is the same in both cases and there is argument
checking.

christos

Re: CVS commit: src/sys/sys

[Martin Husemann]

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

Re: CVS commit: src/sys/sys

[Maxime Villard]

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 issues - kern_malloc()
(for historical reasons) takes an unsigned long parameter, not a
size_t - on 64 bit arch's this makes no difference (size_t is unsigned
long) but that's not true on 32 bit archs (or not all of them anyway).

This should unbreak the i386 build (others?) - hopefully without
damaging anything too badly.Note the type issues need fixing,
just making this change permanent is not the solution.


To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/sys/sys/asan.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


Shouldn't we make kern_malloc take a size_t? In the end it calls kmem_alloc
which does take a size_t.

The reason we should not use __nothing is because it leaves unused
variables, and causes warnings.

Re: CVS commit: src/sys/sys

[Paul Goyette]

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
| when using gcc.  For example:

Not if the value has side effects:

int *flags;
CLR(*flags++, 1);


Ah, yeah, that would be bad!  Thanks for the example.


+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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 has side effects:

int *flags;
CLR(*flags++, 1);

christos

Re: CVS commit: src/sys/sys

[Paul Goyette]

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
type-sensitive, and will likely fail silently when the flags variable
is a 64-bit type.

No functional change intended.  If anything breaks, it was probably
already broken.


This is much worse, since it now will evaluate the expression twice.
Please do not just change macros like this without a proper discussion
on the mailing lists.


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:


kern/vfs_bio.c:

   #1037: cv_signal(_cv);

   0x80a3ce88 <+127>:   callq  0x80998ef5 

   #1040: if (ISSET(bp->b_cflags, BC_WANTED))

   0x80a3ce8d <+132>:   mov0xec(%rbx),%eax
   0x80a3ce93 <+138>:   test   $0x80,%eax
   0x80a3ce98 <+143>:   je 0x80a3cea5 

   #1041: CLR(bp->b_cflags, BC_WANTED|BC_AGE);
   0x80a3ce9a <+145>:   and$0xff7e,%eax   
   0x80a3ce9f <+150>:   mov%eax,0xec(%rbx)

The compiler seems perfectly happy optimizing this code without
generating any additional evaluations.

HOWEVER, I'll be happy to revert this.  Since it was dholland@ who
proposed this (on IRC), I will let him initiate any needed discussion
on the tech-kern list.


+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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: types.h
>> 
>> Log Message:
>> Use a different, type-insensitive idiom for CLR().
>> 
>> As discussed on IRC and proposed by dholland@, the existing idiom is
>> type-sensitive, and will likely fail silently when the flags variable
>> is a 64-bit type.
>> 
>> No functional change intended.  If anything breaks, it was probably
>> already broken.
>
>This is much worse, since it now will evaluate the expression twice.
>Please do not just change macros like this without a proper discussion
>on the mailing lists.

Yes, the double evaluation is a show-stopper, please revert.

christos

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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 and proposed by dholland@, the existing idiom is
> type-sensitive, and will likely fail silently when the flags variable
> is a 64-bit type.
> 
> No functional change intended.  If anything breaks, it was probably
> already broken.

This is much worse, since it now will evaluate the expression twice.
Please do not just change macros like this without a proper discussion
on the mailing lists.

Joerg

Re: CVS commit: src/sys/sys

[Michael van Elst]

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,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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 try:
> 
> 
> Maybe this:
> 
> Index: sys/device.h
> ===
> RCS file: /cvsroot/src/sys/sys/device.h,v
> retrieving revision 1.151
> diff -p -u -r1.151 device.h
> --- sys/device.h4 Mar 2018 07:13:11 -   1.151
> +++ sys/device.h18 Apr 2018 05:17:44 -
> @@ -84,7 +84,13 @@
>  #if defined(_KERNEL) || defined(_KMEMUSER)
>  #include 
>  #include 
> +#endif
> +
> +#if defined(_KERNEL)
>  #include 
> +#else if defined(_KMEMUSER) && !defined(_SYS_PMF_H)
> +struct pmf_qual;
> +typedef struct pmf_qual pmf_qual_t;
>  #endif
>  
>  #include 
> 
> 
> Ugly and needs further discussion, but the alternative of moving sys/pmf.h
> into userland is probably worse.
> 
> 
> Greetings,
> 

OK, so assuming that  shall not be exposed to userland - I
propose this patch:

http://netbsd.org/~kamil/patch-00047-pmf_h.txt

It follows the existing style of handling multiple typedefs for the same
type (compliant with pre-C11 code).

It works for me.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[Michael van Elst]

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
===
RCS file: /cvsroot/src/sys/sys/device.h,v
retrieving revision 1.151
diff -p -u -r1.151 device.h
--- sys/device.h4 Mar 2018 07:13:11 -   1.151
+++ sys/device.h18 Apr 2018 05:17:44 -
@@ -84,7 +84,13 @@
 #if defined(_KERNEL) || defined(_KMEMUSER)
 #include 
 #include 
+#endif
+
+#if defined(_KERNEL)
 #include 
+#else if defined(_KMEMUSER) && !defined(_SYS_PMF_H)
+struct pmf_qual;
+typedef struct pmf_qual pmf_qual_t;
 #endif
 
 #include 


Ugly and needs further discussion, but the alternative of moving sys/pmf.h
into userland is probably worse.


Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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 hidden and finally all uses were removed
> from userland, so it only exists in _KERNEL namespace.
> 
> But crash(8) is a hybrid, because it is mostly ddb code compiled for
> userland.
> 
> 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:
> 
> Index: sys/device.h
> ===
> RCS file: /cvsroot/src/sys/sys/device.h,v
> retrieving revision 1.151
> diff -p -u -r1.151 device.h
> --- sys/device.h4 Mar 2018 07:13:11 -   1.151
> +++ sys/device.h18 Apr 2018 04:53:14 -
> @@ -84,6 +84,9 @@
>  #if defined(_KERNEL) || defined(_KMEMUSER)
>  #include 
>  #include 
> +#endif
> +
> +#if defined(_KERNEL)
>  #include 
>  #endif
> 
> I'm verifying against a regular build.
> 
> 
> Greetings,
> 

This change is not sufficient:

In file included from
/public/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_netbsd.cc:97:
In file included from /usr/include/dev/biovar.h:40:
/usr/include/sys/device.h:169:45: error: unknown type name 'pmf_qual_t'
In file included from
/public/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_netbsd.cc:97:
In file included from /usr/include/dev/biovar.h:40:
/usr/include/sys/device.h:169:45: error: unknown type name 'pmf_qual_t'
In file included from
/public/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_netbsd.cc:97:
In file included from /usr/include/dev/biovar.h:40:
/usr/include/sys/device.h:169:45: error: unknown type name 'pmf_qual_t'
In file included from
/public/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_netbsd.cc:97:
In file included from
/public/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_netbsd.cc:97:
In file included from /usr/include/dev/biovar.h:40:
/usr/include/sys/device.h:169:45: error: unknown type name 'pmf_qual_t'
In file included from /usr/include/dev/biovar.h:40:
In file included from
/public/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_netbsd.cc:97:
/usr/include/sys/device.h:169:45: error: unknown type name 'pmf_qual_t'
In file included from /usr/include/dev/biovar.h:40:
/usr/include/sys/device.h:169:45: error: unknown type name 'pmf_qual_t'
[ 49%] Built target LLVMBPFDesc
bool(*dv_driver_suspend)(device_t, const pmf_qual_t *);
 ^
/usr/include/sys/device.h:170:44: error: unknown type name 'pmf_qual_t'
bool(*dv_driver_resume)(device_t, const pmf_qual_t *);
^
/usr/include/sys/device.h:175:42: error: unknown type name 'pmf_qual_t'
bool(*dv_bus_suspend)(device_t, const pmf_qual_t *);
  ^
bool(*dv_driver_suspend)(device_t, const pmf_qual_t *);
 ^
/usr/include/sys/device.h:170:44: error: unknown type name 'pmf_qual_t'
bool(*dv_driver_resume)(device_t, const pmf_qual_t *);
^
bool(*dv_driver_suspend)(device_t, const pmf_qual_t *);
 ^
/usr/include/sys/device.h:170:44: error: unknown type name 'pmf_qual_t'
bool(*dv_driver_resume)(device_t, const pmf_qual_t *);
^
bool(*dv_driver_suspend)(device_t, const pmf_qual_t *);
 ^
/usr/include/sys/device.h:170:44: error: unknown type name 'pmf_qual_t'
bool(*dv_driver_resume)(device_t, const pmf_qual_t *);
^
/usr/include/sys/device.h:175:42: error: unknown type name 'pmf_qual_t'
bool(*dv_bus_suspend)(device_t, const pmf_qual_t *);
  ^
bool(*dv_driver_suspend)(device_t, const pmf_qual_t *);
 ^
/usr/include/sys/device.h:170:44: error: unknown type name 'pmf_qual_t'
bool(*dv_driver_resume)(device_t, const pmf_qual_t *);
^
bool(*dv_driver_suspend)(device_t, const pmf_qual_t *);
   

Re: CVS commit: src/sys/sys

[Michael van Elst]

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, so it only exists in _KERNEL namespace.

But crash(8) is a hybrid, because it is mostly ddb code compiled for
userland.

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:

Index: sys/device.h
===
RCS file: /cvsroot/src/sys/sys/device.h,v
retrieving revision 1.151
diff -p -u -r1.151 device.h
--- sys/device.h4 Mar 2018 07:13:11 -   1.151
+++ sys/device.h18 Apr 2018 04:53:14 -
@@ -84,6 +84,9 @@
 #if defined(_KERNEL) || defined(_KMEMUSER)
 #include 
 #include 
+#endif
+
+#if defined(_KERNEL)
 #include 
 #endif

I'm verifying against a regular build.


Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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 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.
>>>
 @@ -81,7 +81,7 @@
  #include 
  #include 
  
 -#ifdef _KERNEL
 +#if defined(_KERNEL) || defined(_KMEMUSER)
  #include 
  #include 
  #include 
>>>
>>> The sys/pmf.h header is not accessible from userland.
>>
>> True.
>>
>> What program includes device.h as _KMEMUSER but crash(8) ? There
>> shouldn't be any.
>>
>> crash helps itself by including system headers, but that's probably
>> not a good recipe for everyone.
>>
>>
>>
>> Greetings,
>>
> 
> I'm including this header indirectly in compiler-rt (with local
> patches). I have a long list of includes and _KMEMUSER on top.
> 
> It's included at least through  ->  ->
> .
> 
> https://github.com/llvm-mirror/compiler-rt/blob/master/lib/sanitizer_common/sanitizer_platform_limits_netbsd.cc
> + local patch
> https://github.com/NetBSD/pkgsrc-wip/blob/master/compiler-rt-netbsd/patches/patch-lib_sanitizer__common_sanitizer__platform__limits__netbsd.cc
> 
> This code used to build and work before that change.
> 

Looking at other users, everyone except  include
 in the _KERNEL namespace.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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:
>>> src/sys/sys: device.h
>>>
>>> Log Message:
>>> Expose device structures to _KMEMUSER
>>>
>>>
>>
>> This broke building device.h with _KMEMUSER.
>>
>>> @@ -81,7 +81,7 @@
>>>  #include 
>>>  #include 
>>>  
>>> -#ifdef _KERNEL
>>> +#if defined(_KERNEL) || defined(_KMEMUSER)
>>>  #include 
>>>  #include 
>>>  #include 
>>
>> The sys/pmf.h header is not accessible from userland.
> 
> True.
> 
> What program includes device.h as _KMEMUSER but crash(8) ? There
> shouldn't be any.
> 
> crash helps itself by including system headers, but that's probably
> not a good recipe for everyone.
> 
> 
> 
> Greetings,
> 

I'm including this header indirectly in compiler-rt (with local
patches). I have a long list of includes and _KMEMUSER on top.

It's included at least through  ->  ->
.

https://github.com/llvm-mirror/compiler-rt/blob/master/lib/sanitizer_common/sanitizer_platform_limits_netbsd.cc
+ local patch
https://github.com/NetBSD/pkgsrc-wip/blob/master/compiler-rt-netbsd/patches/patch-lib_sanitizer__common_sanitizer__platform__limits__netbsd.cc

This code used to build and work before that change.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[Michael van Elst]

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 Message:
> > Expose device structures to _KMEMUSER
> > 
> > 
> 
> This broke building device.h with _KMEMUSER.
> 
> > @@ -81,7 +81,7 @@
> >  #include 
> >  #include 
> >  
> > -#ifdef _KERNEL
> > +#if defined(_KERNEL) || defined(_KMEMUSER)
> >  #include 
> >  #include 
> >  #include 
> 
> The sys/pmf.h header is not accessible from userland.

True.

What program includes device.h as _KMEMUSER but crash(8) ? There
shouldn't be any.

crash helps itself by including system headers, but that's probably
not a good recipe for everyone.



Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: CVS commit: src/sys/sys

[Kamil Rytarowski]

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.

> @@ -81,7 +81,7 @@
>  #include 
>  #include 
>  
> -#ifdef _KERNEL
> +#if defined(_KERNEL) || defined(_KMEMUSER)
>  #include 
>  #include 
>  #include 

The sys/pmf.h header is not accessible from userland.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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:  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 that
> >> we get the correct width.
> >
> >Please don't use __typeof__. 1ull is good enough and we can depend on
> >a non-stupid compiler to truncate the intermediate.
> 
> The __typeof__ ship has already sailed:
> 
> $ fgrep -r __typeof__ /usr/include/sys/ | wc -l
>3

Of those, only the rounddown2 is non-optional. That falls into the same
category even, it doesn't really hurt to widen there.

> Doing a 64 bit calculation on a 32 bit platform when it is not needed
> is a waste (and produces narrowing warnings).

It's not a 64bit calculation if the compiler is at least trying to
create sane code. The bit masking should ensure that.

Joerg

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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: bitops.h
>> 
>> Log Message:
>> PR/53081: Fix size of the shift to depend on the type of the bitmap so that
>> we get the correct width.
>
>Please don't use __typeof__. 1ull is good enough and we can depend on
>a non-stupid compiler to truncate the intermediate.

The __typeof__ ship has already sailed:

$ fgrep -r __typeof__ /usr/include/sys/ | wc -l
   3

Not counting all the c++ header uses...

Doing a 64 bit calculation on a 32 bit platform when it is not needed
is a waste (and produces narrowing warnings).

christos

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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 that
> we get the correct width.

Please don't use __typeof__. 1ull is good enough and we can depend on
a non-stupid compiler to truncate the intermediate.

Joerg

Re: CVS commit: src/sys/sys

[Masanobu SAITOH]

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)

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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 UTC 2017
> > > 
> > > Modified Files:
> > >   src/sys/sys: disk.h
> > > 
> > > Log Message:
> > > do not expose kernel-internal structure definitions to userland.
> > > needed for ZFS.
> > 
> > The move of sys/iostat.h is breaking a couple of monitoring/statistics
> > programs. Is that really necessary?
> 
> no, it doesn't cause a problem if that one is moved back to the group of
> includes at the top.  I take it you'd like me to do that?

Yes, please.

> 
> what are these programs that broke?  are they in pkgsrc?

E.g. py-psutil, gkrellm and others.

Joerg

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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.

The move of sys/iostat.h is breaking a couple of monitoring/statistics
programs. Is that really necessary?

Joerg

Re: CVS commit: src/sys/sys

[Martin Husemann]

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.
In this case it was actually pretty good (I had feared a lot worse fallout).

Martin

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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
>> 
>> Log Message:
>> define constants as being wider than int when needed, instead of casting
>> them at use. makes compilers happier.
>
>Besides the already fixed bug, can we please just go back to
>"-Wsystem-header considered harmful"?

The default state of having system header warnings disabled is broken
because it hides all kinds of bugs in the headers, and also conseals
unintended user interaction with the headers:

- one header does #define FOO 1, another does #define FOO 2
  you don't get warned; case in point MACHINE_ARCH on ppc64,
  MACHINE on cesfic.

- fortify is castrated (we found bugs in sysinst):

char foo[5];
strncat(foo, "bazfoo", sizeof(foo));

cc -O2 --param ssp-buffer-size=1 -Wstack-protector \
-D_FORTIFY_SOURCE=2 -Wall -Wsystem-headers \
-fstack-protector -c ssp.c
In file included from /usr/include/string.h:126:0,
from ssp.c:2:
ssp.c: In function 'main':
ssp.c:8:2: warning: call to __builtin___strncat_chk will \
always overflow destination buffer

- since there is an arbitrary boundary between user + system header
  code, context is lost (the ctype problem):

# 5 "isblank.c" 3 4
   ((int)((_ctype_tab_ + 1)[(
# 5 "isblank.c"
   ac
# 5 "isblank.c" 3 4
   )] & 0x0200))
# 5 "isblank.c"
  ;

  this basically says, 3 == system header, 4 == in "c" context
  (extern "C")... So the array expression now (gcc 5.x) does not
  produce a warning anymore. gcc 4.8 did this as:

   ((int)((_ctype_tab_ + 1)[(ac)] & 0x0200));
 
  Another set of bugs were revealed in ATF code, because we
  have large macros defined in , so user code warnings
  get hidden .
  
- Who decides what warnings are disabled for system headers?
  should I be warned for a structure declaration inside a parameter
  list (I don't get warned).

- If I do:

#define INFTIM 3
#include 

  shouldn't I get a warning? Because I don't!

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.

christos

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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 use. makes compilers happier.

Besides the already fixed bug, can we please just go back to
"-Wsystem-header considered harmful"?

Joerg

re: CVS commit: src/sys/sys

[Paul Goyette]

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:

   The inline functions {ms,us,ns}2bintime() are currently defined
   incorrectly, and always result in the bt.frac being set to zero.
   Even correcting for left- vs right shifts, the results are low
   precision with at most 32 significant bits.

   Rewrite using 64-bit multiply rather than division to get proper
   results.  Also the multiply is less costly than a divide on most
   platforms.

Unfortunately, the line breaks didn't survive my 'cvs admin' command
(I tried to put them in the message using \n but that didn't work.)



+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

re: CVS commit: src/sys/sys

[matthew green]

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" 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!
> >
> > !DSPAM:586f0b9f152991262213216!
> >
> >
> 
> +--+--++
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
> | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
> +--+--++
> 

re: CVS commit: src/sys/sys

[matthew green]

"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!

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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.

Since the macros are already cast to uint64_t the second cast is a no-op.

christos

Re: CVS commit: src/sys/sys

[Paul Goyette]

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.msg



Perhaps #define some BINTIME_SCALE_{M,U,N}S constants since they are repeated
in the code?


Sure - sounds like a good idea to me!


+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Re: CVS commit: src/sys/sys

[Christos Zoulas]

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_SCALE_{M,U,N}S constants since they are repeated
in the code?

christos

Re: CVS commit: src/sys/sys

[coypu]

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.

Re: CVS commit: src/sys/sys

[coypu]

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?

re: CVS commit: src/sys/sys

[matthew green]

"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

shouldn't the _NETBSD_SOURCE ifdef also check _KERNEL, like
the older versions of this did as well as the other checks
in this file.


.mrg.

Re: CVS commit: src/sys/sys

[David Holland]

(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:
 > >src/sys/sys: dirent.h
 > > 
 > > Log Message:
 > > Uses __GNUC_PREREQ__, needs sys/cdefs.h.
 > 
 > I wonder if including stddef.h / libkern.h and using the real offsetof
 > would be better.

Wouldn't help; the GNUC_PREREQ is there because it uses typeof. Which
it needs to do, because the macro in question needs to be polymorphic
over struct dirent and also struct direct from FFS. *That* is what
ought to be tidied up.

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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 symbol weak is a
> very strange way to stop the compiler making this assumption.

Actually, it is the most natural way given the constraints. It is pretty
much the only attribute around to define that one object is actually a
different object altogether.

> I have trouble seeing how the mis-optimization can be justified for external
> symbols anyway, but this may depend on the type they point to and the
> fine print. Your example with local/auto symbols certainly is very
> differnent to the link sets case.

There are no local / auto symbols involved here. Just global variables.
That's *exactly* what the linker set case is using.

> How about making the start/end symbols uintptr_t, then calculating the count
> upfront and casting start for the iteration?

The symbols reference the start and end of the section. They have no
natural value associated.

Joerg

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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) {
>  >  return  != 
>  >}
> 
> Do you perhaps mean "extern int a, b;"? That's an important
> distinction. In particular I can't find anything in C99 that
> guarantees that two such declarations for which storage is not
> reserved can't refer to the same object.

The historic mistake of using common for uninitialised storage is
irrelevant and so is using extern or not. In C11, the relevant case is
6.5.9 (6).

Joerg

Re: CVS commit: src/sys/sys

[David Holland]

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  != 
 >}

Do you perhaps mean "extern int a, b;"? That's an important
distinction. In particular I can't find anything in C99 that
guarantees that two such declarations for which storage is not
reserved can't refer to the same object.

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/sys/sys

[Martin Husemann]

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 assumption. I have
trouble seeing how the mis-optimization can be justified for external
symbols anyway, but this may depend on the type they point to and the
fine print. Your example with local/auto symbols certainly is very
differnent to the link sets case.

How about making the start/end symbols uintptr_t, then calculating the count
upfront and casting start for the iteration?

Martin

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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. So
> >far I have seen no real justification for the change, other than some
> >mumblings about ld mishandling weak symbols. That seems to be a pretty
> >clear cut case for a revert and going back to the design board to
> >understand why rump started failing with new binutils.
> 
> I'm old and forgetful and need a PR.
> 
> I think at the moment it's a case of least used gets left broken until all
> problems are understood

Here is a trivial test case showing that the basic problem exists for
both clang and gcc:

   int a, b

   int f(void) {
 return  != 
   }

When compiling with -O2, both return the function to "return 1". The
linker set iteration typically looks something like:
   for (iter =  iter !=  ++iter)
  ...

Depending on the phase of the moon, the compiler will therefore turn
this into a do-while loop as the condition is initially false.

In short, this is a real problem and the assumption is not specific to
clang. Revert now, please.

Joerg

Re: CVS commit: src/sys/sys

[Nick Hudson]

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 some
mumblings about ld mishandling weak symbols. That seems to be a pretty
clear cut case for a revert and going back to the design board to
understand why rump started failing with new binutils.


I'm old and forgetful and need a PR.

I think at the moment it's a case of least used gets left broken until 
all problems are understood




Joerg


Nick

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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:44:57PM -0500, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Fri Mar 11 00:44:56 UTC 2016
> 
> Modified Files:
>   src/sys/sys: cdefs_elf.h
> 
> Log Message:
> Undo weak here to fix the tests; will revisit soon.
> >>>Can you revert this now as it is broken and should not be used to work
> >>>around binutils bugs?
> >>Did something change? If I revert it all the rump tests fail...
> >So we are breaking clang for bugs in binutils now?
> >
> >Joerg
> >
> 
> 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 some
mumblings about ld mishandling weak symbols. That seems to be a pretty
clear cut case for a revert and going back to the design board to
understand why rump started failing with new binutils.

Joerg

Re: CVS commit: src/sys/sys

[Christos Zoulas]

In article <20160318161925.ga27...@britannica.bec.de>,
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:44:57PM -0500, Christos Zoulas wrote:
>> >> Module Name:  src
>> >> Committed By: christos
>> >> Date: Fri Mar 11 00:44:56 UTC 2016
>> >> 
>> >> Modified Files:
>> >>   src/sys/sys: cdefs_elf.h
>> >> 
>> >> Log Message:
>> >> Undo weak here to fix the tests; will revisit soon.
>> >
>> >Can you revert this now as it is broken and should not be used to work
>> >around binutils bugs?
>> 
>> Did something change? If I revert it all the rump tests fail...
>
>So we are breaking clang for bugs in binutils now?

I am trying to accommodate both compilers. I don't think that the people
maintaining binutils believe this is a bug; do they? Is there a PR open
for it?

christos

Re: CVS commit: src/sys/sys

[Christos Zoulas]

In article <20160318030154.gb12...@britannica.bec.de>,
Joerg Sonnenberger   wrote:
>On Thu, Mar 10, 2016 at 07:44:57PM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Fri Mar 11 00:44:56 UTC 2016
>> 
>> Modified Files:
>>  src/sys/sys: cdefs_elf.h
>> 
>> Log Message:
>> Undo weak here to fix the tests; will revisit soon.
>
>Can you revert this now as it is broken and should not be used to work
>around binutils bugs?

Did something change? If I revert it all the rump tests fail...

christos

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

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:44:57PM -0500, Christos Zoulas wrote:
> >> Module Name:   src
> >> Committed By:  christos
> >> Date:  Fri Mar 11 00:44:56 UTC 2016
> >> 
> >> Modified Files:
> >>src/sys/sys: cdefs_elf.h
> >> 
> >> Log Message:
> >> Undo weak here to fix the tests; will revisit soon.
> >
> >Can you revert this now as it is broken and should not be used to work
> >around binutils bugs?
> 
> Did something change? If I revert it all the rump tests fail...

So we are breaking clang for bugs in binutils now?

Joerg

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

On Thu, Mar 10, 2016 at 07:44:57PM -0500, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Fri Mar 11 00:44:56 UTC 2016
> 
> Modified Files:
>   src/sys/sys: cdefs_elf.h
> 
> Log Message:
> Undo weak here to fix the tests; will revisit soon.

Can you revert this now as it is broken and should not be used to work
around binutils bugs?

Joerg

Re: CVS commit: src/sys/sys

[Nick Hudson]

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:44:57PM -0500, Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Fri Mar 11 00:44:56 UTC 2016

Modified Files:
src/sys/sys: cdefs_elf.h

Log Message:
Undo weak here to fix the tests; will revisit soon.

Can you revert this now as it is broken and should not be used to work
around binutils bugs?

Did something change? If I revert it all the rump tests fail...

So we are breaking clang for bugs in binutils now?

Joerg



Is there a PR that describes the clang problem?

Nick

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

On Tue, May 19, 2015 at 11:35:11PM +, Taylor R Campbell wrote:
 Module Name:  src
 Committed By: riastradh
 Date: Tue May 19 23:35:11 UTC 2015
 
 Modified Files:
   src/sys/sys: time.h
 
 Log Message:
 Avoid C99 initializers outside _KERNEL.

Two comments. First: C99 initializers are not valid C++, which makes it
even more problematic. Second, can't you just write them as plain struct
init? It's unlikely that the structures will grow more entries after
all...

Joerg

re: CVS commit: src/sys/sys

[Paul Goyette]

On Fri, 24 Apr 2015, matthew green wrote:



Paul Goyette writes:

Module Name:src
Committed By:   pgoyette
Date:   Thu Apr 23 23:23:20 UTC 2015

Modified Files:
src/sys/sys: param.h

Log Message:
Welcome to 7.99.x and the modularization of sysmon!


why bump the version?  i didn't see any kernel ABI change.


Lots of inter-module dependencies that won't get resolved properly if 
you mix new kernel with previous 7.99.10 modules.




-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
-

re: CVS commit: src/sys/sys

[matthew green]

Paul Goyette writes:
 Module Name:  src
 Committed By: pgoyette
 Date: Thu Apr 23 23:23:20 UTC 2015
 
 Modified Files:
   src/sys/sys: param.h
 
 Log Message:
 Welcome to 7.99.x and the modularization of sysmon!

why bump the version?  i didn't see any kernel ABI change.


.mrg.

Re: CVS commit: src/sys/sys

[Paul Goyette]

I'll also fix this - we're now at 7.99.11 (not 'x')

On Thu, 23 Apr 2015, Paul Goyette wrote:


Module Name:src
Committed By:   pgoyette
Date:   Thu Apr 23 23:23:20 UTC 2015

Modified Files:
src/sys/sys: param.h

Log Message:
Welcome to 7.99.x and the modularization of sysmon!


To generate a diff of this commit:
cvs rdiff -u -r1.472 -r1.473 src/sys/sys/param.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
-

Re: CVS commit: src/sys/sys

[Christos Zoulas]

On Nov 17,  7:56am, mar...@homeworld.netbsd.org (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/sys/sys

| On Sun, Nov 16, 2014 at 09:27:26PM -0500, Christos Zoulas wrote:
|  Module Name:src
|  Committed By:   christos
|  Date:   Mon Nov 17 02:27:26 UTC 2014
|  
|  Added Files:
|  src/sys/sys: clock.h
|  
|  Log Message:
|  PR/49207: Kamil Rytarowski: Centralize and rename a bunch of clock constants
|  and inline functions.
| 
| Why inline functions? None of these are used often or time critical.

I was thinking the same. We could put them in common/ somewhere.

| Besides: this broke the tools build, as you did not deal with
| tools/compat/subr_clock.h.

I forgot about hat.

christos

Re: CVS commit: src/sys/sys

[Joerg Sonnenberger]

On Mon, Nov 17, 2014 at 08:50:20AM -0500, Christos Zoulas wrote:
 On Nov 17,  7:56am, mar...@homeworld.netbsd.org (Martin Husemann) wrote:
 -- Subject: Re: CVS commit: src/sys/sys
 
 | On Sun, Nov 16, 2014 at 09:27:26PM -0500, Christos Zoulas wrote:
 |  Module Name:  src
 |  Committed By: christos
 |  Date: Mon Nov 17 02:27:26 UTC 2014
 |  
 |  Added Files:
 |src/sys/sys: clock.h
 |  
 |  Log Message:
 |  PR/49207: Kamil Rytarowski: Centralize and rename a bunch of clock 
 constants
 |  and inline functions.
 | 
 | Why inline functions? None of these are used often or time critical.
 
 I was thinking the same. We could put them in common/ somewhere.

I don't agree, for most the complexity of the call doesn't justify the
extra code, so inline is fine. That said, days_in_month is quite
wasteful with using an array of int...

Joerg