Re: Rump dependencies (5.2)?
>> Then I think possibly the right answer for the moment is for me to >> excise rump from my tree entirely. [...] > But it seems really obvious that you should fix the rump build and > write some atf test cases for your SCM_MEMORY stuff, and then you > will be able to test it automatically. I will be testing it automatically anyway; I have a test program written with a half-dozen or so test cases already. Indeed, one of them turned up what I would call bugs in the pre-changes system, which apparently exist in later systems too: stressing SCM_RIGHTS through one socket leads to _something_ breaking unrelated processes' use of SCM_RIGHTS - I think I wrote here about a test program, which, incidentally, I have now improved to ignore SIGPIPE, so it should complain when broken pipes are the symptom. (Also, it appears 4.0.1 is not vulnerable; the misbehaviour does not occur for me there.) It is not worth the time and headache, to me, to * learn how ATF works enough to write and run test cases (something is broken with its documentation on my machines, though I don't know who's to blame; man -k shows ATF(7), but man 7 ATF says no such page exists); * figure out how to fix the places where it doesn't work for me (experience says there will be at least a few, quite possibly involving showstoppers like expecting perl or the like to be installed); * figure out what's involved in coaxing the dependency tree out of the scattered Makefiles (kre says this alone is significant headache) and persuading rump to build again, quite possibly demanding a redesign of the kernel code... when I will be building (and to some extent have already built) automated test cases anyway, test cases that don't depend on rump and actually test the real thing, and I expect the chance anyone else is interested is zero to a fairly good approximation. (Is even SCM_MEMORY enough to get anyone interested in running my mutant 5.2? And if someone ports it to something newer, any rump fixes I do will need changing and/or redoing anyway.) If anyone else does want to do the above, great. I'll be happy to help to the extent that I'm competent to. But that is unlikely to include dealing with the rump side of it. /~\ 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 dependencies (5.2)?
Mouse writes: >> The rump build is done with separate reachover makefiles. [...] > > Hm. Then I think possibly the right answer for the moment is for me to > excise rump from my tree entirely. I can't recall ever wanting its > functionality, and trying to figure out what the dependency graph is > when it exists only implicitly in Makefiles scattered all over the tree > sounds like a recipe for serious headaches. > > If and when it looks worth the effort, I can always back out the > removal commit and clean up the result. But SCM_MEMORY looks like the > more valuable thing for my use cases for the moment. Your tree, your call. But it seems really obvious that you should fix the rump build and write some atf test cases for your SCM_MEMORY stuff, and then you will be able to test it automatically.
Re: Rump dependencies (5.2)?
Date:Sun, 12 Jan 2020 22:36:23 -0500 (EST) From:Mouse Message-ID: <202001130336.waa17...@stone.rodents-montreal.org> | I can't recall ever wanting its functionality, It is used mostly by a lot of the ATF tests. | and trying to figure out what the dependency graph is | when it exists only implicitly in Makefiles scattered all over the tree | sounds like a recipe for serious headaches. That it is. kre
Re: Rump dependencies (5.2)?
>> But now, when I try to build the world, rump_nfs fails to link, >> citing as undefined two routines I added to uipc_usrreq.c which are >> referred to from uipc_syscalls.c. >> This leads me to ask [...] where can I get the dependency graph > The rump build is done with separate reachover makefiles. [...] Hm. Then I think possibly the right answer for the moment is for me to excise rump from my tree entirely. I can't recall ever wanting its functionality, and trying to figure out what the dependency graph is when it exists only implicitly in Makefiles scattered all over the tree sounds like a recipe for serious headaches. If and when it looks worth the effort, I can always back out the removal commit and clean up the result. But SCM_MEMORY looks like the more valuable thing for my use cases for the moment. /~\ 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 dependencies (5.2)?
> Date: Sun, 12 Jan 2020 21:56:30 -0500 (EST) > From: Mouse > > But now, when I try to build the world, rump_nfs fails to link, citing > as undefined two routines I added to uipc_usrreq.c which are referred > to from uipc_syscalls.c. > > This leads me to ask - and I realize it's possible nobody remembers the > answer, or perhaps nobody ever knew the answer: where can I get the > dependency graph the rump stuff expects the kernel sources to have, > since it clearly doesn't just work the way it does in the kernel? The rump build is done with separate reachover makefiles. See, e.g., sys/rump/librump/rumpnet/Makefile.rumpnet. In HEAD, uipc_usrreq.c appears in sys/rump/net/lib/liblocal/Makefile which provides the local socket domain, in contrast to, e.g., sys/rump/net/lib/libnetinet. Seems that in netbsd-5, uipc_usrreq.c did not appear in any part of rump.
Rump dependencies (5.2)?
I've just got something new working (a way, sibling to SCM_RIGHTS, for passing memory space between processes). I've been doing this in 5.2, because that's what I have handy. But now, when I try to build the world, rump_nfs fails to link, citing as undefined two routines I added to uipc_usrreq.c which are referred to from uipc_syscalls.c. This leads me to ask - and I realize it's possible nobody remembers the answer, or perhaps nobody ever knew the answer: where can I get the dependency graph the rump stuff expects the kernel sources to have, since it clearly doesn't just work the way it does in the kernel? /~\ 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
