Re: CVS commit: src

2020-08-17 Thread David Brownlee
On Sun, 16 Aug 2020 at 08:13, Martin Husemann  wrote:
>
> Hi Nia,
>
> I think you are mixing a few issues here into one discussion - which might
> make sense from a user perspective, but does not help us to get forward.

I think that the other issues provide important context.

NetBSD's underlying implementation has a fundamental difference in
blocking entropy behaviour - the specification matches in terms of "an
implementation *may* block... ", but real world use will have some
NetBSD boxes block indefinitely until user intervention, whereas other
systems would not.

Obviously there is no perfect choice, as other different systems have
made different API behaviour choices, and in general have a less
sophisticated approach to entropy usage, and NetBSD itself has to
cater for boxes with and without hardware entropy.

However a getentropy() where the *effective* behaviour from a user
perspective matched Linux and the other BSDs but not Solaris would
seem to be a reasonable option. As the Linux random(7) manpage even
suggests "The getentropy(3) function provides a slightly more portable
interface on top of getrandom(2)"

David

> From my POV the interacting-but-need-to-be-solved-individually issues
> are:
>
>  - The libc or kernel<->userland API. This is what the core decision was
>about. The API is well (enough) defined, same on multiple OSes,
>and provides all the flexibility we need.
>
>  - Making entropy available "early enough" during the boot process. This
>is a hard problem on *many* machines, but no big deal at all on modern
>x86 and a few modern aarch64.
>For me this is looks like still work in progress with no "good enough"
>solution yet. I understood Taylor would like to improve this next.
>I personally would define "early enough" as "during rc.d" and this makes
>the problem relatively easily solvable for "real installations" (see
>below) by just manually (or "someway") seeding the individual installations
>entropy file.
>IIUC Taylor would like to also enhance/add kernel parts providing entropy.
>
>  - Related to above: how to deal with one-off setups like first boots of
>install images or clones of virtual machines.
>This will be solvable (probably by a combination of better scripting
>and/or documented "best practices") once the point above is more or
>less settled.
>
>  - Finaly the grey area of "which variant of our API should applications
>use" (and even more complex: libraries). This needs individual answers
>on a case by case basis and might need some upstream battle - but we
>should be able to give good guidance and clear rules once the items
>above are cleared.
>
> Martin


Re: Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-02 Thread David Brownlee
On Sat, 2 May 2020, 20:10 Jason Thorpe,  wrote:

>
> > On May 1, 2020, at 1:07 PM, Ryo ONODERA  wrote:
> >
> > Hi,
> >
> > Have you missed this thread?
> >
> > If the problem requires more time to investigate,
> > could you consider to revert ata change for a while?
> >
> > Thank you.
>
> I backed it out, but would appreciate some help tracking down the issue
> because no other problems were reported other than on these specific
> machines.
>

The T480 is my main machine but I'm happy to boot any test kernels (to
confirm, - current as of the 30th with just that one commit reverted runs
fine)

Thanks

David

>


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

2020-05-01 Thread David Brownlee
Plus to confirm reverting just this commit from today's github copy of
current (d5b32e03eac8b05d38a143ee0ec615efb2233201) boots fine on the
T480

Thanks

On Thu, 30 Apr 2020 at 00:12, Alexander Nasonov  wrote:
>
> David Brownlee wrote:
> > Just another data point - seeing this same panic on a T480 with the
> > latest kernel from nyftp
>
> Same problem on T470.
>
> --
> Alex


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

2020-04-29 Thread David Brownlee
Just another data point - seeing this same panic on a T480 with the
latest kernel from nyftp


Re: CVS commit: src/share/mk

2019-11-15 Thread David Brownlee
On Thu, 14 Nov 2019 at 21:05, Christos Zoulas  wrote:
>
> In article <2c05e1ed-8410-fa0f-d786-06ee6e1c4...@marples.name>,
> Roy Marples   wrote:
> >On 14/11/2019 05:47, Martin Husemann wrote:
> >> On Thu, Nov 14, 2019 at 03:53:02PM +1100, matthew green wrote:
> >>> i'm not happy about this change.  i wish that bsdtar was
> >>> fixed to not be unfriendly, because it mostly is a better
> >>> implementation.  just these edge cases are rather ..
> >>> problematic yet these issues are being ignored or
> >>> rejected as being irrelevant.
> >>
> >> Me neither, especially as we now effectively have different command line
> >> args passed from sysinst to tar depending on the tar invocation (and this
> >> is all hard coded). I'll have to make it a define in sysinst depending
> >> on the seleted tar variant :-/.
> >
> >Just for the record, I don't really care about different cmd line args,
> >symlinks and security involved.
> >
> >My expectation is that a modern NetBSD tar can extract a modern tar
> >archive from other sources.
> >
> >If it cannot do this we have failed.
>
> So I am trying to find some time to pursue the two issues I have
> with upstream and understand if they will accept the following two
> changes (or versions thereof):
>
> The first issue is that I prefer to have tar respect existing
> symlinks (ones that it did not create by default -- without having
> to specify extra flags) since to do this (in my opinion) does not
> pose a security risk. Yes my implementation is Q+D, but it works.
>
> https://www.netbsd.org/~christos/track-symlinks.diff
>
> The second issue is that the way libarchive-tar overwrites existing
> files is by removing them first, and writing them directly to the
> final destination pathname. This creates a significant amount of
> time where the file is either not available or not completely
> written. Imagine trying to replace shared libraries or programs
> frequently used. Pax-as-tar wrote the file to a temporary one first
> and used rename(2) to atomically replace it. I've written a patch
> to do the same for libarchive-tar:
>
> https://www.netbsd.org/~christos/libarchive-atomic.diff
>
> With those two patches we can put libarchive as tar back and we don't
> need to make any other changes since behavioraly the old pax-as-tar
> and libarchive-tar behave the same for those two cases that bothered us.
>
> I am inclined to just commit them and flip the default again.

I could see an argument for having an option to turn off the
extract-to-temp-and-rename behaviour (not that I'd use it), but I'd be
very happy to see both above changes in as defaults and us back onto
libarchive-tar

Thanks for working on this!

David


CVS commit: src/etc

2019-09-25 Thread David Brownlee
Module Name:src
Committed By:   abs
Date:   Wed Sep 25 23:09:25 UTC 2019

Modified Files:
src/etc/etc.aarch64: ttys
src/etc/etc.algor: ttys
src/etc/etc.alpha: ttys
src/etc/etc.amd64: ttys
src/etc/etc.amiga: ttys
src/etc/etc.amigappc: ttys
src/etc/etc.arc: ttys
src/etc/etc.cesfic: ttys
src/etc/etc.emips: ttys
src/etc/etc.epoc32: ttys
src/etc/etc.evbarm: ttys
src/etc/etc.evbcf: ttys
src/etc/etc.evbmips: ttys
src/etc/etc.evbppc: ttys
src/etc/etc.evbsh3: ttys
src/etc/etc.ews4800mips: ttys
src/etc/etc.hp300: ttys
src/etc/etc.hpcmips: ttys
src/etc/etc.hppa: ttys
src/etc/etc.i386: ttys
src/etc/etc.ia64: ttys
src/etc/etc.iyonix: ttys
src/etc/etc.landisk: ttys
src/etc/etc.luna68k: ttys
src/etc/etc.mipsco: ttys
src/etc/etc.mmeye: ttys
src/etc/etc.mvme68k: ttys
src/etc/etc.mvmeppc: ttys
src/etc/etc.netwinder: ttys
src/etc/etc.news68k: ttys
src/etc/etc.newsmips: ttys
src/etc/etc.next68k: ttys
src/etc/etc.or1k: ttys
src/etc/etc.playstation2: ttys
src/etc/etc.pmax: ttys
src/etc/etc.riscv: ttys
src/etc/etc.sandpoint: ttys
src/etc/etc.sbmips: ttys
src/etc/etc.sgimips: ttys
src/etc/etc.shark: ttys
src/etc/etc.sparc: ttys
src/etc/etc.sparc64: ttys
src/etc/etc.vax: ttys
src/etc/etc.zaurus: ttys

Log Message:
Switch default console tty from /dev/console to /dev/constty

With this switch processes (such as xconsole) can open /dev/console
without breaking login on the text or serial console. This can be
trivially triggered by enabling xdm in rc.conf and hitting
Ctrl+Alt+F1 or equivalent once booted.

The changes:
- Add entry for /dev/console or /dev/constty if missing
- If a port's had /dev/console 'on' switch it off and enable /dev/constty
- If a port did not have /dev/console 'on', leave /dev/constty off

Some ports had /dev/console off and /dev/ttyE0 enabled, presumably to
avoid just this issue. It may make sense to adjust these also (but not
in this pass)

As discussed on current-users


To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.aarch64/ttys
cvs rdiff -u -r1.5 -r1.6 src/etc/etc.algor/ttys
cvs rdiff -u -r1.12 -r1.13 src/etc/etc.alpha/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.amd64/ttys
cvs rdiff -u -r1.24 -r1.25 src/etc/etc.amiga/ttys
cvs rdiff -u -r1.3 -r1.4 src/etc/etc.amigappc/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.arc/ttys
cvs rdiff -u -r1.5 -r1.6 src/etc/etc.cesfic/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.emips/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.epoc32/ttys
cvs rdiff -u -r1.7 -r1.8 src/etc/etc.evbarm/ttys
cvs rdiff -u -r1.2 -r1.3 src/etc/etc.evbcf/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.evbmips/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.evbppc/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.evbsh3/ttys
cvs rdiff -u -r1.2 -r1.3 src/etc/etc.ews4800mips/ttys
cvs rdiff -u -r1.16 -r1.17 src/etc/etc.hp300/ttys
cvs rdiff -u -r1.11 -r1.12 src/etc/etc.hpcmips/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.hppa/ttys
cvs rdiff -u -r1.20 -r1.21 src/etc/etc.i386/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.ia64/ttys
cvs rdiff -u -r1.4 -r1.5 src/etc/etc.iyonix/ttys
cvs rdiff -u -r1.3 -r1.4 src/etc/etc.landisk/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.luna68k/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.mipsco/ttys
cvs rdiff -u -r1.7 -r1.8 src/etc/etc.mmeye/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.mvme68k/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.mvmeppc/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.netwinder/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.news68k/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.newsmips/ttys
cvs rdiff -u -r1.10 -r1.11 src/etc/etc.next68k/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.or1k/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.playstation2/ttys
cvs rdiff -u -r1.15 -r1.16 src/etc/etc.pmax/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.riscv/ttys
cvs rdiff -u -r1.7 -r1.8 src/etc/etc.sandpoint/ttys
cvs rdiff -u -r1.5 -r1.6 src/etc/etc.sbmips/ttys
cvs rdiff -u -r1.10 -r1.11 src/etc/etc.sgimips/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.shark/ttys
cvs rdiff -u -r1.16 -r1.17 src/etc/etc.sparc/ttys
cvs rdiff -u -r1.11 -r1.12 src/etc/etc.sparc64/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.vax/ttys
cvs rdiff -u -r1.3 -r1.4 src/etc/etc.zaurus/ttys

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/etc

2019-09-25 Thread David Brownlee
Module Name:src
Committed By:   abs
Date:   Wed Sep 25 23:09:25 UTC 2019

Modified Files:
src/etc/etc.aarch64: ttys
src/etc/etc.algor: ttys
src/etc/etc.alpha: ttys
src/etc/etc.amd64: ttys
src/etc/etc.amiga: ttys
src/etc/etc.amigappc: ttys
src/etc/etc.arc: ttys
src/etc/etc.cesfic: ttys
src/etc/etc.emips: ttys
src/etc/etc.epoc32: ttys
src/etc/etc.evbarm: ttys
src/etc/etc.evbcf: ttys
src/etc/etc.evbmips: ttys
src/etc/etc.evbppc: ttys
src/etc/etc.evbsh3: ttys
src/etc/etc.ews4800mips: ttys
src/etc/etc.hp300: ttys
src/etc/etc.hpcmips: ttys
src/etc/etc.hppa: ttys
src/etc/etc.i386: ttys
src/etc/etc.ia64: ttys
src/etc/etc.iyonix: ttys
src/etc/etc.landisk: ttys
src/etc/etc.luna68k: ttys
src/etc/etc.mipsco: ttys
src/etc/etc.mmeye: ttys
src/etc/etc.mvme68k: ttys
src/etc/etc.mvmeppc: ttys
src/etc/etc.netwinder: ttys
src/etc/etc.news68k: ttys
src/etc/etc.newsmips: ttys
src/etc/etc.next68k: ttys
src/etc/etc.or1k: ttys
src/etc/etc.playstation2: ttys
src/etc/etc.pmax: ttys
src/etc/etc.riscv: ttys
src/etc/etc.sandpoint: ttys
src/etc/etc.sbmips: ttys
src/etc/etc.sgimips: ttys
src/etc/etc.shark: ttys
src/etc/etc.sparc: ttys
src/etc/etc.sparc64: ttys
src/etc/etc.vax: ttys
src/etc/etc.zaurus: ttys

Log Message:
Switch default console tty from /dev/console to /dev/constty

With this switch processes (such as xconsole) can open /dev/console
without breaking login on the text or serial console. This can be
trivially triggered by enabling xdm in rc.conf and hitting
Ctrl+Alt+F1 or equivalent once booted.

The changes:
- Add entry for /dev/console or /dev/constty if missing
- If a port's had /dev/console 'on' switch it off and enable /dev/constty
- If a port did not have /dev/console 'on', leave /dev/constty off

Some ports had /dev/console off and /dev/ttyE0 enabled, presumably to
avoid just this issue. It may make sense to adjust these also (but not
in this pass)

As discussed on current-users


To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.aarch64/ttys
cvs rdiff -u -r1.5 -r1.6 src/etc/etc.algor/ttys
cvs rdiff -u -r1.12 -r1.13 src/etc/etc.alpha/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.amd64/ttys
cvs rdiff -u -r1.24 -r1.25 src/etc/etc.amiga/ttys
cvs rdiff -u -r1.3 -r1.4 src/etc/etc.amigappc/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.arc/ttys
cvs rdiff -u -r1.5 -r1.6 src/etc/etc.cesfic/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.emips/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.epoc32/ttys
cvs rdiff -u -r1.7 -r1.8 src/etc/etc.evbarm/ttys
cvs rdiff -u -r1.2 -r1.3 src/etc/etc.evbcf/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.evbmips/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.evbppc/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.evbsh3/ttys
cvs rdiff -u -r1.2 -r1.3 src/etc/etc.ews4800mips/ttys
cvs rdiff -u -r1.16 -r1.17 src/etc/etc.hp300/ttys
cvs rdiff -u -r1.11 -r1.12 src/etc/etc.hpcmips/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.hppa/ttys
cvs rdiff -u -r1.20 -r1.21 src/etc/etc.i386/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.ia64/ttys
cvs rdiff -u -r1.4 -r1.5 src/etc/etc.iyonix/ttys
cvs rdiff -u -r1.3 -r1.4 src/etc/etc.landisk/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.luna68k/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.mipsco/ttys
cvs rdiff -u -r1.7 -r1.8 src/etc/etc.mmeye/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.mvme68k/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.mvmeppc/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.netwinder/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.news68k/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.newsmips/ttys
cvs rdiff -u -r1.10 -r1.11 src/etc/etc.next68k/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.or1k/ttys
cvs rdiff -u -r1.6 -r1.7 src/etc/etc.playstation2/ttys
cvs rdiff -u -r1.15 -r1.16 src/etc/etc.pmax/ttys
cvs rdiff -u -r1.1 -r1.2 src/etc/etc.riscv/ttys
cvs rdiff -u -r1.7 -r1.8 src/etc/etc.sandpoint/ttys
cvs rdiff -u -r1.5 -r1.6 src/etc/etc.sbmips/ttys
cvs rdiff -u -r1.10 -r1.11 src/etc/etc.sgimips/ttys
cvs rdiff -u -r1.8 -r1.9 src/etc/etc.shark/ttys
cvs rdiff -u -r1.16 -r1.17 src/etc/etc.sparc/ttys
cvs rdiff -u -r1.11 -r1.12 src/etc/etc.sparc64/ttys
cvs rdiff -u -r1.9 -r1.10 src/etc/etc.vax/ttys
cvs rdiff -u -r1.3 -r1.4 src/etc/etc.zaurus/ttys

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/etc/etc.aarch64/ttys
diff -u src/etc/etc.aarch64/ttys:1.1 src/etc/etc.aarch64/ttys:1.2
--- src/etc/etc.aarch64/ttys:1.1	Sun Aug 10 05:47:36 2014
+++ src/etc/etc.aarch64/ttys	Wed Sep 25 23:09:19 2019
@@ -1,11 +1,11 @@
-# $NetBSD: ttys,v 1.1 2014/08/10 05:47:36 matt Exp $
+# $NetBSD: ttys,v 1.2 2019/09/25 23:09:19 abs Exp $
 #
 #	from: @(#)ttys	5.1 (Berkeley) 4/17/89
 #

Re: CVS commit: src/bin/sleep

2019-01-25 Thread David Brownlee
On Fri, 25 Jan 2019 at 09:30, Valery Ushakov  wrote:
>
> On Fri, Jan 25, 2019 at 10:43:10 +0700, Robert Elz wrote:
>
> > Date:Thu, 24 Jan 2019 16:18:49 +0100
> > From:Joerg Sonnenberger 
> > Message-ID:  <20190124151849.ga10...@britannica.bec.de>
> >
> >   | This is overcomplicated and fragile, IMO. Can we just go back to the old
> >   | code and switch the strtod to strtod_l with LC_C_LOCALE? That solves the
> >   | input problem.
> >
> > We could certainly do that, but while it is a little complicated, I do not
> > really think it is fragile.  Using a locale specific decimal radix in a
> > script is fragile - but the only way to avoid that is either to effectively
> > give up on non-C locales entirely for scripts, or drop all support for
> > fractional numbers as args to any command.
> >
> > Note: the arg to "sleep" might come as ...
> >   echo -n "How many seconds do you want to sleep? "
> >   read secs
> >   sleep "${secs}"
> > (with some error checking).
> >
> > I have no idea why sleep() was made to parse its arg in a locale
> > specific way, but that was done long long ago, and was (according
> > to the comments) done quite deliberately.
> >
> > I think changing that decison (rather than just avoiding the problem,
> > as the current "fix" does) needs more discussion than a few comments
> > on the source-changes-d list.
>
> As someone who actually have to ecnoutner locales in daily life and
> not just think about them sitting in an ivory tower I don't understand
> why do we even have this argument. Locale-specific argument to sleep
> is pure madness, period (no pun intended).

Granted, and no-one is arguing that sleep should not handle the
standard '.' separator.

The only question is what it should do if it is ever called with a
locale specific separator instead - error or take Postel's law and "be
liberal in what you accept".

I think it might be nice to have a way to control behaviour like this
in tools - maybe an environment variable for "disable various
extensions and be more strict in what is accepted", but that is a
separate bikeshed :)

David


Re: CVS commit: src/sys/kern

2018-10-28 Thread David Brownlee
On Sat, 27 Oct 2018 at 07:40, Martin Husemann  wrote:
>
> On Sat, Oct 27, 2018 at 12:26:56AM +0100, David Brownlee wrote:
> > (Sorry if this is a stupid question) - is it at all possible for the
> > call to MAKEDEV to fail in such a way that its not run and no output
> > is generated?
>
> It can fail in various ways, and I am trying to reprove error reporting
> in that situation. However, since we support the "no /dev/console"
> situation in regular setups it is wrong to report an error for that.

Absolutely in agreement it should not be an error message, but an
informative message might be useful. Particularly if we're supporting
MAKEDEV in locations other than /dev then possibly indicating which
MAKEDEV is being called could be reasonable...

Thanks

David


Re: CVS commit: src/sys/kern

2018-10-26 Thread David Brownlee
On Fri, 26 Oct 2018 at 19:41, Martin Husemann  wrote:
>
> On Sat, Oct 27, 2018 at 05:39:30AM +1100, matthew green wrote:
> > FWIW, i liked this because it let me know i had a problem to fix.
> > perhaps the message could be reworded to be less scary, instead
> > of removing it in most cases?
>
> It will always be followed by output from init/MAKEDEV when it creates
> a /dev tmpfs (or fails to do so), so I don't think it is very usefull.

(Sorry if this is a stupid question) - is it at all possible for the
call to MAKEDEV to fail in such a way that its not run and no output
is generated?

David


Re: CVS commit: src/sys

2017-12-15 Thread David Brownlee
On 15 December 2017 at 14:24, Robert Elz  wrote:
>
> Date:Fri, 15 Dec 2017 05:01:17 +
> From:"Kengo NAKAHARA" 
> Message-ID:  <20171215050117.241baf...@cvs.netbsd.org>
>
>   | Fix pullup'ed mbuf leaks.
>   | The match function just requires enough mbuf length.
>
> This is still not correct.   There are no mbuf leaks, I think you did
> not understand maxv's point (if I remember it correctly).
>
> The problem isn't lost mbufs, it is that if code does a m_pullup()
> (or m_ensure_contig() which is essentially the same thing) the
> mbuf chain can be altered.
>
> What that means is that after a call of in_l2tp_match(m, ...) in the
> calling function, the value of m has been lost - using the old one is
> incorrect and anything might happen (up to and including a panic).
>
> This is why so many mbuf functions pass a struct mbuf ** instead of a
> struct mbuf * so when the parameter is changed, it gets passed back to
> the caller.   This function probably needs something like that (the other
> way is returning the updated m value, but I don't think that fits here.)
>
> Unfortunately, because of the way it gets called, this might not be an
> easy change to make.
>
> The problem occurs way back in encap4_input() which does
>
> match = encap4_lookup(m,...);
>
> and then later
>
> encap_fillarg(m, match);
> or
> m_freem(m);
> or
> rip_input(m, off, proto);
>
> all of which use the 'm' that was passed to encap4_lookup().
>
> encap4_lookup does ..
>
> prio = (*ep->func)(m, off, proto, ep->arg);
>
> where *ep->func is in_l2tp_match which does the m_pullup() or now
> m_ensure_contig() instead which potentially changes what 'm' should
> be (the old one may have been freed and replaced by a different one.)

Just wondering, is there scope for a (rather heavy) debug option in
which m_ensure_contig() always returns a new mbuf for valid input?

David


Re: CVS commit: src/distrib/dreamcast/ramdisk

2016-09-18 Thread David Brownlee
On 18 September 2016 at 18:52, Christos Zoulas  wrote:
> On Sep 19,  1:29am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> -- Subject: Re: CVS commit: src/distrib/dreamcast/ramdisk
>
> | christos@ wrote:
> |
> | > Module Name:src
> | > Committed By:   christos
> | > Date:   Sun Sep 18 15:38:05 UTC 2016
> | >
> | > Modified Files:
> | > src/distrib/dreamcast/ramdisk: list
> | >
> | > Log Message:
> | > kill some useless programs (it is not like the dreamcast has a tape drive)
> |
> | - dmesg(8) is so useful for everyone
> | - why drop swapctl(8) but keep disklabel(8)?
> |   (both are useful for me for wd support though)
>
> Don't we have kernfs and cat /kern/msgbuf?
> I thought that disklabel is more useful that swapctl. Perhaps swapctl will
> fit.

Last I checked dmesg was smaller than options KERNFS (that would have
been on an m68k port tho' :)


Re: CVS commit: src

2014-08-13 Thread David Brownlee
On 10 August 2014 21:25, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
 riz@ wrote:

 Module Name:  src
 Committed By: riz
 Date: Sun Aug 10 20:04:30 UTC 2014

 Modified Files:
   src/distrib/newsmips/floppies/ramdisk: Makefile
   src/sys/arch/newsmips/conf: INSTALL

 Log Message:
 Bump the ramdisk size; the longer paths on the build cluster are
 likely enough to put this over the edge.


 To generate a diff of this commit:
 cvs rdiff -u -r1.31 -r1.32 src/distrib/newsmips/floppies/ramdisk/Makefile

 -IMAGESIZE= 2560k
 +IMAGESIZE= 2660k

 Note sysinst(8) requires some spare space in /tmp during installation,
 especially on using non-default settings on choosing installation sets etc.
 on ports which don't use tmpfs or mfs during installation.
 (100KB would be enough for this newsmips case though)

Would it make sense to dd 100K of null data to a file  then delete in
the build to ensure there is enough space in the final image?


re: CVS commit: src/sys/kern

2014-04-27 Thread David Brownlee
I'm away from my machine,  but I believe the simple test for this is to
build.sh a kernel and see if nm shows pool_head
On 26 Apr 2014 20:11, matthew green m...@eterna.com.au wrote:


 David Brownlee writes:
  Module Name:  src
  Committed By: abs
  Date: Sat Apr 26 16:30:05 UTC 2014
 
  Modified Files:
src/sys/kern: subr_pool.c
 
  Log Message:
  Ensure pool_head is non static - for vmstat -i

 did this use to work?

 does it work if you build your kernel with GCC 4.5?

 it was recently noticed that GDB is no longer able to see
 static symbols in netbsd.gdb images, and the preliminary
 testing i've done so far for amd64 shows that GCC 4.5 works.


 .mrg.



Re: CVS commit: src/sbin/mount_ptyfs

2012-09-19 Thread David Brownlee
On 19 September 2012 08:25, matthew green m...@eterna.com.au wrote:

 Module Name:  src
 Committed By: christos
 Date: Tue Sep 18 21:35:43 UTC 2012

 Modified Files:
   src/sbin/mount_ptyfs: mount_ptyfs.8 mount_ptyfs.c

 Log Message:
 remove -c and chroot option; they are always on now

 since -c is in a release (or will be?) how about making it
 just ignored and not documented isntead of failing mounts?

Make it spit something out to stderr for a release or so then lose...


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

2012-08-01 Thread David Brownlee
On 1 August 2012 13:42, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
 christos@ wrote:
 It is simple enough to arrange to be notified about autobuild failures.
[...]

 See above.  I'm afraid automated daily notifies which
 won't stop until real fix are too annoying.

 If it's sent ~bi-weelky like our gnats, it's fine for me.

Possibly an on-failure/on-resume with a weekly current fails?

It could even collate the data nightly and include the details for all
ports, so for example dreamcast-builds@ list gets an email like they
below they can be pretty certain it was an MI change that broke
something...

| Subject: HEAD builds: dreamcast FAIL
|
| Build report for: HEAD 201209091130
|
| dreamcast: FAIL (was OK)
|
| All ports: FAIL (was OK)
| acorn26 acorn32 algor alpha amd64 amiga amigappc arc atari bebox
| cats cesfic cobalt dreamcast emips evbarm evbsh3-sh3eb evbsh3-sh3el
| ews4800mips hp300 hp700 hpcarm hpcmips hpcsh i386 ibmnws iyonix
| landisk luna68k mac68k macppc mipsco mmeye mvme68k mvmeppc netwinder
| news68k newsmips next68k ofppc pmax prep rs6000 sandpoint sbmips-mipseb
| sbmips-mipsel shark sparc sparc64 sun2 sun3 x68k zaurus
|
| All ports: FAIL (unchanged)
| evbmips-mips64eb evbmips-mips64el evbmips-mipseb evbmips-mipsel evbppc
| sgimips vax


Re: CVS commit: src/sys/arch/arm/iomd

2012-02-14 Thread David Brownlee
On 14 February 2012 21:09, Michael macallan1...@gmail.com wrote:
 Hello,

 On Tue, 14 Feb 2012 14:25:18 +
 Nick Hudson nick.hud...@gmx.co.uk wrote:

 On Tuesday 14 February 2012 13:11:34 Izumi Tsutsui wrote:
  skrll@ wrote:
   Module Name:      src
   Committed By:     skrll
   Date:             Tue Feb 14 13:04:52 UTC 2012
  
   Modified Files:
     src/sys/arch/arm/iomd: vidcvideo.c
  
   Log Message:
   Pass RI_NO_AUTO to rasops_init so that rasops doesn't attempt to allocate
   memory as we're too early in kernel startup for this.
 
  I always think we should make RI_NO_AUTO default and
  RI_AUTO should be optional, because too many MD drivers
  have been trapped by this silent panic...

 Can't argue with that.

 Yeah. I wish there was a way to know wether we can kmem_alloc() or not.

Surely it must be possible to be able to query the kmem subsystem for
whether its too soon for kmem_alloc()?


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

2012-01-07 Thread David Brownlee
On 31 December 2011 15:41, Jared D. McNeill jmcne...@invisible.ca wrote:
 No reason why it can't be used on other ports, but I wasn't sure the best
 way to solve the bootstrap problem wrt the network stack. In usermode case,
 it listens on a socket provided by the host OS.

Could it not just listen on a port for connections? The console would
not be visible until
an interface had a valid IP, but other than that everything *should*
Just Work...

Alternatively could it be modelled similarly to NFS root, whereby the
system uses dhcp obtained
information (or data set in config) to determine how to make the
console available.

Another random thought - could it be attached *in addition* to an
existing console, providing a way to view and manipulate a console
remotely (providing the appropriate interface remains configured).


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

2011-10-18 Thread David Brownlee
On 18 October 2011 10:07, Jukka Ruohonen jruoho...@iki.fi 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.

Presumably whether to permit autounload should be an option that can
be specified at manual module load time, then the default is less
important.


Re: CVS commit: src

2011-01-28 Thread David Brownlee
On 28 January 2011 14:40, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:

 hpcmips chose and implemented painful fpemul to avoid such discussion,
 IIRC :-)


If emips is going to be using softfloat it looks like it could be an
opportunity for hpcmips
machines of the same endian to gain some better suited pkgsrc binaries :)

As a complete aside whatever is done to address this might be extended to mac68k
which has a selection of machines with broken FPU emulation and as such require
softfloat userlands. Currently someone just builds  provides
softfloat userlands
outside of the project...


CVS commit: src

2010-03-10 Thread David Brownlee
Module Name:src
Committed By:   abs
Date:   Wed Mar 10 23:13:10 UTC 2010

Modified Files:
src/distrib/atari/floppies/prepare: list
src/distrib/mvme68k/miniroot: install.md list
src/distrib/mvme68k/ramdisk: list rd.welcome
src/distrib/notes/mvme68k: install
src/distrib/sets/lists/base: ad.m68000 ad.m68k md.sparc md.sparc64
rescue.ad.m68k rescue.sparc rescue.sparc64 rescue.sun2
src/distrib/sets/lists/comp: md.atari md.mvme68k md.sparc md.sparc64
md.sun2 md.sun3
src/distrib/sun2/miniroot: list
src/distrib/sun2/ramdisk: list
src/distrib/sun3/miniroot: list
src/distrib/sun3/ramdisk: list
src/distrib/utils: Makefile
src/rescue: Makefile
src/sbin: Makefile
Removed Files:
src/rescue: list.edlabel
src/sbin/edlabel: Makefile edlabel.c

Log Message:
Relegate edlabel to use in extremely memory constrained install
ramdisks and prefer disklabel elsewhere.
Based on discussion on affected port lists (port-sparc port-sparc64
port-sun3 port-sun2 port-atari port-mvme68k).
All listed ports plus amd64 test built after change


To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 src/distrib/atari/floppies/prepare/list
cvs rdiff -u -r1.5 -r1.6 src/distrib/mvme68k/miniroot/install.md
cvs rdiff -u -r1.20 -r1.21 src/distrib/mvme68k/miniroot/list
cvs rdiff -u -r1.18 -r1.19 src/distrib/mvme68k/ramdisk/list
cvs rdiff -u -r1.3 -r1.4 src/distrib/mvme68k/ramdisk/rd.welcome
cvs rdiff -u -r1.21 -r1.22 src/distrib/notes/mvme68k/install
cvs rdiff -u -r1.1 -r1.2 src/distrib/sets/lists/base/ad.m68000
cvs rdiff -u -r1.17 -r1.18 src/distrib/sets/lists/base/ad.m68k
cvs rdiff -u -r1.79 -r1.80 src/distrib/sets/lists/base/md.sparc
cvs rdiff -u -r1.78 -r1.79 src/distrib/sets/lists/base/md.sparc64
cvs rdiff -u -r1.2 -r1.3 src/distrib/sets/lists/base/rescue.ad.m68k \
src/distrib/sets/lists/base/rescue.sparc \
src/distrib/sets/lists/base/rescue.sparc64 \
src/distrib/sets/lists/base/rescue.sun2
cvs rdiff -u -r1.55 -r1.56 src/distrib/sets/lists/comp/md.atari
cvs rdiff -u -r1.33 -r1.34 src/distrib/sets/lists/comp/md.mvme68k
cvs rdiff -u -r1.68 -r1.69 src/distrib/sets/lists/comp/md.sparc
cvs rdiff -u -r1.53 -r1.54 src/distrib/sets/lists/comp/md.sparc64
cvs rdiff -u -r1.17 -r1.18 src/distrib/sets/lists/comp/md.sun2
cvs rdiff -u -r1.59 -r1.60 src/distrib/sets/lists/comp/md.sun3
cvs rdiff -u -r1.15 -r1.16 src/distrib/sun2/miniroot/list
cvs rdiff -u -r1.10 -r1.11 src/distrib/sun2/ramdisk/list
cvs rdiff -u -r1.24 -r1.25 src/distrib/sun3/miniroot/list
cvs rdiff -u -r1.6 -r1.7 src/distrib/sun3/ramdisk/list
cvs rdiff -u -r1.18 -r1.19 src/distrib/utils/Makefile
cvs rdiff -u -r1.26 -r1.27 src/rescue/Makefile
cvs rdiff -u -r1.1 -r0 src/rescue/list.edlabel
cvs rdiff -u -r1.115 -r1.116 src/sbin/Makefile
cvs rdiff -u -r1.18 -r0 src/sbin/edlabel/Makefile
cvs rdiff -u -r1.17 -r0 src/sbin/edlabel/edlabel.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src

2010-03-10 Thread David Brownlee
Module Name:src
Committed By:   abs
Date:   Wed Mar 10 23:13:10 UTC 2010

Modified Files:
src/distrib/atari/floppies/prepare: list
src/distrib/mvme68k/miniroot: install.md list
src/distrib/mvme68k/ramdisk: list rd.welcome
src/distrib/notes/mvme68k: install
src/distrib/sets/lists/base: ad.m68000 ad.m68k md.sparc md.sparc64
rescue.ad.m68k rescue.sparc rescue.sparc64 rescue.sun2
src/distrib/sets/lists/comp: md.atari md.mvme68k md.sparc md.sparc64
md.sun2 md.sun3
src/distrib/sun2/miniroot: list
src/distrib/sun2/ramdisk: list
src/distrib/sun3/miniroot: list
src/distrib/sun3/ramdisk: list
src/distrib/utils: Makefile
src/rescue: Makefile
src/sbin: Makefile
Removed Files:
src/rescue: list.edlabel
src/sbin/edlabel: Makefile edlabel.c

Log Message:
Relegate edlabel to use in extremely memory constrained install
ramdisks and prefer disklabel elsewhere.
Based on discussion on affected port lists (port-sparc port-sparc64
port-sun3 port-sun2 port-atari port-mvme68k).
All listed ports plus amd64 test built after change


To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 src/distrib/atari/floppies/prepare/list
cvs rdiff -u -r1.5 -r1.6 src/distrib/mvme68k/miniroot/install.md
cvs rdiff -u -r1.20 -r1.21 src/distrib/mvme68k/miniroot/list
cvs rdiff -u -r1.18 -r1.19 src/distrib/mvme68k/ramdisk/list
cvs rdiff -u -r1.3 -r1.4 src/distrib/mvme68k/ramdisk/rd.welcome
cvs rdiff -u -r1.21 -r1.22 src/distrib/notes/mvme68k/install
cvs rdiff -u -r1.1 -r1.2 src/distrib/sets/lists/base/ad.m68000
cvs rdiff -u -r1.17 -r1.18 src/distrib/sets/lists/base/ad.m68k
cvs rdiff -u -r1.79 -r1.80 src/distrib/sets/lists/base/md.sparc
cvs rdiff -u -r1.78 -r1.79 src/distrib/sets/lists/base/md.sparc64
cvs rdiff -u -r1.2 -r1.3 src/distrib/sets/lists/base/rescue.ad.m68k \
src/distrib/sets/lists/base/rescue.sparc \
src/distrib/sets/lists/base/rescue.sparc64 \
src/distrib/sets/lists/base/rescue.sun2
cvs rdiff -u -r1.55 -r1.56 src/distrib/sets/lists/comp/md.atari
cvs rdiff -u -r1.33 -r1.34 src/distrib/sets/lists/comp/md.mvme68k
cvs rdiff -u -r1.68 -r1.69 src/distrib/sets/lists/comp/md.sparc
cvs rdiff -u -r1.53 -r1.54 src/distrib/sets/lists/comp/md.sparc64
cvs rdiff -u -r1.17 -r1.18 src/distrib/sets/lists/comp/md.sun2
cvs rdiff -u -r1.59 -r1.60 src/distrib/sets/lists/comp/md.sun3
cvs rdiff -u -r1.15 -r1.16 src/distrib/sun2/miniroot/list
cvs rdiff -u -r1.10 -r1.11 src/distrib/sun2/ramdisk/list
cvs rdiff -u -r1.24 -r1.25 src/distrib/sun3/miniroot/list
cvs rdiff -u -r1.6 -r1.7 src/distrib/sun3/ramdisk/list
cvs rdiff -u -r1.18 -r1.19 src/distrib/utils/Makefile
cvs rdiff -u -r1.26 -r1.27 src/rescue/Makefile
cvs rdiff -u -r1.1 -r0 src/rescue/list.edlabel
cvs rdiff -u -r1.115 -r1.116 src/sbin/Makefile
cvs rdiff -u -r1.18 -r0 src/sbin/edlabel/Makefile
cvs rdiff -u -r1.17 -r0 src/sbin/edlabel/edlabel.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/distrib/atari/floppies/prepare/list
diff -u src/distrib/atari/floppies/prepare/list:1.8 src/distrib/atari/floppies/prepare/list:1.9
--- src/distrib/atari/floppies/prepare/list:1.8	Sun Feb 21 20:09:50 2010
+++ src/distrib/atari/floppies/prepare/list	Wed Mar 10 23:13:09 2010
@@ -1,4 +1,4 @@
-#	$NetBSD: list,v 1.8 2010/02/21 20:09:50 tsutsui Exp $
+#	$NetBSD: list,v 1.9 2010/03/10 23:13:09 abs Exp $
 
 PROG	bin/cat
 PROG	bin/chmod
@@ -44,6 +44,7 @@
 
 SPECIAL	gzip		srcdir	distrib/utils/x_gzip
 SPECIAL	umount		srcdir	distrib/utils/x_umount
+SPECIAL	edlabel		srcdir	distrib/utils/edlabel
 
 # The installation scripts
 COPY	${CURDIR}/install.md		install.md

Index: src/distrib/mvme68k/miniroot/install.md
diff -u src/distrib/mvme68k/miniroot/install.md:1.5 src/distrib/mvme68k/miniroot/install.md:1.6
--- src/distrib/mvme68k/miniroot/install.md:1.5	Fri May  2 18:31:11 2008
+++ src/distrib/mvme68k/miniroot/install.md	Wed Mar 10 23:13:09 2010
@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-#	$NetBSD: install.md,v 1.5 2008/05/02 18:31:11 martin Exp $
+#	$NetBSD: install.md,v 1.6 2010/03/10 23:13:09 abs Exp $
 #
 # Copyright (c) 1996 The NetBSD Foundation, Inc.
 # All rights reserved.
@@ -179,7 +179,7 @@
 __md_prep_disklabel_1
 	echo -n Press [Enter] to continue 
 	getresp 
-	edlabel /dev/r${_disk}c
+	disklabel -i -I /dev/r${_disk}c
 }
 
 md_copy_kernel() {

Index: src/distrib/mvme68k/miniroot/list
diff -u src/distrib/mvme68k/miniroot/list:1.20 src/distrib/mvme68k/miniroot/list:1.21
--- src/distrib/mvme68k/miniroot/list:1.20	Thu Feb 11 09:06:49 2010
+++ src/distrib/mvme68k/miniroot/list	Wed Mar 10 23:13:09 2010
@@ -1,8 +1,7 @@
-#	$NetBSD: list,v 1.20 2010/02/11 09:06:49 roy Exp $
+#	$NetBSD: list,v 1.21 2010/03/10 23:13:09 abs Exp $
 
 # mvme68k's extras
 PROG	sbin/disklabel
-PROG	sbin/edlabel
 PROG	sbin/mount_kernfs
 
 PROG	usr/bin/basename

Index: src/distrib/mvme68k/ramdisk/list
diff -u 

CVS commit: src/distrib/utils/edlabel

2010-03-10 Thread David Brownlee
Module Name:src
Committed By:   abs
Date:   Wed Mar 10 23:16:16 UTC 2010

Added Files:
src/distrib/utils/edlabel: Makefile edlabel.c

Log Message:
Relegate edlabel to use in extremely memory constrained install
ramdisks and prefer disklabel elsewhere.
Based on discussion on affected port lists (port-sparc port-sparc64
port-sun3 port-sun2 port-atari port-mvme68k).
All listed ports plus amd64 test built after change


To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/distrib/utils/edlabel/Makefile \
src/distrib/utils/edlabel/edlabel.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Added files:

Index: src/distrib/utils/edlabel/Makefile
diff -u /dev/null src/distrib/utils/edlabel/Makefile:1.1
--- /dev/null	Wed Mar 10 23:16:16 2010
+++ src/distrib/utils/edlabel/Makefile	Wed Mar 10 23:16:16 2010
@@ -0,0 +1,10 @@
+# $NetBSD: Makefile,v 1.1 2010/03/10 23:16:16 abs Exp $
+# edlabel (Edit Disk LABEL)
+
+NOMAN=	# defined
+
+PROG=	edlabel
+LDADD+=-lutil
+DPADD+=${LIBUTIL}
+
+.include bsd.prog.mk
Index: src/distrib/utils/edlabel/edlabel.c
diff -u /dev/null src/distrib/utils/edlabel/edlabel.c:1.1
--- /dev/null	Wed Mar 10 23:16:16 2010
+++ src/distrib/utils/edlabel/edlabel.c	Wed Mar 10 23:16:16 2010
@@ -0,0 +1,535 @@
+/*	$NetBSD: edlabel.c,v 1.1 2010/03/10 23:16:16 abs Exp $	*/
+
+/*
+ * Copyright (c) 1995 Gordon W. Ross
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include sys/cdefs.h
+#include sys/types.h
+#include sys/param.h
+#include sys/ioctl.h
+#define FSTYPENAMES
+#include sys/disklabel.h
+
+#include fcntl.h
+#include stdio.h
+#include ctype.h
+#include string.h
+#include errno.h
+#include unistd.h
+#include util.h
+#include stdlib.h
+
+/*
+ * Machine dependent constants you want to retrieve only once...
+ */
+int rawpartition, maxpartitions;
+
+/*
+ * This is a data-driven program
+ */
+struct field {
+	const char *f_name;
+	int f_offset;
+	int f_type;	/* 1:char, 2:short, 4:int, 4:string */
+};
+
+/* Table describing fields in the head of a disklabel. */
+#define	dloff(f) (int)(((struct disklabel *)0)-f)
+struct field label_head[] = {
+  { type_num, dloff(d_type), 2 },
+  { sub_type, dloff(d_subtype), 2 },
+  {type_name, dloff(d_typename), 16 },
+  {pack_name, dloff(d_packname),  16 },
+  { bytes/sector, dloff(d_secsize), 4 },
+  {sectors/track, dloff(d_nsectors), 4 },
+  {  tracks/cylinder, dloff(d_ntracks),  4 },
+  {cylinders, dloff(d_ncylinders), 4 },
+  { sectors/cylinder, dloff(d_secpercyl), 4 },
+  /* Don't care about the others until later... */
+  { .f_name = NULL },
+};
+#undef dloff
+
+void	check_divisors(struct disklabel *);
+u_short	dkcksum(struct disklabel *);
+void	edit_geo(struct disklabel *);
+void	edit_head_all(struct disklabel *, int);
+void	edit_head_field(void *, struct field *, int);
+void	edit_partition(struct disklabel *, int, int);
+void	get_fstype(char *, u_int8_t *);
+void	get_val_cts(struct disklabel *, char *, u_int32_t *);
+void	label_modify(struct disklabel *, char *);
+void	label_print(struct disklabel *, char *);
+void	label_quit(struct disklabel *, char *);
+void	label_read(struct disklabel *, char *);
+void	label_write(struct disklabel *, char *);
+void	menu(void);
+void	print_val_cts(struct disklabel *, u_long val);
+
+char	tmpbuf[64];
+
+void
+edit_head_field(void *v, struct field *f, int modify /* also modify */)
+{
+	u_int8_t  *cp;
+	u_int tmp;
+
+	cp = v;
+	cp += f-f_offset;
+
+	printf(%s: , f-f_name);
+
+	/* Print current value... */
+	switch (f-f_type) {
+	case 1:
+		tmp = *cp;
+		printf(%d, tmp);
+		break;
+	case 2:
+		tmp = *((u_int16_t *)cp);
+		printf(%d, tmp);
+		break;
+	case 4:
+		

CVS commit: src/distrib/utils/edlabel

2010-03-10 Thread David Brownlee
Module Name:src
Committed By:   abs
Date:   Wed Mar 10 23:16:16 UTC 2010

Added Files:
src/distrib/utils/edlabel: Makefile edlabel.c

Log Message:
Relegate edlabel to use in extremely memory constrained install
ramdisks and prefer disklabel elsewhere.
Based on discussion on affected port lists (port-sparc port-sparc64
port-sun3 port-sun2 port-atari port-mvme68k).
All listed ports plus amd64 test built after change


To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/distrib/utils/edlabel/Makefile \
src/distrib/utils/edlabel/edlabel.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/share/mk

2009-12-30 Thread David Brownlee
Module Name:src
Committed By:   abs
Date:   Wed Dec 30 20:45:46 UTC 2009

Modified Files:
src/share/mk: bsd.README

Log Message:
Add note on SHLIB_{MAJOR,MINOR,TEENY}


To generate a diff of this commit:
cvs rdiff -u -r1.262 -r1.263 src/share/mk/bsd.README

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



Re: CVS commit: src/distrib

2009-09-21 Thread David Brownlee

On Mon, 21 Sep 2009, Izumi Tsutsui wrote:


Can't it use src/distrib/common/mktermcap script?


With the ~same set of terminals (actually dropping 'unknown'),
mktermcap generates a 7723 byte termcap file, as opposed to the
6987 byte 'hand crafted' one. Its not really much different,
but on very space constrained install media maybe thats enough
to make a difference? I'm not certain which way to go...

--
David/absolute   -- www.NetBSD.org: No hype required --


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

2009-08-31 Thread David Brownlee

On Sun, 30 Aug 2009, David Brownlee wrote:


From: Jared D. McNeill jmcne...@netbsd.org

Log Message:
PR# port-i386/39671: panic while booting with an acpi kernel on a 790GX 
board


If the firmware describes duplicate keyboard controller nodes, don't panic
when the driver fails to map registers.


Is tis suitable for a pullup to netbsd-5?


Just a (very limited) testing report, have tested the patch on
two netbsd-5 boxes, one which paniced and one which did not and
they both boot fine with it :)

--
David/absolute   -- www.NetBSD.org: No hype required --


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

2009-08-30 Thread David Brownlee

From: Jared D. McNeill jmcne...@netbsd.org

Modified Files:
 src/sys/dev/acpi: pckbc_acpi.c

Log Message:
PR# port-i386/39671: panic while booting with an acpi kernel on a 790GX 
board


If the firmware describes duplicate keyboard controller nodes, don't 
panic

when the driver fails to map registers.


Is tis suitable for a pullup to netbsd-5?
Thanks :)