Canonical system name for Hurd on top of l4

[Niels Möller]

Hi,

there's a group of people investigating the possiblity of porting the
Hurd to other (micro)kernels than Mach. The hottest candidate seems to
be l4, but some are also interested in building an micro kernel
abstraction layer that could also be implemented on top of other
kernels, like Linux or FreeBSD.

One minor but important question is what "canonical system name" to
use for such systems. I include some of my thoughts below, and I would
appreciate comments. I cc: this to rms because one proposal clashes a
with the current use of "cpu-manufacturer-linux-gnu", and perhaps you
can shed some light on how to generalize the four-part system tuple.

You can reply to me, or directly to the address@hidden list.

Regards,
/Niels

------- Start of forwarded message -------
To: OKUJI Yoshinori <address@hidden>
Cc: address@hidden, address@hidden
Subject: Re: configuration
References: <address@hidden> <address@hidden> <address@hidden>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: address@hidden (Niels Möller)
Message-ID: <address@hidden>
Date: 06 Nov 2000 17:01:01 +0100

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

_______________________________________________
L4-hurd mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/l4-hurd

------- End of forwarded message -------