Weekly Edition
Return to the Kernel page
| |||||||||||||
Quote of the week
I wonder what a tiny, SANE register-based bytecode
interface might look like. Have a single page shared between kernel and
userland, for each thread. Userland fills that page with bytecode, for a
virtual machines with 256 registers -- where instructions roughly equate to
syscalls.
-- Jeff GarzikThe common case -- a single syscall like open(2) -- would be a single byte bytecode, plus a couple VM register stores. The result is stored in another VM register. But this format enables more complex cases, where userland programs can pass strings of syscalls into the kernel, and let them execute until some exceptional condition occurs. Results would be stored in VM registers (or userland addresses stored in VM registers...). (Log in to post comments)
Quote of the week Posted Jan 17, 2008 19:46 UTC (Thu) by vomlehn (subscriber, #45588) [Link] This is not, on the face of it, necessarily a bad idea. It is, however, a radical change in the user/kernel mode interface. As such, there are reliability, performance, and security implications that would need some careful looking at. It bears some similarities to stored procedure calls in database backends, which might provide one model for how you would do such a thing.
Quote of the week Posted Jan 24, 2008 16:47 UTC (Thu) by forthy (guest, #1525) [Link] This is neither a new idea, nor are the implications unknown. Actually, a sane bytecode interface for sure is stack-, and not register-based. Display Postscript e.g. used such an interface a long time ago (including stored procedures). The implications are that you now can perform tasks with a lot less kernel/userland switching. This helps a lot if the task in question does something quite simple. It also helps that asynchronous IO can be done differently - just asynchronously execute this bytecode instead.
|
|||||||||||||