Re: Another option issue [was Re: Rump makes the kernel problematically brittle]
>> Of course, it's entirely possible nobody remembers enough from far >> enough back > I don't remember much from as far back as yesterday, :-) > but what failed was the XEN Dom0 kernel build (well, the "make > depend" for that). You say you added things to > sys/arch/amd64/amd64/machdep.c which makes me wonder if (back then) > something needed to be added in a similar place in > sys/arch/xen/somewhere Possibly. Following up on some off-list email, I've discovered that files.amd64, where I added the defparam line, is inside "ifdef xen"..."endif". This seems to reinforce what you just said. HOWEVERso is the defparam line for opt_realmem.h, another of the .h files included in that block of unconditional #include lines in amd64/machdep.c. And, spot-checking a third include file, there's opt_cpureset_delay.h among the #includes, and the only files in all of /usr/src that include the string "cpureset_delay" are sys/arch/amd64/amd64/machdep.c and sys/arch/i386/i386/machdep.c, so I have no idea what makes config generate opt_cpureset_delay.h. I clearly need to dig deeper. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Another option issue [was Re: Rump makes the kernel problematically brittle]
Date:Sat, 4 Apr 2020 12:59:54 -0400 (EDT) From:Mouse Message-ID: <202004041659.maa21...@stone.rodents-montreal.org> | I added the #include to a long string of #include "opt_h" lines, | none of which are conditional on anything, in | sys/arch/amd64/amd64/machdep.c. | Of course, it's entirely possible nobody remembers enough from far | enough back I don't remember much from as far back as yesterday, but what failed was the XEN Dom0 kernel build (well, the "make depend" for that). You say you added things to sys/arch/amd64/amd64/machdep.c which makes me wonder if (back then) something needed to be added in a similar place in sys/arch/xen/somewhere kre
Re: Another option issue [was Re: Rump makes the kernel problematically brittle]
I wrote about build.sh release failing. Someone (again off-list)
pointed out that I didn't really give enough information. And, this
time, the change is small.
So, here is the changeset in question:
commit e1f85bf071f6fcc167b5266da1db35c3ee9a8969
Author: Mouse
Date: Wed Oct 17 13:17:47 2018 -0400
Add `options HALTED_MESSAGE' to control what's printed on halt.
diff --git a/sys/arch/amd64/amd64/machdep.c b/sys/arch/amd64/amd64/machdep.c
index a21a084..a9e7011 100644
--- a/sys/arch/amd64/amd64/machdep.c
+++ b/sys/arch/amd64/amd64/machdep.c
@@ -127,6 +127,7 @@ __KERNEL_RCSID(0, "$NetBSD: machdep.c,v 1.102.4.14
2012/06/12 23:18:13 riz Exp $
#include "opt_lockdebug.h"
#include "opt_mtrr.h"
#include "opt_realmem.h"
+#include "opt_halted_message.h"
#include "opt_xen.h"
#ifndef XEN
#include "opt_physmem.h"
@@ -732,9 +733,13 @@ haltsys:
AcpiDisable();
#endif
+#ifdef HALTED_MESSAGE
+ printf("%s",HALTED_MESSAGE);
+#else
printf("\n");
printf("The operating system has halted.\n");
printf("Please press any key to reboot.\n\n");
+#endif
cnpollc(1); /* for proper keyboard command handling */
cngetc();
cnpollc(0);
diff --git a/sys/arch/amd64/conf/files.amd64 b/sys/arch/amd64/conf/files.amd64
index 923ad4f..19df2cd 100644
--- a/sys/arch/amd64/conf/files.amd64
+++ b/sys/arch/amd64/conf/files.amd64
@@ -12,6 +12,8 @@ maxpartitions 16
maxusers 2 16 128
+defparam opt_halted_message.h HALTED_MESSAGE
+
# delay before cpu_reset() for reboot.
defparam CPURESET_DELAY
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Another option issue [was Re: Rump makes the kernel problematically brittle]
>> Yes, I got a very nice and helpful off-list mail (thank you!) >> saying, approximately, that I needed to have the #include of >> opt_autoconf.h inside the _KERNEL_OPT conditional. > As you guessed, that was the issue I suspected. Okay, I've now tried something I rarely try - build.sh release - and have another, related, question. Admittedly, though, it's for an old release. This was for 5.2, and build.sh release on amd64 failed. It appears to come from my adding another option file, opt_halted_message.h, in support of an option to allow a kernel config to provide a replacement for the "halted, press any key to reboot" message. This has worked fine for build.sh build runs. But this build.sh release run failed release ===> etc (with: DISTRIBUTION_DONE=1) [...] #create XEN3_DOM0/machdep.d CC=/home/mouse/amd64/OBJDIR/tooldir.NetBSD-5.2-amd64/bin/x86_64--netbsd-gcc /home/mouse/amd64/OBJDIR/tooldir.NetBSD-5.2-amd64/bin/nbmkdep -f machdep.d -- -mcmodel=kernel -mno-red-zone -ffreestanding -fno-zero-initialized-in-bss -g -O2 -fno-omit-frame-pointer -std=gnu99 -fno-strict-aliasing -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-sign-compare -Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter -Werror-Damd64 -Dx86_64 -I. -I/home/mouse/amd64/OBJDIR/sys/arch/amd64/compile/XEN3_DOM0/xen-ma -I/usr/src/sys/../common/include -I/usr/src/sys/arch -I/usr/src/sys -nostdinc -DMSGBUFSIZE="24576" -DLKM -DDIAGNOSTIC -DDEBUG -DMAXUSERS=32 -D_KERNEL -D_KERNEL_OPT -I/usr/src/sys/lib/libkern/../../../common/lib/libc/quad -I/usr/src/sys/lib/libkern/../../../common/lib/libc/string -I/usr/src/sys/lib/libkern/../../../common/lib/libc/arch/x86_! 64/string -I/usr/src/sys/external/isc/atheros_hal/dist -I/usr/src/sys/external/isc/atheros_hal/ic -I/usr/src/sys/dist/ipf /usr/src/sys/arch/amd64/amd64/machdep.c /usr/src/sys/arch/amd64/amd64/machdep.c:130:32: error: opt_halted_message.h: No such file or directory I added the #include to a long string of #include "opt_h" lines, none of which are conditional on anything, in sys/arch/amd64/amd64/machdep.c. Of course, it's entirely possible nobody remembers enough from far enough back to say anythng useful. But, if anyone does, I'd appreciate any pointers to what I might have done wrong or where to look to fix this. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Rump makes the kernel problematically brittle
Thor Lancelot Simon writes: > I'd love to see a GSoC project to actually make rump build like the > kernel...but it may be too much work. Good points, and improvement would be great.
Re: Rump makes the kernel problematically brittle
On Thu, Apr 02, 2020 at 04:16:35PM -0400, Greg Troxel wrote: > The other side of the coin to "rump is fragile" is "an operating system > without rump-style tests that can be run automatically is suscpetible to > hard-to-detect failures from changes, and is therefore fragile". There > have been many instances (usually on current-users, I think) of reports > of newly-failing tests cases, leading to rapid removal of > newly-introduced defects. I have to say I have always found rump a major impediment to kernel development. I chalk this up to one problem with rump, and one problem only, but it is a problem so serious to this day I feel core should not have allowed rump to be committed to HEAD without it being definitively resolved. The problem is that rump duplicates the entire kernel configuration and build framework -- poorly. Rump builds more like v7 did than like modern BSD, and this means that any code added to the kernel typically has to be fitted into not one build system but two. This just plain sucks. It is shoddy. It is definitely the case that rump is a huge technical accomplishment that enables us to do really cool things - with testing, with userspace network stacks, and more. But it is tremendously unfortunate that it was checked into our tree before it was ready, and has remained that way ever since. I'd love to see a GSoC project to actually make rump build like the kernel...but it may be too much work. Thor -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand up for human rights because it will work, but because it is right." --Andrei Sakharov
Re: Rump makes the kernel problematically brittle
On Thu, Apr 02, 2020 at 23:29:55 +0300, Valery Ushakov wrote: > On Thu, Apr 02, 2020 at 16:15:30 -0400, Mouse wrote: > > > > http://www.fixup.fi/misc/rumpkernel-book/ > > > > That page I can look at fine, but when I try to fetch the PDF, I get a > > 403 Forbidden. In case it helps anyone, the body says > > > > Code: AccessDenied > > Message: Access Denied > > RequestId: CE223007341C4B9F > > HostId: > > iIeEi7wGEkGET4V/Pw2ndjkjrChsKswcqoLJJpmExJOrqdRFFgHw6L6XWjB2ZSNqBTTXyPHJYMI= > > Works with firefox. It porbably needs javascript or cookies or > whatever. It wants a referrer. Go to that page with lynx and you can download the pdf by following the link. -uwe
Re: Rump makes the kernel problematically brittle
>> (While I recognize you may not be the person to say this to, denying >> access like that without any indication of what the problem is or >> whom to ask for help is...singularly useless.) > This is so *richly* ironic coming from you :) I've given up trying > to send you personal mail years ago. Odd, I thought all my rejections indicated the basis for the rejection. I also think mail to postmaster@ should get through from all but the very worst offenders (the only one I can think of offhand that I'm sure gets blocked so hard even postmaster won't work is Google). > No, please, don't answer that, I'm no longer interested. Well, too late in one sense; I've already written the above four lines. But if you don't care any longer, then, shrug. > Re whom to contact, there's a contact email literally right beneath > that link. Not sure if your MX will agree to accept the reply > though. :) Oh, on _that_ page - oh, pooka, cool! I don't recall whether I've got mail from pooka in the past or not. I'll drop a note thataway. > PS: Sorry, I still can't stop giggling... > PPS: Sorry... :) > PPPS: *giggle* Well, I'm glad I can provide your day's amusement... :-> And I suppose to be fair I should try - should have tried - webmas...@www.fixup.fi before maundering about not saying whom to contact. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Rump makes the kernel problematically brittle
On Thu, Apr 02, 2020 at 16:15:30 -0400, Mouse wrote: > > http://www.fixup.fi/misc/rumpkernel-book/ > > That page I can look at fine, but when I try to fetch the PDF, I get a > 403 Forbidden. In case it helps anyone, the body says > > Code: AccessDenied > Message: Access Denied > RequestId: CE223007341C4B9F > HostId: > iIeEi7wGEkGET4V/Pw2ndjkjrChsKswcqoLJJpmExJOrqdRFFgHw6L6XWjB2ZSNqBTTXyPHJYMI= Works with firefox. It porbably needs javascript or cookies or whatever. > (While I recognize you may not be the person to say this to, denying > access like that without any indication of what the problem is or whom > to ask for help is...singularly useless.) This is so *richly* ironic coming from you :) I've given up trying to send you personal mail years ago. No, please, don't answer that, I'm no longer interested. Re whom to contact, there's a contact email literally right beneath that link. Not sure if your MX will agree to accept the reply though. :) PS: Sorry, I still can't stop giggling... PPS: Sorry... :) PPPS: *giggle* -uwe
Re: Rump makes the kernel problematically brittle
The other side of the coin to "rump is fragile" is "an operating system without rump-style tests that can be run automatically is suscpetible to hard-to-detect failures from changes, and is therefore fragile". There have been many instances (usually on current-users, I think) of reports of newly-failing tests cases, leading to rapid removal of newly-introduced defects.
Re: Rump makes the kernel problematically brittle
> http://www.fixup.fi/misc/rumpkernel-book/ That page I can look at fine, but when I try to fetch the PDF, I get a 403 Forbidden. In case it helps anyone, the body says Code: AccessDenied Message: Access Denied RequestId: CE223007341C4B9F HostId: iIeEi7wGEkGET4V/Pw2ndjkjrChsKswcqoLJJpmExJOrqdRFFgHw6L6XWjB2ZSNqBTTXyPHJYMI= (While I recognize you may not be the person to say this to, denying access like that without any indication of what the problem is or whom to ask for help is...singularly useless.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Rump makes the kernel problematically brittle
> Since you're just using an #ifndef that should be all that's needed, > for this issue anyway. Yes, the build is now up to some 80 megs of logfile. Since the previous failure was before 50 megs, I think this issue is fixed. Thank you all very much! As for the 5.2 issue, I checked out the tree just before I cut rump out of the build and test-built it. It failed with "warning: pointer targets [...] differ in signedness" during the rump build of uipc_syscalls.c, a warning which does not occur during a real kernel build, probably because the real build passes -Wmo-pointer-sign but the rump build does not. I'm not sure what I think of that. The types in question are unsigned char * and char *, which complicates it in that character types have a bunch of semi-magic properties. Further complicating it is that the actual argument CMSG_DATA(...), which IMO should be void * (well, actually, IMO CMSG_DATA() should not exist, at least not in its current form, but that's a separate kettle of rants). >> Is this documented anywhere? > You're putting documented and rump into the same thought space? Since it affects building the world after making kernel changes not directly related to rump, yes, I think it should be documented, even if only in the form of "if rump gets uppity, build with -no-rump" or whatever, instead of having to touch some 15 or 20 files (my removal touched 252 files, but that includes entirely removing a lot of rump-specific files). Alternatively, and maybe preferably, a failure in rump should not fail a build, at least not unless such failures were specifically requested. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Rump makes the kernel problematically brittle
On Fri, Apr 03, 2020 at 02:23:31 +0700, Robert Elz wrote: > | Is this documented anywhere? > > You're putting documented and rump into the same thought space? http://www.fixup.fi/misc/rumpkernel-book/ -uwe
Re: Rump makes the kernel problematically brittle
Date:Thu, 2 Apr 2020 14:54:13 -0400 (EDT) From:Mouse Message-ID: <202004021854.oaa20...@stone.rodents-montreal.org> | Yes, I got a very nice and helpful off-list mail (thank you!) saying, | approximately, that I needed to have the #include of opt_autoconf.h | inside the _KERNEL_OPT conditional. As you guessed, that was the issue I suspected. Since you're just using an #ifndef that should be all that's needed, for this issue anyway. | Is this documented anywhere? You're putting documented and rump into the same thought space? kre
Re: Rump makes the kernel problematically brittle
> Perhaps. I'd actually like to see the diff for this (related) one ... > usr/src/sys/kern/subr_autoconf.c > Include "opt_autoconf.h" and implement NO_DETACH_MESSAGES, to > suppress device-detached console spammage on shutdown. > as that's clearly where the problem occurs. Here you are. But see below, too. diff --git a/usr/src/sys/kern/subr_autoconf.c b/usr/src/sys/kern/subr_autoconf.c index b9aa7c8..05f6dac 100644 --- a/usr/src/sys/kern/subr_autoconf.c +++ b/usr/src/sys/kern/subr_autoconf.c @@ -83,6 +83,7 @@ __KERNEL_RCSID(0, "$NetBSD: subr_autoconf.c,v 1.253 2017/06/01 02:45:13 chs Exp #include "opt_ddb.h" #include "drvctl.h" #endif +#include "opt_autoconf.h" #include #include @@ -1812,8 +1813,10 @@ config_detach(device_t dev, int flags) } } +#ifndef NO_DETACH_MESSAGES if (dev->dv_cfdata != NULL && (flags & DETACH_QUIET) == 0) aprint_normal_dev(dev, "detached\n"); +#endif out: config_alldevs_enter(&af); > Rump doesn't do kernel options the wame way the kernel does, and care > needs to be taken when adding op_*.h includes as those files won't > generally exist in the rump universe. Yes, I got a very nice and helpful off-list mail (thank you!) saying, approximately, that I needed to have the #include of opt_autoconf.h inside the _KERNEL_OPT conditional. I've now moved it and have a build running. Hasn't failed so far, but it hasn't been long enough for that to mean much yet. Is this documented anywhere? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Rump makes the kernel problematically brittle
Date:Thu, 2 Apr 2020 12:45:35 -0400 (EDT) From:Mouse Message-ID: <202004021645.maa22...@stone.rodents-montreal.org> | But the error makes me reasonably sure it's related to the defflag I | added to files.kern. Perhaps. I'd actually like to see the diff for this (related) one ... usr/src/sys/kern/subr_autoconf.c Include "opt_autoconf.h" and implement NO_DETACH_MESSAGES, to suppress device-detached console spammage on shutdown. as that's clearly where the problem occurs. Rump doesn't do kernel options the wame way the kernel does, and care needs to be taken when adding op_*.h includes as those files won't generally exist in the rump universe. kre
Rump makes the kernel problematically brittle
I've got two 8.0 machines at work. I just did a build-of-the-world on them. They both failed, and at the same spot. This is not all that surprising, since I checked that /usr/src and /usr/xsrc were identical between the two, but it does mean that it probably is not something like a fluke timestamp glitch. It appears to be something wrong with rump and its reaction to a kernel change - see below. In each case, the build was done as me, a nonprivileged user, using (cd /usr/src && sh ./build.sh -D /home/mouse/amd64/DESTDIR -O /home/mouse/amd64/OBJDIR -x -U build) with stdout and stderr redirected to a logfile. (The -D and -O directories were pre-created manually, starting out empty; as the names imply, this is all on amd64.) The logfiles are nearly 50 megs, so posting them here directly is, I think, counterindicated. Once I sed out the timestamps generated by build.sh (sed -e "s/Thu Apr 2 ..:..:../Thu Apr 2 xx:xx:xx/"), the build logs for the two machines are bit-identical. They end with dependall ===> lib/librumpdev /home/mouse/amd64/OBJDIR/tooldir.NetBSD-8.0-amd64/bin/nbconfig -b /home/mouse/amd64/OBJDIR/lib/librumpdev -s /usr/src/sys /usr/src/lib/librumpdev/../../sys/rump/librump/rumpdev/MAINBUS.ioconf touch ioconf.c ioconf.h locators.h #create librumpdev/autoconf.d [...] #create librumpdev/dev_verbose.d [...] #create librumpdev/ioconf.d [...] #create librumpdev/kern_pmf.d [...] #create librumpdev/rump_dev.d [...] #create librumpdev/subr_autoconf.d CC=/home/mouse/amd64/OBJDIR/tooldir.NetBSD-8.0-amd64/bin/x86_64--netbsd-gcc /home/mouse/amd64/OBJDIR/tooldir.NetBSD-8.0-amd64/bin/nbmkdep -f subr_autoconf.d.tmp -- -std=gnu99 -I/usr/src/lib/librumpdev/../../sys/rump/librump/rumpkern --sysroot=/home/mouse/amd64/DESTDIR -DCOMPAT_50 -DCOMPAT_60 -DCOMPAT_70 -nostdinc -imacros /usr/src/lib/librumpdev/../../sys/rump/include/opt/opt_rumpkernel.h -I/usr/src/lib/librumpdev -I. -I/usr/src/lib/librumpdev/../../sys/rump/../../common/include -I/usr/src/lib/librumpdev/../../sys/rump/include -I/usr/src/lib/librumpdev/../../sys/rump/include/opt -I/usr/src/lib/librumpdev/../../sys/rump/../arch -I/usr/src/lib/librumpdev/../../sys/rump/.. -DDIAGNOSTIC -DKTRACE -D_FORTIFY_SOURCE=2 /usr/src/lib/librumpdev/../../sys/rump/../kern/subr_autoconf.c && mv subr_autoconf.d.tmp subr_autoconf.d /usr/src/lib/librumpdev/../../sys/rump/../kern/subr_autoconf.c:86:26: fatal error: opt_autoconf.h: No such file or directory compilation terminated. nbmkdep: compile failed. *** Failed target: subr_autoconf.d [...cascade of nested make failures, ending with...] ERROR: Failed to make build *** BUILD ABORTED *** I do have changes as compared to stock 8.0 source, but not much, mostly hardware driver changes. The full list of affected files and how they're touched (I can provide full diffs if relevant): usr/src/distrib/sets/lists/comp/mi Get three hardware .h files (below) installed in /usr/include. usr/src/sys/conf/files Add a defflag for an option added to com.c (below). usr/src/sys/conf/majors Add a device-major for the 7300 driver (below). usr/src/sys/dev/ic/Makefile Install two of the three .h files (lptioc.h and lptreg.h). usr/src/sys/dev/ic/com.c Add the ability to delay output by a userland-configurable time. usr/src/sys/dev/ic/lpt.c usr/src/sys/dev/ic/lptioc.h usr/src/sys/dev/ic/lptreg.h usr/src/sys/dev/ic/lptvar.h Give it a mode that's "parallel port" instead of "printer interface", including some custom tweaks for the use case. usr/src/sys/dev/pci/7300a-reg.h usr/src/sys/dev/pci/7300a.c usr/src/sys/dev/pci/7300a.h A driver for the Adlink 7300A (depressingly heavily customized for the use case, but still...). usr/src/sys/dev/pci/Makefile Install the third .h file (7300a.h). usr/src/sys/dev/pci/files.pci Add the 7300 driver. usr/src/sys/dev/pci/if_wm.c Add some debugging kludgery. usr/src/sys/dev/pci/ixgbe/ix_txrx.c Make it build when neither INET nor INET6 is enabled. usr/src/sys/dev/pci/pucdata.c Add the NetMos NM9912. usr/src/sys/dev/usb/usb_subr.c Print something more informative than just "device problem" when having difficulty with a device. usr/src/sys/kern/files.kern Add "defflag opt_autoconf.h NO_DETACH_MESSAGES". usr/src/sys/kern/subr_autoconf.c Include "opt_autoconf.h" and implement NO_DETACH_MESSAGES, to suppress device-detached console spammage on shutdown. usr/src/sys/net/if_loop.c Make it build when neither INET nor INET6 is enabled. usr/xsrc/external/mit/xorg-server/dist/hw/xfree86/common/xf86Init.c usr/xsrc/external/mit/xorg-server/dist/hw/xfree86/vbe/vbe.c Add options to the X server to deal with some DDC issues (-ddc-capture, to record DDC info, and -ddc-fallback, to provide DDC info to be used when the server can't obtain any on startup
