I had a strange Lisp dream last night. I suppose that could be
considered redundant. Maybe any dream involving Lisp should be
considered strange.
In any case, I dreamt that I was fiddling around with a Linux kernel
driver (loading it into the kernel, debugging it, etc) , but the
driver was implemented in Lisp. I remember dropping into the debugger
to watch packets make their way through the driver. I think CMUCL was
involved.
Now that I'm awake, I can think of a few ways this could be done.
Write a loadable kernel module in Lisp & use CMUCL or RScheme or some
other Lisp compiler to compile it. How hard would this be? It'd
certainly be pretty cool - as a general concept and for those who want
to do that LispOS kernel hacking. Another possibility would be to
actually build a kernel module out of a Lisp implementation. How hard
would it be to make CMUCL or RScheme into a loadable kernel module?
Then you could load additional modules written in Lisp which make use
of CMUCL or RScheme.
CMUCL & RScheme are but two examples, but they give a good range in
that RScheme compiles to C code, so for RScheme to be in the kernel
one would also need the C compiler in the kernel, at least for that
last bit of dynamic oomph. I suppose one could use the user side
RScheme to compile code & load that into the kernel RScheme module.
On the other hand, CMUCL compiles directly, so it might be easier to
build it directly into the kernel.
Any takers?
--
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il
Harvey J. Stein wrote:
>
> I had a strange Lisp dream last night. I suppose that could be
> considered redundant. Maybe any dream involving Lisp should be
> considered strange.
>
> In any case, I dreamt that I was fiddling around with a Linux kernel
> driver (loading it into the kernel, debugging it, etc) , but the
> driver was implemented in Lisp. [snip]
>
> CMUCL & RScheme are but two examples, but they give a good range in
> that RScheme compiles to C code, so for RScheme to be in the kernel
> one would also need the C compiler in the kernel, at least for that
> last bit of dynamic oomph. I suppose one could use the user side
> RScheme to compile code & load that into the kernel RScheme module.
>
> On the other hand, CMUCL compiles directly, so it might be easier to
> build it directly into the kernel.
>
> Any takers?
Nice dream ... Unfortunately, I think you first have to deal with the problems
associated with supporting (anything like) Lisp in an OS kernel. The particular
problems I see are support for garbage collection and exceptions.
Let's see ...exceptions ... I could write code that didn't use exceptions. It
would involve some pain, but not too much. I'd have to think about what I would
do with calls to error, etc.
Garbage collection on the other hand ... I don't even want to think about
writing garbage free Lisp code (I've heard it can be done, I don't think I want
to do it.) So I'd have to have a garbage collecting kernel. Now there's an
interesting idea. Unfortunately, you'd probably have to do a complete rewrite of
the kernel to accomplish that.
Chris
--
This is an informal message and not an official Mitretek Systems position.
Dr. Christopher L. Reedy, Mail Stop Z551
Mitretek Systems, 7525 Colshire Drive, McLean, VA 22102-7400
Email: ······@mitretek.org Phone: (703) 610-1615 FAX: (703) 610-1603
In article <··············@blinky.bfr.co.il>
·······@bfr.co.il (Harvey J. Stein) writes:
>On the other hand, CMUCL compiles directly, so it might be easier to
>build it directly into the kernel.
You want a 20 megs unpageable kernel?
--
Matthias K. Buelow * Boycott Micro$oft, see http://www.vcnet.com/bms/ *
·····@cip.informatik.uni-wuerzburg.de (Matthias Buelow) writes:
> In article <··············@blinky.bfr.co.il>
> ·······@bfr.co.il (Harvey J. Stein) writes:
>
> >On the other hand, CMUCL compiles directly, so it might be easier to
> >build it directly into the kernel.
>
> You want a 20 megs unpageable kernel?
But it'd be a LispOS!
:)
--
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il
·······@bfr.co.il (Harvey J. Stein) writes:
| > You want a 20 megs unpageable kernel?
|
| But it'd be a LispOS!
Would it, really? I don't think one or two drivers written in
Lisp would turn Linux into LispOS. Even if you got CMUCL into a
kernel module, I think much harder part would be to make it
possible to "hook" your Lisp stuff into various parts of the
system (and make it replace behaviour etc., like it is possible
in, for example, Genera (based on what I've read from Rainer's
WWW-pages)). In other words, I don't think you could do much
that kind of things people seem to associate with a LispOS with
your CMUCL-in-kernel.
As I've been involved in driver development with the rest of our
company, I have toyed with these ideas before. I have usually
just thought about using some Scheme->C type of compiler (whose
output should be able to live with minimal dependencies/support
to/from the environment (except for possible fancy GC)) to
compile drivers but that's all. Even in this case, not to talk
about "deeper hooking", it would take some effort to make all
interfaces available _and_ so that your Lisp-view into kernel
would track the changes on the C side. This is to be considered
especially with Linux that supports many platforms (and thus
there are many inline-functions, macros etc. to take care of
addressing buses and such) and is bit more moving target than
others. In this respect, the situation might be better with,
say, QNX (commercial, with /very/ limited support for different
platforms and lacks some nice features, so out of the question
at least for me) where drivers are normally (always? -- I can't
remember anymore, it's few years since I've touched it) separate
processes with same access to OS services as normal
applications.
Not to disappoint you, though! Worth mentioning is that the
author of SCM Scheme interpreter has written a Windows NT driver
for his hardware (also modelled and simulated with Scheme, IIRC)
in Scheme with a compiler he wrote for that purpose. So I'm sure
that what you suggest could be done (even feasibly) at least in
some restricted form. On the other hand, I'd personally take one
more step away from kernel...
Now having said that you may not be able to actually accomplish
much with your CMUCL-in-kernel, the next question is whether you
even need to. I don't want to ask whether you _want_ to or not
(because then some LispOS kernel hacker emerges and claims
there's a death penalty for questioning that :). [I'm not saying
there would be no advantages with Lispified kernel, but I doubt
that those advantages are not practically materialized unless
you write (almost) everything in Lisp.] However, when you think
about Linux kernel, it's just a bunch of little (green?) men who
shovel data from NIC to you, from you to hard disk controller
and so on. And Linux does that pretty well. I haven't had chance
to use a real Lisp machine so I'm probably not the right person
to make guesses, but I'd _think_ that one could get 95% of the
real LispOS features without doing all that in Lisp. I mean
features that /really/ make you feel you are finally home :)
Just compile everything you can as modules, say init="/bin/lisp
-core /the-wonderful-world-of-lispos.core" and there you go. You
can figure out configuration for drivers in user space and load
them, control and query lots of stuff via procfs, do your own
initialization with information from persistent object stores
etc. If procfs or POSIX APIs aren't enough and you need, for
example, some additional VM support, _then_ you could sleep over
it and if you still think it is neccessary, write a little
module to provide suitable "window" into the kernel. If you do
it well, you _might_ even get it to the official kernel tree --
after all, there is special support code for Wine and DOSEMU
already. Let Linux kernel people do all the magic that is needed
with all that more or less broken hardware and concentrate on
usability.
just some thoughts,
//Hannu
On 16 Dec 1998 01:47:59 +0200, Hannu Koivisto <·····@iki.fi.ns> wrote:
> Not to disappoint you, though! Worth mentioning is that the
> author of SCM Scheme interpreter has written a Windows NT driver
> for his hardware (also modelled and simulated with Scheme, IIRC)
> in Scheme with a compiler he wrote for that purpose. So I'm sure
He seems to be doing neat things at the bare metal level with Scheme. For
more info check:
http://www-swiss.ai.mit.edu/~jaffer/SIMSYNCH.html
Paolo
--
Paolo Amoroso <·······@mclink.it>
·····@cip.informatik.uni-wuerzburg.de (Matthias Buelow) writes:
> In article <··············@blinky.bfr.co.il>
> ·······@bfr.co.il (Harvey J. Stein) writes:
>
> >On the other hand, CMUCL compiles directly, so it might be easier to
> >build it directly into the kernel.
>
> You want a 20 megs unpageable kernel?
I guess the 1st thing that'd have to be implemented would be pagable
kernel memory. :)
--
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il
·······@bfr.co.il (Harvey J. Stein) writes:
>
> ·····@cip.informatik.uni-wuerzburg.de (Matthias Buelow) writes:
>
> > In article <··············@blinky.bfr.co.il>
> > ·······@bfr.co.il (Harvey J. Stein) writes:
> >
> > >On the other hand, CMUCL compiles directly, so it might be easier to
> > >build it directly into the kernel.
> > You want a 20 megs unpageable kernel?
> I guess the 1st thing that'd have to be implemented would be pagable
> kernel memory. :)
You mean like we had in the 1970s?
Probably too hard to do...
Christopher C Stacy <······@world.std.com> writes:
> > I guess the 1st thing that'd have to be implemented would be pagable
> > kernel memory. :)
>
> You mean like we had in the 1970s?
> Probably too hard to do...
This discussion has actually been done to death on the
kernel-developers lists (at least when I still read them regularly).
In essence it always seemed like a bad idea, since the Linux kernel is
tiny, especially when compared to kernels that do implement pageable
kernel memory. And implementing this feature would add so much
complexity to the kernel, that you might actually end-up with a much
bigger non-pageable part of the kernel (look at NT, whose non-pageable
part of the kernel is bigger than most Linux kernels).
If one wanted to do this, I'd rather suggest switching to a
micro-kernel based OS, possibly running Linux as one personality (see
L4-Linux at http://os.inf.tu-dresden.de/L4/LinuxOnL4/). This would
also allow you to run existing Linux/Unix applications in parallel to
your developing LispOS. This would also spare you much trouble you
will run into welding a 20MB CMUCL to the Linux kernel, both of which
were never intended for this kind of thing.
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Harvey J. Stein wrote:
>...
> On the other hand, CMUCL compiles directly, so it might be easier to
> build it directly into the [linux] kernel.
>
> Any takers?
>
Maybe Harvey J. Stein will do it ??
Kelly Murray <···@IntelliMarket.Com> writes:
> Harvey J. Stein wrote:
> >...
> > On the other hand, CMUCL compiles directly, so it might be easier to
> > build it directly into the [linux] kernel.
> >
> > Any takers?
> >
>
> Maybe Harvey J. Stein will do it ??
If he could get some of the micro-kernel people interested, he'd
probably get some academics to help him. LispOS and Linux running on
top of L4, there should be a number of papers in this...
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Kelly Murray <···@IntelliMarket.Com> writes:
> Harvey J. Stein wrote:
> >...
> > On the other hand, CMUCL compiles directly, so it might be easier to
> > build it directly into the [linux] kernel.
> >
> > Any takers?
> >
>
> Maybe Harvey J. Stein will do it ??
I'm sure he will ;>
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre Mai <····@acm.org> writes:
> Kelly Murray <···@IntelliMarket.Com> writes:
>
> > Harvey J. Stein wrote:
> > >...
> > > On the other hand, CMUCL compiles directly, so it might be easier to
> > > build it directly into the [linux] kernel.
> > >
> > > Any takers?
> > >
> >
> > Maybe Harvey J. Stein will do it ??
>
> I'm sure he will ;>
The idea is bizzare enough that I might actually try to give it a spin
just for the hell of it. But, with respect to actually contributing
to The Cause (tm), I am on record for advocating writing applications
as opposed to kernel hacking.
In response to one poster who, when I implored that people write
applications, challenged me to start writing, I'd like to reply that I
*am* writing/helping out, but with Guile, not with any of the really
good implementations (cmucl, rscheme, ...). It's frustrating because
I believe the two initial design choices (basing it on scm & forking
from scm) were wrong from the start and are still causing substantial
problems. None the less, I expect that because of the FSF, guile will
ultimately be the one member of the Lisp family implementation that
one can expected to be available on all Linux platforms, and thus a)
it's important to help clean it up, and b) it'll give my applications
the biggest user base.
So, I was predominantly suggesting this kernel hacking for those who
are more enamoured with kernel hacking.
As for the objections that such hacks lack practicality or usefulness,
I'd like to point out that it's *just* supposed to be a hack, more for
entertainment than utility, and it does seem pretty amusing to me.
None the less, I think actually that building such Frankenstein
monsters would be useful. At the very least it would be useful in
learning about kernels and Lisp and how the issues involved in making
existing implementations play together in various ways.
Furthermore, I think the particular points brought up regarding the
uselessness of such endeavors are overstated. I'll address some of
them here.
Chris Reedy <······@mitretek.org> writes:
> Nice dream ... Unfortunately, I think you first have to deal with
> the problems associated with supporting (anything like) Lisp in an
> OS kernel. The particular problems I see are support for garbage
> collection and exceptions.
>
> Let's see ...exceptions ... I could write code that didn't use
> exceptions. It would involve some pain, but not too much. I'd have
> to think about what I would do with calls to error, etc.
>
> Garbage collection on the other hand ... I don't even want to think
> about writing garbage free Lisp code (I've heard it can be done, I
> don't think I want to do it.) So I'd have to have a garbage
> collecting kernel. Now there's an interesting idea. Unfortunately,
> you'd probably have to do a complete rewrite of the kernel to
> accomplish that.
GC would be a nice thing to have in the kernel. And it would be
difficult to have for the kernel as a whole. But a Lisp module which
had an internal memory interface (including GC) based on kernel
supplied memory services shouldn't be much more difficult than a user
space lisp which depends on malloc/free for space.
As for exceptions, I suppose whether or not it's easy to have them
inside of a lisp module depends on exactly how they're implemented in
the lisp system. I don't think such blanket statements that they're
impossible/difficult to support inside of the kernel code are really
supportable.
Pierre Mai <····@acm.org> writes:
> This discussion has actually been done to death on the
> kernel-developers lists (at least when I still read them
> regularly). In essence it always seemed like a bad idea, since the
> Linux kernel is tiny, especially when compared to kernels that do
> implement pageable kernel memory. And implementing this feature
> would add so much complexity to the kernel, that you might actually
> end-up with a much bigger non-pageable part of the kernel (look at
> NT, whose non-pageable part of the kernel is bigger than most Linux
> kernels).
It seems like you're saying that it's bad for the Linux kernel because
the kernel is so small anyway. Well, it won't be small once CMUCL is
in it! :) So, I don't think the argument applies. Also, consider the
size of the kernel on Dave Miller's 14 CPU sun box with >1gb of ram.
I think it was something like 56mb. Not large as a part of total ram,
but large none the less. Maybe the scale of things is sufficiently
different on large boxes (or with CMUCL inside (tm)) that paging makes
sense.
> If one wanted to do this, I'd rather suggest switching to a
> micro-kernel based OS, possibly running Linux as one personality (see
> L4-Linux at http://os.inf.tu-dresden.de/L4/LinuxOnL4/). This would
> also allow you to run existing Linux/Unix applications in parallel to
> your developing LispOS. This would also spare you much trouble you
> will run into welding a 20MB CMUCL to the Linux kernel, both of which
> were never intended for this kind of thing.
The fact that it was never really intended actually makes it more fun.
You're encouraging the experiment now! In any case, MkLinux also
applies (the one built on top of MACH), not to mention that MIT thing
with the kernel just mediating hardware access (directly, *without*
abstraction) & libraries doing everything else. But, yes, I'm sure
any of these would form a better foundation for a quality LispOS, but
they won't make it as widely available as a direct Linux kernel hack.
It also is perhaps less portable (L4 & Fiasco only run on ix86, where
as Linux runs on ix86, sparc, alpha, ...) and probably supplies far
fewer drivers thus giving much sparser hardware support.
Also, since I'm actually in favor of lisp applications running on
Linux, it's interesting to see how much linux can be converted into a
lisp machine. It's also natural (in a twisted sort of way) if you
have the applications, to start migrating parts of lisp itself into
the kernel.
Hannu Koivisto <·····@iki.fi.ns> writes:
> Would it, really? I don't think one or two drivers written in
> Lisp would turn Linux into LispOS. Even if you got CMUCL into a
> kernel module, I think much harder part would be to make it
> possible to "hook" your Lisp stuff into various parts of the
> system (and make it replace behaviour etc., like it is possible
> in, for example, Genera (based on what I've read from Rainer's
> WWW-pages)). In other words, I don't think you could do much
> that kind of things people seem to associate with a LispOS with
> your CMUCL-in-kernel.
I don't think so. Once you had Lisp Inside (tm), you would next
import the foreign structures and functions from the kernel so that
you could interact with kernel state from Lisp. You mention the
issues involved in this in your next paragraph. I agree there's much
work (bcause macros, inline fcns, etc), but gcc parses the crap, so
it's doable. In any case, then you'd start migrating parts of the
kernel into the lisp module. So actually, I think one would be able
to do quite a lot with it.
<snipping out cited paragraph>
> Not to disappoint you, though! Worth mentioning is that the
> author of SCM Scheme interpreter has written a Windows NT driver
> for his hardware (also modelled and simulated with Scheme, IIRC)
> in Scheme with a compiler he wrote for that purpose. So I'm sure
> that what you suggest could be done (even feasibly) at least in
> some restricted form. On the other hand, I'd personally take one
> more step away from kernel...
I don't think he really wrote it in scheme. I think he wrote scheme
like code which can be converted directly into C. In any case, this
sort of thing is another possibility for writing modules in scheme &
linking them into the kernel.
> Now having said that you may not be able to actually accomplish
> much with your CMUCL-in-kernel, the next question is whether you
> even need to. I don't want to ask whether you _want_ to or not
> (because then some LispOS kernel hacker emerges and claims
> there's a death penalty for questioning that :). [I'm not saying
> there would be no advantages with Lispified kernel, but I doubt
> that those advantages are not practically materialized unless
> you write (almost) everything in Lisp.] However, when you think
> about Linux kernel, it's just a bunch of little (green?) men who
> shovel data from NIC to you, from you to hard disk controller
> and so on. And Linux does that pretty well. I haven't had chance
> to use a real Lisp machine so I'm probably not the right person
> to make guesses, but I'd _think_ that one could get 95% of the
> real LispOS features without doing all that in Lisp. I mean
> features that /really/ make you feel you are finally home :)
I completely agree here. As I said, I'm also in the applications
camp. I should have made the disclaimers against kernel hacking
clearer.
> Just compile everything you can as modules, say init="/bin/lisp
> -core /the-wonderful-world-of-lispos.core" and there you go. You
> can figure out configuration for drivers in user space and load
> them, control and query lots of stuff via procfs, do your own
> initialization with information from persistent object stores
> etc. If procfs or POSIX APIs aren't enough and you need, for
> example, some additional VM support, _then_ you could sleep over
> it and if you still think it is neccessary, write a little
> module to provide suitable "window" into the kernel. If you do
> it well, you _might_ even get it to the official kernel tree --
> after all, there is special support code for Wine and DOSEMU
> already. Let Linux kernel people do all the magic that is needed
> with all that more or less broken hardware and concentrate on
> usability.
Absolutely. This is the "correct" way of doing it, as far as I'm
concerned. But for those with the heart of a kernel hacker, I thought
that hacking lisp into the Linux kernel in various ways might make
appealing projects, and also yield various sorts of benefits.
--
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il
·······@bfr.co.il (Harvey J. Stein) writes:
> > If one wanted to do this, I'd rather suggest switching to a
> > micro-kernel based OS, possibly running Linux as one personality (see
> > L4-Linux at http://os.inf.tu-dresden.de/L4/LinuxOnL4/). This would
> > also allow you to run existing Linux/Unix applications in parallel to
> > your developing LispOS. This would also spare you much trouble you
> > will run into welding a 20MB CMUCL to the Linux kernel, both of which
> > were never intended for this kind of thing.
>
> The fact that it was never really intended actually makes it more fun.
> You're encouraging the experiment now! In any case, MkLinux also
> applies (the one built on top of MACH), not to mention that MIT thing
Mach (that is the later versions of mach, since earlier versions were
just monolithic kernels to begin with) is a first-generation
micro-kernel, which means it's really huge, and slow. Look at the
performance comparissons between MkLinux and LinuxPPC. L4/Fiasco,
like many other second generation micro-kernels is _actually_ small,
and performs reasonably well (see comparison between Linux and
L4Linux). The advantage of Fiasco is that it's GPL'd, which most
other micro-kernels I know aren't.
> with the kernel just mediating hardware access (directly, *without*
> abstraction) & libraries doing everything else. But, yes, I'm sure
I don't know what you mean, but IMHO the above is (part of) the definition
of micro-kernels. Normal kernels do hardware-abstraction, micro-kernels
let servers/libraries do hardware-access and abstraction.
> It also is perhaps less portable (L4 & Fiasco only run on ix86, where
> as Linux runs on ix86, sparc, alpha, ...) and probably supplies far
> fewer drivers thus giving much sparser hardware support.
L3/L4 have been ported to other architectures, and porting Fiasco
does seem trivial compared to plugging CMUCL into Linux ;) And
Fiasco doesn't supply any drivers. It's the L4Linux Server that
does supply the drivers, and they are the same that Linux 2.0.21
did, since L4Linux is in-sync with Linux 2.0.21...
> Also, since I'm actually in favor of lisp applications running on
> Linux, it's interesting to see how much linux can be converted into a
> lisp machine. It's also natural (in a twisted sort of way) if you
> have the applications, to start migrating parts of lisp itself into
> the kernel.
Well, yes, but I still think that going the direct way is wasted
effort. I'd be very surprised if this didn't take a _huge_ amount of
work and result in a bloated, buggy, and intolerably slow kernel.
Besides the feeping fun of doing it, I don't think much interesting
will come out of it, besides maybe another bad design show-case, but
the mainstream is providing enough of those already, IMHO. But don't
let me put you off (I know you will ignore my rambling anyways ;)...
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre Mai <····@acm.org> writes:
> ·······@bfr.co.il (Harvey J. Stein) writes:
>
> > applies (the one built on top of MACH), not to mention that MIT thing
> > with the kernel just mediating hardware access (directly, *without*
> > abstraction) & libraries doing everything else. But, yes, I'm sure
>
> I don't know what you mean, but IMHO the above is (part of) the definition
> of micro-kernels. Normal kernels do hardware-abstraction, micro-kernels
> let servers/libraries do hardware-access and abstraction.
Which microkernels are you refering to exactly? AFAIK, one still
typically communicates with the microkernel via message passing or
some other mechanism to make requests for various kinds of things like
memory or IPC. They typically present some sort of unifying
abstraction of the underlying hardware to the applications.
The MIT thing I was talking about is the MIT Exokernel Operating
System, which is a little closer to the silicon:
http://www.pdos.lcs.mit.edu/exo.html
Quote:
An operating system is interposed between applications and the
physical hardware. Therefore, its structure has a dramatic impact
on the performance and the scope of applications that can be built
on it. Since its inception, the field of operating systems has been
attempting to identify an appropriate structure: previous attempts
include the familiar monolithic and micro-kernel operating systems
as well as more exotic language-based and virtual machine operating
systems.
Exokernels dramatically depart from this previous work. An
exokernel eliminates the notion that an operating system should
provide abstractions on which applications are built. Instead, it
concentrates solely on securely multiplexing the raw hardware: from
basic hardware primitives, application-level libraries and servers
can directly implement traditional operating system abstractions,
specialized for appropriateness and speed.
I also left out the always soon to be released Flux OSkit
(http://www.cs.utah.edu/projects/flexmach/).
BTW, http://www.cs.arizona.edu/people/bridges/os/microkernel.html has
a nice list of microkernel projects.
--
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il
In article <··············@orion.dent.isdn.cs.tu-berlin.de>
Pierre Mai <····@acm.org> writes:
>L4Linux). The advantage of Fiasco is that it's GPL'd, which most
>other micro-kernels I know aren't.
What an advantage.. with the result that it can only be used in GPL'ed
operating systems (by now I only know Gnu/Linux which is licensed that
way). MACH can be (and actually is being) used in various commercial
(and non-commercial) systems, like for example Digital Unix, to name a
commercial product.
--
Matthias K. Buelow * Boycott Micro$oft, see http://www.vcnet.com/bms/ *
·····@cip.informatik.uni-wuerzburg.de (Matthias Buelow) writes:
> >L4Linux). The advantage of Fiasco is that it's GPL'd, which most
> >other micro-kernels I know aren't.
>
> What an advantage.. with the result that it can only be used in GPL'ed
> operating systems (by now I only know Gnu/Linux which is licensed that
> way). MACH can be (and actually is being) used in various commercial
> (and non-commercial) systems, like for example Digital Unix, to name a
> commercial product.
I don't wont to be misunderstood here: I've never joined the group of
those that believe GPL is somehow superior to all other licencing
schemes. Indeed I'd personally prefer something at least as
unrestrictive as BSD-style licensing.
IIRC I already pointed out why MACH (at least in the forms I know of),
is _not_ the kind of "micro-kernel" I have in mind[1]. And of the other
second-generation micro-kernels I know about, Fiasco has one of the
more liberal licenses, which sadly still is only GPL.
If you can name me another second-generation micro-kernel (i.e. _NOT_
MACH!) that has a more liberal licence, I'm all ears...
OTOH I still believe that more useful work can be done with helping
maintain a free CL implementation (CMUCL is actually PD, so no GPL
problem here ;), or writing a CL Emacs, or any other kind of
application or library code. Playing around with micro-kernels might
be nice
Regs, Pierre.
Footnotes:
[1] Just as a side-note to Digital Unix, born OSF/1: If I understand
correctly, both the OSF and DEC had some non-trivial problems with
OSF, not totally unrelated to MACH...
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
In article <··············@orion.dent.isdn.cs.tu-berlin.de>, Pierre Mai wrote:
>If you can name me another second-generation micro-kernel (i.e. _NOT_
>MACH!) that has a more liberal licence, I'm all ears...
Andrew Valencia's Vsta. It is GPLed and rather complete/usable system
already. The source code is very nice. Unfortunately I currently can't
find the URL for it.
>[1] Just as a side-note to Digital Unix, born OSF/1: If I understand
>correctly, both the OSF and DEC had some non-trivial problems with
>OSF, not totally unrelated to MACH...
OSF/1 was based on Mach2, which never claimed to be a micro kernel.
But I agree that Mach (both 2 and 3) are pigs.
-Andi
··@colin.muc.de (Andi Kleen) writes:
> Andrew Valencia's Vsta. It is GPLed and rather complete/usable system
> already. The source code is very nice. Unfortunately I currently can't
> find the URL for it.
Another reader of this group has already pointed me at Vsta (to be
found at http://www.zendo.com/vsta/). I have not had the time to look
deeply into it, though...
> OSF/1 was based on Mach2, which never claimed to be a micro kernel.
Yes, and it has been suggested that Mach3's historic growth out of
Mach2 (wasn't OSF/1 actually based on Mach2.5, like NextStep was at
some time in it's history?) was one of the factors that made Mach3
not very successful at providing the benefits of a micro-kernel with
sufficient performance and clarity of design...
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
··@colin.muc.de (Andi Kleen) writes:
> In article <··············@orion.dent.isdn.cs.tu-berlin.de>, Pierre Mai wrote:
> >If you can name me another second-generation micro-kernel (i.e. _NOT_
> >MACH!) that has a more liberal licence, I'm all ears...
>
> Andrew Valencia's Vsta. It is GPLed and rather complete/usable system
> already. The source code is very nice. Unfortunately I currently can't
> find the URL for it.
http://www.zendo.com/vsta/
--
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il