Re: CVS commit: src/share/misc

2020-08-02 Thread 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

2020-04-19 Thread 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

2020-03-13 Thread 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

2020-03-09 Thread 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

2019-12-28 Thread 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

2019-12-28 Thread 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

2019-12-24 Thread 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

2019-12-24 Thread 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

2019-12-19 Thread 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

2019-09-12 Thread 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

2019-09-05 Thread 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

2018-12-05 Thread 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

2017-10-03 Thread 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

2017-10-03 Thread 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

2015-03-01 Thread 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

2014-01-24 Thread 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

2013-05-24 Thread 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

2013-01-30 Thread 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

2013-01-25 Thread 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

2012-12-13 Thread 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

2012-11-21 Thread Warner Losh

On Nov 21, 2012, at 1:25 PM, Christos Zoulas wrote:

 In article 20121121200309.gn...@snowdrop.l8s.co.uk,
 David Laight  da...@l8s.co.uk wrote:
 On Wed, Nov 21, 2012 at 12:43:20PM -0500, Christos Zoulas wrote:
 On Nov 22,  4:39am, m...@eterna.com.au (matthew green) wrote:
 -- Subject: re: CVS commit: src/usr.bin/pkill
 
 | this seems like a fairly big semantic change to me.
 | 
 | could you change it to take a new option to look in argv[0] instead
 | of p_comm?  p_comm is not changeable by the user.
 
 You could already do this with -f. The point was to make the default case
 behave intuitively. Adding an option is against that. I could add backwards
 compatibility by checking both, but I think that in the long term this will
 be dangerous and confusing (since you might end up killing more than you
 thought you would...)
 
 That (killing too much) is always true when you use something like pkill().
 At least it is better that the 'ps | grep' I've seen many people do!
 
 Yes, this is why it is best to not use things that kill by name from scripts.
 
 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?

Warner

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

2012-11-21 Thread 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

2012-10-12 Thread 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

2012-04-19 Thread 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

2012-03-22 Thread 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

2012-03-04 Thread 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

2012-03-02 Thread 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

2012-03-01 Thread 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

2012-01-31 Thread 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

2011-12-28 Thread 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

2011-10-18 Thread 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

2011-10-18 Thread 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

2011-10-16 Thread 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

2011-09-12 Thread 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

2011-09-03 Thread 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

2011-08-31 Thread 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

2011-03-09 Thread 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

2011-01-28 Thread 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

2011-01-19 Thread 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

2011-01-18 Thread 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

2010-12-05 Thread 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

2010-12-04 Thread 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

2010-11-09 Thread 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/arch/mips/mips

2010-11-08 Thread Warner Losh

 On 11/08/2010 15:19, Antti Kantee wrote:

On Mon Nov 08 2010 at 21:40:49 +, David Holland wrote:

On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
Modified Files:
src/sys/arch/mips/mips: locore_mips1.S
  
Log Message:
In TLBRead, restore PID before doing the saves so that the caller's
TLB entries are used instead of the PID given as the argument.
  
from Alessandro Forin

This doesn't make any sense.

As far as I can tell, the real problem is that the code is not
attending to pipeline hazards properly; moving things around until it
experimentally seems to work is just going to create other odd
behavior sometime down the line under different timing circumstances.

I don't have a mips1-specific reference on hand, but my recollection
is that you need *three* nops when messing with cop0 registers for all
effects to flush through.

locore_mips1.S doesn't agree with your recollection, e.g. mips1_TLBUpdate
right above mips1_TLBRead.
mips1 had a 2 stage pipeline, so at most you'd need 1 nop.  3 nops is 
for the R4000's and similar.  Then it got weird with multi-issue, 
threads, and sometimes silicon bugs that required more before MIPS32r2 
and MIPS64r2 codified a single, special kind of nop that did the trick.


Warner


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

2010-07-02 Thread 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

2010-06-25 Thread 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

2010-06-14 Thread 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

2010-06-14 Thread 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

2010-06-09 Thread 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

2010-06-05 Thread 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

2009-12-31 Thread 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

2009-11-07 Thread 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

2009-09-08 Thread 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

2009-09-08 Thread 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/sys/rump

2009-09-08 Thread M. Warner Losh
In message: 20090909010833.ga12...@netbsd.org
David Holland dholland-sourcechan...@netbsd.org writes:
: On Tue, Sep 08, 2009 at 10:02:33AM -0600, M. Warner Losh wrote:
:   __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.
: 
: No need to shout...
: 
: Anyway, what does the compiler environment *mean* besides we're
: building a NetBSD binary? That's exactly what rumpkernel is, even if
: it's compiled with the FreeBSD compiler. Properly speaking it ought to
: be built with a cross-compiler; maybe that'll happen in the long term.

If you are building with a FreeBSD compiler, you are building a
FreeBSD binary, by definition.  __FreeBSD__ means you are building a
FreeBSD binary.  If that's not what you want to do, you need to jump
through a lot of hoops, but it usually easier to build a cross
compiler than jump through those hoops.  There's a lot more to the
environment than just -D__FreeBSD__, there's the default binaries that
are produced, there's a bunch of defines and arch assertions, default
paths to includes and libraries, etc.

This may be inconvenient.  I know years ago I tried building a NetBSD
kernel with a FreeBSD compiler, and that failed due to these
differences (and others other than __NetBSD__ not being defined).
Trying to kludge it caused me much pain and suffering.  I abandoned
the effort because building a proper cross compiler turned out to be a
lot easier...

sorry for the shouting earlier, but this is a hot-button since I've
had to explain this difference many times to many people over the
years...

Warner


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

2009-08-13 Thread 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: CVS commit: src/etc/rc.d

2009-08-06 Thread M. Warner Losh
In message: 87ab2dat79@snark.cb.piermont.com
Perry E. Metzger pe...@piermont.com writes:
: 
: Frank Kardel kar...@netbsd.org writes:
:  Actually we can retire ntpdate in rc unless we are very tight on
:  memory. ntpd_flags should add the -g flag. This allows  for a  big
:  (time setting) initial (and only one time) step in ntpd.
: 
: I was made aware of that a few days ago.

How long after startup does ntpd exit in this case?  How long does it
take to make the time measurements?  Does it do this in parallel or
before it calls daemon?

The reason I ask is that I know ntpd used to have issues with this,
and you'd get a time jump after it started.  Have they been fixed?

: If we go that route, however, we will have to move ntpd to start much
: earlier (where ntpdate currently runs), because various tools like the
: kdc stuff require that the time be properly set before they execute.
:
: I'm willing to do that for -current but not for 5.0 (the fixes now in
: -current are being pulled up.)
: 
:  This is the ntpdate functionality with ntpd normally continuing
:  afterwards. ntpd is fine when the network is up with loopback
:  interfaces only. It will discover interfaces going up/down
:  automatically and re-trigger name resolution when new interfaces come
:  up and unresolved dns-names still exist.
: 
: That seems like quite a good thing. We should probably do that, moving
: ntpd much earlier in the system startup and making kdc etc. depend on
: ntpd instead of ntpdate. Are you willing to do the work? I don't have
: time for some days.

Just be careful here about the races here...  ntpdate guaranteed the
time was set and wasn't going to change...

Warner


Re: CVS commit: src/etc/rc.d

2009-08-06 Thread M. Warner Losh
In message: 87y6px9cr9@snark.cb.piermont.com
Perry E. Metzger pe...@piermont.com writes:
: 
: M. Warner Losh i...@bsdimp.com writes:
:  In message: 87ab2dat79@snark.cb.piermont.com
:  Perry E. Metzger pe...@piermont.com writes:
:  : 
:  : Frank Kardel kar...@netbsd.org writes:
:  :  Actually we can retire ntpdate in rc unless we are very tight on
:  :  memory. ntpd_flags should add the -g flag. This allows  for a  big
:  :  (time setting) initial (and only one time) step in ntpd.
:  : 
:  : I was made aware of that a few days ago.
: 
:  How long after startup does ntpd exit in this case?
: 
: It doesn't. -g says that the initial time difference may be large and to
: just step the time rather than slewing it on initial start. Then you
: don't need ntpdate. (You *can* use ntpd with other flags to behave like
: ntpdate but that's not the purpose here.)

I think you've missed my point.

With ntpdate the time is set when ntpdate is run, and the
adjtime/ntpd_adjtime parameters aren't set (which is part of what I
meant by 'not going to change', the other part is 'time will pass
normally without jumps').

With ntpd -g, it means that time will be messed up until the time is
first set (which isn't after the first measurement).  There are
several polling intervals, about a minute apart, that have to happen
before ntpd believes the time (at least historically, I haven't
checked the exact version in NetBSD).  This means that different
things in the system will start up with the wrong time.

Eg, the system starts up with Jan 1, 1980 (lovely bios error, pick any
other year you want, the example is still valid)...  ntpd starts, as
does sendmail, cron, sshd, etc.  Then, a few minutes later, time jumps
forward 29 years.

Warner


Re: PCI domains

2009-07-10 Thread 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

2009-05-11 Thread 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

2009-05-10 Thread 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

2009-05-10 Thread 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