Subject: Re: RFC: migration to a fully dynamically linked system
To: Bill Studenmund <email@example.com>
From: Robert Elz <kre@munnari.OZ.AU>
Date: 12/30/2001 16:02:57
Date: Sat, 29 Dec 2001 13:26:37 -0800 (PST)
From: Bill Studenmund <firstname.lastname@example.org>
In general, I think I'd prefer a static init as well, but ...
| We could have the kernel try /recovery/init at that point, but how does
| the kernel know if we're in a, "libc is messed up, try recovery" mode, or
| a, "we're doomed, panic until someone comes to help" mode?
That's easy - init can tell the kernel that it is running now, and all is OK.
After that, panic, before then, try some other init path. init would tell
the kernel all is OK as just about the first thing it does in main().
We could invent a new sys call for init to use - wouldn't even need to
be protected, by the time any other process could possibly get an opportunity
to issue the sys call, init would have already done it (and this one would
be a strictly one way operation).
Or, we could just re-use a sys call that already exists, and that init would
never normally use - with a "if (curproc->p_pid == 1)" type test added.
There's even a sys call that does (almost) that test already, so no extra
overhead would be added if that sys call were adapted for the purpose.
And after you're all finished vomiting, it is for you to clean up the floor...