Re: will be able to load new kernel without restarting?

[rmoser]

*********** REPLY SEPARATOR  ***********

On 5/4/2003 at 7:09 PM Jan-Benedict Glaw wrote:

>On Sun, 2003-05-04 12:00:00 -0400, rmoser <[e-mail]>
>wrote in message <[e-mail]>:
>> You silly boys.  Thinking everything is impossible.  The old kernel
>> is just a shadow of the new one... just a shadow............  I'll try
>> spitting out a basic sketch.  This I'm sure you've done but if not,
>> fix it.  I'm an idiot, so this won't work as-is.
>> 
>> For starters, freeze the system.  halt EVERYTHING.
>> 
>> Now load the new kernel.
>> 
>> Now you have this thing in RAM.  Fine.  It's not running but it's in
>> RAM.
>> 
>> Start feeding data over to it.  In a manner it can understand.  You know,
>> make all the modules work with a standard named stream (check the
>> Advanced Tracker planning file at the very end:
>> http://advancedtracker.sourceforge.net/at/__at.plan.txt
>> I did copy it below, so you don't have to go there).  This is the
>> hard part--Module compatibility through defined names.  This would
>> bloat the kernel, so think about it and maybe you'll figure out a good
>> way.
>
>Sounds like being a nice feature (esp. for 24/7 uptime), but it also
>sounds like a *lot* of bloat. You'll have to encode (and to decode) any
>single bit if data. But - where to put all that? See, it you're having
>some Gigabytes of ram, you probably end with > 100MB only describing all
>those single pages (4..8K) of RAM. Encode that into a named stream - you
>end up with > 1GB of data. Then, you also need to encode the whole state
>of any drivers.
>
>What do you do if drivers/mm/you-name-it changed and now uses different
>data structures? In fact, any two choosen kernels may potentially use
>different data structures. So for the newly-to-load kernel, you need
>stream decoders for all possible older kernels. Bloat again.
>

Bloat yes.  But the idea is you keep the transit data structures the same.
It's doable.  It's not easy, but the modules, even with changing datastructures,
could understand what the stream means.  The data structures in the stream
need to be identified by module and function.  Then whatever a new module
has discarded, it discards.  Whatever it needs that's not there, it figures out
somehow.  If it can't, it tries to unload, and if it can unload, it notes all this.

When you're all done, ask the modules which work, which don't, and such.
See if it can go really.  If it can, do it.  If it can but some modules need to
reload, which aren't in use, reload them.  Feh, if some modules can't correlate
see if you can use the old kernel version!

>So if I would need something like that, I think kexec is the way to go,
>possibly with a second machine for failover (to even close the kexec
>booting gap).
>

Isn't that boot-without-bios?

>However - if you like this feature so much you'd die for: nobody stops
>you to implement a proof-of-concept:)
>

Do I look like I can code?  I'm a normal user--I write C, C++, but not
kernel-C.  And I can learn.  But if I crash something.  No.  I have one
machine, not something I can play with.  Well I can.  But I don't want
to blow it up.

>MfG, JBG
>
>-- 
>   Jan-Benedict Glaw       [e-mail]    . [phone]
>   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen
>Krieg
>    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
>      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.1 (GNU/Linux)
>
>iD8DBQE+tUlbHb1edYOZ4bsRAmTEAJ9nSPZCVtsbAVRogpBBFUCruvZaVACfb12C
>vZp7TCxxq7XbyYgeCGY8aK4=
>=+rM+
>-----END PGP SIGNATURE-----
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [e-mail]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/