svn commit: r256367 - head/share/syscons/keymaps
Author: eadler Date: Sat Oct 12 07:00:51 2013 New Revision: 256367 URL: http://svnweb.freebsd.org/changeset/base/256367 Log: Fix the formatting for the danish keymap. Reported by: dteske Approved by: re (glebius) Modified: head/share/syscons/keymaps/INDEX.keymaps Modified: head/share/syscons/keymaps/INDEX.keymaps == --- head/share/syscons/keymaps/INDEX.keymapsSat Oct 12 06:08:18 2013 (r256366) +++ head/share/syscons/keymaps/INDEX.keymapsSat Oct 12 07:00:51 2013 (r256367) @@ -117,7 +117,7 @@ danish.cp865.kbd:fr:Danois Code page 865 danish.cp865.kbd:pt:Dinamarqu�s Codepage 865 danish.cp865.kbd:es:Dan�s Codepage 865 -danish.iso.macbook.kbd:Danish ISO-8859-1 (macbook) +danish.iso.macbook.kbd:da:Danish ISO-8859-1 (macbook) dutch.iso.acc.kbd:en:Dutch ISO keymap (accent keys) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256343 - in head/usr.sbin/bsdinstall: . scripts
On 10/11/13 22:41, Devin Teske wrote: > Author: dteske > Date: Fri Oct 11 20:41:35 2013 > New Revision: 256343 > URL: http://svnweb.freebsd.org/changeset/base/256343 > > Log: > Add zfsboot module as an option for automatic configuration. Default is > to run interactively but it can be scripted too (optinally completely > non-interactive). Currently supports GELI and all ZFS vdev types. Also > performs validation on selections/settings providing error messages if > necessary, explaining (in plain language) what the issue is. Currently > the auto partitioning of naked disks only supports GPT and MBR (VTOC8 > pending for sparc64), so is only available for i386/amd64 install. > > Submitted by: Allan Jude , myself > Reviewed by:Allan Jude > Approved by:re (glebius) Hi Devin -- As was discussed on the mailing list, this patch still has some issues that need to be resolved, for example the use of camcontrol unconditionally even when the disks may not be CAM and destruction of existing sub-partitioning for MBR disks. There were some others brought up in the discussion as well. I am surprised you committed it, especially to stable/10, before those issues were resolved. I'm also not sure if people can review their own patches. Installer regressions are very easy to introduce and very problematic when created. Real review for installer changes is thus especially important this late in the release cycle. Do you have any plans to fix these issues in the very near future? -Nathan ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256365 - in head: . etc etc/atf etc/mtree lib/libcrypt/tests share share/atf share/examples share/examples/atf share/man/man5 share/man/man7 share/mk share/xml share/xsl tools/build/m
On Oct 11, 2013 11:07 PM, "Rui Paulo" wrote:
>
> Author: rpaulo
> Date: Sat Oct 12 06:06:53 2013
> New Revision: 256365
> URL: http://svnweb.freebsd.org/changeset/base/256365
>
> Log:
> Remove most of the ATF tools and the _atf user.
>
> This is necessary because ATF is deprecated and it will be replaced by
Kyua.
When are we planning to bring in Kyua?
I may be missing something but why remove ATF before that?
Cheers,
Hiren
>
> Submitted by: j...@netbsd.org
> Reviewed by: Garrett Cooper
> Approved by: re
>
> Deleted:
> head/etc/atf/
> head/share/atf/
> head/share/examples/atf/
> head/share/xml/
> head/share/xsl/
> head/usr.bin/atf/atf-config/
> head/usr.bin/atf/atf-report/
> head/usr.bin/atf/atf-run/
> head/usr.bin/atf/atf-version/
> Modified:
> head/ObsoleteFiles.inc
> head/etc/Makefile
> head/etc/ftpusers
> head/etc/group
> head/etc/master.passwd
> head/etc/mtree/BSD.root.dist
> head/etc/mtree/BSD.usr.dist
> head/lib/libcrypt/tests/crypt_tests.c
> head/share/Makefile
> head/share/examples/Makefile
> head/share/man/man5/Makefile
> head/share/man/man7/Makefile
> head/share/mk/atf.test.mk
> head/tools/build/mk/OptionalObsoleteFiles.inc
> head/usr.bin/atf/Makefile
> head/usr.bin/atf/Makefile.inc
>
> Modified: head/ObsoleteFiles.inc
>
==
> --- head/ObsoleteFiles.inc Sat Oct 12 04:35:38 2013(r256364)
> +++ head/ObsoleteFiles.inc Sat Oct 12 06:06:53 2013(r256365)
> @@ -38,6 +38,25 @@
> # xargs -n1 | sort | uniq -d;
> # done
>
> +# 20131013: Removal of the ATF tools
> +OLD_FILES+=etc/atf/FreeBSD.conf
> +OLD_FILES+=etc/atf/atf-run.hooks
> +OLD_FILES+=etc/atf/common.conf
> +OLD_FILES+=usr/bin/atf-config
> +OLD_FILES+=usr/bin/atf-report
> +OLD_FILES+=usr/bin/atf-run
> +OLD_FILES+=usr/bin/atf-version
> +OLD_FILES+=usr/share/atf/atf-run.hooks
> +OLD_FILES+=usr/share/examples/atf/atf-run.hooks
> +OLD_FILES+=usr/share/examples/atf/tests-results.css
> +OLD_FILES+=usr/share/man/man1/atf-config.1.gz
> +OLD_FILES+=usr/share/man/man1/atf-report.1.gz
> +OLD_FILES+=usr/share/man/man1/atf-run.1.gz
> +OLD_FILES+=usr/share/man/man1/atf-version.1.gz
> +OLD_FILES+=usr/share/man/man5/atf-formats.5.gz
> +OLD_FILES+=usr/share/man/man7/atf.7.gz
> +OLD_FILES+=usr/share/xml/atf/tests-results.dtd
> +OLD_FILES+=usr/share/xsl/atf/tests-results.xsl
> # 20131009: freebsd-version moved from /libexec to /bin
> OLD_FILES+=libexec/freebsd-version
> # 20131001: ar and ranlib from binutils not used
> @@ -6093,6 +6112,13 @@ OLD_LIBS+=usr/lib/libkse.so.1
> OLD_LIBS+=usr/lib/liblwres.so.3
> OLD_LIBS+=usr/lib/pam_ftp.so.2
>
> +# 20131013: Removal of the ATF tools
> +OLD_DIRS+=etc/atf
> +OLD_DIRS+=usr/share/examples/atf
> +OLD_DIRS+=usr/share/xml/atf
> +OLD_DIRS+=usr/share/xml
> +OLD_DIRS+=usr/share/xsl/atf
> +OLD_DIRS+=usr/share/xsl
> # 20040925: bind9 import
> OLD_DIRS+=usr/share/doc/bind/html
> OLD_DIRS+=usr/share/doc/bind/misc
>
> Modified: head/etc/Makefile
>
==
> --- head/etc/Makefile Sat Oct 12 04:35:38 2013(r256364)
> +++ head/etc/Makefile Sat Oct 12 06:06:53 2013(r256365)
> @@ -215,9 +215,6 @@ distribution:
> echo "./etc/spwd.db type=file mode=0600 uname=root
gname=wheel"; \
> ) | ${METALOG.add}
> .endif
> -.if ${MK_ATF} != "no"
> - ${_+_}cd ${.CURDIR}/atf; ${MAKE} install
> -.endif
> .if ${MK_BLUETOOTH} != "no"
> ${_+_}cd ${.CURDIR}/bluetooth; ${MAKE} install
> .endif
>
> Modified: head/etc/ftpusers
>
==
> --- head/etc/ftpusers Sat Oct 12 04:35:38 2013(r256364)
> +++ head/etc/ftpusers Sat Oct 12 06:06:53 2013(r256365)
> @@ -15,7 +15,6 @@ man
> sshd
> smmsp
> mailnull
> -_atf
> bind
> unbound
> proxy
>
> Modified: head/etc/group
>
==
> --- head/etc/group Sat Oct 12 04:35:38 2013(r256364)
> +++ head/etc/group Sat Oct 12 06:06:53 2013(r256365)
> @@ -16,7 +16,6 @@ staff:*:20:
> sshd:*:22:
> smmsp:*:25:
> mailnull:*:26:
> -_atf:*:27:
> guest:*:31:
> bind:*:53:
> unbound:*:59:
>
> Modified: head/etc/master.passwd
>
==
> --- head/etc/master.passwd Sat Oct 12 04:35:38 2013(r256364)
> +++ head/etc/master.passwd Sat Oct 12 06:06:53 2013(r256365)
> @@ -13,7 +13,6 @@ man:*:9:9::0:0:Mister Man Pages:/usr/sha
> sshd:*:22:22::0:0:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
> smmsp:*:25:25::0:0:Sendmail Submission
User:/var/spool/clientmqueue:/usr/sbin/nologin
> mailnull:*:26:26::0:0:Sendmail Default
User:/var/spool/mqueue:/usr/sbin/nologin
> -_atf:*:27:27::0:0:& pseudo-user:/nonexistent:/usr/sbin/nologin
> bind:*:53:53::0:0:Bind San
Re: svn commit: r256365 - in head: . etc etc/atf etc/mtree lib/libcrypt/tests share share/atf share/examples share/examples/atf share/man/man5 share/man/man7 share/mk share/xml share/xsl tools/build/m
On Sat, Oct 12, 2013 at 01:01:55AM -0700, hiren panchasara wrote: > On Oct 11, 2013 11:07 PM, "Rui Paulo" wrote: > > > > Author: rpaulo > > Date: Sat Oct 12 06:06:53 2013 > > New Revision: 256365 > > URL: http://svnweb.freebsd.org/changeset/base/256365 > > > > Log: > > Remove most of the ATF tools and the _atf user. > > > > This is necessary because ATF is deprecated and it will be replaced by > > Kyua. > > When are we planning to bring in Kyua? IMHO, it should exist in ports. > I may be missing something but why remove ATF before that? > It is deprecated upstream. Glen pgpMPO01Hklhf.pgp Description: PGP signature
Re: svn commit: r256343 - in head/usr.sbin/bsdinstall: . scripts
On Oct 12, 2013, at 12:26 AM, Nathan Whitehorn wrote: > On 10/11/13 22:41, Devin Teske wrote: >> Author: dteske >> Date: Fri Oct 11 20:41:35 2013 >> New Revision: 256343 >> URL: >> https://urldefense.proofpoint.com/v1/url?u=http://svnweb.freebsd.org/changeset/base/256343&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=LDzuPpXPP4D5BzfISZjw%2BXitYn4aKVzfXzcrmMNFo2U%3D%0A&s=3d0963d9c497f7bad091032ca62844580612dc48ab3a8a6768fe640c365b >> >> Log: >> Add zfsboot module as an option for automatic configuration. Default is >> to run interactively but it can be scripted too (optinally completely >> non-interactive). Currently supports GELI and all ZFS vdev types. Also >> performs validation on selections/settings providing error messages if >> necessary, explaining (in plain language) what the issue is. Currently >> the auto partitioning of naked disks only supports GPT and MBR (VTOC8 >> pending for sparc64), so is only available for i386/amd64 install. >> >> Submitted by: Allan Jude , myself >> Reviewed by:Allan Jude >> Approved by:re (glebius) > > Hi Devin -- > > As was discussed on the mailing list, this patch still has some issues > that need to be resolved, for example the use of camcontrol > unconditionally even when the disks may not be CAM and destruction of > existing sub-partitioning for MBR disks. The code to replace the use of camcontrol is a a *very* complex parsing of the geom XML configuration data stashed in sysctl. jmg@ started the ball rolling on that. > There were some others brought > up in the discussion as well. I am surprised you committed it, Calm down. The camcontrol functionality is a value-add and *not* the sole provision for getting descriptions of the disk. jmg@ dumped a beautiful (but needs cleaning up for integration and optimization -- not bad for the fact that he wrote in ... a day!) piece of code on me that can parse the XML geom data from sysctl. Unfortunately, it needs some heavy integration. So while you bring up this short-coming... _others_ have already kindly chimed in to help. The likelihood that it will be fixed before 10.0-R is extremely high. You can calm down. > especially to stable/10, before those issues were resolved. Uh... I don't know how to respond to that. I'm going to ignore that (completely). > I'm also not > sure if people can review their own patches. > He didn't... it should have been "In collaboration with". Allan submitted something. I completely rewrote it, and he reviewed what *I* wrote. > Installer regressions are very easy to introduce and very problematic Don't I know (looks at *you*) > when created. Real review for installer changes is thus especially > important this late in the release cycle. Using camcontrol is not the end of the world -- even if the code is read-only to you... you should be able to ... "read it?" > Do you have any plans to fix > these issues in the very near future? Yes. Which has been discussed at-length, you didn't need to put a sandbag on my back (publicly no less; thanks for that). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256343 - in head/usr.sbin/bsdinstall: . scripts
"Teske, Devin" writes: > The code to replace the use of camcontrol is a a *very* complex parsing > of the geom XML configuration data stashed in sysctl. jmg@ started the > ball rolling on that. You realize there is a text version as well? > Yes. Which has been discussed at-length, you didn't need to put a > sandbag on my back (publicly no less; thanks for that). Umm, I think Nathan was pretty civil. You're the one who's turning this into a catfight. DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256343 - in head/usr.sbin/bsdinstall: . scripts
[snip] > >> Installer regressions are very easy to introduce and very problematic > > Don't I know (looks at *you*) > > > >> when created. Real review for installer changes is thus especially >> important this late in the release cycle. > > Using camcontrol is not the end of the world -- even if the code is read-only > to you... > you should be able to ... "read it?" > > >> Do you have any plans to fix >> these issues in the very near future? > > Yes. Which has been discussed at-length, you didn't need to put a sandbag on > my back > (publicly no less; thanks for that). I apologize... I should have gone on to explain that... The use of camcontrol is protected by a conditional block making use of the f_have() function which means if you rip out camcontrol completely (in any way resulting in the binary being absent) then the value-add potentially provided by camcontrol is silently skipped as the utility is not available. So let's say you don't have camcontrol(8) in the media, *or* say that you have a kernel lacking CAM knobs... No problem. I could have completely omitted the camcontrol value-add, ... what we had already was sufficient enough to describe disks. It was only upon Allan's testing that he noticed that the labels could be... better ;D So I went scrounging for something that could supersede the description of a `da0' that would satisfy Allan, and I found it in camcontrol -- his testing confirmed. I don't know if he was using a kernel enhanced with CAM through custom configuration or if he was using everything stock... and I could ask him... but it appeared to be working *and* I protected it with f_have() so in the event that it doesn't work for everyone... no biggie... the descriptions will be as they were before the value-add (still there, but not as accurate as they could be... enter jmg@ and a parsing of geom later). I think of all people, you should understand that if something doesn't introduce a blocker, but lacks a particular value-add (in this case, geom parsing), then it should be OK to proceed (I'm not harping on you, but I'm specifically calling out that bsdinstall did not implement everything needed by VICOR "out of the box"; so we're still on 8.x because we rely on much functionality in sysinstall that bsdinstall doesn't implement). So I'm a bit shocked to see you coming down so hard on this commit. It will be addressed, but I also had to first address jilles@ Integer Overflow statement (I _on purpose_ committed the code we had because it had to go in, and then *very* quickly followed it up with a fix to the integer overflow detection). You're next in-line, but the geom parsing may not make it in until BETA2 (I honestly need a break from that last round of commits... it took me a solid week of sleepless nights -- the wife and I would like some time together, please). In light of that last paragraph... we're all Human... and what we do is volunteer. So I can't harp on you legitimately for any short-comings. But I do request a little slack considering I didn't break anything and this is *not* that serious in the grand scheme of things. There are no regressions that I can see which you speak of. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256343 - in head/usr.sbin/bsdinstall: . scripts
On Oct 12, 2013, at 8:03 AM, Dag-Erling Smørgrav wrote: > "Teske, Devin" writes: >> The code to replace the use of camcontrol is a a *very* complex parsing >> of the geom XML configuration data stashed in sysctl. jmg@ started the >> ball rolling on that. > > You realize there is a text version as well? > >> Yes. Which has been discussed at-length, you didn't need to put a >> sandbag on my back (publicly no less; thanks for that). > > Umm, I think Nathan was pretty civil. You're the one who's turning this > into a catfight. > Reflecting upon the thread to see if you're _right_... 1. He stated there were still some issues. [definitely civil] 2. "I am surprised you committed it especially to stable/10, before those issues were resolved." [civil? or inflammatory?] 3. "I'm also not sure if people can review their own patches." [misunderstanding] 4. "Installer regressions are very easy to introduce and very problematic when created." [statements like that invariably lead people to believe he views the commit as a regression -- I explained in a follow-up that it is not a regression] 5. "Real review for installer changes is thus especially important this late in the release cycle." [I read this invariably as he views that the commit did not go through "Real review", but again... there is no regression and it's purely value- add] 6. "Do you have any plans to fix these issues in the very near future?" [definitely civil] What got me ralled up was #'s 2, 4, and 5. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256343 - in head/usr.sbin/bsdinstall: . scripts
On Oct 12, 2013, at 8:10 AM, Teske, Devin wrote: > [snip] > > So let's say you don't have camcontrol(8) in the media, *or* say that you > have a kernel > lacking CAM knobs... > > No problem. > > I could have completely omitted the camcontrol value-add, ... what we had > already > was sufficient enough to describe disks. > > It was only upon Allan's testing that he noticed that the labels could be... > better ;D > > So I went scrounging for something that could supersede the description of a > `da0' > that would satisfy Allan, and I found it in camcontrol -- his testing > confirmed. > > I don't know if he was using a kernel enhanced with CAM through custom > configuration > or if he was using everything stock... and I could ask him... but it appeared > to be working > I asked Allan about that, and this was his response... AJ> Stock 9 and 10 use CAM by default. In 8.x camcontrol is there, but the AJ> regular SATA disks do not show up if you do camcontrol devlist, because AJ> they are the old style (ad4) instead of the new cam style (ada0) etc. AJ> AJ> So worst case, you get a blank output from camcontrol devlist -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256343 - in head/usr.sbin/bsdinstall: . scripts
On Oct 12, 2013, at 12:26 AM, Nathan Whitehorn wrote: > On 10/11/13 22:41, Devin Teske wrote: >> Author: dteske >> Date: Fri Oct 11 20:41:35 2013 >> New Revision: 256343 >> URL: >> https://urldefense.proofpoint.com/v1/url?u=http://svnweb.freebsd.org/changeset/base/256343&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=LDzuPpXPP4D5BzfISZjw%2BXitYn4aKVzfXzcrmMNFo2U%3D%0A&s=3d0963d9c497f7bad091032ca62844580612dc48ab3a8a6768fe640c365b >> >> Log: >> Add zfsboot module as an option for automatic configuration. Default is >> to run interactively but it can be scripted too (optinally completely >> non-interactive). Currently supports GELI and all ZFS vdev types. Also >> performs validation on selections/settings providing error messages if >> necessary, explaining (in plain language) what the issue is. Currently >> the auto partitioning of naked disks only supports GPT and MBR (VTOC8 >> pending for sparc64), so is only available for i386/amd64 install. >> >> Submitted by: Allan Jude , myself >> Reviewed by:Allan Jude >> Approved by:re (glebius) > > Hi Devin -- > > As was discussed on the mailing list, this patch still has some issues > that need to be resolved, Can you kindly provide links? I'm crawling through the mailing lists and not finding anything for the October, (current, stable, sysinstall, ... ?? others?) Do I need to be looking back in September? I wouldn't think so, because that bit wasn't even in our development tree until October 1st: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A%3Absdconfig%3A%3Ashare%3A%3Adevice.subr.patch?revision=1.1&view=markup So there couldn't have been any discussion on it before then. So I'm just not able to find the mailing lists where all the action is that they're discussing it. Would be nice to find where the action is, so I could participate. > for example the use of camcontrol > unconditionally even when the disks may not be CAM Allan Adds: 9.2 should have all disks listed in camcontrol, so it shouldn't be an issue And: I think the only systems without cam based disks are old 8.x - we're only targeting 10 anyway. I tend to agree with those statements. > and destruction of > existing sub-partitioning for MBR disks. I think we both (Allan and I) actually responded directly to you on this one. We have code that handles that. It's in there. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
hihi, I've just test booted this on a MIPS board. It doesn't hang at boot waiting for entropy. http://people.freebsd.org/~adrian/mips/20131012-ar9344-boot-1.txt Thanks! -adrian On 12 October 2013 05:57, Mark Murray wrote: > Author: markm > Date: Sat Oct 12 12:57:57 2013 > New Revision: 256377 > URL: http://svnweb.freebsd.org/changeset/base/256377 > > Log: > Merge from project branch. Uninteresting commits are trimmed. > > Refactor of /dev/random device. Main points include: > > * Userland seeding is no longer used. This auto-seeds at boot time > on PC/Desktop setups; this may need some tweeking and intelligence > from those folks setting up embedded boxes, but the work is believed > to be minimal. > > * An entropy cache is written to /entropy (even during installation) > and the kernel uses this at next boot. > > * An entropy file written to /boot/entropy can be loaded by loader(8) > > * Hardware sources such as rdrand are fed into Yarrow, and are no > longer available raw. > > > r256240 | des | 2013-10-09 21:14:16 +0100 (Wed, 09 Oct 2013) | 4 lines > > Add a RANDOM_RWFILE option and hide the entropy cache code behind it. > Rename YARROW_RNG and FORTUNA_RNG to RANDOM_YARROW and RANDOM_FORTUNA. > Add the RANDOM_* options to LINT. > > > r256239 | des | 2013-10-09 21:12:59 +0100 (Wed, 09 Oct 2013) | 2 lines > > Define RANDOM_PURE_RNDTEST for rndtest(4). > > > r256204 | des | 2013-10-09 18:51:38 +0100 (Wed, 09 Oct 2013) | 2 lines > > staticize struct random_hardware_source > > > r256203 | markm | 2013-10-09 18:50:36 +0100 (Wed, 09 Oct 2013) | 2 lines > > Wrap some policy-rich code in 'if NOTYET' until we can thresh out > what it really needs to do. > > > r256184 | des | 2013-10-09 10:13:12 +0100 (Wed, 09 Oct 2013) | 2 lines > > Re-add /dev/urandom for compatibility purposes. > > > r256182 | des | 2013-10-09 10:11:14 +0100 (Wed, 09 Oct 2013) | 3 lines > > Add missing include guards and move the existing ones out of the > implementation namespace. > > > r256168 | markm | 2013-10-08 23:14:07 +0100 (Tue, 08 Oct 2013) | 10 lines > > Fix some just-noticed problems: > > o Allow this to work with "nodevice random" by fixing where the > MALLOC pool is defined. > > o Fix the explicit reseed code. This was correct as submitted, but > in the project branch doesn't need to set the "seeded" bit as this > is done correctly in the "unblock" function. > > o Remove some debug ifdeffing. > > o Adjust comments. > > > r256159 | markm | 2013-10-08 19:48:11 +0100 (Tue, 08 Oct 2013) | 6 lines > > Time to eat crow for me. > > I replaced the sx_* locks that Arthur used with regular mutexes; > this turned out the be the wrong thing to do as the locks need to > be sleepable. Revert this folly. > > # Submitted by: Arthur Mesh (In original > diff) > > > r256138 | des | 2013-10-08 12:05:26 +0100 (Tue, 08 Oct 2013) | 10 lines > > Add YARROW_RNG and FORTUNA_RNG to sys/conf/options. > > Add a SYSINIT that forces a reseed during proc0 setup, which happens > fairly late in the boot process. > > Add a RANDOM_DEBUG option which enables some debugging printf()s. > > Add a new RANDOM_ATTACH entropy source which harvests entropy from the > get_cyclecount() delta across each call to a device attach method. > > > r256135 | markm | 2013-10-08 07:54:52 +0100 (Tue, 08 Oct 2013) | 8 lines > > Debugging. My attempt at EVENTHANDLER(multiuser) was a failure; use > EVENTHANDLER(mountroot) instead. > > This means we can't count on /var being present, so something will > need to be done about harvesting /var/db/entropy/... . > > Some policy now needs to be sorted out, and a pre-sync cache needs > to be written, but apart from that we are now ready to go. > > Over to review. > > --
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 12 Oct 2013, at 17:27, Adrian Chadd wrote: > hihi, > > I've just test booted this on a MIPS board. It doesn't hang at boot waiting > for entropy. > > http://people.freebsd.org/~adrian/mips/20131012-ar9344-boot-1.txt > > Thanks! You are most welcome! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 12 Oct 2013, at 17:35, "Teske, Devin" wrote: > Can you maybe test with ZFS + Geli? I'm concerned because we told it to use > random(4) > instead of urandom(4). I hope there's enough entropy when creating the geli > stuff that > said process doesn't hang. I think DES's patch will help there too (not that > anyone > testing our ZFS patches reported any hangs... including when testing GELI -- > this was > before DES's patch). urandom is a symlink to random. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On Oct 12, 2013, at 9:39 AM, Mark R V Murray wrote: > > On 12 Oct 2013, at 17:35, "Teske, Devin" wrote: >> Can you maybe test with ZFS + Geli? I'm concerned because we told it to use >> random(4) >> instead of urandom(4). I hope there's enough entropy when creating the geli >> stuff that >> said process doesn't hang. I think DES's patch will help there too (not that >> anyone >> testing our ZFS patches reported any hangs... including when testing GELI -- >> this was >> before DES's patch). > > urandom is a symlink to random. > Hmmm, interesting ;D You know... for years I've been compiling a custom apache for $work and using the --with-random=/dev/urandom flag. And then recently in the past couple years in 8.x I recall having problems with a GnuPG related tool that would hang due to lack of entropy on a freshly installed box when generating "stuff" using random(4). Are the days of choosing between urandom(4) and random(4) over? Would SSL function great on a freshly installed box even if using random(4) for apache? (it wants to default to /dev/random anyways) -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 12 Oct 2013, at 17:44, "Teske, Devin" wrote: > You know... for years I've been compiling a custom apache for $work and using > the > --with-random=/dev/urandom flag. And then recently in the past couple years > in 8.x > I recall having problems with a GnuPG related tool that would hang due to > lack of > entropy on a freshly installed box when generating "stuff" using random(4). > > Are the days of choosing between urandom(4) and random(4) over? They were over last millennium :-) > Would SSL function great on a freshly installed box even if using random(4) > for > apache? (it wants to default to /dev/random anyways) Yup! No worse than usual. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On Oct 12, 2013, at 9:46 AM, Mark R V Murray wrote: > > On 12 Oct 2013, at 17:44, "Teske, Devin" wrote: > >> You know... for years I've been compiling a custom apache for $work and >> using the >> --with-random=/dev/urandom flag. And then recently in the past couple years >> in 8.x >> I recall having problems with a GnuPG related tool that would hang due to >> lack of >> entropy on a freshly installed box when generating "stuff" using random(4). >> >> Are the days of choosing between urandom(4) and random(4) over? > > They were over last millennium :-) > Heh, Ok ;D so it sounds like a left-over from 4.11 ;D >> Would SSL function great on a freshly installed box even if using random(4) >> for >> apache? (it wants to default to /dev/random anyways) > > Yup! No worse than usual. > Cool, thanks! That also answers my question for bsdinstall GELI setup using random(4). Doubly-thanks! -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 12 Oct 2013, at 17:49, "Teske, Devin" wrote: > Doubly-thanks! Glad to be useful. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
svn commit: r256385 - in head: etc/rc.d share/man/man5 usr.sbin/jail
Author: hrs
Date: Sat Oct 12 17:27:59 2013
New Revision: 256385
URL: http://svnweb.freebsd.org/changeset/base/256385
Log:
- Add mount.fdescfs parameter to jail(8). This is similar to
mount.devfs but mounts fdescfs. The mount happens just after
mount.devfs.
- rc.d/jail now displays whole error message from jail(8) when a jail
fails to start.
Approved by: re (gjb)
Modified:
head/etc/rc.d/jail
head/share/man/man5/rc.conf.5
head/usr.sbin/jail/command.c
head/usr.sbin/jail/config.c
head/usr.sbin/jail/jail.8
head/usr.sbin/jail/jail.c
head/usr.sbin/jail/jailp.h
Modified: head/etc/rc.d/jail
==
--- head/etc/rc.d/jail Sat Oct 12 16:11:57 2013(r256384)
+++ head/etc/rc.d/jail Sat Oct 12 17:27:59 2013(r256385)
@@ -226,8 +226,7 @@ parse_options()
eval : \${jail_${_j}_fdescfs_enable:=${jail_fdescfs_enable:-NO}}
if checkyesno jail_${_j}_fdescfs_enable; then
- echo " mount += " \
- "\"fdescfs ${_rootdir%/}/dev/fd fdescfs rw 0 0\";"
+ echo " mount.fdescfs;"
fi
eval : \${jail_${_j}_procfs_enable:=${jail_procfs_enable:-NO}}
if checkyesno jail_${_j}_procfs_enable; then
@@ -438,7 +437,7 @@ jail_start()
echo -n " ${_hostname:-${_jail}}"
else
echo " cannot start jail \"${_hostname:-${jail}}\": "
- tail +2 $_tmp
+ cat $_tmp
fi
rm -f $_tmp
done
Modified: head/share/man/man5/rc.conf.5
==
--- head/share/man/man5/rc.conf.5 Sat Oct 12 16:11:57 2013
(r256384)
+++ head/share/man/man5/rc.conf.5 Sat Oct 12 17:27:59 2013
(r256385)
@@ -24,7 +24,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd October 10, 2013
+.Dd October 12, 2013
.Dt RC.CONF 5
.Os
.Sh NAME
@@ -3992,9 +3992,7 @@ set from
.Va jail_ Ns Ao Ar jname Ac Ns Va _fstab
.It Li mount
set from
-.Va jail_ Ns Ao Ar jname Ac Ns Va _fdescfs_enable
-or
-.Va jail_ Ns Ao Ar jname Ac Ns Va _procfs_enable.
+.Va jail_ Ns Ao Ar jname Ac Ns Va _procfs_enable .
.It Li exec.fib
set from
.Va jail_ Ns Ao Ar jname Ac Ns Va _fib
@@ -4042,6 +4040,9 @@ set from
.Va jail_ Ns Ao Ar jname Ac Ns Va _devfs_ruleset .
This must be an integer,
not a string.
+.It Li mount.fdescfs
+set from
+.Va jail_ Ns Ao Ar jname Ac Ns Va _fdescfs_enable
.It Li allow.set_hostname
set from
.Va jail_ Ns Ao Ar jname Ac Ns Va _set_hostname_allow
Modified: head/usr.sbin/jail/command.c
==
--- head/usr.sbin/jail/command.cSat Oct 12 16:11:57 2013
(r256384)
+++ head/usr.sbin/jail/command.cSat Oct 12 17:27:59 2013
(r256385)
@@ -106,7 +106,12 @@ next_command(struct cfjail *j)
case IP_MOUNT_DEVFS:
if (!bool_param(j->intparams[IP_MOUNT_DEVFS]))
continue;
- /* FALLTHROUGH */
+ j->comstring = &dummystring;
+ break;
+ case IP_MOUNT_FDESCFS:
+ if (!bool_param(j->intparams[IP_MOUNT_FDESCFS]))
+ continue;
+ j->comstring = &dummystring;
case IP__OP:
case IP_STOP_TIMEOUT:
j->comstring = &dummystring;
@@ -452,6 +457,32 @@ run_command(struct cfjail *j)
}
break;
+ case IP_MOUNT_FDESCFS:
+ argv = alloca(7 * sizeof(char *));
+ path = string_param(j->intparams[KP_PATH]);
+ if (path == NULL) {
+ jail_warnx(j, "mount.fdescfs: no path");
+ return -1;
+ }
+ devpath = alloca(strlen(path) + 8);
+ sprintf(devpath, "%s/dev/fd", path);
+ if (check_path(j, "mount.fdescfs", devpath, 0,
+ down ? "fdescfs" : NULL) < 0)
+ return -1;
+ if (down) {
+ *(const char **)&argv[0] = "/sbin/umount";
+ argv[1] = devpath;
+ argv[2] = NULL;
+ } else {
+ *(const char **)&argv[0] = _PATH_MOUNT;
+ *(const char **)&argv[1] = "-t";
+ *(const char **)&argv[2] = "fdescfs";
+ *(const char **)&argv[3] = ".";
+ argv[4] = devpath;
+ argv[5] = NULL;
+ }
+ break;
+
case IP_COMMAND:
if
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
"Teske, Devin" writes: > Can you maybe test with ZFS + Geli? I'm concerned because we told it > to use random(4) instead of urandom(4). I hope there's enough entropy > when creating the geli stuff that said process doesn't hang. /dev/urandom is a symlink to /dev/random. Neither will block, because we explicitly mark /dev/random as seeded with a SYSINIT late in the boot (not as late as I'd like, but not too early either). > I think DES's patch will help there too (not that anyone testing our > ZFS patches reported any hangs... including when testing GELI -- this > was before DES's patch). If you mean the device attach entropy gathering, that was a case of parallel invention from Pawel and myself, where I ended up using Pawel's patch with minor modifications. DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r256389 - head/usr.sbin/bhyve
Author: grehan
Date: Sat Oct 12 19:31:19 2013
New Revision: 256389
URL: http://svnweb.freebsd.org/changeset/base/256389
Log:
Implement the virtio block 'get-ident' operation. This eliminates the
annoying verbose boot error of the form
g_handleattr: vtbd0 bio_length 24 len 28 -> EFAULT
The ident returned by bhyve is a text string 'BHYVE--', where
the X's are the first bytes of the md5 hash of the backing filename.
Reviewed by: neel
Approved by: re (gjb)
Modified:
head/usr.sbin/bhyve/pci_virtio_block.c
Modified: head/usr.sbin/bhyve/pci_virtio_block.c
==
--- head/usr.sbin/bhyve/pci_virtio_block.c Sat Oct 12 18:24:52 2013
(r256388)
+++ head/usr.sbin/bhyve/pci_virtio_block.c Sat Oct 12 19:31:19 2013
(r256389)
@@ -46,17 +46,25 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include "bhyverun.h"
#include "pci_emul.h"
#include "virtio.h"
+#ifndef min
+#definemin(a, b) ((a) < (b) ? (a) : (b))
+#endif
+
#define VTBLK_RINGSZ 64
#define VTBLK_MAXSEGS 32
#define VTBLK_S_OK 0
#define VTBLK_S_IOERR 1
+#defineVTBLK_S_UNSUPP 2
+
+#defineVTBLK_BLK_ID_BYTES 20
/*
* Host capabilities
@@ -85,6 +93,7 @@ struct vtblk_config {
struct virtio_blk_hdr {
#defineVBH_OP_READ 0
#defineVBH_OP_WRITE1
+#defineVBH_OP_IDENT8
#defineVBH_FLAG_BARRIER0x8000 /* OR'ed into vbh_type
*/
uint32_tvbh_type;
uint32_tvbh_ioprio;
@@ -106,6 +115,7 @@ struct pci_vtblk_softc {
struct vqueue_info vbsc_vq;
int vbsc_fd;
struct vtblk_config vbsc_cfg;
+ char vbsc_ident[VTBLK_BLK_ID_BYTES];
};
static void pci_vtblk_reset(void *);
@@ -180,7 +190,7 @@ pci_vtblk_proc(struct pci_vtblk_softc *s
for (i = 1; i < n; i++) {
/*
* - write op implies read-only descriptor,
-* - read op implies write-only descriptor,
+* - read/ident op implies write-only descriptor,
* therefore test the inverse of the descriptor bit
* to the op.
*/
@@ -189,14 +199,34 @@ pci_vtblk_proc(struct pci_vtblk_softc *s
}
DPRINTF(("virtio-block: %s op, %d bytes, %d segs, offset %ld\n\r",
-writeop ? "write" : "read", iolen, i - 1, offset));
+writeop ? "write" : "read/ident", iolen, i - 1, offset));
- if (writeop)
+ switch (type) {
+ case VBH_OP_WRITE:
err = pwritev(sc->vbsc_fd, iov + 1, i - 1, offset);
- else
+ break;
+ case VBH_OP_READ:
err = preadv(sc->vbsc_fd, iov + 1, i - 1, offset);
+ break;
+ case VBH_OP_IDENT:
+ /* Assume a single buffer */
+ strlcpy(iov[1].iov_base, sc->vbsc_ident,
+ min(iov[1].iov_len, sizeof(sc->vbsc_ident)));
+ err = 0;
+ break;
+ default:
+ err = -ENOSYS;
+ break;
+ }
- *status = err < 0 ? VTBLK_S_IOERR : VTBLK_S_OK;
+ /* convert errno into a virtio block error return */
+ if (err < 0) {
+ if (err == -ENOSYS)
+ *status = VTBLK_S_UNSUPP;
+ else
+ *status = VTBLK_S_IOERR;
+ } else
+ *status = VTBLK_S_OK;
/*
* Return the descriptor back to the host.
@@ -220,6 +250,8 @@ static int
pci_vtblk_init(struct vmctx *ctx, struct pci_devinst *pi, char *opts)
{
struct stat sbuf;
+ MD5_CTX mdctx;
+ u_char digest[16];
struct pci_vtblk_softc *sc;
off_t size;
int fd;
@@ -274,6 +306,16 @@ pci_vtblk_init(struct vmctx *ctx, struct
sc->vbsc_vq.vq_qsize = VTBLK_RINGSZ;
/* sc->vbsc_vq.vq_notify = we have no per-queue notify */
+ /*
+* Create an identifier for the backing file. Use parts of the
+* md5 sum of the filename
+*/
+ MD5Init(&mdctx);
+ MD5Update(&mdctx, opts, strlen(opts));
+ MD5Final(digest, &mdctx);
+ sprintf(sc->vbsc_ident, "BHYVE-%02X%02X-%02X%02X-%02X%02X",
+ digest[0], digest[1], digest[2], digest[3], digest[4], digest[5]);
+
/* setup virtio block config space */
sc->vbsc_cfg.vbc_capacity = size / sectsz;
sc->vbsc_cfg.vbc_seg_max = VTBLK_MAXSEGS;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r256391 - head/usr.sbin/bsdconfig/share
Author: dteske
Date: Sat Oct 12 19:52:27 2013
New Revision: 256391
URL: http://svnweb.freebsd.org/changeset/base/256391
Log:
Fix signed integer overflow detection in f_expand_number() of strings.subr.
Approved by: re (glebius)
Modified:
head/usr.sbin/bsdconfig/share/strings.subr
Modified: head/usr.sbin/bsdconfig/share/strings.subr
==
--- head/usr.sbin/bsdconfig/share/strings.subr Sat Oct 12 19:41:35 2013
(r256390)
+++ head/usr.sbin/bsdconfig/share/strings.subr Sat Oct 12 19:52:27 2013
(r256391)
@@ -341,17 +341,19 @@ f_shell_unescape()
#
# NOTE: Prefixes are case-insensitive.
#
-# Upon successful completion, the value 0 is returned (or stored to
-# $var_to_set); otherwise -1. Reasons for a -1 return include:
+# Upon successful completion, success status is returned; otherwise the number
+# -1 is produced ($var_to_set set to -1 or if $var_to_set is NULL or missing)
+# on standard output. In the case of failure, the error status will be one of:
#
-# Given $string contains no digits.
-# An unrecognized prefix was given.
-# Result too large to calculate.
+# Status Reason
+# 1 Given $string contains no digits
+# 2 An unrecognized prefix was given
+# 3 Result too large to calculate
#
f_expand_number()
{
local __string="$1" __var_to_set="$2"
- local __cp __num
+ local __cp __num __bshift __maxinput
# Remove any leading non-digits
while :; do
@@ -360,14 +362,14 @@ f_expand_number()
[ "$__string" = "$__cp" ] && break
done
- # Return `-1' if string didn't contain any digits
+ # Produce `-1' if string didn't contain any digits
if [ ! "$__string" ]; then
if [ "$__var_to_set" ]; then
setvar "$__var_to_set" -1
else
echo -1
fi
- return $FAILURE
+ return 1 # 1 = "Given $string contains no digits"
fi
# Store the numbers
@@ -390,9 +392,23 @@ f_expand_number()
[ "$__string" = "$__cp" ] && break
done
- # Test for invalid prefix
+ #
+ # Test for invalid prefix (and determine bitshift length)
+ #
case "$__string" in
- ""|[KkMmGgTtPpEe]*) : known prefix ;;
+ ""|[[:space:]]*) # Shortcut
+ if [ "$__var_to_set" ]; then
+ setvar "$__var_to_set" $__num
+ else
+ echo $__num
+ fi
+ return $SUCCESS ;;
+ [Kk]*) __bshift=10 ;;
+ [Mm]*) __bshift=20 ;;
+ [Gg]*) __bshift=30 ;;
+ [Tt]*) __bshift=40 ;;
+ [Pp]*) __bshift=50 ;;
+ [Ee]*) __bshift=60 ;;
*)
# Unknown prefix
if [ "$__var_to_set" ]; then
@@ -400,29 +416,23 @@ f_expand_number()
else
echo -1
fi
- return $FAILURE
+ return 2 # 2 = "An unrecognized prefix was given"
esac
- # Multiply the number out
- case "$__string" in
- [Kk]) __num=$(( $__num * 1024 )) ;;
- [Mm]) __num=$(( $__num * 1048576 )) ;;
- [Gg]) __num=$(( $__num * 1073741824 )) ;;
- [Tt]) __num=$(( $__num * 1099511627776 )) ;;
- [Pp]) __num=$(( $__num * 1125899906842624 )) ;;
- [Ee]) __num=$(( $__num * 1152921504606846976 )) ;;
- esac
- if [ $__num -le 0 ]; then
- # Arithmetic overflow
+ # Determine if the wheels fall off
+ __maxinput=$(( 0x7fff >> $__bshift ))
+ if [ $__num -gt $__maxinput ]; then
+ # Input (before expanding) would exceed 64-bit signed int
if [ "$__var_to_set" ]; then
setvar "$__var_to_set" -1
else
echo -1
fi
- return $FAILURE
+ return 3 # 3 = "Result too large to calculate"
fi
- # Return the number
+ # Shift the number out and produce it
+ __num=$(( $__num << $__bshift ))
if [ "$__var_to_set" ]; then
setvar "$__var_to_set" $__num
else
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
Adrian Chadd writes: > I've just test booted this on a MIPS board. It doesn't hang at boot waiting > for > entropy. > > http://people.freebsd.org/~adrian/mips/20131012-ar9344-boot-1.txt Do me a favor, rebuild your kernel with "option DEBUG_RANDOM" (to save time, just add #define DEBUG_RANDOM 1 manually to opt_random.h and do a KERNFAST build) and post the dmesg. It will show how much entropy we've accumulated before we force a reseed. DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
Dag-Erling Smørgrav writes: > Do me a favor, rebuild your kernel with "option DEBUG_RANDOM" (to save > time, just add #define DEBUG_RANDOM 1 manually to opt_random.h and do a > KERNFAST build) and post the dmesg. Sorry, I meant RANDOM_DEBUG. DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
http://people.freebsd.org/~adrian/mips/20131012-ar9344-boot-2.txt -a On 12 October 2013 13:05, Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: > > Do me a favor, rebuild your kernel with "option DEBUG_RANDOM" (to save > > time, just add #define DEBUG_RANDOM 1 manually to opt_random.h and do a > > KERNFAST build) and post the dmesg. > > Sorry, I meant RANDOM_DEBUG. > > DES > -- > Dag-Erling Smørgrav - d...@des.no > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
Adrian Chadd writes: > http://people.freebsd.org/~adrian/mips/20131012-ar9344-boot-2.txt Not stellar: random_yarrow_reseed(): fast: 0 68 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 random_yarrow_reseed(): slow: 0 68 0 0 0 0 0 0 5 0 0 0 0 0 0 0 0 Can you apply the following patch and try again: Index: sys/dev/random/random_adaptors.c === --- sys/dev/random/random_adaptors.c(revision 256386) +++ sys/dev/random/random_adaptors.c(working copy) @@ -239,5 +239,5 @@ (*random_adaptor->reseed)(); arc4rand(NULL, 0, 1); } -SYSINIT(random_reseed, SI_SUB_INTRINSIC_POST, SI_ORDER_SECOND, +SYSINIT(random_reseed, SI_SUB_KTHREAD_INIT, SI_ORDER_FIRST, random_adaptors_reseed, NULL); Index: sys/kern/init_main.c === --- sys/kern/init_main.c(revision 256386) +++ sys/kern/init_main.c(working copy) @@ -853,4 +853,4 @@ sched_add(td, SRQ_BORING); thread_unlock(td); } -SYSINIT(kickinit, SI_SUB_KTHREAD_INIT, SI_ORDER_FIRST, kick_init, NULL); +SYSINIT(kickinit, SI_SUB_KTHREAD_INIT, SI_ORDER_MIDDLE, kick_init, NULL); DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256377 - in head: problems on ARM BEAGLEBONE
On Sat, 2013-10-12 at 12:57 +, Mark Murray wrote: > Author: markm > Date: Sat Oct 12 12:57:57 2013 > New Revision: 256377 > URL: http://svnweb.freebsd.org/changeset/base/256377 > > Log: > Merge from project branch. Uninteresting commits are trimmed. > > [snip] > *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** I rebuilt my beaglebone sandbox today after syncing to the latest -current and this happened: FreeBSD 11.0-CURRENT #4 r256393: Sat Oct 12 17:05:43 MDT 2013 ilep...@revolution.hippie.lan:/local/build/staging/freebsd/bb/obj/arm.armv6/local/build/staging/freebsd/bb/src/sys/BB arm ... random device not loaded; using insecure entropy Falling back to random adaptor random: initialized ... Setting hostid: 0xdcf01d1d. Entropy harvesting:sysctl: unknown oid 'kern.random.sys.harvest.interrupt': No such file or directory interruptssysctl: unknown oid 'kern.random.sys.harvest.ethernet': No such file or directory ethernetsysctl: unknown oid 'kern.random.sys.harvest.point_to_point': No such file or directory point_to_pointsysctl: unknown oid 'kern.random.sys.harvest.swi': No such file or directory swi. Starting file system checks: mount_nfs: can't update /var/db/mounttab for 172.22.42.240:/bb Mounting local file systems:. Writing entropy file:random: dummy device blocking on read. If you remove "device random" from the config then it says only "random device not loaded; using insecure entropy" early in boot, and it doesn't block during rc processing. What's being used in that case, arc4random()? It looks like the cause of the problem is that both the dummy and the yarrow generators register, dummy first, and so it gets chosen even though yarrow is available. -- Ian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r256377 - in head: problems on ARM BEAGLEBONE
On Sat, Oct 12, 2013 at 06:07:58PM -0600, Ian Lepore wrote: > On Sat, 2013-10-12 at 12:57 +, Mark Murray wrote: > > Author: markm > > Date: Sat Oct 12 12:57:57 2013 > > New Revision: 256377 > > URL: http://svnweb.freebsd.org/changeset/base/256377 > > > > Log: > > Merge from project branch. Uninteresting commits are trimmed. > > > > [snip] > > *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** > > I rebuilt my beaglebone sandbox today after syncing to the latest > -current and this happened: > > > FreeBSD 11.0-CURRENT #4 r256393: Sat Oct 12 17:05:43 MDT 2013 > > ilep...@revolution.hippie.lan:/local/build/staging/freebsd/bb/obj/arm.armv6/local/build/staging/freebsd/bb/src/sys/BB > arm > ... > random device not loaded; using insecure entropy > Falling back to random adaptor > random: initialized > ... > Setting hostid: 0xdcf01d1d. > Entropy harvesting:sysctl: unknown oid 'kern.random.sys.harvest.interrupt': > No such file or directory > interruptssysctl: unknown oid 'kern.random.sys.harvest.ethernet': No such > file or directory > ethernetsysctl: unknown oid 'kern.random.sys.harvest.point_to_point': No > such file or directory > point_to_pointsysctl: unknown oid 'kern.random.sys.harvest.swi': No such > file or directory > swi. > Starting file system checks: > mount_nfs: can't update /var/db/mounttab for 172.22.42.240:/bb > Mounting local file systems:. > Writing entropy file:random: dummy device blocking on read. > > > If you remove "device random" from the config then it says only "random > device not loaded; using insecure entropy" early in boot, and it doesn't > block during rc processing. What's being used in that case, > arc4random()? > > It looks like the cause of the problem is that both the dummy and the > yarrow generators register, dummy first, and so it gets chosen even > though yarrow is available. > > This is being fixed right now, please standby for the relevant commits to hit the tree. Glen pgpdQJJj0UYZ5.pgp Description: PGP signature
svn commit: r256412 - head/sys/dev/random
Author: markm
Date: Sun Oct 13 00:10:48 2013
New Revision: 256412
URL: http://svnweb.freebsd.org/changeset/base/256412
Log:
There is an issue (not seen in our testing) where "yarrow" and
"dummy" switch priorities, and the users are left with no usable
/dev/random. The fix assigns priories to these and gives the users
what they want. The override tuneable has a stupid name (blame me!)
and this fixes it to be something that 'sysctl kern.random' emits
and is the right thing to set.
Approved by: re (gjb)
Approved by: secteam (cperciva)
Modified:
head/sys/dev/random/dummy_rng.c
head/sys/dev/random/random_adaptors.c
head/sys/dev/random/randomdev.h
head/sys/dev/random/randomdev_soft.c
Directory Properties:
head/sys/ (props changed)
Modified: head/sys/dev/random/dummy_rng.c
==
--- head/sys/dev/random/dummy_rng.c Sat Oct 12 23:51:00 2013
(r256411)
+++ head/sys/dev/random/dummy_rng.c Sun Oct 13 00:10:48 2013
(r256412)
@@ -102,6 +102,7 @@ struct random_adaptor dummy_random = {
.read = (random_read_func_t *)random_null_func,
.reseed = (random_reseed_func_t *)random_null_func,
.seeded = 0, /* This device can never be seeded */
+ .priority = 1, /* Bottom priority, so goes to last position */
};
static int
Modified: head/sys/dev/random/random_adaptors.c
==
--- head/sys/dev/random/random_adaptors.c Sat Oct 12 23:51:00 2013
(r256411)
+++ head/sys/dev/random/random_adaptors.c Sun Oct 13 00:10:48 2013
(r256412)
@@ -104,12 +104,13 @@ void
random_adaptor_choose(struct random_adaptor **adaptor)
{
char rngs[128], *token, *cp;
- struct random_adaptors *rpp;
+ struct random_adaptors *rppi, *ramax;
+ unsigned primax;
KASSERT(adaptor != NULL, ("pre-conditions failed"));
*adaptor = NULL;
- if (TUNABLE_STR_FETCH("rngs_want", rngs, sizeof(rngs))) {
+ if (TUNABLE_STR_FETCH("kern.random.active_adaptor", rngs,
sizeof(rngs))) {
cp = rngs;
while ((token = strsep(&cp, ",")) != NULL)
@@ -120,16 +121,23 @@ random_adaptor_choose(struct random_adap
" skipping\n", token);
}
+ primax = 0U;
if (*adaptor == NULL) {
/*
-* Fallback to the first thing that's on the list of
-* available RNGs.
+* Fall back to the highest priority item on the available
+* RNG list.
*/
sx_slock(&adaptors_lock);
- rpp = LIST_FIRST(&adaptors);
- if (rpp != NULL)
- *adaptor = rpp->rsp;
+ ramax = NULL;
+ LIST_FOREACH(rppi, &adaptors, entries) {
+ if (rppi->rsp->priority >= primax) {
+ ramax = rppi;
+ primax = rppi->rsp->priority;
+ }
+ }
+ if (ramax != NULL)
+ *adaptor = ramax->rsp;
sx_sunlock(&adaptors_lock);
Modified: head/sys/dev/random/randomdev.h
==
--- head/sys/dev/random/randomdev.h Sat Oct 12 23:51:00 2013
(r256411)
+++ head/sys/dev/random/randomdev.h Sun Oct 13 00:10:48 2013
(r256412)
@@ -44,6 +44,7 @@ struct random_adaptor {
struct selinfo rsel;
const char *ident;
int seeded;
+ unsignedpriority;
random_init_func_t *init;
random_deinit_func_t*deinit;
random_block_func_t *block;
Modified: head/sys/dev/random/randomdev_soft.c
==
--- head/sys/dev/random/randomdev_soft.cSat Oct 12 23:51:00 2013
(r256411)
+++ head/sys/dev/random/randomdev_soft.cSun Oct 13 00:10:48 2013
(r256412)
@@ -84,6 +84,7 @@ static struct random_adaptor random_cont
.poll = randomdev_poll,
.reseed = randomdev_flush_reseed,
.seeded = 0, /* This will be seeded during entropy processing */
+ .priority = 90, /* High priority, so top of the list. Fortuna may still
win. */
};
#define RANDOM_MODULE_NAME yarrow
#define RANDOM_CSPRNG_NAME "yarrow"
@@ -99,6 +100,7 @@ static struct random_adaptor random_cont
.poll = randomdev_poll,
.reseed = randomdev_flush_reseed,
.seeded = 0, /* This will be excplicitly seeded at startup when secured
*/
+ .priority = 100, /* High priority, so top of the list. Beat Yarrow. */
};
#define RANDOM_MODULE_NAME fortuna
#define RANDOM_CSPRNG_NAME "fortuna"
Re: svn commit: r256377 - in head: problems on ARM BEAGLEBONE
On 13 Oct 2013, at 01:07, Ian Lepore wrote: > It looks like the cause of the problem is that both the dummy and the > yarrow generators register, dummy first, and so it gets chosen even > though yarrow is available. Correct diagnosis! This is now fixed; sorry for the hassle. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: problems on ARM BEAGLEBONE
On Sun, 2013-10-13 at 01:29 +0100, Mark R V Murray wrote: > On 13 Oct 2013, at 01:07, Ian Lepore wrote: > > It looks like the cause of the problem is that both the dummy and the > > yarrow generators register, dummy first, and so it gets chosen even > > though yarrow is available. > > Correct diagnosis! > > This is now fixed; sorry for the hassle. > > M Yep, I just updated and rebuilt, it's all better now, thanks! -- Ian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r256423 - head/sys/dev/xen/blkfront
Author: gibbs
Date: Sun Oct 13 02:34:20 2013
New Revision: 256423
URL: http://svnweb.freebsd.org/changeset/base/256423
Log:
Allow FreeBSD to be booted from CDROM media on XenServer 6.2 and
prior releases.
Submitted by: Roger Pau Monné
Sponsored by: Citrix Systems R&D
Reviewed by: gibbs
Approved by: re (gjb)
sys/dev/xen/blkfront/blkfront.c:
On XenServer versions up to an including 6.2, paravirtualized
CDROM support is broken. When running in an HVM domain,
ignore paravirtualized instances of CDROM media, and instead
rely on native drivers attaching to emulated hardware. This
functions correctly on all currently known Xen based
platforms.
Modified:
head/sys/dev/xen/blkfront/blkfront.c
Modified: head/sys/dev/xen/blkfront/blkfront.c
==
--- head/sys/dev/xen/blkfront/blkfront.cSun Oct 13 00:29:14 2013
(r256422)
+++ head/sys/dev/xen/blkfront/blkfront.cSun Oct 13 02:34:20 2013
(r256423)
@@ -1381,14 +1381,42 @@ xbd_closing(device_t dev)
static int
xbd_probe(device_t dev)
{
+ if (strcmp(xenbus_get_type(dev), "vbd") != 0)
+ return (ENXIO);
- if (!strcmp(xenbus_get_type(dev), "vbd")) {
- device_set_desc(dev, "Virtual Block Device");
- device_quiet(dev);
- return (0);
+ if (xen_hvm_domain()) {
+ int error;
+ char *type;
+
+ /*
+* When running in an HVM domain, IDE disk emulation is
+* disabled early in boot so that native drivers will
+* not see emulated hardware. However, CDROM device
+* emulation cannot be disabled.
+*
+* Through use of FreeBSD's vm_guest and xen_hvm_domain()
+* APIs, we could modify the native CDROM driver to fail its
+* probe when running under Xen. Unfortunatlely, the PV
+* CDROM support in XenServer (up through at least version
+* 6.2) isn't functional, so we instead rely on the emulated
+* CDROM instance, and fail to attach the PV one here in
+* the blkfront driver.
+*/
+ error = xs_read(XST_NIL, xenbus_get_node(dev),
+ "device-type", NULL, (void **) &type);
+ if (error)
+ return (ENXIO);
+
+ if (strncmp(type, "cdrom", 5) == 0) {
+ free(type, M_XENSTORE);
+ return (ENXIO);
+ }
+ free(type, M_XENSTORE);
}
- return (ENXIO);
+ device_set_desc(dev, "Virtual Block Device");
+ device_quiet(dev);
+ return (0);
}
/*
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r256425 - in head/sys: dev/hyperv/stordisengage dev/hyperv/vmbus sys
Author: gibbs
Date: Sun Oct 13 02:41:30 2013
New Revision: 256425
URL: http://svnweb.freebsd.org/changeset/base/256425
Log:
Centralize the detection logic for the Hyper-V hypervisor.
Submitted by: Roger Pau Monné
Sponsored by: Citrix Systems R&D
Reviewed by: gibbs, grehan
Approved by: re (gjb)
sys/sys/systm.h:
* Add a new VM_GUEST type, VM_GUEST_HV (HyperV guest).
sys/dev/hyperv/vmbus/hv_vmbus_drv_freebsd.c:
sys/dev/hyperv/vmbus/hv_hv.c:
sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c:
* Set vm_guest to VM_GUEST_HV and use that on other HyperV related
devices instead of cloning the cpuid hypervisor check.
* Cleanup the vmbus_identify function.
Modified:
head/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c
head/sys/dev/hyperv/vmbus/hv_hv.c
head/sys/dev/hyperv/vmbus/hv_vmbus_drv_freebsd.c
head/sys/sys/systm.h
Modified: head/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c
==
--- head/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.cSun Oct 13
02:35:19 2013(r256424)
+++ head/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.cSun Oct 13
02:41:30 2013(r256425)
@@ -75,17 +75,11 @@ __FBSDID("$FreeBSD$");
#include
#include
-#define HV_X64_MSR_GUEST_OS_ID 0x4000
-#define HV_X64_CPUID_MIN 0x4005
-#define HV_X64_CPUID_MAX 0x4000
-
/* prototypes */
static int hv_ata_pci_probe(device_t dev);
static int hv_ata_pci_attach(device_t dev);
static int hv_ata_pci_detach(device_t dev);
-static int hv_check_for_hyper_v(void);
-
/*
* generic PCI ATA device probe
*/
@@ -100,7 +94,7 @@ hv_ata_pci_probe(device_t dev)
/*
* Don't probe if not running in a Hyper-V environment
*/
- if (!hv_check_for_hyper_v())
+ if (vm_guest != VM_GUEST_HV)
return (ENXIO);
if (device_get_unit(parent) != 0 || device_get_ivars(dev) != 0)
@@ -139,33 +133,6 @@ hv_ata_pci_detach(device_t dev)
return (0);
}
-/**
-* Detect Hyper-V and enable fast IDE
-* via enlighted storage driver
-*/
-static int
-hv_check_for_hyper_v(void)
-{
- u_int regs[4];
- int hyper_v_detected;
-
- hyper_v_detected = 0;
- do_cpuid(1, regs);
- if (regs[2] & 0x8000) {
- /*
-* if(a hypervisor is detected)
-* make sure this really is Hyper-V
-*/
- do_cpuid(HV_X64_MSR_GUEST_OS_ID, regs);
- hyper_v_detected =
- regs[0] >= HV_X64_CPUID_MIN &&
- regs[0] <= HV_X64_CPUID_MAX &&
- !memcmp("Microsoft Hv", ®s[1], 12);
- }
-
- return (hyper_v_detected);
-}
-
static device_method_t hv_ata_pci_methods[] = {
/* device interface */
DEVMETHOD(device_probe, hv_ata_pci_probe),
Modified: head/sys/dev/hyperv/vmbus/hv_hv.c
==
--- head/sys/dev/hyperv/vmbus/hv_hv.c Sun Oct 13 02:35:19 2013
(r256424)
+++ head/sys/dev/hyperv/vmbus/hv_hv.c Sun Oct 13 02:41:30 2013
(r256425)
@@ -218,7 +218,7 @@ hv_vmbus_init(void)
0,
sizeof(hv_vmbus_handle) * MAXCPU);
- if (!hv_vmbus_query_hypervisor_presence())
+ if (vm_guest != VM_GUEST_HV)
goto cleanup;
max_leaf = hv_vmbus_get_hypervisor_version();
Modified: head/sys/dev/hyperv/vmbus/hv_vmbus_drv_freebsd.c
==
--- head/sys/dev/hyperv/vmbus/hv_vmbus_drv_freebsd.cSun Oct 13 02:35:19
2013(r256424)
+++ head/sys/dev/hyperv/vmbus/hv_vmbus_drv_freebsd.cSun Oct 13 02:41:30
2013(r256425)
@@ -295,11 +295,15 @@ hv_vmbus_child_device_unregister(struct
return(ret);
}
-static void vmbus_identify(driver_t *driver, device_t parent) {
+static void
+vmbus_identify(driver_t *driver, device_t parent)
+{
+ if (!hv_vmbus_query_hypervisor_presence())
+ return;
+
+ vm_guest = VM_GUEST_HV;
+
BUS_ADD_CHILD(parent, 0, "vmbus", 0);
- if (device_find_child(parent, "vmbus", 0) == NULL) {
- BUS_ADD_CHILD(parent, 0, "vmbus", 0);
- }
}
static int
@@ -307,9 +311,6 @@ vmbus_probe(device_t dev) {
if(bootverbose)
device_printf(dev, "VMBUS: probe\n");
- if (!hv_vmbus_query_hypervisor_presence())
- return (ENXIO);
-
device_set_desc(dev, "Vmbus Devices");
return (0);
@@ -491,10 +492,13 @@ vmbus_attach(device_t dev)
static void
vmbus_init(void)
{
+ if (vm_guest != VM_GUEST_HV)
+ return;
+
/*
* If the system has already booted and thread
-* scheduling is possible indicated by the global
-* cold set to zero, we just call the driver
+* scheduling is possible, as indicate
