svn commit: r366629 - head/sys/sys
Author: imp Date: Mon Oct 12 05:56:29 2020 New Revision: 366629 URL: https://svnweb.freebsd.org/changeset/base/366629 Log: systm.h: forward declare ucred for _STANDALONE too There's a number of types we forward declare for the kernel. We need struct ucred for the ZSTD ZFS integration, so go ahead and forward declare it here too. Modified: head/sys/sys/systm.h Modified: head/sys/sys/systm.h == --- head/sys/sys/systm.hSun Oct 11 16:01:16 2020(r366628) +++ head/sys/sys/systm.hMon Oct 12 05:56:29 2020(r366629) @@ -124,6 +124,7 @@ voidvpanic(const char *, __va_list) __dead2 __printfl #if defined(_STANDALONE) +struct ucred; /* * Until we have more experience with KASSERTS that are called * from the boot loader, they are off. The bootloader does this ___ 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: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020 at 09:17:42PM -0600, Warner Losh wrote: > On Sun, Oct 11, 2020, 8:13 PM Alexey Dokuchaev wrote: > > ... > > I still don't understand how could rm be better than graceful disabling > > alternative configuration with nextboot_enable="NO". I most certainly > > do *not* like when my custom config files are being removed, especially > > silently. When I see nextboot_enable="NO" I know that the file > > had been processed, and processed by the machine, not me (since I would > > never add trailing space). When I don't see the file, I'd be questioning > > myself if I've ever added it here, or maybe I put in the wrong location. > > Nextboot.conf is special. It will be deleted. It doesn't belong to you, it > belongs to nextboot(8). OK, I see your point. > > Personally I find them quite useful, except when they contradict the > > reality (like this time). In these cases, I'd fix them. > > For now, it's fine. Fair enough; I guess we can now wrap this discussion up, thanks! ./danfe ___ 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: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020, 8:13 PM Alexey Dokuchaev wrote: > On Sun, Oct 11, 2020 at 09:12:43AM -0600, Warner Losh wrote: > > ... > > There were cases that were discussed when the feature went in that > > required it to be removed in some failure modes for full functionality. > > I don't recall if they were in the rc thread or somewhere else. > > You mean, literally delete the file, that is, nextboot_enable="NO" can > not be enough? > Yes. Sometimes it's not reliably written in some failure scenarios. In those cases it must be deleted. > And honestly, nextboot.conf is special in so many ways. We have no > > unlink in the loader for UFS and no write for ZFS or MSDOS. In those > > What's the problem with in-place overwrite in the FAT case? > Last I checked, it wasn't implemented. It could be done, but hasn't been. > cases, the rm from rc is what you want > > I still don't understand how could rm be better than graceful disabling > alternative configuration with nextboot_enable="NO". I most certainly > do *not* like when my custom config files are being removed, especially > silently. When I see nextboot_enable="NO" I know that the file > had been processed, and processed by the machine, not me (since I would > never add trailing space). When I don't see the file, I'd be questioning > myself if I've ever added it here, or maybe I put in the wrong location. > Nextboot.conf is special. It will be deleted. It doesn't belong to you, it belongs to nextboot(8). > I'm not likely to remove it, but if UFS grows unlink in the future, > > this man page will need to change. > > Just because it's easier to implemented unlink for UFS then (over)write > for ZFS? > Both are hard in ZFS. Unlink has issues that I hadn't recalled, so that path is unlikely... > Then again, all the loser [loader?] man pages need a complete rewrite, > > or close to it. > > Personally I find them quite useful, except when they contradict the > reality (like this time). In these cases, I'd fix them. > For now, it's fine. Warner > ___ 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: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020 at 09:12:43AM -0600, Warner Losh wrote: > ... > There were cases that were discussed when the feature went in that > required it to be removed in some failure modes for full functionality. > I don't recall if they were in the rc thread or somewhere else. You mean, literally delete the file, that is, nextboot_enable="NO" can not be enough? > And honestly, nextboot.conf is special in so many ways. We have no > unlink in the loader for UFS and no write for ZFS or MSDOS. In those What's the problem with in-place overwrite in the FAT case? > cases, the rm from rc is what you want I still don't understand how could rm be better than graceful disabling alternative configuration with nextboot_enable="NO". I most certainly do *not* like when my custom config files are being removed, especially silently. When I see nextboot_enable="NO" I know that the file had been processed, and processed by the machine, not me (since I would never add trailing space). When I don't see the file, I'd be questioning myself if I've ever added it here, or maybe I put in the wrong location. > I'm not likely to remove it, but if UFS grows unlink in the future, > this man page will need to change. Just because it's easier to implemented unlink for UFS then (over)write for ZFS? > Then again, all the loser [loader?] man pages need a complete rewrite, > or close to it. Personally I find them quite useful, except when they contradict the reality (like this time). In these cases, I'd fix them. ./danfe ___ 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: r366628 - in head/sys: amd64/conf arm64/conf conf dev/axgbe modules modules/axgbe modules/axgbe/if_axa modules/axgbe/if_axp
Author: manu Date: Sun Oct 11 16:01:16 2020 New Revision: 366628 URL: https://svnweb.freebsd.org/changeset/base/366628 Log: 10Gigabit Ethernet driver for AMD SoC This patch has the driver for 10Gigabit Ethernet controller in AMD SoC. This driver is written compatible to the Iflib framework. The existing driver is for the old version of hardware. The submitted driver here is for the recent versions of the hardware where the Ethernet controller is PCI-E based. Submitted by: Rajesh Kumar MFC after:1 month Relnotes: yes Differential Revision:https://reviews.freebsd.org/D25793 Added: head/sys/dev/axgbe/if_axgbe_pci.c (contents, props changed) head/sys/dev/axgbe/xgbe-dcb.c (contents, props changed) head/sys/dev/axgbe/xgbe-i2c.c (contents, props changed) head/sys/dev/axgbe/xgbe-phy-v1.c (contents, props changed) head/sys/dev/axgbe/xgbe-phy-v2.c (contents, props changed) head/sys/dev/axgbe/xgbe-ptp.c (contents, props changed) head/sys/dev/axgbe/xgbe-sysctl.c (contents, props changed) head/sys/dev/axgbe/xgbe-txrx.c (contents, props changed) head/sys/dev/axgbe/xgbe_osdep.c (contents, props changed) head/sys/modules/axgbe/ head/sys/modules/axgbe/Makefile (contents, props changed) head/sys/modules/axgbe/if_axa/ head/sys/modules/axgbe/if_axa/Makefile (contents, props changed) head/sys/modules/axgbe/if_axp/ head/sys/modules/axgbe/if_axp/Makefile (contents, props changed) Modified: head/sys/amd64/conf/GENERIC head/sys/amd64/conf/NOTES head/sys/arm64/conf/GENERIC head/sys/arm64/conf/NOTES head/sys/conf/files.amd64 head/sys/conf/files.arm64 head/sys/dev/axgbe/if_axgbe.c head/sys/dev/axgbe/xgbe-common.h head/sys/dev/axgbe/xgbe-desc.c head/sys/dev/axgbe/xgbe-dev.c head/sys/dev/axgbe/xgbe-drv.c head/sys/dev/axgbe/xgbe-mdio.c head/sys/dev/axgbe/xgbe.h head/sys/dev/axgbe/xgbe_osdep.h head/sys/modules/Makefile Modified: head/sys/amd64/conf/GENERIC == --- head/sys/amd64/conf/GENERIC Sun Oct 11 13:39:04 2020(r366627) +++ head/sys/amd64/conf/GENERIC Sun Oct 11 16:01:16 2020(r366628) @@ -248,6 +248,7 @@ device ixl # Intel 700 Series Physical Function device iavf# Intel Adaptive Virtual Function device ice # Intel 800 Series Physical Function device vmx # VMware VMXNET3 Ethernet +device axp # AMD EPYC integrated NIC # PCI Ethernet NICs. device bxe # Broadcom NetXtreme II BCM5771X/BCM578XX 10GbE Modified: head/sys/amd64/conf/NOTES == --- head/sys/amd64/conf/NOTES Sun Oct 11 13:39:04 2020(r366627) +++ head/sys/amd64/conf/NOTES Sun Oct 11 16:01:16 2020(r366628) @@ -328,6 +328,7 @@ device nfe # nVidia nForce MCP on-board Ethernet device sfxge # Solarflare SFC9000 10Gb Ethernet device vmx # VMware VMXNET3 Ethernet device wpi # Intel 3945ABG wireless NICs. +device axp # AMD EPYC integrated NIC # IEEE 802.11 adapter firmware modules Modified: head/sys/arm64/conf/GENERIC == --- head/sys/arm64/conf/GENERIC Sun Oct 11 13:39:04 2020(r366627) +++ head/sys/arm64/conf/GENERIC Sun Oct 11 16:01:16 2020(r366628) @@ -167,7 +167,7 @@ device mdio device mii device miibus # MII bus support device awg # Allwinner EMAC Gigabit Ethernet -device axgbe # AMD Opteron A1100 integrated NIC +device axa # AMD Opteron A1100 integrated NIC device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device neta# Marvell Armada 370/38x/XP/3700 NIC device smc # SMSC LAN91C111 Modified: head/sys/arm64/conf/NOTES == --- head/sys/arm64/conf/NOTES Sun Oct 11 13:39:04 2020(r366627) +++ head/sys/arm64/conf/NOTES Sun Oct 11 16:01:16 2020(r366628) @@ -76,7 +76,7 @@ options PCI_IOV # PCI SR-IOV support # Ethernet NICs device mdio device awg # Allwinner EMAC Gigabit Ethernet -device axgbe # AMD Opteron A1100 integrated NIC +device axa # AMD Opteron A1100 integrated NIC device neta# Marvell Armada 370/38x/XP/3700 NIC device smc # SMSC LAN91C111 device vnic# Cavium ThunderX NIC Modified: head/sys/conf/files.amd64 ==
Re: svn commit: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020, 8:00 AM Kyle Evans wrote: > On Sun, Oct 11, 2020 at 8:30 AM Alexey Dokuchaev > wrote: > > > > On Sun, Oct 11, 2020 at 04:08:09PM +0300, Toomas Soome wrote: > > > > On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote: > > > >> ... > > > >> Also nextboot.conf not generic configuration file (such as > loader.conf > > > >> or loader.conf.local), but the implementation specific file, part of > > > >> special feature. > > > >> > > > >> That is, one should not assume the presence of nextboot.conf file, > make > > > >> assumptions about its content, or perform manual edits on it. > > > > > > > > Do we want it to be the second-class citizen like this? Would it > make > > > > better sense by documenting it more completely instead? > > > > > > It is not really about being second-class citizen, it really is about > if > > > and how we can implement the feature. With UFS there is a limited write > > > (write to existing, allocated disk blocks), with ZFS there is no write > to > > > file system at all. > > > > I see; that would explain why loader(8) replaces the "YES" -> > "NO", > > but I guess I'd have to read the discussion on -rc@ which lead to > r177062, > > because I don't see the reason for it to be removed (twice) if it's being > > disabled by the loader(8) earlier anyway. > > > > IMO both steps are important. You have to (at least try to) disable it > in case it doesn't get you all the way to multi-user, but then you > don't want the old contents of nextboot.conf being inadvertently used > on another boot if someone's habitually `nextboot -a`ing. > There were cases that were discussed when the geature went in that required it to be removed in some failure modes for full functionality. I don't recall if they were in the rc thread or somewhere else. And honestly, nextboot.conf is special in so many ways. We have no unlink in the loader for UFS and no write for ZFS or MSDOS. In those cases, the rm from rc is what you want (though lately we use a different mechanism for ZFS). So the docs were right before, in the big picture. The implementation detail now enshrined there is unwise. I'm not likely to remove it, but if UFS grows unlink in the future, this man page will need to change. Then again, all the loser man pages need a complete rewrite, or close to it. Warner > ___ 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: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020 at 8:30 AM Alexey Dokuchaev wrote: > > On Sun, Oct 11, 2020 at 04:08:09PM +0300, Toomas Soome wrote: > > > On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote: > > >> ... > > >> Also nextboot.conf not generic configuration file (such as loader.conf > > >> or loader.conf.local), but the implementation specific file, part of > > >> special feature. > > >> > > >> That is, one should not assume the presence of nextboot.conf file, make > > >> assumptions about its content, or perform manual edits on it. > > > > > > Do we want it to be the second-class citizen like this? Would it make > > > better sense by documenting it more completely instead? > > > > It is not really about being second-class citizen, it really is about if > > and how we can implement the feature. With UFS there is a limited write > > (write to existing, allocated disk blocks), with ZFS there is no write to > > file system at all. > > I see; that would explain why loader(8) replaces the "YES" -> "NO", > but I guess I'd have to read the discussion on -rc@ which lead to r177062, > because I don't see the reason for it to be removed (twice) if it's being > disabled by the loader(8) earlier anyway. > IMO both steps are important. You have to (at least try to) disable it in case it doesn't get you all the way to multi-user, but then you don't want the old contents of nextboot.conf being inadvertently used on another boot if someone's habitually `nextboot -a`ing. ___ 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: r366627 - stable/12/usr.sbin/ctld
Author: rscheff
Date: Sun Oct 11 13:39:04 2020
New Revision: 366627
URL: https://svnweb.freebsd.org/changeset/base/366627
Log:
MFC r366206: Add DSCP support for network QoS to iscsi target.
In order to prioritize iSCSI traffic across a network,
DSCP can be used. In order not to rely on "ipfw setdscp"
or in-network reclassification, this adds the dscp value
directly to the portal group (where TCP sessions are accepted).
Reviewed by: mav, trasz
MFC after:2 weeks
Sponsored by: NetApp, Inc.
Differential Revision:https://reviews.freebsd.org/D26385
Modified:
stable/12/usr.sbin/ctld/ctl.conf.5
stable/12/usr.sbin/ctld/ctld.c
stable/12/usr.sbin/ctld/ctld.h
stable/12/usr.sbin/ctld/parse.y
stable/12/usr.sbin/ctld/token.l
stable/12/usr.sbin/ctld/uclparse.c
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/usr.sbin/ctld/ctl.conf.5
==
--- stable/12/usr.sbin/ctld/ctl.conf.5 Sun Oct 11 10:40:11 2020
(r366626)
+++ stable/12/usr.sbin/ctld/ctl.conf.5 Sun Oct 11 13:39:04 2020
(r366627)
@@ -250,6 +250,14 @@ Specifies that this
.Sy portal-group
is listened by some other host.
This host will announce it on discovery stage, but won't listen.
+.It Ic dscp Ar value
+The DiffServ Codepoint used for sending data. The DSCP can be
+set to numeric, or hexadecimal values directly, as well as the
+well-defined
+.Qq Ar CSx
+and
+.Qq Ar AFxx
+codepoints.
.El
.Ss target Context
.Bl -tag -width indent
Modified: stable/12/usr.sbin/ctld/ctld.c
==
--- stable/12/usr.sbin/ctld/ctld.c Sun Oct 11 10:40:11 2020
(r366626)
+++ stable/12/usr.sbin/ctld/ctld.c Sun Oct 11 13:39:04 2020
(r366627)
@@ -624,6 +624,7 @@ portal_group_new(struct conf *conf, const char *name)
TAILQ_INIT(>pg_ports);
pg->pg_conf = conf;
pg->pg_tag = 0; /* Assigned later in conf_apply(). */
+ pg->pg_dscp = -1;
TAILQ_INSERT_TAIL(>conf_portal_groups, pg, pg_next);
return (pg);
@@ -2179,6 +2180,32 @@ conf_apply(struct conf *oldconf, struct conf *newconf)
newp->p_socket = 0;
cumulated_error++;
continue;
+ }
+ if (newpg->pg_dscp != -1) {
+ struct sockaddr sa;
+ int len = sizeof(sa);
+ getsockname(newp->p_socket, , );
+ /*
+* Only allow the 6-bit DSCP
+* field to be modified
+*/
+ int tos = newpg->pg_dscp << 2;
+ if (sa.sa_family == AF_INET) {
+ if (setsockopt(newp->p_socket,
+ IPPROTO_IP, IP_TOS,
+ , sizeof(tos)) == -1)
+ log_warn("setsockopt(IP_TOS) "
+ "failed for %s",
+ newp->p_listen);
+ } else
+ if (sa.sa_family == AF_INET6) {
+ if (setsockopt(newp->p_socket,
+ IPPROTO_IPV6, IPV6_TCLASS,
+ , sizeof(tos)) == -1)
+
log_warn("setsockopt(IPV6_TCLASS) "
+ "failed for %s",
+ newp->p_listen);
+ }
}
error = bind(newp->p_socket, newp->p_ai->ai_addr,
newp->p_ai->ai_addrlen);
Modified: stable/12/usr.sbin/ctld/ctld.h
==
--- stable/12/usr.sbin/ctld/ctld.h Sun Oct 11 10:40:11 2020
(r366626)
+++ stable/12/usr.sbin/ctld/ctld.h Sun Oct 11 13:39:04 2020
(r366627)
@@ -127,6 +127,7 @@ struct portal_group {
TAILQ_HEAD(, port) pg_ports;
char*pg_offload;
char*pg_redirection;
+ int pg_dscp;
uint16_tpg_tag;
};
Modified: stable/12/usr.sbin/ctld/parse.y
==
--- stable/12/usr.sbin/ctld/parse.y Sun Oct 11 10:40:11 2020
(r366626)
+++ stable/12/usr.sbin/ctld/parse.y Sun Oct 11 13:39:04 2020
(r366627)
@@ -41,6 +41,8 @@
#include
Re: svn commit: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020 at 04:08:09PM +0300, Toomas Soome wrote: > > On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote: > >> ... > >> Also nextboot.conf not generic configuration file (such as loader.conf > >> or loader.conf.local), but the implementation specific file, part of > >> special feature. > >> > >> That is, one should not assume the presence of nextboot.conf file, make > >> assumptions about its content, or perform manual edits on it. > > > > Do we want it to be the second-class citizen like this? Would it make > > better sense by documenting it more completely instead? > > It is not really about being second-class citizen, it really is about if > and how we can implement the feature. With UFS there is a limited write > (write to existing, allocated disk blocks), with ZFS there is no write to > file system at all. I see; that would explain why loader(8) replaces the "YES" -> "NO", but I guess I'd have to read the discussion on -rc@ which lead to r177062, because I don't see the reason for it to be removed (twice) if it's being disabled by the loader(8) earlier anyway. ./danfe ___ 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: r366626 - head/sbin/reboot
> On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote: > > On Sun, Oct 11, 2020 at 03:20:16PM +0300, Toomas Soome wrote: >> Please note, the remove is done by rc script during the boot. > > But not by the loader(8) as the page used to claim. It confused me how to > avoid the remove, and only later I've discovered with some relief that it > is in fact not being removed, but only disabled (which IMHO is a lot more > graceful and thus correct behavior). > >> Also nextboot.conf not generic configuration file (such as loader.conf >> or loader.conf.local), but the implementation specific file, part of >> special feature. >> >> That is, one should not assume the presence of nextboot.conf file, make >> assumptions about its content, or perform manual edits on it. > > Do we want it to be the second-class citizen like this? Would it make > better sense by documenting it more completely instead? > > ./danfe It is not really about being second-class citizen, it really is about if and how we can implement the feature. With UFS there is a limited write (write to existing, allocated disk blocks), with zfs there is no write to file system at all. rgds, toomas ___ 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: r366626 - head/sbin/reboot
On Sun, Oct 11, 2020 at 03:20:16PM +0300, Toomas Soome wrote: > Please note, the remove is done by rc script during the boot. But not by the loader(8) as the page used to claim. It confused me how to avoid the remove, and only later I've discovered with some relief that it is in fact not being removed, but only disabled (which IMHO is a lot more graceful and thus correct behavior). > Also nextboot.conf not generic configuration file (such as loader.conf > or loader.conf.local), but the implementation specific file, part of > special feature. > > That is, one should not assume the presence of nextboot.conf file, make > assumptions about its content, or perform manual edits on it. Do we want it to be the second-class citizen like this? Would it make better sense by documenting it more completely instead? ./danfe ___ 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: r366626 - head/sbin/reboot
Please note, the remove is done by rc script during the boot. Also nextboot.conf not generic configuration file (such as loader.conf or loader.conf.local), but the implementation specific file, part of special feature. That is, one should not assume the presence of nextboot.conf file, make assumptions about its content, or perform manual edits on it. Rgds, Toomas > On 11. Oct 2020, at 13:40, Alexey Dokuchaev wrote: > > Author: danfe (ports committer) > Date: Sun Oct 11 10:40:11 2020 > New Revision: 366626 > URL: https://svnweb.freebsd.org/changeset/base/366626 > > Log: > The nextboot(8) manual page currently says that the loader(8) would delete > the /boot/nextboot.conf file or its contents which is 1) not the most user- > friendly way of working with custom configurations, and 2) simply not true > for both Forth and Lua implementations: they would not delete it, but just > change the setting to "NO", that is, disable it. > > While at it, add one missing serial (Oxford) comma and fix some bogus line > wraps along the way. > > Approved by:bcr (manpages) > Differential Revision:https://reviews.freebsd.org/D25971 > > Modified: > head/sbin/reboot/nextboot.8 > > Modified: head/sbin/reboot/nextboot.8 > == > --- head/sbin/reboot/nextboot.8Sun Oct 11 09:05:13 2020(r366625) > +++ head/sbin/reboot/nextboot.8Sun Oct 11 10:40:11 2020(r366626) > @@ -24,7 +24,7 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd September 19, 2020 > +.Dd October 11, 2020 > .Dt NEXTBOOT 8 > .Os > .Sh NAME > @@ -41,14 +41,14 @@ > .Sh DESCRIPTION > The > .Nm > -utility allows specifying some combination of an alternate kernel, boot flags > -and kernel environment for the > -next time the machine is booted. > +utility allows specifying some combination of an alternate kernel, boot > +flags, and kernel environment for the next time the machine is booted. > Once the > .Xr loader 8 > -loads in the new kernel > -information, it is deleted so in case the new kernel hangs the machine, > -once it is rebooted, the machine will automatically revert to its previous > +loads in the new kernel information from the > +.Pa /boot/nextboot.conf > +file, it is disabled so in case the new kernel hangs the machine, once > +it is rebooted, the machine will automatically revert to its previous > configuration. > .Pp > The options are as follows: ___ 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: r366626 - head/sbin/reboot
Author: danfe (ports committer) Date: Sun Oct 11 10:40:11 2020 New Revision: 366626 URL: https://svnweb.freebsd.org/changeset/base/366626 Log: The nextboot(8) manual page currently says that the loader(8) would delete the /boot/nextboot.conf file or its contents which is 1) not the most user- friendly way of working with custom configurations, and 2) simply not true for both Forth and Lua implementations: they would not delete it, but just change the setting to "NO", that is, disable it. While at it, add one missing serial (Oxford) comma and fix some bogus line wraps along the way. Approved by: bcr (manpages) Differential Revision:https://reviews.freebsd.org/D25971 Modified: head/sbin/reboot/nextboot.8 Modified: head/sbin/reboot/nextboot.8 == --- head/sbin/reboot/nextboot.8 Sun Oct 11 09:05:13 2020(r366625) +++ head/sbin/reboot/nextboot.8 Sun Oct 11 10:40:11 2020(r366626) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd September 19, 2020 +.Dd October 11, 2020 .Dt NEXTBOOT 8 .Os .Sh NAME @@ -41,14 +41,14 @@ .Sh DESCRIPTION The .Nm -utility allows specifying some combination of an alternate kernel, boot flags -and kernel environment for the -next time the machine is booted. +utility allows specifying some combination of an alternate kernel, boot +flags, and kernel environment for the next time the machine is booted. Once the .Xr loader 8 -loads in the new kernel -information, it is deleted so in case the new kernel hangs the machine, -once it is rebooted, the machine will automatically revert to its previous +loads in the new kernel information from the +.Pa /boot/nextboot.conf +file, it is disabled so in case the new kernel hangs the machine, once +it is rebooted, the machine will automatically revert to its previous configuration. .Pp The options are as follows: ___ 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: r366620 - in head/sys: conf dev/random/fenestrasX
> On 10 Oct 2020, at 22:45, Conrad Meyer wrote: > > Author: cem > Date: Sat Oct 10 21:45:59 2020 > New Revision: 366620 > URL: https://svnweb.freebsd.org/changeset/base/366620 > > Log: > Add "Fenestras X" alternative /dev/random implementation This is a much needed improvement to the (CS)PRNG, as we are now supporting SMTP architectures with many cores, where this should shine! I have not had the time to do the work myself, so I'm delighted that *someone* got to it! Thanks, Conrad! M -- signature.asc Description: Message signed with OpenPGP
svn commit: r366625 - stable/11/contrib/tzdata
Author: philip Date: Sun Oct 11 09:05:13 2020 New Revision: 366625 URL: https://svnweb.freebsd.org/changeset/base/366625 Log: MFC r366529: Import tzdata 2020b Modified: stable/11/contrib/tzdata/Makefile stable/11/contrib/tzdata/NEWS stable/11/contrib/tzdata/README stable/11/contrib/tzdata/africa stable/11/contrib/tzdata/antarctica stable/11/contrib/tzdata/asia stable/11/contrib/tzdata/australasia stable/11/contrib/tzdata/backzone stable/11/contrib/tzdata/europe stable/11/contrib/tzdata/leap-seconds.list stable/11/contrib/tzdata/leapseconds stable/11/contrib/tzdata/leapseconds.awk stable/11/contrib/tzdata/northamerica stable/11/contrib/tzdata/southamerica stable/11/contrib/tzdata/theory.html stable/11/contrib/tzdata/version stable/11/contrib/tzdata/zishrink.awk stable/11/contrib/tzdata/zoneinfo2tdf.pl Directory Properties: stable/11/ (props changed) Modified: stable/11/contrib/tzdata/Makefile == --- stable/11/contrib/tzdata/Makefile Sun Oct 11 09:04:56 2020 (r366624) +++ stable/11/contrib/tzdata/Makefile Sun Oct 11 09:05:13 2020 (r366625) @@ -22,13 +22,13 @@ BUGEMAIL= t...@iana.org # DATAFORM= main # To wait even longer for new features, use: # DATAFORM= rearguard +# Rearguard users might also want "ZFLAGS = -b fat"; see below. DATAFORM= main # Change the line below for your timezone (after finding the one you want in # one of the $(TDATA) source files, or adding it to a source file). # Alternatively, if you discover you've got the wrong timezone, you can just -# zic -l rightzone -# to correct things. +# 'zic -l -' to remove it, or 'zic -l rightzone' to change it. # Use the command # make zonenames # to get a list of the values you can use for LOCALTIME. @@ -37,33 +37,30 @@ LOCALTIME= GMT # The POSIXRULES macro controls interpretation of nonstandard and obsolete # POSIX-like TZ settings like TZ='EET-2EEST' that lack DST transition rules. -# In the reference implementation, if you want something other than Eastern -# United States time as a template for handling these settings, you can -# change the line below (after finding the timezone you want in the -# one of the $(TDATA) source files, or adding it to a source file). -# A setting like TZ='EET-2EEST' is supposed to use the rules in the -# template file to determine "spring forward" and "fall back" days and -# times; the environment variable itself specifies UT offsets of standard and -# daylight saving time. -# Alternatively, if you discover you've got the wrong timezone, you can just -# zic -p rightzone -# to correct things. -# Use the command -# make zonenames -# to get a list of the values you can use for POSIXRULES. +# Such a setting uses the rules in a template file to determine +# "spring forward" and "fall back" days and times; the environment +# variable itself specifies UT offsets of standard and daylight saving time. # -# If POSIXRULES is empty, no template is installed; this is the intended -# future default for POSIXRULES. +# If POSIXRULES is '-', no template is installed; this is the default. # -# Nonempty POSIXRULES is obsolete and should not be relied on, because: +# Any other value for POSIXRULES is obsolete and should not be relied on, as: # * It does not work correctly in popular implementations such as GNU/Linux. # * It does not work in the tzdb implementation for timestamps after 2037. # * It is incompatible with 'zic -b slim' if POSIXRULES specifies transitions # at standard time or UT rather than at local time. # In short, software should avoid ruleless settings like TZ='EET-2EEST' # and so should not depend on the value of POSIXRULES. +# +# If, despite the above, you want a template for handling these settings, +# you can change the line below (after finding the timezone you want in the +# one of the $(TDATA) source files, or adding it to a source file). +# Alternatively, if you discover you've got the wrong timezone, you can just +# 'zic -p -' to remove it, or 'zic -p rightzone' to change it. +# Use the command +# make zonenames +# to get a list of the values you can use for POSIXRULES. -POSIXRULES=America/New_York +POSIXRULES=- # Also see TZDEFRULESTRING below, which takes effect only # if the time zone files cannot be accessed. @@ -172,9 +169,6 @@ TZDATA_TEXT=leapseconds tzdata.zi # For backward-compatibility links for old zone names, use # BACKWARD= backward -# If you also want the link US/Pacific-New, even though it is confusing -# and is planned to be removed from the database eventually, use -# BACKWARD= backward pacificnew # To omit these links, use # BACKWARD= @@ -192,10 +186,6 @@ PACKRATDATA= UTF8_LOCALE= en_US.utf8 -# Since "." may not be in PATH... - -YEARISTYPE=./yearistype - # Non-default libraries needed to link. LDLIBS=
svn commit: r366624 - stable/12/contrib/tzdata
Author: philip Date: Sun Oct 11 09:04:56 2020 New Revision: 366624 URL: https://svnweb.freebsd.org/changeset/base/366624 Log: MFC r366529: Import tzdata 2020b Modified: stable/12/contrib/tzdata/Makefile stable/12/contrib/tzdata/NEWS stable/12/contrib/tzdata/README stable/12/contrib/tzdata/africa stable/12/contrib/tzdata/antarctica stable/12/contrib/tzdata/asia stable/12/contrib/tzdata/australasia stable/12/contrib/tzdata/backzone stable/12/contrib/tzdata/europe stable/12/contrib/tzdata/leap-seconds.list stable/12/contrib/tzdata/leapseconds stable/12/contrib/tzdata/leapseconds.awk stable/12/contrib/tzdata/northamerica stable/12/contrib/tzdata/southamerica stable/12/contrib/tzdata/theory.html stable/12/contrib/tzdata/version stable/12/contrib/tzdata/zishrink.awk stable/12/contrib/tzdata/zoneinfo2tdf.pl Directory Properties: stable/12/ (props changed) Modified: stable/12/contrib/tzdata/Makefile == --- stable/12/contrib/tzdata/Makefile Sun Oct 11 00:01:00 2020 (r366623) +++ stable/12/contrib/tzdata/Makefile Sun Oct 11 09:04:56 2020 (r366624) @@ -22,13 +22,13 @@ BUGEMAIL= t...@iana.org # DATAFORM= main # To wait even longer for new features, use: # DATAFORM= rearguard +# Rearguard users might also want "ZFLAGS = -b fat"; see below. DATAFORM= main # Change the line below for your timezone (after finding the one you want in # one of the $(TDATA) source files, or adding it to a source file). # Alternatively, if you discover you've got the wrong timezone, you can just -# zic -l rightzone -# to correct things. +# 'zic -l -' to remove it, or 'zic -l rightzone' to change it. # Use the command # make zonenames # to get a list of the values you can use for LOCALTIME. @@ -37,33 +37,30 @@ LOCALTIME= GMT # The POSIXRULES macro controls interpretation of nonstandard and obsolete # POSIX-like TZ settings like TZ='EET-2EEST' that lack DST transition rules. -# In the reference implementation, if you want something other than Eastern -# United States time as a template for handling these settings, you can -# change the line below (after finding the timezone you want in the -# one of the $(TDATA) source files, or adding it to a source file). -# A setting like TZ='EET-2EEST' is supposed to use the rules in the -# template file to determine "spring forward" and "fall back" days and -# times; the environment variable itself specifies UT offsets of standard and -# daylight saving time. -# Alternatively, if you discover you've got the wrong timezone, you can just -# zic -p rightzone -# to correct things. -# Use the command -# make zonenames -# to get a list of the values you can use for POSIXRULES. +# Such a setting uses the rules in a template file to determine +# "spring forward" and "fall back" days and times; the environment +# variable itself specifies UT offsets of standard and daylight saving time. # -# If POSIXRULES is empty, no template is installed; this is the intended -# future default for POSIXRULES. +# If POSIXRULES is '-', no template is installed; this is the default. # -# Nonempty POSIXRULES is obsolete and should not be relied on, because: +# Any other value for POSIXRULES is obsolete and should not be relied on, as: # * It does not work correctly in popular implementations such as GNU/Linux. # * It does not work in the tzdb implementation for timestamps after 2037. # * It is incompatible with 'zic -b slim' if POSIXRULES specifies transitions # at standard time or UT rather than at local time. # In short, software should avoid ruleless settings like TZ='EET-2EEST' # and so should not depend on the value of POSIXRULES. +# +# If, despite the above, you want a template for handling these settings, +# you can change the line below (after finding the timezone you want in the +# one of the $(TDATA) source files, or adding it to a source file). +# Alternatively, if you discover you've got the wrong timezone, you can just +# 'zic -p -' to remove it, or 'zic -p rightzone' to change it. +# Use the command +# make zonenames +# to get a list of the values you can use for POSIXRULES. -POSIXRULES=America/New_York +POSIXRULES=- # Also see TZDEFRULESTRING below, which takes effect only # if the time zone files cannot be accessed. @@ -172,9 +169,6 @@ TZDATA_TEXT=leapseconds tzdata.zi # For backward-compatibility links for old zone names, use # BACKWARD= backward -# If you also want the link US/Pacific-New, even though it is confusing -# and is planned to be removed from the database eventually, use -# BACKWARD= backward pacificnew # To omit these links, use # BACKWARD= @@ -192,10 +186,6 @@ PACKRATDATA= UTF8_LOCALE= en_US.utf8 -# Since "." may not be in PATH... - -YEARISTYPE=./yearistype - # Non-default libraries needed to link. LDLIBS=
