Re: CVS commit: src

[J. Hannken-Illjes]

> On 29. May 2022, at 19:04, nia  wrote:
> 
> On Sun, May 29, 2022 at 05:50:30PM +0100, Alistair Crooks wrote:
>> But before starting to make piecemeal changes to the build system, maybe
>> some research into how others have accomplished this before with NetBSD?
>> 
>> I'd really like to avoid the plethora of (sometimes conflicting) switches
>> that make up the FreeBSD build system.
> 
> Hmm, okay.  I wouldn't like to introduce any conflicting options,
> and I'd like to keep the changes as unintrusive as possible, right
> now only modifying the make system and adding flags to the set lists.
> 
>> And I'd like to see discussion before any work is done (on a branch for
>> such intrusive changes) for this
> 
> OK, should I back out my changes?

Just a side note, how do we test a build system with say 20 knobs,
do we build all 2**20 configurations to be sure everything at
least builds?

Isn't it better to always build everything and move this selection
into the set lists or whatever you use to get the final image?

--
J. Hannken-Illjes - hann...@mailbox.org


signature.asc
Description: Message signed with OpenPGP

Re: CVS commit: src

[Alistair Crooks]

On Sun, May 29, 2022 at 17:39 nia  wrote:

>
> Hi, sorry I missed this email, please CC me next time.
>
> I talked about this a bit on ICB, but not on the lists yet.
>
> My end-game is to make it easier to make minimal embedded
> images of NetBSD.
>

A laudable endgoal.

But before starting to make piecemeal changes to the build system, maybe
some research into how others have accomplished this before with NetBSD?

I'd really like to avoid the plethora of (sometimes conflicting) switches
that make up the FreeBSD build system.

>
And I'd like to see discussion before any work is done (on a branch for
such intrusive changes) for this

Thanks,
Alistair

Re: CVS commit: src

[Frank Kardel]

Thanks for that explanation.

I was wondering if the same goal could be achieved with sypkgs as they 
seem to have about the same granularity as the MKxxx options.


You would still build all component but could populate the images from 
the set of syspkgs. So you would be able to generate tailored


images using appropriate sets of syspkgs.

I don't know how well tested syspkgs currently are, but maybe that is 
already closer what you would need for you goal. syspkgs are


already very granular per component.

running "build.sh syspkgs" will create all system packages.

Excerpt from my current syspkgs run:

...

Registered base-rcs-bin-9.99.97.0.20210420
  Packaged base-rcs-bin-9.99.97.0.20210420.tgz
Registered base-psd-share-9.99.97.0.20220524
  Packaged base-psd-share-9.99.97.0.20220524.tgz
Registered base-ppp-bin-9.99.97.0.20220412
  Packaged base-ppp-bin-9.99.97.0.20220412.tgz
Registered base-postfix-examples-9.99.97.0.20220524
  Packaged base-postfix-examples-9.99.97.0.20220524.tgz
Registered base-postfix-usr-9.99.97.0.20220524
  Packaged base-postfix-usr-9.99.97.0.20220524.tgz
Registered base-pkgutil-bin-9.99.97.0.20210420
  Packaged base-pkgutil-bin-9.99.97.0.20210420.tgz
Registered base-ntp-bin-9.99.97.0.20210420
  Packaged base-ntp-bin-9.99.97.0.20210420.tgz
Registered base-nis-bin-9.99.97.0.20220411
  Packaged base-nis-bin-9.99.97.0.20220411.tgz
Registered base-nfsserver-bin-9.99.97.0.20211127
  Packaged base-nfsserver-bin-9.99.97.0.20211127.tgz
Registered base-nfsclient-bin-9.99.97.0.20210420
  Packaged base-nfsclient-bin-9.99.97.0.20210420.tgz

...

here you already get the ntp binaries. There are other syskpgs for ntp 
etc files.


NTP syspkgs are:

-rw-r--r--  1 root  wheel  1106566 May 29 19:10 
/src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/base-ntp-bin-9.99.97.0.20210420.tgz
-rw-r--r--  1 root  wheel  700 May 29 19:06 
/src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/base-ntp-root-9.99.97.0.20220524.tgz
-rw-r--r--  1 root  wheel 2869 May 29 19:06 
/src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/etc-ntp-etc-9.99.97.0.20211028.tgz
-rw-r--r--  1 root  wheel 1730 May 29 19:06 
/src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/etc-ntp-rc-9.99.97.0.20201225.tgz
-rw-r--r--  1 root  wheel78090 May 29 19:12 
/src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/man-ntp-man-9.99.97.0.20100828.tgz
-rw-r--r--  1 root  wheel   225558 May 29 19:11 
/src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/misc-ntp-htmldoc-9.99.97.0.20220524.tgz


base-ntp-bin-9.99.97.0.20210420.tgz looks like:

Information for 
/src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/base-ntp-bin-9.99.97.0.20210420.tgz:


Comment:
utilities for network time protocol support

Requires:
base-sys-usr>=9.99.97

Description:
utilities for network time protocol support

Homepage:
http://www.NetBSD.org/


and contains:

Information for 
/src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/base-ntp-bin-9.99.97.0.20210420.tgz:


Files:
/usr/sbin/ntp-keygen
/usr/sbin/ntpd
/usr/sbin/ntpdate
/usr/sbin/ntpdc
/usr/sbin/ntpq
/usr/sbin/ntptime
/usr/sbin/ntptrace
/usr/sbin/sntp

Currently 1383 syspkgs are built.

There may be some work to clean up syspkgs but the structural packaging 
work is already done.


Example for a current issue:

/src/NetBSD/cur/src/distrib/sets/regpkg: ls: argument list too long
ls: No such file or directory
Registered comp-c-man-9.99.97.0.0

also some descriptions seem to be missing and other issues like missing 
(or mis-configured) packages.


Frank


On 05/29/22 18:39, nia wrote:

On Sun, May 29, 2022 at 09:34:16AM +0200, Frank Kardel wrote:

Hi *!

I see we are building knobs to not build and install parts of the system.
Somehow I missed the discussion on this. Could someone point me to that
thread, so that I can understand the overall rationale?

As for NTP: sysinst is configuring for ntp and ntpdate. How is sysinst
supposed to handle a potentially missing NTP installation?

Frank


Hi, sorry I missed this email, please CC me next time.

I talked about this a bit on ICB, but not on the lists yet.

My end-game is to make it easier to make minimal embedded
images of NetBSD.

At work we are shipping an embedded OS derived from FreeBSD,
with some patches and custom tools, and also "incredibly stripped down"
with many knobs similar to this.  It's extremely useful to exclude
some non-essential components from the build without modifying the
build system.

As for why I want to do this to NetBSD, I had the idea of making a
small-as-possible live image with GUI similar to Damn Small Linux.

This is obviously focused on live and embedded images, so nothing
using sysinst. It might be not too intrusive to conditionally enable
some options in sysinst, though.

There is a secondary goal, to identify groups of commands that are
related. When all you have is a big unstructured list of commands,
it's difficult to tell that everything configured with MKMROUTING
is enabled, or that it's related to the the kernel option MKROUTING.

I don't intend to 

Re: CVS commit: src

[nia]

On Sun, May 29, 2022 at 05:50:30PM +0100, Alistair Crooks wrote:
> But before starting to make piecemeal changes to the build system, maybe
> some research into how others have accomplished this before with NetBSD?
> 
> I'd really like to avoid the plethora of (sometimes conflicting) switches
> that make up the FreeBSD build system.

Hmm, okay.  I wouldn't like to introduce any conflicting options,
and I'd like to keep the changes as unintrusive as possible, right
now only modifying the make system and adding flags to the set lists.

> And I'd like to see discussion before any work is done (on a branch for
> such intrusive changes) for this

OK, should I back out my changes?

Re: CVS commit: src

[nia]

On Sun, May 29, 2022 at 09:34:16AM +0200, Frank Kardel wrote:
> Hi *!
> 
> I see we are building knobs to not build and install parts of the system.
> Somehow I missed the discussion on this. Could someone point me to that
> thread, so that I can understand the overall rationale?
> 
> As for NTP: sysinst is configuring for ntp and ntpdate. How is sysinst
> supposed to handle a potentially missing NTP installation?
> 
> Frank


Hi, sorry I missed this email, please CC me next time.

I talked about this a bit on ICB, but not on the lists yet.

My end-game is to make it easier to make minimal embedded
images of NetBSD.

At work we are shipping an embedded OS derived from FreeBSD,
with some patches and custom tools, and also "incredibly stripped down"
with many knobs similar to this.  It's extremely useful to exclude
some non-essential components from the build without modifying the
build system.

As for why I want to do this to NetBSD, I had the idea of making a
small-as-possible live image with GUI similar to Damn Small Linux. 

This is obviously focused on live and embedded images, so nothing
using sysinst. It might be not too intrusive to conditionally enable
some options in sysinst, though.

There is a secondary goal, to identify groups of commands that are
related. When all you have is a big unstructured list of commands,
it's difficult to tell that everything configured with MKMROUTING
is enabled, or that it's related to the the kernel option MKROUTING.

I don't intend to make it possible to remove components of NetBSD
that constitute some form of "API", whether that be in shell scripts
or otherwise, for compatibility's sake. The exception might be BIND
since it's quite large and people have concerns about both the
codebase and the license.  I also do not intend to make it possible
to build NetBSD without any components mandated by POSIX.

I hope this answer is satisfactory.

Re: CVS commit: src

[Frank Kardel]

Hi *!

I see we are building knobs to not build and install parts of the 
system. Somehow I missed the discussion on this. Could someone point me 
to that thread, so that I can understand the overall rationale?


As for NTP: sysinst is configuring for ntp and ntpdate. How is sysinst 
supposed to handle a potentially missing NTP installation?


Frank


On 05/28/22 13:17, Nia Alarie wrote:

Module Name:src
Committed By:   nia
Date:   Sat May 28 11:17:36 UTC 2022

Modified Files:
src/distrib/sets/lists/base: mi
src/distrib/sets/lists/debug: mi
src/distrib/sets/lists/etc: mi
src/distrib/sets/lists/man: mi
src/distrib/sets/lists/misc: mi
src/etc: Makefile
src/etc/rc.d: Makefile
src/external/bsd: Makefile
src/share/man/man5: mk.conf.5
src/share/mk: bsd.README bsd.own.mk

Log Message:
mk: Add MKNTP, MKTCPDUMP knobs.


To generate a diff of this commit:
cvs rdiff -u -r1.1302 -r1.1303 src/distrib/sets/lists/base/mi
cvs rdiff -u -r1.381 -r1.382 src/distrib/sets/lists/debug/mi
cvs rdiff -u -r1.267 -r1.268 src/distrib/sets/lists/etc/mi
cvs rdiff -u -r1.1743 -r1.1744 src/distrib/sets/lists/man/mi
cvs rdiff -u -r1.220 -r1.221 src/distrib/sets/lists/misc/mi
cvs rdiff -u -r1.460 -r1.461 src/etc/Makefile
cvs rdiff -u -r1.113 -r1.114 src/etc/rc.d/Makefile
cvs rdiff -u -r1.72 -r1.73 src/external/bsd/Makefile
cvs rdiff -u -r1.91 -r1.92 src/share/man/man5/mk.conf.5
cvs rdiff -u -r1.434 -r1.435 src/share/mk/bsd.README
cvs rdiff -u -r1.1280 -r1.1281 src/share/mk/bsd.own.mk

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

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

[Rin Okuyama]

On 2022/05/21 19:27, Rin Okuyama wrote:

Module Name:src
Committed By:   rin
Date:   Sat May 21 10:27:30 UTC 2022

Modified Files:
src/sys/dev/marvell: if_mvgbe.c

Log Message:
m_freem() *after* bus_dmamap_sync() and bus_dmamap_load() for
that mbuf. This is mandatory for some archs.


To generate a diff of this commit:
cvs rdiff -u -r1.64 -r1.65 src/sys/dev/marvell/if_mvgbe.c


s/load/unload/ here. Thanks riastradh@ for pointing out.

rin

Re: CVS commit: src/sbin/cgdconfig

[Robert Elz]

Please test it.  In HEAD today, and last week, and for probably
a long time back into the past, /sbin/cgdconfig has threads, and
/rescue/cgdconfig does not.

I don"t know when argon2 support was added, or how to use it,
but if you do, it should be simple to create an cgd in vnd using
one, and then attempt to access it using the other.

Let us know the results.

kre

Re: CVS commit: src/sbin/cgdconfig

[nia]

On Mon, May 16, 2022 at 09:10:40AM +, Taylor R Campbell wrote:
> Surely `disabling threads' just means cgdconfig can't take advantage
> of parallelism to compute the same function in less time, not that
> cgdconfig computes a different function or fails to compute the same
> function, no?
> 

My understanding is that argon2 gives different results for
different values of P:

$ echo test | argon2 testtest -i -p 18
Hash:   07d31bd489c4264bde42d32a2cb1cd6020964d9c5789ae96025c0111478e07b
$ echo test | argon2 testtest -i -p 19
Hash:   b02710381cfc4c943ce4bafc5ac28684a4878dedd01c5e25617e9424c87619a2

If the differences between P are preserved when compiled without
pthreads, then please ignore my comment :/

Re: CVS commit: src/sbin/cgdconfig

[Robert Elz]

Date:Mon, 16 May 2022 09:10:40 +
From:Taylor R Campbell 
Message-ID:  <20220516090946.a3c4660...@jupiter.mumble.net>

  | > Please re-enable threads. They influence the output hash
  | > so by disabling threads you stop people from being able
  | > to decrypt their disks.
  |
  | Surely `disabling threads' just means cgdconfig can't take advantage
  | of parallelism to compute the same function in less time, not that
  | cgdconfig computes a different function or fails to compute the same
  | function, no?

I agree, the issue, whatever it was that nia saw, is far more
likely caused by the namespace changes influencing just what
functions are getting called, in an unintended way, than by
anything related to threading.

Can we have threads back the way they were last week?  That
is not race around adding -lpthread to every static link
that exists, most likely breaking some size limits along the
way.

Then, once things build again, if there is a problem, we can
debug it, rather than just guessing.

kre

Re: CVS commit: src/sbin/cgdconfig

[Christos Zoulas]

> On May 16, 2022, at 5:10 AM, Taylor R Campbell  wrote:
> 
>> Date: Mon, 16 May 2022 04:49:22 +
>> From: nia 
>> 
>> On Sun, May 15, 2022 at 03:53:27PM -0400, Christos Zoulas wrote:
>>> Log Message:
>>> Build argon2 inline so that crunched programs work. I also disabled threads
>>> for now; we can put them back if needed.
>> 
>> Please re-enable threads. They influence the output hash
>> so by disabling threads you stop people from being able
>> to decrypt their disks.
> 
> Surely `disabling threads' just means cgdconfig can't take advantage
> of parallelism to compute the same function in less time, not that
> cgdconfig computes a different function or fails to compute the same
> function, no?
> 
> I agree threads should be re-enabled, but maybe it would be reasonable
> to find a way to conditionalize this on crunchgen/rescue/whatever if
> that gets in the way.
> 
> Christos, can you write down the problems that led to making this
> commit?  The commit message doesn't explain any of what went wrong so
> I don't even know what to look for when putting threads back.

It is simple. You just take out the cpp define to disable and add thread.c to 
the
list of files to be built and -lpthread. The reason I changed the build in 
cgdconfig
from reaching out to libargon2 and using the pre-built library to explicitly 
building
the necessary objects locally was that I did not want to teach rescue about 
libargon2.
I just disabled threads in the process because it was the same way done in 
libcrypt.
I didn't expect that this would produce different results. Rescue was not 
threaded before
but now I had to add -lpthread for it to link. The whole thing is very weird. 
It all started
with me protecting all the extra symbols that libargon2 exposed to libcrypt. 
This in
turn made cgdconfig not link in rescue because it was missing argon2_hash which
before it was resolving from libcrypt. Which means that the cgdconfig in rescue 
was
built without threads before... What a mess.

christos



signature.asc
Description: Message signed with OpenPGP

Re: CVS commit: src/sbin/cgdconfig

[Taylor R Campbell]

> Date: Mon, 16 May 2022 04:49:22 +
> From: nia 
> 
> On Sun, May 15, 2022 at 03:53:27PM -0400, Christos Zoulas wrote:
> > Log Message:
> > Build argon2 inline so that crunched programs work. I also disabled threads
> > for now; we can put them back if needed.
> 
> Please re-enable threads. They influence the output hash
> so by disabling threads you stop people from being able
> to decrypt their disks.

Surely `disabling threads' just means cgdconfig can't take advantage
of parallelism to compute the same function in less time, not that
cgdconfig computes a different function or fails to compute the same
function, no?

I agree threads should be re-enabled, but maybe it would be reasonable
to find a way to conditionalize this on crunchgen/rescue/whatever if
that gets in the way.

Christos, can you write down the problems that led to making this
commit?  The commit message doesn't explain any of what went wrong so
I don't even know what to look for when putting threads back.

Re: CVS commit: src/sbin/cgdconfig

[nia]

On Sun, May 15, 2022 at 03:53:27PM -0400, Christos Zoulas wrote:
> Log Message:
> Build argon2 inline so that crunched programs work. I also disabled threads
> for now; we can put them back if needed.

Please re-enable threads. They influence the output hash
so by disabling threads you stop people from being able
to decrypt their disks.

re: CVS commit: src/distrib/common/bootimage

[matthew green]

> > Module Name:src
> > Committed By:   mrg
> > Date:   Sun May 15 00:05:24 UTC 2022
> > 
> > Modified Files:
> > src/distrib/common/bootimage: Makefile.bootimage
> > 
> > Log Message:
> > allow some invocations of expr(1) to "fail" - expr(1) returns "1" is
> > the expression expands to "0" or empty, and sometimes these values end
> > up correctly being 0.
>
> Several values (SWAPSECTORS, EFISECTORS, FATSECTORS, and SWAPCYLINDERS)
> that couldbe zero already have '|| true'.  Should they be consistent?
> (I'm not sure if all should use strict '|| test $$? -eq 1 || exit 1')

i use the test -eq 1 method to only match the case expr(1)
exists due to "0" or "".  manual says:

The expr utility exits with one of the following values:
0   the expression is neither an empty string nor 0.
1   the expression is an empty string or 0.
2   the expression is invalid.
>2  an error occurred (such as memory allocation failure).

i kind of meant to fix the other uses too, thanks for
reminding me i wasn't done here :)


.mrg.

Re: CVS commit: src/distrib/common/bootimage

[Izumi Tsutsui]

mrg@ wrote:

> Module Name:  src
> Committed By: mrg
> Date: Sun May 15 00:05:24 UTC 2022
> 
> Modified Files:
>   src/distrib/common/bootimage: Makefile.bootimage
> 
> Log Message:
> allow some invocations of expr(1) to "fail" - expr(1) returns "1" is
> the expression expands to "0" or empty, and sometimes these values end
> up correctly being 0.

Several values (SWAPSECTORS, EFISECTORS, FATSECTORS, and SWAPCYLINDERS)
that couldbe zero already have '|| true'.  Should they be consistent?
(I'm not sure if all should use strict '|| test $$? -eq 1 || exit 1')

---
Izumi Tsutsui

Re: CVS commit: src

[Valery Ushakov]

On Sat, May 14, 2022 at 14:02:08 +, Valeriy E. Ushakov wrote:

> Module Name:  src
> Committed By: uwe
> Date: Sat May 14 14:02:08 UTC 2022
> 
> Modified Files:
>   src/distrib/sets/lists/base: mi
>   src/doc: 3RDPARTY
>   src/share/wscons/fonts: Makefile
> Added Files:
>   src/share/wscons/fonts: ter-i16b.wsf.uue ter-i16n.wsf.uue
>   ter-i16v.wsf.uue ter-i20n.wsf.uue ter-i24n.wsf.uue ter-i32n.wsf.uue
> 
> Log Message:
> Terminus Font: Import IBM-encoded versions from 4.49.1
> 
> Terminus Font is a clean, fixed width bitmap font, designed for long
> (8 and more hours per day) work with computers.
> 
> The font has a very good script coverage and subsets with other
> encodings can be imported in the future.
> 
> This commit imports IBM437 encoded (WSDISPLAY_FONTENC_ISO) subsets
> converted to WSF format.  wsfont metadata are stored in the files, so
> you can load them without any additional arguments to wsfontload(8).

*sigh* The log should say "WSDISPLAY_FONTENC_IBM", sorry.

-uwe

Re: CVS commit: src/common/lib/libc/atomic

[Nick Hudson]

On 14/05/2022 06:35, Nick Hudson wrote:

Module Name:src
Committed By:   skrll
Date:   Sat May 14 05:35:55 UTC 2022

Modified Files:
src/common/lib/libc/atomic: atomic_c11_compare_exchange_cas_16.c
atomic_c11_compare_exchange_cas_32.c
atomic_c11_compare_exchange_cas_8.c



Commit message should have been

lib/56832: __atomic_compare_exchange[_n] is wrong on non-mainstream
platforms

Make the implementation match the documentation wrt 'expected'

This built-in function implements an atomic compare and exchange
operation.This compares the contents of *ptr with the contents of
*expected. If equal, the operation is a read-modify-write operation that
writes desired into *ptr. If they are not equal, the operation is a read
and the current contents of *ptr are written into *expected.

Re: CVS commit: src/sys/arch

[Rin Okuyama]

Oops, I missed it. I will fix soon.

Thanks again,
rin

On 2022/05/07 17:24, Valery Ushakov wrote:

On Sat, May 07, 2022 at 04:12:55 +, Rin Okuyama wrote:


Module Name:src
Committed By:   rin
Date:   Sat May  7 04:12:55 UTC 2022

Modified Files:
src/sys/arch/evbppc/dht: locore.S
src/sys/arch/powerpc/include: spr.h

Log Message:
Instead of hard-coding SPR# for CCR0, define SPR_CCR0 in
 and use it.

Idea from uwe@, thanks!
(and sorry for delayed response!)


Note that we already have it defined (along with bunch of others) in
sys/arch/powerpc/include/ibm4xx/spr.h:74


-uwe

Re: CVS commit: src/sys/arch

[Valery Ushakov]

On Sat, May 07, 2022 at 04:12:55 +, Rin Okuyama wrote:

> Module Name:  src
> Committed By: rin
> Date: Sat May  7 04:12:55 UTC 2022
> 
> Modified Files:
>   src/sys/arch/evbppc/dht: locore.S
>   src/sys/arch/powerpc/include: spr.h
> 
> Log Message:
> Instead of hard-coding SPR# for CCR0, define SPR_CCR0 in
>  and use it.
> 
> Idea from uwe@, thanks!
> (and sorry for delayed response!)

Note that we already have it defined (along with bunch of others) in 
sys/arch/powerpc/include/ibm4xx/spr.h:74


-uwe

Re: CVS commit: src/sys/lib/libsa

[Rin Okuyama]

On 2022/04/28 3:29, Christos Zoulas wrote:

In article <20220427144850.61383f...@cvs.netbsd.org>,
Rin Okuyama  wrote:

-=-=-=-=-=-

Module Name:src
Committed By:   rin
Date:   Wed Apr 27 14:48:50 UTC 2022

Modified Files:
src/sys/lib/libsa: ext2fs.c minixfs3.c stand.h ufs.c

Log Message:
Revert previous at the moment.

This is wrong reasoning; 68020 and above (incl. 040 and 060) support
32-bit displacements for PC relative addressing (via "fully extension
addressing mode" with null index register).

I've still not figured out what goes wrong with amiga/boot(8) when
compiled without -l option for gas(1)...


But that was a nice change :-)


Thanks! Actually, it should be useful for ancient archs.

Now, amiga/boot(8) is fixed. I will enable this again.

rin

Re: CVS commit: src/sys/lib/libsa

[Christos Zoulas]

In article <20220427144850.61383f...@cvs.netbsd.org>,
Rin Okuyama  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  rin
>Date:  Wed Apr 27 14:48:50 UTC 2022
>
>Modified Files:
>   src/sys/lib/libsa: ext2fs.c minixfs3.c stand.h ufs.c
>
>Log Message:
>Revert previous at the moment.
>
>This is wrong reasoning; 68020 and above (incl. 040 and 060) support
>32-bit displacements for PC relative addressing (via "fully extension
>addressing mode" with null index register).
>
>I've still not figured out what goes wrong with amiga/boot(8) when
>compiled without -l option for gas(1)...

But that was a nice change :-)

christos

Re: CVS commit: src/sys/arch/x68k/stand

[Izumi Tsutsui]

> Module Name:  src
> Committed By: mlelstv
> Date: Mon Apr 25 15:12:07 UTC 2022
> 
> Modified Files:
>   src/sys/arch/x68k/stand/boot: conf.c
>   src/sys/arch/x68k/stand/xxboot: Makefile.xxboot xx.c
> 
> Log Message:
> libsa now needs ioctl to support media with large sectors. Provide
> missing functions.

Only for bootloaders that load a kernel?

FS_xxx ops in libsa is also used to load secondary bootloaders
(not a kernel that might require module info) on several ports,
including x86, and I guess in that case ioctl or the "fsmod" variable
is not necessary as before.
(I'm afraid "const char *fsmod" might require some ifdefs)
---
Izumi Tsutsui

Re: CVS commit: src/sys/arch/amiga/stand/bootblock/elf2bb

[Rin Okuyama]

On 2022/04/25 23:03, Rin Okuyama wrote:

Module Name:src
Committed By:   rin
Date:   Mon Apr 25 14:03:15 UTC 2022

Modified Files:
src/sys/arch/amiga/stand/bootblock/elf2bb: chksum.c elf2bb.c

Log Message:
Use htobe{16,32}(9) instead of be{16,32}toh(9) where appropriate.

No binary changes both for little and big endian machines.


Oops, "be{16,32}toh(3) instead of htobe{16,32}(3)", apparently...

Thanks,
rin

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

[J. Hannken-Illjes]

> On 16. Apr 2022, at 18:40, Andrius Varanavicius  wrote:
> 
> Module Name:  src
> Committed By: andvar
> Date: Sat Apr 16 16:40:54 UTC 2022
> 
> Modified Files:
>   src/sys/dev/raidframe: rf_netbsdkintf.c
> 
> Log Message:
> Fix mistake in error branch locking caused by previous changes.
> vput(vp) also unlocks vp, thus unlocking happens twice in error flow
> causing kernel to panic with failed assertion lktype != LK_NONE
> in vfs_vnode.c#778. Thanks riastradh with finding the issue.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.406 -r1.407 src/sys/dev/raidframe/rf_netbsdkintf.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.

Thanks, replacing vput() with vrele() would have been even better ...

--
J. Hannken-Illjes - hann...@mailbox.org


signature.asc
Description: Message signed with OpenPGP

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

[Jason Thorpe]

> On Mar 26, 2022, at 9:39 AM, Taylor R Campbell 
>  wrote:
> 
> `C string' is ambiguous because there are also char arrays that
> function as strings but which are not guaranteed to be NUL-terminated,
> as strncpy is intended for.

A non-terminated char array is not a C-string.  The term C-string is not 
ambiguous.  This is something that, amazingly, even Internet trolls appear to 
agree on.  However, they do disagree as to the spelling of the terminating 
character's name, which is why I think it's best to elide it altogether.

-- thorpej

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

[Jason Thorpe]

> On Mar 26, 2022, at 9:09 AM, Warner Losh  wrote:
> 
> Since all the 'C' standards[*] use "null-terminated" and "null character", 
> it's likely best to use that terminology because there is a source of truth 
> for its definition in case of ambiguity or doubt.

Ah, but you're giving up the opportunity to use indirection to solve the 
problem.  By calling it a "C-string", then those who care what the standard 
calls the terminating character can go look it up! :-)

-- thorpej

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

[Warner Losh]

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

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

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

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

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

Warner

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

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

[Taylor R Campbell]

> 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).

`C string' is ambiguous because there are also char arrays that
function as strings but which are not guaranteed to be NUL-terminated,
as strncpy is intended for.

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

[Jason Thorpe]

> On Mar 26, 2022, at 9:17 AM, Martin Husemann  wrote:
> When talking about it I prefer "zero terminated", or C-string, in
> contrast to C++ std::string (which are objects) or Pascal strings
> (which have an explicit length at the beginning).

Yes, I also prefer the term “C-string"

-- thorpej

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

[Martin Husemann]

On Sat, Mar 26, 2022 at 04:53:19PM +0100, Roland Illig wrote:
> The term "null-terminated string" is quite common when talking about C.

NULL terminated lists/array are quite common, but NULL is a pointer and
the string is terminated by a 0 char (sometimes spelled as \0 in a string
literal, but implicitly added by the compiler at the end of a literal,
and spelled as NUL in the ascii table).

>  I prefer to keep "null-terminated" here.

I think it is a bug.

When talking about it I prefer "zero terminated", or C-string, in
contrast to C++ std::string (which are objects) or Pascal strings
(which have an explicit length at the beginning).

Martin

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

[Roland Illig]

Am 24.03.2022 um 02:55 schrieb David H. Gutteridge:

Module Name:src
Committed By:   gutteridge
Date:   Thu Mar 24 01:55:15 UTC 2022

Modified Files:
src/lib/libc/gen: popen.3

Log Message:
popen.3: minor spelling, grammar, style, and xref tweaks


To generate a diff of this commit:
cvs rdiff -u -r1.22 -r1.23 src/lib/libc/gen/popen.3


The term "null-terminated string" is quite common when talking about C.
 In contrast, the word "nul" in "nul-terminated" always reminds me of
the character abbreviation in ASCII, which has a narrower scope than C.
 I prefer to keep "null-terminated" here.

Roland

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

[Christos Zoulas]

In article <977b81a4-d330-6722-7ce4-cc4e61011...@gmx.de>,
Roland Illig   wrote:
>Am 25.03.2022 um 22:25 schrieb Christos Zoulas:
>> In article <20220325183551.0f039f...@cvs.netbsd.org>,
>> Roland Illig  wrote:
>>> -=-=-=-=-=-
>>>
>>> Module Name:src
>>> Committed By:   rillig
>>> Date:   Fri Mar 25 18:35:50 UTC 2022
>>>
>>> Modified Files:
>>> src/lib/libc/time: localtime.c
>>>
>>> Log Message:
>>> localtime.c: add back storage class 'register'
>>>
>>> This reduces the differences to the upstream code.
>>
>> I don't know why you did that. It is as simple to sed -e 's/register //g'
>> in upstream when you diff. Adding register is useless; these days it is
>> mostly ignored by compilers, except you can't &...
>
>I thought that having a small diff to the upstream code was more
>important than a few saved keywords.  If I was wrong, I can of course
>revert it.

I don't care too much, less clutter without obsolete keywords that do
nothing or worse.

christos

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

[Roland Illig]

Am 26.03.2022 um 00:50 schrieb Tobias Nygren:

On Sat, 26 Mar 2022 00:31:45 +0100
Roland Illig  wrote:


localtime.c: add back storage class 'register'

This reduces the differences to the upstream code.


I don't know why you did that. It is as simple to sed -e 's/register //g'
in upstream when you diff. Adding register is useless; these days it is
mostly ignored by compilers, except you can't &...


I thought that having a small diff to the upstream code was more
important than a few saved keywords.  If I was wrong, I can of course
revert it.


Can we keep it as-is, but #define register to empty at the top of the file?


I don't think the compiler's view on the code is the main point of this
discussion.  At least, GCC generates the same code on x86_64, with or
without 'register', so it doesn't seem to care.

To me, the more interesting question is how human readers should deal
with the code.

If this piece of code had originated in the NetBSD tree, I wouldn't have
added the 'register' keywords, I would have just indented the code
according to KNF.

But, most of this code is copied from the tz project, therefore our goal
should be to make the diff minimal, in order to benefit from the testing
of other projects using the same code.  In this case, it means to keep
the indentation exactly as inconsistent as upstream and also to keep the
keyword 'register'.  The remaining diff is still large enough to consume
some developer time, containing a few fixes for WARNS=6 and for the lint
checks.

Roland

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

[Tobias Nygren]

On Sat, 26 Mar 2022 00:31:45 +0100
Roland Illig  wrote:

> >> localtime.c: add back storage class 'register'
> >>
> >> This reduces the differences to the upstream code.
> >
> > I don't know why you did that. It is as simple to sed -e 's/register //g'
> > in upstream when you diff. Adding register is useless; these days it is
> > mostly ignored by compilers, except you can't &...
> 
> I thought that having a small diff to the upstream code was more
> important than a few saved keywords.  If I was wrong, I can of course
> revert it.

Can we keep it as-is, but #define register to empty at the top of the file?

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

[Roland Illig]

Am 25.03.2022 um 22:25 schrieb Christos Zoulas:

In article <20220325183551.0f039f...@cvs.netbsd.org>,
Roland Illig  wrote:

-=-=-=-=-=-

Module Name:src
Committed By:   rillig
Date:   Fri Mar 25 18:35:50 UTC 2022

Modified Files:
src/lib/libc/time: localtime.c

Log Message:
localtime.c: add back storage class 'register'

This reduces the differences to the upstream code.


I don't know why you did that. It is as simple to sed -e 's/register //g'
in upstream when you diff. Adding register is useless; these days it is
mostly ignored by compilers, except you can't &...


I thought that having a small diff to the upstream code was more
important than a few saved keywords.  If I was wrong, I can of course
revert it.

Roland

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

[Christos Zoulas]

In article ,
Roland Illig   wrote:
>
>The mess with the indentation comes from upstream.  In our copy it's a
>bit worth than upstream, but not much.

I've asked upstream to indent consistently in the past. It has not happened.
I try to minimize the diffs with upstream so that we can keep patching in
our changes. I've also submitted our changes for inclusion to upstream.
Some have been accepted, others have not.

Best,

christos

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

[Christos Zoulas]

In article <20220325183551.0f039f...@cvs.netbsd.org>,
Roland Illig  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  rillig
>Date:  Fri Mar 25 18:35:50 UTC 2022
>
>Modified Files:
>   src/lib/libc/time: localtime.c
>
>Log Message:
>localtime.c: add back storage class 'register'
>
>This reduces the differences to the upstream code.

I don't know why you did that. It is as simple to sed -e 's/register //g'
in upstream when you diff. Adding register is useless; these days it is
mostly ignored by compilers, except you can't &...

christos

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

[Christos Zoulas]

In article <20220325190016.15114f...@cvs.netbsd.org>,
Roland Illig  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  rillig
>Date:  Fri Mar 25 19:00:16 UTC 2022
>
>Modified Files:
>   src/lib/libc/time: localtime.c
>
>Log Message:
>localtime.c: take indentation style from upstream

That I am fine with, but remember that some of the indentation changes
in upstream were gratuitus (no code changes).

christos

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

[Roland Illig]

Am 25.03.2022 um 13:59 schrieb Robert Elz:

 Date:Thu, 24 Mar 2022 23:32:30 +0100
 From:Roland Illig 
 Message-ID:  <6bb00924-edaf-a4c8-348e-ba1304d57...@gmx.de>

   | Someone should clean up this mess.

No, they probabky shouldn't, in general.

That source comes from the tz project (currently from
tzcode2022a) with local modifications.


When I said "somebody" above, I really meant "somebody at the
appropriate position".  I already suspected that this would not be
NetBSD.  Sorry for the brevity.


I think upstream mostly uses ts=4 (or more likely
the emacs equivalent).   we mostky use tab, and view
with ts=8 and yes, that can mead to ugly results.


The mess with the indentation comes from upstream.  In our copy it's a
bit worth than upstream, but not much.

Roland

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

[Robert Elz]

Date:Thu, 24 Mar 2022 23:32:30 +0100
From:Roland Illig 
Message-ID:  <6bb00924-edaf-a4c8-348e-ba1304d57...@gmx.de>

  | Someone should clean up this mess.

No, they probabky shouldn't, in general.

That source comes from the tz project (currently from
tzcode2022a) with local modifications.

I think upstream mostly uses ts=4 (or more likely
the emacs equivalent).   we mostky use tab, and view
with ts=8 and yes, that can mead to ugly results.

But to ease merging of future versions, this should be
touched as little as possible.

kre

ps: one way and another we have plenty of localtime
testing, not all in tests/libc.  At least for general
correctness.  I don't know if all the various hard casez
are as well tested locally, but changes that would
affect thise generally come from upstream.   Lots of
people do lots of tests on the upstream code.

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

[Roland Illig]

Am 24.03.2022 um 17:15 schrieb Christos Zoulas:

Module Name:src
Committed By:   christos
Date:   Thu Mar 24 16:15:05 UTC 2022

Modified Files:
src/lib/libc/time: localtime.c

Log Message:
put back the 2022a changes and fix the misplaced brace.


To generate a diff of this commit:
cvs rdiff -u -r1.128 -r1.129 src/lib/libc/time/localtime.c


The indentation of this file looks completely random:

Line 272 has a comment indented by 2 spaces, the code in that block is
indented by 4 spaces instead of the usual tab.  Same for line 295.

Line 350 is indented differently than line 346.

Line 420 has a continuation that is indented by 2 spaces instead of the
usual 4.

Line 490 is indented by 2 spaces instead of the usual tab.

Line 513 is indented by 4 spaces instead of the usual tab.

Line 534 is indented by 2 spaces instead of the usual tab.

Line 585 is indented by 2 spaces instead of the usual tab.

Line 667 is indented by 2 tabs instead of the usual 1 tab.

Line 683 is indented by 2 tabs instead of the usual tab.

Line 688 is indented by 2 spaces instead of the usual tab.

Line 1083 contains unaligned variable declarations.

Line 2347 looks as if it were assuming a tab width of 4, but the
immediately following line breaks this assumption.


Someone should clean up this mess.  I don't know how good the test
coverage for localtime(3) is, so I'm happy to leave this (and a few
possible refactorings to decrease the indentation) to people more
familiar with the history and origins of this file.

Roland

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

[Martin Husemann]

On Wed, Mar 23, 2022 at 02:00:29PM +0100, Tobias Nygren wrote:
> I think this commit broke something.
> date(1) no longer reports a time zone and is stuck at GMT time:
> 
> $ ls -l /etc/localtime
> lrwxr-xr-x  1 root  wheel  36 Mar 22 08:47 /etc/localtime -> 
> /usr/share/zoneinfo/Europe/Stockholm
> $ date
> Wed Mar 23 12:57:40  2022
> $ TZ=CET date
> Wed Mar 23 12:57:44  2022
> $ TZ=foo date
> Wed Mar 23 12:57:48 GMT 2022

The lib/libc/time tests are failing and e.g. this:

zdump -v /usr/share/zoneinfo/US/Eastern

gives a suprisingly short output.

Martin

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

[Tobias Nygren]

On Tue, 22 Mar 2022 13:48:39 -0400
Christos Zoulas  wrote:

> Modified Files:
>   src/lib/libc/time: CONTRIBUTING Makefile NEWS localtime.c private.h
>   theory.html tz-link.html tzselect.8 tzselect.ksh version zdump.c
>   zic.c
> 
> Log Message:
> welcome to tzcode-2022a

Hi,

I think this commit broke something.
date(1) no longer reports a time zone and is stuck at GMT time:

$ ls -l /etc/localtime
lrwxr-xr-x  1 root  wheel  36 Mar 22 08:47 /etc/localtime -> 
/usr/share/zoneinfo/Europe/Stockholm
$ date
Wed Mar 23 12:57:40  2022
$ TZ=CET date
Wed Mar 23 12:57:44  2022
$ TZ=foo date
Wed Mar 23 12:57:48 GMT 2022

Kind regards,
-Tobias

Re: CVS commit: src

[Roland Illig]

Am 19.03.2022 um 16:28 schrieb Paul Goyette:

Does this impact PR/51084 at all?


PR/51084 is about MAKEVERBOSE as well, but it's a different part of the
build infrastructure.  So no, that PR is not yet fixed.

Re: CVS commit: src

[Paul Goyette]

Does this impact PR/51084 at all?


On Sat, 19 Mar 2022, Roland Illig wrote:


Module Name:src
Committed By:   rillig
Date:   Sat Mar 19 14:35:13 UTC 2022

Modified Files:
src: Makefile

Log Message:
Makefile: fix location of postinstall program for MAKEVERBOSE > 2

If MAKEVERBOSE > 2, each shell command from a make target is echoed.
This resulted in two additional words ending up in the variable
_POSTINSTALL.  Noticed by Brad Harder.

Before:
$ make -v _POSTINSTALL MAKEVERBOSE=3
echo .../usr.sbin/postinstall .../usr.sbin/postinstall/postinstall ...

After:
$ make -v _POSTINSTALL MAKEVERBOSE=3
.../usr.sbin/postinstall/postinstall ...


To generate a diff of this commit:
cvs rdiff -u -r1.333 -r1.334 src/Makefile

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


!DSPAM:6235ea25249971057441505!




++--+--+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses:|
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org  |
| & Network Engineer |  | pgoyett...@gmail.com |
++--+--+

Re: CVS commit: src/sys/fs/udf

[Joerg Sonnenberger]

Am Fri, Mar 18, 2022 at 04:06:18PM + schrieb Reinoud Zandijk:
> Module Name:  src
> Committed By: reinoud
> Date: Fri Mar 18 16:06:18 UTC 2022
> 
> Modified Files:
>   src/sys/fs/udf: ecma167-udf.h
> 
> Log Message:
> Replace the variable field data[0] to data[1] to avoid undefined behaviour.

Just use a flexible array member, data[]. That gives essentially the
same behavior as the ancient GNU extension of [0] but sanitizers knows
what it means. That said, it is somewhat pointless in a packed data
structure...

Joerg

re: CVS commit: src/sys/external/bsd/drm/dist/bsd-core

[matthew green]

> Log Message:
> old drm: Use getticks(), not hardclock_ticks.
>
> Should delete this code, no idea if it even still compiles.

it did last i tried, and it still worked on the r100/r200 systems
that new drm is still problematic with.

not objecting...


.mrg.

Re: CVS commit: src/etc

[Simon Burge]

Hi Alex,

Alexander Nasonov wrote:

> Simon Burge wrote:
> > Why don't we just mount all the ZFS filesystems in mountcritlocal?
>
> Future versions may require loading of encryption keys over kerberos
> or a special pam module to decrypt /home/$USER.

How is this different to the existing "zfs mount -a" that
/etc/rc.d/mountall does?  Would there be new rc.d scripts between
mountcritlocal and mountall ?

Cheers,
Simon.

Re: CVS commit: src/etc

[Brad Spencer]

Greg Troxel  writes:

[snip]

>
>   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.

[snip]

Ya, I suspect that the notion of precedence needs to be developed
somehow and not abuse the notion of critical too much.  That is,
filesystem mounting by type needs to happen in a particular order.  The
default would have to choose something, either making not ZFS happen
first followed by normal and usual ZFS pools, or the other way around.
I suspect that someone loses out as no default can handle every way that
ZFS may be used when other filesystem types are present.  For example,
in the cases I have, a FFS is the root filesystem along with other FFS
file systems.  Under these are ZFS normal pools, so the order I would
prefer in this case is mount FFS first and then import the pools, as the
places that the pools would mount under would not exist the other way
around.  However, I very much understand that the other way around could
exist where ZFS normal pools are imported before anything else.  I
honestly don't remember what Solaris did, but I can't see any ordering
default with NetBSD handling every case in the correct manor.  Even if
it were possible to know the root filesystem type in a simple manor like
one can know the root filesystem device and partition, I don't think
that it would be possible to guess all of the cases correctly.


-- 
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

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

[Tobias Nygren]

On Sat, 12 Mar 2022 08:26:01 +
Nia Alarie  wrote:

> Module Name:  src
> Committed By: nia
> Date: Sat Mar 12 08:26:01 UTC 2022
> 
> Modified Files:
>   src/lib/libc/stdlib: hcreate.c
> 
> Log Message:
> hcreate(3): use reallocarr instead of malloc(x * y)

Caution: malloc(0) and reallocarr(, 0, s) have different semantics
for the returned pointer value.

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

[Brad Spencer]

Greg Troxel  writes:

[snip]

> [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).]

[snip]

I am only going to speak to the use of "legacy" in this conversation.

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
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.




-- 
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

Re: CVS commit: src/etc

[Alexander Nasonov]

Simon Burge wrote:
> Why don't we just mount all the ZFS filesystems in mountcritlocal?

Future versions may require loading of encryption keys over kerberos
or a special pam module to decrypt /home/$USER.

Alex

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 

Re: CVS commit: src/etc

[Simon Burge]

[ Oops, resending to include the source-changes-d list. ]
[ Sorry for the double-up for the original recipients.  ]

Hi Alexander, folks,

Sorry for chiming in a bit late on this.

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 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.

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).

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.

Cheers,
Simon.

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

[Roland Illig]

Am 10.03.2022 um 22:48 schrieb David H. Gutteridge:

Module Name:src
Committed By:   rillig
Date:   Tue Mar  8 23:13:05 UTC 2022

Modified Files:
 src/usr.bin/man: man.c

Log Message:
man: remove unused global variable 'instype' (since yesterday)

No functional change.


To generate a diff of this commit:
cvs rdiff -u -r1.71 -r1.72 src/usr.bin/man/man.c

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


Hi Roland,

Hardly the most pressing concern for us to discuss, but, the reason I'd
defined that global variable is because that's how NetBSD's "style"
document shows it's done in its enum example. I didn't think that was
necessary here, but took the "style" example literally.


Hi Dave,

I agree that taking the "style" example literally could lead to this
code, thank you for explaining how you arrived with this code.  In fact,
when I first saw your code I didn't realize that 'instype' was a
variable, I thought it would be a typedef name.  Only when I tried to
remove this unused name, the generated binary changed, which made me
cautious.

To avoid future misinterpretation, I fixed the enum example in
share/misc/style.


As for the other change you made (enum vs. int), I guess that's just bad
style on my part. I don't really work in C anymore, but when I did, in
my context, we treated enum and int as being interchangable. Good to
know.


I changed the parameter type from int to enum because this enables
stricter checks in the compilers and in lint.  They would report a
mismatch of enum types then.  The enum check in lint is not enabled by
default though, but still it is there (LINTFLAGS+= -e in the Makefile).

For usr.bin/man, there aren't many enum constants that could be
confused, but in other programs like usr.bin/make there are really many
of them, and 2 years ago there were even enum constants from different
types that used the same prefix "VAR_", which increased the confusion.
That's the reason that I prefer to be as specific with enum types as
possible.

Another benefit is that using 'enum' (or 'bool') instead of 'int'
communicates the purpose of the variable more precisely to human
readers, and I like this extra bit of precision.

Regards,
Roland

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

[David H. Gutteridge]

> Module Name:src
> Committed By:   rillig
> Date:   Tue Mar  8 23:13:05 UTC 2022
> 
> Modified Files:
> src/usr.bin/man: man.c
> 
> Log Message:
> man: remove unused global variable 'instype' (since yesterday)
> 
> No functional change.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.71 -r1.72 src/usr.bin/man/man.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.

Hi Roland,

Hardly the most pressing concern for us to discuss, but, the reason I'd
defined that global variable is because that's how NetBSD's "style"
document shows it's done in its enum example. I didn't think that was
necessary here, but took the "style" example literally.

As for the other change you made (enum vs. int), I guess that's just bad
style on my part. I don't really work in C anymore, but when I did, in
my context, we treated enum and int as being interchangable. Good to
know.

Regards,

Dave

Re: CVS commit: src/usr.sbin/makefs/ffs

[Izumi Tsutsui]

> Module Name:  src
> Committed By: hgutch
> Date: Sun Mar  6 08:31:54 UTC 2022
> 
> Modified Files:
>   src/usr.sbin/makefs/ffs: buf.h newfs_extern.h
> Added Files:
>   src/usr.sbin/makefs/ffs: namespace.h
> 
> Log Message:
> Make sure daddr_t is a 64 bit type when building tools.
> (see also PR sw-bug/56742 ).

I wonder this target type definition should rather be defined in
src/tools/compat/compat_defs.h (and src/tools/compat/configure.ac).

---
Izumi Tsutsui

Re: CVS commit: src/external/apache2/llvm

[Joerg Sonnenberger]

Am Tue, Mar 01, 2022 at 10:17:18AM +1100 schrieb matthew green:
> "Joerg Sonnenberger" writes:
> > Module Name:src
> > Committed By:   joerg
> > Date:   Mon Feb 28 16:30:10 UTC 2022
> >
> > Modified Files:
> > src/external/apache2/llvm: Makefile.inc
> >
> > Log Message:
> > When MKDEBUG is use, build LLVM with -g1 to significantly reduce debug
> > information. This still includes types and line tables, but skips e.g.
> > local variables and inline tracking.
> 
> tempted to do this for GCC as well.  i'll see what happens to the
> size of eg gallium.so.0.debug (currently larger than the full
> base install itself.)  it's kind of insane:
> 
> -r--r--r--  1 root  wheel  1828732744 Nov 14 00:15 
> /usr/libdata/debug/usr/X11R7/lib/modules/dri/gallium_dri.so.0.debug
> 
> yesterday-when-i-was-mad /usr/src> readelf --debug-dump 
> /usr/libdata/debug/usr/X11R7/lib/modules/dri/gallium_dri.so.0.debug >& 
> /dev/null
> 320.988u 1.149s 5:22.15 99.9%   0+0k 1+0io 0pf+0w
> 
> ... and that's a zen3 cpu.

This is applied to both GCC and Clang as base compiler.

Joerg

re: CVS commit: src/external/apache2/llvm

[matthew green]

"Joerg Sonnenberger" writes:
> Module Name:  src
> Committed By: joerg
> Date: Mon Feb 28 16:30:10 UTC 2022
>
> Modified Files:
>   src/external/apache2/llvm: Makefile.inc
>
> Log Message:
> When MKDEBUG is use, build LLVM with -g1 to significantly reduce debug
> information. This still includes types and line tables, but skips e.g.
> local variables and inline tracking.

tempted to do this for GCC as well.  i'll see what happens to the
size of eg gallium.so.0.debug (currently larger than the full
base install itself.)  it's kind of insane:

-r--r--r--  1 root  wheel  1828732744 Nov 14 00:15 
/usr/libdata/debug/usr/X11R7/lib/modules/dri/gallium_dri.so.0.debug

yesterday-when-i-was-mad /usr/src> readelf --debug-dump 
/usr/libdata/debug/usr/X11R7/lib/modules/dri/gallium_dri.so.0.debug >& /dev/null
320.988u 1.149s 5:22.15 99.9%   0+0k 1+0io 0pf+0w

... and that's a zen3 cpu.


.mrg.

re: CVS commit: src/usr.bin/vmstat

[matthew green]

"Roland Illig" writes:
> Module Name:  src
> Committed By: rillig
> Date: Sun Feb 27 19:00:46 UTC 2022
>
> Modified Files:
>   src/usr.bin/vmstat: vmstat.c
>
> Log Message:
> vmstat: unexport file-scope variable numdisks
>
> There is no need to make this variable externally visible.  There are
> several more variables in this file that could be unexported, leave
> these for someone who knows whether vmstat.c is used by other parts of
> the tree as well.
>
> No functional change, OK mrg.

thanks!

re: CVS commit: src/usr.bin/vmstat

[matthew green]

Roland Illig writes:
> Am 09.02.2022 um 08:34 schrieb matthew green:
> > Module Name:src
> > Committed By:   mrg
> > Date:   Wed Feb  9 07:34:18 UTC 2022
> >
> > Modified Files:
> > src/usr.bin/vmstat: vmstat.c
> >
> > Log Message:
> > allow the number of disks displayed in the default output
> > to be controlled.
> >
> >
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.249 -r1.250 src/usr.bin/vmstat/vmstat.c
>
> Did you omit the "static" from the variable definition on purpose?  As a
> general rule, I prefer to keep the scope of each variable as narrow as
> possible.

good idea.  feel free to fix, i usually do this :-)

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

[Martin Husemann]

On Sun, Feb 27, 2022 at 11:50:15AM +0100, Martin Husemann wrote:
> On Sun, Feb 27, 2022 at 12:04:58AM +0100, Joerg Sonnenberger wrote:
> > Personally, I prefer the use of the C extension in cases like this. The
> > "portable" version is less readable...
> 
> I would prefer the type correct C++ style variant (and making lint deal
> with it, if it doesn't yet). At least gcc is happy with it.

Ah, never mind - the inline function is void already - so effectively I
agree with Jörg.

Martin

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

[Martin Husemann]

On Sun, Feb 27, 2022 at 12:04:58AM +0100, Joerg Sonnenberger wrote:
> Personally, I prefer the use of the C extension in cases like this. The
> "portable" version is less readable...

I would prefer the type correct C++ style variant (and making lint deal
with it, if it doesn't yet). At least gcc is happy with it.

Index: if_wm.c
===
RCS file: /cvsroot/src/sys/dev/pci/if_wm.c,v
retrieving revision 1.728
diff -u -p -r1.728 if_wm.c
--- if_wm.c 26 Feb 2022 14:53:05 -  1.728
+++ if_wm.c 27 Feb 2022 10:48:11 -
@@ -10025,7 +10025,7 @@ wm_txrxintr_disable(struct wm_queue *wmq
struct wm_softc *sc = wmq->wmq_txq.txq_sc;
 
if (__predict_false(!wm_is_using_msix(sc))) {
-   return wm_legacy_intr_disable(sc);
+   return (void)wm_legacy_intr_disable(sc);
}
 
if (sc->sc_type == WM_T_82574)
@@ -10046,7 +10046,7 @@ wm_txrxintr_enable(struct wm_queue *wmq)
wm_itrs_calculate(sc, wmq);
 
if (__predict_false(!wm_is_using_msix(sc))) {
-   return wm_legacy_intr_enable(sc);
+   return (void)wm_legacy_intr_enable(sc);
}
 
/*

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

[Joerg Sonnenberger]

Am Sat, Feb 26, 2022 at 03:04:40PM + schrieb Roland Illig:
> Module Name:  src
> Committed By: rillig
> Date: Sat Feb 26 15:04:40 UTC 2022
> 
> Modified Files:
>   src/sys/dev/pci: if_wm.c
> 
> Log Message:
> if_wm.c: fix value return from void function
> 
> lint complained:
> if_wm.c(10028): error:
> void function wm_txrxintr_disable cannot return value [213]
> if_wm.c(10049): error:
> void function wm_txrxintr_enable cannot return value [213]
> 
> No functional change.

Personally, I prefer the use of the C extension in cases like this. The
"portable" version is less readable...

Joerg

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

[Roland Illig]

Am 09.02.2022 um 08:34 schrieb matthew green:

Module Name:src
Committed By:   mrg
Date:   Wed Feb  9 07:34:18 UTC 2022

Modified Files:
src/usr.bin/vmstat: vmstat.c

Log Message:
allow the number of disks displayed in the default output
to be controlled.


To generate a diff of this commit:
cvs rdiff -u -r1.249 -r1.250 src/usr.bin/vmstat/vmstat.c


Did you omit the "static" from the variable definition on purpose?  As a
general rule, I prefer to keep the scope of each variable as narrow as
possible.

Roland

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

[Warner Losh]

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

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

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

Warner

>

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

[Roland Illig]

Am 12.02.2022 um 20:10 schrieb Warner Losh:

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


That sounds like a useful rule, I'll stick to it.

Roland

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

[Taylor R Campbell]

> Date: Sun, 13 Feb 2022 05:44:38 +1100
> from: matthew green 
> 
> "Roland Illig" writes:
> > Module Name:src
> > Committed By:   rillig
> > Date:   Fri Feb 11 21:36:46 UTC 2022
> >
> > Modified Files:
> > src/lib/libc/stdlib: getenv.c
> >
> > Log Message:
> > libc/getenv: remove trailing whitespace
> >
> > No binary change.
> 
> please avoid purely whitespace changes unless you're
> also going to be modifying the code itself.
> 
> (don't back out now.)

I thought we were supposed to _avoid_ mixing whitespace changes and
functional changes?

(Obviously the solution is to just only ever commit code with perfect
style to begin with so this is never an issue!  Speaking of which,
(setq show-trailing-whitespace t) is helpful to avoid this kind of
mistake up front.  git diff or git add -p will also flag this kind of
mistake, if you're working in git.  /usr/share/misc/NetBSD.el is also
helpful for other KNF style.)

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

[matthew green]

"Roland Illig" writes:
> Module Name:  src
> Committed By: rillig
> Date: Fri Feb 11 21:36:46 UTC 2022
>
> Modified Files:
>   src/lib/libc/stdlib: getenv.c
>
> Log Message:
> libc/getenv: remove trailing whitespace
>
> No binary change.

please avoid purely whitespace changes unless you're
also going to be modifying the code itself.

(don't back out now.)

thanks.


.mrg.

Re: CVS commit: src/sys/kern

[Taylor R Campbell]

> Date: Fri, 11 Feb 2022 16:50:16 -0800
> From: Jason Thorpe 
> 
> > On Feb 11, 2022, at 9:53 AM, Taylor R Campbell  wrote:
> > 
> >  That is, this was presumably meant to ensure (A) happens-before (B).
> >  This relation is already guaranteed by ipi(9), so there is no need
> >  for any explicit memory barrier.
> 
> Is this documented in ipi(9)?

Is now!

Re: CVS commit: src/sys/kern

[Jason Thorpe]

> On Feb 11, 2022, at 9:53 AM, Taylor R Campbell  wrote:
> 
>  That is, this was presumably meant to ensure (A) happens-before (B).
>  This relation is already guaranteed by ipi(9), so there is no need
>  for any explicit memory barrier.

Is this documented in ipi(9)?

-- thorpej

Re: CVS commit: src/etc

[Alexander Nasonov]

Taylor R Campbell wrote:
> > Date: Sat, 5 Feb 2022 21:21:53 +
> > From: Alexander Nasonov 
> > 
> > Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
> > legacy mountpoints a try to see how much complexity they add.
> 
> I use legacy mountpoints for / and /var, but it's a little kludgey,
> and from what I recall a legacy mountpoint requires setting the
> mountpoint property explicitly on anything mounted under it.
> 
> I assumed you had made the change to obviate the need for most of this
> extra bookkeeping with fstab and explicit mountpoint properties that
> don't match the zpool dataset path.

That's right.

> So I'm guessing with your change and critical_filesystems_zfs=/var, I
> could:
> 
> - skip the fstab entry for /var,
> - have only rpool/ROOT with mountpoint=legacy, and
> - have /var and all the file systems under /var use default
>   mountpoints.

yes yes yes :)

It even supports OPTIONAL:

critical_filesystems_zfs=OPTIONAL:/var

and it's clever enough to skip "fake" mountpoints (datasets
with canmount=off).

Alex

Re: CVS commit: src/etc

[Taylor R Campbell]

> Date: Sat, 5 Feb 2022 21:21:53 +
> From: Alexander Nasonov 
> 
> Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
> legacy mountpoints a try to see how much complexity they add.

I use legacy mountpoints for / and /var, but it's a little kludgey,
and from what I recall a legacy mountpoint requires setting the
mountpoint property explicitly on anything mounted under it.

I assumed you had made the change to obviate the need for most of this
extra bookkeeping with fstab and explicit mountpoint properties that
don't match the zpool dataset path.

E.g., right now I have:

rpool/ROOT mountpoint=legacy mounted at /
rpool/ROOT/var mountpoint=legacy mounted at /var
rpool/chroot mountpoint=/var/chroot
rpool/crash mountpoint=/var/crash
rpool/home mountpoint=/home (default)
rpool/export mountpoint=/export (default)
...

and critical_filesystems_local=/var in rc.conf entries in /etc/fstab
for / and /var.  (This is all inside a chroot with the `real' /
mounted from a ramdisk, of course.)

So I'm guessing with your change and critical_filesystems_zfs=/var, I
could:

- skip the fstab entry for /var,
- have only rpool/ROOT with mountpoint=legacy, and
- have /var and all the file systems under /var use default
  mountpoints.

(I haven't looked at or tried the changes yet!)

Re: CVS commit: src/etc

[Brad Spencer]

Alexander Nasonov  writes:

> Brad Spencer wrote:
>> Alexander Nasonov  writes:
>> > Are there any downside of mixing legacy and non-legacy mountpoints?
>> > E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?
>> 
>> That should work fine as long as /var was arranged to be mounted first.
>> The other way around may and probably is trouble right now, where a
>> zpool Not-legacy needs to be mounted so that a ZFS legacy filesystem or,
>> in fact, any other filesystem type gets mounted under it.  I believe
>> that Solaris did and probably still does have this problem too.  Legacy
>> ZFS mounts should be perfectly workable even from single user when /usr
>> isn't available yet for most simple use cases.
>
> Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
> legacy mountpoints a try to see how much complexity they add.
>
> I have the following ZFS mountpoints in my setup
>
> /usr  - legacy
> /var  - legacy
> /var/log  - legacy
> /var/tmp  - normal
> /var/mail - normal
> ...
>
> Ideally, I'd like to keep all datasets under one root:
>
> tank/base/usr  - legacy
> tank/base/var  - legacy
> tank/base/var/log  - legacy
> tank/base/var/mail - normal
>
> but it has a small inconvenience: every time I add a new dataset under
> a legacy mountpoint (e.g. create a dataset for /var/spool), it can't
> inherit a mountpoint from a legacy mountpoint and I have to set it
> manually (zfs set mountpoint=/var/spool tank/base/var/spool).

Yes, that would very much be the case.  Legacy mounts in ZFS are mostly
there to make /etc/fstab (and simular ilk) work the same as one may be
used to doing, so no inheritance.  You do not have to use most of the
zpool / zfs commands to get them mounted, but at the same time you can
set their sizes and such.  Getting too complicated with them, however,
may introduce unexpected adventure.

> One way to avoid this issue is to have separate hierarchies:
>
> tank/legacy
> tank/legacy/usr
> tank/legacy/var
> tank/legacy/var/log
> tank/base
> tank/base/var
> tank/base/var/mail
>
> but I'm pretty sure it has some downsides too.
>
> Alex


-- 
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

Re: CVS commit: src/sys/kern

[Taylor R Campbell]

> Date: Sat, 5 Feb 2022 22:47:30 +0100
> From: Tobias Nygren 
> 
> On Sat, 5 Feb 2022 15:17:40 +
> Martin Husemann  wrote:
> 
> > Modified Files:
> > src/sys/kern: subr_autoconf.c
> > 
> > Log Message:
> > cfdriver_iattr_count() is only used in a KASSERT, so #ifdef DIAGNOSTIC it.
> 
> This doesn't seem to work as intended.
> In a kernel with "no options DIAGNOSTIC" I now get:
> 
> /work/src/sys/kern/subr_autoconf.c: In function 'config_search_internal':
> /work/src/sys/kern/subr_autoconf.c:1149:3: error: implicit declaration of 
> function 'cfdriver_iattr_count' [-Werror=implicit-function-declaration]

I guess we need to decorate cfdriver_iattr_count with __diagused.

(Point of the KASSERT change the other month was to eliminate most of
these `oops I forgot to try a DIAGNOSTIC / !DIAGNOSTIC build' problems
and reduce #ifdefs; thanks, clang...)

Re: CVS commit: src/tests/fs/vfs

[Robert Elz]

Date:Sat, 5 Feb 2022 22:20:16 +
From:David Brownlee 
Message-ID:  


  | Oops, my earliest unix experience was on a BSD4.3 variant, so I was
  | spoiled by ffs and didn't realise the (in this context) helpful v7fs
  | behaviour with overlong filename components.

To clarify ... I meant7th edition (and earlier) filesystems, not
necessarily the thing we have called v7fs about which I know
nothing ... thiugh I wondered when I saw your PR whether a name
length problem might be what caused that.

kre

Re: CVS commit: src/tests/fs/vfs

[David Brownlee]

On Wed, 2 Feb 2022 at 17:24, Robert Elz  wrote:
>
> Date:Wed, 2 Feb 2022 15:26:21 +
> From:David Brownlee 
> Message-ID:  
> 
>
>   | So, we just need an optional flag when mounting v7fs to truncate any
>   | looked up filename component to 14 characters
>
> That's not, or shouldn't be, necessary - that always happened, the limit was
> what was stored in the directory, not on the length of the pathname components
> passed to namei.
>
> Further, v7fs (systems of that vintage) had no concept at all of a maximum
> pathname length (provided there was available ram to store the string).
>

(Apologies for continuing further down this rabbit hole :)

Oops, my earliest unix experience was on a BSD4.3 variant, so I was
spoiled by ffs and didn't realise the (in this context) helpful v7fs
behaviour with overlong filename components.

As a quick test extracting rescue.tar.xz into a v7fs and chrooting
into rescue/sh works, and rsyncing enough to get /bin/sh chrooting
also works (extracting base.tar.xz runs into issues - PR bin/56690)

Actually, there were enough other issues found in PR bin/56690 that I
would have to regretfully recommend against v7fs for production NetBSD
systems (ahem :)

David

Re: CVS commit: src/sys/kern

[Tobias Nygren]

On Sat, 5 Feb 2022 15:17:40 +
Martin Husemann  wrote:

> Modified Files:
>   src/sys/kern: subr_autoconf.c
> 
> Log Message:
> cfdriver_iattr_count() is only used in a KASSERT, so #ifdef DIAGNOSTIC it.

This doesn't seem to work as intended.
In a kernel with "no options DIAGNOSTIC" I now get:

/work/src/sys/kern/subr_autoconf.c: In function 'config_search_internal':
/work/src/sys/kern/subr_autoconf.c:1149:3: error: implicit declaration of 
function 'cfdriver_iattr_count' [-Werror=implicit-function-declaration]
 1149 |   cfdriver_iattr_count(parent->dv_cfdriver) < 2);
  |   ^~~~
/work/src/sys/lib/libkern/libkern.h:279:42: note: in definition of macro 
'KASSERT'
  279 | #define KASSERT(e)  ((void)sizeof((long)(e)))

Re: CVS commit: src/etc

[Alexander Nasonov]

Brad Spencer wrote:
> Alexander Nasonov  writes:
> > Are there any downside of mixing legacy and non-legacy mountpoints?
> > E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?
> 
> That should work fine as long as /var was arranged to be mounted first.
> The other way around may and probably is trouble right now, where a
> zpool Not-legacy needs to be mounted so that a ZFS legacy filesystem or,
> in fact, any other filesystem type gets mounted under it.  I believe
> that Solaris did and probably still does have this problem too.  Legacy
> ZFS mounts should be perfectly workable even from single user when /usr
> isn't available yet for most simple use cases.

Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
legacy mountpoints a try to see how much complexity they add.

I have the following ZFS mountpoints in my setup

/usr  - legacy
/var  - legacy
/var/log  - legacy
/var/tmp  - normal
/var/mail - normal
...

Ideally, I'd like to keep all datasets under one root:

tank/base/usr  - legacy
tank/base/var  - legacy
tank/base/var/log  - legacy
tank/base/var/mail - normal

but it has a small inconvenience: every time I add a new dataset under
a legacy mountpoint (e.g. create a dataset for /var/spool), it can't
inherit a mountpoint from a legacy mountpoint and I have to set it
manually (zfs set mountpoint=/var/spool tank/base/var/spool).

One way to avoid this issue is to have separate hierarchies:

tank/legacy
tank/legacy/usr
tank/legacy/var
tank/legacy/var/log
tank/base
tank/base/var
tank/base/var/mail

but I'm pretty sure it has some downsides too.

Alex

Re: CVS commit: src/etc

[Brad Spencer]

Alexander Nasonov  writes:

> J. Hannken-Illjes wrote:
>> What is wrong with ZFS legacy mounts?
>> 
>> $ zpool create -m legacy tank 
>> $ zfs create tank/a
>> $ mount -t zfs tank/a /mnt
>
> Hmm, I heard about ZFS legacy (quite a while ago!) but I didn't
> look into it because, well, "legacy"...
>
> Are there any downside of mixing legacy and non-legacy mountpoints?
> E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?
>
> Alex


That should work fine as long as /var was arranged to be mounted first.
The other way around may and probably is trouble right now, where a
zpool Not-legacy needs to be mounted so that a ZFS legacy filesystem or,
in fact, any other filesystem type gets mounted under it.  I believe
that Solaris did and probably still does have this problem too.  Legacy
ZFS mounts should be perfectly workable even from single user when /usr
isn't available yet for most simple use cases.



-- 
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

Re: CVS commit: src/etc

[Alexander Nasonov]

J. Hannken-Illjes wrote:
> What is wrong with ZFS legacy mounts?
> 
> $ zpool create -m legacy tank 
> $ zfs create tank/a
> $ mount -t zfs tank/a /mnt

Hmm, I heard about ZFS legacy (quite a while ago!) but I didn't
look into it because, well, "legacy"...

Are there any downside of mixing legacy and non-legacy mountpoints?
E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?

Alex

Re: CVS commit: src/etc

[Martin Husemann]

On Fri, Feb 04, 2022 at 10:19:03PM +, Alexander Nasonov wrote:
> These two "styles of mounting" are
> 
> /sbin/mount /filesystem - looks up fs parameters in /etc/fstab
> /sbin/zfs mount dataset - looks up fs parameters in zpools

There are several things that could be done here. I would guess some
of these also need a "special string" solution (see below) for booting
from ZFS.

I was (maybe eroneously) assuming common usage would be to mount all 
filesystems from a zpool, so expecting something like a
critical_zpools_local variable for a list of zpools that need mounting
early.

Then for special cases I would expect mount_zfs to understand some special
string (and the same type of string being passed in from the bootloader
for root on ZFS), so I could do:

mount zfs:${guid-or-name-of-zpool}:${fs-identifier} /home

and have the equivalent of that in /etc/fstab. And then of course the
legacy mounts, as Jürgen pointed out.

But I am no ZFS expert, and just wanted to note that there is some
"design not yet fully complete" feeling with the current state of
integration of ZFS into NetBSD - which also might just mean it is not
yet properly documented. I really appreciate all the work going into this,
and would like to see sysinst support and boot with root on ZFS, and good
docs for all of it, for netbsd-10 (on amd64 at least).

Martin

Re: CVS commit: src/etc

[J. Hannken-Illjes]

> On 4. Feb 2022, at 23:19, Alexander Nasonov  wrote:
> 
> Martin Husemann wrote:
>> On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
>>> variable, it will mix two very different styles of mounting and
>>> compilate the code.
> 
> s/compilate/complicate/
> 
>> "different styles of mounting" sounds like a non-starter to me, maybe
>> that should be fixed first?
> 
> These two "styles of mounting" are
> 
> /sbin/mount /filesystem - looks up fs parameters in /etc/fstab
> /sbin/zfs mount dataset - looks up fs parameters in zpools
> 
> I don't think these two approaches can be unified.

What is wrong with ZFS legacy mounts?

$ zpool create -m legacy tank 
$ zfs create tank/a
$ mount -t zfs tank/a /mnt

> We surely
> can modify mount_critical_systems to try entries from /etc/fstab
> first, and if /sbin/mount fails, then try to find a zfs dataset
> for the failed entry and /sbin/zfs mount it. But if things go
> wrong, a complicated mounting process will make troubleshooting
> harder. For that reason, I'd like to keep mountcrit_zfs separate
> from mountcrit_local.

--
J. Hannken-Illjes - hann...@mailbox.org


signature.asc
Description: Message signed with OpenPGP

Re: CVS commit: src/etc

[Alexander Nasonov]

Martin Husemann wrote:
> On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
> > variable, it will mix two very different styles of mounting and
> > compilate the code.

s/compilate/complicate/

> "different styles of mounting" sounds like a non-starter to me, maybe
> that should be fixed first?

These two "styles of mounting" are

/sbin/mount /filesystem - looks up fs parameters in /etc/fstab
/sbin/zfs mount dataset - looks up fs parameters in zpools

I don't think these two approaches can be unified. We surely
can modify mount_critical_systems to try entries from /etc/fstab
first, and if /sbin/mount fails, then try to find a zfs dataset
for the failed entry and /sbin/zfs mount it. But if things go
wrong, a complicated mounting process will make troubleshooting
harder. For that reason, I'd like to keep mountcrit_zfs separate
from mountcrit_local.

Alex

Re: CVS commit: src/etc

[Martin Husemann]

On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
> variable, it will mix two very different styles of mounting and
> compilate the code.

"different styles of mounting" sounds like a non-starter to me, maybe
that should be fixed first?

Martin

Re: CVS commit: src/etc

[Alexander Nasonov]

Hi Robert,

Robert Elz wrote:
> A couple of comments about your mount_critical_filesystems_zfs()
> function in rc.subr

Thank you for reviewing my code!

> It starts:
> 
>   eval _fslist=\$critical_filesystems_zfs
> 
> I'm not sure what you're attempting to accomplish there.

I copied this line from mount_critical_filesystems:

eval _fslist=\$critical_filesystems_${1}

and changed ${1} to zfs without realising that I don't need eval
anymore.

>...
>_dataset=`
> 
> (followed by a lengthy command substitution).   Please don't use ``
> command substitutions, they are fragile, and essentially obsolete.

Noted.

I don't like the approach I took but I'm not very comfortable in
a bare shell when tools in /usr aren't (yet) available and this
giant $() was all I could think of.

> The only excuse for ever using them in anything modern is if the
> script might need to be run by a truly ancient shell.   Just use $( )
> instead, the semantics are much cleaner.
> 
> And perhaps more important, near the bottom of the big loop:
> 
>   if [ "$_mount_es" != 0 ]; then
>   _mountcrit_es="$_mount_es"
>   fi
> 
> which causes the exit status of the function (_mountcrit_es) to be the
> status of the last mount that failed for some reason, rather than the
> first (which tends to be more common).

These lines is a copy/paste from mount_critical_filesystems and
your comment apply to that function too.

>...
> One additional minor point, it might be better to use -ne there instead
> of != since the values are intended to be integers, rather than strings.
> But that doesn't really matter (unless $_mount_es might be "" in which
> case using != is better - that would be 0 for -ne, but not 0 for !=).

Yes, it's intended to be integers.

--
Alex

Re: CVS commit: src/etc

[Alexander Nasonov]

Alexander Nasonov wrote:
> Module Name:  src
> Committed By: alnsn
> Date: Thu Feb  3 20:52:44 UTC 2022
> 
> Modified Files:
>   src/etc: rc.subr
> 
> Log Message:
> Add mount_critical_filesystems_zfs
> 
> The new function is similar to mount_critical_filesystems
> but it walks through ZFS datasets and mounts matching entries.

I plan to intoduce a new rc.conf variable critical_filesystems_zfs
which is essentially the same as critical_filesystems_local but
for ZFS.

Although the new variable can be avoided if my code is merged into
existing mount_critical_filesystems(), and all critical filesystems
(ZFS or not) are mounted in one pass through critical_filesystems_local
variable, it will mix two very different styles of mounting and
compilate the code. One extra variable shouldn't be a problem for
most users but it will help to keep rc.subr neater.

--
Alex

Re: CVS commit: src/etc

[Robert Elz]

A couple of comments about your mount_critical_filesystems_zfs()
function in rc.subr

It starts:

eval _fslist=\$critical_filesystems_zfs

I'm not sure what you're attempting to accomplish there.  The eval
command sees
fslist=$critical_filesystems_zfs
(the \ having quoted the '$' preventing variable expansion, and
was then removed).

eval uses that as input, and runs it.   But if that was what you
wanted, why bother with eval at all, just write it as eval sees it.

eval is most useful when some of the arg string is to come from a
variable that is expanded before eval sees it, which isn't the case here.

Later:

 _dataset=`

(followed by a lengthy command substitution).   Please don't use ``
command substitutions, they are fragile, and essentially obsolete.
The only excuse for ever using them in anything modern is if the
script might need to be run by a truly ancient shell.   Just use $( )
instead, the semantics are much cleaner.

And perhaps more important, near the bottom of the big loop:

if [ "$_mount_es" != 0 ]; then
_mountcrit_es="$_mount_es"
fi

which causes the exit status of the function (_mountcrit_es) to be the
status of the last mount that failed for some reason, rather than the
first (which tends to be more common).   Perhaps "zfs mount" only ever
does exit(1) for any error, in which case it doesn't matter (1 from any
execution is the same thing) but if it returns different exit codes
depending upon the error, you usually want the first one, rather than
the last - particularly with filesystem mounting, it isn't unusual for
later mounts to fail if an earlier one did, if the earlier one was
intended to provide the mount points, for example - knowing that the
later mounts failed because the directory they intended to mount onto
wasn't present is fairly useless, what you want to know is why the
earlier one failed.

One additional minor point, it might be better to use -ne there instead
of != since the values are intended to be integers, rather than strings.
But that doesn't really matter (unless $_mount_es might be "" in which
case using != is better - that would be 0 for -ne, but not 0 for !=).

kre

Re: CVS commit: src/tests/fs/vfs

[Robert Elz]

Date:Wed, 2 Feb 2022 15:26:21 +
From:David Brownlee 
Message-ID:  


  | So, we just need an optional flag when mounting v7fs to truncate any
  | looked up filename component to 14 characters

That's not, or shouldn't be, necessary - that always happened, the limit was
what was stored in the directory, not on the length of the pathname components
passed to namei.

Further, v7fs (systems of that vintage) had no concept at all of a maximum
pathname length (provided there was available ram to store the string).

kre

Re: CVS commit: src/tests/fs/vfs

[Jason Thorpe]

> On Feb 2, 2022, at 6:47 AM, Robert Elz  wrote:
> 
>Date:Wed, 2 Feb 2022 07:11:45 +
>From:David Holland 
>Message-ID:  
> 
>  | v7fs isn't a compat interface for old users,
> 
> That's sad, I could do with something just for me!
> 
>  | it's a compat interface for old disk images :-)
> 
> And makefs -t v7fs fits into that purpose how?
> 
> So maybe it is for us truly old fogies (can we have v6fs as well?
> Then I'd really feel at home.)   Can I have a v7fs as root, and
> boot from it?   Does sysinst support it?

I thought we maybe supported a system whose ROM boots from it?

-- thorpej

Re: CVS commit: src/tests/fs/vfs

[Michael]

Hello,

On Wed, 02 Feb 2022 21:47:25 +0700
Robert Elz  wrote:

> So maybe it is for us truly old fogies (can we have v6fs as well?

Well, there is this thing...
https://github.com/jaylogue/retro-fuse

A user-space filesystem (FUSE) for accessing ancient Unix filesystems.

retro-fuse provides a way to mount filesystems created by ancient Unix
systems on modern OSes. The current version of retro-fuse supports
mounting filesystems created by fifth, sixth and seventh-edition
research Unix, as well as 2.9BSD and 2.11BSD. It can also initialize
such filesystems.

have fun
Michael

Re: CVS commit: src/tests/fs/vfs

[David Brownlee]

On Wed, 2 Feb 2022 at 14:47, Robert Elz  wrote:
>
> Date:Wed, 2 Feb 2022 07:11:45 +
> From:David Holland 
> Message-ID:  
>
>   | v7fs isn't a compat interface for old users,
>
> That's sad, I could do with something just for me!

Sounds like we need a compat_kre(8) - assuming it would be more
correct to provide the appropriate trailing slash behaviour for all
filesystems in that mode? :-p

>   | it's a compat interface for old disk images :-)
>
> And makefs -t v7fs fits into that purpose how?
>
> So maybe it is for us truly old fogies (can we have v6fs as well?
> Then I'd really feel at home.)   Can I have a v7fs as root, and
> boot from it?

Maybe?
- Throw together a bootxx_v7fs
- Leave /dev with just MAKEDEV so the system will mount a mfs /dev
- Convert symlinks to hard links or file copies when setting up
- Then it's just the 14 character filename component limit: excluding
drm firmware, kernel modules and X config most filename components are
14 characters or less - but there are a few libraries in /lib with
longer filenames - lib/libcrypto.so.14 lib/libtermcap.so.0
lib/libterminfo.so.1 and lib/libpthread.so.1 are likely to be
problematic

So, we just need an optional flag when mounting v7fs to truncate any
looked up filename component to 14 characters, then we're good to go.
Actually, I'm a little concerned about how close it could be to being
possible! :)

>   Does sysinst support it?

It would be under the --spinal-tap option

David

Re: CVS commit: src/tests/fs/vfs

[Robert Elz]

Date:Wed, 2 Feb 2022 07:11:45 +
From:David Holland 
Message-ID:  

  | v7fs isn't a compat interface for old users,

That's sad, I could do with something just for me!

  | it's a compat interface for old disk images :-)

And makefs -t v7fs fits into that purpose how?

So maybe it is for us truly old fogies (can we have v6fs as well?
Then I'd really feel at home.)   Can I have a v7fs as root, and
boot from it?   Does sysinst support it?

kre

Re: CVS commit: src/tests/fs/vfs

[David Holland]

On Wed, Feb 02, 2022 at 05:43:45AM +0700, Robert Elz wrote:
 >   | Test mkdir(2) with one or more trailing slashes - this currently fails
 >   | for v7fs.
 > 
 > As it should I think, trailing slashes are not simply deleted in v7fs.
 >
 > [...]
 > 
 > If this was ever changed, it would not truly be a v7fs any more.

v7fs isn't a compat interface for old users, it's a compat interface
for old disk images :-)

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/tests/fs/vfs

[Robert Elz]

Date:Tue, 1 Feb 2022 18:27:24 +
From:"Martin Husemann" 
Message-ID:  <20220201182724.90f82f...@cvs.netbsd.org>

  | Test mkdir(2) with one or more trailing slashes - this currently fails
  | for v7fs.

As it should I think, trailing slashes are not simply deleted in v7fs.

If you do

mkdir /path/to/dir/

in a v7 fs, then you're guaranteed (unless some other error happens earlier)
either ENOENT if /path/to/dir doesn't already exist, ENOTDIR if it it does
but isn't a directory, or EEXIST if it exists and is a directory.   The thing
to be created always follows the final slash, everything prior to that is
path to look up, and must all exist and be directories (with appropriate
permissions, etc).In this case the "thing" is "" which is (kind of) an
alias for "." (without ever actually looking up ".").   It can never not
exist if the preceding path all exists.

If this was ever changed, it would not truly be a v7fs any more.

kre

ps: I never understood the fascination with always writing directory names
with a trailing / - it seems to come largely from filename completion
where the '/' is added if the name found is a directory, so you can just
go on typing anything that is to follow in the path (but could easily be
removed again if no more components are added - just isn't) but it makes
no sense for this to have happened with mkdir, filename completion can
only find files that exist, not ones to be created, so it couldn't be that
which adds the '/' after the directory name - some human must be doing
that, but why?  It seems to be to be just meaningless extra unneeded typing.

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

[Christos Zoulas]

> On Jan 30, 2022, at 2:41 PM, Roland Illig  wrote:
> 
> Am 30.01.2022 um 14:21 schrieb Christos Zoulas:
>> Module Name: src
>> Committed By:christos
>> Date:Sun Jan 30 13:21:09 UTC 2022
>> 
>> Modified Files:
>>  src/usr.bin/make: dir.c job.c make.h
>> 
>> Log Message:
>> Make the GNode lineno unsigned to fix lint warning in var.c calling
>> PrintLocation()
> 
> Hi Christos,
> 
> Did you get that warning on i386?  On x86_64 I didn't get any lint
> warnings, as these would have made my pre-commit hook fail.

Yes: https://releng.netbsd.org/builds/HEAD-lint/202201300710Z/i386.build.failed 

Do you know it would only fail on i386?

> Since usr.bin/make is also used in tools/make, it needs to follow the
> rules in tools/README, which say that all tools should stick to C89.
> The format specifier %zu comes from C99 though.

Yes, %zu is annoying because windows does not have it either (until very
recently I think). But cygwin does have it(?) so there is no issue?

> Or can we drop the C89 rule from tools/README?  In the past few years,
> usr.bin/make used several features from C99 (end-of-line comments, long
> long, %zu, snprintf), and nobody cared to fix the C99-isms, so either
> nobody needed the C89 restriction or we simply ignored the complaints.

I think that we should ask in tech-toolchain. Yes, I prefer to require c99
at this point.

Best,

christos


signature.asc
Description: Message signed with OpenPGP

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

[Roland Illig]

Am 30.01.2022 um 20:54 schrieb Christos Zoulas:



On Jan 30, 2022, at 2:41 PM, Roland Illig mailto:roland.il...@gmx.de>> wrote:

Am 30.01.2022 um 14:21 schrieb Christos Zoulas:

Module Name:src
Committed By:christos
Date:Sun Jan 30 13:21:09 UTC 2022

Modified Files:
src/usr.bin/make: dir.c job.c make.h

Log Message:
Make the GNode lineno unsigned to fix lint warning in var.c calling
PrintLocation()


Hi Christos,

Did you get that warning on i386?  On x86_64 I didn't get any lint
warnings, as these would have made my pre-commit hook fail.


Yes:
https://releng.netbsd.org/builds/HEAD-lint/202201300710Z/i386.build.failed
Do you know it would only fail on i386?


No, I didn't know, and I also couldn't guess the lint warning, that's
why I asked.  The lint warning from the log is:

var.c(4527): warning: argument #4 is converted from 'int' to 'unsigned
int' due to prototype [259]

The warning makes sense, and it doesn't occur on x86_64 because size_t
is a 64-bit integer type there, which can hold any value of int.  But
still, the representation might change, so lint should warn.  Not about
potential value truncation, but about prototype compatibility.  In
lint's should_warn_about_prototype_conversion, I already wrote a comment
saying 'XXX: Investigate whether this rule makes sense', so it's
probably a conceptual bug in lint that this warning didn't occur on x86_64.

Roland

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

[Simon Gerraty]

On Sun, 30 Jan 2022 14:54:25 -0500, Christos Zoulas writes:
>> Since usr.bin/make is also used in tools/make, it needs to follow the
>> rules in tools/README, which say that all tools should stick to C89.
>> The format specifier %zu comes from C99 though.
>
>Yes, %zu is annoying because windows does not have it either (until very
>recently I think). But cygwin does have it(?) so there is no issue?

size_t is annoying ;-)

>> Or can we drop the C89 rule from tools/README?  In the past few years,
>> usr.bin/make used several features from C99 (end-of-line comments, =
>long
>> long, %zu, snprintf), and nobody cared to fix the C99-isms, so either
>> nobody needed the C89 restriction or we simply ignored the complaints.
>
>I think that we should ask in tech-toolchain. Yes, I prefer to require =
>c99
>at this point.

For bmake I have converted the %zu to %u.
I no longer have access to even a tiny fraction of the systems bmake is
used on, but I recall %z being an issue in the past.

I cannot find docs on gcc-2.95 (which is the oldest compiler I've
recently had to use to port bmake), and the license for that VM has
expired, it probably should support c99 but I cannot confirm.

--sjg