1 |
Hello again, |
2 |
|
3 |
|
4 |
let's be clear about your goals for genkernel 5.x. Are you aiming at |
5 |
re-writing support for all of the current kernel options of genkernel |
6 |
below? |
7 |
|
8 |
I am wondering (and asking) because we cannot make a genkernel 5.x |
9 |
with just a small fraction of what genkernel 3.4.x already could do. |
10 |
|
11 |
--config FILE genkernel configuration file to use |
12 |
--menuconfig Run menuconfig after oldconfig |
13 |
--no-menuconfig Do not run menuconfig after oldconfig |
14 |
--gconfig Run gconfig after oldconfig |
15 |
--no-gconfig Don't run gconfig after oldconfig |
16 |
--xconfig Run xconfig after oldconfig |
17 |
--no-xconfig Don't run xconfig after oldconfig |
18 |
--save-config Save the configuration to /etc/kernels |
19 |
--no-save-config Don't save the configuration to /etc/kernels |
20 |
--oldconfig Implies --no-clean and runs a "make oldconfig" |
21 |
--no-oldconfig Do not run "make oldconfig" |
22 |
--clean Run make clean before compilation |
23 |
--no-clean Do not run "make clean" |
24 |
--mrproper Run make mrproper before compilation |
25 |
--no-mrproper Do not run make mrproper before compilation |
26 |
--install Install the kernel after building |
27 |
--no-install Do not install the kernel after building |
28 |
--symlink Manage symlinks in /boot for installed images |
29 |
--no-symlink Do not manage symlinks |
30 |
--callback COMMAND Run the specified arguments after the kernel and |
31 |
modules have been compiled |
32 |
--static Build a static (monolithic) kernel |
33 |
--no-static Do not build a static (monolithic) kernel |
34 |
--kerneldir DIR Location of the kernel sources |
35 |
--kernel-config FILE Kernel configuration file to use for compilation |
36 |
--module-prefix DIR Prefix to kernel module destination, modules |
37 |
will be installed in <prefix>/lib/modules |
38 |
--kernel-cc COMPILER Compiler to use for kernel (e.g. distcc) |
39 |
--kernel-as ASSEMBLER |
40 |
Assembler to use for kernel |
41 |
--kernel-ld LINKER Linker to use for kernel |
42 |
--kernel-cross-compile COMMAND |
43 |
CROSS_COMPILE kernel variable |
44 |
--kernel-make MAKEPRG |
45 |
GNU Make to use for kernel |
46 |
--kernel-target TARGET |
47 |
Override default make target (bzImage) |
48 |
--kernel-binary PATH Override default kernel binary path |
49 |
(arch/foo/boot/bar) |
50 |
--makeopts OPTIONS Make options such as -j2, etc... |
51 |
--arch-override ARCH Force to arch instead of autodetect |
52 |
--cachedir DIR Override the default cache location |
53 |
--tempdir DIR Location of Genkernel's temporary directory |
54 |
--postclear Clear all tmp files and caches after genkernel |
55 |
has run |
56 |
--no-postclear Do not clean up after genkernel has run |
57 |
--kernname LABEL Tag the kernel and ramdisk with a name: If not |
58 |
defined the option defaults to "genkernel" |
59 |
--minkernpackage FILE |
60 |
File to output a .tar.bz2'd kernel and ramdisk: |
61 |
No modules outside of the ramdisk will be |
62 |
included... |
63 |
--modulespackage FILE |
64 |
File to output a .tar.bz2'd modules after the |
65 |
callbacks have run |
66 |
--kerncache FILE File to output a .tar.bz2'd kernel contents of |
67 |
/lib/modules/ and the kernel config. NOTE: This |
68 |
is created before the callbacks are run! |
69 |
--no-kernel-sources This option is only valid if kerncache is |
70 |
defined. If there is a valid kerncache no |
71 |
checks will be made against a kernel source tree |
72 |
--kernel-sources Revert --no-kernel-sources |
73 |
|
74 |
|
75 |
--integrated-initramfs |
76 |
Include the generated initramfs in the kernel |
77 |
instead of keeping it as a separate file |
78 |
--no-integrated-initramfs |
79 |
Exclude the generated initramfs from the |
80 |
kernel, keep it as a separate file |
81 |
|
82 |
|
83 |
On 09/09/2012 11:47 PM, Amadeusz Żołnowski wrote: |
84 |
> While for many small steps we will need an eternity. |
85 |
|
86 |
Each step takes more effort than the same step would take in a |
87 |
from-scratch world, correct. |
88 |
|
89 |
|
90 |
>> If genkernel4 takes a year to complete, no one can use your |
91 |
>> progress combined with the current initramfs creation. |
92 |
> |
93 |
> My progress could be used with Dracut until it is fully usable and |
94 |
> then Geninitramfs support could added quickly. |
95 |
> |
96 |
> My goal is to write Genkernel4/5 quickly, simply and painlessly as |
97 |
> well as do the split of Genkernel and Geninitramfs. Where exactly |
98 |
> in the plan above is a real problem? |
99 |
|
100 |
If something is meant to be used with two backends, it's risky to |
101 |
develop for one and adding the other later. To save surprises, each |
102 |
feature should be made working for both backends plus you need a clear |
103 |
and complete overview of how operation, feature sets and interfaces |
104 |
differ among these two backends upfront. |
105 |
|
106 |
|
107 |
> There are no features to be moved if you have read my plan |
108 |
> carefully. Please try to understand my initial idea because with |
109 |
> every answer I have a feeling we divert from it too much. |
110 |
|
111 |
I was previously steering in somewhat shared but different direction, |
112 |
yes. This very mail focuses on your original approach now, only. |
113 |
|
114 |
|
115 |
> - Gentoo initramfs generator is going to be extracted from |
116 |
> Genkernel and it is going start its own life under Geninitramfs |
117 |
> name. - Genkernel4/5 is going to use Geninitramfs or Dracut to |
118 |
> generate initramfs. It will just call one of them appropriately. |
119 |
|
120 |
Understood, yes. |
121 |
|
122 |
|
123 |
> I do not like this idea and I will not like it tomorrow or even |
124 |
> day after tomorrow. My initial plan is totally different from what |
125 |
> you are suggesting. Please not divert from it too much because the |
126 |
> discussion stops to make any sense. If you don't like my ideas and |
127 |
> plan at all lets just abandon it. I have already put an effort to |
128 |
> describe and we waste our precious time discussing something |
129 |
> completely different. |
130 |
|
131 |
We're back at your original approach now. |
132 |
|
133 |
|
134 |
> Where you have to cope with complicated string manipulation in |
135 |
> Genkernel? And what number of lines has to do with it? |
136 |
|
137 |
Come on, are you seriously suggesting Bash for real software in 2012? |
138 |
There are no proper dictionaries in Bash, lists and seperators are a |
139 |
pain. Bash is a shell, good for ebuilds and scripts, and bad for real |
140 |
software. |
141 |
|
142 |
|
143 |
> I will write it again. Genkernel is mostly calling shell commands. |
144 |
> The parts where more complicated string manipulation takes place |
145 |
> are: |
146 |
> |
147 |
> a) boot manager entries adding/removing/updating b) parsing |
148 |
> kernel.org wrt step 01.b. |
149 |
> |
150 |
> where for (a) awk would be best and for (b) Python would be best. |
151 |
|
152 |
To me it sounds like you underestimate the final complexity of the |
153 |
future genkernel. You guess you assume I overestimate it. |
154 |
|
155 |
|
156 |
> I'd like to write new Genkernel in Bash4 because this is the best |
157 |
> tool for that. |
158 |
|
159 |
I disagree. |
160 |
|
161 |
|
162 |
> If you think in categories of POSIX shell your arguments for |
163 |
> writing it in Python would make sense, but Bash4 can do much more |
164 |
> than old sh. |
165 |
|
166 |
I'm aware. |
167 |
|
168 |
Best, |
169 |
|
170 |
|
171 |
|
172 |
Sebastian |