Re: CVS commit: src/sys/sys
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
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
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
> 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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Thu, Mar 08, 2018 at 10:25:45PM +, Christos Zoulas wrote: > In article <20180308215453.gb22...@britannica.bec.de>, > Joerg Sonnenbergerwrote: > >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
In article <20180308215453.gb22...@britannica.bec.de>, Joerg Sonnenbergerwrote: >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
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
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
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
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
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
In article <20170117155009.ga13...@britannica.bec.de>, Joerg Sonnenbergerwrote: >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
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
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
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
"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
In article <20170105232440.032b1f...@cvs.netbsd.org>, Paul Goyettewrote: >-=-=-=-=-=- > >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
On Thu, 5 Jan 2017, Christos Zoulas wrote: In article <20170105225115.78e7df...@cvs.netbsd.org>, Paul Goyettewrote: -=-=-=-=-=- 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
In article <20170105225115.78e7df...@cvs.netbsd.org>, Paul Goyettewrote: >-=-=-=-=-=- > >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
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
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
"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
(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
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
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
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
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
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
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
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 Sonnenbergerwrote: > >>>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
In article <20160318161925.ga27...@britannica.bec.de>, Joerg Sonnenbergerwrote: >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
In article <20160318030154.gb12...@britannica.bec.de>, Joerg Sonnenbergerwrote: >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
On Fri, Mar 18, 2016 at 10:52:27AM +, Christos Zoulas wrote: > In article <20160318030154.gb12...@britannica.bec.de>, > Joerg Sonnenbergerwrote: > >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
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
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 Sonnenbergerwrote: 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
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
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
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
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
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
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