[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Potential Improvements on Lua Support?
I like this idea a lot more than the inetd/rc.d idea. I am not sure that
"Improvements on Lua Support" is a good title, unless you're actually planning
on working on the kernel Lua implementation, and it doesn't sound like that.
I'd suggest something more like "Using Lua scripts to improve kernel heuristics"
or something like that. That is, if that is what you are really proposing,
using your machine learning knowledge in areas where it might benefit the kernel.
I cannot help with Lua, I know it exists, but that's the extent of my knowledge
on that front. I know something about filesystems, but not the details of our
current implementation. I would however like to see this idea applied to CPU
scheduelling, particularly when there are different classes of CPUs available
(ie: they're not all identical to each other - while any can do any work, they
don't all do it equally well). I think we're currently lacking in that area.
For filesystems, my gut feeling is that a better task to take on might be
working out which cached data ought be ejected, and which retained, rather
than (or perhaps just before) working on prefetching algorithms (particularly
as "drives" get much faster, and delays to fetch blocks are reducing considerably).
So, I'm prepared to help with this, with two caveats. First, you need to also
find someone knowledgable (enough) with the kernel Lua implementation and use
to assist with that (and Lua scripting) who is willing, and available, to assist
with this. Some occasional filesystem/uvm and schedueller assistance might be
useful as well. And second, you need to receive e-mail somewhere other than at
gmail - gmail refuses mail from me (mail I normally send, rather than mail this
way, from a NetBSD host, which is not at all convenient to send), and even forwarding
mail from me to them from some other mailbox is likely to fail. I have zero interest
in bowing to gmail's stupid requirements to avoid that problem, so if I am to assist
you need to be able to receive mail somewhere else. Probably at UT I'd guess.
Main Index |
Thread Index |