elysium-developers

Re: [elysium-developers] NE2000 specification

[Kasper V. L. <ve...@da...>]

Returning from IRQ handlers
----

You actually use sys_yield() to return from an IRQ handler -  take a look at
the init/src/keyboard.{S,c} and init/include/keyboard.h.

As it is now the IRQ handler will not receive any prologue or epilogue
upcalls, and it's free to run for any number of time slices. This has to be
fixed in a later release.

/Kasper

Re: [elysium-developers] NE2000 specification

[Adam L. <ag...@li...>]

On Wed, Feb 23, 2000 at 01:50:39PM +0100, Kasper Verdich Lund wrote:
> A specification of NE2000 (among other interesting things) can be found
> here:=20
> http://www.acm.uiuc.edu/sigops/rsrc/
This looks quite good

sys_irq_hook (1, cr3, _irq4_wrapper, irq_stack);

But how do you hook interrupts? The kernel calls _process_run with cr3, and=
 so
on as above. But then what do you do? You can't ret in _irq4_wrapper because
the kernel installed a new stack, so there is no return address. You can't
do a prolog because it isn't your quantum and I don't think you should yeild
because it's an interrupt and you'll confuse cpu.c.

AGL

--=20
Smoking is one of the leading causes of statistics.

Re: [elysium-developers] PCT

[Adam L. <ag...@li...>]

On Wed, Feb 23, 2000 at 03:05:48PM +0100, Kasper Verdich Lund wrote:
> [snipped something about crappy floppy controllers]
>=20
> Yeah, it's probably really difficult to get working. How about looking at
> the Linux sources?
>=20

floppy.c is 4500 lines long and deals w/ every device under the sun. I tend
to look at old sources (I've got linux 0.0.1), but the early kernels didn't
have floppy support. I'll go hunting.

AGL

--=20
Smoking is one of the leading causes of statistics.

Re: [elysium-developers] Capabilities

[Adam L. <ag...@li...>]

The end of my phone cable broke off. If you're getting this, I guess the=20
chocolate block worked ;)

On Wed, Feb 23, 2000 at 01:22:38PM +0100, Kasper Verdich Lund wrote:
> Each process will have a list of capabilities (c-list), which can be
> mapped read-only to the process (and other processes).=20

So you are going for the in-kernel, per-process table system. That's ok.

> The first entry
> in the list (entry 0) will hold the process capability for the any given
> process.

Well here you are talking like 'normal' capabilites. How can there be a
process capability if they do not encode objects?
=20
> The capabilities are ordered in a hierarchy. One way of implemented the
> capability would be:
<snip>=20
> This means that the capability with the name 1.3 will dominate the
> capabilities 1.3.1, 1.3.4.5.6, and 1.3.6 - but not 1.4 or 2.

So really they aren't capabilites at all, just a hierarchy of users.

> Using the Capabilities
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The kernel should protect physical pages, I/O port ranges, and CPU
> quantums with capabilities. As an example consider mapping in a page
> from memory protected by a capability. The system call you should use is
> sys_pte_set(). A protected implementation could look like this:
>=20
> int
> sys_pte_set(uint32_t ptbl, uint32_t pte, uint32_t entry, int cap_index)
> {
>   if (page[pte].status !=3D PAGE_FREE)
>     {
>       if (!cap_dominates(current_process->clist[cap_index],
> page[pte].cap_guard)) return -1;
>     }
>   else
>     {
>       page[pte].cap_guard =3D clist[cap_index];
>     }
>   ptbl[entry] =3D pte;
> }

This means that if you grant a process a certain 'access', you grant it
everything needing that access, or less. It's the *NIX-root problem again.

> Comments? Good ideas?

I *hope* they are good :-)

> P.S.: The design described here is pretty close to the design used in
> Xok (the MIT exokernel).=20

I'd be interrested in reading their finding on this system, if they have an=
y.
=20
> P.P.S.: The term 'capability' might be a bit misused in this discussion.
> Normally a capability encode an object, but the capabilities in this
> design merely represents access rights. Maybe we should change the name
> to EAR (a TLA, which means encoding of access rights). :-)

Well, I'd suggest using real 'capabilites', not EARs.

Let me try something like this:
struct cap {
    int obj_type;
    int obj_id;
    int obj_meth;
    int access;
};

'int' might not be the right datatype for some of these, but that's not
important right now. This system encodes an object and an access. The @acce=
ss
field would be a bitmap like:

#define CAP_READ   1 << 0
#define CAP_WRITE  1 << 1
#define CAP_DELETE 1 << 2
#define CAP_APPEND 1 << 3

etc...

The @obj_type would be something like process, mem_page, I/O port etc. The=
=20
@obj_id would define the actual process, memory page or port etc. The=20
@obj_meth would be one more level (like the method of a server).

A process would be granted capabilies when it started, in well known table
indexes. Like STDIN, STDOUT and STDERR are fd 0, 1 and 2 in *NIX.=20

Lets say a process wanted to give another read-access to one of it's pages.=
 It
would make a capability.

obj_type =3D CAP_MEMPAGE
obj_id =3D <the page number>
obj_meth =3D 0   /* Not used */
obj_access =3D CAP_READ

It would then send this to the kernel. The kernel would check that it had *=
at
least* read access to the page, and give it the capability (returning the i=
ndex
id). It could then give the capability to the other process, like you descr=
ibe.

For another example: a server.

The server generates the capability:

obj_type =3D CAP_PROCESS
obj_id =3D get_pid()
obj_meth =3D MY_SERVER_METHOD_READ;
access =3D CAP_READ | CAP_WRITE

It could then give the capabilites to any process it wants. When they do a =
PCT,
they (via the kernel) present the capability. The server checks the obj_met=
h and
access fields and does the requested work.

This (IMHO) is a far better system. I would recommend this paper:
http://www.eros-os.org/essays/capintro.html

As good reading.

AGL

--=20
Smoking is one of the leading causes of statistics.

Re: [elysium-developers] PCT

[Kasper V. L. <ve...@da...>]

[snipped something about crappy floppy controllers]

Yeah, it's probably really difficult to get working. How about looking at
the Linux sources?

/Kasper

-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218             | Phone: (+45) 8942 5680
Email: ve...@da...  | WWW: http://www.daimi.au.dk/~verdich/

Re: [elysium-developers] PCT

[Adam L. <ag...@li...>]

> > I think we should start writing some floppy driver code.
>=20
> I'll see what I can dig up regarding h/w datasheets
=20
<after a morning of coding>

Yuk! Whoever designed floppy controlers should be *shot*. What a pile of cr=
ap.

(If you can't guess, I'm fed up with writing floppy code, which isn't worki=
ng ;)

AGL

--=20
Smoking is one of the leading causes of statistics.

[elysium-developers] NE2000 specification

[Kasper V. L. <ve...@da...>]

A specification of NE2000 (among other interesting things) can be found
here:

http://www.acm.uiuc.edu/sigops/rsrc/

/Kasper

-- 
-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218              | Phone: (+45) 8942 5680
Email:  ve...@da...  | WWW: http://www.daimi.au.dk/~verdich

[elysium-developers] Capabilities

[Kasper V. L. <ve...@da...>]

This posting describes some thoughts on handling capabilities in
Elysium. Comments are welcome and expected.

Capabilities in Elysium
=======================

Each process will have a list of capabilities (c-list), which can be
mapped read-only to the process (and other processes). The first entry
in the list (entry 0) will hold the process capability for the any given
process. To create new capabilities a process uses the (as of now
un-implemented) sys_cap_set() system call:

int
sys_cap_set(int cap_no, cap_t cap, int cap_dom_no)
{
  if (cap_no == 0 || cap_no > CLIST_LENGTH) return -1;
  if (!cap_dominates(clist[cap_dom_no], cap)) return -1;
  clist[cap_dom_no] = cap;
  return 0;
}

The cap_dominates() function returns true iff the first argument is a
capability that has more access rights than the second argument. This
way a process cannot create capabilities that extends the access rights
of the process. 

The capabilities are ordered in a hierarchy. One way of implemented the
capability would be:

typedef struct cap_s
{
  uint32_t perm_bits;
  uint8_t name_length;
  uint8_t name[8];
} cap_t;

If we disregard the permission bits for a moment the cap_dominates()
could be implemented like:

bool
cap_dominates(cap_t c1, cap_t c2)
{
  if (c1.name_length > c2.name_length) return false;
  if (c1.name[0..c1.name_length-1] == c2.name[0..c1.name_length-1])
    return true;
  else
    return false;
}

This means that the capability with the name 1.3 will dominate the
capabilities 1.3.1, 1.3.4.5.6, and 1.3.6 - but not 1.4 or 2.

Any process can request read-only access to the c-list of a given
process. A typical server can rely on the fact that capabilities cannot
be changed directly by applications, and can therefore do all
authentication itself. To transfer capabilites between two processes we
can implement system calls - sys_get_cap() and sys_transfer_cap() -
which can used like this:

* process A wants to transfer a capability to process B
* process A calls sys_transfer_cap() with the correct cap index, and the
pid of process B.
* process A uses some IPC mechanism to tell process B that the
capability is ready for it.
* process B calls sys_get_cap() with the two correct cap indices, and
the pid of process A.
* the capability from the clist of process A is copied to the clist of
process B.
* process B uses some IPC mechanism to tell process A that it has
claimed the capability.

Using the Capabilities
======================
The kernel should protect physical pages, I/O port ranges, and CPU
quantums with capabilities. As an example consider mapping in a page
from memory protected by a capability. The system call you should use is
sys_pte_set(). A protected implementation could look like this:

int
sys_pte_set(uint32_t ptbl, uint32_t pte, uint32_t entry, int cap_index)
{
  if (page[pte].status != PAGE_FREE)
    {
      if (!cap_dominates(current_process->clist[cap_index],
page[pte].cap_guard)) return -1;
    }
  else
    {
      page[pte].cap_guard = clist[cap_index];
    }
  ptbl[entry] = pte;
}

Issues with Capabilities
========================
It's obvious that one physical resource might be perfectly legal to read
from (requiring almost no access rights), but only accessible for
writing by a few processes. If a memory page only has one capability
guard it's difficult to handle this situation correctly.

Comments? Good ideas?

/Kasper

P.S.: The design described here is pretty close to the design used in
Xok (the MIT exokernel). 

P.P.S.: The term 'capability' might be a bit misused in this discussion.
Normally a capability encode an object, but the capabilities in this
design merely represents access rights. Maybe we should change the name
to EAR (a TLA, which means encoding of access rights). :-)

-- 
-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218              | Phone: (+45) 8942 5680
Email:  ve...@da...  | WWW: http://www.daimi.au.dk/~verdich

Re: Exo-graphical systems (Was: [elysium-developers] PCT])

[Claus M. <cla...@ma...>]

> The basic philosophy behind exokernels, which has been discussed elsewhere
> on this site is here applied to user interface systems. This means that we
> have to apply the most important design principle of exo-kernels:
>
> * Multiplex resources of underlying systems without enforcing any
> abstractions that aren't strictly necessary for protection.
>
> In the kernel case the underlying system is the hardware.

I agree that this is a more precise description, and so I'll replace the
bit.

> The key thing to remember is that exo-systems are about not making any
> abstractions that aren't strictly necessary for protection. Traditional
> micro-kernels provide as few and as general abstractions as possible, but
> even though they are designed to be general there are several applications
> for which they fail miserably.
>
> * all privileged abstractions (necessary for protection) should be put in
> the kernel or privileged servers
> * all unprivileged, non-shared abstractions should be placed in libraries
> * some unprivileged, shared abstractions could be placed in unprivileged
> servers

Onco again I agree, but there is a point to be made here: As you correctly
write, only shared abstractions should be put in servers - unpriviledged
servers, of course, I never intended it otherwise. One key point I am trying
to make is, though, that abstractions are generally not shared *enough*.
Neither Gnome/X, Windows, BeOS can provide the flexibility we desire because
they cannot offer sound abstractions properly.

> I've got a thesis on 'Flexible and Efficient Sharing of Protected
> Abstractions' by George M. Candea, which explains how MIT has built shared
> abstractions on top of their exokernel without using unprivileged servers.

I would of course like to read it - but I am not principally against
servers, and think they often provide a good abstraction. We should of have
more than absolutely necessary, but I fear that avoiding them completely
could make things messy. After all, a user would be quite contend to lose
3-5% processing power in exchange for at 20% increase in his own work
efficiency. Still, I would be glad to read it.

> As an aside it should be noted that there are advantages - at least one -
of
> putting abstractions into servers (instead of tossing them into
libraries).
> Servers allow for higher levels of distribution. OTOH it might be too
slow.

Precisely my point. I am quite willing to sacrifice a small performance loss
for programs using servers. I think the design of the server structure
should follow the general outline of a display server, though; No server
should enforce standards by checking all operations on, for example, paper.
They should instead try to check things only when it is their concern - for
instance when something is commited in some way. If the server is only
invoked once every 5 seconds, the performance loss is miniscule.
Combinations of libraries and servers are also an option.

And now for Adam's comment:

> You have some great ideas on graphical handling,

Well, thanks! :-)

> but I must contest this point.

Oh, shoot. :-(

> I assume elysium is going to be a proper O/S, with multiple users as in
*NIX.
> I don't want the kernel to have to know anything about users, and enforce
> permissions, I see some logon process taking a username&passwd and then
> spawning a shell with the correct capabilities for that 'user'.

>Now if we have many processes, with differing permissions we *cannot* allow
>the keyboard data to be sent to all of them. For example, if someone is
telneted
>onto the same box as me, they could run a program that saves all keystokes
>(because we "distribute keyboard commands to all processes that request
it")
>and he could capture my GPG passphrase etc, as I type it. This is not a
>solution.

> The problem is that the kernel doesn't know anything about 'focus'. Also
many
> processes can have 'focus', because there can be many keyboards. Only one
> wired to the box, but many over a network.

> We could have a keyboard server that sends the data on to the correct
process,
> but if there are keyboards over a network, this means that it must handle
> network data too. This means lots of abstractions.

> I can't really think of a good solution at the moment. Anyone?

You are quite right. Once again I turn to my server architecture (look, i'ts
not that I love servers. They're just so d*mn handy sometimes). The keyboard
server descides which process has the focus when the system starts - the
login process, for instance. The login process does not "talk" to the
keyboard via the server, it does so directly. When this process has finished
(the keyboard server can just be programmed to let it have keyboard Focus
until the login is satisfied), the next keyboard lending process gets the
Focus. This could be a fancy keyboard server with country codes, perhaps
even with code that allows they keyboard input to be sent directly via the
network. Once again, the priviledged servers does not, like normal servers,
run constantly - they are only invoked whenever Focus has to change,
something that happens rarely, even in human time spaces.

That's my best bid for the moment. Comments are, as always, welcome.

- xmentor

Re: [elysium-developers] PCT

[Adam L. <ag...@li...>]

> I think we should start writing some floppy driver code.

I'll see what I can dig up regarding h/w datasheets

> Other hot topics would drivers for network adapters....
Despite the fact that they are the standard netcard, I can't find *any* doc=
s on
NE2000 programming ;(=20
=20
> We need to get some people to work on SMP support.

I *hope* to be getting an SMP box quite soon. If I do (fingers crossed - I =
run
a P100 at the moment!), I should be able to help.

> * capabilities (related to the previous entry)

Well, from what little I know about O/S design there are 3 ways of doing
capabilities:
    * In kernel, per-process tables. (Like file descriptors in *NIX), each
      process gets it capabilites stored in the table and can't touch them
    * Capabilites are stored in protected pages (e.g. EROS) so it can't cha=
nge
      them.
    * Capabilites are crypto protected, usally using MAC's

Personally, I like the openness of the 3rd option, but there are good reaso=
ns
for the others (e.g. you can't brute force them open)

AGL

--=20
Smoking is one of the leading causes of statistics.

Re: Exo-graphical systems (Was: [elysium-developers] PCT])

[Adam L. <ag...@li...>]

On Mon, Feb 21, 2000 at 06:56:38PM +0100, Claus Matthiesen wrote:
> Keyboard handling has not been discussed that elaborately, but it seems we
> can safely distribute keyboard commands to all processes that request it.
> They know if they're focused, so if they have no need for keyboard input
> when they are not displayed, they can safely ignore it.

You have some great ideas on graphical handling, but I must contest this po=
int.
I assume elysium is going to be a proper O/S, with multiple users as in *NI=
X.
I don't want the kernel to have to know anything about users, and enforce
permissions, I see some logon process taking a username&passwd and then
spawning a shell with the correct capabilities for that 'user'.

Now if we have many processes, with differing permissions we *cannot* allow
the keyboard data to be sent to all of them. For example, if someone is tel=
neted
onto the same box as me, they could run a program that saves all keystokes
(because we "distribute keyboard commands to all processes that request it")
and he could capture my GPG passphrase etc, as I type it. This is not a
solution.

The problem is that the kernel doesn't know anything about 'focus'. Also ma=
ny
processes can have 'focus', because there can be many keyboards. Only one
wired to the box, but many over a network.

We could have a keyboard server that sends the data on to the correct proce=
ss,
but if there are keyboards over a network, this means that it must handle
network data too. This means lots of abstractions.

I can't really think of a good solution at the moment. Anyone?

AGL

--=20
Smoking is one of the leading causes of statistics.

[elysium-developers] PCT support added

[Kasper V. L. <ve...@da...>]

Hi,

I've commited the kernel patch done by Adam - basic PCT support is now
available.

/Kasper

-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218              | Phone: (+45) 8942 5680
Email:  ve...@da...  | WWW: http://www.daimi.au.dk/~verdich

Re: Exo-graphical systems (Was: [elysium-developers] PCT])

[Claus M. <cla...@ma...>]

Her er et udkast til en tekst om exografiske interfaces til hjemmesiden.
Kommentarer er velkomne.


Thoughts on exo-interface systems


The basic philosophy behind exokernels, which has been discussed elsewhere
on this site are here applied to user interface systems. This actually means
that we have to apply the two most important features of exo-kernels:



a)     Application of as few and as general abstractions as possible

b)     Possibility for direct access to underlying systems (the hardware in
the kernel case)



Let us try to imagine the OS from the point of view of a user - specifically
an architect. Now, the architect has to make a presentation of a project he
is working on. Typically some of the material needed has been made and some
has yet to be made. He has not used the computer earlier in the process, so
let us assume he has made some models and sketches. He has to import photos
of the models, he has to import scans of his sketches, he has to make some
technical drawings CAD-style, he has to make a 3d-representation of his
project and render those to 2d-images and he has to assemble all this is on
a piece of paper - typically A1 or A0 (in Europe, at least). If he made this
in Windows (or Linux/X, System X, BeOS, etc.) he would conceptually start an
application (possibly CorelDraw or Adobe Illustrator) and start lay outing
the project. He would soon find out that Adobe Illustrator is prohibitively
difficult to write text in, so he would start Word up, write the text,
import it in Illustrator and set it up. Pictures would be scanned and
prepared in Adobe PhotoShop, AutoCAD would probably deliver the technical
drawings, 3dStudioMax would deliver the 3d-representation, etc. All of these
steps would require knowledge of file types and conversion between them,
loss of data and/or accuracy, repetitive actions and sometimes even direct
errors. All this, because the programs involved does not know each other's
abstractions.

It might seem strange to make a system designed for avoiding abstractions
deliver just such abstractions. The key thing to remember is, that
exo-systems are not about not making abstractions; it is about making as few
and as general ones as possible. This fits our scheme very well, because for
instance the page concept used by Word is very insufficient for a program
working like CorelDraw.

Another thing to take into account when designing interface systems is the
common user - for instance our architect. The architect does not really care
about programs at all. What does he need? He needs an abstraction for
images, one for sheets of paper, one of texts, one for virtual 3d-spaces in
which he can create the shapes he needs, he needs an abstraction for
technical 2d-representations of this 3d-space, ideally created without him
lifting a finger directly from the 3d-space representation. He does not need
an abstraction for programs, ports or icons. These concepts are (useful)
concepts from the view of the programmer; were he has almost always failed
is in recognizing that this representation is inadequate for a common user.

Exo-systems' have one prominent feature - they result in the creation of
several servers that supply abstractions. The kernel makes an abstract
representation of simple kernel functions, such as address spaces. The
Elysium OS will probably sport a graphics server, making screens available
as representation. If we expand this concept we may have a sheet server.
When asking the server for something, you ask it for a sheet of paper. You
are now the only process with access to this particular sheet. You might
then supply your own abstractions: A sheet might contain frames like a
screen contains view, for instance. All programs matching your frame
specification will be able to cooperate with your process on this concept.
Both Word, PageMaker and CorelDraw would be able to do something useful with
this format. An image is likewise created when asking for an image from the
image server, a 3d space from the VR server and so forth. This would make
implementing ToolGlasses or Markup Menus very easy, since they are just
servers providing proper abstractions for overlay operations on objects from
other servers.

What about the inter-program cooperation? It is obvious that it should still
be possible to make a program CorelDraw-style that works completely on
itself (since exo systems, may we never forget it, should not enforce but
offer abstractions), but it would be interesting to create programs that
work entirely on server objects. This is of course the primary area of
research currently since the abstractions we need to provide must never be
more constraining than least possible. The abstractions must also be strong,
easy to use and worthwhile. The primary server that we need to provide is a
Graphics Server, a Window Server, a Pointing Device Server and a Block
Device Server. Work on these are progressing (this document being one sign
of progress), and later the need for a ToolGlass server and a Sheet Server
will become significant.



xmentor, 21/02 2000

RE: Exo-graphical systems (Was: [elysium-developers] PCT])

[Kasper V. L. <ve...@da...>]

> Lemon curry?

Yes, I believe so.

/Kasper

Exo-graphical systems (Was: [elysium-developers] PCT])

[Claus M. <cla...@ma...>]

This is a snippet of an earlier post on which I'd very much like to comment:

> * <vage> How will the kernel demultiplex the console and keyboard?
>   Currently all the processes outputting can get a little strange. They
>   mustn't be allowed to write to the screen unless they have 'focus',
>   and maybe a keyboard handling process that handles the keyboard IRQ
>   and sends it on (via PCT) to the right process?


First I think I'd better introduce myself; My name is Claus Matthiesen, and
I study architecture at the AAA, the Aarhus School of Architecture. The
reasons why I am involved in this project are many, but my primary interest
is the interface between the computer and the user. The philosophy behind
Exo kernels can easily ve regarded as more than a technical one, and thus
Kasper V. Lund and I have spent some time evolving a general *principle*
behind Exo systems. It is my concern that this principle is extended to
include at least the graphical system. On a more elaborate description of
the general principles, I refer to our new web page, which (hopefully, God
be willing, etc.) will be up shortly.

Anyway, on to the question in hand. The thought that only one process at any
time may be allowed to write to a screen - not "the screen", as we might
expect there to be more than one - has also occured to us. One might make a
distinction between text interfaces and graphical interfaces and allow -
much like Windows or X does - that more than one process might have the
screen, or at least a window or view within the screen to write in. This
approach is of course rather useful seen from at desktop application's view
and rather less appealing from the viewpoint of a game or other graphically
heavy applications with an interface significally different from the common
desktop. As the Exo principle certainly dictates that: a) No (or at least
very few) abstractions must be enforced by the system, though it might offer
them as a possibility; b) Any process should have the possibility to access
the hardware it uses directly; - this approach is entirely unsatisfactory.
We must remember, however, that it must be *possible* to write a normal
desktop application on the lines of Microsoft Word (to take a much hated
example). The idea we have now looks something like this:

There is a process owning what we might call the screen Focus. Ideally one
process might own more than one Focus, allowing the two screens on a Matrox
G400 dualhead or Max, for instance, to be controlled by a single process. It
should also be possible to have several Focus-owning processes running at
once, but of course one one screen always have one and only one Focus. Now
such a Focus-owning process might decide to lend it out to another process
upon request - Quake II, for instance. The Focus-owner does not have any
primitives for writing to the screen, as this would be enforcing an
unnecessary abstraction, so this must be supplied by the lender itself - in
most cases probably via an independent graphics driver library. Now the
process that owns the Focus might decide to recall it and lend it to someone
else, effectively making another process take over the screen. The processes
that are shifted in and out should of course be notified via RPC's or
something along those lines. Processes trying to acces the ports on the
graphics card without having the focus should be ignored or killed.

Now what about Desktop applications? Desktop applications will run under
some desktop manager or window manager. The window manager will hold the
Focus (or Focuses) to allow it to write to the screen(s) it wants to (or is
allowed to) write to. Now the window manager can deliver the primitives
needed by the normal desktop applications in views within the window
manager.

Keyboard handling has not been discussed that elaborately, but it seems we
can safely distribute keyboard commands to all processes that request it.
They know if they're focused, so if they have no need for keyboard input
when they are not displayed, they can safely ignore it.

A variation on this theme could be to simply not schedule processes that are
registered as graphical processes when they are unfocused. This means,
however, that we need to distingiush between graphical and non-graphical
processes, though we could simply say that processes that requested the
screen would not be scheduled unless they got it. It would also require that
the kernel was told by the graphics system what processes not to schedule -
a dangerous proposition, because possibly destructive processes, such as
viruses, might try to do the same thing. This method would, however, remove
the administrative costs of giving and taking the Focus. Overall the
disadventages seem to outweigh the advantages of this solution right now,
but comments are very welcome indeed.

In text-only modes the ideas discussed so far are just as applicable, and
would allow for a rather nifty implementation of Borland's old TurboVision
text-driven window library for instance.

It is clear that as time progresses, some sort of window manager is
required, since none of us are interested in having only full-screen
graphics-mode programs. I am currently sketching the first outlines of what
such an interface would have to offer, and many new approaches - marking
menus, toolglasses, (semi-)3d-interfaces and document-oriented interfaces
are being considered. This will all be available for comment, cooperative
development and flaming once our new site is up.

- xmentor (Claus)


Lemon curry?

RE: [elysium-developers] PCT

[Kasper V. L. <ve...@da...>]

> > [snipped something about the bug]
> You guessed it! Whats next on the TODO?

Well, Bastiaan, Claus, Jakob, and I are working on improving the web site
considerably, but unfortunately the site isn't quite done yet. I think we
should start writing some floppy driver code. Right now all applications
have full access to all ports so it should be fairly easy to do a simple
floppy disk driver. Once the floppy driver code is working we could
implement a basic filesystem (such as FAT12) on top of it. Other hot topics
would drivers for network adapters....

We need to get some people to work on SMP support. IMHO it has quite high
priority, and I would be delighted to see - at least - the APIC CPU
detection routines in a few weeks. I know Jakob is willing to do some work
on this part of kernel, but he'll probably need help. Anyone?

I'll be working on a kernel specification in the near future, and the plan
is to have a full specification in 2 or 3 weeks. The specification will
describe and explain the implementation of all the features the kernel
currently lacks. I probably need help writing this specification.

The kernel currently lacks support for:
* protection of resources, such as physical pages
* capabilities (related to the previous entry)
* protection of individual I/O ports
* SMP
* .... ?

/Kasper

Re: [elysium-developers] PCT

[Adam L. <ag...@li...>]

On Mon, Feb 21, 2000 at 02:04:41PM +0100, Kasper Verdich Lund wrote:
> > Fixed ;) Single letter typo (Doh!)
>=20
> Let me guess...
>=20
> 	pushl sys_pct_after=20
>=20
> should have been
>=20
> 	pushl $sys_pct_after
> =20
> :-)

You guessed it! Whats next on the TODO?

AGL

--=20
Smoking is one of the leading causes of statistics.

RE: [elysium-developers] PCT

[Kasper V. L. <ve...@da...>]

> Fixed ;) Single letter typo (Doh!)

Let me guess...

	pushl sys_pct_after 

should have been

	pushl $sys_pct_after
 
:-)

Re: [elysium-developers] PCT

[Adam L. <ag...@li...>]

Last post was too big ;(

Fixed ;) Single letter typo (Doh!)

I'm not going to commit this, but post the patches here because it's had
too many problems for me to be sure of a commit, and I want you to check it
first.

Attached files:
p.diff	-   patch in kernel/src
p2.diff	-   patch in kernel/include

Download these:
http://www.agl.uklinux.net/
t1.tgz	-   Test 1, based on init, it test PCT with...
t2.tgz	-   Test 2

e.g.
$ cd kernel/src
$ patch --dry-run -p0 < p.diff
<check for errors, if none>
$ patch -p0 < p.diff
<etc for include ..>

Walkthru:

It starts in t1/src/main.c:107
sys_pct_register (&_pct_entry);

This calls t1/src/syscall.S which moves the argument into EAX and calls in =
0x46
The kernel ends up in process.c:sys_pct_register. It stores the address of =
the
entry in pr_pct. t1 then goes into a loop printing "t1, heartbeat\n".

t2 is in a loop printing ("t2!\n") and calling sys_pct (0, 99), which goes =
to
t2/src/syscall.S:

sys_pct:
        movl    4(%esp),%ebx
	<move the data argument to EBX>
        movl    8(%esp),%eax
        <move the pid to jump to to EAX>
        pushl   $sys_pct_after
        <push the return address, so that when prolog calls ret, it jumps to
         sys_pct_after>=20
        pushal
        pushf
        <push other stuff for prolog>
        movl    %esp, _crt0_saved_sp
        <save ESP>
        int     $0x47
        <jump to kernel>

Kernel:
void
sys_pct (pid_t pid, uint32_t data)
{
  cpucontext_t *cpu =3D stack_get_cpu_context ();
  process_t *p;

  if (cpu->cpu_in_revocation) {
    /* FIXME: What to do here ? --AGL */
#ifdef DEBUG
    printf ("Eek!, sys_pct() while revoking CPU time!\n");
#endif
    return;
  }
  if (process_lookup (&p, pid) =3D=3D -1) {
     /* FIXME: What to do here ? --AGL */
#ifdef DEBUG
    printf ("Eek!, bad pid in sys_pct()\n");
#endif
    return;
  }

  /* We don't update the quantums as a PCT donates them.. --AGL */
  cpu->cpu_current_process =3D p;
  process_pct (cpu->cpu_current_process->pr_pid, data, p);
}

I don't know what to do about bad pids, or revokes. Currently it returns which
upsets the processes and they page fault. I'd suggest a return code (in EAX
maybe) that is *standard* for all syscalls. The processes can then check for
errors and cleanup and pass the error code up the call chain.

process_pct ends up in process.h:
_process_pct (calling_pid, data, p->pr_cr3, p->pr_pct, USER_CS, 0x3202, 0,
                USER_DS);

and that goes to process.S:

_process_pct:
        popl    %eax
        <clear the ret from the stack>
        popl    %eax
        <move the *calling pid* to EAX>
        popl    %ebx
        <move the data to EBX>
        popl    %ecx
        movl    %ecx,%cr3
        <setup page directory>
        iret
        <jump>
That goes to t1/src/syscall.S:

_pct_entry:
        /* This is the wrapper for PCT. It restores state, pushes the pid
           (given by kernel in EAX) and calls pct_entry. It then saves state
           and returns to code. --AGL
        */
        movl    _crt0_saved_sp, %esp
        <restore ESP>
        popf
        <setup saved flags (saved either by sys_pct or epilog)>
        push    %ebx
        <push the data into the stack>
        push    %eax
        <and the pid>
        call    pct_entry
        <this is in main.c>
        /* Better hope our stack is good --AGL */
        addl    $0x8,%esp
        <update the stack to remove the push'ed args>
        popal
        <pop all the registers that were saved>
        ret
        <jump back to wherever we were and eat up the quantums>

pct_entry in t1/src/main.c prints "t1, pct (pid,data)\n"
       
Problems:       
	* Error codes (as discussed above)
	* If pct_entry calls sys_pct the stack fills up with the pushal's
	* If pct_entry trashes the flags the process can get upset. Maybe
	  the flags should be popped off after calling pct_entry, but
	  what flags should be set?
	* <vage> How will processes setup shared memory. Currently they can
	  pass 32-bits per call, but really they want shared memory buffers.
	  Could they pass capibilities that can be given to the kernel to
	  setup the page tables?
	* <vage> How will the kernel demultiplex the console and keyboard?
	  Currently all the processes outputting can get a little strange. They
	  mustn't be allowed to write to the screen unless they have 'focus',
	  and maybe a keyboard handling process that handles the keyboard IRQ
	  and sends it on (via PCT) to the right process?
	 
AGL
	 
--
Smoking is one of the leading causes of statistics.

Re: [elysium-developers] PCT

[Adam L. <ag...@li...>]

On Sun, Feb 20, 2000 at 12:54:53PM +0100, Kasper Verdich Lund wrote:
> > Well I'm stuck again ;(
>=20
> Okay - let's see...

BTW: Im Nebulae on us.chatjunkies.org, #linux

> What's your strategy? Do you intend to let the called process return?
> When I did the IRQ handling stuff I made a mistake that produced strange
> results. I ran the IRQ handling process with _process_run() which
> changes the address space (by changing CR3), but on return I didn't
> change back.=20

Process 1 wants to jump to process 2:
It saves state so prolog can restore state=20
It sets up the pid in %eax
It sets a value in %ebx
int $0x47
kernel jumps to the PCT entry in process 2
process 2 does what it wants
at somepoint process 1 prolog is called and everything continues

> > All the movl    $xx,%ecx are debugging
> > t2 crashes with ECX=3D59 everytime (and I've put delay loops in to chec=
k it isn't
> > a timing thing).

Doh! The ECX came from prolog when it popal's. In sys_pct I push (in order):
pushl  0x10000950
pusha
pushf

Now prolog pops the flags and registers ok, but the ret seems to jump to
0xc35831eb

> I'm really worried about the SS =3D 0x00100023 - could you send me the
> code? I want to investigate :-)

SS is 16bit. Thus that 1 can't be there. It must be from the debug code that
prints the value

> =20
> > It must be that pushal crashing I think (because if it ever finished EC=
X would
> > change). But how does EIP go so wonkey?
>=20
> It's easy to mess up EIP - if you fail to maintain the stack properly a
> single 'ret' instruction will certainly do something like that.

But popal seems to restore all the registers to the correct values in prolo=
g,
which makes me think the stack is OK

> BTW: Let's make a debug system call (interrupt 3 would do fine) and let
> that dump some basic CPU information. That would be useful instead of
> the movl $xx,%ecx stuff :-)

It wouldn't have helped, but it sounds a good idea. Maybe we it could set t=
he
single-step flag (that would have been usful), if the kernel dumps state on
every instruction. Also maybe the kernel could write it to a serial port...

AGL

--=20
Smoking is one of the leading causes of statistics.

Re: [elysium-developers] PCT

[Kasper V. L. <ve...@da...>]

> Well I'm stuck again ;(

Okay - let's see...
 
> In t2 (the test program that currently does a PCT to t1) the asm code for
> sys_pct is thus:
> 
> sys_pct:
>         movl    $0x55,%ecx
>         movl    4(%esp),%eax
>         movl    $0x58,%ecx
>         pushl   sys_pct_after
>         movl    $0x59,%ecx
>         pushal
>         movl    $0x62,%ecx
>         pushf
>         movl    $0x60,%ecx
>         movl    %esp, _crt0_saved_sp
>         movl    $0x61,%ecx
>         movl    $0x57,%ecx
>         int     $0x47

What's your strategy? Do you intend to let the called process return?
When I did the IRQ handling stuff I made a mistake that produced strange
results. I ran the IRQ handling process with _process_run() which
changes the address space (by changing CR3), but on return I didn't
change back. 
 
> The prototype is:
> void sys_pct (int pid);

Fine.

> All the movl    $xx,%ecx are debugging
> t2 crashes with ECX=59 everytime (and I've put delay loops in to check it isn't
> a timing thing).
> 
> CS = 0x1b
> DS = 0x23
> SS = 0x00100023
> (that 1 is there again, but pushl sys_pct_after works...)
> EIP= 0xc35832eb
> ESP= 0x10001d0c
> (there's room on the stack yet)

I'm really worried about the SS = 0x00100023 - could you send me the
code? I want to investigate :-)
 
> It must be that pushal crashing I think (because if it ever finished ECX would
> change). But how does EIP go so wonkey?

It's easy to mess up EIP - if you fail to maintain the stack properly a
single 'ret' instruction will certainly do something like that.

/Kasper

BTW: Let's make a debug system call (interrupt 3 would do fine) and let
that dump some basic CPU information. That would be useful instead of
the movl $xx,%ecx stuff :-)

Re: [elysium-developers] PCT

[Adam L. <ag...@li...>]

On Sat, Feb 19, 2000 at 12:57:04PM +0100, Kasper Verdich Lund wrote:
> > Well I've got a quick PCT system working. It ends up w/
> >
> > _process_run (p->pr_cr3, p->pr_pct, USER_CS, 0x3202, 0, USER_DS);
>=20
> That looks okay.
>=20

Well I'm stuck again ;(

In t2 (the test program that currently does a PCT to t1) the asm code for
sys_pct is thus:

sys_pct:
        movl    $0x55,%ecx
        movl    4(%esp),%eax
        movl    $0x58,%ecx
        pushl   sys_pct_after
        movl    $0x59,%ecx
        pushal
        movl    $0x62,%ecx
        pushf
        movl    $0x60,%ecx
        movl    %esp, _crt0_saved_sp
        movl    $0x61,%ecx
        movl    $0x57,%ecx
        int     $0x47

The prototype is:
void sys_pct (int pid);

All the movl	$xx,%ecx are debugging
t2 crashes with ECX=3D59 everytime (and I've put delay loops in to check it=
 isn't
a timing thing).

CS =3D 0x1b
DS =3D 0x23
SS =3D 0x00100023
(that 1 is there again, but pushl sys_pct_after works...)
EIP=3D 0xc35832eb
ESP=3D 0x10001d0c
(there's room on the stack yet)

It must be that pushal crashing I think (because if it ever finished ECX wo=
uld
change). But how does EIP go so wonkey?

AGL

RE: [elysium-developers] PCT

[Kasper V. L. <ve...@da...>]

> Well I've got a quick PCT system working. It ends up w/
>
> _process_run (p->pr_cr3, p->pr_pct, USER_CS, 0x3202, 0, USER_DS);

That looks okay.

> But as soon as the called process tries to push to the stack it
> page faults. I
> didn't spend very long hunting, but anyway:
>
> SS = 0x00100023
> ESP= 0x0
> ESI= 0x0
> EBP= 0x00837000
> DS = 0x23
> CS = 0x1b

Apart from the extra 1 in the SS it seems correct. And as soon as the called
process tries to push something on the stack it SHOULD page fault. The
exception error code should probably indicate that it is an access rights
violation that caused the page fault (as opposed to a non-present page). The
value you try to push on the stack will be written into memory at 0xfffffffc
(which is a part of the read-only mapping of page tables and directories).
If you look at

init/src/crt/crt0.S

you'll see the following lines of code:

	.align	4
_crt0_prolog:
	movl	_crt0_saved_sp, %esp
	popf
	popal
	ret

	.align	4
_crt0_epilog:
	pushal
	pushf
	movl	%esp, _crt0_saved_sp
	int	$0x40

The prolog code is called with the _process_run() function and as you can
see the first thing it does is to set %esp to something sensible.

> Should SS have the extra 1 in it? I've got to order a new Insight
> from Intel,
> so I don't know the selector structure. But I don't think a bad
> selector would
> cause a page fault.

It cannot. AFAIK it should cause a GPF, but who knows what happens.

/Kasper

BTW: I'm working on a specification of the PCT and IRQ stuff - I'm looking
forward to seeing your work under CVS :-)

Re: [elysium-developers] User-level IRQ handling added

[Adam L. <ag...@li...>]

Well I've got a quick PCT system working. It ends up w/

_process_run (p->pr_cr3, p->pr_pct, USER_CS, 0x3202, 0, USER_DS);

But as soon as the called process tries to push to the stack it page faults=
. I
didn't spend very long hunting, but anyway:

SS =3D 0x00100023
ESP=3D 0x0
ESI=3D 0x0
EBP=3D 0x00837000
DS =3D 0x23
CS =3D 0x1b

Should SS have the extra 1 in it? I've got to order a new Insight from Inte=
l,
so I don't know the selector structure. But I don't think a bad selector wo=
uld
cause a page fault.

Thanks

AGL

--=20
Smoking is one of the leading causes of statistics.

Re: [elysium-developers] User-level IRQ handling added

[Adam L. <ag...@li...>]

On Thu, Feb 17, 2000 at 02:58:03PM +0100, Kasper Verdich Lund wrote:
> > > We still need to work on PCT (protected control transfer) - anyone?
> >=20
> > [snip] I've lost my Insight CD (damm!) but can you explain how the upca=
lling works? I've only used TSS before.
> >=20
> > popl %eax
> > popl %eax
> > movl %cr3,%eax
> > iret
> >=20
> > I think that's the code (from memory), it sets up the page tables but d=
oes the iret pop stuff off the argument stack? And does that drop the prive=
lage level?
>=20
> The code is correct. It doesn't set up any page tables, but it does
> change the page directory. The assembly code you've included in your
> posting is the implementation of a function with the following
> prototype:
>=20
> extern void _process_run(uint32_t cr3, uint32_t eip, uint32_t cs,=20
>                          uint32_t eflags, uint32_t esp,=20
>                          uint32_t ss) __attribute__ ((noreturn));
>=20

AH! Missed that ;) Sorry, everything is clear now

AGL

--=20
Smoking is one of the leading causes of statistics.