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. kre
