Re: what's next for the linux kernel?

From: Luke Kenneth Casson Leighton
Date: Wed Oct 05 2005 - 05:27:36 EST


On Tue, Oct 04, 2005 at 06:40:33PM -0500, Chase Venters wrote:

> Work on dbus and HAL should give us good improvements in these areas. One

dbus. total waste of several man-years of effort that could have been
better spent in e.g. removing the dependency of posix draft 4 threads
from freedce (which i finally did last month) and e.g. adding an ultra-fast
shared-memory transport plugin.

hal. _excellent_. look forward to it being ported to win32 so that
it's useful for the kde-win32 port etc. etc.

> remaining challenge I see is system configuration - each daemon tends to
> adopt its own syntax for configuration, which means that providing a GUI for
> novice users to manage these systems means attacking each problem separately
> and in full.

that's quite straightforward to deal with but it _does_ mean using a
unified approach to writing APIs.

NT solved this problem by writing graphical tools in c and then
adopting dce/rpc as the means to administer the services both locally
_and_ remotely.

wholesale. utterly. everything. right from the simplest things like
rebooting the machine, through checking the MAC addresses of cards
(NetTransportEnum) all the way up to DNS administration - yes,
dnsadmin.exe will write out DNS zone files in proper bind format.

it's quite a brave choice to take.

> Now I certainly wouldn't advocate a Windows-style registry,
> because I think it's full of obvious problems.

such as? :)

they're not obvious to me. at the risk of in-for-penny, in-for-pound
_radically_ off-topic discussion encouragement here, and also for
completeness should someone come back to the archives in some years or
months and go "what obvious problems", could you kindly elaborate?

one i can think of is "eek, my system's broken, eek, i can't even use
vi to edit the configs".

and having described the problem, then.. .. well... actually...
it's simply dealt with:

http://www.bindview.com/Services/RAZOR/Utilities/Unix_Linux/ntreg_readme.cfm

todd sabin wrote a linux filesystem driver which is read-only, so at
least half the work's done.

(and the reactos people have written a complete implementation
of a registry, btw).

> Nevertheless, it would be nice
> to have some kind of configuration editor abstraction library that had some
> sort of syntax definition database to allow for some interesting work on
> GUIs.

i have to say this: it's almost too radical, dude :)

he he.


> In any case, I think pretty much all of this work lives outside the kernel.

ACK!

... well... not entirely.

a "registry" - god help us - would need to be stored on a filesystem.
and then, ideally, made accessible a la todd sabin's ntreg driver - via
a POSIX interface (because the linux kernel doesn't _do_ anything other
than POSIX filesystems *sigh*). and that makes it also convenient to
access from kernelspace, too.

hey, you know what? if linux got a registry, it would be possible for
the kernel to access - and store, and communicate - persistent
information.

conveniently.

hurrah.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/