Flux toolkit as LispOS base

[Dwight Hughes]

| From: Martin Cracauer <cracauer@wavehh.hanse.de>
| 
| Dwight Hughes writes:
|  
| > I very much agree -- there are actually two potential sources of
| > Unixisms and crippling. The Linux/*BSD kernel is one but the other
| > is CMUCL. No fault of theirs but it was written *for* such systems
| > -- as a result it contains whatever compromises, workarounds, or
| > low-level changes were necessary to get it to run decently on such
| > kernels. In short, it is warped to fit a hostile environment.
| 
| Is this comment backup up by real observation?

Not yet, merely a stray thought until I can come up to speed on all
the assorted parts of this project. You say "put up or shut up" very
nicely <g>.
 
| I think that CMUCL in fact *minimized* its Unix dependencies and that
| it does very much in Lisp and on the base of lower level abstractions
| than normal Unix kernel/ C-library semantics.
| 
| For example, it organizes its memory by getting memory areas using
| mmap. It manages allocation or individual portions itself. I doesn't
| use malloc, it doesn't use sbrk. What CMUCL uses from the operating
| system is not much more than direct access to what the MMU gives
| you. It can't be easier to move this to plain hardware. Of course,
| CMUCL has C portions, noticeable the low-level debugger and much of
| its process control, making heavy use of Unix signals.
| 
| But what CMUCL uses from Unix signals are more or less direct
| interfaces to the hardware, too.
| 
| I hope I'm not mistaken here, but my impression from this discussion
| is that people who vote against Unix signals forget that the hardware
| is quite rough, too. I can't imagine you want the underlying OS to
| provide higher-level signaling mechanism, what we want to pull
| abstraction levels into Lisp, no?
| 
| So, you will take these low-level signals (or hardware exceptions, for
| that matter) from your Lisp world anyway, no matter if you are on a
| Unix kernel, an OSkit kernel or directly on the hardware. 
| 
| The difference is just that you do more or less of the pre/post signal
| processing stuff from Lisp, but if it is clear what you want you can
| modify any kernel you have source for, too.
| 
| Please, *if* I'm mistaken, please post some examples where you think
| that Unix signals make things worse than what the hardware
| provides. I'm very interestedt.

This is not really my point of view of the "problem" (assuming
for the moment that one exists). The most elemental actions of
reading from/writing to/setting/clearing/... hardware are done the
same way by everyone, since the hardware dictates what must be
done -- what is done next (or before) is another matter and is
tied up in the mechanisms and models and representations
one uses to present the functionality of the hardware to
the rest of the "kernel" and ultimately to the rest of the
system. Mechanisms and models that work dandy for Unix may
not fit into the scheme of an OS that is reflective down
to its lowest levels (to give an example) or will cause some
considerable addition of complexity to do an "impedance match"
-- while models and representations that roar for us may suck
for Unix. I don't think we can view a design even at this low
level independent of what we will put on top of it - there is
no absolute *best* solution - only the best for our purposes.
I am certainly no lover of Unix but I would hope there
*are* models or even code we will want to keep - just that much
work we don't have to do. As for examples, those should be
forthcoming in a month or so after I study things a bit (or
maybe not - I might find I'm full of it <g>).
 
| > We must use care not to propagate this into the core of the LispOS.
| > Starting with a mostly clean slate with the Flux OStoolkit should
| > allow us to properly identify and correct most such problem spots.
| 
| > I'm not against using CMUCL, it is only that we should keep this in
| > mind and not warp our environment to fit a tool that was warped to
| > fit unix-style kernels.
| 
| What we have to do is to replace the alien calls CMUCL uses with our
| new functionality. It's as simple as that: Just replace the alien
| function *definition* with a Lisp *implementation*. It's a single line
| of Lisp code. As long as we still load a C library (which interfaces
| to the Unix kernel system calls), all the functions are loaded into
| CMUCL, but a loaded alien symbol isn't used unless you have an alien
| function definition.

This would make porting to something like the Flux OStoolkit somewhat
less horrendous than I had thought.
 
| Unless you implement everything in Lisp (booting Lisp directly on
| hardware), you will probably keep a C library with OS service
| calls. And even here, CMUCL's interface is well-suited to use C code
| without an Unix around it. It calls alien functions by a fixed address
| in the code, it doesn't rely on the OS to tell it at runtime.
| 
| Happy Lisping
| 	Martin
| -- 
| %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
| Martin Cracauer <cracauer@wavehh.hanse.de>
| http://cracauer.cons.org
| Fax +49 40 522 85 36 
|