l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Let's do some coding :-)


From: Bas Wijnen
Subject: Let's do some coding :-)
Date: Wed, 19 Oct 2005 16:29:19 +0200
User-agent: Mutt/1.5.11

Hi,

The current discussions on the list are very interesting.  I'm happy to see
the project getting more attention. :-)  Also, it stimulates me to start
writing some code for it, and I hope I'm not the only one. :-)

First of all, given the theoretical issues being discussed, any code which is
written at this point will most likely be discarded when we will go for the
final solution.  The reason I want to write code anyway is to get a feeling
for what must be done.

There are two things which are really important IMO.  The first one is a
filesystem.  The second one is device drivers, in particular hard disk.

I still haven't really looked into it, but since banner could be compiled, I
suppose there already is some kind of terminal driver.

I would think that with a filesystem, we should be able to compile a shell
(perhaps not with libreadline, depending on the state of the terminal).  With
a shell, we have a system which looks almost usable.  All we have to do then
is to compile some programs. :-)  And of course, since a filesystem without
device drivers will be backed by a RAM-disk, a hard disk driver would be very
welcome.  :-)

So what do we need for a filesystem?
  libc support, mostly.  I took a brief look in the source, and it seems there
  are just some functions which need to be implemented.  In particular
  readdir and read, etc.  I didn't see open, though.  Is that because readdir
  returns some structure containing a pointer to it or something?

To make the shell work, we should obviously have a working fork and exec as
well.  Not sure what's needed for that.

I was planning to use capabilities in a very simple manner: Use pointers in
server memory or indices in a (server-side) table of pointers.  Capability
copy is easy, revocation is impossible, and there is no security.  Make some
functions to handle them:
- copy
- map
- unmap (which doesn't do anything)
- transfer (do copy or map, whatever is primitive)
- invoke
- maybe some more which I didn't think of right now

Then when we have a real solution (with protection), it can be inserted
without much change.  Or if we junk all the code, we still gained some
experience with the mechanisms. :-)

I didn't really think it through yet (and I don't think I will until I'm
writing code), so I'm sure there are some things which don't make sense.

I look forward to any comments.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]