[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux binaries on HURD

On Wed, 21 Oct 1998, Grigorio V. Moshkin wrote:

> 			Hello, collegues!
> 	I am just a Linux fan and user and (slightly) programmer. Plese do
> not forget the _MAIN_ goal of HURD to be alive!!!
> Linux binaries and driver modules MUST BE runnig atop Debian GNU/HURD
> system on the same hardware architecture.


> And Linux program and module code sources MUST BE runnig after simple
> re-compilation on the different hardware architecture.

Programs, certainly.  Source compatibility is *definitely* a goal. For
programs.  Not for drivers - the linux driver model is utterly different
(and utterly inferior) to the HURD one.  Perhaps the key difference is
that, as far as Mach allows, HURD drivers are userland, not kernel-side.

> So Debian GNU/HURD MUST NOT differ at all compared to Debian GNU/Linux for
> 'external user'. It's a wrong way to port packages such as make, tar, etc.
> from Linux to HURD. Instead you have to create environment that couldn't
> be distinguished from Linux by any Linux packages, programs or modules!

And what would we then gain?

Your comments would be better directed to a central HURD mailing list,
anyway, since this is just the Debian/HURD project.  But, the point is,
that if the HURD were identical, we would have gained nothing.  The HURD
aims to be superior (and different).

Source compatibility is important.  And we aim for this, since we're going
to be running a version of glibc on HURD - so the glibc interface will be
maintained.  Binary compatibility is an interesting goal, but not a very
important one, IMHO.

> Also it is very important now since there are hard real time extentions
> for Windows NT to build in the same RT feature into HURD kernel. As I know
> mach microkernel is quite useful for real time (RT) os development. Note
> you need true real time feature allowed for example for some type of
> modules (servers). Linux RT scheduling is not sufficient since non-RT
> applications could slow-down RT applications during i/o and/or interrupt
> handling for non-RT programs.
> Plese accept opinion mentioned above, it's so IMPORTANT for your
> success!!!

Depending how you measure success..


|  Jelibean aka  | jules@jellybean.co.uk         |  6 Evelyn Rd	       |
|  Jules aka     |                               |  Richmond, Surrey   |
|  Julian Bean   | jmlb2@hermes.cam.ac.uk        |  TW9 2TF *UK*       |
|  War doesn't demonstrate who's right... just who's left.             |
|  When privacy is outlawed... only the outlaws have privacy.          |

Reply to: