Re: implicit linkage
On Mon, Oct 13, 2014 at 7:34 PM, Ansgar Burchardt <ansgar@43-1.org> wrote:
> Hi,
>
> On 10/13/2014 12:14, Joel Rees wrote:
>> Get pid 1 down to 100 lines of C, no loops, no functions called, then
>> I'll be impressed.
> [...]
>> Setting aside initialization code, pid 1 should target less than 1000
>> lines of C in the main loop. (If we were to use dash or other
>> streamlined shells, we might set a target of 100 lines of code.) Loops
>> and subroutines should be carefully metered for maximum execution
>> paths, and proven to be deterministic, with a maximum execution path
>> of less than 500 lines of C.
>
> What's the point of this exercise?
What exercise? I'm repeating rules of thumb, not revealing the ways I
derived them (estimates, based on the idea that you don't want
anything close to a millisecond consumed by a pass through the main
loop in pid 1), and admitting that the target I'm proposing is not
necessarily achievable.
systemd doesn't even consider such a target, near as I can tell. I
didn't do a full analysis, but from my casual scan I'm guessing there
are times a pass through the systemd main loop consumes more than a
hundred microseconds, which is too close to a millisecond.
> Linux's process scheduler alone has
> significant more lines. And there runtime complexity actually matters...
Does the scheduler run as pid 1?
Have you traced execution paths?
Did I say the kernel did not need some work? I don't remember saying
such a thing,. In fact, I distinctly remember implying that it did
need continued work.
> I'm just counting lines in kernel/sched/*.[ch], I'm too lazy to filter
> out comments.
Or do the execution path analysis.
Okay, I haven't shown the result of a path analysis for systemd,
either. But systemd runs as process 1. The scheduler does not.
> As an example:
>
> $ wc kernel/sched/fair.c
> 7867 26757 207986 kernel/sched/fair.c
You might want to ask on the kernel list for a pointer to the last
execution path analysis Linus did for the scheduler. You might be
surprised about what they tell you.
You might also want to ask how often the code in fair.c runs.
At any rate, whatever the kernel does is no excuse to introduce the
kind of code in systemd into pid 1.
pid 1 should always delegate any complex task to a child process. That
way, a failure in the complex task does not have to be dealt with
before pid 1 can do it's job the next time around.
--
Joel Rees
Be careful when you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself.
Reply to: