Re: svn commit: r368820 - head

[Rodney W. Grimes]

> On Sun, 20 Dec 2020 15:46:12 +0100
> "Hartmann, O."  wrote:
> 
> > On Sun, 20 Dec 2020 02:59:44 + (UTC)
> > Li-Wen Hsu  wrote:
> > 
> > > Author: lwhsu
> > > Date: Sun Dec 20 02:59:44 2020
> > > New Revision: 368820
> > > URL: https://svnweb.freebsd.org/changeset/base/368820
> > > 
> > > Log:
> > >   Mark the repository as being converted to Git.
> > >   
> > >   This is the last Subversion commit to src.
> > >   
> > >   Sponsored by:   The FreeBSD Foundation
> > > 
> > > Modified:
> > >   head/README
> > >   head/README.md
> > > 
> > > Modified: head/README
> > > ==
> > > --- head/README   Sat Dec 19 22:04:46 2020(r368819)
> > > +++ head/README   Sun Dec 20 02:59:44 2020(r368820)
> > > @@ -1,3 +1,5 @@
> > > +This repository is being converted from Subversion to Git.
> > > +
> > >  This is the top level of the FreeBSD source directory.  This file
> > >  was last revised on:
> > >  $FreeBSD$
> > > 
> > > Modified: head/README.md
> > > ==
> > > --- head/README.mdSat Dec 19 22:04:46 2020(r368819)
> > > +++ head/README.mdSun Dec 20 02:59:44 2020(r368820)
> > > @@ -1,3 +1,5 @@
> > > +This repository is being converted from Subversion to Git.
> > > +
> > >  FreeBSD Source:
> > >  ---
> > >  This is the top level of the FreeBSD source directory.  This file
> > > ___
> > > svn-src-h...@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/svn-src-head
> > > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"  
> > 
> > Is this message of yours also the last message concerning the source 
> > changes? Since then
> > you published this message, no further logs ran into list 
> > svn-src-h...@freebsd.org.
> > 
> 
> Take a look at this https://wiki.freebsd.org/git.  Write access to
> Subversion has been disabled.

I think the bigger question is why as a committer have I not seen ANY
commits to git since this cut over?  Is it a) none have happened in 24 hours,
or b) commit mail is no longer going to developers as it use to?

> -- 
> Gary Jennejohn
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r368130 - in head: share/man/man4 sys/dev/ftwd sys/modules sys/modules/ftwd

[Rodney W. Grimes]

> Author: phk
> Date: Sat Nov 28 22:34:33 2020
> New Revision: 368130
> URL: https://svnweb.freebsd.org/changeset/base/368130
> 
> Log:
>   Add watchdog(9) driver for the Fintek F81803 SuperIO chip
> 
> Added:
>   head/share/man/man4/ftwd.4   (contents, props changed)
>   head/sys/dev/ftwd/
>   head/sys/dev/ftwd/ftwd.c   (contents, props changed)
>   head/sys/modules/ftwd/
>   head/sys/modules/ftwd/Makefile   (contents, props changed)
> Modified:
>   head/share/man/man4/Makefile
>   head/sys/modules/Makefile
> 
> Modified: head/share/man/man4/Makefile
> ==
> --- head/share/man/man4/Makefile  Sat Nov 28 18:09:16 2020
> (r368129)
> +++ head/share/man/man4/Makefile  Sat Nov 28 22:34:33 2020
> (r368130)
> @@ -158,6 +158,7 @@ MAN=  aac.4 \
>   ffclock.4 \
>   filemon.4 \
>   firewire.4 \
> + ${_ftwd.4} \
>   full.4 \
>   fwe.4 \
>   fwip.4 \
> @@ -785,6 +786,7 @@ _chvgpio.4=   chvgpio.4
>  _coretemp.4= coretemp.4
>  _cpuctl.4=   cpuctl.4
>  _dpms.4= dpms.4
> +_ftwd.4= ftwd.4
>  _hpt27xx.4=  hpt27xx.4
>  _hptiop.4=   hptiop.4
>  _hptmv.4=hptmv.4
> 
> Added: head/share/man/man4/ftwd.4
> ==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ head/share/man/man4/ftwd.4Sat Nov 28 22:34:33 2020
> (r368130)
> @@ -0,0 +1,66 @@
> +.\"
> +.\" SPDX-License-Identifier: BSD-2-Clause-FreeBSD
> +.\"
> +.\" Copyright (c) 2012 Bjoern A. Zeeb 
> +.\" Copyright (c) 2019 Andriy Gapon 

This appears to be a new file, perhaps cloned from some place else?
And later you assert that you wrote this manual page,
so shouldn't you also be the copyright holder?


> +.\"
> +.\" Redistribution and use in source and binary forms, with or without
> +.\" modification, are permitted provided that the following conditions
> +.\" are met:
> +.\" 1. Redistributions of source code must retain the above copyright
> +.\"notice, this list of conditions and the following disclaimer.
> +.\" 2. Redistributions in binary form must reproduce the above copyright
> +.\"notice, this list of conditions and the following disclaimer in the
> +.\"documentation and/or other materials provided with the distribution.
> +.\"
> +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
> PURPOSE
> +.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
> CONSEQUENTIAL
> +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 
> STRICT
> +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> +.\" SUCH DAMAGE.
> +.\"
> +.\" $FreeBSD$
> +.\"
> +.Dd November 26, 2020
> +.Dt FTWD 4
> +.Os
> +.Sh NAME
> +.Nm ftwd
> +.Nd Fintek F81803 watchdog timer
> +.Sh SYNOPSIS
> +To compile this driver into the kernel, place the following lines in your
> +kernel configuration file:
> +.Bd -ragged -offset indent
> +.Cd "device superio"
> +.Cd "device ftwd"
> +.Ed
> +.Pp
> +Alternatively, to load the driver as a module at boot time, place the 
> following
> +line in
> +.Xr loader.conf 5 :
> +.Bd -literal -offset indent
> +ftwd_load="YES"
> +.Ed
> +.Sh DESCRIPTION
> +The
> +.Nm
> +driver provides
> +.Xr watchdog 4
> +support for the watchdog timer in the Fintek F81803 chip.
> +.Sh SEE ALSO
> +.Xr superio 4 ,
> +.Xr watchdog 4 ,
> +.Xr device.hints 5 ,
> +.Xr watchdog 8 ,
> +.Xr watchdogd 8 ,
> +.Xr watchdog 9
> +.Sh AUTHORS
> +.An -nosplit
> +This manual page was written by
> +.An Poul-Henning Kamp Aq Mt p...@freebsd.org .

Here you claim you wrote it...

> 
> Added: head/sys/dev/ftwd/ftwd.c
> ==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ head/sys/dev/ftwd/ftwd.c  Sat Nov 28 22:34:33 2020(r368130)
> @@ -0,0 +1,157 @@
> +/*-
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (c) 2020 Poul-Henning Kamp
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *

Re: svn commit: r367678 - head/usr.sbin/freebsd-update

[Rodney W. Grimes]

> On Sat, Nov 14, 2020 at 11:20 AM Mateusz Piotrowski <0...@freebsd.org> wrote:
> >
> > Hello Rodney,
> >
> > On 11/14/20 4:59 PM, Rodney W. Grimes wrote:
> > >> Author: 0mp (doc,ports committer)
> > >> Date: Sat Nov 14 13:07:41 2020
> > >> New Revision: 367678
> > >> URL: https://svnweb.freebsd.org/changeset/base/367678
> > >>
> > >> Log:
> > >>Document the PAGER environment variable
> > >>
> > >>Sometimes users want to use freebsd-update(8) in a non-interactive 
> > >> way and
> > >>what they often miss is that they have to set PAGER to cat(1) in 
> > >> order to
> > >>avoid interactive prompts from less(1).
> > > Which was caused by the change of invoking more(1) as less(1) causing
> > > this regression, as when invoked as more(1) it falls off the end of
> > > empty input and causes no such interactive prompt.
> > >
> > > Setting PAGER to more(1) also fixes this.
> >
> > Mmm, I'm not sure if that would work. If I run "jot 1000 | more" in my 
> > terminal I still get an
> > interactive prompt. Could it be that you are referring to a different 
> > more(1) implementation? I'm
> > clearly missing something.
> >

Part of what your missing is freebsd-update(8) often outputs a 0
length file which less(1) well want you to respond Quit to before
going to the next file.  more(1) does not do that.

jot 1000 produces 1 x 1000 line file, that is not whats causing
the issues with freebsd-update and less(1), it is more like
1000 x 1 line files.

> 
> more(1) is more or less like `less -E`, which is a default PAGER I had
> advocated for back when it changed. It can be mostly non-interactive
> as long as your diffs are small, but it's definitely much less
> painful.

Yes, that would of been less painful, note that iirc there are a
few other places effected in similiar ways with 0 line output
files sent to less(1) that cause a need to hit a bunch of q's
to get the command completed.

Since I am an aged more(1) user I just globally fix PAGER.
It would of been far less painful had PAGER simply been
changed to less rather than all the binary invokations
beeing changed, but hind sight is amazing.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r367678 - head/usr.sbin/freebsd-update

[Rodney W. Grimes]

> Author: 0mp (doc,ports committer)
> Date: Sat Nov 14 13:07:41 2020
> New Revision: 367678
> URL: https://svnweb.freebsd.org/changeset/base/367678
> 
> Log:
>   Document the PAGER environment variable
>   
>   Sometimes users want to use freebsd-update(8) in a non-interactive way and
>   what they often miss is that they have to set PAGER to cat(1) in order to
>   avoid interactive prompts from less(1).

Which was caused by the change of invoking more(1) as less(1) causing
this regression, as when invoked as more(1) it falls off the end of
empty input and causes no such interactive prompt.

Setting PAGER to more(1) also fixes this.

>   
>   MFC after:  4 weeks
> 
> Modified:
>   head/usr.sbin/freebsd-update/freebsd-update.8
> 
> Modified: head/usr.sbin/freebsd-update/freebsd-update.8
> ==
> --- head/usr.sbin/freebsd-update/freebsd-update.8 Sat Nov 14 12:02:50 
> 2020(r367677)
> +++ head/usr.sbin/freebsd-update/freebsd-update.8 Sat Nov 14 13:07:41 
> 2020(r367678)
> @@ -25,7 +25,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd September 24, 2019
> +.Dd November 14, 2020
>  .Dt FREEBSD-UPDATE 8
>  .Os
>  .Sh NAME
> @@ -193,6 +193,20 @@ System", since if the system has been tampered with
>  it cannot be trusted to operate correctly.
>  If you intend to use this command for intrusion-detection
>  purposes, make sure you boot from a secure disk (e.g., a CD).
> +.El
> +.Sh ENVIRONMENT
> +.Bl -tag -width "PAGER"
> +.It Ev PAGER
> +The pager program used to present various reports during the execution.
> +.Po
> +Default:
> +.Dq Pa /usr/bin/less .
> +.Pc
> +.Pp
> +.Ev PAGER
> +can be set to
> +.Dq cat
> +when a non-interactive pager is desired.
>  .El
>  .Sh FILES
>  .Bl -tag -width "/etc/freebsd-update.conf"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r367280 - head/lib/libc/gen

[Rodney W. Grimes]

Picking a late message in this thread to reply to

[ Charset windows-1252 unsupported, converting... ]
> >>>I think that the first question we want to ask is : Do we want to
> >>> support LOCALBASE being different than /usr/local
> >>
> >> The big majority of users will keep the default value, and I do not
> >> see a good reason for a change, except if there is a large installed
> >> base that traditionally uses another prefix (I have seen /vol/local
> >> and /opt, but also OS and architecture-specific prefixes, for example).
> > 
> >   I'd still like to see some arguments for such installs.
> 
> There are no reasons, if you have a narrow scope where FreeBSD should
> get installed. If it only on individual desktop users' system, they
> are best served with LOCALBASE immutably fixed to /usr/local.
> 
> But there are other kinds of user and I have already given examples.
> Companies that have tooling that traditionally used some other prefix
> will not rewrite all their tools if we tell them that only /usr/local
> is supported, for example.
> 
> I do not have to justify the existence of such use cases, and I'm happy
> with /usr/local on all my systems. But I do know that such use cases
> do exist and I have worked in environments where they were relevant.
> 

For 25 years PREFIX has been rigidly a part of the ports infustructure,
why is it that the BASE system has been allowed to de-evolve from this
concept as documented and REQUIRED by:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html


I again assert at one time the base system was clean of this,
it has regressed and needs to be fixed.  That fix should restore
the independence of PREFIX.  If 30k ported pieces of software can
do it why can't the base system do it?

Those ports do not require a recompile, why should the base system?

> >>>I honestly don't see any advantages of making it !=/usr/local/ and
> >>> before we start putting a lot of new/useless(for I guess 99% of our
> >>> user base) in the tree we should here why people are using /usr/pkg or
> >>> whatever weird location.
> >>
> >> No, why should we [assess] (assuming that word is to be implied in
> >> your sentence) why people want to be able to easily use a different
> >> prefix? That would be a waste of time, IMHO.
> >>
> >> I know that there are legitimate reasons to want a different prefix,
> >> and we had requests to make it easier to support it.
> > 
> >   What are thoses ?
> 
> Please check the mail-lists since I did not save those messages.
> 
> >> We have literal uses of /usr/local in a lot of files in the FreeBSD
> >> base system (more than 1700) and this is not going to change.
> >>
> >> But it was easy to replace a number of such literal pathes in base
> >> system binaries, and we can make it easier for those that need a
> >> different prefix to get it consistently used.
> >>
> >>>If they have some good argument, then we should proceed further.
> >>
> >> You do not have to participate in this effort
> > 
> >   I do have to participate, it's a common project.
> 
> But it does not affect you if you do not use it.
> 
> >   Also since I also participate in pkg(8) and in ports/Mk lua/blah stuff
> > there might be some stuff to do there so yes I need to participate.
> 
> Ports should already support PREFIX and LOCALBASE other than /usr/local.
> 
> And the pkg program even supports the LOCALBASE environment variable.
> 
> All we try to do is go away from multiple inconsistent methods and
> mechanisms and make it easier for installations that do have a need
> for a different LOCALBASE to get in consistently applied to all parts
> of the system. (They have to go through the tree and apply local
> patches to program sources or config files, currently, but will then
> have the same result with much more effort spent by each of them.)
> 
> >   And since you never really started a conversation on a ml (that I know
> > of) my only mean to start this participation is answering a commit
> > email.
> 
> There has been a lengthy discussion in the thread about moving the
> calendar data files out of the base system.
> 
> And there is review D26942, which was announced on the -current list
> and which you seem to have missed. Also relevant are D27009, D27014,
> and D27022, which have been mentioned in commits as far they have
> already been committed, but have not been widely announced. You can
> easily
> 
> >> - there are so many
> >> other areas to work on (and I know you are very active in one).
> > 
> >   Only one ? Damn, I should work more then.
> 
> The most recent breakage you caused for me was the backlight kernel
> option that has been introduced without any discussion I'm aware of.
> 
> Yes, I know about your involvement in getting support for modern GPUs
> into FreeBSD and appreciate it.
> 
> >> But please do not ask those that have started to reduce the use of
> >> literal /usr/local in the base system to justify this work.
> > 
> >   

Re: svn commit: r367228 - in stable: 11/contrib/llvm-project/lldb/source/Target 12/contrib/llvm-project/lldb/source/Target

[Rodney W. Grimes]

> Author: dim
> Date: Sat Oct 31 18:42:03 2020
> New Revision: 367228
> URL: https://svnweb.freebsd.org/changeset/base/367228
> 
> Log:
>   MFC r364480:
>   
>   Merge commit 1ce07cd614be from llvm git (by me):
^^^
FYI, we have a username me so this is not the best
way to express yourself in commit mail:
freefall:rgrimes {102} grep ^me: /etc/passwd
me:*:589:589:Michael Elbel:/home/me:/usr/local/bin/bash


>   
> Instantiate Error in Target::GetEntryPointAddress() only when
> necessary
>   
> When Target::GetEntryPointAddress() calls
> exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned
> entry_addr is valid, it can immediately be returned.
>   
> However, just before that, an llvm::Error value has been setup, but
> in this case it is not consumed before returning, like is done
> further below in the function.
>   
> In https://bugs.freebsd.org/248745 we got a bug report for this,
> where a very simple test case aborts and dumps core:
>   
> * thread #1, name = 'testcase', stop reason = breakpoint 1.1
> frame #0: 0x002018d4 testcase`main(argc=1, 
> argv=0x7fffea18) at testcase.c:3:5
>1int main(int argc, char *argv[])
>2{
> -> 3return 0;
>4}
> (lldb) p argc
> Program aborted due to an unhandled Error:
> Error value was Success. (Note: Success values must still be checked 
> prior to being destroyed).
>   
> Thread 1 received signal SIGABRT, Aborted.
> thr_kill () at thr_kill.S:3
> 3   thr_kill.S: No such file or directory.
> (gdb) bt
> #0  thr_kill () at thr_kill.S:3
> #1  0x0008049a0004 in __raise (s=6) at 
> /usr/src/lib/libc/gen/raise.c:52
> #2  0x000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
> #3  0x0451b5f5 in fatalUncheckedError () at 
> /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
> #4  0x019cf008 in GetEntryPointAddress () at 
> /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
> #5  0x01bccbd8 in ConstructorSetup () at 
> /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
> #6  0x01bcd2c0 in ThreadPlanCallFunction () at 
> /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
> #7  0x020076d4 in InferiorCallMmap () at 
> /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
> #8  0x01f4be33 in DoAllocateMemory () at 
> /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
> #9  0x01fe51b9 in AllocatePage () at 
> /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
> #10 0x01fe5385 in AllocateMemory () at 
> /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
> #11 0x01974da2 in AllocateMemory () at 
> /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
> #12 CanJIT () at 
> /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
> #13 0x01a1bf3d in Evaluate () at 
> /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
> #14 0x019ce7a2 in EvaluateExpression () at 
> /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
> #15 0x01ad784c in EvaluateExpression () at 
> /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
> #16 0x01ad86ae in DoExecute () at 
> /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
> #17 0x01a5e3ed in Execute () at 
> /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
> #18 0x01a6c4a3 in HandleCommand () at 
> /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
> #19 0x01a6f98c in IOHandlerInputComplete () at 
> /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
> #20 0x01a90b08 in Run () at 
> /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
> #21 0x019a6c6a in ExecuteIOHandlers () at 
> /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
> #22 0x01a70337 in RunCommandInterpreter () at 
> /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
> #23 0x01d9d812 in RunCommandInterpreter () at 
> /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
> #24 0x01918be8 in MainLoop () at 
> /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
> #25 0x0191a114 in main () at 
> /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890
>   
> Fix the incorrect error catch by only instantiating an Error object
> if it is necessary.
>   
> Reviewed By: JDevlieghere
>   
> Differential Revision: 

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Rodney W. Grimes]

[ Charset ISO-8859-1 unsupported, converting... ]
> On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote:
> > Am 24.10.20 um 09:48 schrieb Alex Kozlov:
> > > On Fri, Oct 23, 2020 at 09:22:23AM +, Stefan E?er wrote:
> > > > Author: se
> > > > Date: Fri Oct 23 09:22:23 2020
> > > > New Revision: 366962
> > > > URL: https://svnweb.freebsd.org/changeset/base/366962
> > > > 
> > > > Log:
> > > >Add search of LOCALBASE/share/calendar for calendars supplied by a 
> > > > port.
> > > >Calendar files in LOCALBASE override similarily named ones in the 
> > > > base
> > > >system. This could easily be changed if the base system calendars 
> > > > should
> > > >have precedence, but it could lead to a violation of POLA since then 
> > > > the
> > > >port's files were ignored unless those in base have been deleted.
> > > >There was no definition of _PATH_LOCALBASE in paths.h, but verbatim 
> > > > uses
> > > >of /usr/local existed for _PATH_DEFPATH. Use _PATH_LOCALBASE here to 
> > > > ease
> > > >a consistent modification of this prefix.
> > > You are hardcoding assumption that LOCALBASE = /usr/local. Please make it
> > > overridable with LOCALBASE environment variable.
> > This was a trivial change to get us going with calendars provided by
> > a port (which has not been committed, yet - therefore there are no
> > port-provided calendars, neither under /usr/local nor under any other
> > PREFIX, as of now).
> 
> > I understand what you are asking for, but in such a case I'd rather
> > think you want to rebuild FreeBSD with _PATH_LOCALBASE modified in
> > paths.h.
> The PREFIX != LOCALBASE and both != /usr/local configurations
> are supported in the ports tree and the base for a long time, please see
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html

Seems all that work for all them years is about to be tossed out
the window as "an out dated concept".

> 
> If after this commit you need to rebuild base to use non-default 
> LOCALBASE/PREFIX
> it is pretty big regression and POLA.

I guess no one is paying attention to any of this...
  
> > And I have made this a single instance that needs to be changed.
> > Before my change there were 2 instances of /usr/local hard-coded
> > in _PATH_DEFPATH - now you have to only change the definition of
> > _PATH_LOCALBASE to adjust all 3 locations that use it.
> I think you made situation worse, there were two stray hardcoded
> string and now there is official LOCALBASE define which likely will be
> used by other people in the future.

Yep, and now that propogation is about to occur.

>  
> > If you can show me precedence of a LOCALBASE environment variable
> > being used in the way you suggest, I'd be willing to make calendar
> > use it.
> Just an analogy from LOCALBASE make variable, perhaps CALENDAR_HOME
> is a better name.
>  
> > But then I think a CALENDAR_HOME variable would be even more useful,
> > since it would allow to search an additional user selected directory
> > (and not just share/calendar within what you provide as LOCALBASE).
> > 
> > Regards, STefan
> > 
> > PS: If you are a source committer, you might even commit such a
> > change yourself. But I'd think it should be reviewed, and it
> > might be a good idea to wait until other changes (e.g. the
> > switch-over to port-supplied calendar files) have been worked
> > out.
> 
> 
> -- 
> Alex
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Rodney W. Grimes]

> On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes 
> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > > Author: se
> > > Date: Fri Oct 23 09:22:23 2020
> > > New Revision: 366962
> > > URL: https://svnweb.freebsd.org/changeset/base/366962
> > >
> > > Log:
> > >   Add search of LOCALBASE/share/calendar for calendars supplied by a
> > port.
> > >
> > >   Calendar files in LOCALBASE override similarily named ones in the base
> > >   system. This could easily be changed if the base system calendars
> > should
> > >   have precedence, but it could lead to a violation of POLA since then
> > the
> > >   port's files were ignored unless those in base have been deleted.
> > >
> > >   There was no definition of _PATH_LOCALBASE in paths.h, but verbatim
> > uses
> > >   of /usr/local existed for _PATH_DEFPATH. Use _PATH_LOCALBASE here to
> > ease
> > >   a consistent modification of this prefix.
> > >
> > >   Reviewed by:imp, pfg
> > >   Differential Revision:  https://reviews.freebsd.org/D26882
> > >
> > > Modified:
> > >   head/include/paths.h
> > >   head/usr.bin/calendar/io.c
> > >   head/usr.bin/calendar/pathnames.h
> > >
> > > Modified: head/include/paths.h
> > >
> > ==
> > > --- head/include/paths.h  Fri Oct 23 08:44:53 2020(r366961)
> > > +++ head/include/paths.h  Fri Oct 23 09:22:23 2020(r366962)
> > > @@ -37,8 +37,11 @@
> > >
> > >  #include 
> > >
> > > +#define  _PATH_LOCALBASE "/usr/local"
> > > +
> >
> > Something feels very wrong about this becoming a  defined path in base,
> > it is further dependence on /usr/local which in the early days we spent
> > a great deal of time removing.
> >
> > I believe the whole ports system allows this to be something other
> > than /usr/local.  Package should also allow it to be some other place.
> >
> 
> This removes a couple of instances of /usr/local being hardcoded and
> replaces with a define, so net it's better.

No, its net worse as it now creates a define that is highly likely
to propogate adding additional dependencies on this value.

> 
> It could be even better, but this is slightly better than it was before.

I disagree, as it is now easier for additional contamination of
the base system.

> Warner
> 
> 
> > >  /* Default search path. */
> > > -#define  _PATH_DEFPATH
> >  "/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
> > > +#define  _PATH_DEFPATH   "/sbin:/bin:/usr/sbin:/usr/bin:" \
> > > + _PATH_LOCALBASE "/sbin:" _PATH_LOCALBASE "/bin"
> > >  /* All standard utilities path. */
> > >  #define  _PATH_STDPATH   "/usr/bin:/bin:/usr/sbin:/sbin"
> > >  /* Locate system binaries. */
> > >
> > > Modified: head/usr.bin/calendar/io.c
> > >
> > ==
> > > --- head/usr.bin/calendar/io.cFri Oct 23 08:44:53 2020
> > (r366961)
> > > +++ head/usr.bin/calendar/io.cFri Oct 23 09:22:23 2020
> > (r366962)
> > > @@ -71,7 +71,7 @@ enum {
> > >  };
> > >
> > >  const char *calendarFile = "calendar";   /* default calendar file */
> > > -static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE}; /*
> > HOME */
> > > +static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE_LOCAL,
> > _PATH_INCLUDE}; /* HOME */
> > >  static const char *calendarNoMail = "nomail";/* don't sent mail if file
> > exist */
> > >
> > >  static char path[MAXPATHLEN];
> > >
> > > Modified: head/usr.bin/calendar/pathnames.h
> > >
> > ==
> > > --- head/usr.bin/calendar/pathnames.h Fri Oct 23 08:44:53 2020
> > (r366961)
> > > +++ head/usr.bin/calendar/pathnames.h Fri Oct 23 09:22:23 2020
> > (r366962)
> > > @@ -35,3 +35,4 @@
> > >  #include 
> > >
> > >  #define  _PATH_INCLUDE   "/usr/share/calendar"
> > > +#define  _PATH_INCLUDE_LOCAL _PATH_LOCALBASE "/share/calendar"
> > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r366962 - in head: include usr.bin/calendar

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: se
> Date: Fri Oct 23 09:22:23 2020
> New Revision: 366962
> URL: https://svnweb.freebsd.org/changeset/base/366962
> 
> Log:
>   Add search of LOCALBASE/share/calendar for calendars supplied by a port.
>   
>   Calendar files in LOCALBASE override similarily named ones in the base
>   system. This could easily be changed if the base system calendars should
>   have precedence, but it could lead to a violation of POLA since then the
>   port's files were ignored unless those in base have been deleted.
>   
>   There was no definition of _PATH_LOCALBASE in paths.h, but verbatim uses
>   of /usr/local existed for _PATH_DEFPATH. Use _PATH_LOCALBASE here to ease
>   a consistent modification of this prefix.
>   
>   Reviewed by:imp, pfg
>   Differential Revision:  https://reviews.freebsd.org/D26882
> 
> Modified:
>   head/include/paths.h
>   head/usr.bin/calendar/io.c
>   head/usr.bin/calendar/pathnames.h
> 
> Modified: head/include/paths.h
> ==
> --- head/include/paths.h  Fri Oct 23 08:44:53 2020(r366961)
> +++ head/include/paths.h  Fri Oct 23 09:22:23 2020(r366962)
> @@ -37,8 +37,11 @@
>  
>  #include 
>  
> +#define  _PATH_LOCALBASE "/usr/local"
> +

Something feels very wrong about this becoming a  defined path in base,
it is further dependence on /usr/local which in the early days we spent
a great deal of time removing.

I believe the whole ports system allows this to be something other
than /usr/local.  Package should also allow it to be some other place.

>  /* Default search path. */
> -#define  _PATH_DEFPATH   
> "/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
> +#define  _PATH_DEFPATH   "/sbin:/bin:/usr/sbin:/usr/bin:" \
> + _PATH_LOCALBASE "/sbin:" _PATH_LOCALBASE "/bin"
>  /* All standard utilities path. */
>  #define  _PATH_STDPATH   "/usr/bin:/bin:/usr/sbin:/sbin"
>  /* Locate system binaries. */
> 
> Modified: head/usr.bin/calendar/io.c
> ==
> --- head/usr.bin/calendar/io.cFri Oct 23 08:44:53 2020
> (r366961)
> +++ head/usr.bin/calendar/io.cFri Oct 23 09:22:23 2020
> (r366962)
> @@ -71,7 +71,7 @@ enum {
>  };
>  
>  const char *calendarFile = "calendar";   /* default calendar file */
> -static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE}; /* HOME */
> +static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE_LOCAL, 
> _PATH_INCLUDE}; /* HOME */
>  static const char *calendarNoMail = "nomail";/* don't sent mail if file 
> exist */
>  
>  static char path[MAXPATHLEN];
> 
> Modified: head/usr.bin/calendar/pathnames.h
> ==
> --- head/usr.bin/calendar/pathnames.h Fri Oct 23 08:44:53 2020
> (r366961)
> +++ head/usr.bin/calendar/pathnames.h Fri Oct 23 09:22:23 2020
> (r366962)
> @@ -35,3 +35,4 @@
>  #include 
>  
>  #define  _PATH_INCLUDE   "/usr/share/calendar"
> +#define  _PATH_INCLUDE_LOCAL _PATH_LOCALBASE "/share/calendar"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r366537 - head/libexec/rc/rc.d

[Rodney W. Grimes]

> Author: kaktus
> Date: Thu Oct  8 11:45:10 2020
> New Revision: 366537
> URL: https://svnweb.freebsd.org/changeset/base/366537
> 
> Log:
>   [pf] /etc/rc.d/pf should REQUIRE routing
>   
>   When a system with pf_enable="YES" in /etc/rc.conf uses hostnames in
>   /etc/pf.conf, these hostnames cannot be resolved via external nameservers
>   because the default route is not yet set. This results in an empty
>   (all open) ruleset.

Use of hostnames in pf, or any firewall for that mater tends to make
my hair stand on end, unless those hostnames resolve via /etc/hosts
or a link local resolver.

>   
>   Since r195026 already put netif back to REQUIRE, this change does not affect
>   the issue that the firewall should rather have been setup before any
>   network traffic can occur.

This well cause any system that requires pf rules
before routing can work to fail, aka almost any real
router running a real routing protocol well now fail
or have issues during route daemon start up as without
firewall rules the default is to deny the routing
protocol packets.

This should be reverted, or at least made knobable in some way.

>   
>   PR: 211928
>   Submitted by:   Robert Schulze
>   Reported by:Robert Schulze
>   Tested by:  Mateusz Kwiatkowski
>   No objections from: kp
>   MFC after:  3 days
> 
> Modified:
>   head/libexec/rc/rc.d/pf
> 
> Modified: head/libexec/rc/rc.d/pf
> ==
> --- head/libexec/rc/rc.d/pf   Thu Oct  8 11:30:22 2020(r366536)
> +++ head/libexec/rc/rc.d/pf   Thu Oct  8 11:45:10 2020(r366537)
> @@ -4,8 +4,7 @@
>  #
>  
>  # PROVIDE: pf
> -# REQUIRE: FILESYSTEMS netif pflog pfsync
> -# BEFORE:  routing
> +# REQUIRE: FILESYSTEMS netif pflog pfsync routing
>  # KEYWORD: nojailvnet
>  
>  . /etc/rc.subr
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts

[Rodney W. Grimes]

> 
> > On Sep 26, 2020, at 1:22 PM, Warner Losh  wrote:
> > 
> > 
> > 
> > I am the wrong person to answer that question.
> > 
> > In this case, things have not become lame.  For instance, the names 
> > ervers for se.freebsd.org work fine, but ftp3.se and ftp6.se records are 
> > removed.  Same for ru.freebsd.org and ftp4.ru.
> > I'm merely pointing out that changing ftp.CC.freebsd.org usually 
> > requires contacting the person(s) maintaining the CC.freebsd.org zone, 
> > which is usually not the project.
> > 
> > It's usually people associated with the project in some way, but who might 
> > not be as responsive as cluster admin. These domains have been delegated, 
> > so we have to get the delegated admin to make the changes, which can take a 
> > bit of time to chase down and doesn't lend itself to easy / automated 
> > coping with this situation.
> > 
> 
> Just a spitball idea here, but maybe we should consider not embedding these 
> lists of mirror URLs into the binaries.  It seems pretty straight-forward 
> that the list evolves over time, and that evolution is not tightly coupled 
> with the updating of the binaries.  It sounds like the pkg and freebsd-update 
> infrastructure use DNS TXT and/or SRV records to point to the metadata needed 
> to construct a mirror URL list dynamically.  Maybe something similar can be 
> done for bsdconfig?  If it?s not a crazy idea, is there anyone who would be 
> interested in helping me write a proposal over at arch@?

100% behind that idea!  Especially since it seems the project has lost
(some) control over its DNS space, which IMHO, is still an issue, if
the people whom DNS zones have been deligated to are not responsive
that should also be fixed.


> Thanks,
> Scott

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365643 - head/bin/cp

[Rodney W. Grimes]

> On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk  wrote:
> 
> > On Sat, Sep 26, 2020 at 11:55 AM Warner Losh  wrote:
> >
> >> And there's the rub: how did this file come to exist? I'm certain it isn't
> >> booting or shutting down the system based on when devfs is mounted (before
> >> init) and unmounted (it's not done by the shutdown scripts). Now, it's
> >> always possible there's a hole in my understanding of the sequence of
> >> events. But given the examination of code, it's crazy to think this could
> >> be created by anything but some weird bug. That's why a step-by-step from
> >> scratch guide is needed. Im happy to look into it, but I need a bit more
> >> to
> >> go on.

Some others have run dumps, nfs exports, so far I see 4 file system report,
I see these infrequently, so I would not consider these 4 file systems to
be a very large data set.

> >>
> >>
> > I don't think it's terribly complicated; either set up a multi-boot system
> > or
> > pull the physical drive with / from one machine, and mount it while booted
> > into a different environment.  Then, chroot into it and do ... just about
> > anything.
> > If you didn't mount devfs before chrooting, then you get a file /dev/null
> > (and some
> > really confused errors from, e.g., buildworld!).

This is not the situation that I am reporting.

> 
> I think there's two different things that are being talked about here.
> Let's not confuse the two.
> 
> The first is making the build system not depend on /dev/null. You'll find
> that's hard to do if you and try to do it since /dev/null is used about 200
> times in the current build system in about a dozen different ways. Some are
> easy, most are a bit tricky since you can't just close stdout/stderr
> because then any files opened by the program will get those FDs and
> printf/fprint(stderr, will collide.  This dependency won't be fixed any
> time soon, though I could add a seatbelt to buildworld/buildkernel that
> ensures that /dev/null is a character device.
> 
> The second is a report that /dev/null is created all the time through

Correction, I never stated "all the time".  I stated I have seen this
on SOME analysis of disk pulled from running systems.  Let me add to
that these driver are only ever mounted Readonly, as what is going on
is a forensics state post mortem of the system.  These are not jails,
some may be VM images, but even in the VM cases these are raw disk
images that are never mounted read/write.

It is possible that a cdrom or nfs boot was done during the life
time of the node(s) with a chroot into a root file system mounted
some place else.

> normal means before devfs can be mounted.  However, several people have
> looked and found no evidence on their system. This means there's something
> special / unique to Rod's setup that's generating them (assuming it isn't a
> simple chroot without devfs). What that is, and how they come to be, hasn't
> been explained in enough detail to reproduce. That's what people are asking
> Rod about: how do we get there? How did it happen? Once we know those
> answers, we can fix it.

Problem is these are being found in after the fact analysis,
so "getting there" is going to be hard.  I'll try to collect
better data such as inode contents and dates and see if I 
can correlate that to system install time, or some time during
the systems life time.

Given what kib, and ian have said I am starting to suspect
that this may be occuring during the install process, the
dates on the null inode and a find of the oldest inode on
the disk should correlate that next time I see one of these.

If I could easily reroduce it we would not be having
this conversation, it would of been fixed.

> Warner
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts

[Rodney W. Grimes]

> On 2020-09-26 20:12, Rodney W. Grimes wrote:
> >> Author: zeising (doc,ports committer)
> >> Date: Sat Sep 26 16:27:09 2020
> >> New Revision: 366186
> >> URL: https://svnweb.freebsd.org/changeset/base/366186
> >>
> >> Log:
> >>bsdconfig, bsdinstall: Prune dead mirrors
> >>
> >>Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall.
> >>All these return NXDOMAIN when trying to resolve them.
> > 
> > This seems like the wrong place to fix it, as this does
> > nothing for all the "shipped" releases that contain the
> > old values.  Shouldnt these all just be CNAMED in dns
> > to a nearest replacement resource?
> > 
> > 
> 
> Considering that we don't actually have control of the subdomans 
> (CC.freebsd.org) ourselves, that is trickier than it might sound.

How can freebsd.org NOT have ultimate control over deligations?
If things have become "lame" in a deligated zone the deligation
can and should be pulled and replaced with local data.

This is cc.freebsd.org, not freebsd.org.cc!

> I do not oppose that change, but I'm not doing the work to chase all the 
> subdomain DNS admins down to try to fix it.

Nor should you, this should be a clusteradm/domain administration
person that should already working to keep the projects DNS data
up to date and reliable.

> This change cleans out some old mirrors for the 12.2 release, so that 
> people installing 12.2 (and later stuff) won't have the installer 
> complain when they accidentally pick a nonexistent mirror.
> I believe that the proper way to fix this is to just use the FreeBSD CDN 
> even for these downloads (basically, go straight to 
> download.freebsd.org, or at least have that as the preferred option), 
> but I haven't gotten around to that.
> Regards
> -- 
> Niclas Zeising
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts

[Rodney W. Grimes]

> Author: zeising (doc,ports committer)
> Date: Sat Sep 26 16:27:09 2020
> New Revision: 366186
> URL: https://svnweb.freebsd.org/changeset/base/366186
> 
> Log:
>   bsdconfig, bsdinstall: Prune dead mirrors
>   
>   Prune dead mirrors from the list of mirrors in bsdconfig and bsdinstall.
>   All these return NXDOMAIN when trying to resolve them.

This seems like the wrong place to fix it, as this does
nothing for all the "shipped" releases that contain the
old values.  Shouldnt these all just be CNAMED in dns
to a nearest replacement resource?


>   Reviewed by:emaste
>   Approved by:emaste
>   MFC after:  3 days
>   Differential Revision:  https://reviews.freebsd.org/D26535
> 
> Modified:
>   head/usr.sbin/bsdconfig/share/media/ftp.subr
>   head/usr.sbin/bsdinstall/scripts/mirrorselect
> 
> Modified: head/usr.sbin/bsdconfig/share/media/ftp.subr
> ==
> --- head/usr.sbin/bsdconfig/share/media/ftp.subr  Sat Sep 26 14:44:58 
> 2020(r366185)
> +++ head/usr.sbin/bsdconfig/share/media/ftp.subr  Sat Sep 26 16:27:09 
> 2020(r366186)
> @@ -82,7 +82,6 @@ f_dialog_menu_media_ftp()
>   ' IPv6 $msg_japan''ftp2.jp.freebsd.org'
>   ' IPv6 $msg_sweden'   'ftp4.se.freebsd.org'
>   ' IPv6 $msg_usa'  'ftp4.us.freebsd.org'
> - ' IPv6 $msg_turkey'   'ftp2.tr.freebsd.org'
>   '$msg_primary''ftp1.freebsd.org'
>   ' $msg_primary #2''ftp2.freebsd.org'
>   ' $msg_primary #3''ftp3.freebsd.org'
> @@ -95,7 +94,6 @@ f_dialog_menu_media_ftp()
>   ' $msg_primary #12'   'ftp12.freebsd.org'
>   ' $msg_primary #13'   'ftp13.freebsd.org'
>   ' $msg_primary #14'   'ftp14.freebsd.org'
> - '$msg_armenia''ftp1.am.freebsd.org'
>   '$msg_australia'  'ftp.au.freebsd.org'
>   ' $msg_australia #2'  'ftp2.au.freebsd.org'
>   ' $msg_australia #3'  'ftp3.au.freebsd.org'
> @@ -103,11 +101,9 @@ f_dialog_menu_media_ftp()
>   '$msg_brazil' 'ftp2.br.freebsd.org'
>   ' $msg_brazil #3' 'ftp3.br.freebsd.org'
>   ' $msg_brazil #4' 'ftp4.br.freebsd.org'
> - '$msg_canada' 'ftp.ca.freebsd.org'
>   '$msg_china'  'ftp.cn.freebsd.org'
>   '$msg_czech_republic' 'ftp.cz.freebsd.org'
>   '$msg_denmark''ftp.dk.freebsd.org'
> - '$msg_estonia''ftp.ee.freebsd.org'
>   '$msg_finland''ftp.fi.freebsd.org'
>   '$msg_france' 'ftp.fr.freebsd.org'
>   ' $msg_france #3' 'ftp3.fr.freebsd.org'
> @@ -120,13 +116,11 @@ f_dialog_menu_media_ftp()
>   ' $msg_germany #2''ftp2.de.freebsd.org'
>   ' $msg_germany #4''ftp4.de.freebsd.org'
>   ' $msg_germany #5''ftp5.de.freebsd.org'
> - ' $msg_germany #6''ftp6.de.freebsd.org'
>   ' $msg_germany #7''ftp7.de.freebsd.org'
>   ' $msg_germany #8''ftp8.de.freebsd.org'
>   '$msg_greece' 'ftp.gr.freebsd.org'
>   ' $msg_greece #2' 'ftp2.gr.freebsd.org'
>   '$msg_ireland''ftp3.ie.freebsd.org'
> - '$msg_israel' 'ftp.il.freebsd.org'
>   '$msg_japan'  'ftp.jp.freebsd.org'
>   ' $msg_japan #2'  'ftp2.jp.freebsd.org'
>   ' $msg_japan #3'  'ftp3.jp.freebsd.org'
> @@ -139,16 +133,13 @@ f_dialog_menu_media_ftp()
>   '$msg_korea'  'ftp.kr.freebsd.org'
>   ' $msg_korea #2'  'ftp2.kr.freebsd.org'
>   '$msg_latvia' 'ftp.lv.freebsd.org'
> - '$msg_lithuania'  'ftp.lt.freebsd.org'
>   '$msg_netherlands''ftp.nl.freebsd.org'
>   ' $msg_netherlands #2''ftp2.nl.freebsd.org'
>   '$msg_new_zealand''ftp.nz.freebsd.org'
>   '$msg_norway' 'ftp.no.freebsd.org'
>   '$msg_poland' 'ftp.pl.freebsd.org'
> - ' $msg_poland #2' 'ftp2.pl.freebsd.org'
>   '$msg_russia' 'ftp.ru.freebsd.org'
>   ' $msg_russia #2' 'ftp2.ru.freebsd.org'
> - ' $msg_russia #4' 'ftp4.ru.freebsd.org'
>   ' $msg_russia #5' 'ftp5.ru.freebsd.org'
>   ' $msg_russia #6' 'ftp6.ru.freebsd.org'
>   '$msg_slovak_republic''ftp.sk.freebsd.org'
> @@ -157,13 +148,9 @@ f_dialog_menu_media_ftp()
>   '$msg_south_africa'   'ftp.za.freebsd.org'
>   ' $msg_south_africa #2'   

Re: svn commit: r365643 - head/bin/cp

[Rodney W. Grimes]

> On Fri, 2020-09-25 at 10:55 -0700, Rodney W. Grimes wrote:
> > > I was under the impression from previous reading and kib's response
> > > that this is a complete non-issue, there's no way you can go
> > > multi-user without a mounted /dev and we go to somewhat great
> > > lengths to make sure we're good.
> > 
> > Though kib can assert that, it does not change the fact that I
> > frequently find /dev/null FILES on unmounted root file systems.
> > 
> > But lets not mix the 2 separate things of boot time /dev dependency
> > and build time /dev dependency.
> 
> If you look in sys/kern/vfs_mountroot.c you can see that the code to
> mount /dev is invoked unconditionally as the first step of mounting
> root, and that all the calls it makes to get devfs mounted have their
> results checked with KASSERTs.
> 
> That's pretty strong evidence that devfs is mounted before rc scripts
> run.  That creates a situation where you are making an extraordinary
> claim, so you need to provide extraordinary evidence to support it.  A
> sequence of actions that allows others to recreate the situation would
> do the trick.

I have provided ways one can look for this file in
other messages of the threads.  A dump of a UFS root
can show it up, and iirc you can find it in a
zfs send of a boot dataset.

> 
> (A question that occurs to me:  could it be that the files you've seen
> got created at shutdown after devfs was unmounted, rather than at
> startup?  I don't know enough about the shutdown sequence to know
> whether that's possible.)

Its not "the files" it is "a file, /dev/null".  And yes, it could
be very possible that it is during shutdown.  Sadly the files is
usually of 0 length so leave little clue as to what is creating them.

> -- Ian
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365643 - head/bin/cp

[Rodney W. Grimes]

> On Thu, Sep 24, 2020 at 3:08 AM Stefan Esser  wrote:
> >
> > Am 24.09.20 um 08:54 schrieb Warner Losh:
> > >
> > >
> > > On Thu, Sep 24, 2020 at 12:41 AM Stefan Esser  > > > wrote:
> > >
> > > Am 23.09.20 um 19:23 schrieb Warner Losh> But for this issue, we're 
> > > not
> > > mounting devfs early enough.  We should
> > >  > fix that. Removing /dev/null from the boot process likely is
> > > never going
> > >  > to happen because we use it all over the place to discard output...
> > >  > There's ~200 instances of it in the boot rc scripts, so getting
> > > rid of
> > >  > it there would also be quite the effort, with the same question.
> > >
> > > Removal of /dev/null from rc.d scripts should be quite simple,
> > > since most cases could just use ">-" (close file descriptor)
> > > instead. Other usage could be substituted with ":>" followed
> > > by chown.
> > >
> > >
> > > So closing fd1 and fd2 doesn't cause them to be available for these
> > > programs to get as an fd on open, causing other issues?
> > >
> > > But >- isn't documented in sh(1) as doing the close thing. On a whim I
> > > did the following:
> > > $ echo fred >-
> > > $ ls -last ./-
> > > 4 -rw-r--r--  1 imp  imp  5 Sep 24 00:50 ./-
> > > $ cat ./-
> > > fred
> > > $
> > > which suggests maybe you now have a lot of files named - instead...
> >
> > Yes, sorry, please ignore what I wrote - I was thinking of ">&-" of
> > course, but that is not gracefully accepted by many commands (they
> > are aborted when trying to write to the closed file descriptor).
> >
> > I had thought about piping into a command that ignores STDIN, first,
> > e.g. "| :", but that generates a SIGPIPE when trying to flush the
> > FILE buffer (i.e. after 4 KB, which might be sufficient for most
> > cases, but it is not a general solution).
> >
> > A program that reads from STDIN and generates no output could be used,
> > though, e.g. "| sed d".
> >
> > But this would cause lots of extra forked processes and increase the
> > start-up time and is not acceptable.
> >
> > > but e.g. rc.d/syscons
> > > uses ${kbddev} (i.e. /dev/ttyv0) and rc.d/zvol performs swapon
> > > on /dev/zvol/${name}, rc.d/random uses /dev/random and so on.
> > >
> > > So those interactions should be disaled by rc variables...  Or we should
> > > be failing the operation...
> >
> > Going multi-user should not be stopped by any of the rc scripts
> > failing due to lack of /dev. But since most developers will only
> > test with /dev available, there is a risk that changes to rc files
> > will not gracefully handle a missing /dev.
> >
> 
> I was under the impression from previous reading and kib's response
> that this is a complete non-issue, there's no way you can go
> multi-user without a mounted /dev and we go to somewhat great lengths
> to make sure we're good.

Though kib can assert that, it does not change the fact that I
frequently find /dev/null FILES on unmounted root file systems.

But lets not mix the 2 separate things of boot time /dev dependency
and build time /dev dependency.

> 
> I agree with the previous goal of ripping the /dev dependency out of
> the build, but this is also much, much easier said than done.
> 

So we agree that it might be a good idea to reduce /dev
dependency in the build process.


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365643 - head/bin/cp

[Rodney W. Grimes]

> Am 24.09.20 um 08:54 schrieb Warner Losh:
> > 
> > 
> > On Thu, Sep 24, 2020 at 12:41 AM Stefan Esser  > > wrote:
> > 
> > Am 23.09.20 um 19:23 schrieb Warner Losh> But for this issue, we're not
> > mounting devfs early enough.? We should
> >  > fix that. Removing /dev/null from the boot process likely is
> > never going
> >  > to happen because we use it all over the place to discard output...
> >  > There's ~200 instances of it in the boot rc scripts, so getting
> > rid of
> >  > it there would also be quite the effort, with the same question.
> > 
> > Removal of /dev/null from rc.d scripts should be quite simple,
> > since most cases could just use ">-" (close file descriptor)
> > instead. Other usage could be substituted with ":>" followed
> > by chown.
> > 
> > 
> > So closing fd1 and fd2 doesn't cause them to be available for these 
> > programs to get as an fd on open, causing other issues?
> > 
> > But >- isn't documented in sh(1) as doing the close thing. On a whim I 
> > did the following:
> > $ echo fred >-
> > $ ls -last ./-
> > 4 -rw-r--r-- ?1 imp ?imp ?5 Sep 24 00:50 ./-
> > $ cat ./-
> > fred
> > $
> > which suggests maybe you now have a lot of files named - instead...
> 
> Yes, sorry, please ignore what I wrote - I was thinking of ">&-" of
> course, but that is not gracefully accepted by many commands (they
> are aborted when trying to write to the closed file descriptor).
> 
> I had thought about piping into a command that ignores STDIN, first,
> e.g. "| :", but that generates a SIGPIPE when trying to flush the
> FILE buffer (i.e. after 4 KB, which might be sufficient for most
> cases, but it is not a general solution).
> 
> A program that reads from STDIN and generates no output could be used,
> though, e.g. "| sed d".
> 
> But this would cause lots of extra forked processes and increase the
> start-up time and is not acceptable.

Most of these can be "fixed" by fixing the programs that
fail to be old school friendly.  Ie produce no output
when things are done as they are asked to be done, as
these "noisy" programs are not pipe friendly.  #1 being
sysctl insisting to output what it did, simple fix, add
a -Q to it.

> 
> > but e.g. rc.d/syscons
> > uses ${kbddev} (i.e. /dev/ttyv0) and rc.d/zvol performs swapon
> > on /dev/zvol/${name}, rc.d/random uses /dev/random and so on.
> > 
> > So those interactions should be disaled by rc variables...? Or we should 
> > be failing the operation...
> 
> Going multi-user should not be stopped by any of the rc scripts
> failing due to lack of /dev. But since most developers will only
> test with /dev available, there is a risk that changes to rc files
> will not gracefully handle a missing /dev.

I would argue that a missing /dev is a fatal mutliuser boot
situation for security reasons, and the boot should be stopped
dead in its tracks at the earliest detection.

> 
> > But those further references to /dev nodes will in general be
> > NOPs if /dev is not available (some test for existence of the
> > node they rely on, other just fail trying to access them, but
> > without negative effect on going multi-user).
> > 
> > 
> > Yea, that's more minor, but if /dev/ isn't there, they likely should 
> > fail, or shouldn't proceed... But in a way that allows the rest of the 
> > rc scripts to continue...
> 
> Since the issue of no devfs mounted it not typical, tests will be
> required to prevent regressions. If a failure in such a case stops
> the multi-user start-up, then it will most likely be in situations
> where there is no good way to provide diagnostics (e.g. no console
> that works for user land programs, no known writable file system
> locations, ...).
> 
> Regards, STefan

[ Attachment, skipping... ]

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365643 - head/bin/cp

[Rodney W. Grimes]

> On Thu, Sep 24, 2020 at 12:41 AM Stefan Esser  wrote:
> 
> > Am 23.09.20 um 19:23 schrieb Warner Losh> But for this issue, we're not
> > mounting devfs early enough.  We should
> > > fix that. Removing /dev/null from the boot process likely is never going
> > > to happen because we use it all over the place to discard output...
> > > There's ~200 instances of it in the boot rc scripts, so getting rid of
> > > it there would also be quite the effort, with the same question.
> >
> > Removal of /dev/null from rc.d scripts should be quite simple,
> > since most cases could just use ">-" (close file descriptor)
> > instead. Other usage could be substituted with ":>" followed
> > by chown.
> >
> 
> So closing fd1 and fd2 doesn't cause them to be available for these
> programs to get as an fd on open, causing other issues?
> 
> But >- isn't documented in sh(1) as doing the close thing. On a whim I did
> the following:
> $ echo fred >-
> $ ls -last ./-
> 4 -rw-r--r--  1 imp  imp  5 Sep 24 00:50 ./-
> $ cat ./-
> fred
> $
> which suggests maybe you now have a lot of files named - instead...
> 
> 
> > I'd be willing to generate patches for review, if there is any
> > chance such a change might be accepted into -CURRENT.
> >
> > I could not find any use of /dev/zero,
> 
> 
> Yea, I'd thought we used it in libc, but I can't find any evidence of that
> with grep now that I've gone looking for it. For get that specific one :)
> 
> 
> > but e.g. rc.d/syscons
> > uses ${kbddev} (i.e. /dev/ttyv0) and rc.d/zvol performs swapon
> > on /dev/zvol/${name}, rc.d/random uses /dev/random and so on.
> >
> 
> So those interactions should be disaled by rc variables...  Or we should be
> failing the operation...

I believe there are several cases in the rc scripts of failure
to fail, and I have experinced at least one that left a firewall
wide open that I would of just rather had it fail and drop to
single user.  I have repeatedly heard the argument, "but you
want it to continue so you can get into it"  NO, not if that
failure leads to a security risk.

Most modern systems have out of band management so the story
of "but you cant get to the system if it stops" no longer
holds water with me.

I have worked around these locally.

> 
> > But those further references to /dev nodes will in general be
> > NOPs if /dev is not available (some test for existence of the
> > node they rely on, other just fail trying to access them, but
> > without negative effect on going multi-user).
> >
> 
> Yea, that's more minor, but if /dev/ isn't there, they likely should fail,
> or shouldn't proceed... But in a way that allows the rest of the rc scripts
> to continue...

This notion that "must boot at all cost" leads to security risks.

> Warner
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365643 - head/bin/cp

[Rodney W. Grimes]

> On Wed, Sep 23, 2020 at 11:23:51AM -0600, Warner Losh wrote:
> > On Wed, Sep 23, 2020, 10:56 AM Rodney W. Grimes 
> > wrote:
> > 
> > > > cp is already fixed, people are still feeling the fallout of being
> > > > within those revisions and needing to bootstrap their own cp. We can
> > > > reduce the number of components these invocations rely on trivially to
> > > > shell built-in mechanics, why not do so?
> > >
> > > I would even go further, I would like to see the dependency on
> > > /dev/null removed from the build, and the boot process.
> > >
> > 
> > A worthy goal, but one I'm afraid is out of our reach. A quick grep shows
> > just over 200 instances of /dev/null in the Makefile and mk file (800 if
> > you don't filter Makefile.in and Makefile.am). Maybe a third of those are
> > due to tests and other false positives. It would be quite the effort to
> > eliminate them all. And /dev/tty and /dev/zero likely will be troublesome
> > too, as they are used by running programs.
> > 
> > and how would you throw away output you know is bad / bogus without
> > /dev/null?
> > 
> > >From the build because it means I would no longer have to
> > > mount /dev in my chroots, and from the boot because I
> > > hate to say it, but we often scribble in /dev before
> > > devfs is mounted and if you look at root file systems
> > > mounted on other systems you well often find a /dev/null
> > > FILE that got created during the boot process from a >/dev/null
> > > before devfs was mounted.
> > >
> > 
> > But for this issue, we're not mounting devfs early enough.  We should fix
> > that. Removing /dev/null from the boot process likely is never going to
> > happen because we use it all over the place to discard output... There's
> > ~200 instances of it in the boot rc scripts, so getting rid of it there
> > would also be quite the effort, with the same question.
> I would like to see some evidence for this actually occuring.
> 
> We mount devfs instance before root (yes), to get the device nodes
> available, so we can specify device name for root mount from loader.
> After mounting root we do a rearrangement to move devfs to /dev, which
> is somewhat tricky due to e.g. namecache.
> 
> I do not see how could anything in userspace even touch the underlying
> directory on rootfs of the /dev devfs mount.
> 
> OTOH, it is a usual problem with /tmp getting dirty, and the garbage
> hidden with tmpfs/md UFS mount over /tmp.

I consistantly find a /dev/null FILE on most systems when I take
a volume out of one machine and mount it as a non-boot volume.

I believe you can also see these in the underlying file system
on UFS with dump, or with zfs send.


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r366025 - head/share/man/man9

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: imp
> Date: Tue Sep 22 23:01:53 2020
> New Revision: 366025
> URL: https://svnweb.freebsd.org/changeset/base/366025
> 
> Log:
>   Document devctl_safe_quote_sb
>   
>   This routine centralizes the knowledge needed for properly quoting
>   'value' in all key="value" items that appear in devctl messages.
>   
>   Reviewed by: bcr
>   Differential Revision: https://reviews.freebsd.org/D26520
> 
> Added:
>   head/share/man/man9/devctl_safe_quote_sb.9   (contents, props changed)
> Modified:
>   head/share/man/man9/Makefile
> 
> Modified: head/share/man/man9/Makefile
> ==
> --- head/share/man/man9/Makefile  Tue Sep 22 23:01:44 2020
> (r366024)
> +++ head/share/man/man9/Makefile  Tue Sep 22 23:01:53 2020
> (r366025)
> @@ -122,6 +122,8 @@ MAN=  accept_filter.9 \
>   DEV_MODULE.9 \
>   dev_refthread.9 \
>   devctl_process_running.9 \
> + devctl_safe_quote_sb.9 \
> + devctl_
>   devstat.9 \
>   devtoname.9 \
>   disk.9 \
> 
> Added: head/share/man/man9/devctl_safe_quote_sb.9
> ==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ head/share/man/man9/devctl_safe_quote_sb.9Tue Sep 22 23:01:53 
> 2020(r366025)
> @@ -0,0 +1,57 @@
> +.\"
> +.\" Copyright (c) 2020 M Warner Losh
> +.\"
> +.\" This program is free software.

Where is this line suddenly coming from?

> +.\"
> +.\" Redistribution and use in source and binary forms, with or without
> +.\" modification, are permitted provided that the following conditions
> +.\" are met:
> +.\" 1. Redistributions of source code must retain the above copyright
> +.\"notice, this list of conditions and the following disclaimer.
> +.\" 2. Redistributions in binary form must reproduce the above copyright
> +.\"notice, this list of conditions and the following disclaimer in the
> +.\"documentation and/or other materials provided with the distribution.
> +.\"
> +.\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR
> +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> +.\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT,
> +.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> +.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> +.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> +.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> +.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> +.\"
> +.\" $FreeBSD$
> +.\"
> +.Dd September 22, 2020
> +.Dt DEVCTL_SAFE_QUOTE_SB 9
> +.Os
> +.Sh NAME
> +.Nm devctl_safe_quote_sb
> +.Nd Insert a string, properly quoted, into a sbuf
> +.Sh SYNOPSIS
> +.In sys/devctl.h
> +.In sys/sbuf.h
> +.Ft void
> +.Fn devctl_safe_quote_sb "struct sbuf *sb" "const char *src"
> +.Sh DESCRIPTION
> +Copy the string from
> +.Vn src
> +into
> +.Vn sb .
> +All backslash characters are doubled.
> +All double quote characters
> +.Sq "
> +are also preceded by a backslash.
> +All other characters are copied without modification.
> +The
> +.Xr devctl 4
> +protocol requires quoted string to be quoted thus.
> +This routine centralizes this knowledge.
> +.Sh SEE ALSO
> +.Xr devd 8
> +.Sh AUTHORS
> +This manual page was written by
> +.An M. Warner Losh
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365643 - head/bin/cp

[Rodney W. Grimes]

> cp is already fixed, people are still feeling the fallout of being
> within those revisions and needing to bootstrap their own cp. We can
> reduce the number of components these invocations rely on trivially to
> shell built-in mechanics, why not do so?

I would even go further, I would like to see the dependency on
/dev/null removed from the build, and the boot process.

>From the build because it means I would no longer have to
mount /dev in my chroots, and from the boot because I
hate to say it, but we often scribble in /dev before
devfs is mounted and if you look at root file systems
mounted on other systems you well often find a /dev/null
FILE that got created during the boot process from a >/dev/null
before devfs was mounted.

> 
> On Tue, Sep 22, 2020 at 4:40 PM Warner Losh  wrote:
> >
> > So why do we need a workaround at all? cp /dev/null has been fixed, and 
> > that's way more important to get right.
> >
> > I don't want to paper-over issues with this at all, though if we use the 
> > host's (now broken) cp, I suppose that might be OK in the short term. If 
> > that's the case, then maybe this is OK.
> >
> > Otherwise, I'd strongly prefer we fix cp.
> >
> > Warner
> >
> > On Tue, Sep 22, 2020 at 3:31 PM Alan Somers  wrote:
> >>
> >> +1.
> >>
> >> On Tue, Sep 22, 2020 at 3:27 PM Kyle Evans  wrote:
> >>>
> >>> I'm running a build at the suggestion of mjg to confirm there aren't
> >>> any others hiding that can be converted, and I will commit after I've
> >>> verified that this is it.
> >>>
> >>> On Tue, Sep 22, 2020 at 4:02 PM Alan Somers  wrote:
> >>> >
> >>> > LGTM.
> >>> >
> >>> > On Tue, Sep 22, 2020 at 2:59 PM Kyle Evans  wrote:
> >>> >>
> >>> >> Perhaps:
> >>> >>
> >>> >> diff --git a/stand/i386/zfsboot/Makefile b/stand/i386/zfsboot/Makefile
> >>> >> index ff315abc0ef..7e362b43a39 100644
> >>> >> --- a/stand/i386/zfsboot/Makefile
> >>> >> +++ b/stand/i386/zfsboot/Makefile
> >>> >> @@ -81,7 +81,7 @@ zfsboot.ld: zfsboot.ldr zfsboot.bin ${BTXKERN}
> >>> >> -o ${.TARGET} -P 1 zfsboot.bin
> >>> >>
> >>> >>  zfsboot.ldr:
> >>> >> -   cp /dev/null ${.TARGET}
> >>> >> +   :> ${.TARGET}
> >>> >>
> >>> >>  zfsboot.bin: zfsboot.out
> >>> >> ${OBJCOPY} -S -O binary zfsboot.out ${.TARGET}
> >>> >> diff --git a/stand/libsa/Makefile b/stand/libsa/Makefile
> >>> >> index effece9e01b..63cd46a9c54 100644
> >>> >> --- a/stand/libsa/Makefile
> >>> >> +++ b/stand/libsa/Makefile
> >>> >> @@ -122,7 +122,7 @@ beforedepend:
> >>> >> ln -sf ${SRCTOP}/include/arpa/inet.h arpa/inet.h; \
> >>> >> ln -sf ${SRCTOP}/include/arpa/tftp.h arpa/tftp.h; \
> >>> >> for i in _time.h _strings.h _string.h; do \
> >>> >> -   [ -f xlocale/$$i ] || cp /dev/null xlocale/$$i; \
> >>> >> +   [ -f xlocale/$$i ] || :> xlocale/$$i; \
> >>> >> done; \
> >>> >> for i in ${STAND_H_INC}; do \
> >>> >> ln -sf ${SASRC}/stand.h $$i; \
> >>> >>
> >>> >>
> >>> >> On Tue, Sep 22, 2020 at 3:58 PM Alan Somers  
> >>> >> wrote:
> >>> >> >
> >>> >> > Looks like two places in stand.  Is there any reason why Mateusz's 
> >>> >> > suggestion wouldn't work?
> >>> >> >
> >>> >> > > rg -g Makefile 'cp.*/dev/null'
> >>> >> > stand/libsa/Makefile
> >>> >> > 125: [ -f xlocale/$$i ] || cp /dev/null xlocale/$$i; \
> >>> >> >
> >>> >> > stand/i386/zfsboot/Makefile
> >>> >> > 82: cp /dev/null ${.TARGET}
> >>> >> >
> >>> >> > On Tue, Sep 22, 2020 at 2:54 PM Mateusz Guzik  
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> Can we instead add a workaround to the build tree?
> >>> >> >>
> >>> >> >> Where is cp /dev/null coming from anyway? Perhaps this can be 
> >>> >> >> patched
> >>> >> >> to touch the target file.
> >>> >> >>
> >>> >> >> On 9/22/20, Alan Somers  wrote:
> >>> >> >> > On Tue, Sep 22, 2020 at 2:48 PM Kyle Evans  
> >>> >> >> > wrote:
> >>> >> >> >
> >>> >> >> >> On Fri, Sep 11, 2020 at 3:49 PM Alan Somers 
> >>> >> >> >>  wrote:
> >>> >> >> >> >
> >>> >> >> >> > Author: asomers
> >>> >> >> >> > Date: Fri Sep 11 20:49:36 2020
> >>> >> >> >> > New Revision: 365643
> >>> >> >> >> > URL: https://svnweb.freebsd.org/changeset/base/365643
> >>> >> >> >> >
> >>> >> >> >> > Log:
> >>> >> >> >> >   cp: fall back to read/write if copy_file_range fails
> >>> >> >> >> >
> >>> >> >> >> >   Even though copy_file_range has a file-system agnostic 
> >>> >> >> >> > version, it
> >>> >> >> >> still
> >>> >> >> >> >   fails on devfs (perhaps because the file descriptor is 
> >>> >> >> >> > non-seekable?)
> >>> >> >> >> In
> >>> >> >> >> >   that case, fallback to old-fashioned read/write. Fixes
> >>> >> >> >> >   "cp /dev/null /tmp/null"
> >>> >> >> >> >
> >>> >> >> >>
> >>> >> >> >> Hi,
> >>> >> >> >>
> >>> >> >> >> Any objection to adding a quick UPDATING entry for this? I'm 
> >>> >> >> >> seeing
> >>> >> >> >> occasional reports of this breakage as recent as today on IRC 
> >>> >> >> >> from
> >>> >> >> >> folks that were a little bit thrown off by this because it 
> 

Re: svn commit: r365836 - head/share/mk

[Rodney W. Grimes]

> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso  wrote:
> 
> > Alex Richardson wrote in
> >  <202009171507.08hf7qns080...@repo.freebsd.org>:
> >  |Author: arichardson
> >  |Date: Thu Sep 17 15:07:25 2020
> >  |New Revision: 365836
> >  |URL: https://svnweb.freebsd.org/changeset/base/365836
> >  |
> >  |Log:
> >  |  Stop using lorder and ranlib when building libraries
> >  |
> >  |  Use of ranlib or lorder is no longer necessary with current linkers
> >  |  (probably anything newer than ~1990) and ar's ability to create an
> > object
> >  |  index and symbol table in the archive.
> >  |  Currently the build system uses lorder+tsort to sort the .o files in
> >  |  dependency order so that a single-pass linker can use them. However,
> >  |  we can use the -s flag to ar to add an index to the .a file which makes
> >  |  lorder unnecessary.
> >  |  Running ar -s is equivalent to running ranlib afterwards, so we can
> > also
> >  |  skip the ranlib invocation.
> >
> > That ranlib thing yes (for long indeed), but i have vague memories
> > that the tsort/lorder ordering was also meant to keep the things
> > which heavily interdepend nearby each other.  (Luckily Linux
> > always had at least tsort available.)
> > This no longer matters for all the platforms FreeBSD supports?
> >
> 
> tsort has no notion of how dependent the modules are, just an order that
> allows a single pass through the .a file (otherwise you'd need to list the
> .a file multiple times on the command line absent ranlib). That's the
> original purpose of tsort. tsort, lsort, and ranlib all arrived in 7th
> edition unix on a PDP-11, where size was more important than proximity to
> locations (modulo overlays, which this doesn't affect at all).
> 
> There were some issues of long vs short jumps on earlier architectures that
> this helped (since you could only jump 16MB, for example). However, there
> were workarounds for this issue on those platforms too. And if you have a
> program that this does make a difference, then you can still use
> tsort/lorder. They are still in the system.
> 
> I doubt you could measure a difference here today. I doubt, honestly, that
> anybody will notice at all.

The x86 archicture has relative jmps of differning lengths, even in long mode
there is support for rel8 and rel32.

> 
> Warner

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r364989 - head/sys/dev/jedec_dimm

[Rodney W. Grimes]

> On 31/08/2020 18:03, Eric van Gyzen wrote:
> > Author: vangyzen
> > Date: Mon Aug 31 15:03:23 2020
> > New Revision: 364989
> > URL: https://svnweb.freebsd.org/changeset/base/364989
> > 
> > Log:
> >   jedec_dimm: fix array overrun
> >   
> >   Coverity detected the overrunning of sc->part_str.
> >   
> >   Submitted by: bret_ketc...@dell.com
> >   Reported by:  Coverity
> >   MFC after:2 weeks
> >   Sponsored by: Dell EMC Isilon
> >   Differential Revision:https://reviews.freebsd.org/D26145
> > 
> > Modified:
> >   head/sys/dev/jedec_dimm/jedec_dimm.c
> > 
> > Modified: head/sys/dev/jedec_dimm/jedec_dimm.c
> > ==
> > --- head/sys/dev/jedec_dimm/jedec_dimm.cMon Aug 31 14:47:23 2020
> > (r364988)
> > +++ head/sys/dev/jedec_dimm/jedec_dimm.cMon Aug 31 15:03:23 2020
> > (r364989)
> > @@ -795,7 +795,7 @@ jedec_dimm_field_to_str(struct jedec_dimm_softc *sc, c
> >  
> > /* If we're dealing with ASCII, convert trailing spaces to NULs. */
> > if (ascii) {
> > -   for (i = dstsz; i > 0; i--) {
> > +   for (i = dstsz - 1; i > 0; i--) {
> 
> If 'i' is an index into the array, then shouldn't the condition be 
> greater-equal?

Looks that way to me too, and this corner case only occurs
if the string is all spaces, which is probably rare but may exist.

> 
> 
> > if (dst[i] == ' ') {
> > dst[i] = 0;
> > } else if (dst[i] == 0) {
> > 
> 
> 
> -- 
> Andriy Gapon
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r364321 - head/sbin/ipfw

[Rodney W. Grimes]

> Hrm, it seems this reply ended up in my spam folder; sorry for not
> replying until now.

lol Oh, bad filter :-)

> > >   *strchr(timestr, '\n') = '\0';
> > >   bprintf(bp, "%s ", timestr);
> >^ Isnt this the +1 space?
> >
> > >   } else {
> > > - bprintf(bp, "%*s", twidth, " ");
> > > + bprintf(bp, "%*s", twidth + 1, " ");
> > ^missing from this string?
> 
> Inserting an extra space in the format string would also work, sure. I
> considered doing it that way but in the end decided it's not
> materially more clear one way or another, so used the patch as
> submitted.

For me the + 1 leads to a "why is this here", where as the space
in the format string clearly matches the other condition of the else.
Also + 1 causes a run time computation, the extra space does not.


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r364430 - in head: share/man/man4 sys/dev/an sys/dev/ata sys/dev/cmx sys/dev/fdc sys/dev/if_ndis sys/dev/puc sys/dev/uart sys/dev/wi sys/netgraph/bluetooth/drivers/bt3c

[Rodney W. Grimes]

> Author: imp
> Date: Thu Aug 20 17:19:40 2020
> New Revision: 364430
> URL: https://svnweb.freebsd.org/changeset/base/364430
> 
> Log:
>   Tag pccard drivers with gone in 13.
>   
>   MFC After: 3 days
>   Reviewed by: emaste, brooks, adrian (on twitter)
>   Differential Revision: https://reviews.freebsd.org/D26095
> 
> Modified:
>   head/share/man/man4/an.4

This device has a PCI version, so why is it going away with PC card?
Typically these are plx9050 bridge cards which makes the AN device
appear like any other PCI device.

It looks as if you only tagged if_an_pccard.c, so the man page
change is all that is wrong.

>   head/share/man/man4/ata.4
>   head/share/man/man4/cmx.4
>   head/share/man/man4/fdc.4
>   head/share/man/man4/ndis.4
>   head/share/man/man4/ng_bt3c.4
>   head/share/man/man4/pccard.4
>   head/share/man/man4/puc.4
>   head/share/man/man4/uart.4
>   head/share/man/man4/wi.4

These are also often plx9050 based, and your only doing
the if_wi_pccard.c file, so probably also a man page error.


>   head/sys/dev/an/if_an_pccard.c
>   head/sys/dev/ata/ata-card.c
>   head/sys/dev/cmx/cmx_pccard.c
>   head/sys/dev/fdc/fdc_pccard.c
>   head/sys/dev/if_ndis/if_ndis_pccard.c
>   head/sys/dev/puc/puc_pccard.c
>   head/sys/dev/uart/uart_bus_pccard.c
>   head/sys/dev/wi/if_wi_pccard.c
>   head/sys/netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c
> 
> Modified: head/share/man/man4/an.4
> ==
> --- head/share/man/man4/an.4  Thu Aug 20 17:14:44 2020(r364429)
> +++ head/share/man/man4/an.4  Thu Aug 20 17:19:40 2020(r364430)
> @@ -51,6 +51,9 @@ module at boot time, place the following line in
>  .Bd -literal -offset indent
>  if_an_load="YES"
>  .Ed
> +.Sh DEPRECATION NOTICE
> +This driver is scheduled for removal prior to the release of
> +.Fx 13.0
>  .Sh DESCRIPTION
>  The
>  .Nm
> 
> Modified: head/share/man/man4/ata.4
> ==
> --- head/share/man/man4/ata.4 Thu Aug 20 17:14:44 2020(r364429)
> +++ head/share/man/man4/ata.4 Thu Aug 20 17:19:40 2020(r364430)
> @@ -222,6 +222,9 @@ Unknown ATA chipsets are supported in PIO modes, and i
>  busmaster DMA registers are present and contain valid setup, DMA is
>  also enabled, although the max mode is limited to UDMA33, as it is
>  not known what the chipset can do and how to program it.
> +.Sh DEPRECATION NOTICE
> +The PC Card attachment of this driver is scheduled for removal prior to the 
> release of
> +.Fx 13.0
>  .Sh NOTES
>  Please remember that in order to use UDMA4/ATA66 and above modes you
>  .Em must
> 
> Modified: head/share/man/man4/cmx.4
> ==
> --- head/share/man/man4/cmx.4 Thu Aug 20 17:14:44 2020(r364429)
> +++ head/share/man/man4/cmx.4 Thu Aug 20 17:19:40 2020(r364430)
> @@ -34,6 +34,9 @@
>  .Nd Omnikey CardMan 4040 smartcard reader device driver
>  .Sh SYNOPSIS
>  .Cd device cmx
> +.Sh DEPRECATION NOTICE
> +This driver is scheduled for removal prior to the release of
> +.Fx 13.0
>  .Sh DESCRIPTION
>  The
>  .Nm
> 
> Modified: head/share/man/man4/fdc.4
> ==
> --- head/share/man/man4/fdc.4 Thu Aug 20 17:14:44 2020(r364429)
> +++ head/share/man/man4/fdc.4 Thu Aug 20 17:19:40 2020(r364430)
> @@ -313,6 +313,9 @@ Third argument is a pointer to
>  This type is the same as being used in the per-drive configuration
>  flags, or in the CMOS configuration data or ACPI namespace on IA32 systems.
>  .El
> +.Sh DEPRECATION NOTICE
> +The PC Card attachment of this driver is scheduled for removal prior to the 
> release of
> +.Fx 13.0
>  .Sh FILES
>  .Bl -tag -width ".Pa /dev/fd*" -compact
>  .It Pa /dev/fd*
> 
> Modified: head/share/man/man4/ndis.4
> ==
> --- head/share/man/man4/ndis.4Thu Aug 20 17:14:44 2020
> (r364429)
> +++ head/share/man/man4/ndis.4Thu Aug 20 17:19:40 2020
> (r364430)
> @@ -120,6 +120,9 @@ driver-specific registry keys to control the media set
>  which can be configured via the
>  .Xr sysctl 8
>  command.
> +.Sh DEPRECATION NOTICE
> +The PC Card attachment of this driver is scheduled for removal prior to the 
> release of
> +.Fx 13.0
>  .Sh DIAGNOSTICS
>  .Bl -diag
>  .It "ndis%d: watchdog timeout"
> 
> Modified: head/share/man/man4/ng_bt3c.4
> ==
> --- head/share/man/man4/ng_bt3c.4 Thu Aug 20 17:14:44 2020
> (r364429)
> +++ head/share/man/man4/ng_bt3c.4 Thu Aug 20 17:19:40 2020
> (r364430)
> @@ -34,6 +34,9 @@
>  .Sh SYNOPSIS
>  .In sys/types.h
>  .In netgraph/bluetooth/include/ng_bt3c.h
> +.Sh DEPRECATION NOTICE
> +This driver is scheduled for removal prior to the release of
> 

Re: svn commit: r364336 - in head: share/man/man4 sys/dev/pccard

[Rodney W. Grimes]

> Author: imp
> Date: Tue Aug 18 06:18:18 2020
> New Revision: 364336
> URL: https://svnweb.freebsd.org/changeset/base/364336
> 
> Log:
>   Document that PC Card will likely be removed before 13.
>   
>   This was discussed in arch@ a while ago. Most of the 16-bit drivers that it
>   relied on have been removed. There's only a few other drivers remaining that
>   support it, and those are very rare the days (even the once ubiquitious 
> wi(1)
>   is now quite rare).
>   
>   Indvidual drivers will be handled separately before pccard itself is 
> removed.

MFC?  I assume you plan to merge this to stable/12?

> Modified:
>   head/share/man/man4/pccard.4
>   head/sys/dev/pccard/pccard.c
> 
> Modified: head/share/man/man4/pccard.4
> ==
> --- head/share/man/man4/pccard.4  Tue Aug 18 06:07:34 2020
> (r364335)
> +++ head/share/man/man4/pccard.4  Tue Aug 18 06:18:18 2020
> (r364336)
> @@ -23,7 +23,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd July 9, 2002
> +.Dd August 18, 2020
>  .Dt PCCARD 4
>  .Os
>  .Sh NAME
> @@ -31,6 +31,9 @@
>  .Nd PC Card bus driver
>  .Sh SYNOPSIS
>  .Cd device pccard
> +.Sh DEPRECATION NOTICE
> +This driver is scheduled for removal prior to the release of
> +.Fx 13.0
>  .Sh DESCRIPTION
>  The
>  .Nm
> 
> Modified: head/sys/dev/pccard/pccard.c
> ==
> --- head/sys/dev/pccard/pccard.c  Tue Aug 18 06:07:34 2020
> (r364335)
> +++ head/sys/dev/pccard/pccard.c  Tue Aug 18 06:18:18 2020
> (r364336)
> @@ -845,6 +845,7 @@ pccard_attach(device_t dev)
>   sc->sc_enabled_count = 0;
>   if ((err = pccard_device_create(sc)) != 0)
>   return  (err);
> + gone_in(13, "PC Card to be removed.");
>   STAILQ_INIT(>card.pf_head);
>   return (bus_generic_attach(dev));
>  }
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r364321 - head/sbin/ipfw

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: emaste
> Date: Mon Aug 17 18:53:23 2020
> New Revision: 364321
> URL: https://svnweb.freebsd.org/changeset/base/364321
> 
> Log:
>   ipfw: line up `ipfw -t list` with and without timestamp
>   
>   From the PR:
>   When I run `ipfw -t list` on release/12 or current, I get misaligned
>   output between lines that do and do not have a last match timestamp,
>   like so:
>   
>   00100 Tue Aug 11 03:03:26 2020 allow ip from any to any via lo0
>   00200 deny ip from any to 127.0.0.0/8
>   
>   (specifically, the "allow" and "deny" strings do not line up)
>   
>   PR: 248608
>   Submitted by:   Taylor Stearns
>   MFC after:  3 days
> 
> Modified:
>   head/sbin/ipfw/ipfw2.c
> 
> Modified: head/sbin/ipfw/ipfw2.c
> ==
> --- head/sbin/ipfw/ipfw2.cMon Aug 17 17:48:28 2020(r364320)
> +++ head/sbin/ipfw/ipfw2.cMon Aug 17 18:53:23 2020(r364321)
> @@ -2199,7 +2199,7 @@ show_static_rule(struct cmdline_opts *co, struct forma
>   *strchr(timestr, '\n') = '\0';
>   bprintf(bp, "%s ", timestr);
   ^ Isnt this the +1 space?

>   } else {
> - bprintf(bp, "%*s", twidth, " ");
> + bprintf(bp, "%*s", twidth + 1, " ");
^missing from this string?
>   }
>   }
>  
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r364236 - svnadmin/conf

[Rodney W. Grimes]

Author: rgrimes
Date: Fri Aug 14 16:44:10 2020
New Revision: 364236
URL: https://svnweb.freebsd.org/changeset/base/364236

Log:
  Release rscheff from mentorship.

Modified:
  svnadmin/conf/mentors

Modified: svnadmin/conf/mentors
==
--- svnadmin/conf/mentors   Fri Aug 14 14:50:41 2020(r364235)
+++ svnadmin/conf/mentors   Fri Aug 14 16:44:10 2020(r364236)
@@ -22,7 +22,6 @@ mjorasrstone
 nick   philip  Co-mentor: kp
 ramken Co-mentor: mav
 rewkevans  Co-mentor: allanjude
-rschefftuexen  Co-mentor: rgrimes
 scottphscottl  Co-mentor: emaste, jhb
 thjjtl Co-mentor: bz
 wosch  cem
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r364221 - in head/lib/libbsnmp: . tests

[Rodney W. Grimes]

> Author: bdrewery
> Date: Thu Aug 13 22:42:24 2020
> New Revision: 364221
> URL: https://svnweb.freebsd.org/changeset/base/364221
> 
> Log:
>   Add test to for FreeBSD-SA-19:20.bsnmp
>   
>   Submitted by:   Darrick Lew 
>   Reviewed by:cem
>   Sponsored by:   Dell EMC
>   Differential Revision:  https://reviews.freebsd.org/D26037
> 
> Added:
>   head/lib/libbsnmp/tests/
>   head/lib/libbsnmp/tests/Makefile   (contents, props changed)
>   head/lib/libbsnmp/tests/bsnmpd_test.c   (contents, props changed)
> Modified:
>   head/lib/libbsnmp/Makefile
> 
> Modified: head/lib/libbsnmp/Makefile
> ==
> --- head/lib/libbsnmp/MakefileThu Aug 13 22:06:27 2020
> (r364220)
> +++ head/lib/libbsnmp/MakefileThu Aug 13 22:42:24 2020
> (r364221)
> @@ -1,5 +1,6 @@
>  # $FreeBSD$
>  
>  SUBDIR=  libbsnmp
> +SUBDIR.${MK_TESTS}+= tests
>  
>  .include 
> 
> Added: head/lib/libbsnmp/tests/Makefile
> ==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ head/lib/libbsnmp/tests/Makefile  Thu Aug 13 22:42:24 2020
> (r364221)
> @@ -0,0 +1,11 @@
> +# $FreeBSD$
> +
> +.include 
> +
> +ATF_TESTS_C+=bsnmpd_test
> +
> +SRCS.bsmpd_test= bsnmpd_test.c
> +
> +LIBADD+= bsnmp
> +
> +.include 
> 
> Added: head/lib/libbsnmp/tests/bsnmpd_test.c
> ==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ head/lib/libbsnmp/tests/bsnmpd_test.c Thu Aug 13 22:42:24 2020
> (r364221)
> @@ -0,0 +1,53 @@
> +/*-
> + * Copyright (c) 2020 Dell EMC
> + * All rights reserved.

I am not sure where your copying the copyright from, but in all known
in tree templates the "All rights reserved." line has been removed.

Your probably just copying it from another file perhaps?
Or is this something Dell/Emc is requireing?

> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + *
> + * $FreeBSD$
> + */
> +
> +#include 
> +
> +#include 
> +
> +ATF_TC_WITHOUT_HEAD(sa_19_20_bsnmp_test);
> +ATF_TC_BODY(sa_19_20_bsnmp_test, tc)
> +{
> + struct asn_buf b = {};
> + char test_buf[] = { 0x25, 0x7f };
> + enum asn_err err;
> + asn_len_t len;
> + u_char type;
> +
> + b.asn_cptr = test_buf;
> + b.asn_len = sizeof(test_buf);
> +
> + err = asn_get_header(, , );
> + ATF_CHECK_EQ(ASN_ERR_EOBUF, err);
> +}
> +
> +ATF_TP_ADD_TCS(tp)
> +{
> + ATF_TP_ADD_TC(tp, sa_19_20_bsnmp_test);
> + return (atf_no_error());
> +}
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r364190 - head/tools/build

[Rodney W. Grimes]

> Author: arichardson
> Date: Thu Aug 13 14:14:46 2020
> New Revision: 364190
> URL: https://svnweb.freebsd.org/changeset/base/364190
> 
> Log:
>   Add pwd to the list of tools that are linked to $WORLDTMP/legacy

Since "sh" is already in this list, and our "sh" has a builtin pwd
that does the correct thing with pwd -P this should not be needed.

Or are we contininue to use the host "sh" for far too long?

For me from ancient days of hand bootstrapping BSD sources onto
another system sh(1) and make(1) are the first 2 tools to get
working.

>   After r364166 and r364174, crunchgen needs a pwd binary in $PATH instead
>   of using a hardcoded absolute path. This commit is needed for
>   BUILD_WITH_STRICT_TMPPATH builds (currently not on by default).
> 
> Modified:
>   head/tools/build/Makefile
> 
> Modified: head/tools/build/Makefile
> ==
> --- head/tools/build/Makefile Thu Aug 13 13:59:31 2020(r364189)
> +++ head/tools/build/Makefile Thu Aug 13 14:14:46 2020(r364190)
> @@ -113,8 +113,8 @@ SYSINCS+= ${SRCTOP}/sys/sys/font.h
>  # Linux/MacOS since we only use flags that are supported by all of them.
>  _host_tools_to_symlink=  basename bzip2 bunzip2 chmod chown cmp comm cp 
> date dd \
>   dirname echo env false find fmt gzip gunzip head hostname id ln ls \
> - mkdir mv nice patch rm realpath sh sleep stat tee touch tr true uname \
> - uniq wc which
> + mkdir mv nice patch pwd rm realpath sh sleep stat tee touch tr true \
> + uname uniq wc which
>  
>  # We also need a symlink to the absolute path to the make binary used for
>  # the toplevel makefile. This is not necessarily the same as `which make`
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r364166 - head/usr.sbin/crunch/crunchgen

[Rodney W. Grimes]

> On 12 Aug 2020, at 17:10, Rodney W. Grimes  wrote:
> > 
> >> Author: arichardson
> >> Date: Wed Aug 12 15:49:06 2020
> >> New Revision: 364166
> >> URL: https://svnweb.freebsd.org/changeset/base/364166
> >> 
> >> Log:
> >>  Fix crunchgen usage of mkstemp()
> >> 
> >>  On Glibc systems mkstemp can only be used once with the same template
> >>  string since it will be modified in-place and no longer contain any 'X' 
> >> chars.
> >>  It is fine to reuse the same file here but we need to be explicit and use
> >>  open() instead of mkstemp() on the second use.
> >> 
> >>  While touching this file also avoid a hardcoded /bin/pwd since that may 
> >> not
> >>  work when building on non-FreeBSD systems.
> > 
> > This may cause some grief, as now pwd may use a shell builtin
> > and often shell builtin's return a cwd that is not a true
> > full path, ie it may contain symlink compontents in the
> > path.
> > 
> > /bin/sh:
> > 
> > # cd /tmp/b
> > # /bin/pwd
> > /tmp/a
> > # pwd
> > /tmp/b
> > # ls -lag /tmp/?
> > lrwxr-xr-x  1 root  wheel  1 Aug 12 16:06 /tmp/b -> a
> > 
> > /tmp/a:
> > total 17
> > drwxr-xr-x   2 root  wheel2 Aug 12 16:06 .
> > drwxrwxrwt  18 root  wheel  248 Aug 12 16:06 ..
> 
> There's the question of whether that really matters; both values are in
> some sense correct. But if you want to restore the old behaviour, I
> believe `env pwd` is the portable way to do so?

You have cut the context, but the code has a comment that
states it is doing this to remove symbolic links, so this
change infact undoes something that was being done intentionally.

I do believe also that a "env pwd" would do the right thing
as well.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r364166 - head/usr.sbin/crunch/crunchgen

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: arichardson
> Date: Wed Aug 12 15:49:06 2020
> New Revision: 364166
> URL: https://svnweb.freebsd.org/changeset/base/364166
> 
> Log:
>   Fix crunchgen usage of mkstemp()
>   
>   On Glibc systems mkstemp can only be used once with the same template
>   string since it will be modified in-place and no longer contain any 'X' 
> chars.
>   It is fine to reuse the same file here but we need to be explicit and use
>   open() instead of mkstemp() on the second use.
>   
>   While touching this file also avoid a hardcoded /bin/pwd since that may not
>   work when building on non-FreeBSD systems.

This may cause some grief, as now pwd may use a shell builtin
and often shell builtin's return a cwd that is not a true
full path, ie it may contain symlink compontents in the
path.

/bin/sh:

# cd /tmp/b
# /bin/pwd
/tmp/a
# pwd
/tmp/b
# ls -lag /tmp/?
lrwxr-xr-x  1 root  wheel  1 Aug 12 16:06 /tmp/b -> a

/tmp/a:
total 17
drwxr-xr-x   2 root  wheel2 Aug 12 16:06 .
drwxrwxrwt  18 root  wheel  248 Aug 12 16:06 ..

>   
>   Reviewed By:brooks
>   Differential Revision: https://reviews.freebsd.org/D25990
> 
> Modified:
>   head/usr.sbin/crunch/crunchgen/crunchgen.c
> 
> Modified: head/usr.sbin/crunch/crunchgen/crunchgen.c
> ==
> --- head/usr.sbin/crunch/crunchgen/crunchgen.cWed Aug 12 14:45:31 
> 2020(r364165)
> +++ head/usr.sbin/crunch/crunchgen/crunchgen.cWed Aug 12 15:49:06 
> 2020(r364166)
> @@ -39,10 +39,13 @@ __FBSDID("$FreeBSD$");
>  
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #define CRUNCH_VERSION   "0.2"
> @@ -91,6 +94,7 @@ prog_t   *progs = NULL;
>  char confname[MAXPATHLEN], infilename[MAXPATHLEN];
>  char outmkname[MAXPATHLEN], outcfname[MAXPATHLEN], execfname[MAXPATHLEN];
>  char tempfname[MAXPATHLEN], cachename[MAXPATHLEN], curfilename[MAXPATHLEN];
> +bool tempfname_initialized = false;
>  char outhdrname[MAXPATHLEN] ;/* user-supplied header for *.mk */
>  char *objprefix; /* where are the objects ? */
>  char *path_make;
> @@ -216,6 +220,7 @@ main(int argc, char **argv)
>   snprintf(cachename, sizeof(cachename), "%s.cache", confname);
>   snprintf(tempfname, sizeof(tempfname), "%s/crunchgen_%sXX",
>   getenv("TMPDIR") ? getenv("TMPDIR") : _PATH_TMP, confname);
> + tempfname_initialized = false;
>  
>   parse_conf_file();
>   if (list_mode)
> @@ -648,8 +653,7 @@ fillin_program(prog_t *p)
>  
>   /* Determine the actual srcdir (maybe symlinked). */
>   if (p->srcdir) {
> - snprintf(line, MAXLINELEN, "cd %s && echo -n `/bin/pwd`",
> - p->srcdir);
> + snprintf(line, MAXLINELEN, "cd %s && pwd", p->srcdir);
>   f = popen(line,"r");
>   if (!f)
>   errx(1, "Can't execute: %s\n", line);
> @@ -721,14 +725,26 @@ fillin_program_objs(prog_t *p, char *path)
>  
>   /* discover the objs from the srcdir Makefile */
>  
> - if ((fd = mkstemp(tempfname)) == -1) {
> - perror(tempfname);
> - exit(1);
> + /*
> +  * We reuse the same temporary file name for multiple objects. However,
> +  * some libc implementations (such as glibc) return EINVAL if there
> +  * are no X characters in the template. This happens after the
> +  * first call to mkstemp since the argument is modified in-place.
> +  * To avoid this error we use open() instead of mkstemp() after the
> +  * call to mkstemp().
> +  */
> + if (tempfname_initialized) {
> + if ((fd = open(tempfname, O_CREAT | O_EXCL | O_RDWR, 0600)) == 
> -1) {
> + err(EX_OSERR, "open(%s)", tempfname);
> + }
> + } else if ((fd = mkstemp(tempfname)) == -1) {
> + err(EX_OSERR, "mkstemp(%s)", tempfname);
>   }
> + tempfname_initialized = true;
>   if ((f = fdopen(fd, "w")) == NULL) {
> - warn("%s", tempfname);
> + warn("fdopen(%s)", tempfname);
>   goterror = 1;
> - return;
> + goto out;
>   }
>   if (p->objvar)
>   objvar = p->objvar;
> @@ -763,14 +779,14 @@ fillin_program_objs(prog_t *p, char *path)
>   if ((f = popen(line, "r")) == NULL) {
>   warn("submake pipe");
>   goterror = 1;
> - return;
> + goto out;
>   }
>  
>   while(fgets(line, MAXLINELEN, f)) {
>   if (strncmp(line, "OBJS= ", 6)) {
>   warnx("make error: %s", line);
>   goterror = 1;
> - continue;
> + goto out;
>   }
>  
>   cp = line + 6;
> @@ -793,7 +809,7 @@ fillin_program_objs(prog_t *p, char *path)
>   

Re: svn commit: r364010 - head/sbin/iscontrol

[Rodney W. Grimes]

> Author: manu
> Date: Fri Aug  7 12:19:21 2020
> New Revision: 364010
> URL: https://svnweb.freebsd.org/changeset/base/364010
> 
> Log:
>   pkgbase: We can't easily have a package with either a - or a _

Wow, hopefully this is short term.  I would think a package name can
be any valid file name, and to remove - and _ from that set is going
to cause lots of POLA.

>   
>   Rename iscsi_legacy to iscsilegacy, having - or _ in a package name cause
>   problems when we process them and generate the ucl.
> 
> Modified:
>   head/sbin/iscontrol/Makefile
> 
> Modified: head/sbin/iscontrol/Makefile
> ==
> --- head/sbin/iscontrol/Makefile  Fri Aug  7 10:20:39 2020
> (r364009)
> +++ head/sbin/iscontrol/Makefile  Fri Aug  7 12:19:21 2020
> (r364010)
> @@ -1,6 +1,6 @@
>  # $FreeBSD$
>  
> -PACKAGE=iscsi_legacy
> +PACKAGE=iscsilegacy
>  SRCS= iscontrol.c pdu.c fsm.c config.c login.c auth_subr.c misc.c
>  PROG= iscontrol
>  LIBADD=  cam md
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r363598 - head/usr.sbin/nologin

[Rodney W. Grimes]

> Hi,
> 
> On 7/27/20 7:17 PM, Rodney W. Grimes wrote:
> > On 7/27/20 6:41 PM, Rodney W. Grimes wrote:
> >>>> Author: 0mp (doc,ports committer)
> >>>> Date: Mon Jul 27 10:45:47 2020
> >>>> New Revision: 363598
> >>>> URL: https://svnweb.freebsd.org/changeset/base/363598
> >>>>
> >>>> Log:
> >>>> nologin.8: Improve wording
> >>> I disagree that this improves wording.  The norm of action for
> >>> "logging" in Unix is to "write to syslog", not "log to syslog".
> >> Hmm, I agree, but here it is "log using syslog".
> > Please read syslog(3) it is rather consistent about using
> > "write to syslog".  The action of calling syslog(3) is to
> > "writes message to the system message logger."
> 
> Obviously, we write to syslog but from what I remember the reason why we 
> decided to change the 
> wording to "log using syscall" was that you don't write to the syslog(3) 
> function, but you use it 
> instead.
> 
> >
> >> Have you got any idea how to further improve this sentence?
> > No, but can we not degrade it?
> 
> Sure. Would you like me to just revert it?

Without beter wording that would be easy to do.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r363598 - head/usr.sbin/nologin

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Hi!
> 
> On 7/27/20 6:41 PM, Rodney W. Grimes wrote:
> >> Author: 0mp (doc,ports committer)
> >> Date: Mon Jul 27 10:45:47 2020
> >> New Revision: 363598
> >> URL: https://svnweb.freebsd.org/changeset/base/363598
> >>
> >> Log:
> >>nologin.8: Improve wording
> > I disagree that this improves wording.  The norm of action for
> > "logging" in Unix is to "write to syslog", not "log to syslog".
> 
> Hmm, I agree, but here it is "log using syslog".

Please read syslog(3) it is rather consistent about using
"write to syslog".  The action of calling syslog(3) is to
"writes message to the system message logger."


> 
> Have you got any idea how to further improve this sentence?

No, but can we not degrade it?

> 
> >>Reported by:yuripv
> >>Reviewed by:bcr, yuripv
> >>MFC after:  3 days
> >>Differential Revision:  https://reviews.freebsd.org/D25814
> >>
> >> Modified:
> >>head/usr.sbin/nologin/nologin.8
> >>
> >> Modified: head/usr.sbin/nologin/nologin.8
> >> ==
> >> --- head/usr.sbin/nologin/nologin.8Mon Jul 27 09:10:02 2020
> >> (r363597)
> >> +++ head/usr.sbin/nologin/nologin.8Mon Jul 27 10:45:47 2020
> >> (r363598)
> >> @@ -44,7 +44,7 @@ have been disabled.
> >>   .Pp
> >>   When executed,
> >>   .Nm
> >> -first writes about the login attempt to
> >> +first logs about the login attempt using
> >>   .Xr syslog 3
> >>   and then displays a message that an account is not available.
> >>   .Pp
> 
> Cheers!
> 
> Mateusz Piotrowski
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r363598 - head/usr.sbin/nologin

[Rodney W. Grimes]

> Author: 0mp (doc,ports committer)
> Date: Mon Jul 27 10:45:47 2020
> New Revision: 363598
> URL: https://svnweb.freebsd.org/changeset/base/363598
> 
> Log:
>   nologin.8: Improve wording

I disagree that this improves wording.  The norm of action for
"logging" in Unix is to "write to syslog", not "log to syslog".

>   Reported by:yuripv
>   Reviewed by:bcr, yuripv
>   MFC after:  3 days
>   Differential Revision:  https://reviews.freebsd.org/D25814
> 
> Modified:
>   head/usr.sbin/nologin/nologin.8
> 
> Modified: head/usr.sbin/nologin/nologin.8
> ==
> --- head/usr.sbin/nologin/nologin.8   Mon Jul 27 09:10:02 2020
> (r363597)
> +++ head/usr.sbin/nologin/nologin.8   Mon Jul 27 10:45:47 2020
> (r363598)
> @@ -44,7 +44,7 @@ have been disabled.
>  .Pp
>  When executed,
>  .Nm
> -first writes about the login attempt to
> +first logs about the login attempt using
>  .Xr syslog 3
>  and then displays a message that an account is not available.
>  .Pp
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r363595 - head/sys/kern

[Rodney W. Grimes]

> Hi,
> 
> Helpful addition. Might it help people more to make the message point to the 
> replacement of the deprecated functionality?
> 
> Regards,
> Ronald.

I tend to agree here, the functionality was not depricated,
it was replaced by a new implementation in another language.

It would be better to replace the word deprecated with "replaced
by" as in:
This script has been replaced by makesyscalls.lua and
this version shall be removed in FreeBSD 13.

> 
>  
> Van: Kyle Evans 
> Datum: maandag, 27 juli 2020 05:13
> Aan: src-committ...@freebsd.org, svn-src-all@freebsd.org, 
> svn-src-h...@freebsd.org
> Onderwerp: svn commit: r363595 - head/sys/kern
> > 
> > Author: kevans
> > Date: Mon Jul 27 03:13:23 2020
> > New Revision: 363595
> > URL: https://svnweb.freebsd.org/changeset/base/363595
> > 
> > Log:
> >   makesyscalls.sh: spit out a deprecation notice to stderr
> >   
> >   This has for a while been replaced by makesyscalls.lua in the stock 
> > FreeBSD
> >   build.  Ensure downstreams get some notice that it'a going away if they're
> >   reliant on it, maybe.
> > 
> > Modified:
> >   head/sys/kern/makesyscalls.sh
> > 
> > Modified: head/sys/kern/makesyscalls.sh
> > ==
> > --- head/sys/kern/makesyscalls.sh   Mon Jul 27 01:53:27 2020(r363594)
> > +++ head/sys/kern/makesyscalls.sh   Mon Jul 27 03:13:23 2020(r363595)
> > @@ -60,6 +60,8 @@ case $# in
> > ;;
> >  esac
> >  
> > +1>&2 echo "$0: This script is deprecated and will be removed before 
> > FreeBSD 13."
> > +
> >  if [ -n "$2" ]; then
> > . "$2"
> >  fi
> > ___
> > svn-src-all@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/svn-src-all
> > To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
> > 
> > 
> > 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r363178 - head/contrib/mandoc

[Rodney W. Grimes]

> On Tue, 14 Jul 2020 at 12:47, Rodney W. Grimes
>  wrote:
> >
> > > Author: gbe (doc committer)
> > > Date: Tue Jul 14 12:02:30 2020
> > > New Revision: 363178
> > > URL: https://svnweb.freebsd.org/changeset/base/363178
> > >
> > > Log:
> > >   Revert r362809: Mention FreeBSD in the HISTORY sections of apropos(1) 
> > > and makewhatis(8).
> >
> > Thank you
> 
> This seems like a regression - information about when a certain
> utility (or a different implementation thereof) appeared in FreeBSD
> seems like useful and relevant information.

The only thing that was added, and herein reverted was incorrect
information that apropos and makewhatis first appeared in FreeBSD 11,
conflicting the much richer HISTORY already present in this manual page.

Please read the full manual page and make comments if you then feel they are 
needed.

Why reply to my thank you and not the commit that did the revert?
 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r363178 - head/contrib/mandoc

[Rodney W. Grimes]

> Author: gbe (doc committer)
> Date: Tue Jul 14 12:02:30 2020
> New Revision: 363178
> URL: https://svnweb.freebsd.org/changeset/base/363178
> 
> Log:
>   Revert r362809: Mention FreeBSD in the HISTORY sections of apropos(1) and 
> makewhatis(8).
>   

Thank you

>   We don't mention the first appearance of a utility in FreeBSD, when it first
>   appeared in a BSD version that predates FreeBSD.
>   
>   PR: 223520, 223521
>   Reported by:rgrimes, imp
>   Reviewed by:bcr (mentor)
>   Approved by:bcr (mentor)
>   Differential Revision:  https://reviews.freebsd.org/D25521
> 
> Modified:
>   head/contrib/mandoc/apropos.1
>   head/contrib/mandoc/makewhatis.8
> 
> Modified: head/contrib/mandoc/apropos.1
> ==
> --- head/contrib/mandoc/apropos.1 Tue Jul 14 10:55:19 2020
> (r363177)
> +++ head/contrib/mandoc/apropos.1 Tue Jul 14 12:02:30 2020
> (r363178)
> @@ -15,7 +15,7 @@
>  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  .\"
> -.Dd $Mdocdate: June 30 2020 $
> +.Dd $Mdocdate: November 22 2018 $
>  .Dt APROPOS 1
>  .Os
>  .Sh NAME
> @@ -493,12 +493,6 @@ The options
>  .Fl acfhIKklOTWw
>  appeared in
>  .Ox 5.7 .
> -.Pp
> -The
> -.Nm
> -utility was integrated into
> -.Fx 11.1
> -as part of the switch to mandoc.
>  .Sh AUTHORS
>  .An -nosplit
>  .An Bill Joy
> 
> Modified: head/contrib/mandoc/makewhatis.8
> ==
> --- head/contrib/mandoc/makewhatis.8  Tue Jul 14 10:55:19 2020
> (r363177)
> +++ head/contrib/mandoc/makewhatis.8  Tue Jul 14 12:02:30 2020
> (r363178)
> @@ -15,7 +15,7 @@
>  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  .\"
> -.Dd $Mdocdate: June 30 2020 $
> +.Dd $Mdocdate: May 17 2017 $
>  .Dt MAKEWHATIS 8
>  .Os
>  .Sh NAME
> @@ -211,12 +211,6 @@ and the options
>  .Fl aCDnQT
>  in
>  .Ox 5.6 .
> -.Pp
> -The
> -.Nm
> -utility was integrated into
> -.Fx 11.1
> -as part of the switch to mandoc.
>  .Sh AUTHORS
>  .An -nosplit
>  .An Bill Joy
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362809 - head/contrib/mandoc

[Rodney W. Grimes]

> On Thu, Jul 02, 2020 at 12:06:13AM +, Alexey Dokuchaev wrote:
> > On Wed, Jul 01, 2020 at 05:01:00PM -0700, Rodney W. Grimes wrote:
> > > Thats good, but realize the page already contains history that
> > > reads like:
> > > 
> > > HISTORY
> > >  Part of the functionality of whatis was already provided by the 
> > > former
> > >  manwhere utility in 1BSD. The apropos and whatis utilities first ap-
> > >  peared in 2BSD.  They were rewritten from scratch for OpenBSD 5.6.
> > > 
> > >  The -M option and the MANPATH variable first appeared in 4.3BSD; -m 
> > > in
> > >  4.3BSD-Reno; -C in 4.4BSD Lite1; and -S and -s in OpenBSD 4.5 for 
> > > apropos
> > >  and in OpenBSD 5.6 for whatis.  The options -acfhIKklOTWw appeared in
> > >  OpenBSD 5.7.
> > > 
> > > And further contains:
> > > 
> > > AUTHORS
> > >  Bill Joy wrote manwhere in 1977 and the original BSD apropos and 
> > > whatis
> > >  in February 1979. The current version was written by Kristaps 
> > > Dzonsons
> > >   and Ingo Schwarze .
> > > 
> > > So the history is rich and complete, do we really need to say when we
> > > incorporated this into FreeBSD from OpenBSD's mandoc in the manual page?
> > 
> > Ah, in this case, the only thing lacking from the current version is mention
> > of FreeBSD 11.1.  Sorry for not checking with that before writing my reply.
> > My main point, however, was that reverse chronological order looks strange.
> 
> I have created the following differential and integrated the given feedback.
> 
> https://reviews.freebsd.org/D25566
> 
> If necessary I could revert r362809, but somebody should explicit request it.

Consider it so requested.

> --Gordon
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362809 - head/contrib/mandoc

[Rodney W. Grimes]

> On Wed, Jul 01, 2020 at 11:28:47PM +0200, Gordon Bergling wrote:
> > On Wed, Jul 01, 2020 at 11:58:05AM -0600, Warner Losh wrote:
> > > On Wed, Jul 1, 2020 at 8:51 AM Rodney W. Grimes wrote:
> > > > ...
> > > > We often have "An ls command appeared in Version 1 AT UNIX."  Our 
> > > > source
> > > > code and man page is not from that, but that is the history of ls.
> > > >
> > > > This *could* be amended and *should* be amended to reflect that apropos,
> > > > and makewhatis got *updated* by a switch to the mandoc versions, but it
> > > > is misleading to say it was intergrated with the switch to mandoc as 
> > > > that
> > > > implies it did not exist before this action.
> > > 
> > > I tend to agree with Rod here. These appeared in X the first time, but
> > > noting they were replaced in version X with Y is the best way to address
> > > the current provenance of the code...
> > 
> > OK, I see your arguments. How about the following addition for HISTORY 
> > section,
> > 
> > The apropos utility was integrated into FreeBSD 11.1 as part of the
> > switch to mandoc. Before the switch to mandoc apropos was available since
> > FreeBSD 1.0.
> 
> It should be the other way around:
> 
>   "The apropos utility appeared in FreeBSD 1.0.  Since FreeBSD 11.1
>it is based on mandoc implementation."

Thats good, but realize the page already contains history that
reads like:

HISTORY
 Part of the functionality of whatis was already provided by the former
 manwhere utility in 1BSD. The apropos and whatis utilities first ap-
 peared in 2BSD.  They were rewritten from scratch for OpenBSD 5.6.

 The -M option and the MANPATH variable first appeared in 4.3BSD; -m in
 4.3BSD-Reno; -C in 4.4BSD Lite1; and -S and -s in OpenBSD 4.5 for apropos
 and in OpenBSD 5.6 for whatis.  The options -acfhIKklOTWw appeared in
 OpenBSD 5.7.

And further contains:

UTHORS
 Bill Joy wrote manwhere in 1977 and the original BSD apropos and whatis
 in February 1979. The current version was written by Kristaps Dzonsons
  and Ingo Schwarze .

So the history is rich and complete, do we really need to say when we
incorporated this into FreeBSD from OpenBSD's mandoc in the manual page?

> ./danfe
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362809 - head/contrib/mandoc

[Rodney W. Grimes]

> On Wed, Jul 01, 2020 at 11:58:05AM -0600, Warner Losh wrote:
> > On Wed, Jul 1, 2020 at 8:51 AM Rodney W. Grimes 
> > wrote:
> > 
> > > > On Tue, Jun 30, 2020 at 03:56:17PM -0700, Rodney W. Grimes wrote:
> > > > > [ Charset UTF-8 unsupported, converting... ]
> > > > > > Author: gbe (doc committer)
> > > > > > Date: Tue Jun 30 18:08:59 2020
> > > > > > New Revision: 362809
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/362809
> > > > > >
> > > > > > Log:
> > > > > >   Mention FreeBSD in the HISTORY sections of apropos(1) and
> > > makewhatis(8).
> > > > > >
> > > > > >   PR: 223520, 223521
> > > > > >   Reviewed by:bcr (mentor)
> > > > > >   Approved by:bcr (mentor)
> > > > > >   Differential Revision:  https://reviews.freebsd.org/D25521
> > > > > >
> > > > > > Modified:
> > > > > >   head/contrib/mandoc/apropos.1
> > > > > >   head/contrib/mandoc/makewhatis.8
> > > > > >
> > > > > > Modified: head/contrib/mandoc/apropos.1
> > > > > >
> > > ==
> > > > > > --- head/contrib/mandoc/apropos.1 Tue Jun 30 17:21:28 2020
> > > (r362808)
> > > > > > +++ head/contrib/mandoc/apropos.1 Tue Jun 30 18:08:59 2020
> > > (r362809)
> > > > > > @@ -15,7 +15,7 @@
> > > > > >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> > > ARISING OUT OF
> > > > > >  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > > > > >  .\"
> > > > > > -.Dd $Mdocdate: November 22 2018 $
> > > > > > +.Dd $Mdocdate: June 30 2020 $
> > > > > >  .Dt APROPOS 1
> > > > > >  .Os
> > > > > >  .Sh NAME
> > > > > > @@ -493,6 +493,12 @@ The options
> > > > > >  .Fl acfhIKklOTWw
> > > > > >  appeared in
> > > > > >  .Ox 5.7 .
> > > > > > +.Pp
> > > > > > +The
> > > > > > +.Nm
> > > > > > +utility was integrated into
> > > > > > +.Fx 11.1
> > > > > > +as part of the switch to mandoc.
> > > > >
> > > > > Huh?  FreeBSD has had apropos since 1.0 and my 5.4 system clearly has
> > > it:
> > > > > freebsd {110}% uname -a
> > > > > FreeBSD pdx.rh.CN85.dnsmgr.net 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8
> > > #1: Mon Jul  1 17:58:50 PDT 2019 
> > > r...@pdx.rh.cn85.dnsmgr.net:/usr/src/sys/i386/compile/PDXMXPIE
> > > i386
> > > > > pdx.rh.CN85.dnsmgr.net:freebsd {111}% which apropos
> > > > > /usr/bin/apropos
> > > > >
> > > > > And a man page for it too:
> > > > > APROPOS(1)  FreeBSD General Commands Manual
> > >  APROPOS(1)
> > > > >
> > > > > NAME
> > > > >  apropos, whatis -- search the whatis database
> > > > >
> > > > > SYNOPSIS
> > > > >  apropos keyword ...
> > > > >  whatis keyword ...
> > > > >
> > > > > DESCRIPTION
> > > > >  apropos searches a set of database files containing short
> > > descriptions of
> > > > >  system commands for keywords and displays the result on the
> > > standard out-
> > > > >  put.  whatis displays only complete word matches.
> > > > >
> > > > >  keyword really is an extended regular expression, please read
> > > grep(1)
> > > > >  manual page for more information about its format.
> > > > >
> > > > > DIAGNOSTICS
> > > > >  The apropos utility exits 0 on success, and 1 if no keyword
> > > matched.
> > > > >
> > > > > SEE ALSO
> > > > >  grep(1), makewhatis(1), man(1)
> > > > >
> > > > > FreeBSD 5.4January 15, 1991
> > > FreeBSD 5.4
> > > > >
> > > > > >  .Sh AUTHORS
> > > > > >  .An -nosplit
> > > > > >  .An Bill Joy
> > > > > >
> > > >
> > >

Re: svn commit: r362809 - head/contrib/mandoc

[Rodney W. Grimes]

> On Tue, Jun 30, 2020 at 03:56:17PM -0700, Rodney W. Grimes wrote:
> > [ Charset UTF-8 unsupported, converting... ]
> > > Author: gbe (doc committer)
> > > Date: Tue Jun 30 18:08:59 2020
> > > New Revision: 362809
> > > URL: https://svnweb.freebsd.org/changeset/base/362809
> > > 
> > > Log:
> > >   Mention FreeBSD in the HISTORY sections of apropos(1) and makewhatis(8).
> > >   
> > >   PR: 223520, 223521
> > >   Reviewed by:bcr (mentor)
> > >   Approved by:bcr (mentor)
> > >   Differential Revision:  https://reviews.freebsd.org/D25521
> > > 
> > > Modified:
> > >   head/contrib/mandoc/apropos.1
> > >   head/contrib/mandoc/makewhatis.8
> > > 
> > > Modified: head/contrib/mandoc/apropos.1
> > > ==
> > > --- head/contrib/mandoc/apropos.1 Tue Jun 30 17:21:28 2020
> > > (r362808)
> > > +++ head/contrib/mandoc/apropos.1 Tue Jun 30 18:08:59 2020
> > > (r362809)
> > > @@ -15,7 +15,7 @@
> > >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT 
> > > OF
> > >  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > >  .\"
> > > -.Dd $Mdocdate: November 22 2018 $
> > > +.Dd $Mdocdate: June 30 2020 $
> > >  .Dt APROPOS 1
> > >  .Os
> > >  .Sh NAME
> > > @@ -493,6 +493,12 @@ The options
> > >  .Fl acfhIKklOTWw
> > >  appeared in
> > >  .Ox 5.7 .
> > > +.Pp
> > > +The
> > > +.Nm
> > > +utility was integrated into
> > > +.Fx 11.1
> > > +as part of the switch to mandoc.
> > 
> > Huh?  FreeBSD has had apropos since 1.0 and my 5.4 system clearly has it:
> > freebsd {110}% uname -a
> > FreeBSD pdx.rh.CN85.dnsmgr.net 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 #1: 
> > Mon Jul  1 17:58:50 PDT 2019 
> > r...@pdx.rh.cn85.dnsmgr.net:/usr/src/sys/i386/compile/PDXMXPIE  i386
> > pdx.rh.CN85.dnsmgr.net:freebsd {111}% which apropos
> > /usr/bin/apropos
> > 
> > And a man page for it too:
> > APROPOS(1)  FreeBSD General Commands Manual 
> > APROPOS(1)
> > 
> > NAME
> >  apropos, whatis -- search the whatis database
> > 
> > SYNOPSIS
> >  apropos keyword ...
> >  whatis keyword ...
> > 
> > DESCRIPTION
> >  apropos searches a set of database files containing short descriptions 
> > of
> >  system commands for keywords and displays the result on the standard 
> > out-
> >  put.  whatis displays only complete word matches.
> > 
> >  keyword really is an extended regular expression, please read grep(1)
> >  manual page for more information about its format.
> > 
> > DIAGNOSTICS
> >  The apropos utility exits 0 on success, and 1 if no keyword matched.
> > 
> > SEE ALSO
> >  grep(1), makewhatis(1), man(1)
> > 
> > FreeBSD 5.4January 15, 1991FreeBSD 
> > 5.4
> > 
> > >  .Sh AUTHORS
> > >  .An -nosplit
> > >  .An Bill Joy
> > > 
> 
> That is true, but the version of 'apropos' we have currently in base is based 
> on mandoc,
> which was imported around September 2018. Due to the nature of contributed 
> code I 
> thought it would be best to document only the history when it was integrated 
> into
> FreeSBD. The same applies for 'makewhatis'.

That is not what has been done in other places when code is changed/replaced,
the HISTORY section is not specific to "FreeBSD's version" of this function.

We often have "An ls command appeared in Version 1 AT UNIX."  Our source
code and man page is not from that, but that is the history of ls.

This *could* be amended and *should* be amended to reflect that apropos,
and makewhatis got *updated* by a switch to the mandoc versions, but it
is misleading to say it was intergrated with the switch to mandoc as that
implies it did not exist before this action.

> 
> > > Modified: head/contrib/mandoc/makewhatis.8
> > > ==
> > > --- head/contrib/mandoc/makewhatis.8  Tue Jun 30 17:21:28 2020
> > > (r362808)
> > > +++ head/contrib/mandoc/makewhatis.8  Tue Jun 30 18:08:59 2020
> > > (r362809)
> > > @@ -15,7 +15,7 @@
> > >  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,

Re: svn commit: r362809 - head/contrib/mandoc

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: gbe (doc committer)
> Date: Tue Jun 30 18:08:59 2020
> New Revision: 362809
> URL: https://svnweb.freebsd.org/changeset/base/362809
> 
> Log:
>   Mention FreeBSD in the HISTORY sections of apropos(1) and makewhatis(8).
>   
>   PR: 223520, 223521
>   Reviewed by:bcr (mentor)
>   Approved by:bcr (mentor)
>   Differential Revision:  https://reviews.freebsd.org/D25521
> 
> Modified:
>   head/contrib/mandoc/apropos.1
>   head/contrib/mandoc/makewhatis.8
> 
> Modified: head/contrib/mandoc/apropos.1
> ==
> --- head/contrib/mandoc/apropos.1 Tue Jun 30 17:21:28 2020
> (r362808)
> +++ head/contrib/mandoc/apropos.1 Tue Jun 30 18:08:59 2020
> (r362809)
> @@ -15,7 +15,7 @@
>  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  .\"
> -.Dd $Mdocdate: November 22 2018 $
> +.Dd $Mdocdate: June 30 2020 $
>  .Dt APROPOS 1
>  .Os
>  .Sh NAME
> @@ -493,6 +493,12 @@ The options
>  .Fl acfhIKklOTWw
>  appeared in
>  .Ox 5.7 .
> +.Pp
> +The
> +.Nm
> +utility was integrated into
> +.Fx 11.1
> +as part of the switch to mandoc.

Huh?  FreeBSD has had apropos since 1.0 and my 5.4 system clearly has it:
freebsd {110}% uname -a
FreeBSD pdx.rh.CN85.dnsmgr.net 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 #1: Mon 
Jul  1 17:58:50 PDT 2019 
r...@pdx.rh.cn85.dnsmgr.net:/usr/src/sys/i386/compile/PDXMXPIE  i386
pdx.rh.CN85.dnsmgr.net:freebsd {111}% which apropos
/usr/bin/apropos

And a man page for it too:
APROPOS(1)  FreeBSD General Commands Manual APROPOS(1)

NAME
 apropos, whatis -- search the whatis database

SYNOPSIS
 apropos keyword ...
 whatis keyword ...

DESCRIPTION
 apropos searches a set of database files containing short descriptions of
 system commands for keywords and displays the result on the standard out-
 put.  whatis displays only complete word matches.

 keyword really is an extended regular expression, please read grep(1)
 manual page for more information about its format.

DIAGNOSTICS
 The apropos utility exits 0 on success, and 1 if no keyword matched.

SEE ALSO
 grep(1), makewhatis(1), man(1)

FreeBSD 5.4January 15, 1991FreeBSD 5.4

>  .Sh AUTHORS
>  .An -nosplit
>  .An Bill Joy
> 
> Modified: head/contrib/mandoc/makewhatis.8
> ==
> --- head/contrib/mandoc/makewhatis.8  Tue Jun 30 17:21:28 2020
> (r362808)
> +++ head/contrib/mandoc/makewhatis.8  Tue Jun 30 18:08:59 2020
> (r362809)
> @@ -15,7 +15,7 @@
>  .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>  .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  .\"
> -.Dd $Mdocdate: May 17 2017 $
> +.Dd $Mdocdate: June 30 2020 $
>  .Dt MAKEWHATIS 8
>  .Os
>  .Sh NAME
> @@ -211,6 +211,12 @@ and the options
>  .Fl aCDnQT
>  in
>  .Ox 5.6 .
> +.Pp
> +The
> +.Nm
> +utility was integrated into
> +.Fx 11.1
> +as part of the switch to mandoc.

Ditto

>  .Sh AUTHORS
>  .An -nosplit
>  .An Bill Joy
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362600 - in head: sys/amd64/include sys/amd64/vmm usr.sbin/bhyve

[Rodney W. Grimes]

> Author: cem
> Date: Thu Jun 25 00:18:42 2020
> New Revision: 362600
> URL: https://svnweb.freebsd.org/changeset/base/362600
> 
> Log:
>   bhyve(8): For prototyping, reattempt decode in userspace
>   
>   If userspace has a newer bhyve than the kernel, it may be able to decode
>   and emulate some instructions vmm.ko is unaware of.  In this scenario,
>   reset decoder state and try again.

This is pretty darn cool.  Thanks!


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362338 - in head: share/man/man4 sys/conf sys/kern sys/netinet sys/netinet6 sys/netipsec sys/netpfil/pf

[Rodney W. Grimes]

> On 6/21/20 6:10 PM, Mark Johnston wrote:
> > On Fri, Jun 19, 2020 at 08:33:35AM -0700, John Baldwin wrote:
> >> On 6/18/20 12:32 PM, Mark Johnston wrote:
> >>> Author: markj
> >>> Date: Thu Jun 18 19:32:34 2020
> >>> New Revision: 362338
> >>> URL: https://svnweb.freebsd.org/changeset/base/362338
> >>>
> >>> Log:
> >>>   Add the SCTP_SUPPORT kernel option.
> >>>   
> >>>   This is in preparation for enabling a loadable SCTP stack.  Analogous to
> >>>   IPSEC/IPSEC_SUPPORT, the SCTP_SUPPORT kernel option must be configured
> >>>   in order to support a loadable SCTP implementation.
> >>>   
> >>>   Discussed with: tuexen
> >>>   MFC after:  2 weeks
> >>>   Sponsored by:   The FreeBSD Foundation
> >>
> >> Do you want to add similar handling to sys/conf/config.mk that we have
> >> for IPsec?  Also, do we want to avoid building sctp.ko if it is in the
> >> kernel like we do for ipsec.ko and/or only build it if the kernel contains
> >> SCTP_SUPPORT?  (For ipsec.ko we had to do that as it wouldn't compile, not
> >> sure if the same is true for sctp.ko)
> > 
> > Sorry for the delay.
> > I think we do indeed want similar handling in config.mk, I will work on
> > it.  It is probably also reasonable to avoid compiling sctp.ko when
> > SCTP_SUPPORT is not defined, though I can't see a reason that wouldn't
> > work today since SCTP_SUPPORT is not used in any headers.
> 
> Ok.  ipsec.ko mattered more when the build broke.  Whether or not we compile
> "duplicate" modules for kernels is perhaps a larger question.  I think I
> might favor that change, but it is a larger change that merits some thought.
> In particular, you want good code coverage for things like LINT builds, so
> maybe we really should still compile modules whenever possible.

As a person that builds a lot of stuff into his kernel, aka I run
moduleless most of the time, I still would like the modules to build
so I know I have not busted that with other changes.  It is just too
easy to do, IMHO.

> -- 
> John Baldwin
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362420 - head/share/misc

[Rodney W. Grimes]

> On Sat, Jun 20, 2020 at 5:13 AM Rodney W. Grimes 
> wrote:
> 
> > > On Sat, Jun 20, 2020 at 04:07:44AM +, Warner Losh wrote:
> > > > New Revision: 362420
> > > > URL: https://svnweb.freebsd.org/changeset/base/362420
> > > >
> > > > Log:
> > > >   Correct 1BSD release date.
> > > >
> > > >   The Quarter Century of Unix book said that 1BSD was released March
> > 1979.
> > > >   However, the 1BSD tape image that's on Kirk's historical unix
> > collection
> > > >   has an earlier date.
> > > >
> > > >   It was common practice, at the time, to create a new copy of the tape
> > > >   from the master system
> > >  ^^
> > > Ouch! :-)
> >
> > Given that this occured AFTER imp made a commit removing master/slave
> > language I find it very ironic.
> >
> > Uh oh, we need to rewire our VCS system so we can correct our
> > political incorrectness in our logs.
> >
> 
> Master copy has a completely different etymology than master slave.
> 
> The only irony here is that you are over-reacting to this.

Very interesting that you reply to me, and not the original poster
on the reaction, that I reacted to.  Bias perhaps?

> Warner
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362444 - head/sbin/dump

[Rodney W. Grimes]

> On Sat, Jun 20, 2020 at 2:19 PM Alexey Dokuchaev  wrote:
> 
> > On Sat, Jun 20, 2020 at 08:12:40PM +, Colin Percival wrote:
> > > Thanks for backing this out, Warner.
> >
> > I also appreciate it.
> >
> 
> You bet. I had enough people send me dispassionate context around to
> realize that minion was no longer a hill worth dying on. While it wasn't
> problematic in the way slave was, it had other issues my pre-commit
> research completely was blind to...
> 
> 
> > > I'd like to change "slave" to "worker" here (which I think is a
> > reasonably
> > > neutral and entirely inoffensive term), and in the process perhaps make
> > some
> > > associated grammatical changes (since "enworker" is dubious at best).
> > >
> > > To avoid causing any further issues: If anyone objects to the word
> > "worker"
> > > please let me know in the next ~48 hours.  I think there's enough people
> > > reading svn-src-all that I can anticipate feedback now if anyone will
> > care
> > > deeply about that word.
> >
> > Please, just open a DR for that so all interested parties can participate
> > and fine-tune particular grammar and language choices.  Also, r362447
> > should be reverted on the same grounds as r362422.
> >
> 
> I'd have rather r362447 go through review as well, but really, it's fine
> enough for now that it's not worth the churn to back it out.

Agreed, but can we stop the apparent haste to make changes?

> Warner
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362420 - head/share/misc

[Rodney W. Grimes]

> On Sat, Jun 20, 2020 at 04:07:44AM +, Warner Losh wrote:
> > New Revision: 362420
> > URL: https://svnweb.freebsd.org/changeset/base/362420
> > 
> > Log:
> >   Correct 1BSD release date.
> >   
> >   The Quarter Century of Unix book said that 1BSD was released March 1979.
> >   However, the 1BSD tape image that's on Kirk's historical unix collection
> >   has an earlier date.
> >   
> >   It was common practice, at the time, to create a new copy of the tape
> >   from the master system
>  ^^
> Ouch! :-)

Given that this occured AFTER imp made a commit removing master/slave
language I find it very ironic.

Uh oh, we need to rewire our VCS system so we can correct our
political incorrectness in our logs.

> ./danfe
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362422 - head/sbin/dump

[Rodney W. Grimes]

> Author: imp
> Date: Sat Jun 20 04:19:17 2020
> New Revision: 362422
> URL: https://svnweb.freebsd.org/changeset/base/362422
> 
> Log:
>   Increase the whimsy in this file by famring dump's work out to minions. 
> Adjust
>   variables accordingly. Thankfully, we are able to do this without additional
>   banana expenditures.

This flys in the face of its intent and as a "commit" is more
racially biased than the code was!


> Modified:
>   head/sbin/dump/tape.c
> 
> Modified: head/sbin/dump/tape.c
> ==
> --- head/sbin/dump/tape.c Sat Jun 20 04:07:58 2020(r362421)
> +++ head/sbin/dump/tape.c Sat Jun 20 04:19:17 2020(r362422)
> @@ -75,19 +75,19 @@ staticchar *nexttape;
>  static   FILE *popenfp = NULL;
>  
>  static   int atomic(ssize_t (*)(), int, char *, int);
> -static   void doslave(int, int);
> -static   void enslave(void);
> +static   void dominion(int, int);
> +static   void enminion(void);
>  static   void flushtape(void);
>  static   void killall(void);
>  static   void rollforward(void);
>  
>  /*
>   * Concurrent dump mods (Caltech) - disk block reading and tape writing
> - * are exported to several slave processes.  While one slave writes the
> + * are exported to several minion processes.  While one minion writes the
>   * tape, the others read disk blocks; they pass control of the tape in
>   * a ring via signals. The parent process traverses the file system and
> - * sends writeheader()'s and lists of daddr's to the slaves via pipes.
> - * The following structure defines the instruction packets sent to slaves.
> + * sends writeheader()'s and lists of daddr's to the minions via pipes.
> + * The following structure defines the instruction packets sent to minions.
>   */
>  struct req {
>   ufs2_daddr_t dblk;
> @@ -95,20 +95,20 @@ struct req {
>  };
>  static int reqsiz;
>  
> -#define SLAVES 3 /* 1 slave writing, 1 reading, 1 for slack */
> -static struct slave {
> +#define MINIONS 3/* 1 minion writing, 1 reading, 1 for slack */
> +static struct minion {
>   int64_t tapea;  /* header number at start of this chunk */
>   int64_t firstrec;   /* record number of this block */
>   int count;  /* count to next header (used for TS_TAPE */
>   /* after EOT) */
>   int inode;  /* inode that we are currently dealing with */
> - int fd; /* FD for this slave */
> - int pid;/* PID for this slave */
> - int sent;   /* 1 == we've sent this slave requests */
> + int fd; /* FD for this minion */
> + int pid;/* PID for this minion */
> + int sent;   /* 1 == we've sent this minion requests */
>   char (*tblock)[TP_BSIZE]; /* buffer for data blocks */
>   struct req *req;/* buffer for requests */
> -} slaves[SLAVES+1];
> -static struct slave *slp;
> +} minions[MINIONS+1];
> +static struct minion *mlp;
>  
>  static char  (*nextblock)[TP_BSIZE];
>  
> @@ -116,9 +116,9 @@ static int master;/* pid of master, for sending 
> error
>  static int tenths;   /* length of tape used per block written */
>  static volatile sig_atomic_t caught; /* have we caught the signal to 
> proceed? */
>  static volatile sig_atomic_t ready; /* reached the lock point without having 
> */
> - /* received the SIGUSR2 signal from the prev slave? */
> + /* received the SIGUSR2 signal from the prev minion? */
>  static jmp_buf jmpbuf;   /* where to jump to if we are ready when the */
> - /* SIGUSR2 arrives from the previous slave */
> + /* SIGUSR2 arrives from the previous minion */
>  
>  int
>  alloctape(void)
> @@ -143,20 +143,20 @@ alloctape(void)
>* packets, so flushtape() can write them together with one write().
>* Align tape buffer on page boundary to speed up tape write().
>*/
> - for (i = 0; i <= SLAVES; i++) {
> + for (i = 0; i <= MINIONS; i++) {
>   buf = (char *)
>   malloc((unsigned)(reqsiz + writesize + pgoff + TP_BSIZE));
>   if (buf == NULL)
>   return(0);
> - slaves[i].tblock = (char (*)[TP_BSIZE])
> + minions[i].tblock = (char (*)[TP_BSIZE])
>   (((long)[ntrec + 1] + pgoff) &~ pgoff);
> - slaves[i].req = (struct req *)slaves[i].tblock - ntrec - 1;
> + minions[i].req = (struct req *)minions[i].tblock - ntrec - 1;
>   }
> - slp = [0];
> - slp->count = 1;
> - slp->tapea = 0;
> - slp->firstrec = 0;
> - nextblock = slp->tblock;
> + mlp = [0];
> + mlp->count = 1;
> + mlp->tapea = 0;
> + mlp->firstrec = 0;
> + nextblock = mlp->tblock;
>   return(1);
>  }
>  
> @@ -164,8 

Re: svn commit: r362217 - head/stand/common

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Tue, Jun 16, 2020 at 8:33 PM Ian Lepore  wrote:
> 
> > On Tue, 2020-06-16 at 19:34 +0200, Kristof Provost wrote:
> > > On 16 Jun 2020, at 19:11, Ed Maste wrote:
> > > > On Tue, 16 Jun 2020 at 13:01, Ian Lepore  wrote:
> > > > >
> > > > > As much as I prefer doing it this way, style(9) doesn't allow for
> > > > > variable declarations inside a for() statement (or even inside a
> > > > > local
> > > > > block, which is just too 1980s for me, but it is still our standard).
> > > >
> > > > Perhaps it's time to update style(9) to at least permit these uses, as
> > > > we've done with the blank line at the beginning of functions with no
> > > > local variables, and with braces around single-line bodies.
> > >
> > > We have 431 instances of `for (int i` in sys alone. It?s not so much a
> > > question of allowing it as acknowledging reality at this point.
> > >
> > > Best regards,
> > > Kristof
> >
> > Hmm, so we do.  If you weed out sys/contrib, and device drivers
> > contributed by vendors, the number is a lot smaller, but still big
> > enough that we should just change the rules I think.
> >
> 
> We should definitely just change the rules. There's no point in
> prohibiting it. Contributors have already voted with their feet
> 
> diff --git a/share/man/man9/style.9 b/share/man/man9/style.9
> index 4e801bbcbe70..fd23d573eb00 100644
> --- a/share/man/man9/style.9
> +++ b/share/man/man9/style.9
> @@ -592,8 +592,6 @@ not
>  Parts of a
>  .Ic for
>  loop may be left empty.
> -Do not put declarations
> -inside blocks unless the routine is unusually complicated.

Perhaps some wording here that makes it explicit that
block scope variables are allowed, and that the for()
case is allowed.

>  .Bd -literal
> for (; cnt < 15; cnt++) {
+   for (int cnt = 0; cnt < 15; cnt++) {
+   char *p;
> stmt1;

This updates the example to reflect the new accepted style.

> 
> Although the block doesn't start until { so int i; in the commit
> technically doesn't violate this rule. We violate it in dozens of other
> ways than this.

I think it violates some other rule about declarations being
in order of size sorted at the top of a routine, perhaps that
needs looked at as well for some change.

> Warner
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362217 - head/stand/common

[Rodney W. Grimes]

> In message <55903c38d363aef2a6f6d0075dd4526b86d51258.ca...@freebsd.org>, 
> Ian Le
> pore writes:
> > On Tue, 2020-06-16 at 07:05 +, Toomas Soome wrote:
> > > Author: tsoome
> > > Date: Tue Jun 16 07:05:03 2020
> > > New Revision: 362217
> > > URL: https://svnweb.freebsd.org/changeset/base/362217
> > > 
> > > Log:
> > >   loader: variable i is unused without MBR/GPT support built in
> > >   
> > >   Because i is only used as index in for loop, declare it in for
> > > statement.
> > > 
> >
> > As much as I prefer doing it this way, style(9) doesn't allow for
> > variable declarations inside a for() statement (or even inside a local
> > block, which is just too 1980s for me, but it is still our standard).

Last time I tried to assert that bit of style(9) with respect to
inside a local block I was over ridden, so it is probably time
to atleast revisit that part of style(9).

> Doesn't this use stack for a shorter period of time or does the compiler 
> optimize this, making this change moot?
> 
> The tradeoff is a few extra bytes of stack for a longer period of time vs a 
> few extra instructions incrementing and decrementing the stack pointer.

I do not think the reasoning had to do with stack space vs instuctions,
but more about being able to clearly know about variable reuse and not
do it as that can create fun bugs.

Tools have modernized since that part of style was written.

> -- 
> Cy Schubert 
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362191 - head/sbin/md5

[Rodney W. Grimes]

> On Mon, Jun 15, 2020 at 7:34 AM Mateusz Piotrowski <0...@freebsd.org> wrote:
> 
> > Hi,
> >
> > On 6/15/20 2:33 PM, Rodney W. Grimes wrote:
> > > [ Charset UTF-8 unsupported, converting... ]
> > >> Author: fernape (ports committer)
> > >> Date: Mon Jun 15 10:08:02 2020
> > >> New Revision: 362191
> > >> URL: https://svnweb.freebsd.org/changeset/base/362191
> > >>
> > >> Log:
> > >>   md5(1): fix style in man page
> > >
> > > Mandoc is fine to ignore this, but it is wrong to call it useless.
> > >
> > > I really wish that this stop.  .Tn might be useless to mandoc,
> > > but it is a very usable thing if your formatting to something
> > > other than txt, as in a ps or pdf.
> >
> > In that case I would consider patching our in-tree mandoc to not warn
> > about Tn. Or request support for Tn or a well-defined replacement upstream.
> >
> > I can see the benefit of keeping Tn around, as it /might/ potentially
> > create nice formatting for HTML. On the other hand, I don't like the
> > idea of not following the linter.
> >
> 
> I thought that Tn thing was the general consensus thing and added to the
> linter because of that. The man page explains why it's problematic:
> 
>  Tn word ...
>   Supported only for compatibility, do not use this in new manuals.
>   Even though the macro name ("tradename") suggests a semantic
>   function, historic usage is inconsistent, mostly using it as a
>   presentation-level macro to request a small caps font.

I believe that comes about because of confusion over trade name vs
trademark.  They are not defined as the same thing.

> It was useful for the Unix trademark, but was tailor towards AT's
> preferred dressing for the Unix trademark, not for trademarks in general.

Crossing tradename with trademark?

> In this case, there were several instances of abuse:
> 
> -.Tn RSA .
> +key under a public-key cryptosystem such as RSA.

trade name: noun
  1. the name used by a manufacturer, merchant, service company,
 farming business, etc., to identify itself individually
 as a business.
  2. a word or phrase used in a trade to designate a business,
 service, or a particular class of goods, but that is not
 technically a trademark, either because it is not
 susceptible of exclusive appropriation as a trademark or
 because it is not affixed to goods sold in the market.
  3. the name by which an article or substance is known to the trade.

I would say RSA defanitly meets 3, and probably 2.

> 
> Not a trademark in this context. RSA is a trademark for the RSA corporation
> and it uses it in various other contexts.
> 
> -The
> -.Tn MD5
> -and
> -.Tn SHA-1
> -algorithms have been proven to be vulnerable to practical collision
> -attacks and should not be relied upon to produce unique outputs,
> +The MD5 and SHA-1 algorithms have been proven to be vulnerable to practical
> +collision attacks and should not be relied upon to produce unique outputs,
> 
> MD5 and SHA-1 are not trade names in this context. The rest seem similar,
> though I've not gone to the trouble to look them all up.

I would disagree under the definition of trade name above,
you seem to be applying the definition of trade mark.

> 
> All in all, while I have some sympathy to Rod's view that we're losing
> semantic information by these changes in general, this particular one
> actually fixes the abuse talked about in the mdoc manual, IMHO.

Only if the macro is rigidly defined as "trademark" and it
is not.

> Warner
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362191 - head/sbin/md5

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: fernape (ports committer)
> Date: Mon Jun 15 10:08:02 2020
> New Revision: 362191
> URL: https://svnweb.freebsd.org/changeset/base/362191
> 
> Log:
>   md5(1): fix style in man page
>   
>   Fix a bunch of style problems reported by mandoc(1) and igor:
>   
>   mandoc: ./md5.1:19:71: STYLE: no blank before trailing delimiter: Nm ... 
> rmd160,
>   mandoc: ./md5.1:20:23: STYLE: no blank before trailing delimiter: Nm ...  
> skein512,
>   mandoc: ./md5.1:33:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:33:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:33:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:33:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:35:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:42:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:45:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:47:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:56:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:58:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:61:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:66:2: STYLE: useless macro: Tn
>   mandoc: ./md5.1:68:2: STYLE: useless macro: Tn

Mandoc is fine to ignore this, but it is wrong to call it useless.

I really wish that this stop.  .Tn might be useless to mandoc, 
but it is a very usable thing if your formatting to something
other than txt, as in a ps or pdf.


>   mandoc: ./md5.1:104:24: STYLE: no blank before trailing delimiter: Nm 
> skein512,
>   mandoc: ./md5.1:117:6: STYLE: referenced manual not found: Xr sha224 3
>   
>   igor:
>   md5.1:46:no comma after "i.e.":either algorithm, [i.e.] to find an input 
> that produces a specific
>   
>   Approved by:bcr@
>   Differential Revision: https://reviews.freebsd.org/D25277
> 
> Modified:
>   head/sbin/md5/md5.1
> 
> Modified: head/sbin/md5/md5.1
> ==
> --- head/sbin/md5/md5.1   Mon Jun 15 03:10:53 2020(r362190)
> +++ head/sbin/md5/md5.1   Mon Jun 15 10:08:02 2020(r362191)
> @@ -1,5 +1,5 @@
>  .\" $FreeBSD$
> -.Dd July 9, 2018
> +.Dd June 15, 2020
>  .Dt MD5 1
>  .Os
>  .Sh NAME
> @@ -16,8 +16,8 @@
>  (All other hashes have the same options and usage.)
>  .Sh DESCRIPTION
>  The
> -.Nm md5 , sha1 , sha224 , sha256 , sha384 , sha512, sha512t256, rmd160,
> -.Nm skein256, skein512,
> +.Nm md5 , sha1 , sha224 , sha256 , sha384 , sha512 , sha512t256 , rmd160 ,
> +.Nm skein256 , skein512 ,
>  and
>  .Nm skein1024
>  utilities take as input a message of arbitrary length and produce as
> @@ -29,43 +29,29 @@ of the input.
>  It is conjectured that it is computationally infeasible to
>  produce two messages having the same message digest, or to produce any
>  message having a given prespecified target message digest.
> -The
> -.Tn SHA-224 , SHA-256 , SHA-384 , SHA-512, RIPEMD-160,
> -and
> -.Tn SKEIN
> +The SHA-224 , SHA-256 , SHA-384 , SHA-512, RIPEMD-160,
> +and SKEIN
>  algorithms are intended for digital signature applications, where a
>  large file must be
>  .Dq compressed
>  in a secure manner before being encrypted with a private
>  (secret)
> -key under a public-key cryptosystem such as
> -.Tn RSA .
> +key under a public-key cryptosystem such as RSA.
>  .Pp
> -The
> -.Tn MD5
> -and
> -.Tn SHA-1
> -algorithms have been proven to be vulnerable to practical collision
> -attacks and should not be relied upon to produce unique outputs,
> +The MD5 and SHA-1 algorithms have been proven to be vulnerable to practical
> +collision attacks and should not be relied upon to produce unique outputs,
>  .Em nor should they be used as part of a cryptographic signature scheme.
>  As of 2017-03-02, there is no publicly known method to
>  .Em reverse
> -either algorithm, i.e. to find an input that produces a specific
> +either algorithm, i.e., to find an input that produces a specific
>  output.
>  .Pp
> -.Tn SHA-512t256
> -is a version of
> -.Tn SHA-512
> -truncated to only 256 bits.
> -On 64-bit hardware, this algorithm is approximately 50% faster than
> -.Tn SHA-256
> -but with the same level of security.
> +SHA-512t256 is a version of SHA-512 truncated to only 256 bits.
> +On 64-bit hardware, this algorithm is approximately 50% faster than SHA-256 
> but
> +with the same level of security.
>  The hashes are not interchangeable.
>  .Pp
> -It is recommended that all new applications use
> -.Tn SHA-512
> -or
> -.Tn SKEIN-512
> +It is recommended that all new applications use SHA-512 or SKEIN-512
>  instead of one of the other hash functions.
>  .Pp
>  The following options may be used in any combination and must
> @@ -101,7 +87,7 @@ Run a built-in test script.
>  .Sh EXIT STATUS
>  The
>  .Nm md5 , sha1 , sha224 , sha256 , sha512 , sha512t256 , rmd160 ,
> -.Nm skein256 , skein512,
> +.Nm skein256 , skein512 ,
>  and
>  .Nm skein1024
>  utilities exit 0 on success,
> @@ -114,7 +100,6 @@ option.
>  .Xr md5 3 ,
>  .Xr ripemd 3 ,
>  .Xr sha 3 ,
> -.Xr sha224 3 ,
>  .Xr 

Re: svn commit: r362170 - in head/cddl/contrib/opensolaris/cmd: dtrace lockstat zdb zfs zpool zstreamdump

[Rodney W. Grimes]

> Author: gbe (doc committer)
> Date: Sun Jun 14 05:50:28 2020
> New Revision: 362170
> URL: https://svnweb.freebsd.org/changeset/base/362170
> 
> Log:
>   Add HISTORY sections to ZFS and dtrace manpage
>   
>   Reviewed by:bcr (mentor)
>   Approved by:bcr (mentor)
>   MFC after:  7 days
>   Differential Revision:  https://reviews.freebsd.org/D23833
> 
> Modified:
>   head/cddl/contrib/opensolaris/cmd/dtrace/dtrace.1
>   head/cddl/contrib/opensolaris/cmd/lockstat/lockstat.1
>   head/cddl/contrib/opensolaris/cmd/zdb/zdb.8
>   head/cddl/contrib/opensolaris/cmd/zfs/zfs.8
>   head/cddl/contrib/opensolaris/cmd/zpool/zpool.8
>   head/cddl/contrib/opensolaris/cmd/zstreamdump/zstreamdump.1

Is this really the correct history?  Didnt all of these first
appear in Solaris?

The man page may of first appeared in FreeBSD, but the commands
themselves originated some place else?

> 
> Modified: head/cddl/contrib/opensolaris/cmd/dtrace/dtrace.1
> ==
> --- head/cddl/contrib/opensolaris/cmd/dtrace/dtrace.1 Sun Jun 14 05:35:02 
> 2020(r362169)
> +++ head/cddl/contrib/opensolaris/cmd/dtrace/dtrace.1 Sun Jun 14 05:50:28 
> 2020(r362170)
> @@ -20,7 +20,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd October 30, 2018
> +.Dd February 25, 2020
>  .Dt DTRACE 1
>  .Os
>  .Sh NAME
> @@ -776,6 +776,11 @@ failed or that the specified request could not be sati
>  .It 2
>  Invalid command line options or arguments were specified.
>  .El
> +.Sh HISTORY
> +The
> +.Nm 
> +utility first appeared in
> +.Fx 7.1 .
>  .Sh SEE ALSO
>  .Xr cpp 1 ,
>  .Xr elf 5 ,
> 
> Modified: head/cddl/contrib/opensolaris/cmd/lockstat/lockstat.1
> ==
> --- head/cddl/contrib/opensolaris/cmd/lockstat/lockstat.1 Sun Jun 14 
> 05:35:02 2020(r362169)
> +++ head/cddl/contrib/opensolaris/cmd/lockstat/lockstat.1 Sun Jun 14 
> 05:50:28 2020(r362170)
> @@ -21,7 +21,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd September 29, 2015
> +.Dd February 25, 2020
>  .Dt LOCKSTAT 1
>  .Os
>  .Sh NAME
> @@ -366,6 +366,11 @@ Count indv cuml rcnt nsec Lock   C
>  .Xr dtrace 1 ,
>  .Xr ksyms 4 ,
>  .Xr locking 9
> +.Sh HISTORY
> +The
> +.Nm
> +utility first appeared in
> +.Fx 7.1 .
>  .Sh NOTES
>  Tail-call elimination can affect call sites.
>  For example, if
> 
> Modified: head/cddl/contrib/opensolaris/cmd/zdb/zdb.8
> ==
> --- head/cddl/contrib/opensolaris/cmd/zdb/zdb.8   Sun Jun 14 05:35:02 
> 2020(r362169)
> +++ head/cddl/contrib/opensolaris/cmd/zdb/zdb.8   Sun Jun 14 05:50:28 
> 2020(r362170)
> @@ -13,7 +13,7 @@
>  .\" Copyright (c) 2012, 2018 by Delphix. All rights reserved.
>  .\" Copyright 2017 Nexenta Systems, Inc.
>  .\"
> -.Dd October 06, 2017
> +.Dd February 25, 2020
>  .Dt ZDB 8
>  .Os
>  .Sh NAME
> @@ -407,3 +407,8 @@ dedup = 1.11, compress = 1.80, copies = 1.00, dedup * 
>  .Sh SEE ALSO
>  .Xr zfs 8 ,
>  .Xr zpool 8
> +.Sh HISTORY
> +The
> +.Nm
> +utility first appeared in
> +.Fx 7.0 .
> 
> Modified: head/cddl/contrib/opensolaris/cmd/zfs/zfs.8
> ==
> --- head/cddl/contrib/opensolaris/cmd/zfs/zfs.8   Sun Jun 14 05:35:02 
> 2020(r362169)
> +++ head/cddl/contrib/opensolaris/cmd/zfs/zfs.8   Sun Jun 14 05:50:28 
> 2020(r362170)
> @@ -3949,6 +3949,11 @@ M   F   /tank/test/modified
>  .Xr umount 8 ,
>  .Xr zfs-program 8 ,
>  .Xr zpool 8
> +.Sh HISTORY
> +The
> +.Nm
> +utility first appeared in
> +.Fx 7.0 .
>  .Sh AUTHORS
>  This manual page is a
>  .Xr mdoc 7
> 
> Modified: head/cddl/contrib/opensolaris/cmd/zpool/zpool.8
> ==
> --- head/cddl/contrib/opensolaris/cmd/zpool/zpool.8   Sun Jun 14 05:35:02 
> 2020(r362169)
> +++ head/cddl/contrib/opensolaris/cmd/zpool/zpool.8   Sun Jun 14 05:50:28 
> 2020(r362170)
> @@ -29,7 +29,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd November 7, 2019
> +.Dd February 25, 2020
>  .Dt ZPOOL 8
>  .Os
>  .Sh NAME
> @@ -2462,6 +2462,11 @@ Discarded approximately 29 seconds of transactions.
>  .Xr zpool-features 7 ,
>  .Xr zfs 8 ,
>  .Xr zfsd 8
> +.Sh HISTORY
> +The
> +.Nm
> +utility first appeared in
> +.Fx 7.0 .
>  .Sh AUTHORS
>  This manual page is a
>  .Xr mdoc 7
> 
> Modified: head/cddl/contrib/opensolaris/cmd/zstreamdump/zstreamdump.1
> ==
> --- head/cddl/contrib/opensolaris/cmd/zstreamdump/zstreamdump.1   Sun Jun 
> 14 05:35:02 2020(r362169)
> +++ head/cddl/contrib/opensolaris/cmd/zstreamdump/zstreamdump.1   Sun Jun 
> 14 05:50:28 2020(r362170)
> @@ -22,7 +22,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd December 31, 2013
> +.Dd 

Re: svn commit: r362029 - head/sys/dev/hdmi

[Rodney W. Grimes]

> Author: gonzo
> Date: Wed Jun 10 21:38:35 2020
> New Revision: 362029
> URL: https://svnweb.freebsd.org/changeset/base/362029
> 
> Log:
>   Fix reading EDID on TVs/monitors without E-DCC support
>   
>   Writing segment id to I2C device 0x30 only required if the segment is
>   non-zero. On the devices without E-DCC support writing to that address
>   fails and whole transaction then fails too. To avoid this do
>   not attempt write to the segment selection device unless required.
>   
>   MFC after:  2 weeks

Is it possible that this bad write is what has caused me to corrupt
the EDID of 3 monitors over the last year while using a Display
Port to HDMI cable on them?

> Modified:
>   head/sys/dev/hdmi/dwc_hdmi.c
> 
> Modified: head/sys/dev/hdmi/dwc_hdmi.c
> ==
> --- head/sys/dev/hdmi/dwc_hdmi.c  Wed Jun 10 21:18:19 2020
> (r362028)
> +++ head/sys/dev/hdmi/dwc_hdmi.c  Wed Jun 10 21:38:35 2020
> (r362029)
> @@ -658,6 +658,11 @@ hdmi_edid_read(struct dwc_hdmi_softc *sc, int block, u
>   int result;
>   uint8_t addr = block & 1 ? EDID_LENGTH : 0;
>   uint8_t segment = block >> 1;
> + /*
> +  * Some devices do not support E-DDC so attempt
> +  * writing segment address only if it's neccessary
> +  */
> + unsigned char xfers = segment ? 3 : 2;
>   struct iic_msg msg[] = {
>   { I2C_DDC_SEGADDR, IIC_M_WR, 1,  },
>   { I2C_DDC_ADDR, IIC_M_WR, 1,  },
> @@ -687,7 +692,7 @@ hdmi_edid_read(struct dwc_hdmi_softc *sc, int block, u
>   return (result);
>   }
>  
> - result = iicbus_transfer(i2c_dev, msg, 3);
> + result = iicbus_transfer(i2c_dev, [3 - xfers], xfers);
>   iicbus_release_bus(i2c_dev, sc->sc_dev);
>  
>   if (result) {
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361884 - in head/usr.bin/sed: . tests

[Rodney W. Grimes]

> Author: kevans
> Date: Sun Jun  7 04:32:38 2020
> New Revision: 361884
> URL: https://svnweb.freebsd.org/changeset/base/361884
> 
> Log:
>   sed: attempt to learn about hex escapes (e.g. \x27)
>   
>   Somewhat predictably, software often wants to use \x27/\x24 among others so
>   that they can decline worrying about ugly escaping, if said escaping is even
>   possible. Right now, this software is using these and getting the wrong
>   results, as we'll interpret those as x27 and x24 respectively. Some examples
>   of this, when an exp-run was ran, were science/octopus and misc/vifm.
>   
>   Go ahead and process these at all times.  We allow either one or two digits,
>   and the tests account for both.  If extra digits are specified, e.g. \x2727,
>   then the third and fourth digits are interpreted literally as one might
>   expect.

Does it work to do \\x27, ie I want it to NOT do \x27 so I can sed
on files that contain sequences of escapes.

>   
>   PR: 229925
>   MFC after:  2 weeks
> 
> Modified:
>   head/usr.bin/sed/compile.c
>   head/usr.bin/sed/tests/sed2_test.sh
> 
> Modified: head/usr.bin/sed/compile.c
> ==
> --- head/usr.bin/sed/compile.cSun Jun  7 03:11:34 2020
> (r361883)
> +++ head/usr.bin/sed/compile.cSun Jun  7 04:32:38 2020
> (r361884)
> @@ -49,6 +49,7 @@ static const char sccsid[] = "@(#)compile.c 8.1 (Berke
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -365,6 +366,51 @@ nonsel:  /* Now parse the command */
>   }
>  }
>  
> +static int
> +hex2char(const char *in, char *out, int len)
> +{
> + long ord;
> + char *endptr, hexbuf[3];
> +
> + hexbuf[0] = in[0];
> + hexbuf[1] = len > 1 ? in[1] : '\0';
> + hexbuf[2] = '\0';
> +
> + errno = 0;
> + ord = strtol(hexbuf, , 16);
> + if (*endptr != '\0' || errno != 0)
> + return (ERANGE);
> + *out = (char)ord;
> + return (0);
> +}
> +
> +static bool
> +hexdigit(char c)
> +{
> + int lc;
> +
> + lc = tolower(c);
> + return isdigit(lc) || (lc >= 'a' && lc <= 'f');
> +}
> +
> +static bool
> +dohex(const char *in, char *out, int *len)
> +{
> + int tmplen;
> +
> + if (!hexdigit(in[0]))
> + return (false);
> + tmplen = 1;
> + if (hexdigit(in[1]))
> + ++tmplen;
> + if (hex2char(in, out, tmplen) == 0) {
> + *len = tmplen;
> + return (true);
> + }
> +
> + return (false);
> +}
> +
>  /*
>   * Get a delimited string.  P points to the delimiter of the string; d points
>   * to a buffer area.  Newline and delimiter escapes are processed; other
> @@ -377,6 +423,7 @@ nonsel:   /* Now parse the command */
>  static char *
>  compile_delimited(char *p, char *d, int is_tr)
>  {
> + int hexlen;
>   char c;
>  
>   c = *p++;
> @@ -412,6 +459,12 @@ compile_delimited(char *p, char *d, int is_tr)
>   }
>   p += 2;
>   continue;
> + } else if (*p == '\\' && p[1] == 'x') {
> + if (dohex([2], d, )) {
> + ++d;
> + p += hexlen + 2;
> + continue;
> + }
>   } else if (*p == '\\' && p[1] == '\\') {
>   if (is_tr)
>   p++;
> @@ -431,7 +484,7 @@ compile_delimited(char *p, char *d, int is_tr)
>  static char *
>  compile_ccl(char **sp, char *t)
>  {
> - int c, d;
> + int c, d, hexlen;
>   char *s = *sp;
>  
>   *t++ = *s++;
> @@ -459,6 +512,10 @@ compile_ccl(char **sp, char *t)
>   *t = '\t';
>   s++;
>   break;
> + case 'x':
> + if (dohex([2], t, ))
> + s += hexlen + 1;
> + break;
>   }
>   }
>   }
> @@ -499,7 +556,7 @@ static char *
>  compile_subst(char *p, struct s_subst *s)
>  {
>   static char lbuf[_POSIX2_LINE_MAX + 1];
> - int asize, size;
> + int asize, hexlen, size;
>   u_char ref;
>   char c, *text, *op, *sp;
>   int more = 1, sawesc = 0;
> @@ -562,6 +619,21 @@ compile_subst(char *p, struct s_subst *s)
>   break;
>   case 't':
>   *p = '\t';
> + break;
> + case 'x':
> +#define  ADVANCE_N(s, n) \
> + do {\
> + char *adv = (s);\
> + while (*(adv + (n) - 1) != '\0') {  \
> +

Re: svn commit: r361783 - head/usr.bin/killall

[Rodney W. Grimes]

> It seems Conrad dropped me from his reply, so I can't include it directly,
> but...
> 
> On Thu, Jun 04, 2020 at 06:12:05AM -0700, Rodney W. Grimes wrote:
> > > 04.06.2020 11:29, Benjamin Kaduk wrote:
> > > 
> > > > Author: bjk (doc committer)
> > > > Date: Thu Jun  4 04:29:43 2020
> > > > New Revision: 361783
> > > > URL: https://svnweb.freebsd.org/changeset/base/361783
> > > > 
> > > > Log:
> > > >   Add EXAMPLES to killall(1)
> > > >   
> > > >   Submitted by: fernape
> > > >   Differential Revision:https://reviews.freebsd.org/D25002
> > > > 
> > > > Modified:
> > > >   head/usr.bin/killall/killall.1
> > > > 
> > > > Modified: head/usr.bin/killall/killall.1
> > > > ==
> > > > --- head/usr.bin/killall/killall.1  Thu Jun  4 02:36:41 2020
> > > > (r361782)
> > > > +++ head/usr.bin/killall/killall.1  Thu Jun  4 04:29:43 2020
> > > > (r361783)
> > > > @@ -145,6 +145,50 @@ utility exits 0 if some processes have been found 
> > > > and
> > > >  signalled successfully.
> > > >  Otherwise, a status of 1 will be
> > > >  returned.
> > > > +.Sh EXAMPLES
> > > > +Send
> > > > +.Dv SIGTERM
> > > > +to all firefox processes:
> > > > +.Bd -literal -offset indent
> > > > +killall firefox
> > > > +.Ed
> > > > +.Pp
> > > > +Send
> > > > +.Dv SIGTERM
> > > > +to firefox processes belonging to
> > > > +.Va USER :
> > > > +.Bd -literal -offset indent
> > > > +killall -u ${USER} firefox
> > > > +.Ed
> > > > +.Pp
> > > > +Stop all firefox processes:
> > > > +.Bd -literal -offset indent
> > > > +killall -SIGSTOP firefox
> > > > +.Ed
> > > > +.Pp
> > > > +Resume firefox processes:
> > > > +.Bd -literal -offset indent
> > > > +killall -SIGCONT firefox
> > > > +.Ed
> > > > +.Pp
> > > > +Show what would be done to firefox processes, but do not actually 
> > > > signal them:
> > > > +.Bd -literal -offset indent
> > > > +killall -s firefox
> > > > +.Ed
> > > > +.Pp
> > > > +Send
> > > > +.Dv SIGKILL
> > > > +to csh process running inside jail ID 282:
> > > > +.Bd -literal -offset indent
> > > > +killall -9 -j282 csh
> > > > +.Ed
> > > > +.Pp
> > > > +Send
> > > > +.Dv SIGTERM
> > > > +to all processes matching provided pattern (like vim and vimdiff):
> > > > +.Bd -literal -offset indent
> > > > +killall -m 'vim*'
> > > > +.Ed
> > > >  .Sh DIAGNOSTICS
> > > >  Diagnostic messages will only be printed if requested by
> > > >  .Fl d
> > > 
> > > "Firefox" is a trade mark (type of intellectual property) of Mozilla 
> > > Foundation.
> > > Is it OK for us to use this name such way?
> > > 
> > > Isn't it better using a name of some utility we have in the base system 
> > > like systat(1) ?
> > 
> > Purley out of simple safety I agree here.   Though I doubt a case could
> > be made for infringement it is just too easy to do the safe thing.
> 
> I'm not aware of any issues with using a trademark-protected term to refer
> to the product named by the mark,

Actually since you fail to recognize it as a mark with a TM notice this
does have other legal issues  much as Sony didnt recognize the TM
on FreeBSD when used Mozilla could send us a nasty gram.

Probably unlikely, but still possible.

> and don't see how one could claim that
> this usage is an attempt to dilute the mark.  I don't currently plan to
> make any further changes to this example, myself (though I will not stand
> in the way if someone else wants to blandify the example).

Good enough.

> Thanks,
> Ben
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361791 - head/etc/mtree

[Rodney W. Grimes]

> On Thu, Jun 04, 2020 at 09:19:35AM -0700, Cy Schubert wrote:
> > In message <202006041604.054g4kab098...@repo.freebsd.org>, Conrad Meyer
> > writes:
> > > New Revision: 361791
> > > URL: https://svnweb.freebsd.org/changeset/base/361791
> > >
> > > Log:
> > >   Restrict default /root permissions
> > >   
> > > ...
> > > @@ -117,7 +117,7 @@
> > >  ..
> > >  rescue
> > >  ..
> > > -root
> > > +rootmode=0750
> > >  ..
> > 
> > Recent CIS benchmarks recommend 0700.

Can you provide a pointer, I would like to understand how they
came to the conclusing that 0700 is more secuire than 0750.  I
can only think of one situation, in which a member of group wheel 
does not know the password for root.

> 
> Please, let's keep a reasonable balance between security and usability.
> I often visit /root as a regular user (wheel'ed), and 0700 would make
> it real PITA.

IIRC there is a review and long discussion on this already...

> ./danfe
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361775 - in head/sys: dts/arm64/overlays modules/dtb/rpi

[Rodney W. Grimes]

> On Thu, Jun 4, 2020 at 7:27 AM Rodney W. Grimes 
> wrote:
> 
> > > On Thu, Jun 4, 2020 at 7:04 AM Rodney W. Grimes <
> > free...@gndrsh.dnsmgr.net>
> > > wrote:
> > >
> > > > > On Wed, Jun 3, 2020, 8:10 PM Pedro Giffuni  wrote:
> > > > >
> > > > > >
> > > > > > On 03/06/2020 19:59, Oleksandr Tymoshenko wrote:
> > > > > > > Rodney W. Grimes (free...@gndrsh.dnsmgr.net) wrote:
> > > > > > >> [ Charset UTF-8 unsupported, converting... ]
> > > > > > >>> Author: gonzo
> > > > > > >>> Date: Wed Jun  3 22:18:15 2020
> > > > > > >>> New Revision: 361775
> > > > > > >>> URL: https://svnweb.freebsd.org/changeset/base/361775
> > > > > > >>>
> > > > > > >>> Log:
> > > > > > >>>Add spigen overlay for Raspberry Pi 4
> > > > > > >>>
> > > > > > >>>Submitted by:gergely.czu...@harmless.hu
> > > > > > >>>
> > > > > > >>> Added:
> > > > > > >>>head/sys/dts/arm64/overlays/spigen-rpi4.dtso   (contents,
> > props
> > > > > > changed)
> > > > > > >>> Modified:
> > > > > > >>>head/sys/modules/dtb/rpi/Makefile
> > > > > > >>>
> > > > > > >>> Added: head/sys/dts/arm64/overlays/spigen-rpi4.dtso
> > > > > > >>>
> > > > > >
> > > >
> > ==
> > > > > > >>> --- /dev/null   00:00:00 1970   (empty, because file is
> > newly
> > > > > > added)
> > > > > > >>> +++ head/sys/dts/arm64/overlays/spigen-rpi4.dtsoWed Jun  3
> > > > > > 22:18:15 2020(r361775)
> > > > > > >>> @@ -0,0 +1,30 @@
> > > > > > >>> +/* $FreeBSD$ */
> > > > > > >> This file needs some form of copyright/license.
> > > > > > > Whom should I put as a copyright folder, The FreeBSD Project or
> > the
> > > > > > > person who submitted the patch?
> > > > > >
> > > > > > The person that submitted the patch.
> > > > > >
> > > > >
> > > > > If it can be copyrighted.
> > > > >
> > > > > Note that the FreeBSD Project is not an entity and cannot hold
> > > > > > copyrights
> > > > >
> > > > >
> > > > > True, but the FreeBSD Project can be the name in the copyright line.
> > It
> > > > is
> > > > > the eponymous author of the FreeBSD collection.
> > > >
> > > > Thats a very slippery slope, though US copyright law allows pseudonyms
> > > > as the copyright holder, I know of nothing that allows eponymous names.
> > > > And I do not believe pseudonyms are support in other jurisdiction.
> > > >
> > > > https://www.copyright.gov/fls/fl101.pdf
> > >
> > >
> > > It is not. Legally, there's no real difference from a pseudonym and an
> > > eponymous name. How could there be?
> >
> > Based on what?   eponymous appears no place in the copyright law, so
> > I shall strongly disagree with you on that point.
> >
> 
> An eponym is a type of pseudonym. It's not a nickname, nor an abbreviated
> form of a company.

And the usage "The FreeBSD Project" does not meet the definition of
either:

eponym
  A person after whom a discovery, invention, place, etc., is named or thought 
to be named.

pseudonym
  A fictitious name, especially one used by an author.

My keypoint is "A/AN PERSON".   

> > I should have added that the project decided, years ago, to only use it
> > for
> > > the collection copyright holder in the /COPYRIGHT file. All other files
> >
> > It appears as if it is used many other places, as my find/grep showed.
> >
> 
> Yes. And apart from the 3 files I identified, the others should be fixed. I
> did this the last time we did a sweep maybe in the late 90s / early 2000s
> based on advice from an IP attorney who specialized in open source. For
> various reasons, it's fine in the collection copyright context, but we
> don't want to have it anywhere else if we can help it.

I find it very hard to believe that using anything in 3 copyrights is
somehow valid if it can not be used in all copyrights.  That,  again,
is just a slippery slope.

Further, let me speculate, more "Free" advice?  Free legal advice is
worth exactly what you paid for it, nothing.  Especially if you do not
have the advice in writting.

> Warner
> 
> 
> > > require an actual copyright holder at the time of submission. The project
> > > generally doesn't track successors in interest, though there are
> > exceptions
> > > when the copyright holder themselves make the change.
> > >
> > > Warner
> > >
> > >
> > > >
> > > > > (The Foundation can but unless they sponsored it, that
> > > > > > usually involves paperwork).
> > > > > >
> > > > >
> > > > > Yup.
> > > > >
> > > > > Warner
> > > > >
> > > > > > Pedro.
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > Rod Grimes
> > > > rgri...@freebsd.org
> > > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361775 - in head/sys: dts/arm64/overlays modules/dtb/rpi

[Rodney W. Grimes]

> On Thu, Jun 4, 2020 at 6:54 AM Rodney W. Grimes 
> wrote:
> 
> > >
> > > On 03/06/2020 19:59, Oleksandr Tymoshenko wrote:
> > > > Rodney W. Grimes (free...@gndrsh.dnsmgr.net) wrote:
> > > >> [ Charset UTF-8 unsupported, converting... ]
> > > >>> Author: gonzo
> > > >>> Date: Wed Jun  3 22:18:15 2020
> > > >>> New Revision: 361775
> > > >>> URL: https://svnweb.freebsd.org/changeset/base/361775
> > > >>>
> > > >>> Log:
> > > >>>Add spigen overlay for Raspberry Pi 4
> > > >>>
> > > >>>Submitted by:  gergely.czu...@harmless.hu
> > > >>>
> > > >>> Added:
> > > >>>head/sys/dts/arm64/overlays/spigen-rpi4.dtso   (contents, props
> > changed)
> > > >>> Modified:
> > > >>>head/sys/modules/dtb/rpi/Makefile
> > > >>>
> > > >>> Added: head/sys/dts/arm64/overlays/spigen-rpi4.dtso
> > > >>>
> > ==
> > > >>> --- /dev/null 00:00:00 1970   (empty, because file is newly
> > added)
> > > >>> +++ head/sys/dts/arm64/overlays/spigen-rpi4.dtso  Wed Jun  3
> > 22:18:15 2020(r361775)
> > > >>> @@ -0,0 +1,30 @@
> > > >>> +/* $FreeBSD$ */
> > > >> This file needs some form of copyright/license.
> > > > Whom should I put as a copyright folder, The FreeBSD Project or the
> > > > person who submitted the patch?
> > >
> > > The person that submitted the patch.
> > >
> > > Note that the FreeBSD Project is not an entity and cannot hold
> > > copyrights (The Foundation can but unless they sponsored it, that
> > > usually involves paperwork).
> >
> > I am glad at least one other person understands that point in law:
> >
> > :root {1002}# find . -type f | xargs grep Copyright | grep -i freebsd |
> > grep -i project
> > ./cddl/compat/opensolaris/kern/opensolaris_dtrace.c: * Copyright 2014 The
> > FreeBSD Project.
> > ./net/if_enc.h: * Copyright (c) 2008 The FreeBSD Project.
> > ./net/if_enc.c: * Copyright (c) 2006 The FreeBSD Project.
> > ./kern/kern_idle.c: * Copyright (C) 2000-2004 The FreeBSD Project. All
> > rights reserved.
> 
> ./kern/subr_kdb.c: * Copyright (c) 2004 The FreeBSD Project
> >
> 
> These should be changed to the actual author.
> 
> 
> > ./conf/newvers.sh:  year=$(sed -Ee '/^Copyright .* The FreeBSD
> > Project/!d;s/^.*1992-([0-9]*) .*$/\1/g' ${SYSDIR}/../COPYRIGHT)
> > ./conf/newvers.sh: * Copyright (c) 1992-$year The FreeBSD Project.
> > ./sys/copyright.h: * Copyright (C) 1992-2018 The FreeBSD Project. All
> > rights reserved.
> > ./sys/copyright.h:  "Copyright (c) 1992-2019 The FreeBSD Project.\n"
> > ^^^  The copyright we spit out on every boot :-(
> >
> 
> These four are fine. They were cleared by lawyers long ago. This is a point
> that was extensively litigated during your absence and has been settled

There was a lawsuit?  

Cleared by which lawyers, you have some documentation of opinion?

> practice for a long, long time. Those four instances and /COPYRIGHT are the
> only places in the tree we should have this, however.

One can operate outside the law... until one gets caught.  As can be
seen just having this copyright statement in the tree has lead to others
to copy it thinking it was ok, and those "tending the house" did not
catch it.

> 
> ./compat/linux/linux_uid16.c: * Copyright (c) 2001  The FreeBSD Project
> > ./tools/embed_mfs.sh:# Copyright (C) 2008 The FreeBSD Project. All rights
> > reserved.
> > ./dev/mfi/mfi_syspd.c: *Copyright 1994-2009 The FreeBSD
> > Project.
> > ./dev/mfi/mfi_tbolt.c: *Copyright 1994-2009 The FreeBSD
> > Project.
> > ./dev/chromebook_platform/chromebook_platform.c: * Copyright (c) 2016 The
> > FreeBSD Project.
> > ./dev/pccard/pccarddevs: * Copyright (c) 1999-2004 The FreeBSD Project.
> > ./dev/tdfx/tdfx_linux.c: * Copyright (c) 2006 The FreeBSD Project
> > ./powerpc/powerpc/uma_machdep.c: * Copyright (c) 2003 The FreeBSD Project
> > ./libkern/memset.c: * Copyright (C) 1992-2007 The FreeBSD Project. All
> > rights reserved.
> >
> 
> These are also not fine and should be similarly changed.
> 
> It would be a great project for someone to do the svn diving and find who
> committed those files originally and correct it.
> 
> Warner
> > > Pedro.
> > --
> > Rod Grimes
> > rgri...@freebsd.org
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361775 - in head/sys: dts/arm64/overlays modules/dtb/rpi

[Rodney W. Grimes]

> On Thu, Jun 4, 2020 at 7:04 AM Rodney W. Grimes 
> wrote:
> 
> > > On Wed, Jun 3, 2020, 8:10 PM Pedro Giffuni  wrote:
> > >
> > > >
> > > > On 03/06/2020 19:59, Oleksandr Tymoshenko wrote:
> > > > > Rodney W. Grimes (free...@gndrsh.dnsmgr.net) wrote:
> > > > >> [ Charset UTF-8 unsupported, converting... ]
> > > > >>> Author: gonzo
> > > > >>> Date: Wed Jun  3 22:18:15 2020
> > > > >>> New Revision: 361775
> > > > >>> URL: https://svnweb.freebsd.org/changeset/base/361775
> > > > >>>
> > > > >>> Log:
> > > > >>>Add spigen overlay for Raspberry Pi 4
> > > > >>>
> > > > >>>Submitted by:gergely.czu...@harmless.hu
> > > > >>>
> > > > >>> Added:
> > > > >>>head/sys/dts/arm64/overlays/spigen-rpi4.dtso   (contents, props
> > > > changed)
> > > > >>> Modified:
> > > > >>>head/sys/modules/dtb/rpi/Makefile
> > > > >>>
> > > > >>> Added: head/sys/dts/arm64/overlays/spigen-rpi4.dtso
> > > > >>>
> > > >
> > ==
> > > > >>> --- /dev/null   00:00:00 1970   (empty, because file is newly
> > > > added)
> > > > >>> +++ head/sys/dts/arm64/overlays/spigen-rpi4.dtsoWed Jun  3
> > > > 22:18:15 2020(r361775)
> > > > >>> @@ -0,0 +1,30 @@
> > > > >>> +/* $FreeBSD$ */
> > > > >> This file needs some form of copyright/license.
> > > > > Whom should I put as a copyright folder, The FreeBSD Project or the
> > > > > person who submitted the patch?
> > > >
> > > > The person that submitted the patch.
> > > >
> > >
> > > If it can be copyrighted.
> > >
> > > Note that the FreeBSD Project is not an entity and cannot hold
> > > > copyrights
> > >
> > >
> > > True, but the FreeBSD Project can be the name in the copyright line. It
> > is
> > > the eponymous author of the FreeBSD collection.
> >
> > Thats a very slippery slope, though US copyright law allows pseudonyms
> > as the copyright holder, I know of nothing that allows eponymous names.
> > And I do not believe pseudonyms are support in other jurisdiction.
> >
> > https://www.copyright.gov/fls/fl101.pdf
> 
> 
> It is not. Legally, there's no real difference from a pseudonym and an
> eponymous name. How could there be?

Based on what?   eponymous appears no place in the copyright law, so
I shall strongly disagree with you on that point.

> 
> I should have added that the project decided, years ago, to only use it for
> the collection copyright holder in the /COPYRIGHT file. All other files

It appears as if it is used many other places, as my find/grep showed.

> require an actual copyright holder at the time of submission. The project
> generally doesn't track successors in interest, though there are exceptions
> when the copyright holder themselves make the change.
> 
> Warner
> 
> 
> >
> > > (The Foundation can but unless they sponsored it, that
> > > > usually involves paperwork).
> > > >
> > >
> > > Yup.
> > >
> > > Warner
> > >
> > > > Pedro.
> > > >
> > > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361783 - head/usr.bin/killall

[Rodney W. Grimes]

> 04.06.2020 11:29, Benjamin Kaduk wrote:
> 
> > Author: bjk (doc committer)
> > Date: Thu Jun  4 04:29:43 2020
> > New Revision: 361783
> > URL: https://svnweb.freebsd.org/changeset/base/361783
> > 
> > Log:
> >   Add EXAMPLES to killall(1)
> >   
> >   Submitted by: fernape
> >   Differential Revision:https://reviews.freebsd.org/D25002
> > 
> > Modified:
> >   head/usr.bin/killall/killall.1
> > 
> > Modified: head/usr.bin/killall/killall.1
> > ==
> > --- head/usr.bin/killall/killall.1  Thu Jun  4 02:36:41 2020
> > (r361782)
> > +++ head/usr.bin/killall/killall.1  Thu Jun  4 04:29:43 2020
> > (r361783)
> > @@ -145,6 +145,50 @@ utility exits 0 if some processes have been found and
> >  signalled successfully.
> >  Otherwise, a status of 1 will be
> >  returned.
> > +.Sh EXAMPLES
> > +Send
> > +.Dv SIGTERM
> > +to all firefox processes:
> > +.Bd -literal -offset indent
> > +killall firefox
> > +.Ed
> > +.Pp
> > +Send
> > +.Dv SIGTERM
> > +to firefox processes belonging to
> > +.Va USER :
> > +.Bd -literal -offset indent
> > +killall -u ${USER} firefox
> > +.Ed
> > +.Pp
> > +Stop all firefox processes:
> > +.Bd -literal -offset indent
> > +killall -SIGSTOP firefox
> > +.Ed
> > +.Pp
> > +Resume firefox processes:
> > +.Bd -literal -offset indent
> > +killall -SIGCONT firefox
> > +.Ed
> > +.Pp
> > +Show what would be done to firefox processes, but do not actually signal 
> > them:
> > +.Bd -literal -offset indent
> > +killall -s firefox
> > +.Ed
> > +.Pp
> > +Send
> > +.Dv SIGKILL
> > +to csh process running inside jail ID 282:
> > +.Bd -literal -offset indent
> > +killall -9 -j282 csh
> > +.Ed
> > +.Pp
> > +Send
> > +.Dv SIGTERM
> > +to all processes matching provided pattern (like vim and vimdiff):
> > +.Bd -literal -offset indent
> > +killall -m 'vim*'
> > +.Ed
> >  .Sh DIAGNOSTICS
> >  Diagnostic messages will only be printed if requested by
> >  .Fl d
> 
> "Firefox" is a trade mark (type of intellectual property) of Mozilla 
> Foundation.
> Is it OK for us to use this name such way?
> 
> Isn't it better using a name of some utility we have in the base system like 
> systat(1) ?

Purley out of simple safety I agree here.   Though I doubt a case could
be made for infringement it is just too easy to do the safe thing.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361775 - in head/sys: dts/arm64/overlays modules/dtb/rpi

[Rodney W. Grimes]

> On Wed, Jun 3, 2020, 8:10 PM Pedro Giffuni  wrote:
> 
> >
> > On 03/06/2020 19:59, Oleksandr Tymoshenko wrote:
> > > Rodney W. Grimes (free...@gndrsh.dnsmgr.net) wrote:
> > >> [ Charset UTF-8 unsupported, converting... ]
> > >>> Author: gonzo
> > >>> Date: Wed Jun  3 22:18:15 2020
> > >>> New Revision: 361775
> > >>> URL: https://svnweb.freebsd.org/changeset/base/361775
> > >>>
> > >>> Log:
> > >>>Add spigen overlay for Raspberry Pi 4
> > >>>
> > >>>Submitted by:gergely.czu...@harmless.hu
> > >>>
> > >>> Added:
> > >>>head/sys/dts/arm64/overlays/spigen-rpi4.dtso   (contents, props
> > changed)
> > >>> Modified:
> > >>>head/sys/modules/dtb/rpi/Makefile
> > >>>
> > >>> Added: head/sys/dts/arm64/overlays/spigen-rpi4.dtso
> > >>>
> > ==
> > >>> --- /dev/null   00:00:00 1970   (empty, because file is newly
> > added)
> > >>> +++ head/sys/dts/arm64/overlays/spigen-rpi4.dtsoWed Jun  3
> > 22:18:15 2020(r361775)
> > >>> @@ -0,0 +1,30 @@
> > >>> +/* $FreeBSD$ */
> > >> This file needs some form of copyright/license.
> > > Whom should I put as a copyright folder, The FreeBSD Project or the
> > > person who submitted the patch?
> >
> > The person that submitted the patch.
> >
> 
> If it can be copyrighted.
> 
> Note that the FreeBSD Project is not an entity and cannot hold
> > copyrights
> 
> 
> True, but the FreeBSD Project can be the name in the copyright line. It is
> the eponymous author of the FreeBSD collection.

Thats a very slippery slope, though US copyright law allows pseudonyms
as the copyright holder, I know of nothing that allows eponymous names.
And I do not believe pseudonyms are support in other jurisdiction.

https://www.copyright.gov/fls/fl101.pdf

> (The Foundation can but unless they sponsored it, that
> > usually involves paperwork).
> >
> 
> Yup.
> 
> Warner
> 
> > Pedro.
> >
> >

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361775 - in head/sys: dts/arm64/overlays modules/dtb/rpi

[Rodney W. Grimes]

> On Wed, Jun 3, 2020, 6:28 PM Rodney W. Grimes 
> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > > Author: gonzo
> > > Date: Wed Jun  3 22:18:15 2020
> > > New Revision: 361775
> > > URL: https://svnweb.freebsd.org/changeset/base/361775
> > >
> > > Log:
> > >   Add spigen overlay for Raspberry Pi 4
> > >
> > >   Submitted by:   gergely.czu...@harmless.hu
> > >
> > > Added:
> > >   head/sys/dts/arm64/overlays/spigen-rpi4.dtso   (contents, props
> > changed)
> > > Modified:
> > >   head/sys/modules/dtb/rpi/Makefile
> > >
> > > Added: head/sys/dts/arm64/overlays/spigen-rpi4.dtso
> > >
> > ==
> > > --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> > > +++ head/sys/dts/arm64/overlays/spigen-rpi4.dtso  Wed Jun  3
> > 22:18:15 2020(r361775)
> > > @@ -0,0 +1,30 @@
> > > +/* $FreeBSD$ */
> >
> > This file needs some form of copyright/license.
> >
> 
> Dts files are like database files: they likely have no copyright
> protection.

THough I concur on that, it seems the project has lost much insite
on that, as has the industry.  I now see copyrights and licenses
on almost any thing in our tree, shell scripts, Makefiles, etc, etc...

If we infact feel these files are non copyrightable/licensable perhaps
they should have a statement making that clear?  The Berne convention
leaves files with no copyright/license statement in them subject to
dispute.


> Warner
> 
> 
> > +
> > > +/dts-v1/;
> > > +/plugin/;
> > > +
> > > +/ {
> > > + compatible = "brcm,bcm2711";
> > > +};
> > > +
> > > +&{/soc/spi@7e204000} {
> > > + status = "okay";
> > > + spigen0: spigen0 {
> > > + compatible = "freebsd,spigen";
> > > + reg = <0>;
> > > + spi-max-frequency = <50>; /* Req'd property, override
> > with spi(8) */
> > > + status = "okay";
> > > + };
> > > + spigen1: spigen1 {
> > > + compatible = "freebsd,spigen";
> > > + reg = <1>;
> > > + spi-max-frequency = <50>; /* Req'd property, override
> > with spi(8) */
> > > + status = "okay";
> > > + };
> > > +};
> > > +
> > > +&{/soc/gpio@7e20/spi0_cs_pins} {
> > > + brcm,pins = <8 7>;
> > > + brcm,function = <4>; /* ALT0 */
> > > +};
> > > +
> > >
> > > Modified: head/sys/modules/dtb/rpi/Makefile
> > >
> > ==
> > > --- head/sys/modules/dtb/rpi/Makefile Wed Jun  3 22:15:11 2020
> > (r361774)
> > > +++ head/sys/modules/dtb/rpi/Makefile Wed Jun  3 22:18:15 2020
> > (r361775)
> > > @@ -6,7 +6,8 @@ DTSO= \
> > >   spigen-rpi2.dtso
> > >  .elif ${MACHINE_ARCH} == "aarch64"
> > >  DTSO=\
> > > - spigen-rpi3.dtso
> > > + spigen-rpi3.dtso \
> > > + spigen-rpi4.dtso
> > >  .endif
> > >
> > >  .include 
> > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361782 - head/sys/dts/arm64/overlays

[Rodney W. Grimes]

> Author: gonzo
> Date: Thu Jun  4 02:36:41 2020
> New Revision: 361782
> URL: https://svnweb.freebsd.org/changeset/base/361782
> 
> Log:
>   Add copyright headers to spigen overlays for rpi3 and rpi4
>   
>   Reported by:Rodney W. Grimes  (for rpi4)


Thank you, and you did obtain Bob's permission I hope?

> Modified:
>   head/sys/dts/arm64/overlays/spigen-rpi3.dtso
>   head/sys/dts/arm64/overlays/spigen-rpi4.dtso
> 
> Modified: head/sys/dts/arm64/overlays/spigen-rpi3.dtso
> ==
> --- head/sys/dts/arm64/overlays/spigen-rpi3.dtso  Thu Jun  4 01:49:29 
> 2020(r361781)
> +++ head/sys/dts/arm64/overlays/spigen-rpi3.dtso  Thu Jun  4 02:36:41 
> 2020(r361782)
> @@ -1,4 +1,31 @@
> -/* $FreeBSD$ */
> +/*-
> + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
> + *
> + * Copyright (c) 2019 Bob Frazier 
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + *
> + * $FreeBSD$
> + */
>  
>  /dts-v1/;
>  /plugin/;
> 
> Modified: head/sys/dts/arm64/overlays/spigen-rpi4.dtso
> ==
> --- head/sys/dts/arm64/overlays/spigen-rpi4.dtso  Thu Jun  4 01:49:29 
> 2020(r361781)
> +++ head/sys/dts/arm64/overlays/spigen-rpi4.dtso  Thu Jun  4 02:36:41 
> 2020(r361782)
> @@ -1,4 +1,31 @@
> -/* $FreeBSD$ */
> +/*-
> + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
> + *
> + * Copyright (c) 2020 Gergely Czuczy 
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + *
> + * $FreeBSD$
> + */
>  
>  /dts-v1/;
>  /plugin/;
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361775 - in head/sys: dts/arm64/overlays modules/dtb/rpi

[Rodney W. Grimes]

> 
> On 03/06/2020 19:59, Oleksandr Tymoshenko wrote:
> > Rodney W. Grimes (free...@gndrsh.dnsmgr.net) wrote:
> >> [ Charset UTF-8 unsupported, converting... ]
> >>> Author: gonzo
> >>> Date: Wed Jun  3 22:18:15 2020
> >>> New Revision: 361775
> >>> URL: https://svnweb.freebsd.org/changeset/base/361775
> >>>
> >>> Log:
> >>>Add spigen overlay for Raspberry Pi 4
> >>>
> >>>Submitted by:  gergely.czu...@harmless.hu
> >>>
> >>> Added:
> >>>head/sys/dts/arm64/overlays/spigen-rpi4.dtso   (contents, props 
> >>> changed)
> >>> Modified:
> >>>head/sys/modules/dtb/rpi/Makefile
> >>>
> >>> Added: head/sys/dts/arm64/overlays/spigen-rpi4.dtso
> >>> ==
> >>> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> >>> +++ head/sys/dts/arm64/overlays/spigen-rpi4.dtso  Wed Jun  3 22:18:15 
> >>> 2020(r361775)
> >>> @@ -0,0 +1,30 @@
> >>> +/* $FreeBSD$ */
> >> This file needs some form of copyright/license.
> > Whom should I put as a copyright folder, The FreeBSD Project or the
> > person who submitted the patch?
> 
> The person that submitted the patch.
> 
> Note that the FreeBSD Project is not an entity and cannot hold 
> copyrights (The Foundation can but unless they sponsored it, that 
> usually involves paperwork).

I am glad at least one other person understands that point in law:

:root {1002}# find . -type f | xargs grep Copyright | grep -i freebsd | grep -i 
project
./cddl/compat/opensolaris/kern/opensolaris_dtrace.c: * Copyright 2014 The 
FreeBSD Project.
./net/if_enc.h: * Copyright (c) 2008 The FreeBSD Project.
./net/if_enc.c: * Copyright (c) 2006 The FreeBSD Project.
./kern/kern_idle.c: * Copyright (C) 2000-2004 The FreeBSD Project. All rights 
reserved.
./kern/subr_kdb.c: * Copyright (c) 2004 The FreeBSD Project
./conf/newvers.sh:  year=$(sed -Ee '/^Copyright .* The FreeBSD 
Project/!d;s/^.*1992-([0-9]*) .*$/\1/g' ${SYSDIR}/../COPYRIGHT)
./conf/newvers.sh: * Copyright (c) 1992-$year The FreeBSD Project.
./sys/copyright.h: * Copyright (C) 1992-2018 The FreeBSD Project. All rights 
reserved.
./sys/copyright.h:  "Copyright (c) 1992-2019 The FreeBSD Project.\n"
^^^  The copyright we spit out on every boot :-(

./compat/linux/linux_uid16.c: * Copyright (c) 2001  The FreeBSD Project
./tools/embed_mfs.sh:# Copyright (C) 2008 The FreeBSD Project. All rights 
reserved.
./dev/mfi/mfi_syspd.c: *Copyright 1994-2009 The FreeBSD Project.
./dev/mfi/mfi_tbolt.c: *Copyright 1994-2009 The FreeBSD Project.
./dev/chromebook_platform/chromebook_platform.c: * Copyright (c) 2016 The 
FreeBSD Project.
./dev/pccard/pccarddevs: * Copyright (c) 1999-2004 The FreeBSD Project.
./dev/tdfx/tdfx_linux.c: * Copyright (c) 2006 The FreeBSD Project
./powerpc/powerpc/uma_machdep.c: * Copyright (c) 2003 The FreeBSD Project
./libkern/memset.c: * Copyright (C) 1992-2007 The FreeBSD Project. All rights 
reserved.

> 
> Pedro.
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361775 - in head/sys: dts/arm64/overlays modules/dtb/rpi

[Rodney W. Grimes]

> Rodney W. Grimes (free...@gndrsh.dnsmgr.net) wrote:
> > [ Charset UTF-8 unsupported, converting... ]
> > > Author: gonzo
> > > Date: Wed Jun  3 22:18:15 2020
> > > New Revision: 361775
> > > URL: https://svnweb.freebsd.org/changeset/base/361775
> > > 
> > > Log:
> > >   Add spigen overlay for Raspberry Pi 4
> > >   
> > >   Submitted by:   gergely.czu...@harmless.hu
> > > 
> > > Added:
> > >   head/sys/dts/arm64/overlays/spigen-rpi4.dtso   (contents, props changed)
> > > Modified:
> > >   head/sys/modules/dtb/rpi/Makefile
> > > 
> > > Added: head/sys/dts/arm64/overlays/spigen-rpi4.dtso
> > > ==
> > > --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> > > +++ head/sys/dts/arm64/overlays/spigen-rpi4.dtso  Wed Jun  3 22:18:15 
> > > 2020(r361775)
> > > @@ -0,0 +1,30 @@
> > > +/* $FreeBSD$ */
> > 
> > This file needs some form of copyright/license.
> 
> Whom should I put as a copyright folder, The FreeBSD Project or the
> person who submitted the patch?

You need to obtain there permission too, you can not just slap
someones name in a copyright statement.  They can also make the
file "in the public domain".

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361775 - in head/sys: dts/arm64/overlays modules/dtb/rpi

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: gonzo
> Date: Wed Jun  3 22:18:15 2020
> New Revision: 361775
> URL: https://svnweb.freebsd.org/changeset/base/361775
> 
> Log:
>   Add spigen overlay for Raspberry Pi 4
>   
>   Submitted by:   gergely.czu...@harmless.hu
> 
> Added:
>   head/sys/dts/arm64/overlays/spigen-rpi4.dtso   (contents, props changed)
> Modified:
>   head/sys/modules/dtb/rpi/Makefile
> 
> Added: head/sys/dts/arm64/overlays/spigen-rpi4.dtso
> ==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ head/sys/dts/arm64/overlays/spigen-rpi4.dtso  Wed Jun  3 22:18:15 
> 2020(r361775)
> @@ -0,0 +1,30 @@
> +/* $FreeBSD$ */

This file needs some form of copyright/license.

> +
> +/dts-v1/;
> +/plugin/;
> +
> +/ {
> + compatible = "brcm,bcm2711";
> +};
> + 
> +&{/soc/spi@7e204000} {
> + status = "okay";
> + spigen0: spigen0 {
> + compatible = "freebsd,spigen";
> + reg = <0>;
> + spi-max-frequency = <50>; /* Req'd property, override with 
> spi(8) */
> + status = "okay";
> + };
> + spigen1: spigen1 {
> + compatible = "freebsd,spigen";
> + reg = <1>;
> + spi-max-frequency = <50>; /* Req'd property, override with 
> spi(8) */
> + status = "okay";
> + };
> +};
> +
> +&{/soc/gpio@7e20/spi0_cs_pins} {
> + brcm,pins = <8 7>;
> + brcm,function = <4>; /* ALT0 */
> +};
> +
> 
> Modified: head/sys/modules/dtb/rpi/Makefile
> ==
> --- head/sys/modules/dtb/rpi/Makefile Wed Jun  3 22:15:11 2020
> (r361774)
> +++ head/sys/modules/dtb/rpi/Makefile Wed Jun  3 22:18:15 2020
> (r361775)
> @@ -6,7 +6,8 @@ DTSO= \
>   spigen-rpi2.dtso
>  .elif ${MACHINE_ARCH} == "aarch64"
>  DTSO=\
> - spigen-rpi3.dtso
> + spigen-rpi3.dtso \
> + spigen-rpi4.dtso
>  .endif
>  
>  .include 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361752 - head/sys/netinet

[Rodney W. Grimes]

> Author: rrs
> Date: Wed Jun  3 14:16:40 2020
> New Revision: 361752
> URL: https://svnweb.freebsd.org/changeset/base/361752
> 
> Log:
>   We should never allow either the broadcast or IN_ADDR_ANY to be
>   connected to or sent to. This was fond when working with Michael
>   Tuexen and Skyzaller. Skyzaller seems to want to use either of
>   these two addresses to connect to at times. And it really is
>   an error to do so, so lets not allow that behavior.

It would be preferable if possible to use the macros from
netinet/in.h.
#define INADDR_ANY  ((in_addr_t)0x)
#define in_nullhost(x)  ((x).s_addr == INADDR_ANY)

There is an in_broadcast, but thats a function doing a
more complicated test checking for all possible local
broadcast addresses, which may be what you really want
to do here.

I am also finding it odd that we need to do this at the TCP layer,
there should already be stuff in place that prevents this from
occuring at the IP layer.  I guess this stuff is setup and ends
up in a tcb, that later fails when it goes to xmit a packet?

>   
>   Sponsored by:   Netflix Inc.
>   Differential Revision:  https://reviews.freebsd.org/D24852
> 
> Modified:
>   head/sys/netinet/tcp_usrreq.c
> 
> Modified: head/sys/netinet/tcp_usrreq.c
> ==
> --- head/sys/netinet/tcp_usrreq.c Wed Jun  3 14:07:31 2020
> (r361751)
> +++ head/sys/netinet/tcp_usrreq.c Wed Jun  3 14:16:40 2020
> (r361752)
> @@ -552,6 +552,10 @@ tcp_usr_connect(struct socket *so, struct sockaddr *na
>   if (sinp->sin_family == AF_INET
>   && IN_MULTICAST(ntohl(sinp->sin_addr.s_addr)))
>   return (EAFNOSUPPORT);
> + if ((sinp->sin_family == AF_INET) &&
> + ((ntohl(sinp->sin_addr.s_addr) == INADDR_BROADCAST) ||
> +  (sinp->sin_addr.s_addr == INADDR_ANY)))
> + return(EAFNOSUPPORT);
>   if ((error = prison_remote_ip4(td->td_ucred, >sin_addr)) != 0)
>   return (error);
>  
> @@ -652,6 +656,11 @@ tcp6_usr_connect(struct socket *so, struct sockaddr *n
>   error = EAFNOSUPPORT;
>   goto out;
>   }
> + if ((ntohl(sin.sin_addr.s_addr) == INADDR_BROADCAST) ||
> + (sin.sin_addr.s_addr == INADDR_ANY)) {
> + error = EAFNOSUPPORT;
> + goto out;
> + }
>   if ((error = prison_remote_ip4(td->td_ucred,
>   _addr)) != 0)
>   goto out;
> @@ -1019,6 +1028,13 @@ tcp_usr_send(struct socket *so, int flags, struct mbuf
>   goto out;
>   }
>   if (IN_MULTICAST(ntohl(sinp->sin_addr.s_addr))) {
> + if (m)
> + m_freem(m);
> + error = EAFNOSUPPORT;
> + goto out;
> + }
> + if ((ntohl(sinp->sin_addr.s_addr) == INADDR_BROADCAST) 
> ||
> + (sinp->sin_addr.s_addr == INADDR_ANY)) {
>   if (m)
>   m_freem(m);
>   error = EAFNOSUPPORT;
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361721 - head/contrib/ipfilter/man

[Rodney W. Grimes]

> In message <202006021419.052ejopl017...@gndrsh.dnsmgr.net>, "Rodney W. 
> Grimes"
> writes:
> > > Author: cy
> > > Date: Tue Jun  2 03:44:22 2020
> > > New Revision: 361721
> > > URL: https://svnweb.freebsd.org/changeset/base/361721
> > > 
> > > Log:
> > >   Per-rule hit counts (-h) can be used with either -i (input) or -o 
> > > (output
> > )
> > >   filter rule lists.
> >
> > This change does not make that explicitly apparent, as it simply
> > removes that -h -i is valid, but that means -h [-i|-o] is implicit.
> 
> The man page and corresponding verification options needs some work. For 
> instance -n also doesn't mean anything without either -i and/or -o. ipfstat 
> needs the same love that's been shown to ippool. Noted and on my todo list.
> 

Thank you.  

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361721 - head/contrib/ipfilter/man

[Rodney W. Grimes]

> Author: cy
> Date: Tue Jun  2 03:44:22 2020
> New Revision: 361721
> URL: https://svnweb.freebsd.org/changeset/base/361721
> 
> Log:
>   Per-rule hit counts (-h) can be used with either -i (input) or -o (output)
>   filter rule lists.

This change does not make that explicitly apparent, as it simply
removes that -h -i is valid, but that means -h [-i|-o] is implicit.

>   
>   MFC after:  3 days
> 
> Modified:
>   head/contrib/ipfilter/man/ipfstat.8
> 
> Modified: head/contrib/ipfilter/man/ipfstat.8
> ==
> --- head/contrib/ipfilter/man/ipfstat.8   Tue Jun  2 02:38:54 2020
> (r361720)
> +++ head/contrib/ipfilter/man/ipfstat.8   Tue Jun  2 03:44:22 2020
> (r361721)
> @@ -69,8 +69,7 @@ the kernel) if any is present.
>  Show groups currently configured (both active and inactive).
>  .TP
>  .B \-h
> -Show per-rule the number of times each one scores a "hit".  For use in
> -combination with \fB\-i\fP.
> +Show per-rule the number of times each one scores a "hit".

+ For use in combination with \fB-i\fP or \fB-o\P.

Also which does -h list by default if neither -i or -o is given?
Is that even valid?

>  .TP
>  .B \-i
>  Display the filter list used for the input side of the kernel IP processing.
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsvn_diff lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/lib

[Rodney W. Grimes]

> -Original Message-
> From:  on behalf of "Rodney W. Grimes" 
> 
> Reply-To: 
> Date: 2020-06-01, Monday at 09:40
> To: Ian Lepore 
> Cc: Dimitry Andric , , 
> , 
> Subject: Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr 
> lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta 
> lib/libsvn_diff lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/libs...
> 
> > On Sun, 2020-05-31 at 22:04 +, Dimitry Andric wrote:
> > > Author: dim
> > > Date: Sun May 31 22:04:51 2020
> > > New Revision: 361677
> > > URL: https://svnweb.freebsd.org/changeset/base/361677
> > > 
> > > Log:
> > >   Change Makefiles under usr.bin/svn to make them easier to
> > > incrementally
> > >   update. No functional change intended.
> > >   
> > >   MFC after:  2 weeks
> > > 
> > 
> > I wish we could get style.Makefile(9) updated to mandate this 1-per-
> > line style when listing sources, dirs, etc, when the number of items is
> > greater than N, where N is something like 3-6 filenames.  Otherwise the
> > requirement to sort the names alphabetically pretty much mandates that
> > many lines of the file will change just to insert one or two new files,
> > and that makes it all but impossible to figure out from a diff what
> > actually changed.
> 
> I like this idea, though rather than 3-6 filenames I propose
> it to be anything longer than 3 lines, which is kinda about when
> the pain point should start.  See the immediate SUBDIR below, it
> is 11 items on 2ish/3 lines, and any change would worst case be a
> 3 line diff.  This probably covers a large portion of the tree.
> 
> FWIW, I'm partial to the 'FOO+=bar' syntax, rather than continuation lines. 
> It's too easy to forget to add the continuation when appending or inserting.

That is indeed a better technique.

> 
> I particularly do not like massive amounts of vertical white
> space which this would create, but lacking an automated tool
> this is probably a reasonable compromise.
> 
> If we did it everywhere it would mean lots of scrolling when
> working on rather simple makefiles.
> 
> I generally feel the opposite -- I do a destressing amount of work on an 
> 80x24 serial console :-/ -- but I agree that "> 3 lines" is a reasonable 
> compromise.

I think we have had a communications breakdown?  To me it sounds as we
both agree that needlessly making Makefiles vertically long is
not wanted, but acceptable when folding these very long lists
onto wide lines creates a different problem.

> -Ravi (rpokala@)
> 
> > -- Ian
> > 
> > > 
> > [...] 
> > > -SUBDIR=  lib .WAIT \
> > > - svn svnadmin svnbench svndumpfilter svnfsfs svnlook svnserve \
> > > - svnsync svnversion svnmucc svnrdump
> > > +SUBDIR=  lib \
> > > + .WAIT \
> > > + svn \
> > > + svnadmin \
> > > + svnbench \
> > > + svndumpfilter \
> > > + svnfsfs \
> > > + svnlook \
> > > + svnserve \
> > > + svnsync \
> > > + svnversion \
> > > + svnmucc \
> > > + svnrdump
> > >  SUBDIR_PARALLEL=
> > >  
> > 
> > 
> 
> -- 
> Rod Grimes 
> rgri...@freebsd.org
> 
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsvn_diff lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/lib

[Rodney W. Grimes]

> On Sun, 2020-05-31 at 22:04 +, Dimitry Andric wrote:
> > Author: dim
> > Date: Sun May 31 22:04:51 2020
> > New Revision: 361677
> > URL: https://svnweb.freebsd.org/changeset/base/361677
> > 
> > Log:
> >   Change Makefiles under usr.bin/svn to make them easier to
> > incrementally
> >   update. No functional change intended.
> >   
> >   MFC after:2 weeks
> > 
> 
> I wish we could get style.Makefile(9) updated to mandate this 1-per-
> line style when listing sources, dirs, etc, when the number of items is
> greater than N, where N is something like 3-6 filenames.  Otherwise the
> requirement to sort the names alphabetically pretty much mandates that
> many lines of the file will change just to insert one or two new files,
> and that makes it all but impossible to figure out from a diff what
> actually changed.

I like this idea, though rather than 3-6 filenames I propose
it to be anything longer than 3 lines, which is kinda about when
the pain point should start.  See the immediate SUBDIR below, it
is 11 items on 2ish/3 lines, and any change would worst case be a
3 line diff.  This probably covers a large portion of the tree.

I particularly do not like massive amounts of vertical white
space which this would create, but lacking an automated tool
this is probably a reasonable compromise.

If we did it everywhere it would mean lots of scrolling when
working on rather simple makefiles.

> -- Ian
> 
> > 
> [...] 
> > -SUBDIR=lib .WAIT \
> > -   svn svnadmin svnbench svndumpfilter svnfsfs svnlook svnserve \
> > -   svnsync svnversion svnmucc svnrdump
> > +SUBDIR=lib \
> > +   .WAIT \
> > +   svn \
> > +   svnadmin \
> > +   svnbench \
> > +   svndumpfilter \
> > +   svnfsfs \
> > +   svnlook \
> > +   svnserve \
> > +   svnsync \
> > +   svnversion \
> > +   svnmucc \
> > +   svnrdump
> >  SUBDIR_PARALLEL=
> >  
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361685 - head/sys/kern

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: peter
> Date: Mon Jun  1 03:37:58 2020
> New Revision: 361685
> URL: https://svnweb.freebsd.org/changeset/base/361685
> 
> Log:
>   Clarify which hints file is the source of an error message.

Better correction could be to use the variable storing the name
that is used.

>   
>   PR: 246688
>   Submitted by:   Ashish Gupta 
>   MFC after:  1 week
> 
> Modified:
>   head/sys/kern/kern_linker.c
> 
> Modified: head/sys/kern/kern_linker.c
> ==
> --- head/sys/kern/kern_linker.c   Mon Jun  1 02:54:10 2020
> (r361684)
> +++ head/sys/kern/kern_linker.c   Mon Jun  1 03:37:58 2020
> (r361685)
> @@ -1870,7 +1870,7 @@ linker_hints_lookup(const char *path, int pathlen, con
>* XXX: we need to limit this number to some reasonable value
>*/
>   if (vattr.va_size > LINKER_HINTS_MAX) {
> - printf("hints file too large %ld\n", (long)vattr.va_size);
> + printf("linker.hints file too large %ld\n", 
> (long)vattr.va_size);

+   printf("%s file too large %ld\n", linker_hintfile, 
(long)vattr.va_size);

>   goto bad;
>   }
>   hints = malloc(vattr.va_size, M_TEMP, M_WAITOK);
> @@ -1888,7 +1888,7 @@ linker_hints_lookup(const char *path, int pathlen, con
>   intp = (int *)hints;
>   ival = *intp++;
>   if (ival != LINKER_HINTS_VERSION) {
> - printf("hints file version mismatch %d\n", ival);
> + printf("linker.hints file version mismatch %d\n", ival);

Ditto.

>   goto bad;
>   }
>   bufend = hints + vattr.va_size;
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361541 - in head: . sys/amd64/conf sys/arm64/conf sys/conf sys/contrib/dev/ice sys/dev/ice sys/modules sys/modules/ice sys/modules/ice_ddp tools/kerneldoc/subsys

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: erj
> Date: Tue May 26 23:35:10 2020
> New Revision: 361541
> URL: https://svnweb.freebsd.org/changeset/base/361541
> 
> Log:
>   ice(4): Introduce new driver for Intel E800 Ethernet controllers
>   
>   The ice(4) driver is the driver for the Intel E8xx series Ethernet
>   controllers; currently with codenames Columbiaville and
>   Columbia Park.
>   
>   These new controllers support 100G speeds, as well as introducing
>   more queues, better virtualization support, and more offload
>   capabilities. Future work will enable virtual functions (like
>   in ixl(4)) and the other functionality outlined above.
>   
>   For full functionality, the kernel should be compiled with
>   "device ice_ddp" like in the amd64 NOTES file, and/or
>   ice_ddp_load="YES" should be added to /boot/loader.conf so that
>   the DDP package file included in this commit can be downloaded
>   to the adapter. Otherwise, the adapter will fall back to a single
>   queue mode with limited functionality.
>   
>   A man page for this driver will be forthcoming.
>   
>   MFC after:  1 month
>   Relnotes:   yes
>   Sponsored by:   Intel Corporation
>   Differential Revision:  https://reviews.freebsd.org/D21959

This code is not strickly BSD n-claused licensed.

These files contain license clauses and scopes that are outside
the curretly accepted "by the project" and that needs reviewed
by core before this should of been committed.

I do not see any huge issues, but there are some edges that
might need some far more careful consideration.

Oddly the file that was in the email of the commit actually
does contain an "Intel'ed 3 clause BSD license?"

> 
> Added:
>   head/sys/contrib/dev/ice/
>   head/sys/contrib/dev/ice/LICENSE   (contents, props changed)
>   head/sys/contrib/dev/ice/README   (contents, props changed)
>   head/sys/contrib/dev/ice/ice-1.3.9.0.pkg   (contents, props changed)
>   head/sys/dev/ice/
>   head/sys/dev/ice/ice_adminq_cmd.h   (contents, props changed)
>   head/sys/dev/ice/ice_alloc.h   (contents, props changed)
>   head/sys/dev/ice/ice_bitops.h   (contents, props changed)
>   head/sys/dev/ice/ice_common.c   (contents, props changed)
>   head/sys/dev/ice/ice_common.h   (contents, props changed)
>   head/sys/dev/ice/ice_common_sysctls.h   (contents, props changed)
>   head/sys/dev/ice/ice_common_txrx.h   (contents, props changed)
>   head/sys/dev/ice/ice_controlq.c   (contents, props changed)
>   head/sys/dev/ice/ice_controlq.h   (contents, props changed)
>   head/sys/dev/ice/ice_dcb.c   (contents, props changed)
>   head/sys/dev/ice/ice_dcb.h   (contents, props changed)
>   head/sys/dev/ice/ice_devids.h   (contents, props changed)
>   head/sys/dev/ice/ice_drv_info.h   (contents, props changed)
>   head/sys/dev/ice/ice_features.h   (contents, props changed)
>   head/sys/dev/ice/ice_flex_pipe.c   (contents, props changed)
>   head/sys/dev/ice/ice_flex_pipe.h   (contents, props changed)
>   head/sys/dev/ice/ice_flex_type.h   (contents, props changed)
>   head/sys/dev/ice/ice_flow.c   (contents, props changed)
>   head/sys/dev/ice/ice_flow.h   (contents, props changed)
>   head/sys/dev/ice/ice_hw_autogen.h   (contents, props changed)
>   head/sys/dev/ice/ice_iflib.h   (contents, props changed)
>   head/sys/dev/ice/ice_iflib_recovery_txrx.c   (contents, props changed)
>   head/sys/dev/ice/ice_iflib_sysctls.h   (contents, props changed)
>   head/sys/dev/ice/ice_iflib_txrx.c   (contents, props changed)
>   head/sys/dev/ice/ice_lan_tx_rx.h   (contents, props changed)
>   head/sys/dev/ice/ice_lib.c   (contents, props changed)
>   head/sys/dev/ice/ice_lib.h   (contents, props changed)
>   head/sys/dev/ice/ice_nvm.c   (contents, props changed)
>   head/sys/dev/ice/ice_nvm.h   (contents, props changed)
>   head/sys/dev/ice/ice_opts.h   (contents, props changed)
>   head/sys/dev/ice/ice_osdep.c   (contents, props changed)
>   head/sys/dev/ice/ice_osdep.h   (contents, props changed)
>   head/sys/dev/ice/ice_protocol_type.h   (contents, props changed)
>   head/sys/dev/ice/ice_resmgr.c   (contents, props changed)
>   head/sys/dev/ice/ice_resmgr.h   (contents, props changed)
>   head/sys/dev/ice/ice_rss.h   (contents, props changed)
>   head/sys/dev/ice/ice_sbq_cmd.h   (contents, props changed)
>   head/sys/dev/ice/ice_sched.c   (contents, props changed)
>   head/sys/dev/ice/ice_sched.h   (contents, props changed)
>   head/sys/dev/ice/ice_sriov.c   (contents, props changed)
>   head/sys/dev/ice/ice_sriov.h   (contents, props changed)
>   head/sys/dev/ice/ice_status.h   (contents, props changed)
>   head/sys/dev/ice/ice_strings.c   (contents, props changed)
>   head/sys/dev/ice/ice_switch.c   (contents, props changed)
>   head/sys/dev/ice/ice_switch.h   (contents, props changed)
>   head/sys/dev/ice/ice_type.h   (contents, props changed)
>   head/sys/dev/ice/if_ice_iflib.c   (contents, props changed)
>   head/sys/dev/ice/virtchnl.h   (contents, props changed)
>   

svn commit: r361355 - head/share/man/man4

[Rodney W. Grimes]

Author: rgrimes
Date: Fri May 22 03:13:29 2020
New Revision: 361355
URL: https://svnweb.freebsd.org/changeset/base/361355

Log:
  Include all currently present kernel options for IPFW
  Also fix igor complaint about manpage/s/man page
  
  Reported by: rgri...@freebsd.org
  
  PR:   219075
  Submitted by: Dries Michiels driesm.michiels_gmail.com
  Reported by:  rgrimes
  Reviewed by:  bcr (manpages), 0mp
  MFC after:3 days
  Differential Revision:https://reviews.freebsd.org/D24541

Modified:
  head/share/man/man4/ipfirewall.4

Modified: head/share/man/man4/ipfirewall.4
==
--- head/share/man/man4/ipfirewall.4Fri May 22 03:11:33 2020
(r361354)
+++ head/share/man/man4/ipfirewall.4Fri May 22 03:13:29 2020
(r361355)
@@ -1,7 +1,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd October 25, 2012
+.Dd May 21, 2020
 .Dt IPFW 4
 .Os
 .Sh NAME
@@ -20,8 +20,14 @@ Other related kernel options
 which may also be useful are:
 .Bd -ragged -offset indent
 .Cd "options IPFIREWALL_DEFAULT_TO_ACCEPT"
+.Cd "options IPDIVERT"
+.Cd "options IPFIREWALL_NAT"
+.Cd "options IPFIREWALL_NAT64"
+.Cd "options IPFIREWALL_NPTV6"
+.Cd "options IPFIREWALL_PMOD"
 .Cd "options IPFIREWALL_VERBOSE"
 .Cd "options IPFIREWALL_VERBOSE_LIMIT=100"
+.Cd "options LIBALIAS"
 .Ed
 .Pp
 To load
@@ -57,6 +63,54 @@ If the default
 behavior is to allow everything, it is easier to cope with
 firewall-tuning mistakes which may accidentally block all traffic.
 .Pp
+When using
+.Xr natd 8
+in conjunction with
+.Nm
+as
+.Tn NAT
+facility, the kernel option
+.Dv IPDIVERT
+enables diverting packets to
+.Xr natd 8
+for translation.
+.Pp
+When using the in-kernel
+.Tn NAT
+facility of
+.Nm ,
+the kernel option
+.Dv IPFIREWALL_NAT
+enables basic
+.Xr libalias 3
+functionality in the kernel.
+.Pp
+When using any of the
+.Tn IPv4
+to
+.Tn IPv6
+transition mechanisms in
+.Nm ,
+the kernel option
+.Dv IPFIREWALL_NAT64
+enables all of these
+.Tn NAT64
+methods in the kernel.
+.Pp
+When using the
+.Tn IPv6
+network prefix translation facility of
+.Nm ,
+the kernel option
+.Dv IPFIREWALL_NPTV6
+enables this functionality in the kernel.
+.Pp
+When using the packet modification facility of
+.Nm ,
+the kernel option
+.Dv IPFIREWALL_PMOD
+enables this functionality in the kernel.
+.Pp
 To enable logging of packets passing through
 .Nm ,
 enable the
@@ -70,20 +124,39 @@ from flooding system logs or causing local Denial of S
 This option may be set to the number of packets which will be logged on
 a per-entry basis before the entry is rate-limited.
 .Pp
+When using the in-kernel
+.Tn NAT
+facility of
+.Nm ,
+the kernel option
+.Dv LIBALIAS
+enables full
+.Xr libalias 3
+functionality in the kernel.
+Full functionality refers to included support for cuseeme, ftp, bbt,
+skinny, irc, pptp and smedia packets, which are missing in the basic
+.Xr libalias 3
+functionality accomplished with the
+.Dv IPFIREWALL_NAT
+kernel option.
+.Pp
 The user interface for
 .Nm
 is implemented by the
 .Xr ipfw 8
 utility, so please refer to the
 .Xr ipfw 8
-manpage for a complete description of the
+man page for a complete description of the
 .Nm
 capabilities and how to use it.
 .Sh SEE ALSO
 .Xr setsockopt 2 ,
 .Xr divert 4 ,
 .Xr ip 4 ,
+.Xr ip6 4 ,
 .Xr ipfw 8 ,
+.Xr libalias 3 ,
+.Xr natd 8 ,
 .Xr sysctl 8 ,
 .Xr syslogd 8 ,
 .Xr pfil 9
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361342 - in stable/12/sys/netinet: . tcp_stacks

[Rodney W. Grimes]

> Author: rscheff
> Date: Thu May 21 19:46:11 2020
> New Revision: 361342
> URL: https://svnweb.freebsd.org/changeset/base/361342
> 
> Log:
Partial merge of r360477:

>   MFC r360477: Correctly set up the initial TCP congestion window in all cases
>   
>   by not including the SYN bit sequence space in cwnd related calculations.
>   Snd_und is adjusted explicitly in all cases, outside the cwnd update, 
> instead.
>   
>   This fixes an off-by-one conformance issue with regular TCP sessions
>   not  using Appropriate Byte Counting (RFC3465), sending one more
>   packet during  the initial window than expected.

There should of been a note here:
This does NOT contain the merge of the change to bbrv1 since at this
time that code does not exist in stable/12, and there is no plan to
merge that code to stable/12.
>   
>   PR: 235256
>   Reviewed by:tuexen (mentor), rgrimes (mentor, blanket)
>   Approved by:tuexen (mentor), rgrimes (mentor, blanket)
>   MFC after:  3 weeks
>   Sponsored by:   NetApp, Inc.
>   Differential Revision:  https://reviews.freebsd.org/D19000
> 
> Modified:
>   stable/12/sys/netinet/tcp_input.c
>   stable/12/sys/netinet/tcp_stacks/rack.c
> Directory Properties:
>   stable/12/   (props changed)
> 
> Modified: stable/12/sys/netinet/tcp_input.c
> ==
> --- stable/12/sys/netinet/tcp_input.c Thu May 21 19:45:14 2020
> (r361341)
> +++ stable/12/sys/netinet/tcp_input.c Thu May 21 19:46:11 2020
> (r361342)
> @@ -1519,7 +1519,7 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, stru
>  struct tcpcb *tp, int drop_hdrlen, int tlen, uint8_t iptos)
>  {
>   int thflags, acked, ourfinisacked, needoutput = 0, sack_changed;
> - int rstreason, todrop, win;
> + int rstreason, todrop, win, incforsyn = 0;
>   uint32_t tiwin;
>   uint16_t nsegs;
>   char *s;
> @@ -2432,12 +2432,6 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, stru
>   if (IS_FASTOPEN(tp->t_flags) && tp->t_tfo_pending) {
>   tcp_fastopen_decrement_counter(tp->t_tfo_pending);
>   tp->t_tfo_pending = NULL;
> -
> - /*
> -  * Account for the ACK of our SYN prior to
> -  * regular ACK processing below.
> -  */ 
> - tp->snd_una++;
>   }
>   if (tp->t_flags & TF_NEEDFIN) {
>   tcp_state_change(tp, TCPS_FIN_WAIT_1);
> @@ -2458,6 +2452,13 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, stru
>   tcp_timer_activate(tp, TT_KEEP, TP_KEEPIDLE(tp));
>   }
>   /*
> +  * Account for the ACK of our SYN prior to
> +  * regular ACK processing below, except for
> +  * simultaneous SYN, which is handled later.
> +  */
> + if (SEQ_GT(th->th_ack, tp->snd_una) && !(tp->t_flags & 
> TF_NEEDSYN))
> + incforsyn = 1;
> + /*
>* If segment contains data or ACK, will call tcp_reass()
>* later; if not, do so now to pass queued data to user.
>*/
> @@ -2751,6 +2752,15 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, stru
>  process_ACK:
>   INP_WLOCK_ASSERT(tp->t_inpcb);
>  
> + /*
> +  * Adjust for the SYN bit in sequence space,
> +  * but don't account for it in cwnd calculations.
> +  * This is for the SYN_RECEIVED, non-simultaneous
> +  * SYN case. SYN_SENT and simultaneous SYN are
> +  * treated elsewhere.
> +  */
> + if (incforsyn)
> + tp->snd_una++;
>   acked = BYTES_THIS_ACK(tp, th);
>   KASSERT(acked >= 0, ("%s: acked unexepectedly negative "
>   "(tp->snd_una=%u, th->th_ack=%u, tp=%p, m=%p)", __func__,
> 
> Modified: stable/12/sys/netinet/tcp_stacks/rack.c
> ==
> --- stable/12/sys/netinet/tcp_stacks/rack.c   Thu May 21 19:45:14 2020
> (r361341)
> +++ stable/12/sys/netinet/tcp_stacks/rack.c   Thu May 21 19:46:11 2020
> (r361342)
> @@ -5580,12 +5580,6 @@ rack_do_syn_recv(struct mbuf *m, struct tcphdr *th, st
>   if (IS_FASTOPEN(tp->t_flags) && tp->t_tfo_pending) {
>   tcp_fastopen_decrement_counter(tp->t_tfo_pending);
>   tp->t_tfo_pending = NULL;
> -
> - /*
> -  * Account for the ACK of our SYN prior to
> -  * regular ACK processing below.
> -  */ 
> - tp->snd_una++;
>   }
>   if (tp->t_flags & TF_NEEDFIN) {
>   tcp_state_change(tp, TCPS_FIN_WAIT_1);
> @@ -5603,6 +5597,13 @@ rack_do_syn_recv(struct mbuf *m, struct tcphdr *th, st
>   if 

Re: svn commit: r361340 - in stable/12/sys/netinet: . tcp_stacks

[Rodney W. Grimes]

> Author: rscheff
> Date: Thu May 21 19:41:25 2020
> New Revision: 361340
> URL: https://svnweb.freebsd.org/changeset/base/361340
> 
> Log:
>   MFC r360479: Prevent premature shrinking of the scaled receive window
>   
>   which can cause a TCP client to use invalid or stale TCP sequence numbers 
> for ACK packets.
>   
>   Packets with old sequence numbers are ignored and not used to update the 
> send window size.
>   This might cause the TCP session to hang indefinitely under some 
> circumstances.

There should of been a note here:
This does NOT contain the merge of the change to bbrv1 since at this
time that code does not exist in stable/12, and there is no plan to
merge that code to stable/12.

>   Reported by:Cui Cheng
>   Reviewed by:tuexen (mentor), rgrimes (mentor, blanket)
>   Approved by:tuexen (mentor), rgrimes (mentor, blanket)
>   MFC after:  3 weeks
>   Sponsored by:   NetApp, Inc.
>   Differential Revision:  https://reviews.freebsd.org/D24515
> 
> Modified:
>   stable/12/sys/netinet/tcp_output.c
>   stable/12/sys/netinet/tcp_stacks/rack.c
> Directory Properties:
>   stable/12/   (props changed)
> 
> Modified: stable/12/sys/netinet/tcp_output.c
> ==
> --- stable/12/sys/netinet/tcp_output.cThu May 21 18:50:05 2020
> (r361339)
> +++ stable/12/sys/netinet/tcp_output.cThu May 21 19:41:25 2020
> (r361340)
> @@ -1206,8 +1206,11 @@ send:
>   if (flags & TH_SYN)
>   th->th_win = htons((u_short)
>   (min(sbspace(>so_rcv), TCP_MAXWIN)));
> - else
> + else {
> + /* Avoid shrinking window with window scaling. */
> + recwin = roundup2(recwin, 1 << tp->rcv_scale);
>   th->th_win = htons((u_short)(recwin >> tp->rcv_scale));
> + }
>  
>   /*
>* Adjust the RXWIN0SENT flag - indicate that we have advertised
> 
> Modified: stable/12/sys/netinet/tcp_stacks/rack.c
> ==
> --- stable/12/sys/netinet/tcp_stacks/rack.c   Thu May 21 18:50:05 2020
> (r361339)
> +++ stable/12/sys/netinet/tcp_stacks/rack.c   Thu May 21 19:41:25 2020
> (r361340)
> @@ -8355,8 +8355,11 @@ send:
>   if (flags & TH_SYN)
>   th->th_win = htons((u_short)
>   (min(sbspace(>so_rcv), TCP_MAXWIN)));
> - else
> + else {
> + /* Avoid shrinking window with window scaling. */
> + recwin = roundup2(recwin, 1 << tp->rcv_scale);
>   th->th_win = htons((u_short)(recwin >> tp->rcv_scale));
> + }
>   /*
>* Adjust the RXWIN0SENT flag - indicate that we have advertised a 0
>* window.  This may cause the remote transmitter to stall.  This
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361318 - head/bin/ls

[Rodney W. Grimes]

> Author: kevans
> Date: Thu May 21 03:50:56 2020
> New Revision: 361318
> URL: https://svnweb.freebsd.org/changeset/base/361318
> 
> Log:
>   ls: fix a --color regression from r337956
>   
>   The regression is in-fact that I flipped the default from never to auto. The
>   incorrect impression was based on an alias that I failed to notice,
>   installed by the Linux distribution that I used for testing compatibility
>   here. Users that want the old default should be doing so with a shell alias
>   as is done elsewhere, rather than making this decision in ls(1).
>   
>   Many thanks to rgrimes for pointing out the alias that I clearly overlooked
>   that resulted in this; if you despised colors in your terminal from this,
>   consider buying him a beer at the next venue that you see him at.

Thanks Kyle, but this is likely to get me more rocks than beers :-)

>   
>   MFC after:  1 week
>   Relnotes:   yes
> 
> Modified:
>   head/bin/ls/ls.1
>   head/bin/ls/ls.c
> 
> Modified: head/bin/ls/ls.1
> ==
> --- head/bin/ls/ls.1  Thu May 21 03:33:20 2020(r361317)
> +++ head/bin/ls/ls.1  Thu May 21 03:50:56 2020(r361318)
> @@ -32,7 +32,7 @@
>  .\" @(#)ls.1 8.7 (Berkeley) 7/29/94
>  .\" $FreeBSD$
>  .\"
> -.Dd August 18, 2018
> +.Dd May 20, 2020
>  .Dt LS 1
>  .Os
>  .Sh NAME
> @@ -216,8 +216,8 @@ Output colored escape sequences based on
>  .Ar when ,
>  which may be set to either
>  .Cm always ,
> -.Cm auto
> -(default), or
> +.Cm auto ,
> +or
>  .Cm never .
>  .Pp
>  .Cm always
> @@ -252,6 +252,12 @@ environment variable is set and not empty.
>  .Pp
>  .Cm never
>  will disable color regardless of environment variables.
> +.Cm never
> +is the default when neither
> +.Fl -color
> +nor
> +.Fl G
> +is specified.
>  .Pp
>  For compatibility with GNU coreutils,
>  .Nm
> 
> Modified: head/bin/ls/ls.c
> ==
> --- head/bin/ls/ls.c  Thu May 21 03:33:20 2020(r361317)
> +++ head/bin/ls/ls.c  Thu May 21 03:50:56 2020(r361318)
> @@ -152,7 +152,7 @@ static int f_timesort;/* sort by time vice 
> name */
> int f_type;   /* add type character for non-regular files */
>  static int f_whiteout;   /* show whiteout entries */
>  #ifdef COLORLS
> -   int colorflag = COLORFLAG_AUTO;   /* passed in colorflag 
> */
> +   int colorflag = COLORFLAG_NEVER;  /* passed in colorflag 
> */
> int f_color;  /* add type in color for non-regular files */
> bool explicitansi;/* Explicit ANSI sequences, no termcap(5) */
>  char *ansi_bgcol;/* ANSI sequence to set background colour */
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361238 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Rodney W. Grimes]

> On Tue, May 19, 2020 at 10:27 AM Rodney W. Grimes
>  wrote:
> >
> > > On Tue, May 19, 2020 at 10:23 AM Rodney W. Grimes
> > >  wrote:
> > > >
> > > > > Author: kevans
> > > > > Date: Tue May 19 02:41:05 2020
> > > > > New Revision: 361238
> > > > > URL: https://svnweb.freebsd.org/changeset/base/361238
> > > > >
> > > > > Log:
> > > > >   zfs: reject read(2) of a dirfd with EISDIR
> > > > >
> > > > >   This is independent of the recently-discussed global change, which 
> > > > > is still
> > > > >   in review/discussion stage.
> > > > >
> > > > >   This is effectively a measure for consistency in the ZFS world, 
> > > > > where
> > > > >   FreeBSD was the only platform (as far as I could find) that allowed 
> > > > > this.
> > > > >   What ZFS exposes is decidedly not useful for any real purposes, to
> > > > >   paraphrase (hopefully faithfully) jhb's findings when exploring 
> > > > > this:
> > > > >
> > > > >   The size of a directory in ZFS is the number of directory entries 
> > > > > within.
> > > > >   When reading a directory, you would instead get the leading part of 
> > > > > its raw
> > > > >   contents; the amount you get being dictated by the "size," i.e. 
> > > > > number of
> > > > >   directory entries. There's decidedly (luckily) no stack disclosure 
> > > > > happening
> > > > >   here, though the behavior is bizarre and almost certainly a 
> > > > > historical
> > > > >   accident.
> > > > >
> > > > >   This change has already been upstreamed to OpenZFS.
> > > >
> > > > Until the grep -d skip issue is addressed I object to this change as
> > > > it is going to cause people who do grep with wildcards to see lots
> > > > of errors that before where pretty much either silent (no match occured)
> > > > or spit out a "binary file foo matches."
> > > >
> > >
> > > That seems preferable to grepping random bytes that don't particularly
> > > contain any strings? They'd never see "binary file foo matches" in
> > > this case.
> >
> > The difference is you rarely get a hit, and now your gauranteed to
> > get a hit on every single directory making grep * very noisy, where
> > it was often silent or nearly silent before.
> >
> 
> As you noted in the review for the larger change, -d skip is a good
> option for the people that don't like this. It probably makes sense as
> a default, but then we'd be diverging from the other popular grep that
> defaults to -d read and spews out EISDIR more often than not.

Yet another thing I hate about Linux, thank you for adding it to FreeBSD :-)

> > >
> > > This isn't exactly divergent from the behavior they'd see with ZFS
> > > anywhere else.
> >
> > It is extremly divergent from 42 years of behavior.
> >
> 
> I don't think ZFS has been implemented on FreeBSD for 42 years, and I
> don't find this grep argument compelling enough to restore peoples'
> ability to read the raw znode of a directory.

The EISDIR behavior is what your changing, independent of file system(s)
you have done so far.  The fact the behavior is now different between
UFS and ZFS is sic, IMHO.


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361238 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Rodney W. Grimes]

> > On Tue, May 19, 2020 at 10:23 AM Rodney W. Grimes
> >  wrote:
> > >
> > > > Author: kevans
> > > > Date: Tue May 19 02:41:05 2020
> > > > New Revision: 361238
> > > > URL: https://svnweb.freebsd.org/changeset/base/361238
> > > >
> > > > Log:
> > > >   zfs: reject read(2) of a dirfd with EISDIR
> > > >
> > > >   This is independent of the recently-discussed global change, which is 
> > > > still
> > > >   in review/discussion stage.
> > > >
> > > >   This is effectively a measure for consistency in the ZFS world, where
> > > >   FreeBSD was the only platform (as far as I could find) that allowed 
> > > > this.
> > > >   What ZFS exposes is decidedly not useful for any real purposes, to
> > > >   paraphrase (hopefully faithfully) jhb's findings when exploring this:
> > > >
> > > >   The size of a directory in ZFS is the number of directory entries 
> > > > within.
> > > >   When reading a directory, you would instead get the leading part of 
> > > > its raw
> > > >   contents; the amount you get being dictated by the "size," i.e. 
> > > > number of
> > > >   directory entries. There's decidedly (luckily) no stack disclosure 
> > > > happening
> > > >   here, though the behavior is bizarre and almost certainly a historical
> > > >   accident.
> > > >
> > > >   This change has already been upstreamed to OpenZFS.
> > >
> > > Until the grep -d skip issue is addressed I object to this change as
> > > it is going to cause people who do grep with wildcards to see lots
> > > of errors that before where pretty much either silent (no match occured)
> > > or spit out a "binary file foo matches."
> > >
> > 
> > That seems preferable to grepping random bytes that don't particularly
> > contain any strings? They'd never see "binary file foo matches" in
> > this case.
> 
> The difference is you rarely get a hit, and now your gauranteed to
> get a hit on every single directory making grep * very noisy, where
> it was often silent or nearly silent before.

Please, go try this and see if you can see why I am asserting what I am:
(on one of your patched systems)
cd /etc
grep foo *
grep -d skip foo *  #This makes it closer to old behavior, not 
exact as binary matches shall be skipped.

The first command isg going to return an error for every directory,
the second command, closer to historical behavior, is going to be nearly silent.
You could run the second command on a pre patched system, ufs or zfs wont 
matter much.

> > This isn't exactly divergent from the behavior they'd see with ZFS
> > anywhere else.
> 
> It is extremly divergent from 42 years of behavior.
> 
> > Thanks,
> > 
> > Kyle Evans
> > 
> 
> -- 
> Rod Grimes rgri...@freebsd.org
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361238 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Rodney W. Grimes]

> On Tue, May 19, 2020 at 10:23 AM Rodney W. Grimes
>  wrote:
> >
> > > Author: kevans
> > > Date: Tue May 19 02:41:05 2020
> > > New Revision: 361238
> > > URL: https://svnweb.freebsd.org/changeset/base/361238
> > >
> > > Log:
> > >   zfs: reject read(2) of a dirfd with EISDIR
> > >
> > >   This is independent of the recently-discussed global change, which is 
> > > still
> > >   in review/discussion stage.
> > >
> > >   This is effectively a measure for consistency in the ZFS world, where
> > >   FreeBSD was the only platform (as far as I could find) that allowed 
> > > this.
> > >   What ZFS exposes is decidedly not useful for any real purposes, to
> > >   paraphrase (hopefully faithfully) jhb's findings when exploring this:
> > >
> > >   The size of a directory in ZFS is the number of directory entries 
> > > within.
> > >   When reading a directory, you would instead get the leading part of its 
> > > raw
> > >   contents; the amount you get being dictated by the "size," i.e. number 
> > > of
> > >   directory entries. There's decidedly (luckily) no stack disclosure 
> > > happening
> > >   here, though the behavior is bizarre and almost certainly a historical
> > >   accident.
> > >
> > >   This change has already been upstreamed to OpenZFS.
> >
> > Until the grep -d skip issue is addressed I object to this change as
> > it is going to cause people who do grep with wildcards to see lots
> > of errors that before where pretty much either silent (no match occured)
> > or spit out a "binary file foo matches."
> >
> 
> That seems preferable to grepping random bytes that don't particularly
> contain any strings? They'd never see "binary file foo matches" in
> this case.

The difference is you rarely get a hit, and now your gauranteed to
get a hit on every single directory making grep * very noisy, where
it was often silent or nearly silent before.

> 
> This isn't exactly divergent from the behavior they'd see with ZFS
> anywhere else.

It is extremly divergent from 42 years of behavior.

> Thanks,
> 
> Kyle Evans
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361238 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Rodney W. Grimes]

> Author: kevans
> Date: Tue May 19 02:41:05 2020
> New Revision: 361238
> URL: https://svnweb.freebsd.org/changeset/base/361238
> 
> Log:
>   zfs: reject read(2) of a dirfd with EISDIR
>   
>   This is independent of the recently-discussed global change, which is still
>   in review/discussion stage.
>   
>   This is effectively a measure for consistency in the ZFS world, where
>   FreeBSD was the only platform (as far as I could find) that allowed this.
>   What ZFS exposes is decidedly not useful for any real purposes, to
>   paraphrase (hopefully faithfully) jhb's findings when exploring this:
>   
>   The size of a directory in ZFS is the number of directory entries within.
>   When reading a directory, you would instead get the leading part of its raw
>   contents; the amount you get being dictated by the "size," i.e. number of
>   directory entries. There's decidedly (luckily) no stack disclosure happening
>   here, though the behavior is bizarre and almost certainly a historical
>   accident.
>   
>   This change has already been upstreamed to OpenZFS.

Until the grep -d skip issue is addressed I object to this change as
it is going to cause people who do grep with wildcards to see lots
of errors that before where pretty much either silent (no match occured)
or spit out a "binary file foo matches."

>   
>   MFC after:  1 week

Please no.

> Modified:
>   head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
> 
> Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
> ==
> --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c   Tue May 
> 19 02:07:08 2020(r361237)
> +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c   Tue May 
> 19 02:41:05 2020(r361238)
> @@ -646,6 +646,12 @@ zfs_read(vnode_t *vp, uio_t *uio, int ioflag, cred_t *
>   ZFS_ENTER(zfsvfs);
>   ZFS_VERIFY_ZP(zp);
>  
> + /* We don't copy out anything useful for directories. */
> + if (vp->v_type == VDIR) {
> + ZFS_EXIT(zfsvfs);
> + return (SET_ERROR(EISDIR));
> + }
> +
>   if (zp->z_pflags & ZFS_AV_QUARANTINED) {
>   ZFS_EXIT(zfsvfs);
>   return (SET_ERROR(EACCES));
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361143 - head/release/tools

[Rodney W. Grimes]

> On Sun, 17 May 2020 at 20:24, Conrad Meyer  wrote:
> >
> > On Sun, May 17, 2020 at 4:49 PM Oliver Pinter  wrote:
> > > On Sunday, May 17, 2020, Colin Percival  wrote:
> > >> +# Provide instructions on how to mount the requested filesystem.
> > >> +FS=$1
> > >> +REGION=`fetch -qo- 
> > >> http://169.254.169.254/latest/meta-data/placement/availability-zone | 
> > >> sed -e 's/[a-z]$//'`
> > >
> > >
> > > What will be this hard-coded ip address without any verification or at 
> > > least https?
> >
> > It's a special non-routable IP that is used in at least AWS and Azure
> > to provide some VM services.  Traffic to and from it never leaves the
> > virtual overlay network, which by design VM instances already trust to
> > provide privacy.  It doesn't require functioning DNS to access the raw
> > IP.
> 
> And, more information at
> https://en.wikipedia.org/wiki/Link-local_address

And the definative document(s)
https://www.rfc-editor.org/rfc/rfc3927.txt
https://who.is/whois-ip/ip-address/169.254.0.0

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361066 - head/usr.sbin/jail

[Rodney W. Grimes]

> 
> On 5/15/20 4:17 PM, Rodney W. Grimes wrote:
> >> On 5/15/20 3:24 PM, Rodney W. Grimes wrote:
> >>
> >>>> On 5/15/20 6:18 AM, Mateusz Piotrowski wrote:
> >>>>
> >>>>> On 5/15/20 1:38 AM, Ryan Moeller wrote:
> >>>>>> Author: freqlabs
> >>>>>> Date: Thu May 14 23:38:11 2020
> >>>>>> New Revision: 361066
> >>>>>> URL: https://svnweb.freebsd.org/changeset/base/361066
> >>>>>>
> >>>>>> Log:
> >>>>>>  jail: Add exec.prepare and exec.release command hooks
> >>>>>>  
> >>>>>>  This change introduces new jail command hooks that run before and 
> >>>>>> after any
> >>>>>>  other actions.
> >>>>> Should it go into RELNOTES?
> >>>> I'm not sure what all the criteria are for relnotes.
> >>>> The committer's guide makes it seem like relnotes is for breaking
> >>>> changes, which this is not.
> >>> Please could you point at which specific language in the commiters
> >>> guide makes you believe that the RELNOTES are for breaking changes?
> >> Every mention of "release notes" in the document is in the context of
> >> deprecating, removing,
> >> or breaking things, with one exception:
> > Fair, there should be a section on "new features and enhnacements"
> > which is laking.  However if one reads a release notes from a shipping
> > version it becomes clear that the actual majority of the text in it is
> > "new stuff."
> 
> Now that I know better, how do I retcon this and other potentially 
> relnoteworthy enhancements I've made? :)

There is a top level file in the src tree called RELNOTES that
you can use to ad an entry to describing the change and the
revision number.

> >>   > Relnotes:??? If the change is a candidate for inclusion in the
> >> release notes for the next release from the branch, set to yes.
> >>> RELNOTES should be for all changes that have user visible impact
> >>> of any type.
> >>>
> >>>> -Ryan
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361066 - head/usr.sbin/jail

[Rodney W. Grimes]

> On 5/15/20 3:24 PM, Rodney W. Grimes wrote:
> 
> >> On 5/15/20 6:18 AM, Mateusz Piotrowski wrote:
> >>
> >>> On 5/15/20 1:38 AM, Ryan Moeller wrote:
> >>>> Author: freqlabs
> >>>> Date: Thu May 14 23:38:11 2020
> >>>> New Revision: 361066
> >>>> URL: https://svnweb.freebsd.org/changeset/base/361066
> >>>>
> >>>> Log:
> >>>> jail: Add exec.prepare and exec.release command hooks
> >>>> 
> >>>> This change introduces new jail command hooks that run before and 
> >>>> after any
> >>>> other actions.
> >>> Should it go into RELNOTES?
> >> I'm not sure what all the criteria are for relnotes.
> >> The committer's guide makes it seem like relnotes is for breaking
> >> changes, which this is not.
> > Please could you point at which specific language in the commiters
> > guide makes you believe that the RELNOTES are for breaking changes?
> 
> Every mention of "release notes" in the document is in the context of 
> deprecating, removing,
> or breaking things, with one exception:

Fair, there should be a section on "new features and enhnacements"
which is laking.  However if one reads a release notes from a shipping
version it becomes clear that the actual majority of the text in it is
"new stuff."

>  > Relnotes:??? If the change is a candidate for inclusion in the 
> release notes for the next release from the branch, set to yes.
> >
> > RELNOTES should be for all changes that have user visible impact
> > of any type.
> >
> >> -Ryan
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r361066 - head/usr.sbin/jail

[Rodney W. Grimes]

> On 5/15/20 6:18 AM, Mateusz Piotrowski wrote:
> 
> > On 5/15/20 1:38 AM, Ryan Moeller wrote:
> >> Author: freqlabs
> >> Date: Thu May 14 23:38:11 2020
> >> New Revision: 361066
> >> URL: https://svnweb.freebsd.org/changeset/base/361066
> >>
> >> Log:
> >>jail: Add exec.prepare and exec.release command hooks
> >>
> >>This change introduces new jail command hooks that run before and after 
> >> any
> >>other actions.
> > Should it go into RELNOTES?
> I'm not sure what all the criteria are for relnotes.
> The committer's guide makes it seem like relnotes is for breaking 
> changes, which this is not.

Please could you point at which specific language in the commiters
guide makes you believe that the RELNOTES are for breaking changes?

RELNOTES should be for all changes that have user visible impact
of any type.

> -Ryan

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r360077 - head/cddl/usr.sbin/zfsd

[Rodney W. Grimes]

> Author: asomers
> Date: Sat Apr 18 19:47:38 2020
> New Revision: 360077
> URL: https://svnweb.freebsd.org/changeset/base/360077
> 
> Log:
>   zfsd.8: fix orphan .Xr
>   
>   Though ZFS is a kernel module, it has no man page in section 4.

Wouldn't of been better to create a section 4 man page for zfs,
even if it was empty/TBD?

>   Reported by:phk
>   MFC after:  2 weeks
> 
> Modified:
>   head/cddl/usr.sbin/zfsd/zfsd.8
> 
> Modified: head/cddl/usr.sbin/zfsd/zfsd.8
> ==
> --- head/cddl/usr.sbin/zfsd/zfsd.8Sat Apr 18 18:25:30 2020
> (r360076)
> +++ head/cddl/usr.sbin/zfsd/zfsd.8Sat Apr 18 19:47:38 2020
> (r360077)
> @@ -25,7 +25,7 @@
>  .\"
>  .\" $FreeBSD$
>  .\"
> -.Dd May 26, 2016
> +.Dd April 18, 2020
>  .Dt ZFSD 8
>  .Os
>  .Sh NAME
> @@ -96,8 +96,7 @@ If a leaf vdev generates more than 50 I/O errors in a 
>  .Nm
>  will mark that vdev as
>  .Em FAULTED .
> -.Xr zfs 4
> -will no longer issue any I/Os to it.
> +ZFS will no longer issue any I/Os to it.
>  .Nm
>  will activate a hotspare if one is available.
>  .It Checksum errors
> @@ -106,8 +105,7 @@ period, then
>  .Nm
>  will mark that vdev as
>  .Em DEGRADED .
> -.Xr zfs 4
> -will still use it, but zfsd will activate a spare anyway.
> +ZFS will still use it, but zfsd will activate a spare anyway.
>  .It Spare addition
>  If the system administrator adds a hotspare to a pool that is already 
> degraded,
>  .Nm
> @@ -138,7 +136,6 @@ then reads them back in when next it starts up.
>  .El
>  .Sh SEE ALSO
>  .Xr devctl 4 ,
> -.Xr zfs 4 ,
>  .Xr zpool 8
>  .Sh HISTORY
>  .Nm
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r359985 - stable/12/sys/dev/atkbdc

[Rodney W. Grimes]

> On 2020-04-16 03:04, Warner Losh wrote:
> > 
> > 
> > On Wed, Apr 15, 2020, 6:51 PM Rodney W. Grimes 
> > mailto:free...@gndrsh.dnsmgr.net>> wrote:
> > 
> > [ Charset UTF-8 unsupported, converting... ]
> >  > Author: zeising (doc,ports committer)
> >  > Date: Wed Apr 15 19:47:19 2020
> >  > New Revision: 359985
> >  > URL: https://svnweb.freebsd.org/changeset/base/359985
> >  >
> >  > Log:
> >  >? ?MFC r348873: Enable touch and trackpads by default
> >  >
> >  >? ?Enable synaptics and elantech touchpads, as well as IBM/Lenovo
> > TrackPoints
> >  >? ?by default, instead of having users find and toggle a loader
> > tunable.
> >  >? ?This makes things like two finger scroll and other modern
> > features work out
> >  >? ?of the box with X.? By enabling these settings by default, we
> > get a better
> >  >? ?desktop experience in X, since xserver and evdev can make use
> > of the more
> >  >? ?advanced synaptics and elantech features.
> >  >
> >  >? ?Approved by:? ? ? ? imp
> > 
> > RELNOTES: Y?
> > 
> > 
> > Yea. This is a release notes item.
> > 
> 
> Yes, this should have been marked with relnotes, my bad.  How can I fix 
> this?  Did we create the RELNOTES file, and if so, should I commit to 
> that one directly in 12, or first in head and then MFC?

I do not know what the RE@ decision was on how to handle the
RELNOTES file in stabe/X branches.

CC:'ed to re@ so they can answer

> Niclas Zeising
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r360064 - in head: share/man/man4 sys/dev/amr

[Rodney W. Grimes]

> Author: imp
> Date: Sat Apr 18 02:53:19 2020
> New Revision: 360064
> URL: https://svnweb.freebsd.org/changeset/base/360064
> 
> Log:
>   Add deprecation notice to amr(4)
> 

I take it this group of deprecations is also MFC: 3 days?


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r359985 - stable/12/sys/dev/atkbdc

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: zeising (doc,ports committer)
> Date: Wed Apr 15 19:47:19 2020
> New Revision: 359985
> URL: https://svnweb.freebsd.org/changeset/base/359985
> 
> Log:
>   MFC r348873: Enable touch and trackpads by default
>   
>   Enable synaptics and elantech touchpads, as well as IBM/Lenovo TrackPoints
>   by default, instead of having users find and toggle a loader tunable.
>   This makes things like two finger scroll and other modern features work out
>   of the box with X.  By enabling these settings by default, we get a better
>   desktop experience in X, since xserver and evdev can make use of the more
>   advanced synaptics and elantech features.
>   
>   Approved by:imp

RELNOTES: Y?

> Modified:
>   stable/12/sys/dev/atkbdc/psm.c
> Directory Properties:
>   stable/12/   (props changed)
> 
> Modified: stable/12/sys/dev/atkbdc/psm.c
> ==
> --- stable/12/sys/dev/atkbdc/psm.cWed Apr 15 19:33:42 2020
> (r359984)
> +++ stable/12/sys/dev/atkbdc/psm.cWed Apr 15 19:47:19 2020
> (r359985)
> @@ -513,9 +513,9 @@ static devclass_t psm_devclass;
>  /* Tunables */
>  static int tap_enabled = -1;
>  static int verbose = PSM_DEBUG;
> -static int synaptics_support = 0;
> -static int trackpoint_support = 0;
> -static int elantech_support = 0;
> +static int synaptics_support = 1;
> +static int trackpoint_support = 1;
> +static int elantech_support = 1;
>  
>  /* for backward compatibility */
>  #define  OLD_MOUSE_GETHWINFO _IOR('M', 1, old_mousehw_t)
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r359967 - head/usr.sbin/nologin

[Rodney W. Grimes]

> Author: 0mp (doc,ports committer)
> Date: Wed Apr 15 13:13:46 2020
> New Revision: 359967
> URL: https://svnweb.freebsd.org/changeset/base/359967
> 
> Log:
>   Document the exit status and the stdout message of nologin(8)
>   
>   Reviewed by:debdrup (earlier version)
>   MFC after:  2 weeks
>   Differential Revision:  https://reviews.freebsd.org/D24196
> 
> Modified:
>   head/usr.sbin/nologin/nologin.8
> 
> Modified: head/usr.sbin/nologin/nologin.8
> ==
> --- head/usr.sbin/nologin/nologin.8   Wed Apr 15 13:06:55 2020
> (r359966)
> +++ head/usr.sbin/nologin/nologin.8   Wed Apr 15 13:13:46 2020
> (r359967)
> @@ -28,7 +28,7 @@
>  .\" @(#)nologin.88.1 (Berkeley) 6/19/93
>  .\" $FreeBSD$
>  .\"
> -.Dd June 19, 1993
> +.Dd April 15, 2020
>  .Dt NOLOGIN 8
>  .Os
>  .Sh NAME
> @@ -39,14 +39,31 @@
>  .Sh DESCRIPTION
>  The
>  .Nm
> -utility displays a message that an account is not available and
> -exits non-zero.
> -It is intended as a replacement shell field for accounts that
> +is intended as a replacement shell field for accounts that
>  have been disabled.
>  .Pp
> +When executed,
> +.Nm
> +first writes about the login attempt to
> +.Xr syslog 3
> +and then a displays a message that an account is not available.

This needs some wordsmithing, extra "a" needs removed.

and then displays a message that an account is not available.

> +.Pp
>  To disable all logins,
>  investigate
>  .Xr nologin 5 .
> +.Sh EXIT STATUS
> +The
> +.Nm
> +utility always exits non-zero.
> +.Sh EXAMPLES
> +Here is a demonstration of executing
> +.Nm :
> +.Bd -literal -offset 4n
> +$ nologin
> +This account is currently not available.
> +$ tail -n 1 /var/log/messages
> +Mar 30 21:53:07 example.org nologin[65992]: Attempted login by beastie on 
> /dev/pts/18
> +.Ed
>  .Sh SEE ALSO
>  .Xr login 1 ,
>  .Xr nologin 5
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r359685 - in head: . etc lib/libc/gen share/mk share/termcap usr.bin/login usr.bin/vgrind usr.sbin/services_mkdb

[Rodney W. Grimes]

> On 4/7/2020 3:37 AM, Rodney W. Grimes wrote:
> >> Author: sobomax
> >> Date: Tue Apr  7 02:46:22 2020
> >> New Revision: 359685
> >> URL: https://svnweb.freebsd.org/changeset/base/359685
> >>
> >> Log:
> >>   Normalize deployment tools usage and definitions by putting into one 
> >> place
> >>   instead of sprinkling them out over many disjoint files. This is a 
> >> follow-up
> >>   to achieve the same goal in an incomplete rev.348521.
> > I have concerns that this factoring out of 5 values that have not changed
> > in 25 years is a pessimization, it is one more file that make has to
> > open on each invocation.
> > 
> > 
> 
> The truth is that this additional file read is on top of hundreds of new
> reads per directory in the past few years. It can suck on NFS but
> otherwise this 1 change is very minor compared to other additions. One
> big example is foo.o.depend for each foo.o. Or bmake doing
> realpath(getcwd()) on every invocation. Improving those, or the bmake
> job queue, or bmake's overuse of /bin/sh, would go a lot further than
> the hit from this commit.

True, it was unfair of me to pick on this one change, there are a long
slow gradual increase in the disk I/O intensity of buildworld over
time.  I was more raising that general issue, that we should keep
an eye towards that as we make changes to the build system, we should
be very careful of anything that pessimizes the build.

My concerns are for people, like mdexter, that run Build Option
Serveys, which is basically 240 buildwords in a single invocation
with run times on the order days to complete, or for CI clusters
doing 1000's of builds a week.

> -- 
> Regards,
> Bryan Drewery
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r359685 - in head: . etc lib/libc/gen share/mk share/termcap usr.bin/login usr.bin/vgrind usr.sbin/services_mkdb

[Rodney W. Grimes]

> Well, how many FreeBSD builds have you run in the last year, Rodney,
> personally to care about 0.1s slowdown that it might have caused? We've run
> at least a 1,000 here, probably 3x more.

That is a non technical personal attack.

> So yes, the cost is there, the
> cost is well understood and found negligible versus the benefit of having a
> slightly more extensible build system that is slightly easier to understand
> and integrate into bigger projects.

I do not see how moving 5 values adds any extensibility or any ease of use,
or intergratability.  It added an ease of editing the values to one file,
values that *should not be edited inplace*.

If these values need overridden it should always be done on the make command
line, especially by projects external to FreeBSD.  Your "extensible build 
system"
is reaching into internal project build infustructure in a non-supportable way
if it requires this types of change.

> 
> -Max
> 
> On Wed, Apr 8, 2020 at 5:12 PM Rodney W. Grimes 
> wrote:
> 
> > > On Tue, Apr 7, 2020 at 3:37 AM Rodney W. Grimes <
> > free...@gndrsh.dnsmgr.net>
> > > wrote:
> > >
> > > > > Author: sobomax
> > > > > Date: Tue Apr  7 02:46:22 2020
> > > > > New Revision: 359685
> > > > > URL: https://svnweb.freebsd.org/changeset/base/359685
> > > > >
> > > > > Log:
> > > > >   Normalize deployment tools usage and definitions by putting into
> > one
> > > > place
> > > > >   instead of sprinkling them out over many disjoint files. This is a
> > > > follow-up
> > > > >   to achieve the same goal in an incomplete rev.348521.
> > > >
> > > > I have concerns that this factoring out of 5 values that have not
> > changed
> > > > in 25 years is a pessimization, it is one more file that make has to
> > > > open on each invocation.
> > > >
> > >
> > > Well, luckily enough the cost of opening a file has been exponentially
> > > declining over those 25 years, so we are probably many-orders of
> > magnitude
> > > faster than  we used to be back in 1995. Or so I've heard. :)
> >
> > I believe we are pretty much just on par and no more than 1
> > order of magnitude on time completion of make world.
> >
> > >
> > > Having those variables defined in a centralized manner allows us here for
> > > example to convert the result of what would be
> > > installworld/installkernel/distribution action into a self-extracting
> > > archive (optionally signed) with automatically generated script, which
> > does
> > > the action in question. As such, we can now build in a completely
> > sandboxed
> > > environment with 0 privileges (potentially even on something completely
> > > alien like GNU/Linux) and then deploy it to as many systems as we need or
> > > use to create VM images / Jails.
> > >
> > >
> > https://github.com/sobomax/sysmaker/blob/master/makeargs/distribution.sub
> > >
> > https://github.com/sobomax/sysmaker/blob/master/makeargs/installkernel.sub
> > >
> > https://github.com/sobomax/sysmaker/blob/master/makeargs/installworld.sub
> >
> > I do not see anything in that set of files that requires this change,
> > am I missing something?
> >
> > All of the existing values should of been overridable from the make
> > command line invocation, and it does not mater if they are in 1
> > file or 50 files.
> >
> > > I have very few reasons to believe that our needs to be unique in this, I
> > > am pretty sure others will find some interesting use for this as well
> > (e.g.
> > > signing binaries being installed, etc).
> >
> > I do not see that your needs require this change.
> >
> > >
> > > -Max
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >
> >

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r359685 - in head: . etc lib/libc/gen share/mk share/termcap usr.bin/login usr.bin/vgrind usr.sbin/services_mkdb

[Rodney W. Grimes]

> On Tue, Apr 7, 2020 at 3:37 AM Rodney W. Grimes 
> wrote:
> 
> > > Author: sobomax
> > > Date: Tue Apr  7 02:46:22 2020
> > > New Revision: 359685
> > > URL: https://svnweb.freebsd.org/changeset/base/359685
> > >
> > > Log:
> > >   Normalize deployment tools usage and definitions by putting into one
> > place
> > >   instead of sprinkling them out over many disjoint files. This is a
> > follow-up
> > >   to achieve the same goal in an incomplete rev.348521.
> >
> > I have concerns that this factoring out of 5 values that have not changed
> > in 25 years is a pessimization, it is one more file that make has to
> > open on each invocation.
> >
> 
> Well, luckily enough the cost of opening a file has been exponentially
> declining over those 25 years, so we are probably many-orders of magnitude
> faster than  we used to be back in 1995. Or so I've heard. :)

I believe we are pretty much just on par and no more than 1
order of magnitude on time completion of make world.

> 
> Having those variables defined in a centralized manner allows us here for
> example to convert the result of what would be
> installworld/installkernel/distribution action into a self-extracting
> archive (optionally signed) with automatically generated script, which does
> the action in question. As such, we can now build in a completely sandboxed
> environment with 0 privileges (potentially even on something completely
> alien like GNU/Linux) and then deploy it to as many systems as we need or
> use to create VM images / Jails.
> 
> https://github.com/sobomax/sysmaker/blob/master/makeargs/distribution.sub
> https://github.com/sobomax/sysmaker/blob/master/makeargs/installkernel.sub
> https://github.com/sobomax/sysmaker/blob/master/makeargs/installworld.sub

I do not see anything in that set of files that requires this change,
am I missing something?

All of the existing values should of been overridable from the make
command line invocation, and it does not mater if they are in 1
file or 50 files.

> I have very few reasons to believe that our needs to be unique in this, I
> am pretty sure others will find some interesting use for this as well (e.g.
> signing binaries being installed, etc).

I do not see that your needs require this change.

> 
> -Max

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r359719 - head/usr.sbin/bhyve

[Rodney W. Grimes]

Author: rgrimes
Date: Tue Apr  7 23:17:44 2020
New Revision: 359719
URL: https://svnweb.freebsd.org/changeset/base/359719

Log:
  In the past changes have been made to smbios->minor without updating the
  smbios->bcdrev value.
  Correct that by calculating bcdrev from the major/minor values.
  
  Reported by:  bcran
  Reviewed by:  bcran, jhb
  Approved by:  jhb (maintainer)

Modified:
  head/usr.sbin/bhyve/smbiostbl.c

Modified: head/usr.sbin/bhyve/smbiostbl.c
==
--- head/usr.sbin/bhyve/smbiostbl.c Tue Apr  7 22:23:22 2020
(r359718)
+++ head/usr.sbin/bhyve/smbiostbl.c Tue Apr  7 23:17:44 2020
(r359719)
@@ -774,7 +774,7 @@ smbios_ep_initializer(struct smbios_entry_point *smbio
memcpy(smbios_ep->ianchor, SMBIOS_ENTRY_IANCHOR,
SMBIOS_ENTRY_IANCHORLEN);
smbios_ep->staddr = staddr;
-   smbios_ep->bcdrev = 0x24;
+   smbios_ep->bcdrev = (smbios_ep->major & 0xf) << 4 | (smbios_ep->minor & 
0xf);
 }
 
 static void
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r359706 - svnadmin/conf

[Rodney W. Grimes]

Author: rgrimes
Date: Tue Apr  7 17:18:22 2020
New Revision: 359706
URL: https://svnweb.freebsd.org/changeset/base/359706

Log:
  Add tuexen and myself (rgrimes) as rscheff's mentors.
  
  Reminded by:  gjb
  Approved by:  core

Modified:
  svnadmin/conf/mentors

Modified: svnadmin/conf/mentors
==
--- svnadmin/conf/mentors   Tue Apr  7 17:07:04 2020(r359705)
+++ svnadmin/conf/mentors   Tue Apr  7 17:18:22 2020(r359706)
@@ -29,6 +29,7 @@ miwi  araujo
 mjoras rstone
 nick   philip  Co-mentor: kp
 ramken Co-mentor: mav
+rschefftuexen  Co-mentor: rgrimes
 scottphscottl  Co-mentor: emaste, jhb
 thjjtl Co-mentor: bz
 tmunro mjg Co-mentor: allanjude
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r359685 - in head: . etc lib/libc/gen share/mk share/termcap usr.bin/login usr.bin/vgrind usr.sbin/services_mkdb

[Rodney W. Grimes]

> Author: sobomax
> Date: Tue Apr  7 02:46:22 2020
> New Revision: 359685
> URL: https://svnweb.freebsd.org/changeset/base/359685
> 
> Log:
>   Normalize deployment tools usage and definitions by putting into one place
>   instead of sprinkling them out over many disjoint files. This is a follow-up
>   to achieve the same goal in an incomplete rev.348521.

I have concerns that this factoring out of 5 values that have not changed
in 25 years is a pessimization, it is one more file that make has to
open on each invocation.


>   Approved by:imp
>   MFC after:  1 month
>   Differential Revision:  https://reviews.freebsd.org/D20520
> 
> Added:
>   head/share/mk/src.tools.mk   (contents, props changed)
> Modified:
>   head/Makefile.inc1
>   head/etc/Makefile
>   head/lib/libc/gen/Makefile.inc
>   head/share/mk/sys.mk
>   head/share/termcap/Makefile
>   head/usr.bin/login/Makefile
>   head/usr.bin/vgrind/Makefile
>   head/usr.sbin/services_mkdb/Makefile
> 
> Modified: head/Makefile.inc1
> ==
> --- head/Makefile.inc1Tue Apr  7 02:45:24 2020(r359684)
> +++ head/Makefile.inc1Tue Apr  7 02:46:22 2020(r359685)
> @@ -57,6 +57,8 @@ _MKSHOWCONFIG=  t
>  SRCDIR?= ${.CURDIR}
>  LOCALBASE?=  /usr/local
>  
> +.include "share/mk/src.tools.mk"
> +
>  # Cross toolchain changes must be in effect before bsd.compiler.mk
>  # so that gets the right CC, and pass CROSS_TOOLCHAIN to submakes.
>  .if defined(CROSS_TOOLCHAIN)
> @@ -874,8 +876,8 @@ MTREEFLAGS+=  -W
>  INSTALLFLAGS+=   -h sha256
>  .endif
>  .if defined(DB_FROM_SRC) || defined(NO_ROOT)
> -IMAKE_INSTALL=   INSTALL="install ${INSTALLFLAGS}"
> -IMAKE_MTREE= MTREE_CMD="mtree ${MTREEFLAGS}"
> +IMAKE_INSTALL=   INSTALL="${INSTALL_CMD} ${INSTALLFLAGS}"
> +IMAKE_MTREE= MTREE_CMD="${MTREE_CMD} ${MTREEFLAGS}"
>  .endif
>  
>  DESTDIR_MTREEFLAGS=  -deU
> @@ -887,12 +889,12 @@ WORLDTMP_MTREEFLAGS=-deUW
>  # that are created by mtree to be owned by root/wheel.
>  DESTDIR_MTREEFLAGS+= -W
>  .endif
> -MTREE?=  mtree
> +DISTR_MTREE= ${MTREE_CMD}
>  .if ${BUILD_WITH_STRICT_TMPPATH} != 0
> -MTREE=   ${WORLDTMP}/legacy/usr/sbin/mtree
> +DISTR_MTREE= ${WORLDTMP}/legacy/usr/sbin/mtree
>  .endif
> -WORLDTMP_MTREE=  ${MTREE} ${WORLDTMP_MTREEFLAGS}
> -DESTDIR_MTREE=   ${MTREE} ${DESTDIR_MTREEFLAGS}
> +WORLDTMP_MTREE=  ${DISTR_MTREE} ${WORLDTMP_MTREEFLAGS}
> +DESTDIR_MTREE=   ${DISTR_MTREE} ${DESTDIR_MTREEFLAGS}
>  
>  # kernel stage
>  KMAKEENV=${WMAKEENV:NSYSROOT=*}
> @@ -1363,14 +1365,14 @@ distributeworld installworld stageworld: _installcheck
>  .endif
>  .endif
>  .if defined(NO_ROOT)
> - ${IMAKEENV} ${MTREE} -C -f ${.CURDIR}/etc/mtree/BSD.root.dist | \
> + ${IMAKEENV} ${DISTR_MTREE} -C -f ${.CURDIR}/etc/mtree/BSD.root.dist | \
>   sed -e 's#^\./#./${dist}/#' >> ${METALOG}
> - ${IMAKEENV} ${MTREE} -C -f ${.CURDIR}/etc/mtree/BSD.usr.dist | \
> + ${IMAKEENV} ${DISTR_MTREE} -C -f ${.CURDIR}/etc/mtree/BSD.usr.dist | \
>   sed -e 's#^\./#./${dist}/usr/#' >> ${METALOG}
> - ${IMAKEENV} ${MTREE} -C -f ${.CURDIR}/etc/mtree/BSD.include.dist | \
> + ${IMAKEENV} ${DISTR_MTREE} -C -f ${.CURDIR}/etc/mtree/BSD.include.dist 
> | \
>   sed -e 's#^\./#./${dist}/usr/include/#' >> ${METALOG}
>  .if defined(_LIBCOMPAT)
> - ${IMAKEENV} ${MTREE} -C -f 
> ${.CURDIR}/etc/mtree/BSD.lib${libcompat}.dist | \
> + ${IMAKEENV} ${DISTR_MTREE} -C -f 
> ${.CURDIR}/etc/mtree/BSD.lib${libcompat}.dist | \
>   sed -e 's#^\./#./${dist}/usr/#' >> ${METALOG}
>  .endif
>  .endif
> 
> Modified: head/etc/Makefile
> ==
> --- head/etc/Makefile Tue Apr  7 02:45:24 2020(r359684)
> +++ head/etc/Makefile Tue Apr  7 02:46:22 2020(r359685)
> @@ -2,11 +2,11 @@
>  # $FreeBSD$
>  
>  .include 
> +.include 
>  
>  FILESGROUPS= FILES
>  NLS_ALIASES= POSIX C \
>   en_US.US_ASCII C
> -PWD_MKDB_CMD?=   pwd_mkdb
>  
>  # No need as it is empty and just causes rebuilds since this file does so 
> much.
>  UPDATE_DEPENDFILE=   no
> @@ -98,8 +98,6 @@ distribution:
>   ${DESTDIR}/boot/device.hints
>  .endif
>  .endif
> -
> -MTREE_CMD?=  mtree
>  
>  MTREES=  mtree/BSD.root.dist /   \
>   mtree/BSD.var.dist  /var\
> 
> Modified: head/lib/libc/gen/Makefile.inc
> ==
> --- head/lib/libc/gen/Makefile.incTue Apr  7 02:45:24 2020
> (r359684)
> +++ head/lib/libc/gen/Makefile.incTue Apr  7 02:46:22 2020
> (r359685)
> @@ -550,11 +550,13 @@ MLINKS+=vis.3 nvis.3 \
>  
>  MLINKS+=wordexp.3 wordfree.3
>  
> +.include 
> +
>  afterinstallconfig:
>  .if ${MK_TCSH} == "no"
>   sed -i "" -e 's;/bin/csh;/bin/sh;' ${DESTDIR}/etc/master.passwd
>  

svn commit: r359660 - svnadmin/conf

[Rodney W. Grimes]

Author: rgrimes
Date: Mon Apr  6 16:34:04 2020
New Revision: 359660
URL: https://svnweb.freebsd.org/changeset/base/359660

Log:
  #   (2) The full name of the person.
  #   (3) In brief, what they will be working on (a couple of sentences).
  
  Welcome Richard Scheffenegger as a src committer.
  
  Richard will focus on the network stack and RFC conformance.
  
  tuexen and rgrimes will be his mentors.
  
  Approved by:  core

Modified:
  svnadmin/conf/access

Modified: svnadmin/conf/access
==
--- svnadmin/conf/accessMon Apr  6 14:58:24 2020(r359659)
+++ svnadmin/conf/accessMon Apr  6 16:34:04 2020(r359660)
@@ -183,6 +183,7 @@ roberto
 royger
 rpokala
 rrs
+rscheff
 rstone
 rwatson bb+lists.freebsd.cvs-committ...@cyrus.watson.org
 sbruno
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"