Date: Wed, 30 Jul 2008 13:26:33 +0200 From: Heiko Wundram <modelnine@modelnine.org> To: freebsd-stable@freebsd.org Subject: Re: Upcoming ABI Breakage in RELENG_7 Message-ID: <200807301326.33227.modelnine@modelnine.org> In-Reply-To: <op.ue3qb8er8527sy@82-170-177-25.ip.telfort.nl> References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807301302.52450.modelnine@modelnine.org> <op.ue3qb8er8527sy@82-170-177-25.ip.telfort.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Mittwoch, 30. Juli 2008 13:03:34 schrieb Ronald Klop: > I think in this case (the ABI breakage) it is more nice to say: "If you > don't know what to do, you wil probably not see any problem because of > this." > The edge case of what can go wrong is so small, that you must be doing > quite specialized stuff to see breakage. In that case you would understand > what is going on. (IMHO) Err, no. As someone else has already noted, a prominent KLM that's distributed separately from the kernel which uses the vnode structure extensively (which I didn't think of at all until I read the respective mail) is fuse. A pre-upgrade compiled fuse is most certainly going to break because of this change. Some people have dual installations of Windows/FreeBSD (at least I'd presume that's the case with the fiddlers like me that track -STABLE as a hobby, not as a developer, or those developers who program for Windows as a day-job, also like me) who use ntfs-3g to mount their NTFS-data; additionally, I also extensively use ssh-fs, which is also fuse-based, and I guess there are also others who use it, and so the reach of this ABI-change, at least IMHO, is much larger than the original message makes you believe. Now, after the update, a lot can go wrong, because the fuse KLM is loaded by an init-script, and your system is most probably going to Oops while booting if you didn't think of disabling the fuse init-script before you update your kernel, and will NOT fail "gracefully". If the respective person doesn't know how he/she should boot to single-user-mode, update rc.conf to disable this, reboot, rebuild the module to get the system back up, the only thing I can possibly say is: "don't track stable." It might've sounded a bit harsh what I wrote, but tracking -STABLE means knowing your system enough so that you know how to fix things if they come back to bite you (especially after getting a HEADS UP). And that doesn't seem to be the case here if the respective person asks for SPECIFIC instructions what to do. So, again: DON'T track -STABLE if you can't fix the system if it breaks, and AFAICT this change is most certainly going to break quite a few systems. -- Heiko Wundram
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807301326.33227.modelnine>