Re: CVS commit: src/sys/arch
> On Dec 23, 2019, at 7:53 PM, Taylor R Campbell
> wrote:
>
>> Module Name:src
>> Committed By: thorpej
>> Date: Sun Dec 22 15:09:39 UTC 2019
>>
>> Add intr_mask() and corresponding intr_unmask() calls that allow specific
>> interrupt lines / sources to be masked as needed (rather than making a
>> set of sources by IPL as with spl*()).
>>
>> + if (ci == curcpu() || !mp_online) {
>> + intr_hwunmask_xcall(ih, NULL);
>> + } else {
>> + where = xc_unicast(0, intr_hwunmask_xcall, ih, NULL, ci);
>> + xc_wait(where);
>> + }
>
> If this conditional is necessary, we should teach xc_unicast to make
> it unnecessary.
Agreed. I followed the existing patter in intr.c. Andrew pointed out in code
review that the xcall code does at the the !mp_online bit now, but:
1- It does not do the curcpu() check.
2- It also fiddles with interrupt state.
For that reason, I was hesitant to make that change until further investigation
was done.
-- thorpej
Re: CVS commit: src/sys/arch
> Module Name:src
> Committed By: thorpej
> Date: Sun Dec 22 15:09:39 UTC 2019
>
> Add intr_mask() and corresponding intr_unmask() calls that allow specific
> interrupt lines / sources to be masked as needed (rather than making a
> set of sources by IPL as with spl*()).
>
> + if (ci == curcpu() || !mp_online) {
> + intr_hwunmask_xcall(ih, NULL);
> + } else {
> + where = xc_unicast(0, intr_hwunmask_xcall, ih, NULL, ci);
> + xc_wait(where);
> + }
If this conditional is necessary, we should teach xc_unicast to make
it unnecessary.
Re: CVS commit: src/sys/uvm
> On Dec 23, 2019, at 7:22 PM, Taylor R Campbell > wrote: > > So I guess we won't be switching pg->phys_addr from paddr to pfn? If that's the case, we should rename the field. -- thorpej
Re: CVS commit: src/share/tmac
Date:Mon, 23 Dec 2019 23:45:34 +0100
From:Steffen Nurpmeso
Message-ID: <20191223224534.8ufgy%stef...@sdaoden.eu>
| |Troff reads .ie and checks the condition. The condition is true and
| |so the rest of the line is executed. Then troff reads .el that
| |matches successful .ie, so the .el is discarded.
| |
| |Then it reads .el which is not matched with any .ie that troff has
| |seen. It's usually silently discarded,
That is what is (always was) intended to happen.
| |but since we run with -ww we
| |get the warning about an unbalanced .el
That's a broken warning. The code in a "discarded" .el needs to be
examined anyway (if it weren't, the \{ \} block to group the code
together wouldn't work, and when doing that, it can easily notice an
embedded .ie (it must be immediately after the .el so looking for it is
not hard) which will require another matching .el, and make sure that
things are correctly balanced. That would be a useful wraning.
The
.ie
.el .ie
.el .ie
.el
idiom has been used in troff (including by troff's authors) forever.
Deciding to make that improper now, just because someone who doesn't
understand, or cannot work out how to handle it correctly, is absurd.
Perhaps (originally) the ".el .ie" combination could have been made
a macro of its own, it should really be treated as if it were (like
the "elif" word in sh), but adding more code to process another macro,
just to save (what would be) 3 input bytes per use wouldn't really
have been justifiable.
kre
Re: CVS commit: src/sys/uvm
> Module Name:src
> Committed By: ad
> Date: Sat Dec 21 14:41:44 UTC 2019
>
> - Add inlines to set/get locator values in the unused lower bits of
> pg->phys_addr. Begin by using it to cache the freelist index, because
> computing it is expensive and that shows up during profiling. Discussed
> on tech-kern.
So I guess we won't be switching pg->phys_addr from paddr to pfn?
Speaking of which, any plans for expanding to >32-bit (or >31-bit, if
signed) pfns in the rest of uvm?
> +static inline unsigned
> +uvm_page_get_bucket(struct vm_page *pg)
> +{
> + return (pg->phys_addr & 0x3e0) >> 5;
> +}
Can you use __BITS/__SHIFTIN/__SHIFTOUT for this instead of magic hex
masks?
#define PHYSADDR_FREELIST __BITS(0,4)
#define PHYSADDR_BUCKET __BITS(5,9)
static inline unsigned
uvm_page_get_bucket(struct vm_page *pg)
{
return __SHIFTOUT(pg->phys_addr, PHYSADDR_BUCKET);
}
static inline unsigned
uvm_page_set_bucket(struct vm_page *pg, unsigned b)
{
pg->phys_addr &= ~PHYSADDR_BUCKET;
pg->phys_addr |= __SHIFTIN(b, PHYSADDR_BUCKET);
}
Re: CVS commit: src/share/tmac
Valery Ushakov wrote in <20191223222133.gj24...@pony.stderr.spb.ru>: |On Mon, Dec 23, 2019 at 22:13:23 +0100, Steffen Nurpmeso wrote: |> Valeriy E. Ushakov wrote in <20191223201734.0e415f...@cvs.netbsd.org>: |> |>|Modified Files: |>| src/share/tmac: doc2html |>| |>|Log Message: |>|Fix if/else syntax in previous. |> |> What was wrong with that? |> |> . ie 'utf8'\*[.T]' \ |> . ds mx:istty |> . el .ie 'latin1'\*[.T]' \ |> . ds mx:istty |> . el .ie 'ascii'\*[.T]' \ |> . ds mx:istty |> . el .ie 'pdf'\*[.T]' \ |> . mx:dump-init-pdf |> . el .ie 'html'\*[.T]' \ |> . mx:dump-init-html |> . el \ |> . rm mx:gogogo |> |> is perfectly valid roff code. | |Try running it with warnings (-ww), as the build process does. You'll |get | |warning: unbalanced .el request | |Consider | | .ie '\*(.T'ascii' .ds html-charset US-ASCII | .el .ie '\*(.T'latin1' .ds html-charset ISO-8859-1 | .el .ie '\*(.T'utf8' .ds html-charset UTF-8 | .el .ab unsupported encoding \*(.T | |executed with -Tascii. | |Troff reads .ie and checks the condition. The condition is true and |so the rest of the line is executed. Then troff reads .el that |matches successful .ie, so the .el is discarded. | |Then it reads .el which is not matched with any .ie that troff has |seen. It's usually silently discarded, but since we run with -ww we |get the warning about an unbalanced .el | |The the same happens again for the next .el, the number of warnings |depends on which .ie in the chain was successful (no warnings for |utf-8, 1 warning for latin1, two for ascii). Interesting. You are right. Never encountered that, i have to change some macros of mine! A nice Christmas i wish! Ciao from Germany, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/share/tmac
On Mon, Dec 23, 2019 at 22:13:23 +0100, Steffen Nurpmeso wrote: > Valeriy E. Ushakov wrote in <20191223201734.0e415f...@cvs.netbsd.org>: > > |Modified Files: > | src/share/tmac: doc2html > | > |Log Message: > |Fix if/else syntax in previous. > > What was wrong with that? > > . ie 'utf8'\*[.T]' \ > . ds mx:istty > . el .ie 'latin1'\*[.T]' \ > . ds mx:istty > . el .ie 'ascii'\*[.T]' \ > . ds mx:istty > . el .ie 'pdf'\*[.T]' \ > . mx:dump-init-pdf > . el .ie 'html'\*[.T]' \ > . mx:dump-init-html > . el \ > . rm mx:gogogo > > is perfectly valid roff code. Try running it with warnings (-ww), as the build process does. You'll get warning: unbalanced .el request Consider .ie '\*(.T'ascii' .ds html-charset US-ASCII .el .ie '\*(.T'latin1' .ds html-charset ISO-8859-1 .el .ie '\*(.T'utf8' .ds html-charset UTF-8 .el .ab unsupported encoding \*(.T executed with -Tascii. Troff reads .ie and checks the condition. The condition is true and so the rest of the line is executed. Then troff reads .el that matches successful .ie, so the .el is discarded. Then it reads .el which is not matched with any .ie that troff has seen. It's usually silently discarded, but since we run with -ww we get the warning about an unbalanced .el The the same happens again for the next .el, the number of warnings depends on which .ie in the chain was successful (no warnings for utf-8, 1 warning for latin1, two for ascii). -uwe
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/share/tmac
Valeriy E. Ushakov wrote in <20191223201734.0e415f...@cvs.netbsd.org>: |Module Name: src |Committed By: uwe |Date: Mon Dec 23 20:17:33 UTC 2019 | |Modified Files: | src/share/tmac: doc2html | |Log Message: |Fix if/else syntax in previous. What was wrong with that? . ie 'utf8'\*[.T]' \ . ds mx:istty . el .ie 'latin1'\*[.T]' \ . ds mx:istty . el .ie 'ascii'\*[.T]' \ . ds mx:istty . el .ie 'pdf'\*[.T]' \ . mx:dump-init-pdf . el .ie 'html'\*[.T]' \ . mx:dump-init-html . el \ . rm mx:gogogo is perfectly valid roff code. |To generate a diff of this commit: |cvs rdiff -u -r1.69 -r1.70 src/share/tmac/doc2html --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/usr.bin/crunch/crunchgen
On Mon, Dec 23, 2019 at 06:54:47PM -, Christos Zoulas wrote: > Here is a patch that: > > 1. removes all the special handling of variables (-d -p -P -s -S) that >were dealing with DBG (-d) LDSTATIC/NOPIE (-p), and the rest with >disabling/enabling sanitizers. > 2. uses emalloc/estrdup for all the allocators instead of only some cases. > 3. adds -V varspec which passes variables on the command line (as DBG >and LDSTATIC used to be passed before) instead of appending them >to the on-the-fly Makefile using -v varspec. > > The motivation of this is to make variable handling consistent, less magical, > and remove the need for changing crunchgen each time we want to add disabling > an option by default. I like this in principle, but I haven't double checked everything. Joerg
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
Le 23/12/2019 à 04:18, Taylor R Campbell a écrit : Date: Sun, 22 Dec 2019 10:24:01 +0100 From: Maxime Villard You, Martin Christos and Taylor, are trying to change subject, find excuses, and are sending me irrelevant responses vaguely insinuating that I should revert my change only without addressing the additional concerns expressed repeatedly. I fail to see whether I should take these as official core answers. If they are, please clearly say so. Please revert your filemon deletion and leave the existing mitigation in place for the moment pending discussion. We can address the additional concerns afterward. Thanks, -Riastradh, on behalf of core You see, it wasn't really complicated. I have now reverted the removal. Just to sum up a few points: - I am severely accused of wrongdoing. Yet, under core's watch, secteam proceeded with a careless disabling of filemon with no public discussion whatsoever. For some reason, there suddenly is no wrongdoing here. - Actually the reason is apparently that security issues must be discussed in private. Yet, having been in secteam, I was systematically told to stop the discussions and make them public, which I always did. For some reason, there is no need to make these discussions public anymore. - But whatever, I really have to revert my removal _before_ any form of discussion is engaged on this topic. Yet, for some reason, maya's broken disabling must be left as-is and shouldn't be reverted _after_ discussion on the topic. - All in the name of consensus and community. And who cares if core and secteam openly demonstrate gross disregard for said consensus and community the way they have just now. I believe core has just made a great farce of itself with these double standards. For the record: Le 21/12/2019 à 23:48, Christos Zoulas a écrit : If you are unhappy with core@ talk to board@. I have now escalated the matter to board. Maxime
