Re: Kernel support for peer-to-peer protection models...
From: Pavel Machek
Date: Sat Mar 27 2004 - 10:08:20 EST
> 1) had a large number of distinguishable address spaces
> 2) any running code had two of these (code and data environment) it could
> use arbitrarily, but access to addresses in others was arbitrarily protected
> 3) flat, unified virtual addresses (64 bit) so that pointers, including
> inter-space pointers, have the same representation in all spaces
Hmm, will it be possible to have UML?
> 4) no "supervisor mode"
Is all your i/o memory mapped?
> 5) inter-space references require grant of access (transitive) by the
> accessed space; grants can be entire space or any contiguous subspace
> 6) inter-space reference has same performance as intra-space
Huh? Does it mean that all the accesses are horibly slow?
> 9) Hardware interrupts are involuntary inter-space calls. They do not
> require locking (assuming the handler is re-entrant - and if not then only
> from themselves), nor task switch, nor disabling other interrupts. The
> handler runs in the stack of whoever got interrupted, which (depending on
> interrupt priorities) could be another interrupt, on an interrupt, ... on an
> app, all mutually protected.
How do you implement ptrace if apps are protected from kernel?
> 10) Drivers can have their own individual space(s) distinct from those of
> the kernel and the apps. Buggy drivers cannot crash the kernel.
Well... buggy drivers can usually program DMA to do crashing for them.
How is your architecture called?
> dealing with protection models, interrupts, trap handling and the like? What
> about partitioning the kernel into disjoint (and mutually protected)
> components like IP stack, password/security, FS etc?
That would be pretty big rewrite...
Anyway, I believe you *do* want linux on it, if only as a test load.
64 bytes from 188.8.131.52: icmp_seq=28 ttl=51 time=448769.1 ms
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/