Long time lurker, but not by any means a LISP hacker. Quick question
to the LISP OS crowd: would it be easier to build a LISP OS on top of
VMWare? Anyone know anything about the virtual hardware provided in
the hosting environment? That would give everyone a standard hardware
base, and the rest of the OS could be built on top of that. After the
meat of the OS is built, interested parties could write the drivers for
non VMWare hardware (or bare metal).
Any merit to this, or should I just go back to lurking?
"James" <···········@gmail.com> writes:
> Long time lurker, but not by any means a LISP hacker. Quick question
> to the LISP OS crowd: would it be easier to build a LISP OS on top of
> VMWare? Anyone know anything about the virtual hardware provided in
> the hosting environment? That would give everyone a standard hardware
> base, and the rest of the OS could be built on top of that. After the
> meat of the OS is built, interested parties could write the drivers for
> non VMWare hardware (or bare metal).
>
> Any merit to this, or should I just go back to lurking?
Movitz already runs on bare metal. You can experiment with it within
bochs.
http://common-lisp.net/project/movitz/
Zach
Zach Beane wrote:
> "James" <···········@gmail.com> writes:
>
> > Long time lurker, but not by any means a LISP hacker. Quick question
> > to the LISP OS crowd: would it be easier to build a LISP OS on top of
> > VMWare? Anyone know anything about the virtual hardware provided in
> > the hosting environment? That would give everyone a standard hardware
> > base, and the rest of the OS could be built on top of that. After the
> > meat of the OS is built, interested parties could write the drivers for
> > non VMWare hardware (or bare metal).
> >
> > Any merit to this, or should I just go back to lurking?
>
> Movitz already runs on bare metal. You can experiment with it within
> bochs.
>
> http://common-lisp.net/project/movitz/
The CADR Lisp Machine source code and emulator might also be of
interest:
http://www.unlambda.com/cadr/index.html
http://www.heeltoe.com/retro/mit/mit_cadr_lmss.html
On Thu, 30 Nov 2006 06:11:54 -0800, James wrote:
> Long time lurker, but not by any means a LISP hacker. Quick question
> to the LISP OS crowd: would it be easier to build a LISP OS on top of
> VMWare?
Why not start at the top and build an Operating System top-down based on
Linux? You get a lot of (boring?) driver-work done for free, and you can
just wrap the parts you feel are too C'ish near the Linux and C-APIs in
Lisp-style APIs.
--
Lars Rune Nøstdal
http://nostdal.org/
On Nov 30, 7:40 pm, Lars Rune Nøstdal <···········@gmail.com> wrote:
> On Thu, 30 Nov 2006 06:11:54 -0800, James wrote:
> > Long time lurker, but not by any means a LISP hacker. Quick question
> > to the LISP OS crowd: would it be easier to build a LISP OS on top of
> > VMWare?Why not start at the top and build an Operating System top-down based on
> Linux? You get a lot of (boring?) driver-work done for free, and you can
> just wrap the parts you feel are too C'ish near the Linux and C-APIs in
> Lisp-style APIs.
>
> --
> Lars Rune Nøstdalhttp://nostdal.org/
About that, is there any lisp library that aim to provide lisp access
to things like
/etc/hosts or /etc/init.s/ ?
Or maybe a library would not be the right thing.. maybe simple some
filters to go
forth and back between the (each time particular) text representation
of the different
linux tools (could be scripts in perl or bash, ...), configuration
files and text output of other
tools, and sexp's.
Is my question (and underlying idea) is stupid because of some things I
don't see ?
(more practical tools ?)
Bye, Thu
On 9675 day of my life ······@gmail.com wrote:
>> Why not start at the top and build an Operating System top-down
>> based on Linux?
> About that, is there any lisp library that aim to provide lisp
> access to things like /etc/hosts or /etc/init.s/ ?
/etc/hosts and /etc/init.d are not part of Linux kernel. And you can
build a system atop of Linux kernel that use none of them.
So, you don't need such library.
--
Ivan Boldyrev
Violets are red
Roses are blue
It's amazing what DNA splicing can do.
On Sat, 02 Dec 2006 20:15:01 +0600, Ivan Boldyrev wrote:
> On 9675 day of my life ······@gmail.com wrote:
>>> Why not start at the top and build an Operating System top-down
>>> based on Linux?
>
>> About that, is there any lisp library that aim to provide lisp
>> access to things like /etc/hosts or /etc/init.s/ ?
>
> /etc/hosts and /etc/init.d are not part of Linux kernel. And you can
> build a system atop of Linux kernel that use none of them.
>
> So, you don't need such library.
I wonder what project tools like `ifconfig' are a part of. Where is their
source-code?
http://oldfield.wattle.id.au/luv/boot.html#kernel
I'm thinking `boot=/sbin/LispOS' ... :D
..this is actually quite interesting..
--
Lars Rune Nøstdal
http://nostdal.org/
On Boomtime, The Aftermath 45, 3172 YOLD, Lars Rune Nøstdal wrote:
> On Sat, 02 Dec 2006 20:15:01 +0600, Ivan Boldyrev wrote:
>
>> On 9675 day of my life ······@gmail.com wrote:
>>>> Why not start at the top and build an Operating System top-down
>>>> based on Linux?
>>
>>> About that, is there any lisp library that aim to provide lisp
>>> access to things like /etc/hosts or /etc/init.s/ ?
>>
>> /etc/hosts and /etc/init.d are not part of Linux kernel. And you can
>> build a system atop of Linux kernel that use none of them.
>>
>> So, you don't need such library.
>
> I wonder what project tools like `ifconfig' are a part of. Where is their
> source-code?
http://www.linuxfromscratch.org/ might be interesting for you (either
for reading, to know a how working Linux distro is built, or for
tinkering with it yourself - I had a system like this for about two
years on my desktop (until I needed to upgrade glibc the second time,
and there is no package management on bare system) and it was great to
learn Linux distro literally inside out).
> I'm thinking `boot=/sbin/LispOS' ... :D
>
> ..this is actually quite interesting..
You would need either some libc implementation (glibc, dietlibc,
uclibc...) and probably some helper utils/libraries to get at least
basic POSIX API layer and system tools (tools you could implement via
FFI to libc), or, alternatively, libc reimplementation in Lisp --
-- without libc layer all you have are system calls available as
interrupts.
Minimal system that boots (in Unix/C world) can consist only of libc
and busybox (just in case and maybe to do some initialization). I
don't know against exactly which libraries do Lisp implementations
link; SBCL's and Allegro CL's startup programs link only to libc
libraries (with pthread), so it should be possible to boot into a
system containing only libc, /dev, /proc and SBCL (or cmucl). Clisp
can be more tricky as it's implemented in C.
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...you know, the old Pa says:
,|{-}|}| }\/ uważaj na wilki, man... }
\/ |____/ ( Pogodno ) -><-
Maciek Pasternacki <·······@japhy.fnord.org> writes:
> You would need either some libc implementation (glibc, dietlibc,
> uclibc...) and probably some helper utils/libraries to get at least
> basic POSIX API layer and system tools (tools you could implement
> via FFI to libc), or, alternatively, libc reimplementation in Lisp
> -- -- without libc layer all you have are system calls available as
> interrupts.
It's not really clear to me that libc is a necessity in this
scenario. While libc does provide some functionality and a particular
abstraction layer, it also constitutes a substantial blob/bloat of
(user-space) foreign code that you need to deal with. You'll get a
stack of mixed libc and lisp functions (whereas kernel code will never
show up in the user stack), and probably a number of other problems
rooted in the fact that libc is a library designed specifically as a
substrate for applications written in C.
Btw. I think it would be fun and not a lot of work to retarget Movitz
to run directly on the linux kernel in this fashion.
--
Frode Vatvedt Fjeld
On Pungenday, The Aftermath 46, 3172 YOLD, Frode Vatvedt Fjeld wrote:
>> You would need either some libc implementation (glibc, dietlibc,
>> uclibc...) and probably some helper utils/libraries to get at least
>> basic POSIX API layer and system tools (tools you could implement
>> via FFI to libc), or, alternatively, libc reimplementation in Lisp
>> -- -- without libc layer all you have are system calls available as
>> interrupts.
>
> It's not really clear to me that libc is a necessity in this
> scenario. While libc does provide some functionality and a particular
> abstraction layer, it also constitutes a substantial blob/bloat of
> (user-space) foreign code that you need to deal with. You'll get a
> stack of mixed libc and lisp functions (whereas kernel code will never
> show up in the user stack), and probably a number of other problems
> rooted in the fact that libc is a library designed specifically as a
> substrate for applications written in C.
Yup, liblisp instead of libc would certainly be an interesting
project. OTOH, it's non-trivial, as I would expect bare kernel
interfaces to be underdocumented (as opposed to generally
POSIX-compliant libc API), and you lose cross-kernel portability.
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...as Mao Tsu says,
,|{-}|}| }\/ if Shit didn't Happen
\/ |____/ you'd Explode... } ( Apocrypha Discordia ) -><-
* Maciek Pasternacki <··············@lizard.king> :
|
| Yup, liblisp instead of libc would certainly be an interesting
| project. OTOH, it's non-trivial, as I would expect bare kernel
| interfaces to be underdocumented (as opposed to generally
| POSIX-compliant libc API), and you lose cross-kernel portability.
Perhaps the first movitz app should be a x86 emulator/vm on which one
could run linux. :)
That'd sure get the temptation to reuse stuff already out there out of
the way.
--
Madhu
On 9678 day of my life Lars Rune N�stdal wrote:
> I wonder what project tools like `ifconfig' are a part of. Where is their
> source-code?
It is a part of net-tools package.
https://developer.berlios.de/projects/net-tools/
net-tools functions are mostly wrappers around kernel syscalls. You
may write different wrapper in Lisp.
--
Ivan Boldyrev
Your bytes are bitten.
In article <······························@gmail.com>,
Lars Rune Nøstdal <···········@gmail.com> wrote:
> On Thu, 30 Nov 2006 06:11:54 -0800, James wrote:
>
> > Long time lurker, but not by any means a LISP hacker. Quick question
> > to the LISP OS crowd: would it be easier to build a LISP OS on top of
> > VMWare?
>
> Why not start at the top and build an Operating System top-down based on
> Linux? You get a lot of (boring?) driver-work done for free, and you can
> just wrap the parts you feel are too C'ish near the Linux and C-APIs in
> Lisp-style APIs.
It would be interesting to try to compile Linux against the Boehm-GC and
see what happens...
rg
Ron Garret wrote:
>
> It would be interesting to try to compile Linux against the Boehm-GC and
> see what happens...
I don't know about Linux, but other OSs often use very specialised
allocators, and several different ones for different purposes.
On 2006-11-30, Lars Rune N�stdal <···········@gmail.com> wrote:
> On Thu, 30 Nov 2006 06:11:54 -0800, James wrote:
>
>> Long time lurker, but not by any means a LISP hacker. Quick question
>> to the LISP OS crowd: would it be easier to build a LISP OS on top of
>> VMWare?
>
> Why not start at the top and build an Operating System top-down based on
> Linux? You get a lot of (boring?) driver-work done for free, and you can
> just wrap the parts you feel are too C'ish near the Linux and C-APIs in
> Lisp-style APIs.
>
If you want to do that minix3, http://minix3.org, might be a better
choice. The reason for this is that it does not have a kernel like
unix or windows, but has a task switching architecture that allows
each device to live in it's own address space so you can do a chunk
at a time and still have a working os while working on the os.
monolithic kernels make doing things like that harder, especially
if you are moving from C to Lisp.
marc
--
······@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
(message (Hello 'marc)
(you :wrote :on '(Fri, 1 Dec 2006 20:03:33 +0000 (UTC)))
(
ms> If you want to do that minix3, http://minix3.org, might be a better
ms> choice.
and Coyotos [1] might be even better choice:
---
The Coyotos project has several objectives:
...
Construct the kernel and key utilities in a new systems programming language
(BitC) with a well-defined, mechanically-specified semantics. This will
allow us to formally verify security and correctness properties of the
system and its key utilities
---
BitC is just a variant of Scheme (with strong typing/type inference), so
there's a few reasons to start something new.
1. http://www.coyotos.org/
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
James wrote:
> Long time lurker, but not by any means a LISP hacker. Quick question
> to the LISP OS crowd: would it be easier to build a LISP OS on top of
> VMWare? Anyone know anything about the virtual hardware provided in
> the hosting environment? That would give everyone a standard hardware
> base, and the rest of the OS could be built on top of that. After the
> meat of the OS is built, interested parties could write the drivers for
> non VMWare hardware (or bare metal).
>
> Any merit to this, or should I just go back to lurking?
You know, most Lisp environments are VMs, which is pretty much like an
OS within an OS. If you stay in sbcl (or your Lisp of choice) you get
a good deal of the benefits of a Lisp-OS. I know that there are people
who want to create a Lisp-on-Linux, which is already there with sbcl,
smucl, etc.
Chris Parker wrote:
> You know, most Lisp environments are VMs, which is pretty much like an
> OS within an OS. If you stay in sbcl (or your Lisp of choice) you get
> a good deal of the benefits of a Lisp-OS. I know that there are people
> who want to create a Lisp-on-Linux, which is already there with sbcl,
> smucl, etc.
Yes! And although I've been trying hard to avoid gratuitous
self-promotion, I guess I can't avoid it anylonger:
www.knowos.org
www.biobike.org
Enjoy! :-)