XPost: comp.os.linux.development.system
From: user@example.net
phil-news-nospam@ipal.net wrote:
> In comp.os.linux.development.system J.O. Aho wrote:
> | On the other hand, the it could be the other way around, the distribution
> | builds in RAID support, but the user will never use it, in this case the
user
> | will waste memory on something he/she never will be using.
>
> Such a system is, from the start, not a candidate for a statically linked
kernel.
> The admin should install Centos, Debian, Fedora, Slackware, Ubuntu, or some
other
> distribution like that, which are intended for general purpose machines.
>
> However, someone building the firmware image for a cable TV set top box, may
> have reason to make a more solid kernel image.
In those cases you know the hardware and it will not change, in these
embedded environments you can build a monolithic/static kernel, which I
have pointed out earlier.
> | What about updating a driver, the sound card you are using, is badly
supported
> | in your monolithic kernel and there is a new driver released for it, which
> | means you need to rebuild the whole kernel. To start using the new driver,
you
> | must reboot (don't this sound familiar from an American operating system?)
>
> I've seen cases where module drivers won't unload, or the new driver will not
> load even those the predecessor did unload. I've even seen cases of a kernel
> panic apparently due to the new module, which doesn't happen after a reboot
> (presumably because of some leftover data structs that got changed).
Of course there can be ill effects, specially when the old driver been
buggy, but you have less need to reboot than when you have everything
built in.
> | Modular kernel allows you build a module, replace the module file, unload
the
> | module in memory and then load the new module, and you have updated the
driver
> | without the need of spending time to building a big kernel and no reboot.
>
> I know how it works. But I would not considered the avoidance of rebooting
as
> a suitable design direction for a high-availability system/service. Instead,
> I'd design such a service so that rebooting can be readily done without an
> impact. For example, a root or TLD name server needs to be up 24x7x366. The
> classic "five nines" is not even good enough. I wouldn't depend on any
machine
> to not reboot. I'd design around that fact that machines _will_ reboot.
Then
> things can be quite stable when they happen to not reboot on a regular basis.
Depending on what you run the kernel on, you can have a base kernel that
all it does is to be stable, then have kvm environments where you have a
primary system and a secondary system, which will take over when you
reboot the primary, for the user it would look like the system hasn't
rebooted, but suddenly it's running a new kernel (there is also the
possibility to update a kernel that is running, if the update is minor,
but I wouldn't use that as you could by mistake overwrite something
important during a such update).
> | First of all, people would not choose to use it, as it would imply the
> | distribution has a long install time (build the kernel) and that you won't
> | know if it will support what you install next on your computer.
>
> It wouldn't be for a general purpose computer. It would be for special cases
> ranging from special control computers to embedded devices.
Being more clear what you wanted to do in first place would have been
better IMHO, you would have got a different kind of replies than you have.
--
//Aho
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
