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

[Sebastian Pipping]

Hello again,


let's be clear about your goals for genkernel 5.x.  Are you aiming at
re-writing support for all of the current kernel options of genkernel
below?

I am wondering (and asking) because we cannot make a genkernel 5.x
with just a small fraction of what genkernel 3.4.x already could do.

  --config FILE         genkernel configuration file to use
  --menuconfig          Run menuconfig after oldconfig
  --no-menuconfig       Do not run menuconfig after oldconfig
  --gconfig             Run gconfig after oldconfig
  --no-gconfig          Don't run gconfig after oldconfig
  --xconfig             Run xconfig after oldconfig
  --no-xconfig          Don't run xconfig after oldconfig
  --save-config         Save the configuration to /etc/kernels
  --no-save-config      Don't save the configuration to /etc/kernels
  --oldconfig           Implies --no-clean and runs a "make oldconfig"
  --no-oldconfig        Do not run "make oldconfig"
  --clean               Run make clean before compilation
  --no-clean            Do not run "make clean"
  --mrproper            Run make mrproper before compilation
  --no-mrproper         Do not run make mrproper before compilation
  --install             Install the kernel after building
  --no-install          Do not install the kernel after building
  --symlink             Manage symlinks in /boot for installed images
  --no-symlink          Do not manage symlinks
  --callback COMMAND    Run the specified arguments after the kernel and
                        modules have been compiled
  --static              Build a static (monolithic) kernel
  --no-static           Do not build a static (monolithic) kernel
  --kerneldir DIR       Location of the kernel sources
  --kernel-config FILE  Kernel configuration file to use for compilation
  --module-prefix DIR   Prefix to kernel module destination, modules
                        will be installed in <prefix>/lib/modules
  --kernel-cc COMPILER  Compiler to use for kernel (e.g. distcc)
  --kernel-as ASSEMBLER
                        Assembler to use for kernel
  --kernel-ld LINKER    Linker to use for kernel
  --kernel-cross-compile COMMAND
                        CROSS_COMPILE kernel variable
  --kernel-make MAKEPRG
                        GNU Make to use for kernel
  --kernel-target TARGET
                        Override default make target (bzImage)
  --kernel-binary PATH  Override default kernel binary path
                        (arch/foo/boot/bar)
  --makeopts OPTIONS    Make options such as -j2, etc...
  --arch-override ARCH  Force to arch instead of autodetect
  --cachedir DIR        Override the default cache location
  --tempdir DIR         Location of Genkernel's temporary directory
  --postclear           Clear all tmp files and caches after genkernel
                        has run
  --no-postclear        Do not clean up after genkernel has run
  --kernname LABEL      Tag the kernel and ramdisk with a name: If not
                        defined the option defaults to "genkernel"
  --minkernpackage FILE
                        File to output a .tar.bz2'd kernel and ramdisk:
                        No modules outside of the ramdisk will be
                        included...
  --modulespackage FILE
                        File to output a .tar.bz2'd modules after the
                        callbacks have run
  --kerncache FILE      File to output a .tar.bz2'd kernel contents of
                        /lib/modules/ and the kernel config. NOTE: This
                        is created before the callbacks are run!
  --no-kernel-sources   This option is only valid if kerncache is
                        defined. If there is a valid kerncache no
                        checks will be made against a kernel source tree
  --kernel-sources      Revert --no-kernel-sources


  --integrated-initramfs
                        Include the generated initramfs in the kernel
                        instead of keeping it as a separate file
  --no-integrated-initramfs
                        Exclude the generated initramfs from the
                        kernel, keep it as a separate file


On 09/09/2012 11:47 PM, Amadeusz Żołnowski wrote:
> While for many small steps we will need an eternity.

Each step takes more effort than the same step would take in a
from-scratch world, correct.


>> 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?

If something is meant to be used with two backends, it's risky to
develop for one and adding the other later.  To save surprises, each
feature should be made working for both backends plus you need a clear
and complete overview of how operation, feature sets and interfaces
differ among these two backends upfront.


> 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.

I was previously steering in somewhat shared but different direction,
yes.  This very mail focuses on your original approach now, only.


> - 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.

Understood, yes.


> 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.

We're back at your original approach now.


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

Come on, are you seriously suggesting Bash for real software in 2012?
There are no proper dictionaries in Bash, lists and seperators are a
pain.  Bash is a shell, good for ebuilds and scripts, and bad for real
software.


> 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.

To me it sounds like you underestimate the final complexity of the
future genkernel.  You guess you assume I overestimate it.


> I'd like to write new Genkernel in Bash4 because this is the best
> tool for that.

I disagree.


> 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.

I'm aware.

Best,



Sebastian