On Sat, 2003-06-07 at 10:13, Poul-Henning Kamp wrote: > In message <20030606221137.44110.qmail_at_web13504.mail.yahoo.com>, David Yeske writes: >> imgact_gzip.c seems to be pretty stale. Has anyone considered fixing this? If this were fixed >> then kldload() / linker_load_module() could deal with a gzipped .ko file, and gzipped elf >> executables would work also? > > At least originally imgact_gzip.c was heavily a.out aware. Interesting. Making imgact_gzip elf-aware would not make the kernel capable of loading gzipped modules, only executables. There's a separate link_elf.c that the kernel uses for linking ELF images into itself (rather than activating ELF executables at exec() time, with imgact_elf) I've been fiddling a little with compressed data in the kernel already, and was able to hack together a patch for link_elf pretty quickly. The "quickly" means that there's no boot loader support, and the gzip handling is quite braindamaged, extracting the entire zipped file into allocated memory before parsing the ELF structure. This is mainly because the ELF parsing bits of link_elf assume they can make random access to the file. It'd take a bit of rework to make it work with a serial data stream. The whole thing's very rough around the edges, but I can gzip most of /boot/kernel/*.ko, and load the gzipped versions. I can polish this up, and/or add gzipped executable support, if there's any interest in reviewing or committing it. The patch adds "GZLOADER" and "INFLATE" options for the kernel, removing "GZIP" (which was busted anyway, and considered "inflate.c" to be part of the ELF support, while it's pretty much a standalone decompressor.) There's a "COMPAT_GZAOUT" option added, but it's just as bust as GZIP was before. E&OE. Patch may crash your kernel, delete your data, make your cat unwell, etc. Cheers, Peter.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:11 UTC