Date: Wed, 30 Jul 2008 12:36:35 +0300 From: "Vlad GALU" <dudu@dudu.ro> To: "David Southwell" <david@vizion2000.net> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Upcoming ABI Breakage in RELENG_7 Message-ID: <ad79ad6b0807300236g44bbc0bl1e14345f3fb030aa@mail.gmail.com> In-Reply-To: <200807300247.34948.david@vizion2000.net> References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807300247.34948.david@vizion2000.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/30/08, David Southwell <david@vizion2000.net> wrote: > On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: > > Normally the FreeBSD Project tries very hard to avoid ABI breakage in > > "Stable Branches". However occasionally the fix for a bug can not be > > implemented without ABI breakage, and it is decided that the fix > > warrants the impact of the ABI breakage. We have one of those > > situations coming along for RELENG_7 (what will become FreeBSD 7.1). > > The ABI breakage should only impact kernel modules that are not part of > > the baseline system (those will be patched by the MFC) which deal with > > advisory locks. As such the impact should not cause many people > > problems. > > > > The work that will be MFCed fixes issues with filesystem advisory locks, > > and moves the advisory locks list from filesystem-private data > > structures into the vnode structure. > > > > The MFC will be done by Kostantin Belousov some time this coming Friday > > (August 1st, 2008) if you have concerns and want to watch for it. > > > > Thanks. > > Sometimes information gets posted to this list on the assumption that everyone > understand what the writer means. > > This is one of those occasions!! > > For those of us who are not as well informed and experienced as others could > someone please explain what is meant by an ABI breakage, its implications > and how to deal with them. > ABI breakage occurs when internal data structures change (for instance, when members of the structure are removed or added). Kernel modules which expect those structures to look in a certain way will need to be recompiled. Also, depending on what data structures suffer the changes, ioctl() operations may fail, requiring a rebuild of the userland programs which issue the ioctl()s. And I'm sure that there are many other examples that I can't think of right now :) -- ~/.signature: no such file or directory
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ad79ad6b0807300236g44bbc0bl1e14345f3fb030aa>