Re: Using Objective-C or x (Re: Hurd direction)

[Farid Hajji]

Hi Eray,

> If you used a language with object and message passing semantics, it might 
> become a lot easier to make hurd portable.
IIRC, we already discussed the language issues earlier. I do
understand your suggestion and, frankly, I'm not opposed to C++ either
(or probably even something else), but you should consider the
following drawbacks:

1. We don't want to sacrify (potential) portability to non x86
platforms by using a language that is not very widespread (I don't
mean C++ or even gcc's objective C here). If the compiler of the
language you're suggesting is not written in C (or C++, or if it is
absolutely necessary Obj-C), then porting gcc alone would not be
enough. Did you already port a compiler including the runtime of some
more than trivial or small language to a completly new uKernel or
architecture?

2. It would be a good idea to be able to cannibalize as much external
code as possible, like e.g. kernel drivers etc., possibly in the form
of OSKit libs or some such. The language we use must therefore provide
seamless linking to C (at the linker level, but more often than not
also at the API level). What does this mean for the Hurd? Actually,
the glibc sysdeps would have to be adapted to the new runtime/uKernel
and language in which the system is written. This would not be so
hard, iff the kernel were monolithic: Here you've got a simple
interface that could map to glibc's C in some more or less direct
manner. I'm not sure that this still remains true for distributed
multiserver systems like the Hurd.

3. How many people are really fluent with, say Cilk or even something
totally new and different? A few years ago, I implemented a small
uKernel with message passing semantics in scheme (actually, the scheme
engine was itself written in C) and guess what, the performance wasn't
that bad either. _But_, it all boils down to providing an API of the
uKernel (or whatever sits on top of it) to real-world applications.
The toy project involved providing some minimal C-lib that ultimately
linked into Scheme... and here the problems generally start getting
pretty hard. "Native" Scheme applications naturally used the uKernel
scheme API; they even enhanced it if they could present appropriate
credentials/capabilities to do so. Best of all, Lambda-uK ran
naturally on multiprocessors, mapping threads to function
objects. But, really, do we expect that all real world applications be
rewritten in scheme? ;-).

[Please don't ask me for the Lambda-uK code; I'm not (yet) allowed to
redistribute it. Should the restrictions be lifted someday, I'd make
the code available under [L]GPL or BSD license. As long as the code is
classified, we'll have to wait (or you could do a clean-room
implementation yourself; that's not so hard).]

>   1) Obj-c 
>   2) Cilk
Cilk is actually a good candidate, but who would be really willing to
start learning it now? Just asking around: anyone used Cilk before?

>   3) Custom language extension, new language (like inferno?)
>   4) Going C++ (better std lib, still message passing requires lang. 
> extension a la Charm++ which is _not_ a fantastic thing). Might be feasible 
> since we have a much better std lib now. [*]
Well, message passing semantics would really be a "nice thing to
have," but most of it could also be coded in C. Another aspect that
could also be quite hairy, is support for languages with inherent
concurrency.  Here, the problems shift to the runtime that will have
to be ported to any uKernel we'd like to port the Hurd to. I'm not
sure that this would be easier to do rather than write a portable
pthreads library for each uKernel from scratch (but I'm no expert
here).

> Things not to do:
> 
>   1) Corba
>   2) A "Component Object Model"
I partly agree with you here. It may be possible to use some IDL and
IDL stub compiler as replacement for MIG, even when porting to a
non-mach uKernel, but that's it. The L4Ka team is experimenting with
IDL4 (Flick) compiler to generate efficient stubs for L4Ka
interfacing, and we could certainly use something similar, even before
switching to L4 (any volonteers willing to replace MIG with IDL4?). I
may be willing to consider doing some CORBA with C++ (most Hurd
interfaces seem very well suited to CORBA, or some kind of
"lightweight CORBA"), but cerainly not COM!

> Using another language of course does not remove, by itself, complications in 
> the present architecture (part of which is dependency on mach)
Absolutely.

> The candidates have been ordered in order of decreasing feasibility. Many 
> people know obj-c and we have a front end in GCC. Cilk is pretty nice, and 
> used by some hackers at MIT (and elsewhere presumably). Both are extensions 
> to C, so transition is relatively easy. A custom language might be perfected 
> but takes time. Extending C++ (in a good way) is very difficult.
If you have sample code for some core (or non-core) OS components
written in Obj-c, Cilk or any language you think would be better than
C, please let us participate. The problem with such discussions is
that they remain theoretic since no-one seems to be able to provide
real code or at least some framework/skeleton to get started.

> What is the advantage of using a concurrent class based[+] (following 
> Cardelli's definition) language?
>   * shorter/cleaner/better code
The code may be easier to read, but I doubt that it will be more efficient.
Can you provide evidence of better efficiency, e.g. in form of published
benchmarks (mostly in papers)? The whole point to switch to, say L4, is
to reduce the overhead involved with IPC. Every uKernel-based system
uses IPC pretty heavily, and Mach is not that efficient at handling
(i.e. buffering) messages. Using some other language (runtime) could
likely _increase_ the latency even more, unless the runtime is optimized
for _every_ conceivable IPC form used in the Hurd now (and also in the
future). That objective could be tough to achieve.

>   * portability to alternative message passing systems (change the backend)
As said earlier, we would probably just move the problem from porting
a (virtual?) kernel interface library from one uKernel to another, to
porting the backend from one uKernel to another. I've programmed for a
very long time, and all my intuition screams at me, that porting the
backend could be much more difficult than to just change a library. I
may be wrong in some special cases, please convice me that your
solution would be better.

> [*] I'm aware that kernel people despise C++. I can't do much about that 
> except to point out that if you use C++ right it might be a viable option and 
> stdlib, virtual methods, type-checking, genericity, etc. can all be used to 
> advantage in modern os code.

Some L4 implementations are written in C++ (but note that they don't
use the advanced features of C++) and they compete quite well with
hand-crafted _assembler_ code implementations (!). I don't share the
reluctance of most kernel hackers regarding C++. C++ may even be quite
a natural choice for the object oriented Hurd interfaces right
now. But we're getting here in the same religious war that
periodically starts in the Gtk+ (and GNOME) community ;-). Actually, I
can even understand both sides. It's often harder to interface other
languages (like GUILE, Perl, Python etc...) to C++ than to C. This is
an important point that we should not forget.

> [+] Cilk is not class based IIRC, and I don't think Obj-C is concurrent... :)
...at least not really; or should we even consider Ada for concurrency?
[Yuck!...]? ;-)

> Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
> Comp. Sci. Dept., Bilkent University, Ankara
> www: http://www.cs.bilkent.edu.tr/~erayo
> GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

Regards,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.