It's important to note that the SHA256 hash checked against /bsd stored in /var/db each time reorder_kernel is called has no bearing on the integrity or consistency of the files present at compile-time for the next reordering in /usr/share/relink. If a signed SHA256.sig file (or two, GENERIC.sig and GENERIC.MP.sig) for all the individual link-kit objects from the 53mb kernel.tgz file embedded in base67.tgz were also present inside base67.tgz in the relink dir next to kernel.tgz, all the signatures could be verified before relinking for either GENERIC or GENERIC.MP and the objects reordered each time from either relink location would be guaranteed to be the same ones from the initial release. Then repopulating them if they are deleted in either or both locations wouldn't require reordering two kernels or maintaining two sets of uncompressed objects, if need be kernel.tgz could be extracted again for either configuration and the signatures verified before running make once on one set of objects.
On Thu, May 28, 2020, 03:57 Stuart Henderson <[email protected]> wrote: > On 2020/05/27 22:50, Connor Schech wrote: > > I compressed the GENERIC link kit with tar czf and it becomes 114MB, all > > other things being equal to what is done now. That becomes significant > for > > users with many instances or embedded devices. There are trade-offs > > involved, so to speak. > > Relinking once is already quite heavy and makes some systems unusable, > this at least applies to slower machines using the architectures with > wide hardware support in the kernel, i386 probably being the worst case > - some of the smaller arches like landisk cope better, partly because > there's less in the kernel and partly because they use ld.bfd which > uses less RAM. Extracting from tar.gz and linking twice is going to > be way too much for these. > >
