Re: [elysium-developers] Miscellaneous

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

"Rogelio M. Serrano Jr." wrote:
> > > Why don't we use ASH's (Application Specific Handlers)?
> > > Isn't that the way it is done on XOK?
> >
> > As the solution to what?
> 
> Interrupt handling. But then we still have to see how to run the interrupt handler.
> In its own task or within the context of the inerrupted  task. We currently use the
> former scheme right?

Yes, we do. But I'm not sure ASHs is the right solution. Personally I
would rather go for the 

> > > Can we use the I/O permission map to control access to io ports?
> > >
> > That's the plan. Each address space will have it's own I/O permissions.
> >
> I see. That also means a TSS for each address space.

Not necessarily. I'm planning to use only one TSS. To make it work the
I/O permission bitmap will simply be mapped differently in different
address spaces. That's why each address space - and not each process -
has it's own I/O permissions. The other parts of the TSS will be shared
among all processes.

> > > Can we do capabilities the way it was done in Amoeba?
> >
> > What do you mean? Securing them by means of encryption?
> >
> Yes and more. Revocation would simply involve changing a random number.
>
> Like:
> struct cap {
>    int own_pid;
>    int obj_id;
>    int rights;
>    /* random number which is a copy of random number stored in protected object */
>    long check; 
> };
>
> Revocations would be simpler this way.

If capabilities are to reside in - unprotected - user space we'll need
to use encryption, but AFAIK revocation isn't easier with encrypted
capabilities than with clists in kernel space (IMHO it would be easier
with the kernel controlled clists). 

/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