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

[Amadeusz Żołnowski]

Quoting Sebastian Pipping (2012-09-09 22:38:13)
> On 09/09/2012 09:50 PM, Amadeusz Żołnowski wrote:
> > It helps that you don't care about Genkernel4 and Geninitramfs yet
> > until Genkernel4 is ready for users.
> >
> > 1) I implement Genkernel4 working with Dracut (might take some time)
> > 2) Genkernel4 is ready for use
> >
> > Until now Genkernel3 development is not interfered.
> >
> > 3) Genkernel3 development is frozen (only bug fixes)
> > 4) Genkernel3 is moved, as I have described earlier, to Geninitramfs
> > (this is going to be quick)
> > 5) I make Genkernel4 support Geninitramfs (this is going to be
> > quick)
> >
> > There's no need for any wrapper.
>
> that approach sounds closer to big bang than many small steps.

While for many small steps we will need an eternity.


> If genkernel4 takes a year to complete, no one can use your progress
> combined with the current initramfs creation.

My progress could be used with Dracut until it is fully usable and then
Geninitramfs support could added quickly.

My goal is to write Genkernel4/5 quickly, simply and painlessly as well
as do the split of Genkernel and Geninitramfs.  Where exactly in the
plan above is a real problem?


> Personally, I would rather like to see features moved step by step
> from geninitramfs up to genkernel and dracut integration being added
> in parallel, too.

There are no features to be moved if you have read my plan carefully.
Please try to understand my initial idea because with every answer I
have a feeling we divert from it too much.

- Gentoo initramfs generator is going to be extracted from Genkernel
  and it is going start its own life under Geninitramfs name.
- Genkernel4/5 is going to use Geninitramfs or Dracut to generate
  initramfs.  It will just call one of them appropriately.


> I have just created a fully functional pass-through wrapper in Python
> on branch "split-genkernel-geninitramfs" [1].  With that as a basis we
> could start extracting kernel compilation from geninitramfs and move
> it to the wrapper and Python.  When a new option "--dracut" is given,
> dracut is used instead.  If we mark that feature "no warrantees", you
> could work on it in parallel and break as much as you like as long as
> the non-dracut mode works as usual.  If you don't like that idea
> today, maybe you like it tomorrow :-)

I do not like this idea and I will not like it tomorrow or even day
after tomorrow.  My initial plan is totally different from what you are
suggesting.  Please not divert from it too much because the discussion
stops to make any sense.  If you don't like my ideas and plan at all
lets just abandon it.  I have already put an effort to describe and we
waste our precious time discussing something completely different.


> For complex software with much string handling I would not use Bash
> anymore.  Bash is good for single-file things with say 100 lines but
> not for a better genkernel.

Where you have to cope with complicated string manipulation in
Genkernel?  And what number of lines has to do with it?

I will write it again.  Genkernel is mostly calling shell commands.  The
parts where more complicated string manipulation takes place are:

a) boot manager entries adding/removing/updating
b) parsing kernel.org wrt step 01.b.

where for (a) awk would be best and for (b) Python would be best.

I'd like to write new Genkernel in Bash4 because this is the best tool
for that.  If you think in categories of POSIX shell your arguments for
writing it in Python would make sense, but Bash4 can do much more than
old sh.


-- 
Amadeusz Żołnowski