Re: what's next for the linux kernel?

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Wed, Oct 05, 2005 at 01:04:10PM +0200, Diego Calleja wrote:

> El Wed, 5 Oct 2005 11:26:50 +0100,
> Luke Kenneth Casson Leighton <lkcl@lkcl.net> escribi?:
> 
> > > Now I certainly wouldn't advocate a Windows-style registry, 
> > > because I think it's full of obvious problems. 
> > 
> >  such as? :)
> 
> 
> The ugly implementation (inside the kernel and as a big file instead of doing it as a

 the nt 3.51 implementation got it right: userspace service (MSRPC
 service) with LPC (this is NT, based on Mach, so they have LPC which is
 message-passing - joy) communicating from userspace to kernelspace
 where necessary.

 nooo, it not okay to have registry in kernel.  _access_ to it (via
 ioctl's) yes.  _in_ kernel, friggin'ell'no.

 regarding the other points: yes, there's a per-user hive key, which is
 "overlaid" onto parts of the sub-tree.

 and yes, the previous poster is absolutely right: the benefits cannot
 be felt unless evvverrryyy service under the sun is also using it.

 ... but heck - we do configuration of pretty much every major service
 under the sun out of ldap, don't we?
 
 and openldap itself just got the ability to read its own
 config out of its own database, right?

 it's not _that_ far off, not _that_ unachievable, s/ldap/registry.

 there's just a few core services missing - initscripts is a good
 example - which nobody's yet had the nerve to tackle (afaik) and dump
 into LDAP.

 in that example, mostly because there's not much point unless
 you're also going to do something decent like put in proper
 dependencies (see depinit).

 anyway.  how on _earth_ did we get here, and please could
 someone advise me - and everyone else - of a more suitable
 location to discuss these matters?

 l.

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