Re: linux kernel without users



On Fri, 6 Jun 2008, The Natural Philosopher wrote:

d.christou.christou@xxxxxxxxx wrote:
On Jun 5, 2:08 pm, markhob...@xxxxxxxxxxxxxxxxxxxxxxxxxxx (Mark
Hobley) wrote:
I would like the kernel to become more like a microkernel, with
additional features loading as modules.

Yes, I was thinking along these lines: to implement a true capability
system within the linux kernel, taking ideas from Coyotos (and little
from Plan 9, L4 and Minix 3), would not require the traditional user
id mechanism or root user. Certainly, for a multiuser system, it would
be necessary a user id in the filesystem, but what about processes? It
would only be necessary to have a heirarchy descending from the "user
session" process, which itself might be persistent. The other problems
are user resource quotas and ipc between unaffiliated processes.

I am not fully aware of all the uses that uid/gid is put to, in the
kernel. I have done a simple grep for "gid" in kernel and found 2936
references except fs/, not exactly the monumental task. The much
greater work would be introducing an alternate system - true
capabilities.

Any thoughts or issues?
Nothing is easier than writing a micro kernel and a stripped down C library.

Then you are down to making what apps you need work.

If its real time there wont be many.

You can hard code a prority in them if you want, and write a new program loader to read them.



Then you might as well start wondering if you really need an operating system.

Once upon a time, of course, there really wasn't an "operating system" or
at the very most it was some basic routines. So every time someone wanted to write a program, they'd start from scratch, putting everything
that was needed.

An operating system meant one could write applications separate from
the hardware, so they'd run on lots of systems and you weren't reinventing
the wheel every time.

That's the tradeoff. One can use Linux and all the accumulated work
that's already been done, or write only what's absolutely needed and
lay it right on the hardware.

ANd a lot of people have decided it's better to build on the familiar
than start out from scratch every time, even if the familiar has more
than they actually need.

As someone pointed out, memory is easy these days, so it's easier
to take advantage of that than spend time on development of a unique
arrangement.

Michael

.



Relevant Pages