| ||||||||||||||||||||||
Re: [PATCH 5/6] syslets: add generic syslets infrastructure
So my radical ultra tired rant o the week... Rather than adding sys_indirect and syslets as is, * admit that this is beginning to look like a new ABI. explore the freedoms that that avenue opens... * (even more radical) 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. The 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...). This sort of interface would be * fast * equate to the current syscall regime (easy to get existing APIs going... hopefully equivalent to glibc switching to a strange new SYSENTER variant) * be flexible enough to support a simple implementation today * be flexible enough to enable experiments into syscall parallelism (aka VM instruction parallelism <grin>) * be flexible enough to enable experiments into syscall batching One would probably want to add some simple logic opcodes in addition to opcodes for syscalls and such -- but this should not turn into Forth or Parrot or Java :) Thus, this new ABI can easily and immediately support all existing syscalls, while enabling Now to come up with a good programming API and model(s) to match this parallel, batched kernel<->userland interface... Jeff, very tired and delirious, so feel free to laugh at this, but I've been pondering this for a while -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ (Log in to post comments)
Re: [PATCH 5/6] syslets: add generic syslets infrastructure Posted Jan 17, 2008 6:52 UTC (Thu) by guinan (subscriber, #4644) [Link] I don't see any replies to that post on the gmane list, or groups.google.com view of the thread. Did the kernel folks not take it seriously? (Did Corbet post it as humor?) I'm sure the syslets/indirect busines works and "I don't have to worry about it because glibc hides all the gory details", and after all, I'm just a 2-bit userspace hacker, but having read the sys_indirect() article in November, and agreeing with Anvin's and Miller's sentiments, just *knowing* what's behind the curtains with sys_indirect makes me uneasy, and even a little embarassed to promote Linux, when one of the things users used to be able to be proud of was how nice and elegant it was compared to ugly interfaces in other operating systems (ok, Windows). I actually *really like* Garzik's proposal, at least as far as I understand it. Maybe that's why I'm not a kernel hacker...
I actually *LOVE* it... Posted Jan 17, 2008 10:31 UTC (Thu) by hummassa (subscriber, #307) [Link] modulo the Forth reference... if he was serious about the "define some new opcodes easy", a Forth-like or register-based-Forth-like way would be small and fast :-)
This road seems familiar... Posted Jan 17, 2008 11:38 UTC (Thu) by dw (subscriber, #12017) [Link] I think it would be illuminating to google for terms like "acpi interpreter kernel"; there was kurfuffelry* a few years back about the idea of the kernel containing any kind of bytecode interpreter (a very vague and seemingly mistargeted policy, but hey, I'm no kernel developer :) Sorry for the vagueness, but I can barely just about remember it was related to ACPI. * Furore? Drama? Something like that.
This road seems familiar... Posted Jan 17, 2008 15:40 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] As I recall, the complaint about ACPI was that it's huge, horridly complex and hard to get right. As I recall, it wasn't a complaint about bytecode interpretation per set, but rather bytecode interpretation of such magnitude and complexity. This simplified bytecode sounds like it's little more than a switch-case wrapped in a while loop run from its own kernel thread.
This road seems familiar... Posted Jan 17, 2008 15:50 UTC (Thu) by nix (subscriber, #2304) [Link] Bytecoded Forth interpreters can be made very small and very easy to understand. (This would be even simpler, because the parser would be in userspace and all you'd have in the kernel is the interpreter for the bytecode part.)
This road seems familiar... Posted Jan 17, 2008 16:28 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] Isn't the only real difference, once you've constrained the execution to a sandbox with limited safe operations, that one's data references are register based and the other are stack based? Stack based bytecode would give you a more compact representation, but I'm not sure it matters in this scenario. In terms of programming ease, I've found writing assembly programs for register machines to be much easier than for stack machines. Stack programs require a bit of cleverness to avoid unnecessary explicit stack manipulation. This would also obviate the need for a userspace compiler. If the bytecode programs are simple enough to write, then the "assembly" code for them probably ends up looking something like a bunch of #defines in some C code initializing some const arrays. Now you'll probably tell me the same could be done with FORTH, but I'm not sure you get all the FORTH semantics when you do that. You just end up writing RPN assembly language. When I get a hankerin' to do that, I'll just bust out my HP-48. :-)
This road seems familiar... Posted Jan 18, 2008 21:49 UTC (Fri) by nix (subscriber, #2304) [Link] Yeah, it's just that lots of people can already write forth code. :) (well, comparatively lots, and for the sort of trivial stuff you'd probably be doing in this one page, advanced tricks are probably not needed.)
Re: [PATCH 5/6] syslets: add generic syslets infrastructure Posted Jan 17, 2008 17:27 UTC (Thu) by eSk (subscriber, #45221) [Link] One could also "map" some of these virtual registers into physical machine registers to avoid storing syscall parameters in memory altogether. We did similar things with our L4 kernel API years back and it worked out rather well (for a wide range of different processor architectures). We did not take the full step of batching multiple syscalls, although we did circulate ideas about doing so. But then again, our kernel API has always been a lot less complex than the much richer Linux API. Trying the same thing with Linux could prove a quite daunting task.
|
||||||||||||||||||||||