Re: [gentoo-genkernel] Re: [RFC] Genkernel4 and Geninitramfs plan

[Amadeusz Żołnowski]

Hello,

Quoting Sebastian Pipping (2012-09-10 13:49:06)
> I see.  How is the implementation going to be quick then?  How many
> months are we speaking?  All these features need implementation and
> (more or less extensive) testing.

Implementing these feature is not going to be quick.  I was saying that
adding new initramfs support is going to be quick.  I cannot give a
timeline, because I simply don't know how much spare time I will have in
upcoming months.  Anyway slower or faster I'll implement it.  No
worries.


> That's a neat idea.  Still my concern was (and is) a different one.
> To give an example, in the case where the resulting initramfs is going
> to be integrated into the kernel image, the destination of the
> initramfs generator must be known to genkernel 5.x (if it cannot be
> specified).  For that feature, genkernel 5.x needs to handle dracut
> and genkernel differently.  I am basically trying to say that it makes
> a more healthy development process to develop both in parallel rather
> than one backend after the other.

Of course.  Initramfs will have to be build in given temporary path and
later initramfs is either integrated into kernel or installed into
/boot.  If it is already tested well with dracut it will be really easy
and quick to add future geninitramfs support.  I have been integrating
dracut and genkernel3 already and I know how to deal with it.  It
wouldn't take more than a day to move genkernel to geninitramfs and no
more than another day to add support for it in Genkernel4.  Testing this
and adjusting other tools is another problem, but this is typical for
stabilization of any software: Genkernel3 is frozen and only bug fixes
are accepted, while Geninitramfs will be taking new features.  Testing
it would take a month as usual, and than we could submit stabilization
request.  To sum up, if Genkernel4 is eventually done (for which I
cannot give any estimation), it would take ~ 1.5 month to stabilize
Genkernel4 and Geninitramfs.


> > I am suggesting appropiate tool for this task.  Please explain me
> > with real arguments how Python would be better than Bash4.  I have
> > mentioned altering boot manager configuration and parsing kernel.org
> > already, but that still doesn't promote Python for the whole
> > Genkernel.
>
> I have given the real arguments already; there are honestly no hidden
> real ones.  I use Bash and Python at work daily, so I know what Bash
> is good at and what it isn't.

Me too.


> Let's take argument parsing as an example actually again), since you
> don't get around that one.  How are you going to do that in Bash,
> cleanly?  Using getopt(1)?  Using a big case statement with extracting
> "foo" from "--param=foo"?

In Python it would be a big block of "parser.add_argument()" calls.
This is not so much big difference from case..esac, despite that ootb it
would require separate maintenance of usage help, but I have a solution
for that, too.


> In current genkernel that's a mess because it is Bash and not Python.

In current Genkernel it is a mess not because of Bash but because of
design.  In Dracut options are handled better and I have some idea how
do it even better.  For handling options Python/Awk could be used in
some way.  I'd like to implement options generator which will
automatically generate usage help, man page, example config file and
bash case..esac with options from a nice *single* template.

Options handling is not the core functionality and shouldn't be a main
argument in decision on language choice.  Genkernel core functionality
is about coping with shell commands and for that Bash4 is the best.


Regards,

-- 
Amadeusz Żołnowski