On Mon, 06 Nov 2000 21:19:35 +0100, the world broke into rejoicing as
"Marc Mendez" <[EMAIL PROTECTED]> said:
> I just was wondering about something : I ve already read papers about L4.
> It is technically designed to excel on the ix86 architecture : L4/i486 is
> then different from L4/iPentium.
>
Hi
Folks !!!
I just
was wondering about something : I ve already read papers about
L4.
It is technically designed to excel on the ix86 architecture :
L4/i486 is then different from L4/iPentium.
But Intel will soon (days or months whatever!) launch the ia64
processor.
Will
L4 be ported
My following remarks are concerned with porting the Hurd to L4 only; I
am not interested in a virtual kernel because of the performance
penalty and the general complexity of such a project, which will
decrease the probability of it ever bearing fruit.
>-> If we don't use mach anym
[This is quite offtopic for the Hurd lists. As Roland pointed out,
the Hurd lists are for discussing things clearly pertinant to existing
Hurd software. Please direct any replies to this message to
[EMAIL PROTECTED]
> Farid Hajji writes:
FH> 1. I'm trying to put the Hurd on top of a 'vk' (
Roland,
> > need to reply like this. Basically, you suggest nothing less than to shut
> > up and do our own non-approved stuff without asking for feedback from the
> > list. This is asking for a split in development :-((( Sad perspectives...,
> > but splits are necessary sometimes.
> I didn't say
On Sun, Oct 29, 2000 at 03:49:01PM -0500, Roland McGrath wrote:
> > Is it _absolutely_ necessary to use glibc with the Hurd?
>
> Why on earth would one want not to? The Hurd developers have no interest
> whatsoever in using anything but the GNU C library for the GNU system.
think about embedded
On Sun, Oct 29, 2000 at 06:57:41PM -0500, Roland McGrath wrote:
> Perhaps there should just be another mailing for wild speculations about
> random development ideas tangentially related to the Hurd development
> effort. Then I would read that one when I was in that kind of mood. These
> lists re
> "FH" == Farid Hajji <[EMAIL PROTECTED]> writes:
FH> We can't guess what you're planning to do on short or middle term
FH> if you don't post your ideas somewhere
There's a substantial list of work to be done listed in the source
distribution, http://subversions.gnu.org/cgi-bin/cvsweb/hurd/ta
Perhaps there should just be another mailing for wild speculations about
random development ideas tangentially related to the Hurd development
effort. Then I would read that one when I was in that kind of mood. These
lists really exist for concrete discussion of real problems with the
existing co
> if you would let us participate to your concepts of current and future
> development, such discussions would be more effective. We can't guess
> what you're planning to do on short or middle term if you don't post
> your ideas somewhere :(.
There is no secret plan. Marcus has laid out numerous
Roland,
> Look, whatever you want to hack on is fine with me. If you contribute
> changes to Hurd and/or glibc that are clean and do not have negative
> consequences for the ways we are using the code now, then we will probably
> accept your changes. But the development priorities of the Hurd pr
Look, whatever you want to hack on is fine with me. If you contribute
changes to Hurd and/or glibc that are clean and do not have negative
consequences for the ways we are using the code now, then we will probably
accept your changes. But the development priorities of the Hurd project
per se are
> The Hurd is IMHO more than just a simple kernel replacement of a glibc-
> based system. Due to its flexibility, other applications like host-os
> subhurds are possible too. Just because it's 'oolitically correct' to
> stick to glibc doesn't mean that we _must_! Other GNU programs are not
> depend
> Anything that can be done to make the HURD available on more
> processor architectures would be a good thing. But my impression is
> that the work the needs to be done is to port the HURD to OSKit Mach
> and to port OSKit Mach to other architectures.
Then you would still be stuck with Mach which
> > Is it _absolutely_ necessary to use glibc with the Hurd?
> Why on earth would one want not to? The Hurd developers have no interest
> whatsoever in using anything but the GNU C library for the GNU system.
The Hurd is IMHO more than just a simple kernel replacement of a glibc-
based system. Due
> Is it _absolutely_ necessary to use glibc with the Hurd?
Why on earth would one want not to? The Hurd developers have no interest
whatsoever in using anything but the GNU C library for the GNU system.
>>> Farid Hajji <[EMAIL PROTECTED]> 29-Oct-00 5:34:40 PM >>>
>P.S.: I don't have anything against glibc. Dropping glibc
>dependency from the Hurd is purely an architectural issue
>that would help support the notion of "host OS running sub-hurd"
>as well as to help isolate the current Mach depen
Is it _absolutely_ necessary to use glibc with the Hurd?
It seems that many hurd servers and libs are using glibc like
any other C library except for:
/mach
/hurd
/sysdeps/mach
and of course MiG-generated stubs in /*/.deps plus a few places
that use mach_*() syscalls directly. There are so
18 matches
Mail list logo
