On 15/05/2014 20:43, Jorge Almeida wrote:
> If I understand correctly, it would be less efficient (I tend to use
> execve() rather than execvp() etc in my own little programs; searching
> through a path when we already know the location of the binaries is
> not appealing to me).
Sure, but honestly, the cost of a PATH search is negligible compared
to the cost of a successful execve() in the first place. If you are
experiencing a noticeable slowness, it's definitely not because of a
PATH search.
> Anyway, I have both /command and /package in the hard-drive based
> system, and only /command in the initramfs. So, unless I'm missing
> something, setting conf-home seems the best solution.
The fact that setting conf-home to "" works for you is an artefact,
a hack that works by pure chance. It breaks slashpackage assumptions
and is not guaranteed to work in the future.
If you set your PATH to /command in your initramfs, and clear
flag-slashpackage, you will have no PATH security issues, and no
performance loss. This is the supported way of doing what you want.
> Assuming that
> the symlinks in the hard-drive /command dir are up to date, is there
> any real inconvenient in hard-coding the paths in the binaries to
> /command rather than /package/* ? It seems the best of both worlds...
Some people want slashpackage but not slashcommand. /command is an
extension to slashpackage, that provides some benefits but is not
essential.
Really, clearing flag-slashpackage for your initramfs doesn't hurt.
And if you want a slashpackage structure in your initramfs, then do it !
Just copy the directory structure and the .../command subdirectories
with the binaries inside, and have /command be a bunch of symlinks. The
/package tree without the source/doc/randomcrap and the additional
symlinks won't take much space in your initramfs, you have that little
extra RAM, and you'll free it quite fast anyway.
Or you could forego initramfs entirely, initramfs is useless. :P
--
Laurent
Received on Thu May 15 2014 - 20:49:19 UTC