svn commit: r367053 - head/usr.bin/calendar/calendars

2020-10-25 Thread Scott Long
Author: scottl
Date: Mon Oct 26 05:22:52 2020
New Revision: 367053
URL: https://svnweb.freebsd.org/changeset/base/367053

Log:
  Correct calendar entry for myself

Modified:
  head/usr.bin/calendar/calendars/calendar.freebsd

Modified: head/usr.bin/calendar/calendars/calendar.freebsd
==
--- head/usr.bin/calendar/calendars/calendar.freebsdMon Oct 26 04:04:06 
2020(r367052)
+++ head/usr.bin/calendar/calendars/calendar.freebsdMon Oct 26 05:22:52 
2020(r367053)
@@ -331,7 +331,7 @@
 08/24  Alexander Botero-Lowry  died in San Francisco, 
California, United States, 2012
 08/25  Beech Rintoul  born in Oakland, California, United 
States, 1952
 08/25  Jean Milanez Melo  born in Divinopolis, Minas 
Gerais, Brazil, 1982
-08/26  Scott Long  born in Chicago, Illinois, United 
States, 1974
+08/25  Scott Long  born in Chicago, Illinois, United 
States, 1974
 08/26  Dima Ruban  born in Nalchik, USSR, 1970
 08/26  Marc Fonvieille  born in Avignon, France, 1972
 08/26  Herve Quiroz  born in Aix-en-Provence, France, 1977
___
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: r367052 - head/sys/kern

2020-10-25 Thread Alexander Motin
Author: mav
Date: Mon Oct 26 04:04:06 2020
New Revision: 367052
URL: https://svnweb.freebsd.org/changeset/base/367052

Log:
  Enable bioq 'car limit' added at r335066 at 128 bios.
  
  Without the 'car limit' enabled (before this), running sequential ZFS scrub
  on HDD without command queuing support, I've measured latency on concurrent
  random reads reaching 4 seconds (surprised that not more).  Enabling this
  reduced the latency to 65 milliseconds, while scrub still doing ~180MB/s.
  
  For disks with command queuing this does not make much difference (if any),
  since most time all the requests are queued down to the disk or HBA, leaving
  nothing in the queue to sort.  And even if something does not fit, staying on
  the queue, it is likely not for long.  To not limit sorting in such bursty
  scenarios I've added batched counter zeroing when the queue is getting empty.
  
  The internal scheduler of the SAS HDD I was testing seems to be even more
  loyal to random I/O, reducing the scrub speed to ~120MB/s.  So in case
  somebody worried this is limit is too strict -- it actually looks relaxed.
  
  MFC after:2 weeks
  Sponsored by: iXsystems, Inc.

Modified:
  head/sys/kern/subr_disk.c

Modified: head/sys/kern/subr_disk.c
==
--- head/sys/kern/subr_disk.c   Mon Oct 26 03:26:18 2020(r367051)
+++ head/sys/kern/subr_disk.c   Mon Oct 26 04:04:06 2020(r367052)
@@ -26,7 +26,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
-static int bioq_batchsize = 0;
+static int bioq_batchsize = 128;
 SYSCTL_INT(_debug, OID_AUTO, bioq_batchsize, CTLFLAG_RW,
 _batchsize, 0, "BIOQ batch size");
 
@@ -172,6 +172,8 @@ bioq_remove(struct bio_queue_head *head, struct bio *b
head->insert_point = NULL;
 
TAILQ_REMOVE(>queue, bp, bio_queue);
+   if (TAILQ_EMPTY(>queue))
+   head->batched = 0;
head->total--;
 }
 
___
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: r367051 - in head: . usr.bin/calendar usr.bin/calendar/calendars usr.bin/calendar/calendars/de_AT.ISO_8859-15 usr.bin/calendar/calendars/de_DE.ISO8859-1 usr.bin/calendar/calendars/fr_FR...

2020-10-25 Thread Warner Losh
Author: imp
Date: Mon Oct 26 03:26:18 2020
New Revision: 367051
URL: https://svnweb.freebsd.org/changeset/base/367051

Log:
  calendar: remove all datafiles except freebsd one
  
  Move all the data files for the calendar(1) program, except
  calendar.freebsd to the calendar-data package. When a file
  can't be found, and /usr/local/share/calendar doesn't exist
  provide a helpful hint to install this package.
  
  Reviewed by: se@
  Differential Revision:  https://reviews.freebsd.org/D26926

Deleted:
  head/usr.bin/calendar/calendars/calendar.all
  head/usr.bin/calendar/calendars/calendar.australia
  head/usr.bin/calendar/calendars/calendar.birthday
  head/usr.bin/calendar/calendars/calendar.brazilian
  head/usr.bin/calendar/calendars/calendar.christian
  head/usr.bin/calendar/calendars/calendar.computer
  head/usr.bin/calendar/calendars/calendar.croatian
  head/usr.bin/calendar/calendars/calendar.dutch
  head/usr.bin/calendar/calendars/calendar.french
  head/usr.bin/calendar/calendars/calendar.german
  head/usr.bin/calendar/calendars/calendar.history
  head/usr.bin/calendar/calendars/calendar.holiday
  head/usr.bin/calendar/calendars/calendar.hungarian
  head/usr.bin/calendar/calendars/calendar.judaic
  head/usr.bin/calendar/calendars/calendar.lotr
  head/usr.bin/calendar/calendars/calendar.music
  head/usr.bin/calendar/calendars/calendar.newzealand
  head/usr.bin/calendar/calendars/calendar.russian
  head/usr.bin/calendar/calendars/calendar.southafrica
  head/usr.bin/calendar/calendars/calendar.ukrainian
  head/usr.bin/calendar/calendars/calendar.usholiday
  head/usr.bin/calendar/calendars/calendar.world
  head/usr.bin/calendar/calendars/de_AT.ISO_8859-15/
  head/usr.bin/calendar/calendars/de_DE.ISO8859-1/
  head/usr.bin/calendar/calendars/fr_FR.ISO8859-1/
  head/usr.bin/calendar/calendars/hr_HR.ISO8859-2/
  head/usr.bin/calendar/calendars/hu_HU.ISO8859-2/
  head/usr.bin/calendar/calendars/pt_BR.ISO8859-1/
  head/usr.bin/calendar/calendars/pt_BR.UTF-8/
  head/usr.bin/calendar/calendars/ru_RU.KOI8-R/
  head/usr.bin/calendar/calendars/ru_RU.UTF-8/
  head/usr.bin/calendar/calendars/uk_UA.KOI8-U/
Modified:
  head/ObsoleteFiles.inc
  head/UPDATING
  head/usr.bin/calendar/Makefile
  head/usr.bin/calendar/calendar.1
  head/usr.bin/calendar/io.c

Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc  Mon Oct 26 01:23:14 2020(r367050)
+++ head/ObsoleteFiles.inc  Mon Oct 26 03:26:18 2020(r367051)
@@ -36,6 +36,72 @@
 #   xargs -n1 | sort | uniq -d;
 # done
 
+# 20201025: Remove cal data files
+OLD_FILES+=usr/share/calendar/calendar.all
+OLD_FILES+=usr/share/calendar/calendar.australia
+OLD_FILES+=usr/share/calendar/calendar.birthday
+OLD_FILES+=usr/share/calendar/calendar.brazilian
+OLD_FILES+=usr/share/calendar/calendar.christian
+OLD_FILES+=usr/share/calendar/calendar.computer
+OLD_FILES+=usr/share/calendar/calendar.croatian
+OLD_FILES+=usr/share/calendar/calendar.dutch
+OLD_FILES+=usr/share/calendar/calendar.french
+OLD_FILES+=usr/share/calendar/calendar.german
+OLD_FILES+=usr/share/calendar/calendar.history
+OLD_FILES+=usr/share/calendar/calendar.holiday
+OLD_FILES+=usr/share/calendar/calendar.hungarian
+OLD_FILES+=usr/share/calendar/calendar.judaic
+OLD_FILES+=usr/share/calendar/calendar.lotr
+OLD_FILES+=usr/share/calendar/calendar.music
+OLD_FILES+=usr/share/calendar/calendar.newzealand
+OLD_FILES+=usr/share/calendar/calendar.russian
+OLD_FILES+=usr/share/calendar/calendar.southafrica
+OLD_FILES+=usr/share/calendar/calendar.ukrainian
+OLD_FILES+=usr/share/calendar/calendar.usholiday
+OLD_FILES+=usr/share/calendar/calendar.world
+OLD_FILES+=usr/share/calendar/de_AT.ISO_8859-15/calendar.feiertag
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.all
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.feiertag
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.geschichte
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.kirche
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.literatur
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.musik
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.wissenschaft
+OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.all
+OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.fetes
+OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.french
+OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.jferies
+OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.proverbes
+OLD_FILES+=usr/share/calendar/hr_HR.ISO8859-2/calendar.all
+OLD_FILES+=usr/share/calendar/hr_HR.ISO8859-2/calendar.praznici
+OLD_FILES+=usr/share/calendar/hu_HU.ISO8859-2/calendar.all
+OLD_FILES+=usr/share/calendar/hu_HU.ISO8859-2/calendar.nevnapok
+OLD_FILES+=usr/share/calendar/hu_HU.ISO8859-2/calendar.unnepek
+OLD_FILES+=usr/share/calendar/pt_BR.ISO8859-1/calendar.all
+OLD_FILES+=usr/share/calendar/pt_BR.ISO8859-1/calendar.commemorative
+OLD_FILES+=usr

svn commit: r367050 - stable/11/etc/rc.d

2020-10-25 Thread Cy Schubert
Author: cy
Date: Mon Oct 26 01:23:14 2020
New Revision: 367050
URL: https://svnweb.freebsd.org/changeset/base/367050

Log:
  This is a direct commit to stable/11 however it performs MFC r366857
  applied to stable/12 with r367049. This is due to src/etc/rc.d/netif
  having been previously moved to src/libexec/rc.d/netif.
  
  Destroy cloned interfaces at netif stop, netif restart and shutdown.
  This is especially important during shutdown because a child interface
  of lagg with WOL enabled will not enable WOL at interface shutdown and
  thus no WOL to wake up the device (and machine).
  
  PR:   158734, 109980
  Reported by:  Antonio Huete Jimenez 
Marat N.Afanasyev 
  reviewed by:kp

Modified:
  stable/11/etc/rc.d/netif

Modified: stable/11/etc/rc.d/netif
==
--- stable/11/etc/rc.d/netifMon Oct 26 01:18:15 2020(r367049)
+++ stable/11/etc/rc.d/netifMon Oct 26 01:23:14 2020(r367050)
@@ -28,7 +28,7 @@
 # PROVIDE: netif
 # REQUIRE: FILESYSTEMS iovctl serial sppp sysctl
 # REQUIRE: hostid ipfilter ipfs
-# KEYWORD: nojailvnet
+# KEYWORD: nojailvnet shutdown
 
 . /etc/rc.subr
 . /etc/network.subr
___
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: r367049 - stable/12/libexec/rc/rc.d

2020-10-25 Thread Cy Schubert
Author: cy
Date: Mon Oct 26 01:18:15 2020
New Revision: 367049
URL: https://svnweb.freebsd.org/changeset/base/367049

Log:
  MFC r366857:
  Destroy cloned interfaces at netif stop, netif restart and shutdown.
  This is especially important during shutdown because a child interface
  of lagg with WOL enabled will not enable WOL at interface shutdown and
  thus no WOL to wake up the device (and machine).
  
  PR:   158734, 109980
  Reported by:  Antonio Huete Jimenez 
Marat N.Afanasyev 
  reviewed by:  kp

Modified:
  stable/12/libexec/rc/rc.d/netif
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/libexec/rc/rc.d/netif
==
--- stable/12/libexec/rc/rc.d/netif Mon Oct 26 00:37:31 2020
(r367048)
+++ stable/12/libexec/rc/rc.d/netif Mon Oct 26 01:18:15 2020
(r367049)
@@ -28,7 +28,7 @@
 # PROVIDE: netif
 # REQUIRE: FILESYSTEMS iovctl serial sppp sysctl
 # REQUIRE: hostid ipfs
-# KEYWORD: nojailvnet
+# KEYWORD: nojailvnet shutdown
 
 . /etc/rc.subr
 . /etc/network.subr
___
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: r367048 - head/lib/libc/sys

2020-10-25 Thread Cy Schubert
In message <202010260059.09q0xbxt003...@slippy.cwsent.com>, Cy Schubert 
writes:
> In message <202010260037.09q0bvpn090...@repo.freebsd.org>, John-Mark Gurney 
> wri
> tes:
> > Author: jmg
> > Date: Mon Oct 26 00:37:31 2020
> > New Revision: 367048
> > URL: https://svnweb.freebsd.org/changeset/base/367048
> >
> > Log:
> >   update write(2)'s iovec limit w/ info about the iosize_max_clamp sysctl..
> .
> >
> > Modified:
> >   head/lib/libc/sys/write.2
> >
> > Modified: head/lib/libc/sys/write.2
> > ===
> ==
> > =
> > --- head/lib/libc/sys/write.2   Sun Oct 25 23:26:07 2020(r36704
> 7)
> > +++ head/lib/libc/sys/write.2   Mon Oct 26 00:37:31 2020(r36704
> 8)
> > @@ -28,7 +28,7 @@
> >  .\" @(#)write.28.5 (Berkeley) 4/2/94
> >  .\" $FreeBSD$
> >  .\"
> > -.Dd March 30, 2020
> > +.Dd October 25, 2020
> >  .Dt WRITE 2
> >  .Os
> >  .Sh NAME
> > @@ -240,9 +240,13 @@ array was negative.
> >  .It Bq Er EINVAL
> >  The sum of the
> >  .Fa iov_len
> > -values in the
> > -.Fa iov
> > -array overflowed a 32-bit integer.
> > +values is greater than
> > +.Dv SSIZE_MAX
> > +(or greater than
> > +.Dv INT_MAX ,
> > +if the sysctl
> > +.Va debug.iosize_max_clamp
>
> Should we also include SEE ALSO reference to sysctl(8) or sysctl(3)? 
> Personally I think a reference to  sysctl(8) would be more apropos.

Or maybe both.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.


___
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: r367048 - head/lib/libc/sys

2020-10-25 Thread Cy Schubert
In message <202010260037.09q0bvpn090...@repo.freebsd.org>, John-Mark Gurney 
wri
tes:
> Author: jmg
> Date: Mon Oct 26 00:37:31 2020
> New Revision: 367048
> URL: https://svnweb.freebsd.org/changeset/base/367048
>
> Log:
>   update write(2)'s iovec limit w/ info about the iosize_max_clamp sysctl...
>
> Modified:
>   head/lib/libc/sys/write.2
>
> Modified: head/lib/libc/sys/write.2
> =
> =
> --- head/lib/libc/sys/write.2 Sun Oct 25 23:26:07 2020(r367047)
> +++ head/lib/libc/sys/write.2 Mon Oct 26 00:37:31 2020(r367048)
> @@ -28,7 +28,7 @@
>  .\" @(#)write.2  8.5 (Berkeley) 4/2/94
>  .\" $FreeBSD$
>  .\"
> -.Dd March 30, 2020
> +.Dd October 25, 2020
>  .Dt WRITE 2
>  .Os
>  .Sh NAME
> @@ -240,9 +240,13 @@ array was negative.
>  .It Bq Er EINVAL
>  The sum of the
>  .Fa iov_len
> -values in the
> -.Fa iov
> -array overflowed a 32-bit integer.
> +values is greater than
> +.Dv SSIZE_MAX
> +(or greater than
> +.Dv INT_MAX ,
> +if the sysctl
> +.Va debug.iosize_max_clamp

Should we also include SEE ALSO reference to sysctl(8) or sysctl(3)? 
Personally I think a reference to  sysctl(8) would be more apropos.

> +is non-zero).
>  .It Bq Er ENOBUFS
>  The mbuf pool has been completely exhausted when writing to a socket.
>  .El
>


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.


___
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: r367048 - head/lib/libc/sys

2020-10-25 Thread John-Mark Gurney
Author: jmg
Date: Mon Oct 26 00:37:31 2020
New Revision: 367048
URL: https://svnweb.freebsd.org/changeset/base/367048

Log:
  update write(2)'s iovec limit w/ info about the iosize_max_clamp sysctl...

Modified:
  head/lib/libc/sys/write.2

Modified: head/lib/libc/sys/write.2
==
--- head/lib/libc/sys/write.2   Sun Oct 25 23:26:07 2020(r367047)
+++ head/lib/libc/sys/write.2   Mon Oct 26 00:37:31 2020(r367048)
@@ -28,7 +28,7 @@
 .\" @(#)write.28.5 (Berkeley) 4/2/94
 .\" $FreeBSD$
 .\"
-.Dd March 30, 2020
+.Dd October 25, 2020
 .Dt WRITE 2
 .Os
 .Sh NAME
@@ -240,9 +240,13 @@ array was negative.
 .It Bq Er EINVAL
 The sum of the
 .Fa iov_len
-values in the
-.Fa iov
-array overflowed a 32-bit integer.
+values is greater than
+.Dv SSIZE_MAX
+(or greater than
+.Dv INT_MAX ,
+if the sysctl
+.Va debug.iosize_max_clamp
+is non-zero).
 .It Bq Er ENOBUFS
 The mbuf pool has been completely exhausted when writing to a socket.
 .El
___
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

2020-10-25 Thread 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"


svn commit: r367047 - stable/11/sys/ofed/drivers/infiniband/ulp/ipoib

2020-10-25 Thread Ravi Pokala
Author: rpokala
Date: Sun Oct 25 23:26:07 2020
New Revision: 367047
URL: https://svnweb.freebsd.org/changeset/base/367047

Log:
  MFC r366686:
  
  Allow IP over IB to work with multiple FIBs.
  
  Call M_SETFIB() to make sure the IPoIB packet is directed to the correct
  interface-specific FIB.
  
  This was sufficient to allow general-purpose routing using the default FIB,
  and a separate FIB for routing between IPoIB on ib0 and IPoEthernet on mce0.
  
  Reviewed by:  hselasky
  Obtained from:Anmol Kumar 
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D26733

Modified:
  stable/11/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c
==
--- stable/11/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.cSun Oct 
25 23:25:53 2020(r367046)
+++ stable/11/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.cSun Oct 
25 23:26:07 2020(r367047)
@@ -1601,6 +1601,8 @@ ipoib_demux(struct ifnet *ifp, struct mbuf *m, u_short
m_freem(m);
return;
}
+   /* Direct packet to correct FIB based on interface config */
+   M_SETFIB(m, ifp->if_fib);
/*
 * Dispatch frame to upper layer.
 */
___
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: r367046 - stable/12/sys/ofed/drivers/infiniband/ulp/ipoib

2020-10-25 Thread Ravi Pokala
Author: rpokala
Date: Sun Oct 25 23:25:53 2020
New Revision: 367046
URL: https://svnweb.freebsd.org/changeset/base/367046

Log:
  MFC r366686:
  
  Allow IP over IB to work with multiple FIBs.
  
  Call M_SETFIB() to make sure the IPoIB packet is directed to the correct
  interface-specific FIB.
  
  This was sufficient to allow general-purpose routing using the default FIB,
  and a separate FIB for routing between IPoIB on ib0 and IPoEthernet on mce0.
  
  Reviewed by:  hselasky
  Obtained from:Anmol Kumar 
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D26733

Modified:
  stable/12/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c
==
--- stable/12/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.cSun Oct 
25 21:04:07 2020(r367045)
+++ stable/12/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.cSun Oct 
25 23:25:53 2020(r367046)
@@ -1603,6 +1603,8 @@ ipoib_demux(struct ifnet *ifp, struct mbuf *m, u_short
m_freem(m);
return;
}
+   /* Direct packet to correct FIB based on interface config */
+   M_SETFIB(m, ifp->if_fib);
/*
 * Dispatch frame to upper layer.
 */
___
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: r367038 - head/sbin/mount_nullfs

2020-10-25 Thread Cy Schubert
In message <20201025213509.GA1671@brick>, Edward Tomasz Napierala writes:
> On 1025T0717, Cy Schubert wrote:
> > In message  c
> > om>
> > , Oliver Pinter writes:
> > > On Sunday, October 25, 2020, Edward Tomasz Napierala 
> > > wrote:
> > >
> > > > Author: trasz
> > > > Date: Sun Oct 25 14:09:00 2020
> > > > New Revision: 367038
> > > > URL: https://svnweb.freebsd.org/changeset/base/367038
> > > >
> > > > Log:
> > > >   Remove the check that prevents creating "loops" from mount_nullfs(8).
> > > >
> > > >
> > > The simple question is: why?
> > 
> > I was about to ask that myself.
> > 
> > The why is usually more important than the how.
>
> Two reasons.
>
> First, from what I can tell this is an artificial limitation which serves
> no purpose.  I thought it was to prevent some kind of deadlock between
> vnodes, so I asked kib@, and he mentioned removing that very limitation
> from the kernel code; thus, it looks to me like a historical leftover.
>
> Second, I've stumbled upon this when trying to nullfs-mount '/' on
> '/compat/ubuntu/bsd/', which would be useful for autochroot functionality,
> when (or if) it becomes a thing.

Thanks.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.


___
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: r367038 - head/sbin/mount_nullfs

2020-10-25 Thread Oliver Pinter
On Sunday, October 25, 2020, Edward Tomasz Napierala 
wrote:

> On 1025T0717, Cy Schubert wrote:
> > In message  gmail.c
> > om>
> > , Oliver Pinter writes:
> > > On Sunday, October 25, 2020, Edward Tomasz Napierala <
> tr...@freebsd.org>
> > > wrote:
> > >
> > > > Author: trasz
> > > > Date: Sun Oct 25 14:09:00 2020
> > > > New Revision: 367038
> > > > URL: https://svnweb.freebsd.org/changeset/base/367038
> > > >
> > > > Log:
> > > >   Remove the check that prevents creating "loops" from
> mount_nullfs(8).
> > > >
> > > >
> > > The simple question is: why?
> >
> > I was about to ask that myself.
> >
> > The why is usually more important than the how.
>
> Two reasons.
>
> First, from what I can tell this is an artificial limitation which serves
> no purpose.  I thought it was to prevent some kind of deadlock between
> vnodes, so I asked kib@, and he mentioned removing that very limitation
> from the kernel code; thus, it looks to me like a historical leftover.
>
> Second, I've stumbled upon this when trying to nullfs-mount '/' on
> '/compat/ubuntu/bsd/', which would be useful for autochroot functionality,
> when (or if) it becomes a thing.


Thank you!
___
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: r367038 - head/sbin/mount_nullfs

2020-10-25 Thread Edward Tomasz Napierala
On 1025T0717, Cy Schubert wrote:
> In message  om>
> , Oliver Pinter writes:
> > On Sunday, October 25, 2020, Edward Tomasz Napierala 
> > wrote:
> >
> > > Author: trasz
> > > Date: Sun Oct 25 14:09:00 2020
> > > New Revision: 367038
> > > URL: https://svnweb.freebsd.org/changeset/base/367038
> > >
> > > Log:
> > >   Remove the check that prevents creating "loops" from mount_nullfs(8).
> > >
> > >
> > The simple question is: why?
> 
> I was about to ask that myself.
> 
> The why is usually more important than the how.

Two reasons.

First, from what I can tell this is an artificial limitation which serves
no purpose.  I thought it was to prevent some kind of deadlock between
vnodes, so I asked kib@, and he mentioned removing that very limitation
from the kernel code; thus, it looks to me like a historical leftover.

Second, I've stumbled upon this when trying to nullfs-mount '/' on
'/compat/ubuntu/bsd/', which would be useful for autochroot functionality,
when (or if) it becomes a thing.

___
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: r367045 - head/sbin/fsck_ffs

2020-10-25 Thread Kirk McKusick
Author: mckusick
Date: Sun Oct 25 21:04:07 2020
New Revision: 367045
URL: https://svnweb.freebsd.org/changeset/base/367045

Log:
  Use proper type (ino_t) for inode numbers to avoid improper sign extention
  in the Pass 5 checks. The manifestation was fsck_ffs exiting with this error:
  
** Phase 5 - Check Cyl groups
fsck_ffs: inoinfo: inumber 18446744071562087424 out of range
  
  The error only manifests itself for filesystems bigger than about 100Tb.
  
  Reported by:  Nikita Grechikhin 
  MFC after:2 weeks
  Sponsored by: Netflix

Modified:
  head/sbin/fsck_ffs/pass5.c

Modified: head/sbin/fsck_ffs/pass5.c
==
--- head/sbin/fsck_ffs/pass5.c  Sun Oct 25 19:34:02 2020(r367044)
+++ head/sbin/fsck_ffs/pass5.c  Sun Oct 25 21:04:07 2020(r367045)
@@ -63,6 +63,7 @@ pass5(void)
struct fs *fs = 
ufs2_daddr_t d, dbase, dmax, start;
int rewritecg = 0;
+   ino_t inum;
struct csum *cs;
struct csum_total cstotal;
struct inodesc idesc[3];
@@ -238,9 +239,9 @@ pass5(void)
}
memset(>cg_frsum[0], 0, sizeof newcg->cg_frsum);
memset(cg_inosused(newcg), 0, (size_t)(mapsize));
-   j = fs->fs_ipg * c;
-   for (i = 0; i < inostathead[c].il_numalloced; j++, i++) {
-   switch (inoinfo(j)->ino_state) {
+   inum = fs->fs_ipg * c;
+   for (i = 0; i < inostathead[c].il_numalloced; inum++, i++) {
+   switch (inoinfo(inum)->ino_state) {
 
case USTATE:
break;
@@ -260,10 +261,10 @@ pass5(void)
break;
 
default:
-   if (j < (int)UFS_ROOTINO)
+   if (inum < UFS_ROOTINO)
break;
-   errx(EEXIT, "BAD STATE %d FOR INODE I=%d",
-   inoinfo(j)->ino_state, j);
+   errx(EEXIT, "BAD STATE %d FOR INODE I=%ju",
+   inoinfo(inum)->ino_state, (uintmax_t)inum);
}
}
if (c == 0)
___
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: r367044 - in head/sys: cam cam/ctl dev/iscsi dev/isp dev/mpr dev/mps dev/ocs_fc

2020-10-25 Thread Alexander Motin
Author: mav
Date: Sun Oct 25 19:34:02 2020
New Revision: 367044
URL: https://svnweb.freebsd.org/changeset/base/367044

Log:
  Introduce support of SCSI Command Priority.
  
  SAM-3 specification introduced concept of Task Priority, that was renamed
  to Command Priority in SAM-4, and supported by all modern SCSI transports.
  It provides 15 levels of relative priorities: 1 - highest, 15 - lowest and
  0 - default.  SAT specification for SATA devices translates priorities 1-3
  into NCQ high priority.
  
  This change adds new "priority" field into empty spots of struct ccb_scsiio
  and struct ccb_accept_tio of CAM and struct ctl_scsiio of CTL.  Respective
  support is added into iscsi(4), isp(4), mpr(4), mps(4) and ocs_fc(4) drivers
  for both initiator and where applicable target roles.  Minimal support was
  added to CTL to receive the priority value from different frontends, pass it
  between HA controllers and report in few places.
  
  This patch does not add consumers of this functionality, so nothing should
  really change yet, since the field is still set to 0 (default) on initiator
  and not actively used on target.  Those are to be implemented separately.
  
  I've confirmed priority working on WD Red SATA disks connected via mpr(4)
  and properly transferred to CTL target via iscsi(4), isp(4) and ocs_fc(4).
  
  While there, added missing tag_action support to ocs_fc(4) initiator role.
  
  MFC after:1 month
  Relnotes: yes
  Sponsored by: iXsystems, Inc.

Modified:
  head/sys/cam/cam_ccb.h
  head/sys/cam/ctl/ctl.c
  head/sys/cam/ctl/ctl_frontend_cam_sim.c
  head/sys/cam/ctl/ctl_frontend_iscsi.c
  head/sys/cam/ctl/ctl_io.h
  head/sys/cam/ctl/ctl_util.c
  head/sys/cam/ctl/scsi_ctl.c
  head/sys/dev/iscsi/iscsi.c
  head/sys/dev/isp/isp.c
  head/sys/dev/isp/isp_freebsd.c
  head/sys/dev/isp/isp_freebsd.h
  head/sys/dev/isp/isp_stds.h
  head/sys/dev/isp/ispvar.h
  head/sys/dev/mpr/mpr_sas.c
  head/sys/dev/mps/mps_sas.c
  head/sys/dev/ocs_fc/ocs_cam.c
  head/sys/dev/ocs_fc/ocs_scsi.c
  head/sys/dev/ocs_fc/ocs_scsi.h
  head/sys/dev/ocs_fc/ocs_unsol.c

Modified: head/sys/cam/cam_ccb.h
==
--- head/sys/cam/cam_ccb.h  Sun Oct 25 18:27:21 2020(r367043)
+++ head/sys/cam/cam_ccb.h  Sun Oct 25 19:34:02 2020(r367044)
@@ -758,6 +758,7 @@ struct ccb_scsiio {
 * from scsi_message.h.
 */
 #defineCAM_TAG_ACTION_NONE 0x00
+   uint8_tpriority;/* Command priority for SIMPLE tag */
u_int  tag_id;  /* tag id from initator (target mode) */
u_int  init_id; /* initiator id of who selected */
 #if defined(BUF_TRACKING) || defined(FULL_BUF_TRACKING)
@@ -805,6 +806,7 @@ struct ccb_accept_tio {
u_int8_t   cdb_len; /* Number of bytes for the CDB */
u_int8_t   tag_action;  /* What to do for tag queueing */
u_int8_t   sense_len;   /* Number of bytes of Sense Data */
+   uint8_tpriority;/* Command priority for SIMPLE tag */
u_int  tag_id;  /* tag id from initator (target mode) */
u_int  init_id; /* initiator id of who selected */
struct scsi_sense_data sense_data;
@@ -1392,6 +1394,7 @@ cam_fill_csio(struct ccb_scsiio *csio, u_int32_t retri
csio->sense_len = sense_len;
csio->cdb_len = cdb_len;
csio->tag_action = tag_action;
+   csio->priority = 0;
 #if defined(BUF_TRACKING) || defined(FULL_BUF_TRACKING)
csio->bio = NULL;
 #endif
@@ -1414,6 +1417,7 @@ cam_fill_ctio(struct ccb_scsiio *csio, u_int32_t retri
csio->dxfer_len = dxfer_len;
csio->scsi_status = scsi_status;
csio->tag_action = tag_action;
+   csio->priority = 0;
csio->tag_id = tag_id;
csio->init_id = init_id;
 }

Modified: head/sys/cam/ctl/ctl.c
==
--- head/sys/cam/ctl/ctl.c  Sun Oct 25 18:27:21 2020(r367043)
+++ head/sys/cam/ctl/ctl.c  Sun Oct 25 19:34:02 2020(r367044)
@@ -1457,6 +1457,7 @@ ctl_isc_event_handler(ctl_ha_channel channel, ctl_ha_e
if (softc->ha_mode != CTL_HA_MODE_XFER)
io->io_hdr.flags |= CTL_FLAG_INT_COPY;
io->io_hdr.nexus = msg->hdr.nexus;
+   io->scsiio.priority = msg->scsi.priority;
io->scsiio.tag_num = msg->scsi.tag_num;
io->scsiio.tag_type = msg->scsi.tag_type;
 #ifdef CTL_TIME_IO
@@ -11603,8 +11604,9 @@ ctl_scsiio_precheck(struct ctl_softc *softc, struct ct
msg_info.hdr.nexus = ctsio->io_hdr.nexus;
msg_info.scsi.tag_num = ctsio->tag_num;
msg_info.scsi.tag_type = ctsio->tag_type;
-   msg_info.scsi.cdb_len = ctsio->cdb_len;
  

svn commit: r367043 - head/libexec/rc/rc.d

2020-10-25 Thread Ed Maste
Author: emaste
Date: Sun Oct 25 18:27:21 2020
New Revision: 367043
URL: https://svnweb.freebsd.org/changeset/base/367043

Log:
  rc.d/syscons: remove spaces before tab

Modified:
  head/libexec/rc/rc.d/syscons

Modified: head/libexec/rc/rc.d/syscons
==
--- head/libexec/rc/rc.d/sysconsSun Oct 25 18:06:45 2020
(r367042)
+++ head/libexec/rc/rc.d/sysconsSun Oct 25 18:27:21 2020
(r367043)
@@ -151,7 +151,7 @@ kbdcontrol_load_keymap()
if [ -n "${keymap_vt}" ]; then
errmsg=`kbdcontrol < ${kbddev} -l ${keymap_vt} 2>&1`
if [ -z "${errmsg}" ]; then
-   _sc_keymap_msg="New keymap: In /etc/rc.conf 
replace 'keymap=${keymap}' by 'keymap=${keymap_vt}'"
+   _sc_keymap_msg="New keymap: In /etc/rc.conf 
replace 'keymap=${keymap}' by 'keymap=${keymap_vt}'"
fi
else
_sc_keymap_msg="No replacement found for keymap 
'${keymap}'.
___
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: r366993 - head/sys/net

2020-10-25 Thread Pedro Giffuni

On 10/24/20 8:19 PM, Ed Maste wrote:

On Sat, 24 Oct 2020 at 11:27, Warner Losh  wrote:

Given we already have nice .clang-format, that does most of the job, maybe it's 
worth considering looking into tweaking it further to fix this part?
It would be nice if we could finally offload all formatting issues to the tool 
and focus on the actual code :-)

It would be nice if it produced one of the style(9) acceptable formats without 
disrupting things already acceptable.  That's been the big problem with the 
tweaks to date... some things are fixed, others break. It's getting a lot 
closer, though

Upstream clang-format comes with a script that can integrate with git,
adding a `git clang-format` command. It will apply formatting to
modified lines, leaving unchanged ones alone.


I doubt any script can match style(9) perfectly. indent(1) with bde's 
flags came near in some edge cases but generally did a horrible job. 
Also, out style(9) is not mandatory for userland.


Pedro.

___
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: r367042 - head/usr.sbin/mergemaster

2020-10-25 Thread Ed Maste
Author: emaste
Date: Sun Oct 25 18:06:45 2020
New Revision: 367042
URL: https://svnweb.freebsd.org/changeset/base/367042

Log:
  mergemaster: Clarify installed and updated versions
  
  Describe "diff installed new" as "Displaying differences between
  installed and new."  Previously mergemaster described them in the
  opposite order.
  
  PR:   249214
  Reported by:  Yuri Victorovich
  MFC after:2 weeks

Modified:
  head/usr.sbin/mergemaster/mergemaster.sh

Modified: head/usr.sbin/mergemaster/mergemaster.sh
==
--- head/usr.sbin/mergemaster/mergemaster.shSun Oct 25 16:58:48 2020
(r367041)
+++ head/usr.sbin/mergemaster/mergemaster.shSun Oct 25 18:06:45 2020
(r367042)
@@ -143,7 +143,7 @@ diff_loop () {
echo '   
==   '
echo ''
 (
-  echo "  *** Displaying differences between ${COMPFILE} and installed 
version:"
+  echo "  *** Displaying differences between installed version and 
${COMPFILE}:"
   echo ''
   diff ${DIFF_FLAG} ${DIFF_OPTIONS} "${DESTDIR}${COMPFILE#.}" 
"${COMPFILE}"
 ) | ${PAGER}
___
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: r367041 - head/sys/dev/ocs_fc

2020-10-25 Thread Alexander Motin
Author: mav
Date: Sun Oct 25 16:58:48 2020
New Revision: 367041
URL: https://svnweb.freebsd.org/changeset/base/367041

Log:
  Fix incorrect constants of target tag action.
  
  ocs_scsi_recv_cmd() receives the flags after ocs_get_flags_fcp_cmd(),
  which translates them from FCP_TASK_ATTR_* to OCS_SCSI_CMD_*.  As result
  non-SIMPLE requests turned into HEAD or ORDERED depending on direction.
  
  MFC after:2 weeks

Modified:
  head/sys/dev/ocs_fc/ocs_cam.c

Modified: head/sys/dev/ocs_fc/ocs_cam.c
==
--- head/sys/dev/ocs_fc/ocs_cam.c   Sun Oct 25 16:01:03 2020
(r367040)
+++ head/sys/dev/ocs_fc/ocs_cam.c   Sun Oct 25 16:58:48 2020
(r367041)
@@ -576,9 +576,9 @@ int32_t ocs_scsi_recv_cmd(ocs_io_t *io, uint64_t lun, 
 
if (flags & OCS_SCSI_CMD_SIMPLE)
atio->tag_action = MSG_SIMPLE_Q_TAG;
-   else if (flags &  FCP_TASK_ATTR_HEAD_OF_QUEUE)
+   else if (flags & OCS_SCSI_CMD_HEAD_OF_QUEUE)
atio->tag_action = MSG_HEAD_OF_Q_TAG;
-   else if (flags & FCP_TASK_ATTR_ORDERED)
+   else if (flags & OCS_SCSI_CMD_ORDERED)
atio->tag_action = MSG_ORDERED_Q_TAG;
else
atio->tag_action = 0;
___
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

2020-10-25 Thread Warner Losh
On Sun, Oct 25, 2020, 9:04 AM Kyle Evans  wrote:

> On Sun, Oct 25, 2020 at 5:21 AM Stefan Esser  wrote:
> >
> > Am 25.10.20 um 04:46 schrieb Rodney W. Grimes:
> > >> On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes <
> free...@gndrsh.dnsmgr.net>
> > >> wrote:
> >  +#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.
> >
> > There already are places that hard-code /usr/local, and I do agree
> > that this is architecturally bad, if you want to keep the base system
> > and ports as independent from each other as possible.
> >
> > But I do disagree that this was worse than before, and I'd even consider
> > replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE
> > in our sources (but not introduce new references to LOCALBASE in base).
> >
> > This would simplify a grep for such source files, for example, and also
> > to build base for systems with modified LOCALBASE.
> >
> > The following C header files in base (ignoring contrib) contain the
> > string /usr/local:
> >
> > ...
> > sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?)
> > ...
>
> I see that you've excluded sys/contrib from the initial review, but I
> would not bother with luaconf.h in particular. These definitions just
> come from a stock Lua 5.2 and are not used in a ZFS context, they've
> ripped out loadlib and anything else that could try.
>

As an aside: I looked at using this Lua for the boot loader, but quickly
found that it was no good for that purpose due to changes like that. And it
was too far hacked from 5.2 to try to update easily...

Warner

Thanks,
>
> Kyle Evans
>
___
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: r367040 - head/usr.bin/calendar

2020-10-25 Thread Mateusz Piotrowski
Author: 0mp (doc,ports committer)
Date: Sun Oct 25 16:01:03 2020
New Revision: 367040
URL: https://svnweb.freebsd.org/changeset/base/367040

Log:
  calendar.1: Fix locale of the month in Dd ;)

Modified:
  head/usr.bin/calendar/calendar.1

Modified: head/usr.bin/calendar/calendar.1
==
--- head/usr.bin/calendar/calendar.1Sun Oct 25 15:01:01 2020
(r367039)
+++ head/usr.bin/calendar/calendar.1Sun Oct 25 16:01:03 2020
(r367040)
@@ -28,7 +28,7 @@
 .\" @(#)calendar.1  8.1 (Berkeley) 6/29/93
 .\" $FreeBSD$
 .\"
-.Dd Oktober 23, 2020
+.Dd October 23, 2020
 .Dt CALENDAR 1
 .Os
 .Sh NAME
___
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

2020-10-25 Thread Kyle Evans
On Sun, Oct 25, 2020 at 5:21 AM Stefan Esser  wrote:
>
> Am 25.10.20 um 04:46 schrieb Rodney W. Grimes:
> >> On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes 
> >> 
> >> wrote:
>  +#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.
>
> There already are places that hard-code /usr/local, and I do agree
> that this is architecturally bad, if you want to keep the base system
> and ports as independent from each other as possible.
>
> But I do disagree that this was worse than before, and I'd even consider
> replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE
> in our sources (but not introduce new references to LOCALBASE in base).
>
> This would simplify a grep for such source files, for example, and also
> to build base for systems with modified LOCALBASE.
>
> The following C header files in base (ignoring contrib) contain the
> string /usr/local:
>
> ...
> sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?)
> ...

I see that you've excluded sys/contrib from the initial review, but I
would not bother with luaconf.h in particular. These definitions just
come from a stock Lua 5.2 and are not used in a ZFS context, they've
ripped out loadlib and anything else that could try.

Thanks,

Kyle Evans
___
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: r367039 - head/sbin/ifconfig

2020-10-25 Thread Mateusz Piotrowski
Author: 0mp (doc,ports committer)
Date: Sun Oct 25 15:01:01 2020
New Revision: 367039
URL: https://svnweb.freebsd.org/changeset/base/367039

Log:
  ifconfig.8: Remove spurious commas
  
  Correct misuse of commas/parentheses in an enumeration that makes the
  number of actual parameters more important than expected.
  
  PR:   250526
  Submitted by: Samy Mahmoudi 
  MFC after:1 week

Modified:
  head/sbin/ifconfig/ifconfig.8

Modified: head/sbin/ifconfig/ifconfig.8
==
--- head/sbin/ifconfig/ifconfig.8   Sun Oct 25 14:09:00 2020
(r367038)
+++ head/sbin/ifconfig/ifconfig.8   Sun Oct 25 15:01:01 2020
(r367039)
@@ -28,7 +28,7 @@
 .\" From: @(#)ifconfig.8   8.3 (Berkeley) 1/5/94
 .\" $FreeBSD$
 .\"
-.Dd October 21, 2020
+.Dd October 25, 2020
 .Dt IFCONFIG 8
 .Os
 .Sh NAME
@@ -884,10 +884,10 @@ is one of
 .Cm ahdemo
 (or
 .Cm adhoc-demo ) ,
-.Cm ibss ,
+.Cm ibss
 (or
 .Cm adhoc ) ,
-.Cm ap ,
+.Cm ap
 (or
 .Cm hostap ) ,
 .Cm wds ,
___
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: r367038 - head/sbin/mount_nullfs

2020-10-25 Thread Cy Schubert
In message 
, Oliver Pinter writes:
> On Sunday, October 25, 2020, Edward Tomasz Napierala 
> wrote:
>
> > Author: trasz
> > Date: Sun Oct 25 14:09:00 2020
> > New Revision: 367038
> > URL: https://svnweb.freebsd.org/changeset/base/367038
> >
> > Log:
> >   Remove the check that prevents creating "loops" from mount_nullfs(8).
> >
> >
> The simple question is: why?

I was about to ask that myself.

The why is usually more important than the how.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.



___
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: r367038 - head/sbin/mount_nullfs

2020-10-25 Thread Oliver Pinter
On Sunday, October 25, 2020, Edward Tomasz Napierala 
wrote:

> Author: trasz
> Date: Sun Oct 25 14:09:00 2020
> New Revision: 367038
> URL: https://svnweb.freebsd.org/changeset/base/367038
>
> Log:
>   Remove the check that prevents creating "loops" from mount_nullfs(8).
>
>
The simple question is: why?



>   Reviewed by:  kib
>   MFC after:2 weeks
>   Sponsored by: The FreeBSD Foundation
>   Differential Revision:https://reviews.freebsd.org/D26921
>
> Modified:
>   head/sbin/mount_nullfs/mount_nullfs.c
>
> Modified: head/sbin/mount_nullfs/mount_nullfs.c
> 
> ==
> --- head/sbin/mount_nullfs/mount_nullfs.c   Sun Oct 25 10:08:46 2020
>   (r367037)
> +++ head/sbin/mount_nullfs/mount_nullfs.c   Sun Oct 25 14:09:00 2020
>   (r367038)
> @@ -59,7 +59,6 @@ static const char rcsid[] =
>
>  #include "mntopts.h"
>
> -intsubdir(const char *, const char *);
>  static voidusage(void) __dead2;
>
>  int
> @@ -104,10 +103,6 @@ main(int argc, char *argv[])
> if (checkpath(argv[1], source) != 0)
> err(EX_USAGE, "%s", source);
>
> -   if (subdir(target, source) || subdir(source, target))
> -   errx(EX_USAGE, "%s (%s) and %s are not distinct paths",
> -   argv[0], target, argv[1]);
> -
> build_iovec(, , "fstype", nullfs, (size_t)-1);
> build_iovec(, , "fspath", source, (size_t)-1);
> build_iovec(, , "target", target, (size_t)-1);
> @@ -119,21 +114,6 @@ main(int argc, char *argv[])
> err(1, "%s", source);
> }
> exit(0);
> -}
> -
> -int
> -subdir(const char *p, const char *dir)
> -{
> -   int l;
> -
> -   l = strlen(dir);
> -   if (l <= 1)
> -   return (1);
> -
> -   if ((strncmp(p, dir, l) == 0) && (p[l] == '/' || p[l] == '\0'))
> -   return (1);
> -
> -   return (0);
>  }
>
>  static void
> ___
> 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"
>
___
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: r367038 - head/sbin/mount_nullfs

2020-10-25 Thread Edward Tomasz Napierala
Author: trasz
Date: Sun Oct 25 14:09:00 2020
New Revision: 367038
URL: https://svnweb.freebsd.org/changeset/base/367038

Log:
  Remove the check that prevents creating "loops" from mount_nullfs(8).
  
  Reviewed by:  kib
  MFC after:2 weeks
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D26921

Modified:
  head/sbin/mount_nullfs/mount_nullfs.c

Modified: head/sbin/mount_nullfs/mount_nullfs.c
==
--- head/sbin/mount_nullfs/mount_nullfs.c   Sun Oct 25 10:08:46 2020
(r367037)
+++ head/sbin/mount_nullfs/mount_nullfs.c   Sun Oct 25 14:09:00 2020
(r367038)
@@ -59,7 +59,6 @@ static const char rcsid[] =
 
 #include "mntopts.h"
 
-intsubdir(const char *, const char *);
 static voidusage(void) __dead2;
 
 int
@@ -104,10 +103,6 @@ main(int argc, char *argv[])
if (checkpath(argv[1], source) != 0)
err(EX_USAGE, "%s", source);
 
-   if (subdir(target, source) || subdir(source, target))
-   errx(EX_USAGE, "%s (%s) and %s are not distinct paths",
-   argv[0], target, argv[1]);
-
build_iovec(, , "fstype", nullfs, (size_t)-1);
build_iovec(, , "fspath", source, (size_t)-1);
build_iovec(, , "target", target, (size_t)-1);
@@ -119,21 +114,6 @@ main(int argc, char *argv[])
err(1, "%s", source);
}
exit(0);
-}
-
-int
-subdir(const char *p, const char *dir)
-{
-   int l;
-
-   l = strlen(dir);
-   if (l <= 1)
-   return (1);
-
-   if ((strncmp(p, dir, l) == 0) && (p[l] == '/' || p[l] == '\0'))
-   return (1);
-
-   return (0);
 }
 
 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"


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

2020-10-25 Thread Stefan Esser

Am 25.10.20 um 06:56 schrieb Alex Kozlov:

On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote:

Am 24.10.20 um 09:48 schrieb Alex Kozlov:

[...]

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


Yes, and I do not need to look that up in the handbook, having been
a ports committer for 2 decades by now.


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


How is that any different than before?

What I did is make the PATH easier to change when you rebuild base.

There are numerous programs in base that contain the literal string
/usr/local - and what I did was implement a mechanism that allows
to replace this literal reference with a simple change in paths.h.

If you do not modify paths.h for a different LOCALBASE, then you'll
get a wrong _PATH_DEFPATH compiled into your binaries, for example.


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.


I'd hope so to get rid of many of the 1713 literal uses of /usr/local
in our source tree.


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.


Yes, I already suggested CALENDAR_HOME, but as an environment variable
to check, if you want to be able to path an additional directory (or
search path) to the calendar program at run-time. But why introduce
a CALENDAR_HOME macro in the sources, if the port supplied calendar
files are known to be found at LOCALBASE/share/calendar (for some value
of LOCALBASE).

I want to make more programs that currently hard-code /usr/local use
_PATH_LOCALBASE instead. This C macro can then be default to /usr/local
but can be overridden by passing LOCALBASE to the compiler (from the
build infrastructure) when paths.h is included.

Instead of referring to _PATH_LOCALBASE these files could directly use
LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I
think it is best to follow this precedent.


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


My change did not add any dependency on LOCALBASE to any previously
existing functionality. It added support for calendar files provided
by a port (a feature that did not exist before) at a location that is
correct for the big majority of users (who do not modify LOCALBASE).

As I said: I'm going to make it easier to build the base system with
a different LOCALBASE, but not by run-time checking an environment
variable that specifies LOCALBASE in each affected program.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature


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

2020-10-25 Thread Stefan Esser

Am 25.10.20 um 04:46 schrieb Rodney W. Grimes:

On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes 
wrote:

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


There already are places that hard-code /usr/local, and I do agree
that this is architecturally bad, if you want to keep the base system
and ports as independent from each other as possible.

But I do disagree that this was worse than before, and I'd even consider
replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE
in our sources (but not introduce new references to LOCALBASE in base).

This would simplify a grep for such source files, for example, and also
to build base for systems with modified LOCALBASE.

The following C header files in base (ignoring contrib) contain the
string /usr/local:

crypto/openssh/pathnames.h
sys/sys/imgact_binmisc.h
sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?)
usr.bin/fortune/fortune/pathnames.h
usr.bin/mail/pathnames.h
usr.sbin/cron/cron/pathnames.h
usr.sbin/pkg/config.h
usr.sbin/pciconf/pathnames.h
usr.sbin/pciconf-xo/pathnames.h

These are C source files that include that string:

crypto/openssh/ssh-agent.c
crypto/openssh/regress/unittests/sshkey/test_sshkey.c
lib/libfetch/common.c
lib/libc/rpc/getnetconfig.c
lib/libc/nls/msgcat.c
sbin/nvmecontrol/nvmecontrol.c
sys/contrib/openzfs/cmd/zpool/zpool_main.c (FreeBSD specific?)
tools/tools/ath/athprom/athprom.c
tools/tools/net80211/wesside/wesside/wesside.c
usr.bin/env/envopts.c
usr.sbin/bsnmpd/tools/libbsnmptools/bsnmpimport.c
usr.sbin/mailwrapper/mailwrapper.c
usr.sbin/cpucontrol/cpucontrol.c

I intend to prepare a review top make them use _PATH_LOCALBASE instead.
(There might be sources under contrib that have no external up-stream
anymore, but I have not made an attempt to identify them, yet.)

There are 67 man-pages (excluding contrib) that mention /usr/local
and they will not be covered by this C macro definition.

There are further references to /usr/local, e.g. in 32 shell scripts
(outside contrib).

The next step could be to use the LOCALBASE variable that is defined
in Makefile.inc1 to provide the value used to define _PATH_LOCALBASE
in paths.h. This make variable is currently not used in bsd.prog.mk,
but it easily could, allowing to override the value used to build
the world in make.conf.

But I'd suggest to go step by step, and the first step that I suggest
(and am willing to work on) is to remove as many literal uses of
/usr/local in C sources in base (excluding contrib) as reasonable.

Maybe we should have some documentation about building the world for
systems with non-default LOCALBASE ...

Regards, STefan
___
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: r367037 - head/sys/arm64/arm64

2020-10-25 Thread Ruslan Bukin
Author: br
Date: Sun Oct 25 10:08:46 2020
New Revision: 367037
URL: https://svnweb.freebsd.org/changeset/base/367037

Log:
  Add IOMMU support to GICv3 Interrupt Translation Service (ITS) driver.
  
  Submitted by: andrew
  Sponsored by: Innovate DSbD
  Differential Revision:https://reviews.freebsd.org/D26878

Modified:
  head/sys/arm64/arm64/gicv3_its.c

Modified: head/sys/arm64/arm64/gicv3_its.c
==
--- head/sys/arm64/arm64/gicv3_its.cSun Oct 25 07:48:07 2020
(r367036)
+++ head/sys/arm64/arm64/gicv3_its.cSun Oct 25 10:08:46 2020
(r367037)
@@ -32,6 +32,7 @@
 
 #include "opt_acpi.h"
 #include "opt_platform.h"
+#include "opt_iommu.h"
 
 #include 
 __FBSDID("$FreeBSD$");
@@ -47,6 +48,8 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +59,7 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -72,6 +76,11 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#ifdef IOMMU
+#include 
+#include 
+#endif
+
 #include "pcib_if.h"
 #include "pic_if.h"
 #include "msi_if.h"
@@ -269,6 +278,7 @@ struct gicv3_its_softc {
 #defineITS_FLAGS_ERRATA_CAVIUM_22375   0x0004
u_int sc_its_flags;
booltrace_enable;
+   vm_page_t ma; /* fake msi page */
 };
 
 static void *conf_base;
@@ -321,6 +331,10 @@ static msi_release_msi_t gicv3_its_release_msi;
 static msi_alloc_msix_t gicv3_its_alloc_msix;
 static msi_release_msix_t gicv3_its_release_msix;
 static msi_map_msi_t gicv3_its_map_msi;
+#ifdef IOMMU
+static msi_iommu_init_t gicv3_iommu_init;
+static msi_iommu_deinit_t gicv3_iommu_deinit;
+#endif
 
 static void its_cmd_movi(device_t, struct gicv3_its_irqsrc *);
 static void its_cmd_mapc(device_t, struct its_col *, uint8_t);
@@ -352,6 +366,10 @@ static device_method_t gicv3_its_methods[] = {
DEVMETHOD(msi_alloc_msix,   gicv3_its_alloc_msix),
DEVMETHOD(msi_release_msix, gicv3_its_release_msix),
DEVMETHOD(msi_map_msi,  gicv3_its_map_msi),
+#ifdef IOMMU
+   DEVMETHOD(msi_iommu_init,   gicv3_iommu_init),
+   DEVMETHOD(msi_iommu_deinit, gicv3_iommu_deinit),
+#endif
 
/* End */
DEVMETHOD_END
@@ -803,8 +821,9 @@ static int
 gicv3_its_attach(device_t dev)
 {
struct gicv3_its_softc *sc;
-   uint32_t iidr;
int domain, err, i, rid;
+   uint64_t phys;
+   uint32_t iidr;
 
sc = device_get_softc(dev);
 
@@ -820,6 +839,11 @@ gicv3_its_attach(device_t dev)
return (ENXIO);
}
 
+   phys = rounddown2(vtophys(rman_get_virtual(sc->sc_its_res)) +
+   GITS_TRANSLATER, PAGE_SIZE);
+   sc->ma = malloc(sizeof(struct vm_page), M_DEVBUF, M_WAITOK | M_ZERO);
+   vm_page_initfake(sc->ma, phys, VM_MEMATTR_DEFAULT);
+
iidr = gic_its_read_4(sc, GITS_IIDR);
for (i = 0; i < nitems(its_quirks); i++) {
if ((iidr & its_quirks[i].iidr_mask) == its_quirks[i].iidr) {
@@ -1418,6 +1442,33 @@ gicv3_its_map_msi(device_t dev, device_t child, struct
 
return (0);
 }
+
+#ifdef IOMMU
+static int
+gicv3_iommu_init(device_t dev, device_t child, struct iommu_domain **domain)
+{
+   struct gicv3_its_softc *sc;
+   struct iommu_ctx *ctx;
+   int error;
+
+   sc = device_get_softc(dev);
+   ctx = iommu_get_dev_ctx(child);
+   error = iommu_map_msi(ctx, PAGE_SIZE, GITS_TRANSLATER,
+   IOMMU_MAP_ENTRY_WRITE, IOMMU_MF_CANWAIT, >ma);
+   *domain = iommu_get_ctx_domain(ctx);
+
+   return (error);
+}
+
+static void
+gicv3_iommu_deinit(device_t dev, device_t child)
+{
+   struct iommu_ctx *ctx;
+
+   ctx = iommu_get_dev_ctx(child);
+   iommu_unmap_msi(ctx);
+}
+#endif
 
 /*
  * Commands handling.
___
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: r367036 - stable/12/sys/dev/netmap

2020-10-25 Thread Vincenzo Maffione
Author: vmaffione
Date: Sun Oct 25 07:48:07 2020
New Revision: 367036
URL: https://svnweb.freebsd.org/changeset/base/367036

Log:
  MFC r366952
  
  netmap: fix mutex double unlock bug
  
  https://github.com/luigirizzo/netmap/pull/733
  
  Submitted by:brian90013

Modified:
  stable/12/sys/dev/netmap/netmap_mem2.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/dev/netmap/netmap_mem2.c
==
--- stable/12/sys/dev/netmap/netmap_mem2.c  Sun Oct 25 01:36:33 2020
(r367035)
+++ stable/12/sys/dev/netmap/netmap_mem2.c  Sun Oct 25 07:48:07 2020
(r367036)
@@ -2007,7 +2007,6 @@ netmap_mem2_if_new(struct netmap_adapter *na, struct n
len = sizeof(struct netmap_if) + (ntot * sizeof(ssize_t));
nifp = netmap_if_malloc(na->nm_mem, len);
if (nifp == NULL) {
-   NMA_UNLOCK(na->nm_mem);
return NULL;
}
 
___
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"