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)
|
>> 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.