SRFI 176: Version flag Arthur A. Gleckler (07 Oct 2019 05:01 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 18:43 UTC)
Re: SRFI 176: Version flag Lassi Kortela (07 Oct 2019 20:26 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 20:50 UTC)
Re: SRFI 176: Version flag Lassi Kortela (07 Oct 2019 21:42 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 22:49 UTC)
Re: SRFI 176: Version flag Lassi Kortela (11 Oct 2019 23:40 UTC)
Re: SRFI 176: Version flag Arthur A. Gleckler (13 Oct 2019 03:40 UTC)
Re: SRFI 176: Version flag John Cowan (13 Oct 2019 04:23 UTC)
Re: SRFI 176: Version flag Arthur A. Gleckler (13 Oct 2019 04:53 UTC)
Re: SRFI 176: Version flag John Cowan (15 Oct 2019 12:20 UTC)
Storing manual pages and other data in executables Lassi Kortela (16 Oct 2019 20:39 UTC)
Re: Storing manual pages and other data in executables John Cowan (16 Oct 2019 21:36 UTC)
Re: SRFI 176: Version flag Shiro Kawai (13 Oct 2019 05:24 UTC)
Storing manual pages and other data in executables Lassi Kortela (14 Oct 2019 11:56 UTC)
Re: Storing manual pages and other data in executables John Cowan (14 Oct 2019 16:33 UTC)
Re: Storing manual pages and other data in executables Lassi Kortela (17 Oct 2019 17:06 UTC)
Gory details of parsing Lassi Kortela (07 Oct 2019 21:04 UTC)
Re: Gory details of parsing John Cowan (07 Oct 2019 23:05 UTC)
Re: Gory details of parsing Lassi Kortela (11 Oct 2019 23:50 UTC)
Re: Gory details of parsing John Cowan (15 Oct 2019 01:52 UTC)
Working out the platform and compiler info Lassi Kortela (14 Oct 2019 16:52 UTC)
Clarification of tuples Lassi Kortela (14 Oct 2019 17:09 UTC)
Re: Working out the platform and compiler info John Cowan (14 Oct 2019 18:07 UTC)

Re: Storing manual pages and other data in executables Lassi Kortela 17 Oct 2019 17:06 UTC

>> ELF files have support for sections that are not loaded into the runtime
>> program image by the kernel.
>
> Correct.  The difficulties are social and not technical.  The tools you
> would need to extract such things conveniently, elftar(1) or mount-elf (1)
> and accompanying libraries don't exist and probably wouldn't be much used,
> thus would tend to be buggy.

I would explore other options before going for a tar archive or a file
system image. Those consist almost entirely of file metadata and
geometry/structural info that are not needed inside an ELF file.

All you really need is a (pathname data-offset data-size) tuple for each
file. Both random and ordered reads need to be fast; writes can be slow.

A prefix tree could be a good data structure for the index. Those
support fast random access and fast in-order traversal while retaining
good worst-case performance. They are also space-efficient since the
pathname prefix of each node is stored implicitly in its parent nodes,
not the full pathname in each leaf node.