allyes, or enterprise distro kernels. I don't think we can really call them 'reasonable' either (2000+ modules, great ghu). Still, the enterprise distro people can surely do 64->32-bit cross-compilation.
Posted Aug 22, 2012 13:21 UTC (Wed) by nix (subscriber, #2304)
[Link]
And of course as soon as I post this I realise that having heaps of modules will pose no problem at all: LTO doesn't run over those and the kernel as a unit. I wish LWN let me delete things I posted for a few minutes after posting them...
On LTO builds with 32bit compilers.
Posted Aug 22, 2012 13:34 UTC (Wed) by andikleen (subscriber, #39006)
[Link]
Distro modular kernels should be ok, each module is LTOed on its own and the vmlinux is not too big. The limit is only the largest binary.
That said I haven't actually tried it with a 32bit compiler. Testing welcome.
On LTO builds with 32bit compilers.
Posted Aug 22, 2012 18:25 UTC (Wed) by dlang (✭ supporter ✭, #313)
[Link]
This will create yet another advantage to having a monolithic kernel instead of using dozens of modules for your basic functions.
On LTO builds with 32bit compilers.
Posted Aug 24, 2012 15:49 UTC (Fri) by malor (subscriber, #2973)
[Link]
Do monolithic kernels even work anymore? Back in the Stone Age, I used to compile my kernels statically to prevent module-load hacks, but as I recall, that support was mostly removed... my memory is unclear, but I under the impression that it was no longer really possible to run Linux without using loadable modules.
Is that incorrect? Are static kernels actually reasonably possible?
On LTO builds with 32bit compilers.
Posted Aug 24, 2012 16:12 UTC (Fri) by mjg59 (subscriber, #23239)
[Link]
They are, there's just little reason to use them - especially since you'll probably need to build in any loadable firmware, which may make the result undistributable.
On LTO builds with 32bit compilers.
Posted Aug 24, 2012 23:01 UTC (Fri) by dlang (✭ supporter ✭, #313)
[Link]
that depends on the firmware on on your interpretation of the requirements for source for that firmware.
I haven't seen anyone sued for the source of a firmware blob if the firmware blob itself didn't included GPL code in it. (as opposed to the firmware blob being used as data by GPL code and uploaded to a device)
A lot of the linux kernel developers consider the splitting of the firmware out of the source tree to be a waste of time from a technical and legal point of view, but they don't fight it because it shuts up the people who think that it does matter from a legal point of view.
besides, the GPL only comes in to play when you distribute the resulting binary. There's a huge amount of stuff that you can do (especially in a large company) without triggering this.
On LTO builds with 32bit compilers.
Posted Aug 25, 2012 4:44 UTC (Sat) by mjg59 (subscriber, #23239)
[Link]
"Which may make the result undistributable" - you appear to have just spent several paragraphs agreeing with me. What was your point?
On LTO builds with 32bit compilers.
Posted Aug 25, 2012 5:06 UTC (Sat) by dlang (✭ supporter ✭, #313)
[Link]
Ok, "MAY" make the result undistributable, heavy emphasis and lots of doubt on the word MAY
There are a LOT of people who don't think it would.
Also, even if it did, it wouldn't matter for lots of people, because they don't distribute the resulting binaries.