Re: CVS commit: src/lib/libc/time
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
> > 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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