GNU Hurd on $scheme (was: [ANN] the Guile 100 Programs Project)

GNU Hurd on $scheme (was: [ANN] the Guile 100 Programs Project)

[Daniel Hartwig]

[Hello l4-hurd, I see you have been quiet lately.]

On 2 February 2013 01:28, Nala Ginrut <nalaginrut@gmail.com> wrote:
> On Fri, 2013-02-01 at 16:40 +0000, Ian Price wrote:
>> Heh, reimplementing coreutils in Scheme has been a plan of mine for a
>> while, as part of justifying my Iteratees library, but that has taken a
>> sideline to newer and shinier projects.
>>
>
> Maybe another new project, say, rewrite GNU with Guile, include part of
> HURD, heh? I even get the name, GoG, GNU on Guile. ;-P
>

Something I have thought about for some time.  Next on the TODO list :-)


There is a paper by Rees, _A Security Kernel Based on the
Lambda-Calculus_.  It discusses a Lisp dialect, Scheme¯, similar to
Scheme but with certain operations removed; in there place are some
logical guarantees with implications for security for any code written
in the dialect.  This is used to construct a security kernel, W7,
which becomes the basis for Scheme48 (a language supporting R5RS).

I don't want to get in to the details of the paper, I think that many
on this list will be familiar with it.  Suffice to say that the
security kernel provides concepts that closely map to a capability
model.  Also, verified processes can run within the same machine
process and I wonder if this has implications for the communication
overhead that microkernel systems tend to get labelled with.  In
theory the security kernel, core services, and any Scheme (and other)
language programs should be able to reside in the same process without
having to implement access restrictions beyond those implicit in the
language.

After bootstrapping my current pet project, I intend to explore the
ideas in this paper as they relate to the Hurd.  As I am quite fond of
Guile I plan to proceed roughly as follows:
- port Scheme¯ to the Guile language stack;
- get W7 or something similar running on this;
- implement required Hurd interfaces;
- port some of the current Hurd servers and userland to the Scheme in
this stack;
- …
- profit!

Maybe bypassing the first stages and use Scheme48 instead.

I believe having some sort of system running in Scheme would be very
useful for exploring design and architectural issues, regardless of
whether it is a practical or fast performing implementation.

Anyone interested in collaborating on such a project, or have comments
regarding the paper and the implications for the Hurd?  Nala, you
sound interested, and we will certainly benefit from some of the
userland being ported as part of the Guile 100 Programs Project.

Regards

Re: GNU Hurd on $scheme (was: [ANN] the Guile 100 Programs Project)

[Nala Ginrut]

On Sat, 2013-02-02 at 10:49 +0800, Daniel Hartwig wrote:
> [Hello l4-hurd, I see you have been quiet lately.]
> 
> On 2 February 2013 01:28, Nala Ginrut <nalaginrut@gmail.com> wrote:
> > On Fri, 2013-02-01 at 16:40 +0000, Ian Price wrote:
> >> Heh, reimplementing coreutils in Scheme has been a plan of mine for a
> >> while, as part of justifying my Iteratees library, but that has taken a
> >> sideline to newer and shinier projects.
> >>
> >
> > Maybe another new project, say, rewrite GNU with Guile, include part of
> > HURD, heh? I even get the name, GoG, GNU on Guile. ;-P
> >
> 
> Something I have thought about for some time.  Next on the TODO list :-)
> 
> 
> There is a paper by Rees, _A Security Kernel Based on the
> Lambda-Calculus_.  It discusses a Lisp dialect, Scheme¯, similar to
> Scheme but with certain operations removed; in there place are some
> logical guarantees with implications for security for any code written
> in the dialect.  This is used to construct a security kernel, W7,
> which becomes the basis for Scheme48 (a language supporting R5RS).
> 
> I don't want to get in to the details of the paper, I think that many
> on this list will be familiar with it.  Suffice to say that the
> security kernel provides concepts that closely map to a capability
> model.  Also, verified processes can run within the same machine
> process and I wonder if this has implications for the communication
> overhead that microkernel systems tend to get labelled with.  In
> theory the security kernel, core services, and any Scheme (and other)
> language programs should be able to reside in the same process without
> having to implement access restrictions beyond those implicit in the
> language.
> 
> After bootstrapping my current pet project, I intend to explore the
> ideas in this paper as they relate to the Hurd.  As I am quite fond of
> Guile I plan to proceed roughly as follows:
> - port Scheme¯ to the Guile language stack;
> - get W7 or something similar running on this;
> - implement required Hurd interfaces;
> - port some of the current Hurd servers and userland to the Scheme in
> this stack;
> - …
> - profit!
> 
> Maybe bypassing the first stages and use Scheme48 instead.
> 
> I believe having some sort of system running in Scheme would be very
> useful for exploring design and architectural issues, regardless of
> whether it is a practical or fast performing implementation.
> 
> Anyone interested in collaborating on such a project, or have comments
> regarding the paper and the implications for the Hurd?  Nala, you
> sound interested, and we will certainly benefit from some of the
> userland being ported as part of the Guile 100 Programs Project.
> 

Yes, I'm definitely interested on it. Several years ago, I decided to
become an OS hacker and I want to research OS design, but then I became
a language/compiler hacker after I read SICP, I don't know how it is...
Actually, I planed to implement MiG with Guile, but I delayed that since
I need to read many papers about Hurd which is worthy for the hack. 
Now this kind of OS, I can't find a good entrance for it, maybe this GNU
Hurd on $scheme project is a good way to start.
Anyway, count me in! ;-P

> Regards

Re: GNU Hurd on $scheme

[Ludovic Courtès]

Hi!

Daniel Hartwig <mandyke@gmail.com> skribis:

> [Hello l4-hurd, I see you have been quiet lately.]

:-)

> After bootstrapping my current pet project,

So you already started?

> Anyone interested in collaborating on such a project, or have comments
> regarding the paper and the implications for the Hurd?

I’m interesting in lurking, for a start.  ;-)

I think there are really two approaches: one is to augment the Hurd with
Guile APIs and servers, and another one is to write a Scheme OS (like
Göran’s http://weinholt.se/nygos/).  You’re taking the first one, right?

For the Hurd, I’d start by writing some sort of a MiG in Scheme macros.

Happy hacking!  :-)

Ludo’.

Re: GNU Hurd on $scheme

[Nala Ginrut]

On Sat, 2013-02-02 at 11:19 +0100, Ludovic Courtès wrote:
> Hi!
> 
> Daniel Hartwig <mandyke@gmail.com> skribis:
> 
> > [Hello l4-hurd, I see you have been quiet lately.]
> 
> :-)
> 
> > After bootstrapping my current pet project,
> 
> So you already started?
> 
> > Anyone interested in collaborating on such a project, or have comments
> > regarding the paper and the implications for the Hurd?
> 
> I’m interesting in lurking, for a start.  ;-)
> 
> I think there are really two approaches: one is to augment the Hurd with
> Guile APIs and servers, 

I've played Hurd in qemu few weeks ago, it's nice~
Was Guile ported to Hurd? (maybe there's no need for 'porting'?)

> and another one is to write a Scheme OS (like
> Göran’s http://weinholt.se/nygos/).  You’re taking the first one, right?
> 

Oh~man, that's crazy! And I've noticed it uses Guile for pre-process
something. Though it can't work for current Guile...

> For the Hurd, I’d start by writing some sort of a MiG in Scheme macros.
> 

yeah~MiG would be a good start I think ;-)


> Happy hacking!  :-)
> 
> Ludo’.
> 
> 

Re: GNU Hurd on $scheme

[Ludovic Courtès]

Nala Ginrut <nalaginrut@gmail.com> skribis:

> Was Guile ported to Hurd? (maybe there's no need for 'porting'?)

GNU/Hurd is hardly distinguishable from GNU/Linux or GNU/kFreeBSD from
user space, so there’s no porting needed.

Ludo’.

Re: GNU Hurd on $scheme

[Ludovic Courtès]

Hi!

Daniel Hartwig <mandyke@gmail.com> skribis:

> [Hello l4-hurd, I see you have been quiet lately.]

:-)

> After bootstrapping my current pet project,

So you already started?

> Anyone interested in collaborating on such a project, or have comments
> regarding the paper and the implications for the Hurd?

I’m interesting in lurking, for a start.  ;-)

I think there are really two approaches: one is to augment the Hurd with
Guile APIs and servers, and another one is to write a Scheme OS (like
Göran’s http://weinholt.se/nygos/).  You’re taking the first one, right?

For the Hurd, I’d start by writing some sort of a MiG in Scheme macros.

Happy hacking!  :-)

Ludo’.

Re: GNU Hurd on $scheme

[Daniel Hartwig]

On 2 February 2013 18:19, Ludovic Courtès <ludo@gnu.org> wrote:
> Daniel Hartwig <mandyke@gmail.com> skribis:
>> After bootstrapping my current pet project,
>
> So you already started?
>

“Any day now.”

> I think there are really two approaches: one is to augment the Hurd with
> Guile APIs and servers, and another one is to write a Scheme OS (like
> Göran’s http://weinholt.se/nygos/).  You’re taking the first one, right?

Primarily the second, I think.  Guile APIs for the Hurd will be
constructed, but I plan to implement from the security kernel down in
Scheme, the target environment having most of core servers and kernel
running in a single VM process.

How well that works in practice is anyones guess.

>
> For the Hurd, I’d start by writing some sort of a MiG in Scheme macros.
>

This should permit porting the servers without having a Scheme kernel, right?

Regards

Re: GNU Hurd on $scheme

[Ludovic Courtès]

Hey!

Daniel Hartwig <mandyke@gmail.com> skribis:

> On 2 February 2013 18:19, Ludovic Courtès <ludo@gnu.org> wrote:

[...]

>> I think there are really two approaches: one is to augment the Hurd with
>> Guile APIs and servers, and another one is to write a Scheme OS (like
>> Göran’s http://weinholt.se/nygos/).  You’re taking the first one, right?
>
> Primarily the second, I think.  Guile APIs for the Hurd will be
> constructed, but I plan to implement from the security kernel down in
> Scheme, the target environment having most of core servers and kernel
> running in a single VM process.

Hmm, the concept of servers really makes sense when you have unsafe
native code with separate address spaces.  Otherwise Scheme procedure
calls and threads (when needed) are basically equivalent, as Rees’ paper
suggests.  Or did I misunderstood the idea?

>> For the Hurd, I’d start by writing some sort of a MiG in Scheme macros.
>>
>
> This should permit porting the servers without having a Scheme kernel, right?

This would allow Scheme code to make RPCs to Hurd servers, and Hurd
servers to be implemented in Scheme.

Ludo’.