| 1 |
Hi there, |
| 2 |
|
| 3 |
|
| 4 |
On 09/09/2012 09:50 PM, Amadeusz Żołnowski wrote: |
| 5 |
>> I don't get that point, to be honest. What is the problem and how |
| 6 |
>> does pushing the spliut further way help about it? |
| 7 |
> |
| 8 |
> It helps that you don't care about Genkernel4 and Geninitramfs yet until |
| 9 |
> Genkernel4 is ready for users. |
| 10 |
> |
| 11 |
> 1) I implement Genkernel4 working with Dracut (might take some time) |
| 12 |
> 2) Genkernel4 is ready for use |
| 13 |
> |
| 14 |
> Until now Genkernel3 development is not interfered. |
| 15 |
> |
| 16 |
> 3) Genkernel3 development is frozen (only bug fixes) |
| 17 |
> 4) Genkernel3 is moved, as I have described earlier, to Geninitramfs |
| 18 |
> (this is going to be quick) |
| 19 |
> 5) I make Genkernel4 support Geninitramfs (this is going to be quick) |
| 20 |
> |
| 21 |
> There's no need for any wrapper. |
| 22 |
|
| 23 |
that approach sounds closer to big bang than many small steps. |
| 24 |
If genkernel4 takes a year to complete, no one can use your progress |
| 25 |
combined with the current initramfs creation. |
| 26 |
|
| 27 |
Personally, I would rather like to see features moved step by step from |
| 28 |
geninitramfs up to genkernel and dracut integration being added in |
| 29 |
parallel, too. |
| 30 |
|
| 31 |
I have just created a fully functional pass-through wrapper in Python on |
| 32 |
branch "split-genkernel-geninitramfs" [1]. With that as a basis we |
| 33 |
could start extracting kernel compilation from geninitramfs and move it |
| 34 |
to the wrapper and Python. When a new option "--dracut" is given, |
| 35 |
dracut is used instead. If we mark that feature "no warrantees", you |
| 36 |
could work on it in parallel and break as much as you like as long as |
| 37 |
the non-dracut mode works as usual. If you don't like that idea today, |
| 38 |
maybe you like it tomorrow :-) |
| 39 |
|
| 40 |
|
| 41 |
>> Unlike with init scripts, there is no need for using shell scripting |
| 42 |
>> here, right? If so, let's stick to Python >=2.6 only, if just for |
| 43 |
>> argparse alone. Bash is one of genkernel's current issues in my |
| 44 |
>> opinion. |
| 45 |
> |
| 46 |
> What Genkernel does is mostly calling shell commands. Bash4 is the best |
| 47 |
> tool for this task if used correctly. I'd use Python for helper tools |
| 48 |
> only if implementing something in Bash4 is PITA. |
| 49 |
|
| 50 |
For complex software with much string handling I would not use Bash |
| 51 |
anymore. Bash is good for single-file things with say 100 lines but not |
| 52 |
for a better genkernel. |
| 53 |
|
| 54 |
|
| 55 |
>> I could imagine it would even make sense to implement and forward all |
| 56 |
>> the options initially. |
| 57 |
> |
| 58 |
> What options? What do you mean? |
| 59 |
|
| 60 |
The command line options. Basically what I did on branch |
| 61 |
"split-genkernel-geninitramfs" [1] now. |
| 62 |
|
| 63 |
Best, |
| 64 |
|
| 65 |
|
| 66 |
|
| 67 |
Sebastian |
| 68 |
|
| 69 |
|
| 70 |
[1] |
| 71 |
http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=shortlog;h=refs/heads/split-genkernel-geninitramfs |
| 72 |
|
| 73 |
PS: removing genkernel@g.o from CC as the thread is not complete on that |
| 74 |
alias anyway and it seems everyone involved is on the real list by now. |
Archives