Re: configuration

[Niels Möller]

OKUJI Yoshinori <address@hidden> writes:

> From: Ali SHEIKH <address@hidden>
> Subject: Re: configuration
> Date: Thu, 2 Nov 2000 12:09:40 -0500
> 
> > I am not an expert, but I think that Farid's virtual kernel idea might
> > be a way out. If we can come up with a a libvk that is generic enough
> > to encapsulate all microkernel interfaces, then we can just go ahead
> > and call our system *-*-gnu, without worrying about what ukernel it is.
> 
>   Hm, that is one of the things I want to hear. ;)

I think the (u)kernel being used is a quite important piece of the
system identifier, so it ought to be included. Ok, only quite obscure
applications should depend on it, but I believe it should be possible
to use autoconf also for obscure stuff. As an example, consider a lisp
or java system that supports threads and doesn't want to go through
the C library stubs to access the system's thread facilities.

Current versions of config.sub and config.guess uses system names with
four parts (the third being optional). From config.sub:

# The goal of this file is to map all the various variations of a given
# machine specification into a single specification in the form:
#       CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
# or in some cases, the newer four-part form:
#       CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
# It is wrong to echo any other type of specification.

So it might make sense to use "x86-pc-l4-gnu" (meaning a system
running Hurd on l4 on plain pc hardware). This also extends in some
way to the running hurd on top of some other OS (and I think I'd
prefer to call that other os a "host-os" rather than "guest-os", but
that's vmware terminology), like "alpha-dec-bsd-gnu" for running the
hurd on top of bsd on alpha. It clashes terribly with
"x86-pc-linux-gnu" though, which currently doesn't mean Hurd on top of
linux, but "A variant GNU system using Linux as the kernel".

Perhaps one ought to ask the autoconf people and rms what they think.

It seems that the "kernel" part is not currently fully supported by
autoconf (although I'm reading the docs, not the source); ideally one
would want to add variables host_kernel, build_kernel and
target_kernel. 

>   Do all of you agree that the basic idea should be to construct a
> generic but yet powerful layer and rewrite Hurd on the top of the
> microkernel-independent layer?

First step would be to *identify* the features needed from that layer.

I'd also like to know about the interdependencies between glibc and
the new libmom. I imagine the plan would be that glibc not depend on
the ukernel used, only on the cpu type and the new libmom. While
libmom would depend both on the kernel used and on libc (and in the
"host-os" case, is that the the host-os libc or glibc)?

/Niels