Re: CVS commit: src/lib/libc/time

[Warner Losh]

On Sun, Oct 23, 2022 at 11:00 AM Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:

> > Date: Sun, 23 Oct 2022 07:39:25 -0600
> > From: Warner Losh 
> >
> > I guess a more accurate way of saying this is that leap seconds simply
> > aren't reliable, cannot be made reliable, and this affects normalization
> > in ways too numerous to mention due to the details of the tz files, bugs
> > in the system, and lack of others to implement them correctly.
>
> I think you mean `POSIX clocks simply aren't reliable'.  They _could_
> be made reliable, though, by fixing the the calendar arithmetic
> formula in POSIX for mapping time_t to and from UTC -- just like POSIX
> already fixed the bug in its Gregorian leap year formula.
>

Except they can't, at least not practically enough to be a standard. The
Gregorian Leap Year formula is a mathematical formula that needs no
further data other than the broken down time to compute. It's not an
observational calendar, but a computational or arithmetic one. UTC is an
observational calendar. We barely know if there's going to be a leap
second in the coming months, and have nothing more than a vague notion
of when the one after that might be. You must have a table of all past
leap seconds to do any kind of sensible mapping. And you also must
have some way to keep that up to date, even when machines are
powered off, or installed from not really that old media (anything older
than 6 months can't possibly have the right leap table, except by
chance). And then the question becomes how do you get it, do you
assume connectivity, some standard media format, some standard file
format, etc. All of these details means POSIX can't really fix this. And
even if they do, the current formula has been around so long there's a
lot of dusty decks of code that will likely silently break. You can
ameliorate
that somewhat by inventing new interfaces, but issues like the one you go
into below will still persist.


> > > The code works with either set of tzdata files, POSIX stretchy secs,
> > > or UTC with leap secs - claiming that one doesn't happen, or cannot
> > > happen, isn't really correct.
> >
> > Yea, and even 'posix stretchy sec' is really a misnomer. POSIX simply
> > counts time without leap seconds. Each second is the same length,
>
> Not at all.
>
> If you use a monotonic timer to sample the POSIX clock before and
> after a leap second, the POSIX clock will appear to have taken twice
> as long as it should to pass the leap second.
>
> Of course, it's worse.  If sampled at _subsecond_ intervals, a POSIX
> clock behaves _erratically_: it spontaneously rewinds itself!
>
> Suppose we have a machine with a monotonic clock that counts SI
> seconds as well as a POSIX clock:
>
> SI monotonicPOSIX
> 123.25  1483228799.00
> 123.50  1483228799.25
> 123.75  1483228799.50  # t0 = boottime + 123.75
> 124.00  1483228799.75
> 124.25  1483228800.00  # leap second begins at 2016-12-31T23:59:60Z
> 124.50  1483228800.25
> 124.75  1483228800.50
> 125.00  1483228800.75  # t1 = boottime + 125.00
> 125.25  1483228800.00  # POSIX clock rewinds at
> 2017-01-01T00:00:00Z!
> 125.50  1483228800.25
> 125.75  1483228800.50  # t2 = boottime + 125.75
> 126.00  1483228800.75
>
> At supersecond resolution, t2 - t0 is a duration of 2 SI seconds, but
> a POSIX clock reports a time difference POSIX(t2) - POSIX(t0) of 1, so
> `POSIX seconds' are not always SI seconds -- it is not the case that
> `each [POSIX] second is the same length', even ignoring physical clock
> sampling error.
>

Right. Except during that brief interval around a leap second, all the
seconds
are the same size. They aren't expanded or contracted by running the clock
at a different frequency that was done between approx 1960-1972 which is
often referred to as the rubber leap second era. It was more on that basis
that
I was objecting to the turn of phrase because that sort of thing isn't
happening.


> And, of course, at subsecond resolution, the POSIX clock rewinds.  The
> monotonic clock correctly has t1 < t2, but POSIX(t1) > POSIX(t2).  And
> this erratic behaviour is much worse than a typical NTP-driven clock
> adjustment at random times, because by design this erratic behaviour
> happens on ~every computer on the planet simultaneously!
>

Yea, if NTP knows about the leap, it can deal with it. The problem as you
say comes in when the stratum 1 servers don't announce the leap second
far enough in advance for the implementations to cope. It then devolves to
the 'when, exactly, do you step the time back' problem since there's a
couple
of choices, unless you have the 'leap smear' ntp servers which do it over

Re: CVS commit: src/lib/libc/time

[Warner Losh]

On Sat, Oct 22, 2022 at 10:55 PM Robert Elz  wrote:

> Date:Sat, 22 Oct 2022 20:17:57 -0600
> From:    Warner Losh 
> Message-ID:  <
> canczdfqhkz0xs7lf6lmjveontc5dgsonons_ug6fzsf30og...@mail.gmail.com>
>
>
>   | On the other hand, adding a caveat that leap seconds don't exist in a
> POSIX
>   | time_t and that's necessarily reflected in the normalization wouldn't
> be
>   | bad.
>
> The problem with doing that is that while we don't install it this
> way, it is possible to install tzdata such that leap seconds do occur
> (despite that not being posix) either unconditionally, or installing
> both and leaving it up to the user by their choice of timezone to use
> (which makes rather a mess).
>

That's true. In the default "UTC system time" clock, leap seconds simply
do no work at all. With the tzdata with leap seconds, they work for a
limited
subset of things, but not quite everything because you can't completely
close the gap due to time_t not having an encoding for them. Having tried
to deploy systems that needed to present a pedantically-correct UTC
time to the outside world shows many hole (most of which self correct
and are mostly right not near leap seconds).

I guess a more accurate way of saying this is that leap seconds simply
aren't reliable, cannot be made reliable, and this affects normalization
in ways too numerous to mention due to the details of the tz files, bugs
in the system, and lack of others to implement them correctly.


> The code works with either set of tzdata files, POSIX stretchy secs,
> or UTC with leap secs - claiming that one doesn't happen, or cannot
> happen, isn't really correct.
>

Yea, and even 'posix stretchy sec' is really a misnomer. POSIX simply
counts time without leap seconds. Each second is the same length,
and it doesn't make them longer or shorter. It just assumes some
ad-hoc, beyond the standard method for synchronization. The quality
of these ad-hoc methods ranges from terrible to halfway-decent, but
none are perfect.

OK. I've got my annual leap seconds rant out of the way. Even 15 years
after shipping these systems, the almost (but not completely) right nature
of how computers implement them still has my knee jerking just a little
too much...

Warner

Re: CVS commit: src/lib/libc/time

[Warner Losh]

On Sat, Oct 22, 2022, 8:05 PM Robert Elz  wrote:

> Date:Sat, 22 Oct 2022 13:42:54 -0400
> From:Jan Schaumann 
> Message-ID:  
>
>   | A full set of examples strikes me as too much here
>
> A full set would be yes, but I think we could handle 3.
> They don't need to be C code examples, just something
> like
> if tm_year==2022 tm_mon==10 tm_mday==19
>tm_hour==23 tm_min==58 tm_sec==17 and tm_dst==-1
>
> and tm_min was incremented as tm_min+=180, and then
> mktime() called upon the result, the struct tm would
> now have tm_min==1 tm_hour==24 and tm_mday==20, with
> tm_isdst 0 or 1 depending upon the local time zone.
> The other fields shown would not be altered in this
> example, the fields of struct tm not show here would
> (tm_wday, ...) would be filled in with appropriate values.
>

That sounds like a good idea...

[Using tm_min rather than tm_sec to avoid needing to include
> caveats about possible leap seconds, which, at least currently,
> could never happen in November, but all of that is too much
> to bother with.]
>

On the other hand, adding a caveat that leap seconds don't exist in a POSIX
time_t and that's necessarily reflected in the normalization wouldn't be
bad. It's a quite common misconception that somehow they do because they
exist in UTC... while you can encode any valid UTC time, they are always
normalized away.

The other examples could be even shorter, no need to repeat
> the final sentence about the other field changes or otherwise.
>
>   | Perhaps:
>   |
>   | This normalization is done in order from tm_sec up to
>   | tm_year,
>
> No, that is what you cannot say, because it is wrong.
>
> We do not always start from tm_sec, and tm_mon is *always*
> normalised (with its possible flow on to tm_year) before
> tm_mday - nothing else makes sense.   tm_year isn't
> "normalized" at all, though it might be adjusted.
>
> But all of this is what we already agreed is too much
> to explain.   And no matter how simple it makes things,
> the man pages cannot (deliberately) lie.
>

Agreed. These nuances are important.

  | possibly leading to cascading values.  That
>   | is, a tm_sec value of e.g., 185 with a tm_min value of
>   | 58 could lead to an increment of tm_min by three, and
>   | thus further incrementing tm_hour by one, and so on.
>
> This is more explaining how it works, which if we do at all,
> we need to do correctly.   That's where a few examples can
> be better, they allow the reader to deduce what probably
> happens, the weird one is there to show that the results
> will not always be what is expected at first glance, but
> that they always are correct.
>
>   | As with most things relating to
>   | time, dates, and calendars, the full details of these
>   | side effects are often non‐obvious, and it may be best
>   | to avoid such scenarios.
>
> And that part is just useless, unless you mean that non-normalised
> values should never be used, perhaps just in some fields (and it
> isn't that anyway, a big enough increment of tm_sec is the same
> as an increment of tm_mday or tm_mon) in which case we should just
> say that.   If not that, then hinting that it is sometimes odd,
> and those cases, which ones we refuse to tell you, should be
> avoided is a complete waste of time.   Which scenarios should be
> avoided?   The answer really is none of them, the answer is
> always correct, it just might not be what the user expected.
>


All good points.

Warner

> kre
>
>

Re: null-terminated vs. nul-terminated

[Warner Losh]

On Tue, Mar 29, 2022, 5:40 AM Greg Troxel  wrote:

>
> "David H. Gutteridge"  writes:
>
> Thanks for the history and it is  all sensible.
>
> > "nul-terminated" and "null-terminated" seemed more common in man pages
> > that originated from historical BSD sources, so, lacking any style
> > guide, I inferred the lowercase "nul" was more "correct" as "BSD style"
> > (excepting modern OpenBSD), even though that looks a bit odd to me. I
> > then examined where "nul-terminated" came from, and found these bulk
> > commits, which imply a standard.
>
> > date: 2005-01-02 18:38:04 +;  author: wiz;
> > Mark up NULL, and replace null by nul where appropriate.
> >
> > date: 2006-10-16 08:48:45 +;  author: wiz;
> > nul/null/NULL cleanup:
> > when talking about characters/bytes, use "nul" and "nul-terminate"
> > when talking about pointers, use "null pointer" or ".Dv NULL"
> >
> > So that seemed to me the established style.
>
> It may have been BSD style, but I think it's wrong to use lowercase for
> an ASCII codepoint.  And therefore it is confusing to people who know
> that the ASCII zero byte is written NUL.
>

FreeBSD has adopted the POSIX language (null terminated) because it mirrors
the standard and the xopen folks have blanket permission to use it in open
source man pages...

Warner

>

Re: null-terminated vs. nul-terminated (was: Re: CVS commit: src/lib/libc/gen)

[Warner Losh]

On Sat, Mar 26, 2022 at 9:53 AM Roland Illig  wrote:

> Am 24.03.2022 um 02:55 schrieb David H. Gutteridge:
> > Module Name:  src
> > Committed By: gutteridge
> > Date: Thu Mar 24 01:55:15 UTC 2022
> >
> > Modified Files:
> >   src/lib/libc/gen: popen.3
> >
> > Log Message:
> > popen.3: minor spelling, grammar, style, and xref tweaks
> >
> >
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.22 -r1.23 src/lib/libc/gen/popen.3
>
> The term "null-terminated string" is quite common when talking about C.
>   In contrast, the word "nul" in "nul-terminated" always reminds me of
> the character abbreviation in ASCII, which has a narrower scope than C.
>   I prefer to keep "null-terminated" here.
>

The standard uses "null-terminated" and "null character" (see Character
Sets section 5.2.1 (from the C2x draft, but this term dates back to C89):
"A byte with all bits set to 0, called the null character, shall exist in
the basic execution character set; it is used to terminate a character
string."
I couldn't find the definition for null-terminated though. This is
different than the NULL #define

Not to be confused with the all zeros ASCII charater, whose mnemonic is
NUL, which is where some pressure to use NUL terminated comes from. I agree
that it's usage is narrower and really only relevant for certain ASCII and
ASCII-derived character sets, which is why the standard chose the spelling
it did.

Since all the 'C' standards[*] use "null-terminated" and "null character",
it's likely best to use that terminology because there is a source of truth
for its definition in case of ambiguity or doubt.

Warner

[*] I've not gone the extra mile and checked to see if K used this
phrase, to be honest.

Re: CVS commit: src/lib/libc/stdlib

[Warner Losh]

On Sat, Feb 12, 2022, 11:52 AM Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:

> > Date: Sun, 13 Feb 2022 05:44:38 +1100
> > from: matthew green 
> >
> > "Roland Illig" writes:
> > > Module Name:src
> > > Committed By:   rillig
> > > Date:   Fri Feb 11 21:36:46 UTC 2022
> > >
> > > Modified Files:
> > > src/lib/libc/stdlib: getenv.c
> > >
> > > Log Message:
> > > libc/getenv: remove trailing whitespace
> > >
> > > No binary change.
> >
> > please avoid purely whitespace changes unless you're
> > also going to be modifying the code itself.
> >
> > (don't back out now.)
>
> I thought we were supposed to _avoid_ mixing whitespace changes and
> functional changes?
>
> (Obviously the solution is to just only ever commit code with perfect
> style to begin with so this is never an issue!  Speaking of which,
> (setq show-trailing-whitespace t) is helpful to avoid this kind of
> mistake up front.  git diff or git add -p will also flag this kind of
> mistake, if you're working in git.  /usr/share/misc/NetBSD.el is also
> helpful for other KNF style.)
>

I thought the rule was don't make purely whitespace changes UNLESS you plan
on making other changes to (or are fixing an oops you just made). If that's
the case, separate the two commits.

Warner

>

Re: CVS commit: src/share/misc

[Warner Losh]

On Sat, Aug 1, 2020, 6:26 PM Luke Mewburn  wrote:

> On 20-08-01 23:07, Taylor R Campbell wrote:
>   | Index: share/misc/style
>   | ===
>   | RCS file: /cvsroot/src/share/misc/style,v
>   | retrieving revision 1.56
>   | diff -p -p -u -r1.56 style
>   | --- share/misc/style1 Aug 2020 02:45:35 -   1.56
>   | +++ share/misc/style1 Aug 2020 22:54:53 -
>   | @@ -241,9 +241,8 @@ main(int argc, char *argv[])
>   | errno = 0;
>   | num = strtol(optarg, , 10);
>   | if (num <= 0 || *ep != '\0' || (errno == ERANGE &&
>   | -   (num == LONG_MAX || num == LONG_MIN)) ) {
>   | +   (num == LONG_MAX || num == LONG_MIN)) )
>   | errx(1, "illegal number -- %s", optarg);
>   | -   }
>   | break;
>
> IMO, that example is a case in where if the style is "minimal braces"
> that's still a good case to retain it. The if condition is across
> multiple lines, and the brakes make it clearer (to me) where the statement
> is.
>
> This all comes down to a matter of style, where some people
> prefer "purple" and some prefer "orange", yet the arguments are
> often claimed to be (by all concerned) as "technical reasons".
>

I thought the only two color choices were green and purple given the Bab 5
heritage of the project...

Warner

Anyway, I haven't got the motivation to bikeshed like this in NetBSD
> anymore.
>
> Luke.
>

Re: CVS commit: src/sys

[Warner Losh]

On Fri, Apr 17, 2020 at 9:02 AM Manuel Bouyer 
wrote:

> On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote:
> >
> > > On Apr 17, 2020, at 7:46 AM, Robert Elz  wrote:
> > >
> > >Date:Fri, 17 Apr 2020 15:37:33 +0200
> > >From:Manuel Bouyer 
> > >Message-ID:  <20200417133733.ga5...@antioche.eu.org>
> > >
> > >  | And that would be a problem for me. I regulary update a single file
> to a
> > >  | specific revision in a source tree.
> > >
> > > Me too - I pull the current sh into NetBSD 8 (and I guess 9 now too,
> > > though I haven't done that yet) and build it there for some people who
> > > like to test and report bugs.
> >
> > The New Hotness (which isn't particularly new, at this point) is to
> create branches and merge what you want into that branch.
>
> Yes, but it's much more work than 'cvs up' in a single directory or against
> a few files.
>

The real new hotness is to use a git mirror to create a branch and then
rebase it. It's no more steps to rebase a branch forward than it is to
update twice...

OK, don't know if it's really the right new hotness, or coldness, or
lukewarm seething, but it's a strategy I've started to use to keep
FreeBSD-specific changes for software that doesn't support it (yet) before
I upstream (or if I upstream, sometimes the upstreams don't want to know).

With NetBSD and updating /bin/sh to the latest on an old branch, I'd think
that would just be creating a branch from netbsd-8, cherry picking the
/bin/sh changes to that branch and then rebasing it forward as the netbsd-8
branch evolves, possibly with cherry-picking new changes as /bin/sh does in
-current. It's more controlled that way, and also allows tweaks to /bin/sh
if it were to become uncompilable as-is for some reason (more likely with
other programs than /bin/sh). It's a little more work, but it's a lot more
flexible.

Warner

Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

[Warner Losh]

On Wed, Mar 11, 2020 at 12:13 AM J. Hannken-Illjes 
wrote:

> On 10. Mar 2020, at 13:37, Santhosh Raju  wrote:
>
> On Tue, Mar 10, 2020 at 7:25 AM Santhosh Raju  wrote:
>
>
> Module Name:src
> Committed By:   fox
> Date:   Mon Mar  9 15:40:50 UTC 2020
>
> Modified Files:
>src/external/cddl/osnet/dist/uts/common/fs/zfs: metaslab.c
>
> Log Message:
> external/cddl/osnet: Fix possible null pointer access.
>
> Detected by UBSan and fixed upstream, pick only the fix from the commit.
>
> Cherry-pick:
> From 928e8ad47d3478a3d5d01f0dd6ae74a9371af65e Mon Sep 17 00:00:00 2001
> From: Serapheim Dimitropoulos 
> Date: Wed, 20 Feb 2019 09:59:57 -0800
> Subject: [PATCH] Introduce auxiliary metaslab histograms
>
> Reviewed by: Paul Dagnelie 
> Reviewed-by: Brian Behlendorf 
> Reviewed by: Matt Ahrens 
> Signed-off-by: Serapheim Dimitropoulos 
> Closes #8358
>
> Reviewed by: kamil@
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.1.1.3 -r1.2 \
>src/external/cddl/osnet/dist/uts/common/fs/zfs/metaslab.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>
> Forgot to add in the commit log, the changes have been pulled in from
> upstream openzfs.
>
>
> https://github.com/openzfs/zfs/commit/928e8ad47d3478a3d5d01f0dd6ae74a9371af65e#diff-9fd6b453f8153161abe0728c449e6505R4386
>
> --
> Santhosh
>
>
> This is NOT our upstream --
>

Regardless of NetBSD's "official" upstream, this is the new OpenZFS
upstream. It has moved off illumos earlier in the year to ZoL which was
restructured to be cross platform. It includes FreeBSD support, though that
flavor of ZFS hasn't been completely merged back into FreeBSD just yet
(there's work in progress to make that happen). Since it's the only real
upstream today, you may need to do some updates to cope with the new ZFS
playing field.

Warner

Re: CVS commit: src/usr.bin/finger

[Warner Losh]

On Sun, Mar 8, 2020, 7:10 PM Luke Mewburn  wrote:

>
> On 20-01-30 23:50, Sevan Janiyan wrote:
>   | Module Name:src
>   | Committed By:   sevan
>   | Date:   Thu Jan 30 23:50:23 UTC 2020
>   |
>   | Modified Files:
>   | src/usr.bin/finger: finger.1
>   |
>   | Log Message:
>   | Drop url which is now invalid, see CSRG archive or mirrors on TUHS.org
> or
>   | svnweb.FreeBSD.org
>
> I think the URL was always invalid because ".ua" is not Australia
> (".au" is), and TUHS is maintained by Warren Toomey in Australia.
>
> Looks like TUHS is now at https://www.tuhs.org or ftp://www.tuhs.org
> but the I can't find a variation the link below any more.
>


Tuhs.org is the best place to send people. Full paths move around over the
years.

Warner


>   |
>   | To generate a diff of this commit:
>   | cvs rdiff -u -r1.19 -r1.20 src/usr.bin/finger/finger.1
>   |
>   | Please note that diffs are not public domain; they are subject to the
>   | copyright notices on the relevant files.
>   |
>
>   | Modified files:
>   |
>   | Index: src/usr.bin/finger/finger.1
>   | diff -u src/usr.bin/finger/finger.1:1.19
> src/usr.bin/finger/finger.1:1.20
>   | @@ -212,5 +212,4 @@ last login data base
>   |  The
>   |  .Nm
>   |  command appeared in
>   | -.Bx 2.0 :
>   | -.Lk ftp://ftp.tuhs.org.ua/PDP-11/Distributions/ucb/2bsd.tar.gz
>   | +.Bx 2.0
>   |
>
>

Re: CVS commit: src/usr.sbin/fstyp

[Warner Losh]

On Sat, Dec 28, 2019, 1:31 AM Tomohiro Kusumi 
wrote:

> 2019年12月28日(土) 5:24 Warner Losh :
> >
> >
> >
> > On Fri, Dec 27, 2019 at 12:45 PM Sevan Janiyan 
> wrote:
> >>
> >> Hi tkusumi,
> >> Thanks for the work you are doing.
> >>
> >> On 27/12/2019 11:06, Tomohiro Kusumi wrote:
> >> > taken-from: FreeBSD
> (freebsd/freebsd@b4d7ad9f787e74e712423def67de8bd76f71943a)
> >>
> >> One minor nit, could you please cite the revision in the svn repo which
> >> is the source of truth and not the readonly git mirror, this is in case
> >> something happens to the mirror and hashes end up changing in the
> future.
> >
> >
> > FreeBSD is planning a conversion to git.
>
> Yes, that's the reason I'm using Git hash here.
> Nowadays I don't use their svn repo at all, so if recording Git hash
> is not appropriate, I'll just note "taken-from: FreeBSD" without any
> specific revision#.
>

It's a silly reason. Svn revision numbers will be preserved in the
conversion process. Git hashes likely won't so this hash may be
unconvertable to anything at all in the future...

Warner

> It's an open question at the moment what happens to the 'beta' readonly
> export we're doing to github. There's a number of technical issues with it
> which make using it for our source of truth difficult on an ongoing basis,
> so there's a real chance the hashes will change for people just grabbing a
> FreeBSD tree...
> >
> > Warner
>

Re: CVS commit: src/usr.sbin/fstyp

[Warner Losh]

On Fri, Dec 27, 2019 at 12:45 PM Sevan Janiyan 
wrote:

> Hi tkusumi,
> Thanks for the work you are doing.
>
> On 27/12/2019 11:06, Tomohiro Kusumi wrote:
> > taken-from: FreeBSD
> (freebsd/freebsd@b4d7ad9f787e74e712423def67de8bd76f71943a)
>
> One minor nit, could you please cite the revision in the svn repo which
> is the source of truth and not the readonly git mirror, this is in case
> something happens to the mirror and hashes end up changing in the future.


FreeBSD is planning a conversion to git. It's an open question at the
moment what happens to the 'beta' readonly export we're doing to github.
There's a number of technical issues with it which make using it for our
source of truth difficult on an ongoing basis, so there's a real chance the
hashes will change for people just grabbing a FreeBSD tree...

Warner

Re: CVS commit: src/sys/sys

[Warner Losh]

On Mon, Dec 23, 2019, 2:37 PM Kamil Rytarowski  wrote:

> On 23.12.2019 18:14, Greg Troxel wrote:
> > Warner Losh  writes:
> >
> >> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt
> the
> >> wumpus' for all the autoconfig scripts that suddenly thought they were
> >> configuring for FreeBSD 1.0.
> >>
> >> If you can arrange it, it might make sense to do a pkgsrc run on an
> >> experimental system that has the version as 10.0 rather than 9.9.xx
> before
> >> committing to a schedule given the experience of your sister BSD
> project.
> >
> > Thanks, that's a really good point.
> >
>
> This issue is well known. Once we will branch -10 we will test it in
> HEAD and -10 concurrently.
>
> On the other hand, clang10 broke only a single piece of software that I
> build (nodejs).
>


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

Warner

>

Re: CVS commit: src/sys/sys

[Warner Losh]

On Mon, Dec 23, 2019 at 9:33 AM Greg Troxel  wrote:

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

Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt the
wumpus' for all the autoconfig scripts that suddenly thought they were
configuring for FreeBSD 1.0.

If you can arrange it, it might make sense to do a pkgsrc run on an
experimental system that has the version as 10.0 rather than 9.9.xx before
committing to a schedule given the experience of your sister BSD project.

Warner

Re: CVS commit: src

[Warner Losh]

On Wed, Dec 18, 2019, 10:45 AM  wrote:

> On Wed, Dec 18, 2019 at 06:47:44AM -0500, Christos Zoulas wrote:
> > While there was no discussion, it is more efficient to have the
> discussion
> > whether we should put it back or not (instead of putting it back first
> and
> > having the discussion). Of course we should fix the build first since it
> seems
> > to be broken.
> >
> > The reality of the situation is that the syscall race has been there for
> months
> > and nobody has taken responsibility to fix it. The code is in version
> control,
> > so someone should fix it first and then we can discuss if we should
> bring it
> > back.
>
>
> I'd like to also publicly object to the removal of the code from bmake
> (I responded privately at first).
> FreeBSD has filemon, and I suspect it has more acceptance there, but
> maxv stated he will propose it.
> Sharing the code with FreeBSD is more than worth the 200 unused-by-us
> lines of code, and it's already optional.
> No rush though. Let's wait to see what they say.
>

FreeBSD definitely uses filemon in our build system... I've not looked at
the details of this removal to know if that messes things up for us or not.

Warner

I have no objections to removing the kernel module.
>

Re: Leak Sanitizer - how to suppress leaks

[Warner Losh]

On Thu, Sep 12, 2019, 7:24 PM Simon Burge  wrote:

> Kamil Rytarowski wrote:
>
> > I will revert it, but I am looking for a more generic approach.
> >
> > How about adding ifdef __NO_LEAKS like:
> >
> > #ifdef __NO_LEAKS
> > free(3)?
> > #endif
> >
> > And in lsan/asan/valgrind/etc checks use -D__NO_LEAKS.
>
> Sorry if I'm missing something that has been already explained,
> but why (practically) do we care about memory leaks for a utility
> that is about to finish?
>
> If we're doing some ugly #ifdef dance only when running the
> sanitiser(s), then we haven't actually done anything to "fix"
> the leak in the installed binaries so it seems that there was
> no practical problem that we were trying to solve in the first
> place.
>

When multiple people are doing leak busting, maybe over years, they
eliminate many false positives so you can focus on the real issues w/o a
run time penalty. Especially something in the library that comes up
often... otherwise they get in the way of making progress...

Warner

Cheers,
> Simon.
>

Re: CVS commit: src

[Warner Losh]

On Mon, Sep 2, 2019, 1:53 AM Masanobu SAITOH  wrote:

> Background:
>
>  In August 2014, lower-cased filename's files are added in the following
> commit:
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/radeon?id=f333bd435c0b6745cbc4fae3326725d77bf57c82
>
> This commit says those files use the new header format. The radeon's drmkms
> driver basically try to use lower case's file first and then try the upper
> case's one. [*1]
>
> After the above commit, usually lower-case's files have been added and
> updated.
> Two exceptions:
>
> TAHITI_vce.bin (only uppercase exists)
> BONAIRE_uvd.bin (both upper and lowe exist and both updated)
>
> Some old (upper-case'd) firmware might be maintained anymore.
>
> Now:
> Number of upper-cased filename's files: 158
> Number of lower-cased filename's files: 66
> Both lower-cased and upper-cased: 65
>
> kaveri_mec2.bin has only lowercase one.
> (see also:
> http://mail-index.netbsd.org/tech-x11/2019/04/07/msg001953.html)
>
> [*1] For _mc*.bin:
> 1st try: lower-case _mc.bin
> 2nd try: upper-case _mc2.bin
> 3rd try: upper-case _mc.bin
>
> So, options are:
>
> a) Remove duplicated upper-cased files.
>
>pros: Simple. It's not required to modify radeon driver itself.
>  It also works with new kernel with old filesysysm.
>cons: If the driver failed to load the lower cased firmware,
>  driver can't read the upper-cased firmware.
>
> b) Rename upper-case'd file to another name e.g.: foo_bar_old.bin
>
>pros: It can be keep the driver's behavior the same as linux's.
>cons: We have to modify many files and lines.
>  If we support new kernel + old filesystem, we should
> modify
>  the driver to load FOO_BAR.bin first and then
> FOO_BAR_old.bin.
>
> c) keep the current status as it is.
>
>pros: Any additional work is not required.
>cons: have trouble on case-insensitive file system.
>
> d) Any other options.
>

Option A is the best. There is no need in this case to keep the files that
I've seen.

If we do need them, then adding a directory for the old names / format
seems the best way forward (both in tree and new install location). Add the
new directory to the load path. MacOS builds are fine.

Warner


> --
> ---
> SAITOH Masanobu (msai...@execsw.org
>  msai...@netbsd.org)
>

Re: CVS commit: src/sys/kern

[Warner Losh]

>
> No, I committed a set of changes that were agreed upon months ago. It is
> fine to reconsider the changes in retrospect, but meanwhile, you need to
> quit fucking around with these accusations.
>

That's a super crappy attitude. The changes broke things that weren't
contemplated when the agreement was made. Did the changes break things?
Yes. They did. That's a bug, not matter what was agreed to.

Warner

Re: CVS commit: src/sys/arch/x86/x86

[Warner Losh]

On Mon, Oct 2, 2017 at 4:09 PM, Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:

> > Date: Mon, 2 Oct 2017 21:42:11 +0200
> > From: Joerg Sonnenberger 
> >
> > On Mon, Oct 02, 2017 at 07:23:16PM +, Maxime Villard wrote:
> > > Add a machdep.tsc_user_enable sysctl, to enable/disable the rdtsc
> > > instruction in usermode. It defaults to enabled.
> >
> > Do we really need this change? I've said it before, I consider this a
> > really stupid idea and effectively useless complexity. rdtsc is not
> > necessary for precision measurement as long as an attacker is willing to
> > waste CPU time, i.e. having one core spinning incrementing a counter and
> > reading that one of a second core will give fairly accurate measurements
> > as long as both cores are near each other. It's normally not that
> > difficult to ensure that.
>
> Concur.  The way to thwart timing side channel attacks is not to
> pretend attackers don't have stop-watches; it's to avoid the variable
> timing that creates the side channels in the first place.
>

Even if you don't have the ability to change the defective hardware?

Why should I provide an attacker a stop watch? I want him/her to build
their own that has the potential to be accurate enough, but is necessarily
less accurate than the one I'm denying them access to.

Warner

Re: CVS commit: src/sys/arch/x86/x86

[Warner Losh]

On Mon, Oct 2, 2017 at 4:43 PM, Joerg Sonnenberger <jo...@bec.de> wrote:

> On Mon, Oct 02, 2017 at 04:25:34PM -0600, Warner Losh wrote:
> > Even if you don't have the ability to change the defective hardware?
>
> The hardware is not defective. We are not talking about variable timing
> for basic arithmetic operations based on the operand value. Outside
> maybe division, that could be considered a hardware bug. A believe
> that timing of complex operations like memory access should be constant
> is IMO completely misguided for general purpose computing. Outside a
> very narrow range of hardware, it is absurd to even consider it.


On other processors, the issues are needing to do timing attacks due to
flaws in the hardware. For x86, no such bugs are known. History suggests it
is unwise to take the absence of evidence to be evidence of absence

> Why should I provide an attacker a stop watch? I want him/her to build
> > their own that has the potential to be accurate enough, but is
> necessarily
> > less accurate than the one I'm denying them access to.
>
> It has been said before: this is breaking completely valid use cases
> without actually fixing anything. It is security by obscurity at its
> best.
>

I'm not advocating turning it off by default. I'm saying that it would be
useful to allow removal of access to the counter as a mitigation technique,
perhaps while waiting for a more general / complete fix for a kernel bug to
be available.

Warner

Re: CVS commit: src/usr.bin/sed

[Warner Losh]

 On Mar 1, 2015, at 8:45 AM, Aleksej Saushev a...@inbox.ru wrote:
 
 chris...@astron.com (Christos Zoulas) writes:
 
 In article 20150228215653.f2f0...@cvs.netbsd.org,
 Aleksej Saushev source-changes-d@NetBSD.org wrote:
 -=-=-=-=-=-
 
 Module Name:src
 Committed By:   asau
 Date:   Sat Feb 28 21:56:53 UTC 2015
 
 Modified Files:
 src/usr.bin/sed: compile.c extern.h main.c process.c
 
 Log Message:
 Improve modularity of sed source:
 - move program source input subroutines into compiler part;
 - move data I/O subroutines into processor part.
 
 It there a good reason for that? We try to keep it synced with FreeBSD..
 
 It makes code a lot cleaner and allows embedding it.
 
 If that's problem, I'll submit changes to FreeBSD.

Sounds like a good idea to me…

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CVS commit: src/share/mk

[Warner Losh]

On Jan 24, 2014, at 2:16 AM, Izumi Tsutsui wrote:

 Sorry that I was lost, but I still believe that
 creating-directories-as-make-target is to avoid.
 
 Do you have any suggestion without boring work to rename all
 #include machine/foo.h lines and expand the machine path
 in MI files to ${MACHINE}/include?
 
 Creating symlinks for stand programs has been annoying for me
 for 15 years, but see no alternative.

You could install them all into /usr/include/arch and make all the machine/*.h 
files look like:

#include arch/ # MACHINE # /foo.h

which could be generated from a master list or globular expansion of 
arch/*/include (just to get the list, any individual arch/machine would be free 
to not worry about them). OF course, this solved the installed problem, and not 
the symlinks created by config(1), but I'm guessing that's not quite so 
irritating...

Warner

Re: CVS commit: src/usr.sbin/rtsold

[Warner Losh]

On May 24, 2013, at 12:37 PM, Robert Elz wrote:

Date:Fri, 24 May 2013 16:47:08 +
From:David Holland dholland-sourcechan...@netbsd.org
Message-ID:  20130524164708.ga...@netbsd.org
 
  |  : -The default interval for router advertisements, which is on the order 
 of 10
  |  : +The default interval for router advertisements, which is in the order 
 of 10
  | 
  | ...it should be on
 
 Actually, I think it should be of.
 
 in when it relates to orders would be used for the kind of order where
 a follows b follows c - those are in the order of ...
 
 on when it relates to orders would refer to something that is written,
 and there may be a note, on the order, that X should be added, or ...
 
 of when it relates to orders comes to comparisons, and is the variant
 that is meant here, it means approximately 10 minutes, or of the order
 of 10 minutes.

In the US we use on for what you've said you'd think you'd use of. on the 
order of 10 minutes means about 10 minutes.

I think the original text was correct.

But it would be perhaps more international to say which should be 
approximately 10.

Warner

Re: CVS commit: src/sys/kern

[Warner Losh]

On Jan 30, 2013, at 1:07 AM, David Laight wrote:

 On Tue, Jan 29, 2013 at 11:00:31PM +, Lars Heidieker wrote:
 Module Name: src
 Committed By:para
 Date:Tue Jan 29 23:00:31 UTC 2013
 
 Modified Files:
  src/sys/kern: kern_sysctl.c
 
 Log Message:
 fix the sysctl_setup_func typedef
 
 -typedef void (*sysctl_setup_func)(struct sysctllog **);
 +typedef void sysctl_setup_func(struct sysctllog **);
 
 IIRC you are only supposed to be able to typedef pointers to functions.

It is totally legal, and has been for three decades or so...

 The extra level of indirection (that caused the horrid casting)
 is elsewhere.
 (I wasn't at all sure the previous 'fix' was right.)
 
   David
 
 -- 
 David Laight: da...@l8s.co.uk

Re: CVS commit: src/lib/libterminfo

[Warner Losh]

On Jan 25, 2013, at 4:05 PM, David Laight wrote:

 On Fri, Jan 25, 2013 at 12:30:06PM +, Roy Marples wrote:
 Module Name: src
 Committed By:roy
 Date:Fri Jan 25 12:30:06 UTC 2013
 
 Modified Files:
  src/lib/libterminfo: terminfo.3 tparm.c
 
 Log Message:
 For platforms where we cannot fit a char * into a long, return NULL
 and set errno to ENOTSUPP.
 
 Could the 'char *' pointers be replaced with indexes into an array?

How many platforms is this actually the case on?

Warner

Re: CVS commit: src/usr.sbin/envstat

[Warner Losh]

On Dec 13, 2012, at 4:30 PM, John Nemeth wrote:

 On Mar 31, 12:00am, Paul Goyette wrote:
 }
 }  Module Name:src
 }  Committed By:   christos
 }  Date:   Thu Dec 13 19:31:25 UTC 2012
 } 
 }  Modified Files:
 }  src/usr.sbin/envstat: envstat.c
 } 
 }  Log Message:
 }  PR/47316: Henning Petersen: Memory leak in envstat with config file.
 } 
 } While we're making sure to free() things, should we not also defend 
 } against memory leaks in the case where an option is used more than once?
 } 
 } RCS file: /cvsroot/src/usr.sbin/envstat/envstat.c,v
 } retrieving revision 1.92
 } diff -u -p -r1.92 envstat.c
 } --- envstat.c   13 Dec 2012 19:31:25 -  1.92
 } +++ envstat.c   13 Dec 2012 19:47:44 -
 } @@ -132,6 +132,7 @@ int main(int argc, char **argv)
 } while ((c = getopt(argc, argv, c:Dd:fIi:klrSs:Tw:Wx)) != -1) {
 } switch (c) {
 } case 'c':   /* configuration file */
 } +   free(configfile);
 } configfile = strdup(optarg);
 } if (configfile == NULL)
 } err(EXIT_FAILURE, strdup);
 
 If you're going to be this paranoid, you should make sure that
 you're not passing NULL to free(3).  That can blow up on some systems.
 Anyways, I see that Christos has already fixed this in a different way,
 so it doesn't really matter.

free(NULL); has been required to be a nop since c89.

Warner

Re: CVS commit: src/usr.bin/pkill

[Warner Losh]

On Nov 21, 2012, at 1:55 PM, David Laight wrote:

 On Wed, Nov 21, 2012 at 01:36:01PM -0700, Warner Losh wrote:
 Is pkill() guaranteed to do an atomic traversal of the process list?
 So it will kill something that keeps using fork() to change its pid.
 
 I don't think our libkvm offers that.
 
 How could you guarantee this short of moving this into the kernel
 so you could do all the comparisons while keeping all forks from happening?
 
 You probably can't ...
 Even in the kernel it might be 'interesting'.

Agreed.  It was a leading question.  Even with help from the kernel, it would 
be difficult

Warner

Re: CVS commit: src/games/adventure

[Warner Losh]

On Oct 12, 2012, at 7:06 AM, Aleksej Saushev wrote:

 David A. Holland dholl...@netbsd.org
 writes:
 
 Module Name: src
 Committed By:dholland
 Date:Fri Oct 12 10:38:53 UTC 2012
 
 Modified Files:
  src/games/adventure: wizard.c
 
 Log Message:
 Pass -Wstrict-overflow.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.14 -r1.15 src/games/adventure/wizard.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 
 
 Modified files:
 
 
 Index: src/games/adventure/wizard.c
 diff -u src/games/adventure/wizard.c:1.14 src/games/adventure/wizard.c:1.15
 --- src/games/adventure/wizard.c:1.14Tue Aug 25 06:56:52 2009
 +++ src/games/adventure/wizard.c Fri Oct 12 10:38:53 2012
 
 ...
 
 @@ -130,19 +130,19 @@ wizard(void)
 void
 ciao(void)
 {
 -char   *c;
 -charfname[80];
 +char fname[80];
 +size_t pos;
 
  printf(What would you like to call the saved version?\n);
  /* XXX - should use fgetln to avoid arbitrary limit */
 -for (c = fname; c  fname + sizeof fname - 1; c++) {
 +for (pos = 0; pos  sizeof(fname - 1); pos++) {
 
 sizeof(fname-1)??
 
 (Isn't PATH_MAX better approximation to file name limit?)

and sizeof(fname - 1) is likely 4 or 8 since fname - 1 is a pointer and no 
longer an array.  I think this is a typo for sizeof(fname) - 1.

  int ch;
  ch = getchar();
  if (ch == '\n' || ch == EOF)
  break;
 -*c = ch;
 +fname[pos] = ch;
  }
 -*c = 0;
 +fname[pos] = '\0';
  if (save(fname) != 0)
  return; /* Save failed */
  printf(To resume, say \adventure %s\.\n, fname);
 
 -- 
 HE CE3OH...
 

Re: CVS commit: src/sys/dev/scsipi

[Warner Losh]

On Apr 19, 2012, at 6:03 PM, matthew green wrote:
 But that's a problem with autoconf not dealing with non-MPSAFE drivers,
 not the driver themselve (they were working before the MP changes, they
 should continue to work as-is). If you want autoconf to not run
 under the KERNEL_LOCK when not needed, then is has to be extended so that
 MPSAFE drivers can register themselves as MPSAFE, so that non-MPSAFE
 drivers are still called with KERNEL_LOCK.
 
 it seems the wrong answer to me.  instead of fixing the one or
 two drivers you've found problems in, you want to add more
 infrastructure (IMO clutter) to the system and patch all the
 drivers that *are* ok.  considering that this problem is
 very specific to scsipi, i don't think that is a viable
 solution.

FreeBSD started out with MPSAFE and then went to NEEDS_GIANT as flags for the 
drivers.  I'm with Matthew: patch the drivers that are broken (or not known to 
be safe) and then you have a convenient thing to grep for when you want to 
expand the drivers that are safe.  Much better that way, and it turned out to 
be a big win in FreeBSD when we went from opt-in MPSAFE to out-out...

Warner

Re: CVS commit: src/lib/libarch/alpha

[Warner Losh]

On Mar 22, 2012, at 8:43 AM, Joerg Sonnenberger wrote:

 On Thu, Mar 22, 2012 at 02:51:08PM +0100, Havard Eidnes wrote:
 IMHO, as long as lint is capable of helping us spot actual
 problems, adding a few of these sorts of constrcucts seems like a
 small price to pay.
 
 It doesn't. From what I see, the signal to noise ratio of lint is
 completely inacceptable and for that very reason, uglifying the code
 with questionable constructs is not acceptable. Even worse, changing
 code for undefined/misdefined behavior of KR (!) is simply wrong.
 ISO C90 is now 22 years old. Traditional C is irrelevant.

When was the last time that NetBSD could be compiled with a KR compiler?  1995?

Warner

Re: CVS commit: src/lib/libc

[Warner Losh]

On Mar 3, 2012, at 5:55 PM, David Holland wrote:

 On Thu, Mar 01, 2012 at 11:14:16AM -0700, Warner Losh wrote:
 Maybe somebody can look at a full pkgsrc build to see how many
 instances of gets are in it?
 
 Given the way bulk builds work, and various logistical reasons that is
 unlikely to change, the only practical way to check this is to remove
 gets locally before doing a build.
 
 Perhaps I'll do this. Any such program is broken and needs to be
 patched. Your example is unpersuasive.

So there's no way to troll through the build binaries for references to gets, 
at least in the dynamically linked binaries?  That's unfortunate.

My example was a place where it was completely safe to use.  I offered only to 
counter those that said it is never safe, which is factually untrue.

But given the extreme ease with which it is unsafe to use, I'm with the 'get it 
out' crowd, but only if it doesn't provoke wide-spread chaos.  without data, it 
is hard to say for sure the level of chaos.

Warner

Re: CVS commit: src/doc

[Warner Losh]

On Mar 2, 2012, at 12:41 AM, Alan Barrett wrote:

 On Fri, 02 Mar 2012, Jukka Ruohonen wrote:
 tzcode2012b and tzdata2012b ahve been released.
 We have updated to tzdata2012b.
 
 What was the resolution with the patent issues and whatnot?
 
 The lawsuit was withdrawn after it became obvious that the 
 plaintiffs had no valid case.  The EFF got involved with the 
 defence, and here's their collection of links to relevant 
 documents:  https://www.eff.org/cases/astrolabe-v-olson.

And there were never any patent issues.  It was a bad copyright case.

Warner

Re: CVS commit: src/lib/libc

[Warner Losh]

On Mar 1, 2012, at 10:58 AM, Izumi Tsutsui wrote:

 Again, how can you support/control/update third party products 
 not to use deprecated functions?  Our libc is designed for 
 NetBSD?
 
 You can't make them not use deprecated functions, but I think you 
 can tell them to link with libdeprecated, or to add -DI_WANT_GETS 
 to CFLAGS.
 
 We could *tell* them, but no lazy third parties would bother to add
 extra configure checks for paranoiac non C89 compliant environment.

Let's gratuitously break third parties because one cannot think of a good way 
to use gets.

I hit warnings on some package years ago that did use gets 100% safely because 
it was used in a pipeline where the produce never produced (and could never 
produce) strings longer than the consumer had buffer space for.  The original 
author demurred when I sent (trivial) patches to fix the receiver to use fgets 
instead.  He insisted he had better things to do with his time than to cope 
with the paranoid and complained that strcpy was next since it could be used 
unsafely.  Rather than argue, I just got on with my life and even forgot the 
name of the package that had these warnings...

Maybe somebody can look at a full pkgsrc build to see how many instances of 
gets are in it?

Warner

Re: CVS commit: src/sys/kern

[Warner Losh]

On Jan 31, 2012, at 3:53 PM, Alexander Nasonov wrote:
 David Laight wrote:
 I don't believe there is a problem using m[0], just m[non-constant-expr].
 
 Practically speaking, m[0] is not a problem but the standard says
 
 ... to the structure member (designated by member-designator), ...
 ^^
 
 OTOH 'sizeof (s *)0-m[0]' might be deemed invalid (because it has
 an inferred dereference of NULL.
 
 Oh yes. I can change it to:
 
 extern void *foo(void);
 
 and then sizeof(((s *)foo())-m[0]) but NULL should work too.
 
 So, if we reached a consensus on this, where should I add the macro?

There's no NULL dereference, so it is fine (completely standards conforming).  
The sizeof operator is a compile time construct that evaluates its argument for 
its type only, so no dereference is happening, so any value for the pointer is 
OK.  In the absence of a local variable, 0 is just as valid as anything else.

Warner

Re: CVS commit: src/lib/libperfuse

[Warner Losh]

On Dec 28, 2011, at 8:40 PM, matthew green wrote:
   - time_t can be a floating point type

For my information, have there ever been any systems that represent time_t as a 
float?

Warner

Re: CVS commit: src/sys/arch/x86/x86

[Warner Losh]

On Oct 18, 2011, at 4:39 AM, Jared McNeill wrote:
 I would argue that any manually loaded module shouldn't be autounloaded. What 
 do you think about flagging modules as autoloaded and only autounloading the 
 autoloaded ones?

If I manually load a dozen drivers at boot because I have a dozen different 
boards with different devices.  I'd kinda like the system to automatically 
figure out what isn't needed and unload those drivers.

Warner

 On Tue, 18 Oct 2011, Jukka Ruohonen wrote:
 
 On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote:
 Am 18.10.11 06:27, schrieb Jukka Ruohonen:
 On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote:
 Module Name:  src
 Committed By: jmcneill
 Date: Tue Oct 18 00:07:45 UTC 2011
 
 Modified Files:
   src/sys/arch/x86/x86: vmt.c
 
 Log Message:
 don't allow module autounload
 
 I wonder should autounloading be prohibited for all driver-class modules?
 
 Why?  When the parent goes away, why not autounload a driver?
 
 I am not sure. But have we thought about all the consequences and corner-
 cases? Unloading happens while modifying hardware state? Deferred calls
 in the drivers? And so on? To me it also seems that if I manually load
 a driver-module, I expect it to stay loaded until I unload it.
 
 - Jukka.
 
 
 
 

Re: CVS commit: src/sys/arch/x86/x86

[Warner Losh]

On Oct 18, 2011, at 9:28 AM, Jukka Ruohonen wrote:

 On Tue, Oct 18, 2011 at 08:49:39AM -0600, Warner Losh wrote:
 
 On Oct 18, 2011, at 4:39 AM, Jared McNeill wrote:
 I would argue that any manually loaded module shouldn't be autounloaded. 
 What do you think about flagging modules as autoloaded and only 
 autounloading the autoloaded ones?
 
 If I manually load a dozen drivers at boot because I have a dozen
 different boards with different devices.  I'd kinda like the system to
 automatically figure out what isn't needed and unload those drivers.
 
 The general idea here probably is that you shouldn't actually load manually
 all those drivers, but the system should be able to autoload modules specific
 to your hardware. But we are not there yet. And AFAIR, neither is FreeBSD.

That's true.  It is a hard problem that people have been working around by 
manually loading things. :)

Warner

Re: CVS commit: src/sys/dev/ata

[Warner Losh]

On Oct 16, 2011, at 9:25 PM, John Nemeth wrote:

 On Feb 25,  1:28pm, Wolfgang Solfrank wrote:
 } Jonathan A. Kollasch schrieb:
 }  On Wed, Oct 05, 2011 at 10:25:52AM +0200, Manuel Bouyer wrote:
 }  On Wed, Oct 05, 2011 at 03:40:18AM +, Jonathan A. Kollasch wrote:
 }  Module Name:src
 }  Committed By:   jakllsch
 }  Date:   Wed Oct  5 03:40:18 UTC 2011
 } 
 }  Modified Files:
 }  src/sys/dev/ata: wd.c
 } 
 }  Log Message:
 }  Limit wd(4) transfers to 128 (512-byte) logical sectors, as the 
 traditional
 }  MAXPHYS value has for at least the past decade.
 } 
 }  We should be able to go safely up to 256 sectors. Anything larger 
 requires
 }  LBA48, which is not supported by some controllers.
 } 
 }  Do we know how a real ST506 or similar ancient drive would respond
 }  to such a command?
 } 
 } The ST506 was only a disk drive with no embedded controller logic.
 } So it wouldn't respond to such a command at all, as it doesn't even see it.
 } The command interface, after which the original ATA interface was modelled,
 } was that of the WD1010 disk controller, to which this and similar drives
 } would attach.  You would tell the controller the cylinder/head/sector
 
 And, I very much doubt there were any PCI versions of these
 controllers since IDE came out well before the end of the ISA era.
 Worrying about drives that old is pretty much pointless.  Even if you
 could find one, it is very likely to be non-functional (these weren't
 exactly high quality devices).

You can still buy ESDI devices (that are compatible with the ST506 interface).  
Ebay has them from $35 to $535!  Sizes up to 750MB.

I was able to find ISA and Micro Channel ESDI cards.  I didn't see EISA or PCI 
ones either on Ebay or Google...

So I think you may be right about PCI.  IIRC, the only machines that had these 
were 386 boxes that weren't lucky enough to have IDE (the frankenstein machines 
of the time, since by then multi-function cards with IDE were the common 
solution) and some of the 68k early home machines (Atari and Amiga maybe) and 
sun 3's.

Warner

Re: CVS commit: src/lib/libm/man

[Warner Losh]

On Sep 12, 2011, at 1:09 PM, Jukka Ruohonen wrote:

 On Mon, Sep 12, 2011 at 08:00:53PM +0200, Joerg Sonnenberger wrote:
 On Mon, Sep 12, 2011 at 02:44:27PM +, Jukka Ruohonen wrote:
 Module Name:src
 Committed By:   jruoho
 Date:   Mon Sep 12 14:44:27 UTC 2011
 
 Modified Files:
 src/lib/libm/man: ldexp.3
 
 Log Message:
 Update and improve, and note that the long double variant is not supported.
 
 Can we please *not* add such notes? They don't really add value, the
 lack of a long double prototype at the beginning of the man page is
 indicator enough. They do add just another thing to keep track of when
 adding the support though.
 
 Fair enough. But I think it is a BUG worth mentioning when an operating
 system does not support standard C.

Then create a bunch of MLINKS to a generic 'This function isn't supported' 
page.  Since the implementors would need to create a real man page or real 
link, this seems to be to be less likely to cause confusion than notes 
everywhere that grow stale.

Warner

Re: CVS commit: src

[Warner Losh]

On Sep 2, 2011, at 11:09 AM, David Laight wrote:

 On Thu, Sep 01, 2011 at 08:19:07AM +0100, Iain Hibbert wrote:
 On Wed, 31 Aug 2011, Warner Losh wrote:
 
 In the absence of both the prototype and a cast, NULL (which can be 0)
 will be passed as an int, not as a pointer.
 
 NetBSD C headers define NULL as ((void *)0), and our Makefiles use -Wall
 (includes -Wimplicit-function-declaration) to avoid such situations..
 
 ISTR that ansi C (or some recent version of it) does require that
 NULL be a pointer constant - so that it gets passed correctly to
 varargs functions that expect a data pointer.

C89 and C99 don't require this.  #define NULL 0 is a conforming definition.

C1X draft N1570 still has 6.3.2.3 An integer constant expression with the 
value 0, or such an expression cast to type void *, is called a null pointer 
constant. and 7.19 The macros are NULL which expands to an 
implementation-defined null pointer constant which means #define NULL 0 is 
still a conforming definition.

C++'s new standard is different though.

 Without function prototypes this is a bigger problem, especially
 since (char *)0 isn't a useful definition!
 This is where 'lint' comes in handy, since it (effectively) checked
 that args matched the inferred prototype ...
 
   David
 
 -- 
 David Laight: da...@l8s.co.uk
 
 

Re: CVS commit: src

[Warner Losh]

In the absence of both the prototype and a cast, NULL (which can be 0) will be 
passed as an int, not as a pointer.  These need not be the same size, leading 
to a situation where the termination of the list will not be guaranteed if 
there's stack garbage that is non-zero in the other half of the pointer.

The whole issue of defining NULL to be 0 or (void *)0 can be debated.  Each 
definition catches some class of bugs, while letting other classes of bugs 
through.  Both definitions are 100% standards compliant for C.

Given that NetBSD's charter is to create portable code, reverting the variadic 
function argument cast removal seems the most portable thing to do.

Warner

On Aug 31, 2011, at 7:03 PM, David Young wrote:

 On Thu, Sep 01, 2011 at 03:47:29AM +0400, Valeriy E. Ushakov wrote:
 On Thu, Sep 01, 2011 at 01:24:12 +0200, Joerg Sonnenberger wrote:
 
 Please revert this. It is incorrect at least for execl and other
 variadic functions.
 
 What Joerg said.  I know, Xenix 286 is, fortunately, no longer with
 us, but I learned its lessons the hard way :)
 
 Joerg, Valeriy,
 
 Please explain your objection.
 
 Dave
 
 -- 
 David Young OJC Technologies
 dyo...@ojctech.com  Urbana, IL * (217) 344-0444 x24
 
 

Re: CVS commit: src/sys/sys

[Warner Losh]

On 03/09/2011 15:01, Antti Kantee wrote:

On Wed Mar 09 2011 at 13:45:37 -0800, Matt Thomas wrote:

On Mar 9, 2011, at 1:14 PM, matthew green wrote:


Module Name:src
Committed By:   pooka
Date:   Wed Mar  9 19:02:04 UTC 2011

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

Log Message:
Bump version for new quota code -- even if ABIs didn't change, it's
still a major feature.

we haven't done this in the past and now i have to rebuild tools and
my module dirs are out of date again.

Sigh.  param.h is not supposed to reflect features changes only ABI
incompatibilities.

are you worried we going to run out of numbers tomorrow?

How else should one know the new quotactl is present?  running awk on
the headers?  i could understand whineage if we had the ever-elusive
stable kernel ABI, but then we'd have some other method of conveying
that information, right?


You can 'piggy back' it on the next real bump.  There will be a small 
period of time where the feature is, in fact, on the system, but this 
will likely give you sufficient fidelity to know for sure.  After all, 
since this was a separate commit, the window already existed...


Warner

Warner

Re: CVS commit: src

[Warner Losh]

On 01/28/2011 02:05, Izumi Tsutsui wrote:

Out of curiosity, was there any thought is adding this to evbmips
instead of getting its own top-level arch subdir?

emips already has native bootloader and src/distrib files,
so it's enough reason to have own port dir.


to the PowerPC Virtex that lives in arch/evbppc/virtex.

BTW evbppc has 405 vs oea issue in module.

evb* method is used for boards/appliances that have
less man power and few variants, I think.


While it avoids clutter, it also tends to bury the lead as it were.  
It is harder to know what NetBSD supports and eaiser to pass it by...


Warner

Re: Changes made with too little discussion

[Warner Losh]

On 01/19/2011 03:13, haad wrote:

On Wed, Jan 19, 2011 at 10:31 AM, Alan Barretta...@cequrux.com  wrote:

On Tue, 18 Jan 2011, Jukka Ruohonen wrote:

On Tue, Jan 18, 2011 at 11:34:23AM +1100, Simon Burge wrote:

Why was this removed when there was an active discussion about removing
it where no concensus was reached?  This sort of thing where commis
occur before a discussion is finished seems to be occurring more and
more often.

I don't care much about /usr/share/misc/operator, but I do care about
people making changes without discussion, or making changes with too
little discussion, or making changes that go against the consensus of
the discussion.

I would like to see this change reverted, becasue it was made with
too little discussion.


Maybe because the whole tech-userlevel@ mailing list has become
poisonous?  I know several people who abstain from posting anything to
the list because of the nature of the list and these discussions.

If you are not willing to discuss changes, or pay attention to other
people's opinions, then you are part of the problem.

You don't have to agree with everybody, but you do need to pay attention
to the discussion.  If no clear consensus emerges, or if the consensus
is opposite from your preferred outcome, then you may appeal to core to
make a decision.

Let me say it this way, if will will spent months in clueless
discussion about thinks like remove misc/operator we will not do any
real work.


Then maybe it is a dumb-ass idea.  I'm sorry to be blunt, but if you 
propose something that will have a month of discussion for something 
trivial, then you are doing it wrong.

e.g. Lua it took one year to discuss everything and it was major PITA
for almost everyone.


Again, maybe it was a dumb idea?  Maybe it was poorly communicated?  
Either way, using this as an example might prove the point: you have to 
gather consensus for change and if you try to force it, then you are 
doing it wrong.

We need some proper way how to evaluate changes, discussion about them
is clearly  not good way. Because most of best developers are not
talking in those never ending mail threads. In practice most active
never ending mail writers contribute very small or zero amount of
code. I really don't think that their opinion should be taken serious.
If they really want to have NetBSD done by their way they should start
contributing, just talking is not going to fix anything.

E.G. Example scenario Dev A wants to add new feature, software
whatever he spent his time on it, developing, testing preparing and
sends patch to tech-userlevel@ where it starts never ending discussion
about it how it slows build on 20years old vax(replace with anything
with  128Mb ram). After few weeks of waiting Dev A doesn't have
attitude to work on his patch anymore and he is totally pissed of by
trying to explain that we really need to move forward. In the result
we will lost (maybe good maybe wrong patch), contributing developer
and onlyone who wins are those who a priori hates any change.

Truly I haven't seen any discussion which had more than 10mails where
clear consensus was made. Thats not going to happen.


Then you are doing it wrong.  In FreeBSD we have them all the time.  
I've seen them in NetBSD land too, so clearly, you aren't paying attention.


Warner

Re: CVS commit: src

[Warner Losh]

On 01/18/2011 02:15, David Holland wrote:

On Tue, Jan 18, 2011 at 07:06:52AM +0200, Jukka Ruohonen wrote:
  Why was this removed when there was an active discussion about removing
  it where no concensus was reached?  This sort of thing where commis
  occur before a discussion is finished seems to be occurring more and
  more often.
  
Maybe because the whole tech-userlevel@ mailing list has become poisonous?
I know several people who abstain from posting anything to the list because
of the nature of the list and these discussions.

I think that's a vast exaggeration. Then again, maybe you think I'm
part of the problem?

If one can not use his or her own discretion with what must be one of the
most trivial files in the system, there is something fundamentally wrong.
It is easy to block and freeze things (even by an user) simply by posting
regularly to tech-userlevel@ just to show that there was no consensus.

The things that appear trivial from a technical perspective are also
commonly the things that are most visible in people's day-to-day use
of the system. Of course something like operator, which many people
refer to regularly, is going to concern them more than stuff deep in
the kernel. And in that context, proposing gratuitous changes with no
clear rationale is guaranteed to cause a fuss.

Understanding how this works is essential to working on the visible
parts of the system. Blowing off concerns people raise just because
you think their concerns aren't important (and hence bikeshedding)
is not the right approach; neither is skipping the review entirely.

It's perfectly possible to propose things on tech-userlevel and get
them agreed on. It just requires doing a little more planning up front
to make sure the proposal has clear motivations and benefits and
addresses likely concerns.


There is a fine art between listening to everybody and getting things 
done.  When you are listening to people and they are reasonable, then 
the process works out well.  If the conversation becomes circular, then 
you need to thank them for their opinion and move forward.  Sometimes 
moving forward means that you go with a majority viewpoint if the 
minority can't articulate a good technical reason for the objection.  
Other times moving forward may mean abandoning your plans.  Still other 
times (and this is usual), your plans are modified based on input you 
received.  The more you fight the process, the more the process will 
fight you and you'll have an unsatisfactory outcome.


Knowing how to balance this all, as well as having the patience to 
practice this dance, can be difficult to know at first, but often the 
rewards are better in the end.


Unfortunately, the delayed gratification necessary to do this often 
matches poorly with the desire to scratch an itch and move on.


Warner

Re: CVS commit: src/sys/dev

[Warner Losh]

On 12/05/2010 02:35, Antti Kantee wrote:

On Sat Dec 04 2010 at 18:44:07 +, Christos Zoulas wrote:

In article20101204173951.3ae6e17...@cvs.netbsd.org,
Antti Kanteesource-changes-d@NetBSD.org  wrote:

-=-=-=-=-=-

Module Name:src
Committed By:   pooka
Date:   Sat Dec  4 17:39:51 UTC 2010

Modified Files:
src/sys/dev: rnd.c

Log Message:
Don't allow goes to 11^H^Hhyperspace len field for RNDADDATA.


Should be EINVAL; E2BIG has a very specific meaning (unless we want to change
that).

EINVAL is used too much and I try to pick more descriptive remotely
fitting errnos when possible.

If someone feels strongly otherwise, please change it.

At least update intro(2) to document the new meaning.

Warner

Re: CVS commit: src/sys/dev

[Warner Losh]

On 12/04/2010 15:09, David Laight wrote:

On Sat, Dec 04, 2010 at 03:50:25PM -0600, Michael Graff wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I admit to a certain lack of understanding the twisty maze of pointers
and memory mapping magic at play here, but is simply checking the length
enough?  That is, what happens if I pass in a structure that is smaller
than expected?

That is, is there a way to check the actual size of the data passed into
the ioctl, rather than the field in the structure we expect, or is that
done at a higher level?

The length of the program's buffer is unknown.
The kernel uses the high 16 bits of the ioctl command to indicate
whether to read/write (2 bits) and a length (14 bits).
If either control bit is set, the ioctl syscall stub will do the
copyin/out and pass the actual device driver a pointer to the
in-kernel buffer.
So the device driver can always access the buffer length implied
from the command.

To my mind this is a horrid hack :-)
It does ensure, however, that all the error checking is centralized (and 
therefore more likely ot be correct).  Removing the checks from the 
ioctl layer would break a lot of code...


Warner

David

Re: CVS commit: src/sys/arch/mips/mips

[Warner Losh]

 On 11/09/2010 13:54, David Holland wrote:

On Tue, Nov 09, 2010 at 01:46:46PM +0200, Antti Kantee wrote:
  Thanks for the extra details.  It may be obvious with the background
  info you've now provided, but wasn't from your initial commit message.
  
Gotta love source-changes-full and nxr.netbsd.org ;)

No, it's not obvious from those either, and I'm even familiar with the
architecture. This whole thing could have been avoided if you'd
written a clear commit message; can you revise the text in CVS to have
fewer dangling referents?
Or better yet, improve the comments so people looking at the code know 
what the considerations are?  Seems like an area where a sentence or two 
would save a lot of grief in the future...


Warner

Re: CVS commit: src/sys/dev/pci

[M. Warner Losh]

In message: 100702193931.m0105...@mirage.ceres.dti.ne.jp
Izumi Tsutsui tsut...@ceres.dti.ne.jp writes:
:  Module Name:src
:  Committed By:   msaitoh
:  Date:   Fri Jul  2 03:25:27 UTC 2010
:  
:  Modified Files:
:  src/sys/dev/pci: pucdata.c
:  
:  Log Message:
:   Fix frequency for OX16PCI954.
: 
: I'm afraid some puc's frequencies are not chip specific
: but board specific, i.e. the same chips could have different clocks
: and we might also have to check svend and sprod in such case.

Even that won't be enough.  We've hit this problem in FreeBSD.
There's two boards that are totally the same from a software
perspective, but the frequencies are different.

Warner

Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/lib

[M. Warner Losh]

In message: 20100626032531.ga14...@britannica.bec.de
Joerg Sonnenberger jo...@britannica.bec.de writes:
: On Sat, Jun 26, 2010 at 05:11:39AM +0200, Alistair Crooks wrote:
:  On Sat, Jun 26, 2010 at 01:32:05AM +0200, Joerg Sonnenberger wrote:
:   On Fri, Jun 25, 2010 at 11:54:32PM +0200, Alistair Crooks wrote:
:Even in C99, the %lu method will work unless size_t is bigger 
than
:unsigned long *and* the value being printed exceeds ULONG_MAX, 
which
:is unlikely to happen in practice.
:  
:  Please get the attributions right - I was quoting that text.
:   
:   Actually, it doesn't. This method breaks as soon as size_t != u_long and
:   might only work in a few edge cases like the size_t being the last
:   argument and the byte order is Little Endian. This is worse because IIRC
:   Microsoft decided to use IL32LLP64 or something similarly fancy.
:  
:  Can you give us a reference to this, please?
: 
: E.g.
: 
http://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows
: and the MSDN reference inside.
: 
:   A more portable approach with autoconf can be found in pkg_install, look
:   for MISSING_SIZE_T_SUPPORT and the corresponding AC_CHECK_SIZEOF calls
:   in configure.ac.
:  
:  Hmmm, I see this in configure.ac -
:  
:  AC_CHECK_SIZEOF(int)  
:  AC_CHECK_SIZEOF(long)   
:  AC_CHECK_SIZEOF(long long)
:  AC_CHECK_SIZEOF(size_t, [#include stdlib.h])
: 
: ...compute the sizes to not depend on SIZE_MAX (which would simplify the
: logic a lot).
: 
:  and
:  
:  case $host in
:  *-*-hpux*)
:  AC_DEFINE(MISSING_SIZE_T_SUPPORT)
:  AH_TEMPLATE([MISSING_SIZE_T_SUPPORT], [ 
:  Define to 1 if the `z' modifider for printf is missing.
:  ])
:  ;;
:  esac
: 
: The only platform for pkgsrc purposes ATM which lacks the %z support.
: 
:  and
:  
:  #ifndef MISSING_SIZE_T_SUPPORT
:  #  define PRIzu zu
:  #elif SIZEOF_SIZE_T == SIZEOF_INT
:  #  define PRIzu u
:  #elif SIZEOF_SIZE_T == SIZEOF_LONG
:  #  define PRIzu lu
:  #elif SIZEOF_SIZE_T == SIZEOF_LONG_LONG
:  #  define PRIzu llu
:  #else
:  #  errror Unknown size_t size
:  #endif
:  
:  Not quite what I'd been expecting, though, from the glowing description
:  above.
: 
: It would be simpler if SIZE_MAX support can be assumed. In that case it
: would boil down to
: #if SIZE_MAX == INT_MAX
: #define PRIzu u
: #elif SIZE_MAX == LONG_MAX
: #define PRIzu lu
: #else SIZE_MAX == LLONG_MAX
: #define PRIzu llu
: #endif

You could easily enough have something like the following in autoconf
to generate that:

#include stdlib.h
#include stdio.h

int main(int argc, char **argv)
{
size_t foo = ~0;
printf(#ifndef SIZE_MAX\n#define SIZE_MAX %llu\n#endif\n,
(unsigned long long)foo);
return (0);
}

Warner

Re: CVS commit: src/sys/rump/librump/rumpkern

[M. Warner Losh]

In message: 20100614083424.gc16...@cs.hut.fi
Antti Kantee po...@cs.hut.fi writes:
: On Mon Jun 14 2010 at 07:00:05 +, David Holland wrote:
:  On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote:
:Fix previous in emul.c -- only numbers are operands for cpp comparisons.
:Apparently non-numbers logically produce arch-dependent behaviour.
:  
:  Not at all.
:  
:  C99 6.10.1 #4:
:  
:[...] After all replacements due to macro expansion and the defined
:unary operator have been performed, all remaining identifiers
:(including those lexically identical to keywords) are replaced with
:the pp-number 0, and then each preprocessing token is converted into
:a token. The resulting tokens compose the controlling constant
:expression which is evaluated according to the rules of 6.6. [...]
: 
: So, you being the person who attempted to write cpp with sed, what
: comparison does amd64 == sun3 actually result in?  What about
: i386 == sun3 (the former returned true, the latter didn't).

On i386, that's true.  amd64 expands to '0', as does sun3.  This makes
the first one true.  The second one, i386 expands to '1', so the
second one would be false.

Warner

Re: CVS commit: src/sys/rump/librump/rumpkern

[M. Warner Losh]

In message: 20100615052154.gb16...@netbsd.org
David Holland dholland-sourcechan...@netbsd.org writes:
: On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote:
:   On i386, that's true.  amd64 expands to '0', as does sun3.  This makes
:   the first one true.  The second one, i386 expands to '1', so the
:   second one would be false.
: 
: Arguably we shouhld fix our gcc to only define __i386__, not i386,
: which conflicts with the user namespace...

True, but doing so would likely break applications that have depended
on this define.  Which is worse?

Warner

Re: CVS commit: src/usr.bin/make

[M. Warner Losh]

In message: huonge$v4...@dough.gmane.org
chris...@astron.com (Christos Zoulas) writes:
: In article 20100609171621.ga23...@britannica.bec.de,
: Joerg Sonnenberger  jo...@britannica.bec.de wrote:
: On Wed, Jun 09, 2010 at 12:58:23PM -0400, Christos Zoulas wrote:
:  Log Message:
:  Explain variable expansion better. Requested by Aleksey Cheusov
: 
: This is wrong. Loop variables are not exapnded on each loop iteration.
: Each loop iteration effectively creates a new variable. The rest of his
: confusion comes from two simple facts:
: (1) += is lazy in bmake. This is different from FreeBSD, where it forces
: expansion.
: (2) The evaluation of j is lazy as well. That's why he sees the last
: loop iteration.
: 
: Well, it was true when I wrote the for code (more than 16 years
: ago!). I guess dsl re-wrote it, but the net effect is the same.
: 
: When did FreeBSD changed += not to be lazy? That would break a lot
: of existing Makefiles I presume.

It looks like it is lazy to me for all non-loop variables in FreeBSD:

% uname
FreeBSD
% cat M
FOO=1
BAR=2
.for j in a b c
FOO+= ${BAR} ${j}
.endfor
BAR=3

all:
@echo ${FOO}
@echo ${BAR}
%  make -f M
1 3 a 3 b 3 c
3
%

Not sure if this is correct or expected but it strikes me as
useful and changes to this behavior would break things...

Warner

Re: CVS commit: src/lib/libc/locale

[M. Warner Losh]

In message: 20100606041254.gb19...@netbsd.org
David Holland dholland-sourcechan...@netbsd.org writes:
: On Sat, Jun 05, 2010 at 11:53:32PM +0200, Alistair Crooks wrote:
:Module Name: src
:Committed By:tnozaki
:Date:Wed Jun  2 16:04:52 UTC 2010
:
:Modified Files:
: src/lib/libc/locale: bsdctype.c
:
:Log Message:
:uint8_t - unsigned char, int16_t - short.
:   
:   As ever, thank you for looking after our locale code.
:   
:   I was just wondering why this change was made? It seems to be a backwards
:   step to me?
: 
: I looked at it and it appears to me that it's a change to use
: non-sized types (that are guaranteed to be large enough) in the
: in-memory structures. If we ever do a port to a 36-bit machine or
: whatever it's probably desirable.

If you ever port to a 36-bit machine, you are going to have to lie and
define int32_t as 'int' anyway

Warner

Re: CVS commit: src/sys/conf

[M. Warner Losh]

In message: 201001010039.o010dvjh028...@vtn1.victoria.tc.ca
jnem...@victoria.tc.ca (John Nemeth) writes:
: On May 23,  6:34pm, John Nemeth wrote:
: } 
: } Module Name:src
: } Committed By:   jnemeth
: } Date:   Thu Dec 31 23:59:02 UTC 2009
: 
:  Bah!  One minute early, got confused.  Mea Culpa.  For penance I
: shall remove myself from the race for the next two years.

Generally, copyright in the last half of the year goes to the next
year anyway, so a few seconds is no big deal :)

Warner

Re: CVS commit: src/external/bsd/mdocml/dist

[M. Warner Losh]

In message: 20091107084411.gt15...@snowdrop.l8s.co.uk
David Laight da...@l8s.co.uk writes:
: On Sat, Nov 07, 2009 at 12:48:16AM -0700, M. Warner Losh wrote:
:  
:  which ones have the same name, but different behavior on OS X?  A quick read
:  of the man pages suggests they are identical...
: 
: Check about whether they need a \n at the end of the format.

They aren't needed on MacOS, nor FreeBSD.  A quick test on 10.5.8
shows that warn doesn't need it.  Is there one that does need them?

Warner

Re: CVS commit: src/sys/rump

[M. Warner Losh]

In message: 20090908131801.gb17...@cs.hut.fi
Antti Kantee po...@cs.hut.fi writes:
: On Tue Sep 08 2009 at 13:02:55 +, Christos Zoulas wrote:
:  In article 20090907174634.ga16...@cs.hut.fi,
:  Antti Kantee  po...@netbsd.org wrote:
:  On Tue Sep 08 2009 at 03:28:35 +1000, matthew green wrote:
:   
:  Module Name:  src
:  Committed By: pooka
:  Date: Mon Sep  7 13:02:37 UTC 2009
:  
:  Modified Files:
:src/sys/rump: Makefile.rump
:  
:  Log Message:
:  Always define __NetBSD__ (for builds on non-NetBSD)
:   
:   
:   when does this happen?  even builds on non-NetBSD should
:   end up here with a compiler that defines __NetBSD__.
:  
:  When you are building the binaries to be used as libraries on non-NetBSD,
:  i.e. not building NetBSD itself.
:  
:  Then perhaps we should be using a different CPP symbol?
: 
: No, __NetBSD__ is right.  For all purposes, code in the rump kernel *is*
: NetBSD.  E.g. if you have #ifdef __NetBSD__ in a kernel driver which
: was imported from $OtherOS, you must have the rump version think it is
: running on NetBSD, since it technically speaking is.  The difference to
: most cpp symbols is merely that __NetBSD__ comes from the compiler instead
: of from the kernel headers.  Of course param.h could define something like
: __I_am_the_NetBSD__ and we could test against that in all of our NetBSD
: kernel code, but I don't see any benefit, especially since __NetBSD__
: is a well established practise even outside NetBSD developers.

__NetBSD__ is the *COMPILER* environment.  Depending on it is *BAD*.
You need to use a different symbol.  This is a bug in the NetBSD code
now.  __NetBSD__ isn't, and never has bene, the KERNEL.

: Maybe it's easier to understand this issue if you think of rump as a
: highly componentized OS running inside a virtual machine.  Just instead
: of qemu or xen or what have you, your vmm is a process -- nobody is
: saying xen code shouldn't use __NetBSD__, are they?

I'd say that it shouldn't...

: I think Matt understood my extended offline explanation yesterday,
: so maybe he could chime in and summarize?

Maybe __NetBSD_Version__ should be used instead?  Its clearly NetBSD
kernel build environment specific (since it comes from sys/parma.h)
and doesn't muddy the waters with the differences between the
different BUILD systems.

Warner

Re: CVS commit: src/sys/rump

[M. Warner Losh]

In message: 20090908162339.ga11...@cs.hut.fi
Antti Kantee po...@cs.hut.fi writes:
: On Tue Sep 08 2009 at 12:18:57 -0400, Christos Zoulas wrote:
:  | : No, __NetBSD__ is right.  For all purposes, code in the rump kernel *is*
:  | : NetBSD.  E.g. if you have #ifdef __NetBSD__ in a kernel driver which
:  | : was imported from $OtherOS, you must have the rump version think it is
:  | : running on NetBSD, since it technically speaking is.  The difference to
:  | : most cpp symbols is merely that __NetBSD__ comes from the compiler 
instead
:  | : of from the kernel headers.  Of course param.h could define something 
like
:  | : __I_am_the_NetBSD__ and we could test against that in all of our NetBSD
:  | : kernel code, but I don't see any benefit, especially since __NetBSD__
:  | : is a well established practise even outside NetBSD developers.
:  | 
:  | __NetBSD__ is the *COMPILER* environment.  Depending on it is *BAD*.
:  | You need to use a different symbol.  This is a bug in the NetBSD code
:  | now.  __NetBSD__ isn't, and never has bene, the KERNEL.
:  
:  That was my complaint exactly. I meant to say this in my next message :-)
:  
:  | Maybe __NetBSD_Version__ should be used instead?  Its clearly NetBSD
:  | kernel build environment specific (since it comes from sys/parma.h)
:  | and doesn't muddy the waters with the differences between the
:  | different BUILD systems.
:  
:  That is what I was thinking also.
: 
: Whoever finds this churn worth their effort, as dh pointed out, remember
: to replace all instances of __FreeBSD__, __OpenBSD__, __Linux__,
: __Slowaris__, __sMackOS__, __etc__ as well.

How many instances of those are there?  And wouldn't it be spelled
__linsux__? :)

Warmer

Re: CVS commit: src/usr.bin/error

[M. Warner Losh]

In message: 20090814021047.91ed856...@rebar.astron.com
chris...@zoulas.com (Christos Zoulas) writes:
: On Aug 13, 10:19pm, dholland-sourcechan...@netbsd.org (David Holland) wrote:
: -- Subject: Re: CVS commit: src/usr.bin/error
: 
: | On Thu, Aug 13, 2009 at 03:46:39PM +, Christos Zoulas wrote:
: |   XXX: does this program actually do anything useful these days?
: |   
: |   Yes, it works just fine :-) I use it all the time.
: | 
: | Better you than me :-)
: | 
: | Maybe it should lose support for compilers that disappeared twenty
: | years ago, though.
: 
: The error reporting syntax has not changed much!

Besides, how much space would it really save?

Warner

Re: PCI domains

[M. Warner Losh]

In message: 20090710024528.ec36959...@thoreau.thistledown.com.au
Simon Burge sim...@netbsd.org writes:
: Christoph Egger wrote:
: 
:  Michael Lorenz wrote:
: 
:   +/*
:   + * NetBSD's userland has a /dev/pci* entry for each bus but userland has 
no way
:   + * to tell if a bus is a subordinate of another one or if it's on a 
different
:   + * host bridge.
:  
:  I have a patch which introduces support for PCI domains. It allows the
:  userland to distinguish between them by checking if the pci bus belongs
:  to the same PCI domain.
: 
: What exactly is a PCI domain?  A quick google seems to suggest that
: this is a Linux concept as opposed to a PCI concept.  In a previous
: life we used NetBSD on a number of different machines of various
: architectures that had multiple PCI host bridges, although admittedly we
: didn't need to know the topology of the PCI bus layout.

PCI domains, as implemented by Linux and FreeBSD are separate host
bridges.  Each bus complex behind the host bridge has independent
numbering.  Each of these bus complexes are in a different domain.

Not all systems with multiple host bridges have separate numbering
domains, but many do.

Warner

Re: CVS commit: src/sbin/fsck_ffs

[M. Warner Losh]

In message: 87r5yv4rqn@snark.cb.piermont.com
Perry E. Metzger pe...@piermont.com writes:
: 
: M. Warner Losh i...@bsdimp.com writes:
:  What I didn't glean from the discussion is what, exactly, you were
:  going to do about it and what, exactly, you'd like to harmonize with
:  FreeBSD on.  It may have been there, but I just missed it.
: 
: Documentation. It would involve making all man pages refer consistently
: to FFS, FFSv1, FFSv2, and not to mix in the references to UFS.

Documentation is easy, and I'll be happy to bring over the changes.

Output of programs and/or input via config file changes is harder...

I wasn't sure which of these two classes you were asking...

Warner

Re: CVS commit: src/sbin/fsck_ffs

[M. Warner Losh]

In message: 20090510220227.gd16...@britannica.bec.de
Joerg Sonnenberger jo...@britannica.bec.de writes:
: On Sun, May 10, 2009 at 04:31:34AM +, YAMAMOTO Takashi wrote:
:  have you tried to convince freebsd guys to use your preferred name?
:  being different creates another layer of confusion.
: 
: We had a short discussion about this during BSDCan. Kirk didn't mind and
: if it should be reasonable to get consistent.

I think that this sort of decision can't be made by just Kirk since
FreeBSD has deployed ufs2 for several releases now.

I've missed much of the discussion, can someone recap exactly what
you'd like to see changed?  That would be the starting point for any
user-visisble changes to FreeBSD...

Warner

Re: CVS commit: src/sbin/fsck_ffs

[M. Warner Losh]

In message: 20090511015855.gd16...@britannica.bec.de
Joerg Sonnenberger jo...@britannica.bec.de writes:
: On Sun, May 10, 2009 at 07:51:41PM -0600, M. Warner Losh wrote:
:  I've missed much of the discussion, can someone recap exactly what
:  you'd like to see changed?  That would be the starting point for any
:  user-visisble changes to FreeBSD...
: 
: There is currently a mixed naming convention when refering to FFS
: filesystems (v1 and v2). Sometimes, it is FFS, FFS2, UFS, UFS2 etc.
: The consensus in NetBSD was to consistently use FFS and FFSv2.
: UFS2 is bad, as it changes the underlaying inode format, but still has
: FFS on top.

Right, I gleaned that from the discussion.

What I didn't glean from the discussion is what, exactly, you were
going to do about it and what, exactly, you'd like to harmonize with
FreeBSD on.  It may have been there, but I just missed it.

Warner