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: 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-head@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"
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-head@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"
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-head@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"
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-head@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"
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-head@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"
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-head@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"
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-head@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 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 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-head@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"
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-head@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"
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-head@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 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-head@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"
