Date: Sat, 5 Jul 2008 17:15:57 -0400 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: "Alexander Sack" <pisymbol@gmail.com> Cc: Matthias Apitz <matthias.apitz@oclc.org>, freebsd-hackers@freebsd.org, guru@unixarea.de, Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> Subject: Re: kernel HEAD && userland 7.0-REL? Message-ID: <20080705171557.18f6348c@bhuda.mired.org> In-Reply-To: <3c0b01820807041938w619caa44of154de91dac1beb4@mail.gmail.com> References: <20080704124227.GA10264@rebelion.Sisis.de> <20080704164015.514425fd@bhuda.mired.org> <3c0b01820807041712l39bdafd8sf3914c2b462023c6@mail.gmail.com> <20080704202744.083436a4@bhuda.mired.org> <3c0b01820807041938w619caa44of154de91dac1beb4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 Jul 2008 22:38:04 -0400 "Alexander Sack" <pisymbol@gmail.com> wrote: > On Fri, Jul 4, 2008 at 8:27 PM, Mike Meyer <mwm@mired.org> wrote: > > On Fri, 4 Jul 2008 20:12:58 -0400 > > "Alexander Sack" <pisymbol@gmail.com> wrote: > > > >> On Fri, Jul 4, 2008 at 4:40 PM, Mike Meyer > >> <mwm-keyword-freebsdhackers2.e313df@mired.org> wrote: > >> > On Fri, 4 Jul 2008 14:42:27 +0200 > >> > Matthias Apitz <guru@unixarea.de> wrote: > >> >> I'm running a RELENG_7 kernel and a userland as 7.0-REL on one of my > >> >> laptops; I've been asked to check if a given driver problem in RELENG_7 is as > >> >> well with HEAD... can I update the kernel to HEAD and let the userland > >> >> (and all my compiled ports) as 7.0-REL; I know that this is not the > >> >> intention, but it would cost me a lot of work if I should compile as > >> >> well ~200 ports.... > >> > > >> > When you say HEAD, do you mean the HEAD of 8-CURRENT or 7-STABLE? In > >> > either case whether or not it works depends on whether something has > >> > changed in the kernel that has a required userland change. > >> > > >> > On the other hand, if you mean 7-STABLE, then the ports should work > >> > properly whether userland does or not. > >> > >> As a note, I just recently used HEAD on a 7_STABLE box to test changes > >> recently to re for an updated PCIe revision NIC card on my Eee Box. > >> It worked fine (both runtime and my NIC which I then patched my > >> 7_STABLE tree which also worked, yea!). In a thread I started about > >> cross platform building, it seems that historically FreeBSD has had a > >> very stable ABI allowing multiple kernels to run underneath different > >> versions of user land (this is certainly not the case for all *NIX > >> variants). > > > > So stable that the things that break when you try and do this have > > made it into the FAQ: > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#NLIST-FAILED > > > > Personally, I managed to try this once when the console driver needed > > a termcap entry change as well :-(. > > Oh c'mon now....if this is the worst of your problems, then you're > doing pretty darn good. I believe Linux binaries rely on the version > of glibc, an aux vec entry, and the way the kernel was actually built > to figure out whether to use syscall or int to hop into the kernel. I > mean things could be a lot worse!! :D! Sorry; I was actually agreeing with you. That it works well enough that there's a FAQ entry on the problems is a good indication that things won't be seriously broken. Nuts - they expect it to work well enough that running that way is part of the from-source upgrade process! What breaks are things in the base system that don't use the ABI, but poke around in the kernel directly, or otherwise expect to be in sync with some kernel behavior other than the ABI. However, just so the GNU/Linux people don't feel to bad, I'll note that the ABI stability really only applies to -STABLE. On -CURRENT, it changes (though I don't track -CURRENT these days, so don't know how bad things have been recently); there have been cases where the FILE * changed, meaning nothing from the old system that used stdio worked. This is why there's /usr/ports/misc/compat* - to make the old ABI available on new releases. We're still fairly close to the last split between -STABLE and -CURRENT; so it's not surprising that (as reported) it works. On the other hand, it's *not* a supported configuration, so that it works last week is at best indicative that it might work this week. There's no guarantee, and if you're left with a dead system - well, that's what you risked. The best way to try something like this is to use the nextboot utility to arrange to boot your "questionable" kernel once, as has already been suggested. That way, if it winds up totally busted, a reboot will automatically bring you back to your working kernel. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080705171557.18f6348c>