init: API

[Avi Kivity]

Gilboa Davara wrote:

>On Sun, 2005-11-20 at 19:17 +0200, Avi Kivity wrote:
>  
>
>>>Don't want to lean VI?
>>>Get a knpppix rescue CD and use what-ever-GUI-editor-you-like.
>>>Nobody is forcing you.
>>> 
>>>
>>>      
>>>
>>You're forcing me to /bin during the boot process. I already wasted some 
>>of my dwindling neuron supply on that excuse for an editor.
>>    
>>
>
>My heart goes to your dwindling supply of neurons, but you-yourself
>suggest I use a rescue CD to save my precious Linux.
>I just followed suit.
>
>I say: Use rescue CD if you want to, but don't force me to dump my
>network-based BootPXE rescue image for that.
>  
>
Please, keep your pxe rescue. Just add /usr to it.

>You say: If I must use a rescue CD, that everybody else must do it also.
>  
>
Not at all. I'm all for flexibility, except when it encourages stagnation.

I'm saying we should move boot-time flexibility from /bin to initrd. 
initrd is a fact of life in module-based kernels. By making it a little 
smarter and more flexible, we remove a development bottleneck: the ban 
on /usr (and C++, python, and a zillion other goodies) during boot.

>  
>
>>What about the other gazillion of thing in /usr? I want to use them in 
>>my boot process, so I don't have to write it in C or bash (what a pair: 
>>one runs fast bu produces buggy code and is slow to develop, the other 
>>is fast to develop but is very slow, and is even more buggy).
>>
>>    
>>
>
>Should I remind you that your kernel and most libraries on that Python
>coding machine of yours are build written in C,
>
I want to reuse that effort. By writing in python I can concentrate on 
the application, not the plumbing. The boot process is an excellent 
candidate for python since it requires flexibility.

> and most of your boot
>process is in bash.
>  
>
bash sucks as a programming language. it is impossible to write a 
correct program with it.

even a simple

  if proggy | grep -q something; then echo boo; fi

has three bugs in it.

and it's horribly slow. not bash itself, but forking/execing a new 
binary every other line.

>Somehow, I don't see Cpp project such as Mozilla, KDE and OO to show
>better stability then the kernel that boots my machine.
>  
>
Writing something like OO or KDE in C is masochism.

>I will accept that writing a kernel module in C is much more difficult
>then writing a user-land application in Python. (But, on that other
>hand, nothing beats spending your nights looking at meaning less oops
>with trashed calling stack... Pure joy!)
>
>  
>
I guess python tracebacks with "your bug here" in the end aren't for you.

>But we are going way-OT here.
>
>>initrd can mount / from local disk and from the network. Surely it can 
>>be extended to mount /usr from another partition or from another server.
>>    
>>
>
>... And all of this just to add python with its 100,000 libraries to the
>boot processes?
>
>  
>
[root at blast ~]# time python -c 'print 1'
1

real    0m0.029s
user    0m0.016s
sys     0m0.012s

.028 sec overhead, and you can complete the entire boot process with a 
single python instance (/sbin/init.py :) which stays around and monitors 
your services.

I measured 'service network restart' at 1.4 sec cpu time. I'm sure it 
can be reduces to 50ms or less in readable python.

>>Put the rescue image into some partition. It's a bit more space, sure, 
>>but still very small compared to disk sizes.
>>    
>>
>
>On my machine Python alone, is around 100MB, let alone required
>libraries and dependencies.
>How could I possibly stick that in my rescue image and/or BootPXE image?
>
>  
>
Most CDs are 700MB in size. Most networks have gigabytes or terabytes of 
storage.

(And I'm sure it can fit into  50MB compressed image - the binary RPM is 
20MB)

>>Hey, that might be a good idea for the installer.
>>    
>>
>
>I second that.
>Actually, it'll be a good idea to create a RFE in the bugzilla.
>Nice catch!
>
>  
>
You are ruining a perfect record of disagreement here.

>>Learning from their mistakes in fine, but that has nothing to do with 
>>restricting boot to /bin.
>>    
>>
>
>I'm not trying to restrict boot  to bin.
>  
>
Well, you did say some words to that effect.

>I am trying to persuade against creating a GUI-only monster, that will
>end up slower and 100 times more complex (and 100,000 times bigger) then
>our current solution.
>
>Speaking of performance, yum is dog slow, even on my dual Opteron
>FC4/x86-64 workstation.
>Compare that to apt-rpm, and you'll see why I consider a python based
>service manager to be a /bad-idea/.
>  
>
It's possible to write slow programs in any language. Usually the 
problem lies with the algorithms, not the language. Writing in C makes 
the algorithms more difficult to improve.

Consider that the boot sequence is really just a few hundred steps. All 
that is needed (performance wise) is to hide I/O latencies and not 
fork/exec every binary under /bin and /sbin. But there is a lot that is 
needed in terms of features, and a high-level language is the easiest 
way to achieve that.

(and of course boot should have text output, gui, and blinkenlights 
plugins so every one of us can enjoy it in their own way)

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.