Jeremy Huntwork wrote:
Alexander E. Patrakov wrote:
I am going to move from unionfs with bad bug history to known working
cloop + devmapper. This requires either going back to shell scripts
(for glibc-based bash) or learning (not well-documented)
libdevmapper.so functions linking /init against this library. As for
insmod, it is not a problem (in C) either.
But I repeat: I don't think C is a proper language for scripting.
And I repeat, a C-based init is a far better option in this scenario.
There are far less packages to build, it's notably quicker, it works on
more architectures and you have a smaller initramfs.
Let's review your arguments.
1) far less packages to build
You avoided klibc (that was added only to make initramfs smaller), and
isoinfo. It is possible to have a glibc-based initramfs with bash in it,
and it will require one extra package (isoinfo) as compared to C-based
init (where you essentially reimplemented isoinfo functionality).
2) it's notably quicker
Maybe.
3) it works on more architectures
yes, that's a problem with klibc. This objection doesn't apply to
initramfs with glibc-based bash.
4) you have a smaller initramfs
I agree.
So only two of your arguments are true. My argument for script-based
initramfs:
we don't need to reimplement existing utilities. E.g., there is no need
to spend time learning some poorly documented libdevmapper library when
one can copy-and-paste existing shell commands from google. Those shell
commands are less numerous than C lines, thus there is less possibility
for error. And I was taught that developer's time is sometimes more
valuable than code speed or size.
Also, if you're going to do investigating into cloop and devmapper, if
my voice means anything, I request that you *not* put it into x86/trunk.
Investigate it in a separate branch, please.
Of course.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
