1 |
Hello, |
2 |
|
3 |
Quoting Sebastian Pipping (2012-09-10 13:49:06) |
4 |
> I see. How is the implementation going to be quick then? How many |
5 |
> months are we speaking? All these features need implementation and |
6 |
> (more or less extensive) testing. |
7 |
|
8 |
Implementing these feature is not going to be quick. I was saying that |
9 |
adding new initramfs support is going to be quick. I cannot give a |
10 |
timeline, because I simply don't know how much spare time I will have in |
11 |
upcoming months. Anyway slower or faster I'll implement it. No |
12 |
worries. |
13 |
|
14 |
|
15 |
> That's a neat idea. Still my concern was (and is) a different one. |
16 |
> To give an example, in the case where the resulting initramfs is going |
17 |
> to be integrated into the kernel image, the destination of the |
18 |
> initramfs generator must be known to genkernel 5.x (if it cannot be |
19 |
> specified). For that feature, genkernel 5.x needs to handle dracut |
20 |
> and genkernel differently. I am basically trying to say that it makes |
21 |
> a more healthy development process to develop both in parallel rather |
22 |
> than one backend after the other. |
23 |
|
24 |
Of course. Initramfs will have to be build in given temporary path and |
25 |
later initramfs is either integrated into kernel or installed into |
26 |
/boot. If it is already tested well with dracut it will be really easy |
27 |
and quick to add future geninitramfs support. I have been integrating |
28 |
dracut and genkernel3 already and I know how to deal with it. It |
29 |
wouldn't take more than a day to move genkernel to geninitramfs and no |
30 |
more than another day to add support for it in Genkernel4. Testing this |
31 |
and adjusting other tools is another problem, but this is typical for |
32 |
stabilization of any software: Genkernel3 is frozen and only bug fixes |
33 |
are accepted, while Geninitramfs will be taking new features. Testing |
34 |
it would take a month as usual, and than we could submit stabilization |
35 |
request. To sum up, if Genkernel4 is eventually done (for which I |
36 |
cannot give any estimation), it would take ~ 1.5 month to stabilize |
37 |
Genkernel4 and Geninitramfs. |
38 |
|
39 |
|
40 |
> > I am suggesting appropiate tool for this task. Please explain me |
41 |
> > with real arguments how Python would be better than Bash4. I have |
42 |
> > mentioned altering boot manager configuration and parsing kernel.org |
43 |
> > already, but that still doesn't promote Python for the whole |
44 |
> > Genkernel. |
45 |
> |
46 |
> I have given the real arguments already; there are honestly no hidden |
47 |
> real ones. I use Bash and Python at work daily, so I know what Bash |
48 |
> is good at and what it isn't. |
49 |
|
50 |
Me too. |
51 |
|
52 |
|
53 |
> Let's take argument parsing as an example actually again), since you |
54 |
> don't get around that one. How are you going to do that in Bash, |
55 |
> cleanly? Using getopt(1)? Using a big case statement with extracting |
56 |
> "foo" from "--param=foo"? |
57 |
|
58 |
In Python it would be a big block of "parser.add_argument()" calls. |
59 |
This is not so much big difference from case..esac, despite that ootb it |
60 |
would require separate maintenance of usage help, but I have a solution |
61 |
for that, too. |
62 |
|
63 |
|
64 |
> In current genkernel that's a mess because it is Bash and not Python. |
65 |
|
66 |
In current Genkernel it is a mess not because of Bash but because of |
67 |
design. In Dracut options are handled better and I have some idea how |
68 |
do it even better. For handling options Python/Awk could be used in |
69 |
some way. I'd like to implement options generator which will |
70 |
automatically generate usage help, man page, example config file and |
71 |
bash case..esac with options from a nice *single* template. |
72 |
|
73 |
Options handling is not the core functionality and shouldn't be a main |
74 |
argument in decision on language choice. Genkernel core functionality |
75 |
is about coping with shell commands and for that Bash4 is the best. |
76 |
|
77 |
|
78 |
Regards, |
79 |
|
80 |
-- |
81 |
Amadeusz Żołnowski |