On Thu, 15 Jun 2017 17:53:20 -0500 Juan Perez-Sanchez <lithoxs@xxxxxxxxx> wrote: > On Thu, Jun 15, 2017 at 5:19 AM, Edoardo <eddyx89@xxxxxxxxx> wrote: > > How much smaller? > > The current kernel with a configuration similar to the default > configuration for the 0.1.3 version, > compiled with BCC has a code size of 51216 bytes. With the new > compiler, size is 48288 bytes. > This is 2928 bytes less (5.7%). > > > If I remember correctly, one of ELKS limits was that binaries had to > > fit on a 64KB page, and that was due to the compiler we used (dev86 / > > bcc). > > Actually, code size <= 64KB and separately (data + bss + stack sizes) <= 64KB. > > > Do you think/know if GCC may solve this limit, being able to produce > > multi-page binaries? > > No, those limits still holds. For the kernel it's good enough it could do it with a few helpers. However the big kernel problem space is data (because of the stacks). If an 'export symbol' thing is added and drivers are treated like kernel modules (even if loaded together not on demand) then you can use tools to generate stubs for each module that do a far call into the kernel. You would probably need to disallow callbacks and modules calling each other because while you are sort of doing a far call you need a near call frame. Also because you'd have pointers to functions in other modules that were not far and did not a segment attached. Actually making it work is tricky but doable. I don't think it's needed however - the data segment is the only really big issue. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
