Means of accessing private functions

[n0toose]

Right now, there are three functions which are exposed to dependants of hermit-entry: parse, hermit_version, mem_size and load_kernel.

Internal functions that parse information from Hermit unikernel images (i.e. entry_point, is_relocatable) have their uses for developers as well - and could be broken into a separate crate that normal users are not supposed to use. This could be eventually solved using packages as namespaces (see rust-lang/rfcs#3452), or by following a uhyve-interface approach.

They can be useful for experiments like developing programs meant to parse and analyze Hermit images to aid debugging (see this Uhyve wiki entry - sorry for any mistakes in advance) or me getting confused during an analysis of Uhyve's Hermit images). Additionally, they could be useful for drafting complex test cases more quickly as well (see #51).

[n0toose]

I'd expect that this issue could be closed, as all of the potential use cases I mentioned above are not necessarily "blockers" themselves. Nevertheless, I do think that they could save future time and effort.

[jounathaen]

Couldn't these use cases be solved more easily by making entry_point() and is_relocatable() pub? I don't really see any advantage in breaking this crate down.

[n0toose]

I don't really see any advantage in breaking this crate down.

Yes, this is a KISS approach of doing it.

However, I presumed that because this project is first and foremost an entry/loading API and not a special ELF inspection API (which guarantees stability), the choice not to make the functions pub was deliberate design.

For instance, is_relocatable should not be invoked by Uhyve directly, thus keeping it private makes sense in a way:

hermit-entry/src/elf.rs

Lines 342 to 348 in a9a826b

	fn entry_point(&self, start_addr: u64) -> u64 {
	let mut entry_point = self.header.e_entry;
	if self.is_relocatable() {
	entry_point += start_addr;
	}
	entry_point
	}

... but it would be great - although not a must - if we could use functions like is_relocatable or tls_info.

[n0toose]

I don't really see any advantage in breaking this crate down.

sorry, the crate suggestion was overengineered... one could simply use a different module that one has to explicitly import as well

[mkroening]

Which functions do you need exactly and why? Non-relocatable images are deprecated and to be removed in future versions.

The scope of this crate is providing a way of loading and entering a Hermit image. I am cautious about generic ELF inspection APIs, which might be better used through crates like elf or goblin instead.

[n0toose]

The scope of this crate is providing a way of loading and entering a Hermit image. I am cautious about generic ELF inspection APIs, which might be better used through crates like elf or goblin instead.

Yeah, I was also under the same impression - I wouldn't otherwise want to turn a loader into an ELF inspector either. I believe I distracted from the central point by talking about solutions, so I'll restart and take a few steps back:

• It would be good if hermit-entry had unit tests: Add unit tests #51 (I believe this step is not controversial)
• In pursuit of that goal, it could make sense to separate some functionality (i.e. the general compatibility checks in parse) by moving them into different functions/units.
• Beyond unit tests, I'd propose something further: One could consider putting them in a separate namespace that apps like Uhyve are not supposed to use, without any backwards compatibility guarantees.

My primary arguments aren't strong: Debuggers exist, tests can use private functions. On the other hand, why not? Modularization is adjacent to existing goals, and it might help time-wise (less code copy-pasting when not needed, less local fork maintenance, easier experimentation). Implicitly, hermit-entry specifies how a Hermit unikernel ELF image is expected to look like and what we infer from it (TLS info, is relocatable, is a Hermit unikernel, Hermit version). This is useful (e.g. "What is Uhyve working with, and under which superficial parameters?"), but it's hidden behind an internal state.