Reply to post: Re: It's BeOS, it's the OS

Google's Fuchsia OS Flutters into view: We're just trying out some new concepts, claims exec

LDS Silver badge

Re: It's BeOS, it's the OS

The issue with x86 is which code can access the I/O instructions and physical memory directly - most hardware usually use a combination of the two - being mapped to some I/O ports and physical addresses.

You can move both accesses up to userland, but then you lose some hardware security - the CPU itself won't allow user code to run those instruction or access that memory - and you need to deploy other security mechanism.

Anyway, even with multiple cores the issue is when a thread needs a ring transition - the required checks and call setting up require CPU cycles (even if they've been reduced by the SYSCALL/SYSENTER opcodes) - execution might not be passed to another thread on another core.

Your model would be message based - split the CPU between cores executing kernel and core executing user code - and pass messages between them. It could be less versatile if you don't know workloads in advance.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon


Biting the hand that feeds IT © 1998–2020