Messages in this thread | | | Date | Mon, 8 Feb 2021 14:03:27 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: Linux 4.9.256 |
| |
On Mon, Feb 08, 2021 at 01:57:12PM +0100, Florian Weimer wrote: > * Greg Kroah-Hartman: > > > I'm announcing the release of the 4.9.256 kernel. > > > > This, and the 4.4.256 release are a little bit "different" than normal. > > > > This contains only 1 patch, just the version bump from .255 to .256 which ends > > up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently > > than normal due to the "overflow". > > > > With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0). > > > > Nothing in the kernel build itself breaks with this change, but given > > that this is a userspace visible change, and some crazy tools (like > > glibc and gcc) have logic that checks the kernel version for different > > reasons, I wanted to do this release as an "empty" release to ensure > > that everything still works properly. > > I'm looking at this from a glibc perspective. glibc took the > KERNEL_VERSION definition and embedded the bit layout into the > /etc/ld.so.cache, as part of the file format. Exact impact is still > unclear at this point.
If we "cap" this at 4, 9, 255 according to what userspace sees, will that be a problem if we increase the number reported by uname(2)?
And when is the ld.so.cache file "regenerated"?
thanks,
greg k-h
| |