CVS commit: src/usr.sbin/vnconfig

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Sat Oct 21 23:42:03 UTC 2023

Modified Files:
src/usr.sbin/vnconfig: vnconfig.8

Log Message:
vnconfig.8: Don't mention ciphertext

After all, this is not cgd(4).


To generate a diff of this commit:
cvs rdiff -u -r1.49 -r1.50 src/usr.sbin/vnconfig/vnconfig.8

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

CVS commit: src/usr.sbin/vnconfig

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Sat Oct 21 23:42:03 UTC 2023

Modified Files:
src/usr.sbin/vnconfig: vnconfig.8

Log Message:
vnconfig.8: Don't mention ciphertext

After all, this is not cgd(4).


To generate a diff of this commit:
cvs rdiff -u -r1.49 -r1.50 src/usr.sbin/vnconfig/vnconfig.8

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

Modified files:

Index: src/usr.sbin/vnconfig/vnconfig.8
diff -u src/usr.sbin/vnconfig/vnconfig.8:1.49 src/usr.sbin/vnconfig/vnconfig.8:1.50
--- src/usr.sbin/vnconfig/vnconfig.8:1.49	Sat Oct 21 23:38:26 2023
+++ src/usr.sbin/vnconfig/vnconfig.8	Sat Oct 21 23:42:03 2023
@@ -1,4 +1,4 @@
-.\"	$NetBSD: vnconfig.8,v 1.49 2023/10/21 23:38:26 gdt Exp $
+.\"	$NetBSD: vnconfig.8,v 1.50 2023/10/21 23:42:03 gdt Exp $
 .\"
 .\" Copyright (c) 1997 The NetBSD Foundation, Inc.
 .\" All rights reserved.
@@ -110,8 +110,8 @@ accesses separated in time, this is gene
 This bypassing behavior results in not updating the modification
 timestamp of the file.
 Also, file contents read through the filesystem (and thus the
-filesystem's caching layer) may not be the correct values of
-ciphertext, so caution is in order for backups.
+filesystem's caching layer) may not be the contents written via this
+interface, so caution is in order for backups.
 The
 .Fl i
 option may be useful if it is necessary to avoid inconsistent caching.

CVS commit: src/usr.sbin/vnconfig

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Sat Oct 21 23:38:26 UTC 2023

Modified Files:
src/usr.sbin/vnconfig: vnconfig.8

Log Message:
vnconfig: Improve recent caching edit to man page

Explain that typical usage patterns don't run into consistency issues.
Xref the -i flag.

Leave ambiguous the nature of cache inconsistency, because I don't
undersstand it and it's best not to make it a defined interface
anyway.  I am unclear on whether a buffer cache read before a vnd
session might persist after a vnd is configured/used/unconfigured, and
whether a buffer cache write might be delayed until after a vnd
configure/write.


To generate a diff of this commit:
cvs rdiff -u -r1.48 -r1.49 src/usr.sbin/vnconfig/vnconfig.8

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

Modified files:

Index: src/usr.sbin/vnconfig/vnconfig.8
diff -u src/usr.sbin/vnconfig/vnconfig.8:1.48 src/usr.sbin/vnconfig/vnconfig.8:1.49
--- src/usr.sbin/vnconfig/vnconfig.8:1.48	Fri Oct 20 13:04:21 2023
+++ src/usr.sbin/vnconfig/vnconfig.8	Sat Oct 21 23:38:26 2023
@@ -1,4 +1,4 @@
-.\"	$NetBSD: vnconfig.8,v 1.48 2023/10/20 13:04:21 wiz Exp $
+.\"	$NetBSD: vnconfig.8,v 1.49 2023/10/21 23:38:26 gdt Exp $
 .\"
 .\" Copyright (c) 1997 The NetBSD Foundation, Inc.
 .\" All rights reserved.
@@ -100,12 +100,21 @@ The
 is a special file of raw partition or name of vnode disk like
 .Pa vnd0 .
 .Pp
-By default, accesses to the file bypass normal mechanisms.
-This behavior results in not updating the modification timestamp
-of the file.
-Also, file contents read through the filesystem may not be the
-correct values of ciphertext, which can lead to corrupted backups of
-the backing file.
+By default, accesses to the file bypass normal mechanisms and thus
+do not read from or fill the filesystem cache.
+Because the typical approach is to access the file only via
+.Xr vnd 4 ,
+or at least to have regular accesses and
+.Xr vnd 4
+accesses separated in time, this is generally not problematic.
+This bypassing behavior results in not updating the modification
+timestamp of the file.
+Also, file contents read through the filesystem (and thus the
+filesystem's caching layer) may not be the correct values of
+ciphertext, so caution is in order for backups.
+The
+.Fl i
+option may be useful if it is necessary to avoid inconsistent caching.
 .Pp
 Options indicate an action to be performed:
 .Bl -tag -width indent

CVS commit: src/usr.sbin/vnconfig

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Sat Oct 21 23:38:26 UTC 2023

Modified Files:
src/usr.sbin/vnconfig: vnconfig.8

Log Message:
vnconfig: Improve recent caching edit to man page

Explain that typical usage patterns don't run into consistency issues.
Xref the -i flag.

Leave ambiguous the nature of cache inconsistency, because I don't
undersstand it and it's best not to make it a defined interface
anyway.  I am unclear on whether a buffer cache read before a vnd
session might persist after a vnd is configured/used/unconfigured, and
whether a buffer cache write might be delayed until after a vnd
configure/write.


To generate a diff of this commit:
cvs rdiff -u -r1.48 -r1.49 src/usr.sbin/vnconfig/vnconfig.8

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

CVS commit: src/usr.sbin/vnconfig

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Fri Oct 20 12:45:17 UTC 2023

Modified Files:
src/usr.sbin/vnconfig: vnconfig.8

Log Message:
vnconfig: Add caution to man page about cache bypassing behavior


To generate a diff of this commit:
cvs rdiff -u -r1.46 -r1.47 src/usr.sbin/vnconfig/vnconfig.8

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

Modified files:

Index: src/usr.sbin/vnconfig/vnconfig.8
diff -u src/usr.sbin/vnconfig/vnconfig.8:1.46 src/usr.sbin/vnconfig/vnconfig.8:1.47
--- src/usr.sbin/vnconfig/vnconfig.8:1.46	Sat Jan  9 23:54:26 2021
+++ src/usr.sbin/vnconfig/vnconfig.8	Fri Oct 20 12:45:17 2023
@@ -1,4 +1,4 @@
-.\"	$NetBSD: vnconfig.8,v 1.46 2021/01/09 23:54:26 wiz Exp $
+.\"	$NetBSD: vnconfig.8,v 1.47 2023/10/20 12:45:17 gdt Exp $
 .\"
 .\" Copyright (c) 1997 The NetBSD Foundation, Inc.
 .\" All rights reserved.
@@ -100,6 +100,12 @@ The
 is a special file of raw partition or name of vnode disk like
 .Pa vnd0 .
 .Pp
+By default, accesses to the file bypass normal mechanisms.  This
+behavior results in not updating the modification timestamp of the
+file.  Also, file contents read through the filesystem may not be the
+correct values of ciphertext, which can lead to corrupted backups of
+the backing file.
+.Pp
 Options indicate an action to be performed:
 .Bl -tag -width indent
 .It Fl c

CVS commit: src/usr.sbin/vnconfig

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Fri Oct 20 12:45:17 UTC 2023

Modified Files:
src/usr.sbin/vnconfig: vnconfig.8

Log Message:
vnconfig: Add caution to man page about cache bypassing behavior


To generate a diff of this commit:
cvs rdiff -u -r1.46 -r1.47 src/usr.sbin/vnconfig/vnconfig.8

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

CVS commit: src/distrib/amd64/installimage

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Mon Aug 14 13:54:05 UTC 2023

Modified Files:
src/distrib/amd64/installimage: installimage.mk

Log Message:
amd64 installimage: Reduce non-xz size slightly to fit 4GB flash drives

The installimage sizes were bumped in 2022 because of some growth, and
the case for not-xz sets went to 4000 (MiB).  That's just over what a
lot of "4 GB" flash drives are, but seems obviously intended to fit.
The actual usage of the filesystem, from a current build from earlier
this year (with non-xz sets) is:

/dev/dk1   3.7G   833M   2.7G  23% /mnt

and similar for netbsd-10 built yesterday, so we can afford to shrink
slightly.  Drop to 3800, which is still huge, but will make 4 GB flash
drives work.


To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/distrib/amd64/installimage/installimage.mk

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

Modified files:

Index: src/distrib/amd64/installimage/installimage.mk
diff -u src/distrib/amd64/installimage/installimage.mk:1.3 src/distrib/amd64/installimage/installimage.mk:1.4
--- src/distrib/amd64/installimage/installimage.mk:1.3	Sat Jul 30 00:55:38 2022
+++ src/distrib/amd64/installimage/installimage.mk	Mon Aug 14 13:54:05 2023
@@ -1,4 +1,4 @@
-#	$NetBSD: installimage.mk,v 1.3 2022/07/30 00:55:38 pgoyette Exp $
+#	$NetBSD: installimage.mk,v 1.4 2023/08/14 13:54:05 gdt Exp $
 
 # common code between distrib/amd64/installimage/Makefile and
 # distrib/amd64/installimage-bios/Makefile.
@@ -6,7 +6,7 @@
 .if ${USE_XZ_SETS:Uno} != "no"
 INSTIMAGEMB?=	2500			# for all installation binaries
 .else
-INSTIMAGEMB?=	4000			# for all installation binaries
+INSTIMAGEMB?=	3800			# for all installation binaries
 .endif
 
 PRIMARY_BOOT=		bootxx_ffsv1

CVS commit: src/distrib/amd64/installimage

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Mon Aug 14 13:54:05 UTC 2023

Modified Files:
src/distrib/amd64/installimage: installimage.mk

Log Message:
amd64 installimage: Reduce non-xz size slightly to fit 4GB flash drives

The installimage sizes were bumped in 2022 because of some growth, and
the case for not-xz sets went to 4000 (MiB).  That's just over what a
lot of "4 GB" flash drives are, but seems obviously intended to fit.
The actual usage of the filesystem, from a current build from earlier
this year (with non-xz sets) is:

/dev/dk1   3.7G   833M   2.7G  23% /mnt

and similar for netbsd-10 built yesterday, so we can afford to shrink
slightly.  Drop to 3800, which is still huge, but will make 4 GB flash
drives work.


To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/distrib/amd64/installimage/installimage.mk

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

CVS commit: src/share/man/man4

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Sat Jul 29 23:11:51 UTC 2023

Modified Files:
src/share/man/man4: nvmm.4

Log Message:
nvmm(4): Document that VMX Unrestricted Guest is required


To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/share/man/man4/nvmm.4

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

Modified files:

Index: src/share/man/man4/nvmm.4
diff -u src/share/man/man4/nvmm.4:1.6 src/share/man/man4/nvmm.4:1.7
--- src/share/man/man4/nvmm.4:1.6	Sat Sep  5 07:22:25 2020
+++ src/share/man/man4/nvmm.4	Sat Jul 29 23:11:50 2023
@@ -1,4 +1,4 @@
-.\"	$NetBSD: nvmm.4,v 1.6 2020/09/05 07:22:25 maxv Exp $
+.\"	$NetBSD: nvmm.4,v 1.7 2023/07/29 23:11:50 gdt Exp $
 .\"
 .\" Copyright (c) 2018-2020 Maxime Villard, m00nbsd.net
 .\" All rights reserved.
@@ -26,7 +26,7 @@
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
-.Dd February 9, 2020
+.Dd July 30, 2023
 .Dt NVMM 4
 .Os
 .Sh NAME
@@ -52,6 +52,10 @@ x86-SVM, for x86 AMD CPUs
 .It
 x86-VMX, for x86 Intel CPUs
 .El
+Note that for VMX support, the CPU must also support "VMX Unrestricted
+Guest", which is only present if Extended Page Tables (EPT) is
+supported.  The earliest CPU family with this feature is Westmere, and
+not all later CPUs have it.
 .Sh SEE ALSO
 .Xr libnvmm 3 ,
 .Xr nvmmctl 8

CVS commit: src/share/man/man4

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Sat Jul 29 23:11:51 UTC 2023

Modified Files:
src/share/man/man4: nvmm.4

Log Message:
nvmm(4): Document that VMX Unrestricted Guest is required


To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/share/man/man4/nvmm.4

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

Re: CVS commit: src/sbin/newfs

[Greg Troxel]

Taylor R Campbell  writes:

> Well, what happened is:
>
> 1. I was drafting posix_memalign and aligned_alloc for libbsdmalloc in
>response to the thread about static program size yesterday, and
>carefully reading the specs -- POSIX 2018, C11 -- to make sure I
>got all the details right.
>
> 2. I saw a silly restriction in C11, that aligned_alloc(A, S) requires
>A to divide S.
>
> 3. For the sake of encouraging portable code, I figured we should
>enforce that restriction, so I went ahead and did that in both the
>libbsdmalloc front end I was writing and in jemalloc.  (This caused
>a bunch of tests to start failing.)
>
> 4. I audited all the uses of aligned_alloc in tree to make sury they
>meet the restriction (which fixed the tests).
>
> 5. Someone pointed out that the silly restriction that was imposed in
>C11 had actually been lifted in C17:
>
> (C11) The value of alignment shall be a valid alignment
> supported by the implementation and the value of size shall be
> an integral multiple of alignment.
>
> (C17) If the value of alignment is not a valid alignment
> supported by the implementation the function shall fail by
> returning a null pointer.
>
> 6. So I reverted the jemalloc enforcement of the C11 restriction, and
>reverted the fixes made to conform to it, and removed the
>restriction in the new libbsdmalloc code, and we're more or less
>back to where we started.
>
> Except I am now reminded that I updated t_posix_memalign.c to verify
> this silly restriction of aligned_alloc, so I'd better go fix that
> before a bunch of tests start failing again!

Thanks for taking the time to explain so thoroughly.  So we are back to
status quo ante-fixum, which is by definition always ok :-)

Re: CVS commit: src/sys/arch/i386/stand/bootxx

[Greg Troxel]

Emmanuel Dreyfus  writes:

> On Thu, Jun 29, 2023 at 08:43:36PM -0400, Greg Troxel wrote:
>> > Primary bootstrap is now able to read a GPT inside RAIDframe.
>> did you also update documentation?
>
> We do not have any documentation specific to primary bootstrap. 
> x86/boot(8) domuent the behavior with no detail about primary
> and secondary bootstrap distinct roles.
>
> The change makes primary bootstrap behavior in line with secondary
> bootstrap and with what is already documented in x86/boot(8). Hence
> there is no documentation update, we could consider it as a bug fix, 
> since the previosu behavior did not match x86/boot(8) documentation.

Thank you for explaining.  That sounds fine then.

Re: CVS commit: src/sys/arch/i386/stand/bootxx

[Greg Troxel]

"Emmanuel Dreyfus"  writes:

> Log Message:
> Primary bootstrap is now able to read a GPT inside RAIDframe.

did you also update documentation?

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

[Greg Troxel]

Taylor R Campbell  writes:

> jschauma@'s change did help clarify (1) and (2).  Let's try to work
> together to make it better?

Well said.


I can shed a little light on some of the questions.

> 1. What is `arch' or `archived' supposed to mean?  Who sets it, who
>pays attention to it, and what consequences does it have?  Is it
>obsolete?  What was it used for?  From the current text, I have no
>idea!

>From reading sources, I think it is exactly "the archive bit is set in
the foreign filesystem entry that this vnode is representting" and that
it is basically an MS-DOS thing that is likely not important (even to
people that do not dismiss all things Windows!) any more.

> 2. What is `nodump' supposed to mean?  Who sets it, who pays attention
>to it, and what consequences does it have?  Does the kernel do
>anything about it, or is it just an extra bit of storage that
>programs like dump(8) can choose to examine?  From the current
>text, I have no idea!

I believe it is just a bit that other programs can query, and that the
intent is that dump(8) will decline to dump files with the bit set.

(I intend, in my Copious Spare Time, to extend pkgsrc/sysutils/bup to
respect this flag.  I have previously made extensive use of nodump with
dump.  Partly because of lack of the bit in bup and partly for
organizational sanity, I use /u0 and /n0 for things that should and
should not be backed up.  But that's me in case it helps motivate why
nodump is useful, not about flag docs.)

I believe that nodump continues to be relevant today.

> 3. What is the difference between `system' and `user' immutable or
>append-only?  If I set uchg, does that mean the _owner_ can't
>modify the file, or that _nobody_ can modify the file?

Not useful for a 1 man page, but

  egrep '[SU]F_' /usr/include/sys/stat.h

is illuminating to programmers.

I believe, but would have to read the code to be 100% sure, that

  only root can modify schg and sappnd flags (and archive)

  either root or the owner can modify other flags (except on
  device files, on which only root may modify flags, for reasons that
  are unclear, but the rationale seems unimportant)

  etiher schg or uchg means the file can't be modified, probably, but
  it's possible that uchg applies to everybody but root and schg applies
  to everybody.  A quick experiment shows that root cannot write to a
  gdt-owned file with the uchg bit set.

Fundamentally there are 16 flag bits for user and 16 for system and I
think it is baked in hard that only root can modify the system set.

> jschauma@'s change did help clarify (1) and (2).  Let's try to work
> together to make it better?

The fundamental issue is that the table attempts to

  - map the tokens used by chflags(1) (good)

  - to names that sort of represent the flags (which are fundamentally C
preprocessor token) but are a third namespace that exists only here
(bad)

  - describe the flags permissions as if they are individual, instead of
simly saying that schg and sappend may be changed by superuser
only (confusing)

  - does not give semantics (ok, because that is not consistent with a
table)

Also, the man page does not explain that because "nodump" is the name of
a flag, one does "chflags dump foo" to remove the nodump flag.

(I don't think it needs explanation that the design decision is that
nodump is a flag, instead of dump, because the norms are that files tend
not to have any flags set and that all files should be backed up.)



I would recommend:

  Noting that archive flag represents something in some foreign
  filesystems, currently known to exist only for some MSDOS filesystems,
  and that the specific filesystem should document that.

  Explaining that the nodump flag is a request that backup programs omit
  the file from backups and to see dump(8).

  Be clearer about permissions.

  Drop the restatement of tokens into a third only-here namespace.
  Instead, use paragraphs following to describe that each token means.

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

[Greg Troxel]

Valery Ushakov  writes:

> On Thu, May 25, 2023 at 07:17:52 -0400, Greg Troxel wrote:
>
>> Jan Schaumann  writes:
>> 
>> > Valery Ushakov  wrote:
>> >> On Wed, May 24, 2023 at 22:33:17 +, Jan Schaumann wrote:
>> >
>> >> > Briefly describe the 'arch' and 'nodump' flags.
>> >> 
>> >> What makes them special and why is that these two have to be described
>> >> here and not in chflags(2), where the flags are actually defined?
>> >
>> > Unlike the other flags, they are not intuitive.  As
>> > they are exposed to the end-user (versus the
>> > programmer), it seems useful to describe them in
>> > section 1 of the manual pages.
>> 
>> FWIW, I agree that the flags are user-facing rather than (only)
>> programmer-facing, and thus should be described in a 1/8 manpage vs only
>> a 2 manpage.
>
> Then *all* of them should be described in a proper narration.  I'm not
> objecting to that.  I'm objecting to sticking the description of two
> of them chosen seemingly at random in a place selected seemingly at
> random.

OK, that's a perfectly reasonable objection.

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

[Greg Troxel]

Jan Schaumann  writes:

> Valery Ushakov  wrote:
>> On Wed, May 24, 2023 at 22:33:17 +, Jan Schaumann wrote:
>
>> > Briefly describe the 'arch' and 'nodump' flags.
>> 
>> What makes them special and why is that these two have to be described
>> here and not in chflags(2), where the flags are actually defined?
>
> Unlike the other flags, they are not intuitive.  As
> they are exposed to the end-user (versus the
> programmer), it seems useful to describe them in
> section 1 of the manual pages.

FWIW, I agree that the flags are user-facing rather than (only)
programmer-facing, and thus should be described in a 1/8 manpage vs only
a 2 manpage.

Re: null-terminated vs. nul-terminated

[Greg Troxel]

"David H. Gutteridge"  writes:

Thanks for the history and it is  all sensible.

> "nul-terminated" and "null-terminated" seemed more common in man pages
> that originated from historical BSD sources, so, lacking any style
> guide, I inferred the lowercase "nul" was more "correct" as "BSD style"
> (excepting modern OpenBSD), even though that looks a bit odd to me. I
> then examined where "nul-terminated" came from, and found these bulk
> commits, which imply a standard.

> date: 2005-01-02 18:38:04 +;  author: wiz;
> Mark up NULL, and replace null by nul where appropriate.
>
> date: 2006-10-16 08:48:45 +;  author: wiz;
> nul/null/NULL cleanup:
> when talking about characters/bytes, use "nul" and "nul-terminate"
> when talking about pointers, use "null pointer" or ".Dv NULL"
>
> So that seemed to me the established style.

It may have been BSD style, but I think it's wrong to use lowercase for
an ASCII codepoint.  And therefore it is confusing to people who know
that the ASCII zero byte is written NUL.




signature.asc
Description: PGP signature

Re: null-terminated vs. nul-terminated

[Greg Troxel]

Taylor R Campbell  writes:

>> Date: Sat, 26 Mar 2022 16:53:19 +0100
>> From: Roland Illig 
>> 
>> The term "null-terminated string" is quite common when talking about C.
>>   In contrast, the word "nul" in "nul-terminated" always reminds me of
>> the character abbreviation in ASCII, which has a narrower scope than C.
>>   I prefer to keep "null-terminated" here.
>
> I feel like I've usually seen it as NUL-terminated.  I thought it was
> in /usr/share/misc/style but I must have been thinking of a different
> style guide.
>
> `NUL' is better than `null' or `NULL' here because it's not a null
> pointer, unlike, e.g., the execve argv terminator.  Even if the string
> isn't US-ASCII, what character encoding calls a nonzero byte `NUL'?
>
> `NUL' is better than `zero' or `0' here because it's unambiguously the
> all-bits-zero byte, not the US-ASCII encoding of `0' (i.e., decimal 48
> or 0x30).

For background I'm a native en_US speaker whose second computer language
was K C from the pre-ANSI edition.

There are three separate concepts.

NULLRefers to a pointer, never to a character

NUL ASCII codepoint, 7 zero bits, and 8 zero bits when stored in an
8-bit byte.  NUL is never properly written nul; the ASCII
codepoints are upper case in formal usage.

nullAn English word that can mean various things, including

   null pointer => NULL

   null character => NUL in ASCII

   null character => 0 in something else, theoretically maybe,
   but C just cannot deal with a character set that uses 0 to
   represent something that gets used in strings.


So one can talk about a "null-terminated string" implying "null
character" which means NUL, and one could also write "NUL-terminated
string".  I find the from NUL-terminated to be artificial.

I perceive "nul-terminated" as an error due to the lower case nul.


signature.asc
Description: PGP signature

Re: CVS commit: src/etc

[Greg Troxel]

Brad Spencer  writes:

> What is referred to here is a specific ZFS idea and should not be
> confused with any sort of global notion.  Specifically, ZFS, by default
> and in common use, does not use anything like a /etc/fstab or
> /etc/vfstab to specify where the filesets get mounted.  It also does not
> usually use the usual mount command either to mount them, although that
> would work in Solaris if I remember correctly (at least in some cases).
> What happens is that the mount point is specified in the fileset meta
> data and "zfs mount " takes care of getting it mounted.  If you
> wanted to use /etc/fstab or /etc/vfstab with ZFS you need to mark the
> mountpoint in the fileset as being legacy, then you could fill in your
> /etc/... files as you wanted.  This, of course, strongly suggests that
> Sun was going to make all of the other filesystems except ZFS second
> class, but Sun fell apart before that really progressed to anything
> final and Oracle never really ran to that conclusion either.  No one is

Somehow I am not shocked that this usage (by Sun) had that lurking.

> at all suggesting that any filesystem become second class in the NetBSD
> realization of ZFS.
>
> So the term legacy when speaking of ZFS is used to refer to a filesystem
> that uses whatever /etc/... files you use and uses the usual mount
> command.

Thanks, and Taylor also sent me a clue privately.A superceding
comment by me crossed in the mail.


signature.asc
Description: PGP signature

Re: CVS commit: src/etc

[Greg Troxel]

I apologize for failing to understand "zfs legacy mount" and incorrectly
associating it with how I usually encounter the word legacy.

I now understand that you meant to separate:

  zfs's preferred path of having mountpoints stored as volume
  properties, which is a different way of specifying what is mounted
  where than everything else, but makes sense in a world with many zfs
  volumes

  having a zfs volume where instead of the normal zfs way, there is an
  fstab entry

So having re-thought I would say:

  It makes sense to have a boolean "critical" property (the name you
  suggested is fine) for zfs volumes that specify a mount point, so that
  such volumes would be mounted in mountcritlocal.  I am 100% happy for
  someone to add that and see no big problems.

  It makes sense to just put zfs volume mountpoints in
  critical_filesystems_local, if those volumes use the fstab method
  instead of mountpoint properties (i.e., are "zfs legacy mounts").

  I think this is tricky if there are multiple pools and some don't come
  up.  But I think it's ok if the main path is that one should have all
  critical zfs filesytems on the same pool as root, with root on zfs.
  With root not on zfs but say /usr and /var on zfs, there needs to be
  some way for the boot to fail if they aren't mountable, just like if
  they were in fstab, if the pool doesn't attach and thus the critical
  variable aren't readable.  That might mean "if root is not zfs, and
  something in critical_fileystems_{local,remote} is in zfs, then those
  things have to use zfs legacy mounts".  It might mean having
  "critical_zfs_pools_{local,remote}" which will fail the boot if they
  are not attached at the mountcritlocal/mountcritremote stage, so that
  the critical properties are reliably there.

  I am opposed to deciding that all zfs filesystems should be treated as
  critical (in a world where we have not abolished the notion).

  We could have a discussion about why we even have the concept of
  critical filesystems, but if so that should not be about zfs and
  should be in a new thread on tech-userlevel.  And, I think it really
  isn't strongly releated to this discussion.


for background, I used to understand the critical filesystem scheme
better, but I'll briefly say (projecting to modern rc.d) that I think
it's about sequencing getting enough filesystems mounted to be able to
hit the NETWORKING rc.d barrier.  Consider a diskless workstation with
separate / and /usr (because /usr is shared across all 10 Sun 3/50s :-)
that also needs to mount some other filesystem from a server beyond the
LAN, which requires running routed.  Sorry if that gives yuo bad
flashbacks to the 80s :-)

In modern NetBSD I put /var and /usr in critical_fileystems_local,
because I want route6d to start, and that's in /usr/sbin.  Arguably
route6d should be in /sbin, or NETWORKING should be split into things
needed to talk to the local link vs the broader network, but I have
avoided digging in because adding a line to rc.conf is easy, and moving
route6d would be actual work.

Greg


signature.asc
Description: PGP signature

Re: CVS commit: src/etc

[Greg Troxel]

Simon Burge  writes:

> I'm running with a complete ZFS-only setup with no legacy mounts.  This
> is my basic ZFS layout (leaving out a few mounts that don't add any more
> value to this discussion):
>
>   NAME  MOUNTPOINT
>   pool0 /pool0
>   pool0/ROOTnone
>   pool0/ROOT/default/
>   pool0/home/home
>   pool0/home/simonb /home/simonb
>   pool0/usr /usr
>   pool0/usr/obj /usr/obj
>   pool0/usr/pkg /usr/pkg
>   pool0/var /var
>   pool0/var/crash   /var/crash
>   pool0/var/log /var/log
>   pool0/var/mail/var/mail
>   pool0/var/tmp /var/tmp
>
> and I then have this grot in my mountcritlocal:
>
>   # XX
>   zfs mount pool0/var
>   zfs mount pool0/var/crash
>   zfs mount pool0/var/log
>   zfs mount pool0/var/mail
>   zfs mount pool0/var/tmp

[I am guessing you have a boot partition that isn't zfs, just to load
the kernel, but I haven't tried to read about that, and it seems a
separate topic.]

I will assume that the / (zfs as you say above) is the only mounted fs
as init starts.

> I have been trying to think of better solutions to this before you added
> this new critical_filesystems_zfs rc.conf variable.  One idea was to add
> a user defined property (eg "netbsd:mountcrit=yes") and use that in a
> similar way to how you implemented mount_critical_filesystems_zfs .  Then
> another idea hit me.
>
> Why don't we just mount all the ZFS filesystems in mountcritlocal?  I
> can't think of any negative reasons for not mounting all non-legacy
> mountable ZFS filesystems early in the boot process. This would be as
> simple as moving this chunk from mountall to mountcritlocal:
>
> # Mount ZFS filesystems first because fstab
> # may try and null mount paths on ZFS.
> if checkyesno zfs; then
> zfs mount -a
> zfs share -a
> fi
>
> and the unmount stuff from mountall to a new mountcritlocal_stop
> function.

[I don't really know what you mean by legacy (other than non-zfs, but
you didn't say that, so perhaps you mean something different).]

I think the big point here  is why do we have a notion of critical
filesystems, and if we are going to mount all zfs filesystems in
mountcritlocal, why would we then not mount all local filesystems?

AIUI, the critical notion comes from the netbooting days and sequencing
of bringing up networking to mount filesystems, which can involve
running programs that aren't on root.

I have used mountcritlocal to mount /var and /usr so that route6d could
start at the time when it is invoked by rc.d, I think, but the details
have been paged out.  I don't see that being a different issue with zfs
for / /var /usr.  Although I see it hitting more people as having
multiple filesystems is a more sensible thing to do with zfs because of
shared pool space.


If we are going to keep the critical concept, then it seems like it
should apply to all filesystems.  If we are going to abandon it, that's
a big discussion for tech-userlevel.

> For people using critical early legacy mounts, they can still be added
> via critical_filesystems_local as that looks up via /etc/fstab (right?
> I haven't tested this).

If you mean /var or /usr as ffs, I would expect so and certainly that's
necessary to support.

> Anyone see a reason for not using this much simpler approach to
> having ZFS filesystems available?  I don't think we'd need to keep
> critical_filesystems_zfs if we change mountcritlocal as I suggest, as
> that explicitly only deals with non-legacy filesystems.

I don't think it's good to treat zfs and non-zfs differently and I don't
think there are any good reasons to do so.  I also don't think its a
good idea to make ffs 2nd class.

If the big thing is to avoid having to manually mark zfs filesystems as
critical in rc.conf, fstab or some other file, and instead use a
property, that sounds like a perfectly fine solution, as the mountpoint
is already in zfs properties, and it makes sense to keep the critical
bit in the same place as the mountpoint.

However, I don't know how it works if you have a 2nd pool with a
critical filesystem and that pool doesn't come up.  (I could see
somebody having RAID1 for / /var and swap and RAIDZ for /usr and
everything else.)  From that viewpoint listing the critical filesystems
in rc.conf, leading to failure if they are not available, seems better.

It also seems like perhaps pools could be marked critical vs not so that
zfs startup can attach the critical pools first, and then the others,
but I suspect that is a lot of work for no gain, and the rc.conf
approach avoids the need.

I am really uncomfortable with a plan that comes from a place of
declaring anything but zfs as "legacy, that 

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

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Thu Mar 25 18:41:29 UTC 2021

Modified Files:
src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_ioctl.c

Log Message:
zfs_ioctl.c: Drop WARNING that ZFS is under development

Following discussions on current-users@, it seems many rely on ZFS to
store data, and there are not particularly large issues with ZFS.  ATF
tests with /tmp as tmpfs, ffs2, and zfs are similar, with only a
slight increase in failures under zfs.

(This commit should probably NOT be pulled up to 9.)


To generate a diff of this commit:
cvs rdiff -u -r1.22 -r1.23 \
src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c

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

Modified files:

Index: src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c
diff -u src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c:1.22 src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c:1.23
--- src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c:1.22	Fri Feb 28 03:52:26 2020
+++ src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c	Thu Mar 25 18:41:29 2021
@@ -7194,7 +7194,6 @@ zfs_modcmd(modcmd_t cmd, void *arg)
 		/* XXXNETBSD trim is not supported yet */
 		zfs_trim_enabled = B_FALSE;
 
-		printf("WARNING: ZFS on NetBSD is under development\n");
 		availrmem = (uint64_t)physmem * PAGE_SIZE / 1048576;
 		if (availrmem < ZFS_MIN_MEGS * 80 / 100) {
 			printf("ERROR: at least %dMB of memory required to "

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

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Thu Mar 25 18:41:29 UTC 2021

Modified Files:
src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_ioctl.c

Log Message:
zfs_ioctl.c: Drop WARNING that ZFS is under development

Following discussions on current-users@, it seems many rely on ZFS to
store data, and there are not particularly large issues with ZFS.  ATF
tests with /tmp as tmpfs, ffs2, and zfs are similar, with only a
slight increase in failures under zfs.

(This commit should probably NOT be pulled up to 9.)


To generate a diff of this commit:
cvs rdiff -u -r1.22 -r1.23 \
src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c

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

Re: CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

matthew green  writes:

> could this be done with include and "no foo" statement?
> eg, like sys/arch/sparc/conf/INSTALL does.

Maybe, but I'm not sure it will end up working.  Right now we don't know
if any of the missing things will be trouble, and even if we do move to
include/no I'd like to do that via an intermediate step of a config with
small differences.

Also I think we should also consider extracting lots of things into
includable files, similar to how

  include "dev/usb/usbdevices.config"

is used now in GENERIC.   That will raise interesting cross-arch issues
about value vs kernel memory usage probably.

These include files would allow a simplification of XEN3_DOMU which as I
see it should have ~no drivers but all the rest of the options.


signature.asc
Description: PGP signature

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Fri Mar  5 20:30:56 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
XEN3_DOM0: Approach GENERIC

When processed to remove comments, blank lines, normalize whitespace,
and sort/uniq (one line was previously duplicated), this file is
identical to the previous version.  It has been reorganized to reduce
diffs to GENERIC, and many missing lines from GENERIC have been added
but commented out.


To generate a diff of this commit:
cvs rdiff -u -r1.191 -r1.192 src/sys/arch/amd64/conf/XEN3_DOM0

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

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Fri Mar  5 20:30:56 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
XEN3_DOM0: Approach GENERIC

When processed to remove comments, blank lines, normalize whitespace,
and sort/uniq (one line was previously duplicated), this file is
identical to the previous version.  It has been reorganized to reduce
diffs to GENERIC, and many missing lines from GENERIC have been added
but commented out.


To generate a diff of this commit:
cvs rdiff -u -r1.191 -r1.192 src/sys/arch/amd64/conf/XEN3_DOM0

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

Modified files:

Index: src/sys/arch/amd64/conf/XEN3_DOM0
diff -u src/sys/arch/amd64/conf/XEN3_DOM0:1.191 src/sys/arch/amd64/conf/XEN3_DOM0:1.192
--- src/sys/arch/amd64/conf/XEN3_DOM0:1.191	Thu Mar  4 16:02:10 2021
+++ src/sys/arch/amd64/conf/XEN3_DOM0	Fri Mar  5 20:30:56 2021
@@ -1,4 +1,4 @@
-# $NetBSD: XEN3_DOM0,v 1.191 2021/03/04 16:02:10 gdt Exp $
+# $NetBSD: XEN3_DOM0,v 1.192 2021/03/05 20:30:56 gdt Exp $
 
 # XEN3_DOM0 machine description file
 #
@@ -14,7 +14,7 @@ include 	"arch/amd64/conf/std.xen"
 
 options 	INCLUDE_CONFIG_FILE	# embed config file in kernel binary
 
-#ident		"XEN3_DOM0-$Revision: 1.191 $"
+#ident		"XEN3_DOM0-$Revision: 1.192 $"
 
 maxusers	32		# estimated number of users
 
@@ -43,9 +43,20 @@ maxusers	32		# estimated number of users
 #options 	PHYSMEM_MAX_SIZE=64	# max size of physical memory (in MB)
 #options 	PHYSMEM_MAX_ADDR=2048	# don't use memory above this (in MB)
 
+## Replace std.amd64 content
+
+mainbus0 at root
+cpu* at mainbus?
+ioapic* at mainbus? apid ?
+
+# Atheros HAL options
+include "external/isc/atheros_hal/conf/std.ath_hal"
+
+## end std.amd64
+
 ## Xen-specific options
 
-options		XENPV		# PV dom0 support
+options 	XENPV		# PV dom0 support
 options 	DOM0OPS
 options 	MULTIPROCESSOR
 #options 	NO_PREEMPTION	# needed if MULTIPROCESSOR is disabled
@@ -58,10 +69,6 @@ options 	MULTIPROCESSOR
 # boot messages with MPBIOS, acpi and ioapic can be quite large
 options 	MSGBUFSIZE=24576
 
-# CPU features
-est0		at cpu0		# Intel Enhanced SpeedStep (non-ACPI)
-powernow0	at cpu0		# AMD PowerNow! and Cool'n'Quiet (non-ACPI)
-
 # Standard system options
 
 options 	INSECURE	# disable kernel security levels - X needs this
@@ -79,10 +86,20 @@ options 	SYSVSEM		# System V-like semaph
 options 	SYSVSHM		# System V-like memory sharing
 
 options 	MODULAR		# new style module(7) framework
+#options 	MODULAR_DEFAULT_AUTOLOAD
 options 	USERCONF	# userconf(4) support
 #options 	PIPE_SOCKETPAIR	# smaller, but slower pipe(2)
 options 	SYSCTL_INCLUDE_DESCR	# Include sysctl descriptions in kernel
 
+# CPU features
+#acpicpu*	at cpu?		# ACPI CPU (including frequency scaling)
+#coretemp*	at cpu?		# Intel on-die thermal sensor
+est0		at cpu0		# Intel Enhanced SpeedStep (non-ACPI)
+#hyperv0 	at cpu0		# Microsoft Hyper-V
+#odcm0		at cpu0		# On-demand clock modulation
+powernow0	at cpu0		# AMD PowerNow! and Cool'n'Quiet (non-ACPI)
+#vmt0		at cpu0		# VMware Tools
+
 # Alternate buffer queue strategies for better responsiveness under high
 # disk I/O load.
 #options 	BUFQ_READPRIO
@@ -286,10 +303,6 @@ config		netbsd	root on ? type ?
 #
 
 ## Xen-specific options
-mainbus0 at root
-
-cpu* at mainbus?
-
 hypervisor*	at mainbus?		# Xen hypervisor
 
 vcpu*		at hypervisor?		# Xen virtual CPUs
@@ -306,8 +319,8 @@ ipmi_acpi*	at acpi?
 ipmi0		at ipmi_acpi?
 
 # ACPI will be used if present. If not it will fall back to MPBIOS
-acpi0		at hypervisor?		# ACPI access in PV mode
 acpi0		at mainbus?		# ACPI access in PVH(VM) mode
+acpi0		at hypervisor?		# ACPI access in PV mode
 
 options 	ACPI_SCANPCI		# find PCI roots using ACPI
 options 	MPBIOS			# configure CPUs and APICs using MPBIOS
@@ -322,8 +335,6 @@ options 	MPBIOS_SCANPCI		# MPBIOS config
 #options 	MPDEBUG			# MPBIOS configures PCI roots
 #options 	MPVERBOSE		# verbose MPBIOS autoconfig messages
 
-ioapic* 	at mainbus? apid ?
-
 # ACPI devices
 acpiacad*	at acpi?		# ACPI AC Adapter
 acpibat*	at acpi?		# ACPI Battery
@@ -343,30 +354,44 @@ acpitz* 	at acpi?		# ACPI Thermal Zone
 
 # Mainboard devices
 aibs*		at acpi?		# ASUSTeK AI Booster hardware monitor
+#asus*		at acpi?		# ASUS hotkeys
+#attimer*	at acpi?		# AT Timer
 #com*		at acpi?		# Serial communications interface
 #fdc*		at acpi?		# Floppy disk controller
+#fujbp*		at acpi?		# Fujitsu Brightness & Pointer
+#fujhk*		at acpi?		# Fujitsu Hotkeys
 #hpacel* 	at acpi?		# HP 3D DriveGuard accelerometer
-#hpqlb*		at acpi?		# HP Quick Launch Buttons
 hpqlb*		at acpi?		# HP Quick Launch Buttons
+#hpet*		at acpihpetbus?		# High Precision Event Timer (table)
+#hpet*		at acpinodebus?		# High Precision Event Timer (device)
+#joy*		at acpi?		# Joystick/Game port
+#lpt*		at acpi?		# Parallel port
+#mpu*		at acpi?		# Roland MPU-401 MIDI UART
 #lpt*		at acpi?		# Parallel port
 pckbc*		at acpi?		# PC keyboard controller
 pcppi*		at 

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Fri Mar  5 20:18:39 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: GENERIC

Log Message:
GENERIC: comment typo fix (spacing)


To generate a diff of this commit:
cvs rdiff -u -r1.585 -r1.586 src/sys/arch/amd64/conf/GENERIC

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

Modified files:

Index: src/sys/arch/amd64/conf/GENERIC
diff -u src/sys/arch/amd64/conf/GENERIC:1.585 src/sys/arch/amd64/conf/GENERIC:1.586
--- src/sys/arch/amd64/conf/GENERIC:1.585	Thu Mar  4 15:58:50 2021
+++ src/sys/arch/amd64/conf/GENERIC	Fri Mar  5 20:18:39 2021
@@ -1,4 +1,4 @@
-# $NetBSD: GENERIC,v 1.585 2021/03/04 15:58:50 gdt Exp $
+# $NetBSD: GENERIC,v 1.586 2021/03/05 20:18:39 gdt Exp $
 #
 # GENERIC machine description file
 #
@@ -22,7 +22,7 @@ include 	"arch/amd64/conf/std.amd64"
 
 options 	INCLUDE_CONFIG_FILE	# embed config file in kernel binary
 
-#ident		"GENERIC-$Revision: 1.585 $"
+#ident		"GENERIC-$Revision: 1.586 $"
 
 maxusers	64		# estimated number of users
 
@@ -1133,7 +1133,7 @@ pseudo-device	ccd			# concatenated/strip
 pseudo-device	cgd			# cryptographic disk devices
 pseudo-device	raid			# RAIDframe disk driver
 options 	RAID_AUTOCONFIG		# auto-configuration of RAID components
-#Options to enable various other RAIDframe RAID types.
+# Options to enable various other RAIDframe RAID types.
 #options 	RF_INCLUDE_EVENODD=1
 #options 	RF_INCLUDE_RAID5_RS=1
 #options 	RF_INCLUDE_PARITYLOGGING=1

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Fri Mar  5 20:18:39 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: GENERIC

Log Message:
GENERIC: comment typo fix (spacing)


To generate a diff of this commit:
cvs rdiff -u -r1.585 -r1.586 src/sys/arch/amd64/conf/GENERIC

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

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Thu Mar  4 19:01:41 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: std.xen

Log Message:
std.xen: Move towards std.amd64

(No functional change.)


To generate a diff of this commit:
cvs rdiff -u -r1.13 -r1.14 src/sys/arch/amd64/conf/std.xen

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

Modified files:

Index: src/sys/arch/amd64/conf/std.xen
diff -u src/sys/arch/amd64/conf/std.xen:1.13 src/sys/arch/amd64/conf/std.xen:1.14
--- src/sys/arch/amd64/conf/std.xen:1.13	Sat Apr 25 15:26:16 2020
+++ src/sys/arch/amd64/conf/std.xen	Thu Mar  4 19:01:41 2021
@@ -1,20 +1,20 @@
-# $NetBSD: std.xen,v 1.13 2020/04/25 15:26:16 bouyer Exp $
-# NetBSD: std.i386,v 1.24 2003/02/26 21:33:36 fvdl Exp 
+# $NetBSD: std.xen,v 1.14 2021/03/04 19:01:41 gdt Exp $
 #
-# standard, required NetBSD/i386 'options'
+# standard, required NetBSD/xen 'options'
+# Note that this file is used by both DOM0 and DOMU.
 
 machine xen amd64 x86
 include 	"conf/std"	# MI standard options
-include		"arch/xen/conf/files.xen.pv"
-
-options 	XEN	#Xen support
-
-include		"arch/xen/conf/std.xenversion"
+include 	"arch/xen/conf/std.xenversion"
 
 options 	CPU_IN_CKSUM
 options 	EXEC_ELF64	# exec ELF binaries
 options 	EXEC_SCRIPT	# exec #! scripts
 options 	MTRR
+#options 	MULTIPROCESSOR
 
 options 	CHILD_MAX=1024	# 160 is too few
 options 	OPEN_MAX=1024	# 128 is too few
+
+options 	XEN		# Xen support
+include 	"arch/xen/conf/files.xen.pv"

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Thu Mar  4 19:01:41 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: std.xen

Log Message:
std.xen: Move towards std.amd64

(No functional change.)


To generate a diff of this commit:
cvs rdiff -u -r1.13 -r1.14 src/sys/arch/amd64/conf/std.xen

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

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Thu Mar  4 16:02:11 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
XEN3_DOM0: Move closer to GENERIC (NFC)

This is another step in making XEN3_DOM0 closer to GENERIC.  It is
just reordering lines, adding commented out lines, and adding a few
comments.  (Test-booted with no dmesg change.)

This pass is showing cases where there are substantive and likely
undesired changes (e.g., UFS_ACL is not defined in XEN3_DOM0).  Often
I added them but commented them out to preserve the NFC property of
this commit.  My plan is to finish the easy NFC stuff first before
addressing functional changes.


To generate a diff of this commit:
cvs rdiff -u -r1.190 -r1.191 src/sys/arch/amd64/conf/XEN3_DOM0

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

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Thu Mar  4 16:02:11 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
XEN3_DOM0: Move closer to GENERIC (NFC)

This is another step in making XEN3_DOM0 closer to GENERIC.  It is
just reordering lines, adding commented out lines, and adding a few
comments.  (Test-booted with no dmesg change.)

This pass is showing cases where there are substantive and likely
undesired changes (e.g., UFS_ACL is not defined in XEN3_DOM0).  Often
I added them but commented them out to preserve the NFC property of
this commit.  My plan is to finish the easy NFC stuff first before
addressing functional changes.


To generate a diff of this commit:
cvs rdiff -u -r1.190 -r1.191 src/sys/arch/amd64/conf/XEN3_DOM0

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

Modified files:

Index: src/sys/arch/amd64/conf/XEN3_DOM0
diff -u src/sys/arch/amd64/conf/XEN3_DOM0:1.190 src/sys/arch/amd64/conf/XEN3_DOM0:1.191
--- src/sys/arch/amd64/conf/XEN3_DOM0:1.190	Wed Mar  3 12:31:19 2021
+++ src/sys/arch/amd64/conf/XEN3_DOM0	Thu Mar  4 16:02:10 2021
@@ -1,4 +1,4 @@
-# $NetBSD: XEN3_DOM0,v 1.190 2021/03/03 12:31:19 gdt Exp $
+# $NetBSD: XEN3_DOM0,v 1.191 2021/03/04 16:02:10 gdt Exp $
 
 # XEN3_DOM0 machine description file
 #
@@ -14,7 +14,7 @@ include 	"arch/amd64/conf/std.xen"
 
 options 	INCLUDE_CONFIG_FILE	# embed config file in kernel binary
 
-#ident		"XEN3_DOM0-$Revision: 1.190 $"
+#ident		"XEN3_DOM0-$Revision: 1.191 $"
 
 maxusers	32		# estimated number of users
 
@@ -80,6 +80,7 @@ options 	SYSVSHM		# System V-like memory
 
 options 	MODULAR		# new style module(7) framework
 options 	USERCONF	# userconf(4) support
+#options 	PIPE_SOCKETPAIR	# smaller, but slower pipe(2)
 options 	SYSCTL_INCLUDE_DESCR	# Include sysctl descriptions in kernel
 
 # Alternate buffer queue strategies for better responsiveness under high
@@ -108,9 +109,55 @@ options 	DDB_HISTORY_SIZE=512	# enable h
 #options 	SYSCALL_STATS	# per syscall counts
 #options 	SYSCALL_TIMES	# per syscall times
 #options 	SYSCALL_TIMES_HASCOUNTER	# use 'broken' rdtsc (soekris)
+#options 	KDTRACE_HOOKS	# kernel DTrace hooks
+
+# Kernel Undefined Behavior Sanitizer (kUBSan).
+#options 	KUBSAN			# mandatory
+#options 	UBSAN_ALWAYS_FATAL	# optional: panic on all kUBSan reports
+
+# Kernel Address Sanitizer (kASan). You need to disable SVS to use it.
+# The quarantine is optional and can help KASAN find more use-after-frees.
+# Use KASAN_PANIC if you want panics instead of warnings.
+#makeoptions 	KASAN=1		# mandatory
+#options 	KASAN		# mandatory
+#no options	SVS		# mandatory
+#options 	POOL_QUARANTINE	# optional
+#options 	KASAN_PANIC	# optional
+
+# Kernel Concurrency Sanitizer (kCSan).
+#makeoptions 	KCSAN=1		# mandatory
+#options 	KCSAN		# mandatory
+#options 	KCSAN_PANIC	# optional
+
+# Kernel Memory Sanitizer (kMSan). You need to disable SVS and kernel modules
+# to use it. POOL_NOCACHE is optional and can help KMSAN find uninitialized
+# memory in pool caches. Note that KMSAN requires at least 4GB of RAM.
+#makeoptions 	KMSAN=1		# mandatory
+#options 	KMSAN		# mandatory
+#no options	SVS		# mandatory
+#no options 	MODULAR		# mandatory
+#no options 	MODULAR_DEFAULT_AUTOLOAD	# mandatory
+#options 	POOL_NOCACHE	# optional
+#options 	KMSAN_PANIC	# optional
+
+# Kernel Code Coverage Driver.
+#makeoptions	KCOV=1
+#options 	KCOV
+
+# Fault Injection Driver.
+#options 	FAULT
 
 # Compatibility options
+# x86_64 never shipped with a.out binaries; the two options below are
+# only relevant to 32-bit i386 binaries
+#options 	EXEC_AOUT	# required by binaries from before 1.5
+#options 	COMPAT_NOMID	# NetBSD 0.8, 386BSD, and BSDI
+
+# NetBSD backward compatibility. Support goes from COMPAT_15 up until
+# the latest release. Note that really old compat (< COMPAT_16) is only
+# useful for 32-bit i386 binaries.
 include 	"conf/compat_netbsd15.config"
+
 #options 	COMPAT_386BSD_MBRPART # recognize old partition ID
 
 options 	COMPAT_NETBSD32
@@ -128,17 +175,23 @@ options 	DKWEDGE_METHOD_APPLE	# Support 
 include "conf/filesystems.config"
 
 # File system options
+# ffs
 options 	QUOTA		# legacy UFS quotas
 options 	QUOTA2		# new, in-filesystem UFS quotas
-#options 	DISKLABEL_EI	# disklabel Endian Independent support
 #options 	FFS_EI		# FFS Endian Independent support
 options 	WAPBL		# File system journaling support
+# Note that UFS_DIRHASH is suspected of causing kernel memory corruption.
+# It is not recommended for general use.
 #options 	UFS_DIRHASH	# UFS Large Directory Hashing - Experimental
-options 	NFSSERVER	# Network File System server
+#options		UFS_ACL		# UFS Access Control Lists
 #options 	FFS_NO_SNAPSHOT	# No FFS snapshot support
 options 	UFS_EXTATTR	# Extended attribute support for UFS1
+# ext2fs
 #options 	EXT2FS_SYSTEM_FLAGS # makes ext2fs file flags (append and
 # immutable) behave as system flags.
+# other
+#options 	DISKLABEL_EI	

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Thu Mar  4 15:58:50 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: GENERIC

Log Message:
GENERIC: Tiny comment adjustment (NFC)

While making XEN3_DOM0 more like GENERIC, I noticed a few differences
where GENERIC was off -- trivial things like missing spaces in
comments, inconsistent comment workding.  This fixes those, both
because they are valid fixes in their own right once noticed, and to
make the diff to XEN smaller.


To generate a diff of this commit:
cvs rdiff -u -r1.584 -r1.585 src/sys/arch/amd64/conf/GENERIC

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

Modified files:

Index: src/sys/arch/amd64/conf/GENERIC
diff -u src/sys/arch/amd64/conf/GENERIC:1.584 src/sys/arch/amd64/conf/GENERIC:1.585
--- src/sys/arch/amd64/conf/GENERIC:1.584	Mon Mar  1 18:12:58 2021
+++ src/sys/arch/amd64/conf/GENERIC	Thu Mar  4 15:58:50 2021
@@ -1,4 +1,4 @@
-# $NetBSD: GENERIC,v 1.584 2021/03/01 18:12:58 jakllsch Exp $
+# $NetBSD: GENERIC,v 1.585 2021/03/04 15:58:50 gdt Exp $
 #
 # GENERIC machine description file
 #
@@ -22,7 +22,7 @@ include 	"arch/amd64/conf/std.amd64"
 
 options 	INCLUDE_CONFIG_FILE	# embed config file in kernel binary
 
-#ident		"GENERIC-$Revision: 1.584 $"
+#ident		"GENERIC-$Revision: 1.585 $"
 
 maxusers	64		# estimated number of users
 
@@ -297,7 +297,7 @@ config		netbsd	root on ? type ?
 # Device configuration
 #
 
-#IPMI support
+# IPMI support
 ipmi0		at mainbus?
 ipmi_acpi*	at acpi?
 ipmi0		at ipmi_acpi?
@@ -307,7 +307,7 @@ acpi0		at mainbus0
 options 	ACPI_SCANPCI		# find PCI roots using ACPI
 options 	MPBIOS			# configure CPUs and APICs using MPBIOS
 options 	MPBIOS_SCANPCI		# MPBIOS configures PCI roots
-#options 	PCI_INTR_FIXUP		# PCI interrupt routing via ACPI
+#options 	PCI_INTR_FIXUP		# fixup PCI interrupt routing via ACPI
 #options 	PCI_BUS_FIXUP		# fixup PCI bus numbering
 #options 	PCI_ADDR_FIXUP		# fixup PCI I/O addresses
 #options 	ACPI_ACTIVATE_DEV	# If set, activate inactive devices
@@ -317,7 +317,7 @@ options 	VGA_POST		# in-kernel support f
 acpiacad*	at acpi?		# ACPI AC Adapter
 acpibat*	at acpi?		# ACPI Battery
 acpibut*	at acpi?		# ACPI Button
-acpidalb*	at acpi?		# Direct Application Launch Button
+acpidalb*	at acpi?		# ACPI Direct Application Launch Button
 acpiec* 	at acpi?		# ACPI Embedded Controller (late)
 acpiecdt*	at acpi?		# ACPI Embedded Controller (early)
 acpifan*	at acpi?		# ACPI Fan

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Thu Mar  4 15:58:50 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: GENERIC

Log Message:
GENERIC: Tiny comment adjustment (NFC)

While making XEN3_DOM0 more like GENERIC, I noticed a few differences
where GENERIC was off -- trivial things like missing spaces in
comments, inconsistent comment workding.  This fixes those, both
because they are valid fixes in their own right once noticed, and to
make the diff to XEN smaller.


To generate a diff of this commit:
cvs rdiff -u -r1.584 -r1.585 src/sys/arch/amd64/conf/GENERIC

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

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Wed Mar  3 12:31:19 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
XEN3_DOM0: Move closer to GENERIC (NFC)

This commit reorders some lines, and brings in commented lines from
GENERIC to reduce the diff.  It also brings in two agp lines,
commented out, and with a warning that they are intentionally omitted.


To generate a diff of this commit:
cvs rdiff -u -r1.189 -r1.190 src/sys/arch/amd64/conf/XEN3_DOM0

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

Modified files:

Index: src/sys/arch/amd64/conf/XEN3_DOM0
diff -u src/sys/arch/amd64/conf/XEN3_DOM0:1.189 src/sys/arch/amd64/conf/XEN3_DOM0:1.190
--- src/sys/arch/amd64/conf/XEN3_DOM0:1.189	Tue Mar  2 18:10:31 2021
+++ src/sys/arch/amd64/conf/XEN3_DOM0	Wed Mar  3 12:31:19 2021
@@ -1,4 +1,4 @@
-# $NetBSD: XEN3_DOM0,v 1.189 2021/03/02 18:10:31 gdt Exp $
+# $NetBSD: XEN3_DOM0,v 1.190 2021/03/03 12:31:19 gdt Exp $
 
 # XEN3_DOM0 machine description file
 #
@@ -12,22 +12,48 @@
 
 include 	"arch/amd64/conf/std.xen"
 
-options		XENPV		# PV dom0 support
-options 	MULTIPROCESSOR
-#options 	NO_PREEMPTION	# needed if MULTIPROCESSOR is disabled
-
 options 	INCLUDE_CONFIG_FILE	# embed config file in kernel binary
 
-#options 	UVMHIST
-#options 	UVMHIST_PRINT
-#options 	SYSCALL_DEBUG
-
-#ident		"XEN3_DOM0-$Revision: 1.189 $"
+#ident		"XEN3_DOM0-$Revision: 1.190 $"
 
 maxusers	32		# estimated number of users
 
-#
+# delay between "rebooting ..." message and hardware reset, in milliseconds
+#options 	CPURESET_DELAY=2000
+
+# This option allows you to force a serial console at the specified
+# I/O address.   see console(4) for details.
+#options 	CONSDEVNAME="\"com\"",CONADDR=0x2f8,CONSPEED=57600
+#	you don't want the option below ON iff you are using the
+#	serial console option of the new boot strap code.
+#options 	CONS_OVERRIDE	# Always use above! independent of boot info
+
+# The following options override the memory sizes passed in from the boot
+# block.  Use them *only* if the boot block is unable to determine the correct
+# values.  Note that the BIOS may *correctly* report less than 640k of base
+# memory if the extended BIOS data area is located at the top of base memory
+# (as is the case on most recent systems).
+#options 	REALBASEMEM=639		# size of base memory (in KB)
+#options 	REALEXTMEM=15360	# size of extended memory (in KB)
+
+# The following options limit the overall size of physical memory
+# and/or the maximum address used by the system.
+# Contrary to REALBASEMEM and REALEXTMEM, they still use the BIOS memory map
+# and can deal with holes in the memory layout.
+#options 	PHYSMEM_MAX_SIZE=64	# max size of physical memory (in MB)
+#options 	PHYSMEM_MAX_ADDR=2048	# don't use memory above this (in MB)
+
+## Xen-specific options
+
+options		XENPV		# PV dom0 support
 options 	DOM0OPS
+options 	MULTIPROCESSOR
+#options 	NO_PREEMPTION	# needed if MULTIPROCESSOR is disabled
+
+#options 	CONSDEVNAME="\"xencons\""
+#options 	CONS_OVERRIDE
+
+## end Xen-specific options
 
 # boot messages with MPBIOS, acpi and ioapic can be quite large
 options 	MSGBUFSIZE=24576
@@ -36,10 +62,7 @@ options 	MSGBUFSIZE=24576
 est0		at cpu0		# Intel Enhanced SpeedStep (non-ACPI)
 powernow0	at cpu0		# AMD PowerNow! and Cool'n'Quiet (non-ACPI)
 
-#options 	MTRR		# memory-type range register syscall support
-
-#options 	CONSDEVNAME="\"xencons\""
-#options 	CONS_OVERRIDE
+# Standard system options
 
 options 	INSECURE	# disable kernel security levels - X needs this
 
@@ -50,6 +73,7 @@ options 	KTRACE		# system call tracing v
 
 options 	CPU_UCODE	# cpu ucode loading support
 
+# Note: SysV IPC parameters could be changed dynamically, see sysctl(8).
 options 	SYSVMSG		# System V-like message queues
 options 	SYSVSEM		# System V-like semaphores
 options 	SYSVSHM		# System V-like memory sharing
@@ -65,15 +89,25 @@ options 	BUFQ_PRIOCSCAN
 
 # Diagnostic/debugging support options
 options 	DIAGNOSTIC	# inexpensive kernel consistency checks
+# XXX to be commented out on release branch
 #options 	DEBUG		# expensive debugging checks/support
+#options 	LOCKDEBUG	# expensive locking checks/support
+
+#
+# Because gcc omits the frame pointer for any -O level, the line below
+# is needed to make backtraces in DDB work.
+#
+makeoptions	COPTS="-O2 -fno-omit-frame-pointer"
 options 	DDB		# in-kernel debugger
+options		DDB_COMMANDONENTER="show registers"
 options 	DDB_ONPANIC=1	# see also sysctl(7): `ddb.onpanic'
 options 	DDB_HISTORY_SIZE=512	# enable history editing in DDB
 #options 	KGDB		# remote debugger
 #options 	KGDB_DEVNAME="\"com\"",KGDB_DEVADDR=0x2f8,KGDB_DEVRATE=57600
 #makeoptions	DEBUG="-g"	# compile full symbol table
-makeoptions	COPTS="-O2 -fno-omit-frame-pointer"
-options DDB_COMMANDONENTER="show registers"
+#options 	SYSCALL_STATS	# per syscall counts
+#options 	SYSCALL_TIMES	# per syscall times
+#options 	

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Wed Mar  3 12:31:19 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
XEN3_DOM0: Move closer to GENERIC (NFC)

This commit reorders some lines, and brings in commented lines from
GENERIC to reduce the diff.  It also brings in two agp lines,
commented out, and with a warning that they are intentionally omitted.


To generate a diff of this commit:
cvs rdiff -u -r1.189 -r1.190 src/sys/arch/amd64/conf/XEN3_DOM0

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

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Tue Mar  2 18:10:31 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
XEN3_DOM0: Fix pckbc console attachment logic

Copy PCKBD_CNATTACH_MAY_FAIL lines from GENERIC to XEN3_DOM0.

GENERIC defines PCKBD_CNATTACH_MAY_FAIL, which means that an attempt
to activate console input on pckbc will fail if there is no keyboard
present.  This is a problem on semi-modern machines that have pckbc
silicon but not ports, and thus almost always have a USB keyboard
also.  What I suspect are bugs in console attachment logic lead to
attempting to attach a ukbd while there already is a console keyboard,
and with DIAGNOSTIC this is (properly) fatal, so XEN3_DOM0 blows up
with a USB keyboard in current, and probably not in 9.

Live tested on a machine that previously paniced on boot.


To generate a diff of this commit:
cvs rdiff -u -r1.188 -r1.189 src/sys/arch/amd64/conf/XEN3_DOM0

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

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Tue Mar  2 18:10:31 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
XEN3_DOM0: Fix pckbc console attachment logic

Copy PCKBD_CNATTACH_MAY_FAIL lines from GENERIC to XEN3_DOM0.

GENERIC defines PCKBD_CNATTACH_MAY_FAIL, which means that an attempt
to activate console input on pckbc will fail if there is no keyboard
present.  This is a problem on semi-modern machines that have pckbc
silicon but not ports, and thus almost always have a USB keyboard
also.  What I suspect are bugs in console attachment logic lead to
attempting to attach a ukbd while there already is a console keyboard,
and with DIAGNOSTIC this is (properly) fatal, so XEN3_DOM0 blows up
with a USB keyboard in current, and probably not in 9.

Live tested on a machine that previously paniced on boot.


To generate a diff of this commit:
cvs rdiff -u -r1.188 -r1.189 src/sys/arch/amd64/conf/XEN3_DOM0

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

Modified files:

Index: src/sys/arch/amd64/conf/XEN3_DOM0
diff -u src/sys/arch/amd64/conf/XEN3_DOM0:1.188 src/sys/arch/amd64/conf/XEN3_DOM0:1.189
--- src/sys/arch/amd64/conf/XEN3_DOM0:1.188	Tue Mar  2 18:06:12 2021
+++ src/sys/arch/amd64/conf/XEN3_DOM0	Tue Mar  2 18:10:31 2021
@@ -1,4 +1,4 @@
-# $NetBSD: XEN3_DOM0,v 1.188 2021/03/02 18:06:12 gdt Exp $
+# $NetBSD: XEN3_DOM0,v 1.189 2021/03/02 18:10:31 gdt Exp $
 
 # XEN3_DOM0 machine description file
 #
@@ -22,7 +22,7 @@ options 	INCLUDE_CONFIG_FILE	# embed con
 #options 	UVMHIST_PRINT
 #options 	SYSCALL_DEBUG
 
-#ident		"XEN3_DOM0-$Revision: 1.188 $"
+#ident		"XEN3_DOM0-$Revision: 1.189 $"
 
 maxusers	32		# estimated number of users
 
@@ -166,6 +166,8 @@ options 	WSDISPLAY_COMPAT_PCVT		# emulat
 options 	WSDISPLAY_COMPAT_SYSCONS	# emulate some ioctls
 options 	WSDISPLAY_COMPAT_USL		# wsconscfg VT handling
 options 	WSDISPLAY_COMPAT_RAWKBD		# can get raw scancodes
+# don't attach pckbd as the console if no PS/2 keyboard is found
+options 	PCKBD_CNATTACH_MAY_FAIL
 # see dev/pckbport/wskbdmap_mfii.c for implemented layouts
 #options 	PCKBD_LAYOUT="(KB_DE | KB_NODEAD)"
 # allocate a number of virtual screens at autoconfiguration time

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Tue Mar  2 18:06:12 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
XEN3_DOM0: Sync VERBOSE with GENERIC

Copy the *VERBOSE option block from GENERIC, and prune the scattered
verbose options in XEN3_DOM0, surely dating from a time they were
copied from an earlier GENERIC.  This amounts to adding PCIVERBOSE and
SCSIVERBOSE, and the diff from GENERIC to DOM0 boots is markedly
reduced.


To generate a diff of this commit:
cvs rdiff -u -r1.187 -r1.188 src/sys/arch/amd64/conf/XEN3_DOM0

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

Modified files:

Index: src/sys/arch/amd64/conf/XEN3_DOM0
diff -u src/sys/arch/amd64/conf/XEN3_DOM0:1.187 src/sys/arch/amd64/conf/XEN3_DOM0:1.188
--- src/sys/arch/amd64/conf/XEN3_DOM0:1.187	Mon Mar  1 13:52:50 2021
+++ src/sys/arch/amd64/conf/XEN3_DOM0	Tue Mar  2 18:06:12 2021
@@ -1,4 +1,4 @@
-# $NetBSD: XEN3_DOM0,v 1.187 2021/03/01 13:52:50 gdt Exp $
+# $NetBSD: XEN3_DOM0,v 1.188 2021/03/02 18:06:12 gdt Exp $
 
 # XEN3_DOM0 machine description file
 #
@@ -22,7 +22,7 @@ options 	INCLUDE_CONFIG_FILE	# embed con
 #options 	UVMHIST_PRINT
 #options 	SYSCALL_DEBUG
 
-#ident		"XEN3_DOM0-$Revision: 1.187 $"
+#ident		"XEN3_DOM0-$Revision: 1.188 $"
 
 maxusers	32		# estimated number of users
 
@@ -133,6 +133,17 @@ options 	PPP_FILTER	# Active filter supp
 #options 	ALTQ_RIO	# RED with IN/OUT
 #options 	ALTQ_WFQ	# Weighted Fair Queueing
 
+# These options enable verbose messages for several subsystems.
+# Warning, these may compile large string tables into the kernel!
+#options 	ACPIVERBOSE	# verbose ACPI configuration messages
+#options 	MIIVERBOSE	# verbose PHY autoconfig messages
+options 	PCIVERBOSE	# verbose PCI device autoconfig messages
+#options 	PCI_CONFIG_DUMP	# verbosely dump PCI config space
+#options 	PCMCIAVERBOSE	# verbose PCMCIA configuration messages
+options 	SCSIVERBOSE	# human readable SCSI error messages
+#options 	USBVERBOSE	# verbose USB device autoconfig messages
+#options 	HDAUDIOVERBOSE	# verbose HDAUDIO driver messages
+
 options 	NFS_BOOT_DHCP,NFS_BOOT_BOOTPARAM
 #options 	NFS_BOOT_BOOTSTATIC
 #options 	NFS_BOOTSTATIC_MYIP="\"169.254.1.2\""
@@ -197,8 +208,6 @@ acpi0		at mainbus?		# ACPI access in PVH
 #options 	ACPI_ACTIVATE_DEV	# If set, activate inactive devices
 options 	ACPI_SCANPCI		# find PCI roots using ACPI
 #options 	ACPICA_PEDANTIC		# force strict conformance to the Spec.
-#options 	ACPIVERBOSE		# verbose ACPI configuration messages
-#options 	MIIVERBOSE		# verbose PHY autoconfig messages
 options 	MPBIOS			# configure CPUs and APICs using MPBIOS
 #options 	MPDEBUG			# MPBIOS configures PCI roots
 #options 	MPVERBOSE		# verbose MPBIOS autoconfig messages
@@ -206,9 +215,6 @@ options 	MPBIOS_SCANPCI		# MPBIOS config
 #options 	PCI_ADDR_FIXUP		# fixup PCI I/O addresses
 #options 	PCI_BUS_FIXUP		# fixup PCI bus numbering
 #options 	PCI_INTR_FIXUP		# fixup PCI interrupt routing
-#options 	PCIVERBOSE		# verbose PCI device autoconfig messages
-#options 	USBVERBOSE		# verbose USB device autoconfig messages
-#options 	HDAUDIOVERBOSE		# verbose HDAUDIO driver messages
 
 ioapic* 	at mainbus? apid ?
 

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Tue Mar  2 18:06:12 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
XEN3_DOM0: Sync VERBOSE with GENERIC

Copy the *VERBOSE option block from GENERIC, and prune the scattered
verbose options in XEN3_DOM0, surely dating from a time they were
copied from an earlier GENERIC.  This amounts to adding PCIVERBOSE and
SCSIVERBOSE, and the diff from GENERIC to DOM0 boots is markedly
reduced.


To generate a diff of this commit:
cvs rdiff -u -r1.187 -r1.188 src/sys/arch/amd64/conf/XEN3_DOM0

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

CVS commit: src/sys/dev/usb

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Tue Mar  2 00:18:22 UTC 2021

Modified Files:
src/sys/dev/usb: ukbd.c

Log Message:
ukbd: GC some 20 year old code (NFC)

Long ago, code was improved to allow detaching keyboards that were the
console, but the old commen and panic() were #if 0'd instead of
removed.


To generate a diff of this commit:
cvs rdiff -u -r1.148 -r1.149 src/sys/dev/usb/ukbd.c

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

Modified files:

Index: src/sys/dev/usb/ukbd.c
diff -u src/sys/dev/usb/ukbd.c:1.148 src/sys/dev/usb/ukbd.c:1.149
--- src/sys/dev/usb/ukbd.c:1.148	Tue Mar  2 00:01:27 2021
+++ src/sys/dev/usb/ukbd.c	Tue Mar  2 00:18:22 2021
@@ -1,4 +1,4 @@
-/*  $NetBSD: ukbd.c,v 1.148 2021/03/02 00:01:27 gdt Exp $*/
+/*  $NetBSD: ukbd.c,v 1.149 2021/03/02 00:18:22 gdt Exp $*/
 
 /*
  * Copyright (c) 1998 The NetBSD Foundation, Inc.
@@ -35,7 +35,7 @@
  */
 
 #include 
-__KERNEL_RCSID(0, "$NetBSD: ukbd.c,v 1.148 2021/03/02 00:01:27 gdt Exp $");
+__KERNEL_RCSID(0, "$NetBSD: ukbd.c,v 1.149 2021/03/02 00:18:22 gdt Exp $");
 
 #ifdef _KERNEL_OPT
 #include "opt_ddb.h"
@@ -555,17 +555,6 @@ ukbd_detach(device_t self, int flags)
 	pmf_device_deregister(self);
 
 	if (sc->sc_console_keyboard) {
-#if 0
-		/*
-		 * XXX Should probably disconnect our consops,
-		 * XXX and either notify some other keyboard that
-		 * XXX it can now be the console, or if there aren't
-		 * XXX any more USB keyboards, set ukbd_is_console
-		 * XXX back to 1 so that the next USB keyboard attached
-		 * XXX to the system will get it.
-		 */
-		panic("ukbd_detach: console keyboard");
-#else
 		/*
 		 * Disconnect our consops and set ukbd_is_console
 		 * back to 1 so that the next USB keyboard attached
@@ -577,7 +566,6 @@ ukbd_detach(device_t self, int flags)
 		   device_xname(sc->sc_hdev.sc_dev));
 		wskbd_cndetach();
 		ukbd_is_console = 1;
-#endif
 	}
 	/* No need to do reference counting of ukbd, wskbd has all the goo. */
 	if (sc->sc_wskbddev != NULL)

CVS commit: src/sys/dev/usb

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Tue Mar  2 00:18:22 UTC 2021

Modified Files:
src/sys/dev/usb: ukbd.c

Log Message:
ukbd: GC some 20 year old code (NFC)

Long ago, code was improved to allow detaching keyboards that were the
console, but the old commen and panic() were #if 0'd instead of
removed.


To generate a diff of this commit:
cvs rdiff -u -r1.148 -r1.149 src/sys/dev/usb/ukbd.c

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

CVS commit: src/sys/dev/usb

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Tue Mar  2 00:01:27 UTC 2021

Modified Files:
src/sys/dev/usb: ukbd.c

Log Message:
ukbd: Condition probe-time verbosity on USBVERBOSE

Previously, this driver switched on more verbose messages based on
DIAGNOSTIC.  But, the messages weren't about an impossible-to-reach
condition, just extra keys.  Change the condition to USBVERBOSE,
documented as serving this purpose.


To generate a diff of this commit:
cvs rdiff -u -r1.147 -r1.148 src/sys/dev/usb/ukbd.c

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

Modified files:

Index: src/sys/dev/usb/ukbd.c
diff -u src/sys/dev/usb/ukbd.c:1.147 src/sys/dev/usb/ukbd.c:1.148
--- src/sys/dev/usb/ukbd.c:1.147	Sat Sep 12 18:10:37 2020
+++ src/sys/dev/usb/ukbd.c	Tue Mar  2 00:01:27 2021
@@ -1,4 +1,4 @@
-/*  $NetBSD: ukbd.c,v 1.147 2020/09/12 18:10:37 macallan Exp $*/
+/*  $NetBSD: ukbd.c,v 1.148 2021/03/02 00:01:27 gdt Exp $*/
 
 /*
  * Copyright (c) 1998 The NetBSD Foundation, Inc.
@@ -35,7 +35,7 @@
  */
 
 #include 
-__KERNEL_RCSID(0, "$NetBSD: ukbd.c,v 1.147 2020/09/12 18:10:37 macallan Exp $");
+__KERNEL_RCSID(0, "$NetBSD: ukbd.c,v 1.148 2021/03/02 00:01:27 gdt Exp $");
 
 #ifdef _KERNEL_OPT
 #include "opt_ddb.h"
@@ -435,7 +435,7 @@ ukbd_attach(device_t parent, device_t se
 		sc->sc_flags = FLAG_GDIUM_FN;
 #endif
 
-#ifdef DIAGNOSTIC
+#ifdef USBVERBOSE
 	aprint_normal(": %d Variable keys, %d Array codes", sc->sc_nkeyloc,
 	   sc->sc_nkeycode);
 	if (sc->sc_flags & FLAG_APPLE_FN)

CVS commit: src/sys/dev/usb

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Tue Mar  2 00:01:27 UTC 2021

Modified Files:
src/sys/dev/usb: ukbd.c

Log Message:
ukbd: Condition probe-time verbosity on USBVERBOSE

Previously, this driver switched on more verbose messages based on
DIAGNOSTIC.  But, the messages weren't about an impossible-to-reach
condition, just extra keys.  Change the condition to USBVERBOSE,
documented as serving this purpose.


To generate a diff of this commit:
cvs rdiff -u -r1.147 -r1.148 src/sys/dev/usb/ukbd.c

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

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Mon Mar  1 13:52:50 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
amd64/conf/XEN3_DOM0: Add comment

This commit merely adds a comment explaining how XEN3_DOM0 ought to
relate to GENERIC.


To generate a diff of this commit:
cvs rdiff -u -r1.186 -r1.187 src/sys/arch/amd64/conf/XEN3_DOM0

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

Modified files:

Index: src/sys/arch/amd64/conf/XEN3_DOM0
diff -u src/sys/arch/amd64/conf/XEN3_DOM0:1.186 src/sys/arch/amd64/conf/XEN3_DOM0:1.187
--- src/sys/arch/amd64/conf/XEN3_DOM0:1.186	Wed Jan 20 13:22:08 2021
+++ src/sys/arch/amd64/conf/XEN3_DOM0	Mon Mar  1 13:52:50 2021
@@ -1,4 +1,14 @@
-# $NetBSD: XEN3_DOM0,v 1.186 2021/01/20 13:22:08 nia Exp $
+# $NetBSD: XEN3_DOM0,v 1.187 2021/03/01 13:52:50 gdt Exp $
+
+# XEN3_DOM0 machine description file
+#
+# This machine description file is used to generate a kernel to be
+# used as a PV dom0 under Xen.  It is similar to GENERIC in that it is
+# intended to be useful for most applications.  Generally, besides
+# changes that are specifically required for Xen (e.g., XENPV), it
+# should be similar to GENERIC.  Some differences are currently
+# necessary, such as drivers that fail under Xen but work in GENERIC,
+# for reasons that do not follow from Xen architecture.
 
 include 	"arch/amd64/conf/std.xen"
 
@@ -12,7 +22,7 @@ options 	INCLUDE_CONFIG_FILE	# embed con
 #options 	UVMHIST_PRINT
 #options 	SYSCALL_DEBUG
 
-#ident		"XEN3_DOM0-$Revision: 1.186 $"
+#ident		"XEN3_DOM0-$Revision: 1.187 $"
 
 maxusers	32		# estimated number of users
 

CVS commit: src/sys/arch/amd64/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Mon Mar  1 13:52:50 UTC 2021

Modified Files:
src/sys/arch/amd64/conf: XEN3_DOM0

Log Message:
amd64/conf/XEN3_DOM0: Add comment

This commit merely adds a comment explaining how XEN3_DOM0 ought to
relate to GENERIC.


To generate a diff of this commit:
cvs rdiff -u -r1.186 -r1.187 src/sys/arch/amd64/conf/XEN3_DOM0

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

Re: CVS commit: src/tests/lib/libarchive

[Greg Troxel]

Jason Thorpe  writes:

>> On Jun 16, 2020, at 8:43 AM, Martin Husemann  wrote:
>> 
>> No, that is definitively not OK, which is what the PR is about.
>> 
>> It is not OK for a regular atf run to cause a reboot of the test machine
>> though, so this is a temporary hack around the issue (and admitedly a very
>> ugly hack).
>
> At the very least, the user-land watchdog tickler should wire itself down.

My impression of the point is that it be normal, so that the system
reboots if normal processes cannot be run.It seems like once
whatever bug exists is fixed, wiring is probably not necessary anyway.

Re: CVS commit: src/external/gpl3

[Greg Troxel]

Great to hear of progress.

I don't see why we don't care about 8.  Given our release policy, that
is supported until 10 is released.

Re: CVS commit: src/external/gpl3

[Greg Troxel]

Generally speaking divergence with upstream is a problem and we lost
these changes anyway in pkgsrc and every standalone GNU toolchain copy.


Agreed that divergence is a problem, but so is having bugs.  It's a 
question of the right balance in each case.



Finding a creative way to make this at least tunable is challenging with
the GCC people.


I think this is the real issue.   As I understand it, upstream is making 
a choice that is inconsistent with longstanding norms and against the 
consensus of an OS community.   So if the best that can happen is that 
we have to patch, that's how it is.  It would be really nice if there 
were a --default-tmpdir= configure argument, but it sounds like they are 
unwilling to do that.


Basically, I don't think we can go from "upstream is unwilling to do X" 
to "impose pain on NetBSD" by making "divergence bad" be the 
highest-weighted concern.   We have to say "what is the minimally 
painful way to cope".

Re: CVS commit: src/external/gpl3

[Greg Troxel]

Greg Troxel  writes:

> It seem really obvious to me, and obvious that it is netbsd consensus,
> that a tool that needs tmp (without needing persistence) should default
> to /tmp.  So I think it's unreasonable to follow upstream here, and
> unreasonable to ask everybody to either inherit some system profile or
> adjust their own to make tmp files be put in /tmp.
>
> Certainly if something in the tools build doesn't honor TMPDIR, that's a
> bug to be fixed -- but that seems uncontroversial.
>
>
> People who really want gcc tmp files to be put in /var/tmp can set
> TMPDIR.  As I understand it people that actually want that are a
> minority, and we haven't had a single person express that they want it
> during this discussion.
>
> What is the real problem here?  I think it's great that NetBSD-specific
> fixes are being upstreamed, and that we are reducing gratuitous changes
> from upstream.  But upstream's position that the default tmp should be
> /var/tmp is at odds with our and traditional norms, and really seems to
> just not make sense.  (Perhaps it does make sense on typical Linux, and
> perhaps upstream should have OS-specific tmp defaults.)   Adding
> complexity to NetBSD config files and users for the sake of reducing a
> diff seems like a bad tradeoff.

If you were only talking about fixing tools build, and have withdrawn
the notion of removing our patch to fix the default, I apologize for
writing this way.   My note is based on a perception that you are still
pushing to remove our patch to fix the tmp behavior.

Re: CVS commit: src/external/gpl3

[Greg Troxel]

Kamil Rytarowski  writes:

> On 26.03.2020 15:01, Martin Husemann wrote:
>> On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote:
>>> The build of tools could be fixed independently.
>> The problem is that we build the whole system with the tools gcc, and that
>> gcc misbehaves (or so I understood).
>> 
>> So pointing TMPDIR anywhere does not help.
>> 
>
> Right. Addressing tools build independently (honoring TMPDIR?) and
> defining TMPDIR in /etc shell profile for common use inside the
> distribution.

It seem really obvious to me, and obvious that it is netbsd consensus,
that a tool that needs tmp (without needing persistence) should default
to /tmp.  So I think it's unreasonable to follow upstream here, and
unreasonable to ask everybody to either inherit some system profile or
adjust their own to make tmp files be put in /tmp.

Certainly if something in the tools build doesn't honor TMPDIR, that's a
bug to be fixed -- but that seems uncontroversial.


People who really want gcc tmp files to be put in /var/tmp can set
TMPDIR.  As I understand it people that actually want that are a
minority, and we haven't had a single person express that they want it
during this discussion.

What is the real problem here?  I think it's great that NetBSD-specific
fixes are being upstreamed, and that we are reducing gratuitous changes
from upstream.  But upstream's position that the default tmp should be
/var/tmp is at odds with our and traditional norms, and really seems to
just not make sense.  (Perhaps it does make sense on typical Linux, and
perhaps upstream should have OS-specific tmp defaults.)   Adding
complexity to NetBSD config files and users for the sake of reducing a
diff seems like a bad tradeoff.

Re: CVS commit: src/external/gpl3

[Greg Troxel]

Taylor R Campbell  writes:

>> Do we insist on this patch? Can we remove it from local sources?
>
> We should keep the change.  There is no semantic justification for
> putting build-time temporary files in the directory for temporary
> files that are meant to persist across reboot.  These temporary files
> _cannot_ be used if interrupted -- let alone by a reboot.

I'll fourth this sentiment.

Plus, I'll observe that on my main development system /var/tmp has 6.4G
free while /tmp has 12G.  That's of course just arbitrary choices on my
part, and if either is an issue for a compiler there's something wrong
anyway.

CVS commit: src

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Wed Mar 25 18:08:34 UTC 2020

Modified Files:
src/lib/libc/sys: fdatasync.2
src/sys/kern: vfs_syscalls.c

Log Message:
Relax fdatasync restriction that fd be writable

The restriction that a fd passed to fdatasync(2) must be writable was
added in 2003 in order to comply with POSIX.  Since then, POSIX has
removed that requirement, and POSIX-valid programs have been therefore
encountering errors on NetBSD.

Patch by Paul Ripke after discussion on netbsd-users.  Issue
discovered with pkgsrc/databases/mongodb3 as used by pkgsrc/net/unifi.


To generate a diff of this commit:
cvs rdiff -u -r1.16 -r1.17 src/lib/libc/sys/fdatasync.2
cvs rdiff -u -r1.543 -r1.544 src/sys/kern/vfs_syscalls.c

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

CVS commit: src

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Wed Mar 25 18:08:34 UTC 2020

Modified Files:
src/lib/libc/sys: fdatasync.2
src/sys/kern: vfs_syscalls.c

Log Message:
Relax fdatasync restriction that fd be writable

The restriction that a fd passed to fdatasync(2) must be writable was
added in 2003 in order to comply with POSIX.  Since then, POSIX has
removed that requirement, and POSIX-valid programs have been therefore
encountering errors on NetBSD.

Patch by Paul Ripke after discussion on netbsd-users.  Issue
discovered with pkgsrc/databases/mongodb3 as used by pkgsrc/net/unifi.


To generate a diff of this commit:
cvs rdiff -u -r1.16 -r1.17 src/lib/libc/sys/fdatasync.2
cvs rdiff -u -r1.543 -r1.544 src/sys/kern/vfs_syscalls.c

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

Modified files:

Index: src/lib/libc/sys/fdatasync.2
diff -u src/lib/libc/sys/fdatasync.2:1.16 src/lib/libc/sys/fdatasync.2:1.17
--- src/lib/libc/sys/fdatasync.2:1.16	Wed Apr 30 13:10:51 2008
+++ src/lib/libc/sys/fdatasync.2	Wed Mar 25 18:08:34 2020
@@ -1,4 +1,4 @@
-.\"	$NetBSD: fdatasync.2,v 1.16 2008/04/30 13:10:51 martin Exp $
+.\"	$NetBSD: fdatasync.2,v 1.17 2020/03/25 18:08:34 gdt Exp $
 .\"
 .\" Copyright (c) 1998 The NetBSD Foundation, Inc.
 .\" All rights reserved.
@@ -68,7 +68,7 @@ function will fail if:
 .It Bq Er EBADF
 The
 .Fa fd
-argument is not a valid file descriptor open for writing.
+argument is not a valid file descriptor.
 .It Bq Er EINVAL
 This implementation does not support synchronized I/O for this file.
 .It Bq Er ENOSYS
@@ -93,4 +93,4 @@ and outstanding I/O operations are not g
 The
 .Fn fdatasync
 function conforms to
-.St -p1003.1b-93 .
+.St -p1003.1-2008 .

Index: src/sys/kern/vfs_syscalls.c
diff -u src/sys/kern/vfs_syscalls.c:1.543 src/sys/kern/vfs_syscalls.c:1.544
--- src/sys/kern/vfs_syscalls.c:1.543	Tue Mar  3 19:55:16 2020
+++ src/sys/kern/vfs_syscalls.c	Wed Mar 25 18:08:34 2020
@@ -1,4 +1,4 @@
-/*	$NetBSD: vfs_syscalls.c,v 1.543 2020/03/03 19:55:16 christos Exp $	*/
+/*	$NetBSD: vfs_syscalls.c,v 1.544 2020/03/25 18:08:34 gdt Exp $	*/
 
 /*-
  * Copyright (c) 2008, 2009, 2019, 2020 The NetBSD Foundation, Inc.
@@ -70,7 +70,7 @@
  */
 
 #include 
-__KERNEL_RCSID(0, "$NetBSD: vfs_syscalls.c,v 1.543 2020/03/03 19:55:16 christos Exp $");
+__KERNEL_RCSID(0, "$NetBSD: vfs_syscalls.c,v 1.544 2020/03/25 18:08:34 gdt Exp $");
 
 #ifdef _KERNEL_OPT
 #include "opt_fileassoc.h"
@@ -4059,8 +4059,7 @@ sys_fsync(struct lwp *l, const struct sy
  * Sync a range of file data.  API modeled after that found in AIX.
  *
  * FDATASYNC indicates that we need only save enough metadata to be able
- * to re-read the written data.  Note we duplicate AIX's requirement that
- * the file be open for writing.
+ * to re-read the written data.
  */
 /* ARGSUSED */
 int
@@ -4141,10 +4140,6 @@ sys_fdatasync(struct lwp *l, const struc
 	/* fd_getvnode() will use the descriptor for us */
 	if ((error = fd_getvnode(SCARG(uap, fd), )) != 0)
 		return (error);
-	if ((fp->f_flag & FWRITE) == 0) {
-		fd_putfile(SCARG(uap, fd));
-		return (EBADF);
-	}
 	vp = fp->f_vnode;
 	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
 	error = VOP_FSYNC(vp, fp->f_cred, FSYNC_WAIT|FSYNC_DATAONLY, 0, 0);

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

[Greg Troxel]

J. Hannken-Illjes  writes:

>> 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
>
> This is NOT our upstream --

This seems to be hard to figure out.  Is there someplace in the tree
that says what our upsream is, and what theirs is, and how all of the
various trees out there relate?  And how we should be sending things,
and getting things?

I tried to figure this out, and ended up with

http://wiki.netbsd.org/zfs/

which has lots of \todo statements.

Re: CVS commit: src/sys/sys

[Greg Troxel]

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.

Re: CVS commit: src/sys/sys

[Greg Troxel]

Martin Husemann  writes:

> On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
>> Well, we are coming up on a year since netbsd-9 was branched, or at
>> least will arrive there before this discussion resolves.   So cutting
>> -10 before we hit 100 works for me :-)
>
> Nitpicking (and I don't know for the discussion resolving), but netbsd-9
> was branched on 2019-07-30 (so not even 1/2 a year yes).
>
> The branch for netbsd-10 can happen soon after Andrew is done (we need
> 10.0 on the build cluster ASAP).

I will admit that my comment was partly humor.

Thanks for pointing out the -9 branch date.  Given that we have had an
RC, this branch is going much better than recent previous ones.  I
realize it's always difficult, but I think we (mostly you, perhaps) are
doing better this time.

I did mean to be somewhat serious in saying it was going to be time to
start 10, just based on calendar, because I believe releases should be
no more than 18 months apart, and I think 12 months is ideal.  Thus I am
in favor of starting a new branch 12 months after the last one was
started.

(I see the merits of points about lots of improvements in current vs 9
and the reasonableness of branching late spring and releasing fall, even
if that seems a bit aspirational.)

Re: CVS commit: src/sys/sys

[Greg Troxel]

Kamil Rytarowski  writes:

> On 23.12.2019 01:54, Roy Marples wrote:
>> On 22/12/2019 22:24, Andrew Doran wrote:
>>> NetBSD 9.99.29 - struct mount changed.
>> 
>> Just curious - does our build software cope with 3 digit for the last
>> number?
>> 
>> Roy
>
> At least from the __NetBSD_Version__ point of view there are 4 digits
> unused, but it is more valuable to branch -10 earlier than going to
> 3-digit patchlevel.

Well, we are coming up on a year since netbsd-9 was branched, or at
least will arrive there before this discussion resolves.   So cutting
-10 before we hit 100 works for me :-)

Re: CVS commit: src/share/mk

[Greg Troxel]

David Brownlee  writes:

> On Thu, 14 Nov 2019 at 21:05, Christos Zoulas  wrote:
>>
>> 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

Me too.

My sense of the list is that

  most people want unpacking sets over a system to work as well as it
  used to work

  some people really want a tar that handles newer formats, and probably
  everything thinks this would be good

  some concern has been expresseed over performance, but more people
  have expressed the notion that things working correctly (which does
  not have a universal definition) is more important.

so Christos's proposal seems to steer very well to this rough consensus.

> Thanks for working on this!

Seconded!

Re: CVS commit: src

[Greg Troxel]

m...@netbsd.org writes:

> These seem to be lowercase versions of the same names. We're going to
> have trouble with the people who use case insensitive filesystems and
> CVS.

With any luck the multicase stuff is just dups to prune and not useful.


> (Or maybe it's not so bad because they're files, not directories?)

Doesn't matter - still bad.

What happens is that cvs creates one of the files, and then when it
creates the other finds a file already there, or overwrites it, so the
other one shows up modified.   Probably there is a bigger explosion with
directories...

Re: CVS commit: src/distrib/amd64/liveimage/emuimage

[Greg Troxel]

Martin Husemann  writes:

> On Thu, Aug 08, 2019 at 08:09:19PM -0400, Greg Troxel wrote:
>> In addition, I don't like it that images have stuff in /boot in the DOS
>> partition that can't be found in some obvious place, like /usr/mdec.
>> But I haven't gotten around to trying to fix it either so I get it that
>> ENOPATCH.
>
> Yes, but in this case the bug is that sysinst does not know how to properly
> fill the /boot things - which is on my TODO list.
>
> (and also, as you mention, that there is no obvious easy source for the 
> content)

I was talking about the first bug, that these things aren't in the
destdir of a build.  The following belong on /usr/mdec/RPI, or similar,
either for all arm build (or when MKRPI=yes if we want to split that
out).

-rwxr-xr-x  1 root  wheel 1494 Oct 26  2017 LICENCE.broadcom
-rwxr-xr-x  1 root  wheel17932 Oct 26  2017 bootcode.bin
-rwxr-xr-x  1 root  wheel  105 Nov  9  2018 cmdline.txt
-rwxr-xr-x  1 root  wheel 6624 Oct 26  2017 fixup.dat
-rwxr-xr-x  1 root  wheel 2533 Oct 26  2017 fixup_cd.dat
-rwxr-xr-x  1 root  wheel  2823716 Oct 26  2017 start.elf
-rwxr-xr-x  1 root  wheel   634948 Oct 26  2017 start_cd.elf

Arguably installboot should be taught to deal with this; it's a FAT
partition instead of blocks 0-15, but it strikes me as the same thing
logically.

Re: CVS commit: src/distrib/amd64/liveimage/emuimage

[Greg Troxel]

Andreas Gustafsson  writes:

> I really don't like the general idea of introducing differences
> between images and systems installed through sysinst.  It's confusing
> for users, and also means that testing of one is less likely to apply
> to the other.

Agreed strongly.

In addition, I don't like it that images have stuff in /boot in the DOS
partition that can't be found in some obvious place, like /usr/mdec.
But I haven't gotten around to trying to fix it either so I get it that
ENOPATCH.

CVS commit: src/etc

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Mon Jul 29 17:53:20 UTC 2019

Modified Files:
src/etc: MAKEDEV.tmpl

Log Message:
MAKEDEV.tmpl: Create nodes for 16 USB hubs

As proposed on current-users, but with better formatting.


To generate a diff of this commit:
cvs rdiff -u -r1.204 -r1.205 src/etc/MAKEDEV.tmpl

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

Modified files:

Index: src/etc/MAKEDEV.tmpl
diff -u src/etc/MAKEDEV.tmpl:1.204 src/etc/MAKEDEV.tmpl:1.205
--- src/etc/MAKEDEV.tmpl:1.204	Fri May 31 13:15:00 2019
+++ src/etc/MAKEDEV.tmpl	Mon Jul 29 17:53:20 2019
@@ -1,5 +1,5 @@
 #!/bin/sh -
-#	$NetBSD: MAKEDEV.tmpl,v 1.204 2019/05/31 13:15:00 nia Exp $
+#	$NetBSD: MAKEDEV.tmpl,v 1.205 2019/07/29 17:53:20 gdt Exp $
 #
 # Copyright (c) 2003,2007,2008 The NetBSD Foundation, Inc.
 # All rights reserved.
@@ -914,6 +914,7 @@ ramdisk)
 
 usbs)
 	makedev usb usb0 usb1 usb2 usb3 usb4 usb5 usb6 usb7
+	makedev usb8 usb9 usb10 usb11 usb12 usb13 usb14 usb15
 	makedev uhid0 uhid1 uhid2 uhid3 uhid4 uhid5
 	makedev uhid6 uhid7 uhid8 uhid9 uhid10 uhid11
 	makedev uhid12 uhid13 uhid14 uhid15

CVS commit: src/etc

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Mon Jul 29 17:53:20 UTC 2019

Modified Files:
src/etc: MAKEDEV.tmpl

Log Message:
MAKEDEV.tmpl: Create nodes for 16 USB hubs

As proposed on current-users, but with better formatting.


To generate a diff of this commit:
cvs rdiff -u -r1.204 -r1.205 src/etc/MAKEDEV.tmpl

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

CVS commit: src/sys/dev/ic

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Mon Jul 29 12:07:57 UTC 2019

Modified Files:
src/sys/dev/ic: mfi.c

Log Message:
sys/dev/ic/mfi.c: Add missing break in switch

(The entire switch is guarded by MFI_DEBUG and is known not to build.)
Reported by Oskar.


To generate a diff of this commit:
cvs rdiff -u -r1.60 -r1.61 src/sys/dev/ic/mfi.c

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

CVS commit: src/sys/dev/ic

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Mon Jul 29 12:07:57 UTC 2019

Modified Files:
src/sys/dev/ic: mfi.c

Log Message:
sys/dev/ic/mfi.c: Add missing break in switch

(The entire switch is guarded by MFI_DEBUG and is known not to build.)
Reported by Oskar.


To generate a diff of this commit:
cvs rdiff -u -r1.60 -r1.61 src/sys/dev/ic/mfi.c

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

Modified files:

Index: src/sys/dev/ic/mfi.c
diff -u src/sys/dev/ic/mfi.c:1.60 src/sys/dev/ic/mfi.c:1.61
--- src/sys/dev/ic/mfi.c:1.60	Sat Nov 24 18:10:29 2018
+++ src/sys/dev/ic/mfi.c	Mon Jul 29 12:07:57 2019
@@ -1,4 +1,4 @@
-/* $NetBSD: mfi.c,v 1.60 2018/11/24 18:10:29 bouyer Exp $ */
+/* $NetBSD: mfi.c,v 1.61 2019/07/29 12:07:57 gdt Exp $ */
 /* $OpenBSD: mfi.c,v 1.66 2006/11/28 23:59:45 dlg Exp $ */
 
 /*
@@ -73,7 +73,7 @@
  */
 
 #include 
-__KERNEL_RCSID(0, "$NetBSD: mfi.c,v 1.60 2018/11/24 18:10:29 bouyer Exp $");
+__KERNEL_RCSID(0, "$NetBSD: mfi.c,v 1.61 2019/07/29 12:07:57 gdt Exp $");
 
 #include "bio.h"
 
@@ -869,6 +869,7 @@ mfi_get_bbu(struct mfi_softc *sc, struct
 		stat->detail.bbu.remaining_capacity ,
 		stat->detail.bbu.full_charge_capacity ,
 		stat->detail.bbu.is_SOH_good);
+		break;
 	default:
 		printf("\n");
 	}

Re: CVS commit: src

[Greg Troxel]

Thomas Klausner  writes:

> P.S.: The file is 44k, so I'm not convinced by the "/ is small"
> argument. ;)

100 * 44k is 4400k :-)   The / and /usr distinction is longstanding, I
don't think we should give up on it easily.

Re: CVS commit: src/sys

[Greg Troxel]

Ryota Ozaki  writes:

>> And, if someone is inclined, having better checks with meaurable
>> slowdown under DEBUG sounds ok too, but my revised understanding is
>> unclear on whether that's helpful.  (But I am only trying to keep
>> performance under DIAGNOSTIC high; I am unconcerned about DEBUG and
>> don't need to understand.)
>
> I've proposed another implementation a few days ago (*).  That provides
> useful information for debugging in exchange for expensive overhead.
> It is enabled by PSREF_DEBUG.
>
> (*) https://mail-index.netbsd.org/tech-kern/2019/05/10/msg025049.html

That sounds useful when needed.  I don't mind if DEBUG turns on
PSREF_DEBUG, but it might be that turning it on only when there is a
known reproduction recipe for a leak is sensible.

Thanks all for the useful and rational discussion.

Re: CVS commit: src/sys

[Greg Troxel]

Ryota Ozaki  writes:

> On Tue, May 14, 2019 at 2:31 AM Jason Thorpe  wrote:
>>
>>
>>
>> > On May 13, 2019, at 7:17 AM, Greg Troxel  wrote:
>> >
>> > 2) Your option 2 seems to involve two things at once:
>> >
>> >  - migration to lwp_specificadata
>> >  - using DEBUG instead of DIAGNOSTIC to control the leak check feature
>> >
>> > I do not understand why changing the nature of the implementation is
>> > linked to how it is enabled.
>>
>> I think Ozaki-san saying that the 3% performance hit only happens
>> when lwp_specificdata is used, and hence that it would need to be
>> wrapped in DEBUG rather than DIAGNOSTIC.

Now this is all making sense.

>> The original negligible-impact implementation did NOT use
>> lwp_specificdata, and thus was fine for DIAGNOSTIC.  I believe
>> Ozaki-san's preference is to use *this* implementation so that it
>> can be exposed to a wider audience.  The lwp_specificdata approach
>> was only explored after someone else suggested a preference for it.
>>
>> At least, that's my understanding of the situation.
>
> Yes, your understanding is correct.  Thank you for the clarification.

So having a check under DIAGNOSTIC that you more or less can't measure
sounds just fine to me.  I only meant to object to a 3% slowdown under
DIAGNOSTIC.

And, if someone is inclined, having better checks with meaurable
slowdown under DEBUG sounds ok too, but my revised understanding is
unclear on whether that's helpful.  (But I am only trying to keep
performance under DIAGNOSTIC high; I am unconcerned about DEBUG and
don't need to understand.)

Re: CVS commit: src/sys

[Greg Troxel]

Ryota Ozaki  writes:

> On Sat, May 11, 2019 at 10:49 AM Greg Troxel  wrote:
>> >> I'm sorry for delaying this task.  Finally I have benchmarked a revised 
>> >> patch
>> >> (our benchmarking setups have been out of service for a couple of 
>> >> weeks...).
>> >>
>> >> Performance degradation of IP forwarding is 3%.  Is it acceptable as
>> >> DIAGNOSTIC?
>> >
>> > For DIAGNOSTIC should be fine.
>>
>> I think 3% is too much for DIAGNOSTIC.   DEBUG, sure, and a specific
>> option to turn it on seems fine.  DIAGNOSTIC historically has been only
>> for things that check invariants and assert, such that if you don't mind
>> the crashes when detecting things, there is no performance reason to
>> avoid it.
>
> So we have two options:
> 1. Keep the original (enabled on DIAGNOSTIC)
>   - Its performance impact is negligible
> 2. Migrate to use lwp_specificadata and enable the feature on DEBUG
> (and something)

I am not following two things:

1) You said that IP forwarding speed is reduced by 3%, and also that it
is a negligble performance impact.  In my view, 3% is not negligible.
DIAGNOSTIC should be sufficiently small performance impact that
essentially nobody wants to disable it to get better performance.  I
could see 0.3% as negligible.  But everything adds up, so it's not just
this, but the overall system with and without DIAGNOSTIC.

2) Your option 2 seems to involve two things at once:

  - migration to lwp_specificadata
  - using DEBUG instead of DIAGNOSTIC to control the leak check feature

I do not understand why changing the nature of the implementation is
linked to how it is enabled.

Overall, I think checking features (other than simple KASSSERTs) should
have their own ifdef, so people can individually enable them, and then
additionally there would be "#ifdef DEBUG // #define PSREFLEAKDETECT" or
something like that.

> I prefer to 1. because I want the feature to be enabled by many users

Sure, but many users prefer that their systems not be slowed down, too.
If we add 10 more checks that each cause 3% slowdown, then we have a
real problem.  DIAGNOSTIC has always had the sense that it should turn
undefined behavior into a panic, but not slow the system down, so that
the only reason to avoid it is not liking the panics.

> (I assume that users (of -current) tend to enable DIAGNOSTIC and not DEBUG).

On -current, DIAGNOSTIC is on by default.  When we branch 9, I expect
that it will remain on until very close to release.

I agree that most people do not have DEBUG on.

> If the detector is not enabled, a psref leak appears as a form that is
> difficult to know where the leak occurs; a fatal page fault occurs on
> psref_target_destroy that is a completely different context.  If
> enabled, we can at least know a suspect LWP or softint handler and may
> find a cause in luck.

How often do these leaks happen?  If DIAGNOSTIC without the new code
will assert or crash on a leak, but in a non-specific way, we know they
are fairly rare.  People who encounter them can add the define to enable
the more specific detector and continue running to catch the next leak.

It seems that if leaks are common, then it should be easy to find them
with a few people enabling the new detector.  If they are very rare,
then 3% forwarding speed is a large price to pay for finding them more
specifically the first time, on systems where they are not expected to
happen.

Another possibility  (that I don't advocate) is to set this up so that
it is enabled on DIAGNOSTIC with current, but not enabled with
DIAGNOSTIC on release branches.   I am much more concerned with
performance loss on releaes branches.

Another option is to enable it in current, until the bugs are fixed and
we don't see leaks, and then turn it off.

Please don't take this as criticism of your new leak detector.  We are
getting lots of checking code to look for many kinds of problems.  Some
of it is expensive to varying degrees.  Everyone benefits from having
the bugs fixed once found, and it's hard to draw the line about what
should be enabled by default.

Re: CVS commit: src/sys

[Greg Troxel]

Kamil Rytarowski  writes:

> On 08.05.2019 11:34, Ryota Ozaki wrote:
>> On Sat, Apr 20, 2019 at 6:45 PM Ryota Ozaki  wrote:
>>>
>>> On Fri, Apr 19, 2019 at 6:49 PM Kamil Rytarowski  wrote:

 On 19.04.2019 11:41, J. Hannken-Illjes wrote:
>> On 19. Apr 2019, at 03:52, Ryota Ozaki  wrote:
>>
>> Module Name: src
>> Committed By:ozaki-r
>> Date:Fri Apr 19 01:52:56 UTC 2019
>>
>> Modified Files:
>>  src/sys/kern: kern_lwp.c kern_softint.c subr_psref.c
>>  src/sys/rump/kern/lib/libsysproxy: sysproxy.c
>>  src/sys/sys: lwp.h userret.h
>>
>> Log Message:
>> Implement a simple psref leak detector
>>
>> It detects leaks by counting up the number of held psref by an LWP and 
>> checking
>> its zeroness at the end of syscalls and softint handlers.  For the 
>> counter, a
>> unused field of struct lwp is reused.
>
> For DIAGNOSTIC-only operations LWP specific data
> (see kern/subr_lwp_specificdata.c) is a better choice.
>

 I wanted to propose the same. An exampe of this is in KCOV.
>>>
>>> Thanks.  I'll try it.  (I'll be AFK for the next few days...)
>> 
>> I'm sorry for delaying this task.  Finally I have benchmarked a revised patch
>> (our benchmarking setups have been out of service for a couple of weeks...).
>> 
>> Performance degradation of IP forwarding is 3%.  Is it acceptable as
>> DIAGNOSTIC?
>> 
>
> For DIAGNOSTIC should be fine.

I think 3% is too much for DIAGNOSTIC.   DEBUG, sure, and a specific
option to turn it on seems fine.  DIAGNOSTIC historically has been only
for things that check invariants and assert, such that if you don't mind
the crashes when detecting things, there is no performance reason to
avoid it.

Re: CVS commit: src/etc

[Greg Troxel]

matthew green  writes:

> (i wouldn't pick 'wheel' as this group -- i would invent a
> new group either called 'net' or 'wpa', with no underscore
> since they're designed to be assigned, unlike the groups
> for specific programs security models.)

Are you saying that you are ok with the following:

   add a new group "net"

   by default, nobody is in it

   it's ok for things that modify networking config to allow this to be
   done by users in group net, in addition to root

   (so therefore, absent configuration by root, there are no additional
   privileges compared to now)

?

If so, that seems like a reasonable compromise compared to letting wheel
modify networking, and calling it "net" lets this be a logical privilege
in general, even if wpa config is the only thing right now.

Re: CVS commit: src/etc

[Greg Troxel]

Jason Thorpe  writes:

>> On Jan 13, 2019, at 5:21 AM, Greg Troxel  wrote:
>> 
>> Even if you have to be root, these changes are still hugely useful.
>> "sudo wpa_cli" is not that hard, even if it seems like it should not be
>> necessary.
>
> ...but made slightly more annoying seeing as how sudo is not part of the base 
> OS.

s/sudo wpa_cli/su root -c wpa_cli/

But yes, it is harder.  I had to read the su man page (back when I was
young, we didn't have sudo and had to use su uphill both ways after
toggling in the boot loader).

Re: CVS commit: src/etc

[Greg Troxel]

Roy Marples  writes:

> On 13/01/2019 10:20, matthew green wrote:
>> shouldn't one need to be root to modify network configuration?
>> i shouldn't be able to tell wpa_supplicant to do something as
>> non-root, in a default install.
>
> In a default install the only member of wheel is root and
> wpa_supplicant is not started.
>
> I suppose the real question is do we want to allow group access to
> wpa_supplicant and if so which group if not wheel?

That is indeed the real question.  As I see it wheel has historically
been a group for users that are system administrators, given how "su"
only allows users in wheel to su.  So it seems reasonable to allow
various configuration changes by users in wheel.

It seems the only point in putting somebody in wheel now is if you tell
them the root pw, to let them su.  Are there other reasons?

Another approach is to create a wpa_supplicant group, and allow wpa
changes by those in that group.  I can't see any reasonable objection to
this, other than group bloat.

> If we don't want to allow group access I may as well revert my changes
> and setup is then as before - the user is expected to configure
> everything themselves and wpa_cli won't work by default. This would be
> a shame as I've had a lot of positive feedback on this change already.

Even if you have to be root, these changes are still hugely useful.
"sudo wpa_cli" is not that hard, even if it seems like it should not be
necessary.

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

[Greg Troxel]

matthew green  writes:

>> In short, this is because -munaligned-access is enabled on ARMv6+ by
>> default for GCC. As the unaligned memory access is forbidden in the
>> supervisor mode unlike in the user mode, we need to explicitly specify
>> -mno-unaligned-access for kernel on ARMv6+.
>
> i think this seems like the right thing to do here.
>
> othewise we'd have to patch this all over..

Why do we generate code with unaligned access in user space?  That seems
surprising, if the processor isn't happy about it.

Re: CVS commit: src/sys/arch/evbarm/conf

[Greg Troxel]

matthew green  writes:

> Nick Hudson writes:
>> On 13/11/2018 08:21, matthew green wrote:
>> >> Modified Files:
>> >>   src/sys/arch/evbarm/conf: std.generic64
>> >>
>> >> Log Message:
>> >> turn on MODULAR by default on aarch64
>> > 
>> > optional things should not be in "std.foo".  that should be
>> > things that are necessary for basic function.  stuff that
>> > a user would never want to remove.
>> 
>> I thought core wanted MODULAR everywhere? If so, it's in the right 
>> place, I think.
>
> it's still "optional", even if we want it default everywhere.
> std.foo is for things that are not optional, that all users
> should have, no matter what choices they have.
>
> i should never have to look in std.foo to decide if an option
> should be removed for my config or not.

Agreed on both points.

Re: CVS commit: src/etc/etc.evbarm

[Greg Troxel]

Greg Troxel  writes:

> "Herbert J. Skuhra"  writes:
>
>> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
>>> 
>>> Module Name:src
>>> Committed By:   skrll
>>> Date:   Sun Nov  4 21:41:12 UTC 2018
>>> 
>>> Modified Files:
>>> src/etc/etc.evbarm: Makefile.inc
>>> 
>>> Log Message:
>>> Only add GENERIC to earmv6 and earmv7 builds
>>
>> This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U release".
>
> That seems like an unusual invocation.   Do you really mean it that way,
> instead of -a evbarm?   Passing earmv7hf to -a is an alias which sets
> both a amd m, and then the line is also setting m.Why do you include
> '-m evbarm' - what cpu type are you trying to build for?

Sorry, I was confused and wrote from memory and got it wrong.  You are
entirely right about your invocation.

I just actually read build.sh and adjusted the wording in the wiki.

Re: CVS commit: src/etc/etc.evbarm

[Greg Troxel]

"Herbert J. Skuhra"  writes:

> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
>> 
>> Module Name: src
>> Committed By:skrll
>> Date:Sun Nov  4 21:41:12 UTC 2018
>> 
>> Modified Files:
>>  src/etc/etc.evbarm: Makefile.inc
>> 
>> Log Message:
>> Only add GENERIC to earmv6 and earmv7 builds
>
> This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U release".

That seems like an unusual invocation.   Do you really mean it that way,
instead of -a evbarm?   Passing earmv7hf to -a is an alias which sets
both a amd m, and then the line is also setting m.Why do you include
'-m evbarm' - what cpu type are you trying to build for?

CVS commit: src/sys/arch/evbarm/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Wed Jul  4 13:32:01 UTC 2018

Modified Files:
src/sys/arch/evbarm/conf: RPI

Log Message:
RPI: remove commented-out pseudodevices

Remove a number of commented out pseudodevice lines that are
duplicative with GENERIC.common.  Othewise, someone might think it
reasonable to uncomment or add them.

For now, a number of pseudodevices that are not in GENERIC.common
remain, pending comments on the larger-scale rototill.


To generate a diff of this commit:
cvs rdiff -u -r1.82 -r1.83 src/sys/arch/evbarm/conf/RPI

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

CVS commit: src/sys/arch/evbarm/conf

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Wed Jul  4 13:32:01 UTC 2018

Modified Files:
src/sys/arch/evbarm/conf: RPI

Log Message:
RPI: remove commented-out pseudodevices

Remove a number of commented out pseudodevice lines that are
duplicative with GENERIC.common.  Othewise, someone might think it
reasonable to uncomment or add them.

For now, a number of pseudodevices that are not in GENERIC.common
remain, pending comments on the larger-scale rototill.


To generate a diff of this commit:
cvs rdiff -u -r1.82 -r1.83 src/sys/arch/evbarm/conf/RPI

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

Modified files:

Index: src/sys/arch/evbarm/conf/RPI
diff -u src/sys/arch/evbarm/conf/RPI:1.82 src/sys/arch/evbarm/conf/RPI:1.83
--- src/sys/arch/evbarm/conf/RPI:1.82	Sun Jul  1 15:33:29 2018
+++ src/sys/arch/evbarm/conf/RPI	Wed Jul  4 13:32:01 2018
@@ -1,5 +1,5 @@
 #
-#	$NetBSD: RPI,v 1.82 2018/07/01 15:33:29 skrll Exp $
+#	$NetBSD: RPI,v 1.83 2018/07/04 13:32:01 gdt Exp $
 #
 #	RPi -- Raspberry Pi
 #
@@ -217,21 +217,11 @@ options 	WSDISPLAY_DEFAULTSCREENS=4
 #pseudo-device	carp			# Common Address Redundancy Protocol
 #pseudo-device	ipfilter		# IP filter (firewall) and NAT
 #pseudo-device	kttcp			# network loopback
-#pseudo-device	ppp			# Point-to-Point Protocol
-#pseudo-device	pppoe			# PPP over Ethernet (RFC 2516)
-#options 	PPPOE_SERVER		# Enable PPPoE server via link0
 #pseudo-device	sl			# Serial Line IP
 #pseudo-device	strip			# Starmode Radio IP (Metricom)
 #pseudo-device	irframetty		# IrDA frame line discipline
-#pseudo-device	tap			# virtual Ethernet
-#pseudo-device	tun			# network tunneling over tty
-#pseudo-device	gre			# generic L3 over IP tunnel
-#pseudo-device	gif			# IPv[46] over IPv[46] tunnel (RFC 1933)
 #pseudo-device	faith			# IPv[46] TCP relay translation i/f
 #pseudo-device	stf			# 6to4 IPv6 over IPv4 encapsulation
-#pseudo-device	vlan			# IEEE 802.1q encapsulation
-#pseudo-device	bridge			# simple inter-network bridging
-#options	BRIDGE_IPF		# bridge uses IP/IPv6 pfil hooks too
 #pseudo-device	agr			# IEEE 802.3ad link aggregation
 #pseudo-device	pf			# PF packet filter
 #pseudo-device	pflog			# PF log if

Re: CVS commit: src/external

[Greg Troxel]

m...@netbsd.org writes:

> On Sun, Apr 08, 2018 at 04:57:07PM +, Jared D. McNeill wrote:
>> @@ -82,6 +82,10 @@ The licenses currently used are:
>>  mpl Mozilla Public license.
>>  https://opensource.org/licenses/MPL-2.0
>>  
>> +nvidia-firmware NVIDIA firmware license permitting redistribution for
>> +use on operating systems distributed under the terms
>> +of an OSI-approved open source license.
>> +
>>  public-domain   Non-license for code that has been explicitly put
>>  into the Public Domain.
>> 
>
> Can we talk to someone with legal expertise before importing code under
> this license?

One issue is that NetBSD's license permits proprietary derived works
(that's the BSD point).  But this really means that people doing that
have to drop the nvidia firmware, and probably other firmware (or get a
license).

To be amusingly pedantic, adding this means that NetBSD's license is
some combination of BSD, GPL (omitting details, MPL, etc. for brevity)
and the nvidia license.  However the nvidia license is not open source,
so NetBSD with nvidia fails to be OSI-approved.  But it seems unlikely
that NVIDIA means this interpretation.

Re: CVS commit: src/sys

[Greg Troxel]

Manuel Bouyer  writes:

> On Mon, Oct 02, 2017 at 02:39:47PM +0200, Maxime Villard wrote:
>> > Actually I did suggest to make the default dependant on MODULAR.
>> 
>> what's the point exactly?
>
> that if I build a non-modular kernel with an emulation option explicitely
> selected, it works at boot. Even in single-user mode.

I think the real point is hidden behind this statement.

If I just run GENERIC, because I'm not paying attention to details, then
I am not "building a non-modular kernel with an emulation option
explicitly selected".  I'm accepting a default.

As I understand it, the real debate is about whether the distributed
GENERIC kernel will run Linux emulation by default, or whether it should
require some enabling of that emulation.   All the rest is details
flowing from that main decision.

Certainly there could be a kernel option to default the sysctl to on.
People who wnt to "explicitly select an emulation optoon" can turn on
that define, and have it working from boot.   Then, I think the debate
reduces to "should the checked-in GENERIC enable the emulation sysctl".


signature.asc
Description: PGP signature

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

[Greg Troxel]

Nick Hudson  writes:

> On 09/10/16 16:46, Jonathan A. Kollasch wrote:
>> Module Name: src
>> Committed By:jakllsch
>> Date:Sat Sep 10 15:46:36 UTC 2016
>>
>> Modified Files:
>>  src/sys/dev/usb: usbdevices.config
>>
>> Log Message:
>> Make usscanner(4) useful by also attaching its children.
>>
> I was hoping to remove u{s,}scanner(4) in favour of userland drivers...

I think that's a good long-term plan, but it seems that usscanner(4),
when configured and enabled, should also work in the interrim.  But
maybe it doesn't work well enough to use at all anyway.



signature.asc
Description: PGP signature

CVS commit: src/sys/arch

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Sat Mar 19 23:21:03 UTC 2016

Modified Files:
src/sys/arch/alpha/conf: GENERIC
src/sys/arch/amd64/conf: GENERIC XEN3_DOM0
src/sys/arch/cats/conf: GENERIC
src/sys/arch/evbarm/conf: HDL_G HPT5325 SHEEVAPLUG SMDK2410
src/sys/arch/evbppc/conf: OPENBLOCKS266_OPT PMPPC
src/sys/arch/hpcmips/conf: GENERIC TX3922 VR41XX
src/sys/arch/hppa/conf: GENERIC
src/sys/arch/i386/conf: GENERIC XEN3_DOM0
src/sys/arch/landisk/conf: GENERIC
src/sys/arch/macppc/conf: GENERIC
src/sys/arch/sgimips/conf: GENERIC32_IP3x
src/sys/arch/sparc64/conf: GENERIC

Log Message:
Disable uscanner in all kernel configs

As discussed on current-users@, SANE uses ugen via libusb and not
uscanner, so users are not well served by having uscanner.  Consensus
is that addressing how to adjust permissions for scanners should not
block restoring basic functionionality.

(Compile-tested only, but there are multiple reports of this being the
right approach.)


To generate a diff of this commit:
cvs rdiff -u -r1.367 -r1.368 src/sys/arch/alpha/conf/GENERIC
cvs rdiff -u -r1.426 -r1.427 src/sys/arch/amd64/conf/GENERIC
cvs rdiff -u -r1.116 -r1.117 src/sys/arch/amd64/conf/XEN3_DOM0
cvs rdiff -u -r1.156 -r1.157 src/sys/arch/cats/conf/GENERIC
cvs rdiff -u -r1.44 -r1.45 src/sys/arch/evbarm/conf/HDL_G
cvs rdiff -u -r1.25 -r1.26 src/sys/arch/evbarm/conf/HPT5325
cvs rdiff -u -r1.47 -r1.48 src/sys/arch/evbarm/conf/SHEEVAPLUG
cvs rdiff -u -r1.58 -r1.59 src/sys/arch/evbarm/conf/SMDK2410
cvs rdiff -u -r1.18 -r1.19 src/sys/arch/evbppc/conf/OPENBLOCKS266_OPT
cvs rdiff -u -r1.35 -r1.36 src/sys/arch/evbppc/conf/PMPPC
cvs rdiff -u -r1.229 -r1.230 src/sys/arch/hpcmips/conf/GENERIC
cvs rdiff -u -r1.101 -r1.102 src/sys/arch/hpcmips/conf/TX3922
cvs rdiff -u -r1.64 -r1.65 src/sys/arch/hpcmips/conf/VR41XX
cvs rdiff -u -r1.7 -r1.8 src/sys/arch/hppa/conf/GENERIC
cvs rdiff -u -r1.1132 -r1.1133 src/sys/arch/i386/conf/GENERIC
cvs rdiff -u -r1.97 -r1.98 src/sys/arch/i386/conf/XEN3_DOM0
cvs rdiff -u -r1.47 -r1.48 src/sys/arch/landisk/conf/GENERIC
cvs rdiff -u -r1.320 -r1.321 src/sys/arch/macppc/conf/GENERIC
cvs rdiff -u -r1.107 -r1.108 src/sys/arch/sgimips/conf/GENERIC32_IP3x
cvs rdiff -u -r1.183 -r1.184 src/sys/arch/sparc64/conf/GENERIC

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

Re: CVS commit: src/tests/lib/libutil

[Greg Troxel]

"David A. Holland"  writes:

> Module Name:  src
> Committed By: dholland
> Date: Thu Dec 31 10:18:00 UTC 2015
>
> Modified Files:
>   src/tests/lib/libutil: t_parsedate.c
>
> Log Message:
> When evaluated on a Sunday, "next Sunday" means 7 days in the future,
> not 14. When evaluated on a Monday, it apparently means 13 days in the
> future. There's not exactly a spec for parsedate.y, so conform to the
> implementation.
>
> PR 50574.
>
> XXX: to me at least this is an odd notion of "next Sunday", but whatever...

It's clearly a bug.

On a Monday, "next Sunday" is 6 days away.  "Sunday week" is 13.

So perhaps the test should be correct, and the implementation fixed.



signature.asc
Description: PGP signature

Re: CVS commit: src/sys/net

[Greg Troxel]

chris...@astron.com (Christos Zoulas) writes:

> In article <20151210081103.e0fbbf...@cvs.netbsd.org>,
> Kengo NAKAHARA  wrote:
>>-=-=-=-=-=-
>>
>>Module Name:  src
>>Committed By: knakahara
>>Date: Thu Dec 10 08:11:03 UTC 2015
>>
>>Modified Files:
>>  src/sys/net: if_gif.c
>>
>>Log Message:
>>kmem_zalloc(, KM_SLEEP) must not return NULL.
>
> I would like to solicit opinions about this change and form a general
> policy.
>
> 1. I would like to reduce the use of KASSERT in the kernel, specially
> in situations like thee above where the test can be centralized (inside
> kmem_alloc) and avoided without being fatal.
>
> 2. Static analyzer models understand allocators, but they are not
> smart enough to determine under which situations they can fail. I
> believe even kmem_alloc with KM_SLEEP can fail when the size is
> large enough.
>
> So I propose to always check the return value of allocators with
> an 'if' and not a KASSERT.

I think that a function needs to have a contract specified in a contract
(and perhaps static analyzer markup).  Code should never KASSERT for
anything that can not be argued (statically shown) to be always true
given contracts.  So I agree with you.


signature.asc
Description: PGP signature

CVS commit: src/external/gpl3

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Mon Nov  2 00:51:18 UTC 2015

Modified Files:
src/external/gpl3/gcc.old/dist/gcc: Makefile.in
src/external/gpl3/gcc/dist/gcc: Makefile.in

Log Message:
Use -f with cp.

When the source tree is 444 (as should be unremarkable), cp results in
object files that are 444, which when cp'd again without -f result in
an error.


To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/external/gpl3/gcc.old/dist/gcc/Makefile.in
cvs rdiff -u -r1.10 -r1.11 src/external/gpl3/gcc/dist/gcc/Makefile.in

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

Modified files:

Index: src/external/gpl3/gcc.old/dist/gcc/Makefile.in
diff -u src/external/gpl3/gcc.old/dist/gcc/Makefile.in:1.3 src/external/gpl3/gcc.old/dist/gcc/Makefile.in:1.4
--- src/external/gpl3/gcc.old/dist/gcc/Makefile.in:1.3	Wed Sep 23 03:39:09 2015
+++ src/external/gpl3/gcc.old/dist/gcc/Makefile.in	Mon Nov  2 00:51:18 2015
@@ -1902,10 +1902,10 @@ gcc-nm.o: gcc-nm.c $(CONFIG_H) $(SYSTEM_
 # ??? the implicit rules dont trigger if the source file has a different name
 # so copy instead
 gcc-ranlib.c: gcc-ar.c
-	cp $^ $@
+	cp -f $^ $@
 
 gcc-nm.c: gcc-ar.c
-	cp $^ $@
+	cp -f $^ $@
 
 COLLECT2_OBJS = collect2.o collect2-aix.o tlink.o vec.o ggc-none.o file-find.o
 COLLECT2_LIBS = @COLLECT2_LIBS@

Index: src/external/gpl3/gcc/dist/gcc/Makefile.in
diff -u src/external/gpl3/gcc/dist/gcc/Makefile.in:1.10 src/external/gpl3/gcc/dist/gcc/Makefile.in:1.11
--- src/external/gpl3/gcc/dist/gcc/Makefile.in:1.10	Sun Jul 13 00:16:31 2014
+++ src/external/gpl3/gcc/dist/gcc/Makefile.in	Mon Nov  2 00:51:18 2015
@@ -1902,10 +1902,10 @@ gcc-nm.o: gcc-nm.c $(CONFIG_H) $(SYSTEM_
 # ??? the implicit rules dont trigger if the source file has a different name
 # so copy instead
 gcc-ranlib.c: gcc-ar.c
-	cp $^ $@
+	cp -f $^ $@
 
 gcc-nm.c: gcc-ar.c
-	cp $^ $@
+	cp -f $^ $@
 
 COLLECT2_OBJS = collect2.o collect2-aix.o tlink.o vec.o ggc-none.o file-find.o
 COLLECT2_LIBS = @COLLECT2_LIBS@

CVS commit: src/external/gpl3

[Greg Troxel]

Module Name:src
Committed By:   gdt
Date:   Mon Nov  2 00:51:18 UTC 2015

Modified Files:
src/external/gpl3/gcc.old/dist/gcc: Makefile.in
src/external/gpl3/gcc/dist/gcc: Makefile.in

Log Message:
Use -f with cp.

When the source tree is 444 (as should be unremarkable), cp results in
object files that are 444, which when cp'd again without -f result in
an error.


To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/external/gpl3/gcc.old/dist/gcc/Makefile.in
cvs rdiff -u -r1.10 -r1.11 src/external/gpl3/gcc/dist/gcc/Makefile.in

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

Re: CVS commit: src/external/cddl/osnet/dist/lib/libdtrace/common

[Greg Troxel]

chris...@zoulas.com (Christos Zoulas) writes:

> On Sep 25,  9:30am, m...@eterna.com.au (matthew green) wrote:
> -- Subject: re: CVS commit: src/external/cddl/osnet/dist/lib/libdtrace/common
>
> | when you sync things, can you also include what version you sunc with?
> | so for the next person to update, they know what baseline we have in
> | our tree.
>
> In this case all the source files have __FBSDID's... Do you mean add in
> the commit message the date and the time I did the last svn sync?

What I'd like to see is the commit message specify which FreeBSD branch
it came from (head presumably, but not entirely clear) and the date.
Your point about _FBSDID is fair, but doing a cvs up -D or the equiv in
FreeBSD before importing would make it clearer to do later updates
(since we can't/shouldn't tag FreeBSD's tree for exports to us).


pgpqZLL_BEH71.pgp
Description: PGP signature

Re: CVS commit: src/sys/dev

[Greg Troxel]

Michael van Elst mlel...@netbsd.org writes:

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

 Log Message:
 warn about labels only when built with DIAGNOSTIC

This feels like an abuse of DIAGNOSTIC, which is supposed to be about
asserts for detecting internal inconsistencies, not changing the
behavior of how the kernel responds to external inputs.

I don't have any problem with warnings for dodgy external input being
generally enabled, or having a separate verbose option.   I can't see
any reason not to have them, as it's not like new labels appearing is a
high-rate event that would dos the log.


pgpI40F0feW4P.pgp
Description: PGP signature

Re: CVS commit: src/distrib/atari/floppies/install

[Greg Troxel]

Izumi Tsutsui tsut...@ceres.dti.ne.jp writes:

 joerg@ wrote:

  Please don't commit untested and broken fix.
  Please file a PR instead if you can't test it.
 
 I agree with Christos that leaving the build broken is worse.  The
 alternative band aids are much more involved, too. That shouldn't stop
 the second point from that list.

 If you claim leaving the build broken is worse than commiting untested code,
 you should ask to update our commit guideline first:

 http://www.netbsd.org/developers/commit-guidelines.html

Perhaps we should.  The problems are:

  A broken build is evidence that the prior commits were not tested, and
  thus need fixing.  Objecting to fixing the build without testing
  should be a far lower priority than objecting to commits that break
  the build.

  A broken build, or a build that succeeds but fails to work is a
  serious problem because it prevents bisecting to find bugs.  I've seen
  this in current/i386 pretty often, less so recently.  During a ~week
  that the build was broken many commits happened, and some of those
  were trouble, and it was a mess to sort out.  So arguably no commits
  should be allowed at all during a time when the build is broken or
  there are sudden significant new test failures, other than fixing the
  build.

  


pgpPVycMH2F2d.pgp
Description: PGP signature

Re: CVS commit: src/distrib/atari/floppies/install

[Greg Troxel]

Joerg Sonnenberger jo...@britannica.bec.de writes:

 On Sun, Apr 26, 2015 at 10:07:32AM -0400, Greg Troxel wrote:

 A broken build is evidence that the prior commits were not tested,
 and thus need fixing.  Objecting to fixing the build without testing
 should be a far lower priority than objecting to commits that break
 the build.

 The problem here is that the original commit that triggered the
 overflow can and often enough is perfectly reasonable on all platforms
 without artifically low size constraints. What is needed to get at
 least basic regression testing done in an emulator?

Fair enough and a good point about emulator testing being really
helpful.


pgpGjBHUeCXLj.pgp
Description: PGP signature

Re: CVS commit: src/share/misc

[Greg Troxel]

S.P.Zeidler s...@netbsd.org writes:

 Thus wrote Paul Goyette (p...@vps1.whooppee.com):

 At the very les, if we're going to have these acronyms, they should be
 listed in a separate file which is not searched by default.  Similar to what
 is done with fortune(6).

 But that might not serve to indicate to these unwanted elements (women)
 that they are not welcome here and might face violence if they obtrude anyway.

Indeed.  This kind of content has no place in NetBSD or any other
open-source project.  It should just be removed.


pgpBXTvGTCS_1.pgp
Description: PGP signature

Re: CVS commit: src

[Greg Troxel]

Alan Barrett a...@cequrux.com writes:

 On Sat, 07 Mar 2015, Martin Husemann wrote:
 Anything that has no PCI.

 Could we rename LEGACY to something more descriptive?  The problem
 with the name LEGACY is that it leaves people wondering whether or
 not particular hardware is old enough to be classified as legacy.
 If the test is Does it have an ISA bus without a PCI bus? then I'd
 suggest a name like ISA_NO_PCI.

I agree about ISA_NO_PCI.   In addition, legacy is a really
problematic word in technical English, because it usually means how
people do things now, compared to the new thing I am proposing that I
think everyone should do instead.

I'm also not sure we need a new kernel config.  It seems the systems of
interest are limited to 486 machines without PCI (and thus EISA
probably), and that's a pretty narrow window around 1993-1994.  So
leaving the lines commented out with a comment explaining it in the
kernel config file is probably entirely adequate for the handful of
people who still have such hardware.


pgpVKVcCocu7L.pgp
Description: PGP signature

Re: CVS commit: src

[Greg Troxel]

David Laight da...@l8s.co.uk writes:

 I'm also not sure we need a new kernel config.  It seems the systems of
 interest are limited to 486 machines without PCI (and thus EISA
 probably), and that's a pretty narrow window around 1993-1994.  So
 leaving the lines commented out with a comment explaining it in the
 kernel config file is probably entirely adequate for the handful of
 people who still have such hardware.

 It is probably almost all 486 systems, and no pentium ones.
 They probably need a 'small' kernel anyway.

I had a 486DX4 motherboard, now broken, that had PCI.  A good point
about GENERIC not being ok.

 More interesting might be the embedded 486-like systems
 from soekris (etc). Not sure if any of those have graphics
 but they will normally run a generic kernel.

The Soekris net5501 and net6501 don't have any VGA, and I think the rest
also lack it.  But I see the point about the other SOC stuff.

So just NO_PCI is descriptive enough; we should rename the file is
going to stay.



pgpLvZZzmoZsm.pgp
Description: PGP signature

Re: CVS commit: src

[Greg Troxel]

Manuel Bouyer bou...@antioche.eu.org writes:

 On Sat, Mar 07, 2015 at 07:28:37AM +, matthew green wrote:
 Module Name: src
 Committed By:mrg
 Date:Sat Mar  7 07:28:37 UTC 2015
 
 Modified Files:
  src/distrib/notes/i386: contents
  src/etc/etc.i386: Makefile.inc
  src/sys/arch/i386/conf: GENERIC
 Added Files:
  src/sys/arch/i386/conf: LEGACY
 
 Log Message:
 remove vga@isa and pcdisplay@isa from i386 GENERIC, and create a new
 LEGACY kernel that includes them instead.  now radeon@pci is able to
 properly claim wsdisplay0 on i386 systems, and radeondrmkms has a good
 chance of working.
 
 this fixes PR#49290.

 This should also fix a problem I noticed with an intel device but
 didn't report yet:
 an intelfb0 is attached to i915drmkms0@pci, but a vga@isa is also
 attached, ending up with 2 wsdisplays. The console keyboard is then
 attached to wsdisplay1, leaving the console (wsdisplay0) without
 keyboard ...

Sorry, I missed the discussion on this.

Will LEGACY be built by default?

What's the set of computers that one has to use LEGACY on?
Is it just systems that are so old that vga is not via PCI?  Are there
thought to be any that have a 486 and could have worked?


pgp1UG8z4tTD0.pgp
Description: PGP signature

Re: CVS commit: src

[Greg Troxel]

Martin Husemann mar...@duskware.de writes:

 On Sat, Mar 07, 2015 at 08:13:17AM -0500, Greg Troxel wrote:
 Will LEGACY be built by default?

 I would vote no on that one.

 What's the set of computers that one has to use LEGACY on?

 Anything that has no PCI.

That sounds ok, then.

 Is it just systems that are so old that vga is not via PCI?  Are there
 thought to be any that have a 486 and could have worked?

 I have a working one of those, EISA, 486DX, basically sun-lamp lookalike
 (if you remember that). I plan to add it to my regular test schedule, maybe
 once a month.

I see - that is pretty ancient, and the number of people wanting to run
NetBSD (or anything) on those is probably tiny.

So this all seems fine to me - I just couldn't tell right away and had
wondered for a second if it was going to affect all machines that didn't
have the spiffy drm2-capacble hw.


pgpWRiUnVNExo.pgp
Description: PGP signature

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

[Greg Troxel]

chris...@astron.com (Christos Zoulas) writes:

 If we want to make every single change to go through tech-userlevel,
 we should institute a rule to do so. To my knowledge we don't have yet
 such a rule. We already have the rest of the p* programs which originated
 in Solaris, we were missing this one, so it made sense to me to add it.

We do sort of have a rule, which is that significant changes need
discussion.  I would say adding programs to base always counts.   Other
than that, it's trickier, but if there's a reasonable likelihood of a
valid objection, I'd say it's over the line into signficant/discuss.


pgp7H4fsvfMbX.pgp
Description: PGP signature

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

[Greg Troxel]

Marc Balmer m...@msys.ch writes:

 Am 03.03.15 um 14:35 schrieb Greg Troxel:
 
 chris...@astron.com (Christos Zoulas) writes:
 
 If we want to make every single change to go through
 tech-userlevel, we should institute a rule to do so. To my
 knowledge we don't have yet such a rule. We already have the rest
 of the p* programs which originated in Solaris, we were missing
 this one, so it made sense to me to add it.
 
 We do sort of have a rule, which is that significant changes need 
 discussion.  I would say adding programs to base always counts.
 Other than that, it's trickier, but if there's a reasonable
 likelihood of a valid objection, I'd say it's over the line into
 signficant/discuss.

 Adding new stuff bears a low risk of breaking existing stuff, so I
 think it does not need discussion all the time.

I meant that adding to base was discuss-worthy because there's a bloat
or necessary question, not because of risk of breakage.


pgpSkT3o7R8yK.pgp
Description: PGP signature

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

[Greg Troxel]

Marc Balmer m...@msys.ch writes:

 I meant that adding to base was discuss-worthy because there's a
 bloat or necessary question, not because of risk of breakage.

 Sure.  So how much bloat is pwait?  Is it a huge piece of software
 or a small utility?  I think that matters a bit.

Posting a note that says I would like to add X, and here's why, and my
comments on the bloat/necessary tradeoff. takes only a few minutes
(assuming well-formed thoughts already).  If there's no grumbling in
48-72h, that's fine.  It's not like this sort of review/comment costs a
lot or really gets in the way - new programs in base are pretty rare.

I don't think pwait is a big deal.  I do think that in general we have
too much commit first, argue about appropriate later.


pgpjC8D8gagfc.pgp
Description: PGP signature