[coyotos-dev] coyotos.ioperm

[Jonathan S. Shapiro]

The ioperm capability is removed as of specification v0.6.

Ioperm wasn't a good idea. We may need to re-introduce it, but here are
the issues:

On most architectures, I/O is memory mapped. For these architectures
what we need is either

  a) an IOpage abstraction, or
  b) a physical memory page abstraction with the ability to make that
     page non-cacheable.

I have not yet decided which way to go on this. We have enough bits in
memory capabilities to do either solution.

x86 is unique in having an I/O port space. This isn't really a proper
address space at all, because it isn't mappable. On this architecture we
have three choices:

  1. Make I/O rights be all or nothing. This is what the EROS IOperm
     capability did, and what the Coyotos IOperm capability was intended
     to do.

  2. Come up with a way to memory map the IO bitmap. This is the
     solution that I prefer, but there are complications.

We need to look at this very soon. I'm hoping to come up with a solution
where:

  1. Application specifies base virtual address of its IO bitmap (if
     any).
  2. Pages mapped at that address must be IO pages, which hold the
     bitmaps.

Not sure where this is going to end up at this point, but it's a
relatively small issue.

Since we're about to start fairly intensive work on the kernel I suspect
this will get resolved pretty soon.


BTW: Thanks for asking this, because talking about the cachability hints
reminded me of something else I forgot to do in the spec.


shap

On Thu, 2007-04-05 at 22:27 +0200, Valerio Bellizzomi wrote:
> I lost its traces in the March 30 spec update.
> 
> Where is it gone ?
> 
> 
> val
> 
> 
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev