Forgot your password?
typodupeerror
Open Source BSD

NetBSD To Support Kernel Development In Lua Scripting 311

Posted by timothy
from the point-of-entry dept.
An anonymous reader writes "NetBSD 7.0 will support the Lua scripting language within its kernel for developing drivers and new sub-systems. A Lua scripting interpreter is being added to the NetBSD kernel along with a kernel API so developers can use this scripting language rather than C for developing new BSD kernel components. Expressed reasons for supporting a scripting language in a kernel were rapid application development, better configuration, and "modifying software written in C is hard for users." In a presentation it was said that Lua in the kernel will let users explore their system in an easy way."
This discussion has been archived. No new comments can be posted.

NetBSD To Support Kernel Development In Lua Scripting

Comments Filter:
  • long overdue (Score:5, Interesting)

    by stenvar (2789879) on Saturday February 16, 2013 @07:54PM (#42924645)

    This is a good thing, and it's long overdue. Linux should do the same.

    It's actually pretty easy to get Lua running in the kernel and call kernel APIs; but to make it really useful, it needs additional kernel hooks and callbacks, and that requires cooperation from the core kernel developers.

  • Great idea. (Score:5, Interesting)

    by Meshugga (581651) on Saturday February 16, 2013 @08:02PM (#42924699)

    I honestly think that this is a great idea. It's a novel approach to extending a kernel, especially considering NetBSD doesn't have that big of a market share and expressly focusses on supporting as many platforms as possible. Prototyping new features or certain drivers in a portable scripting language may give them a leg up in the functionality aspect of the race.

    Also, LUA is super fast, small, easy to learn, concise and the C API/embedding it is straight forward.

    You may knock it all you want, "because kernel land is C land", but after all bias being said and flamed, this may turn out to be a really fun, interesting and possibly very useful idea.

  • Re:users? (Score:5, Interesting)

    by TheRealMindChild (743925) on Saturday February 16, 2013 @08:02PM (#42924701) Homepage Journal
    It seems crazy, but this may not be as braindead as it seems. For instance, a keyboard driver. You just need a read key state->have a look up table to the keycodes function, then pass it on. This is redundant, few lines of code with very little difference between most other drivers. You may not want to write your graphic drivers in it, but not every driver needs bare metal functionality
  • Re:long overdue (Score:3, Interesting)

    by Anonymous Coward on Saturday February 16, 2013 @08:03PM (#42924709)

    Exactly.

    With certain algorithms I have LuaJIT code that runs faster than the best C code I can create (I'm speaking with 25+ years of C experience here).

  • Re: Performance (Score:0, Interesting)

    by Anonymous Coward on Saturday February 16, 2013 @08:08PM (#42924733)

    Because it is a powerful and realtively easy to read and write language. Plus, it has a good compiler with a lot of optimization routines to squeeze performance out. In more modern times, it also has a fair bit of momentum as that is what they were written in in the past.

  • Re:long overdue (Score:3, Interesting)

    by Anonymous Coward on Saturday February 16, 2013 @08:25PM (#42924851)

    LuaJIT can be seriously fast. But usually when C is slow, it's some compiler flag, or perhaps a bunch of unpredictable branches or random access pattern in the inner loop.

    Pretty often the LuaJIT trace machine code generated is similar to what you'd get from gcc. That's how good it is.

  • Re:users? (Score:4, Interesting)

    by Jane Q. Public (1010737) on Saturday February 16, 2013 @08:26PM (#42924861)

    "It seems crazy, but this may not be as braindead as it seems."

    I think that is very much a matter of opinion. And my opinion is: it *IS* just exactly as braindead as it seems.

    Just what we need: "modern" software bloat in the kernel. [sarcasm] Thanks, but no thanks.

    I have right here a program that is more than 45 times the size of the entire hard drive from one of our office computers back in 1994... and that hard drive had a full install of that year's Microsoft Office, plus WordPerfect and Lotus 1-2-3, with lots of room to spare for files.

    Sure... that was '94. But is there REALLY call for programs that large, and by the way slow? And that is by no means the largest application I have on my machine right now. It's on the larger side but I have some many times as big.

  • Re:users? (Score:5, Interesting)

    by Lodragandraoidh (639696) on Saturday February 16, 2013 @08:33PM (#42924905) Journal

    Interesting - failure of user space in this way is exactly why we have zero-days.

    I would like to see this happen - but several things make it improbable:

    1. Von Neuman architecture. As long as data and instructions exist in the same space - poorly written apps will allow abuse of it.

    2. Complexity of current software. The more complex the software, the more likely a bug will exist in it that allows #1. Given how programmers stitch together preexisting modules without understanding what is being done on the underlying system - I only expect that to continue expanding.

    It should be instructive that Java was supposed to be that sandboxed layer...and it has so many zero-days it looks like swiss cheese.

    Now - how would we avoid that and make an unhackable userspace?

  • Re:My P4 (Score:4, Interesting)

    by MacTO (1161105) on Saturday February 16, 2013 @08:37PM (#42924929)

    It depends upon what he needs the computer for. If it is a server, then there is no need for a GUI. Even with respect to application software, there are a multitude of options out there. Writing can be done in text editors, then processed with TeX or troff (for formatted output to a printer, when necessary). There are a multitude of email clients and several web browsers. I've never really tried it, but you can even do graphical design with languages like PostScript and POV. Media? Again, you have access to many audio players. It's much more gimmicky in nature, but you can even play videos on text consoles.

  • Re: Performance (Score:3, Interesting)

    by Anonymous Coward on Saturday February 16, 2013 @08:54PM (#42925051)

    True. Assembly can be faster than C. In the same way it can be more powerful than C.

    Bottom line is C provides a solution for the complexity of large scale development, without sacrificing the performance, while at the same times still let's the developer be in complete control of his code and data structures.

  • Re: Performance (Score:2, Interesting)

    by Anonymous Coward on Saturday February 16, 2013 @08:54PM (#42925053)

    Not really. It's more subtle than that. Straightforward machine code and more explicit code can help performance, or it can hurt. For example, function pointers are slower than inlinable c++ templates or a JIT that can inline across library boundaries or based on observed call frequencies at runtime (all of these at the cost of memory usage). It's not nearly as simple or binary as you're suggesting.

  • Re:users? (Score:5, Interesting)

    by jbolden (176878) on Saturday February 16, 2013 @09:40PM (#42925257) Homepage

    i thought *users* had no business writing device drivers?

    My non programmer wife wrote a custom device driver in AppleScript, not even knowing what a device driver is. Those sorts of languages can be amazing empowering to end users, and yes there are reasons that end users might want a custom device driver if it is easy enough to accomplish. Though this makes more sense for OSX than NetBSD, I doubt there are many if any non programmers who use NetBSD.

    I had to write a custom device driver for Windows once to get something more like a Unix ethernet driver i.e. bypass some normally quite excellent parts of the Windows networking stack. I was doing software not hardware so I guess I'd consider myself an end user. And that was a pain in the ass.

  • Re:Stupid NOT (Score:5, Interesting)

    by Anonymous Coward on Saturday February 16, 2013 @10:18PM (#42925399)

    I don't know how much Unix/BSD/Linus code you have read or written, but I have been developing core code, Scheduler, MM and Drivers since 1980 and this is a great idea, long overdue.

    The Abstractions are now well understood and most code dos't need to be quick, but safe, putting PRE in kernels will clean up acres of cockamamie code now written in C, most of which just runs at boot time and is then freed. ... there are exceptions, you cant't have the garbage collector running whenever it likes, eg in the middle of an interrupt routine, but managed memory, not C, C++ scoping is the way to stop slow memory leaks.

    Put simply you are an idiot and dont know what you are talking about.

    MFG, omb

  • Re:users? (Score:4, Interesting)

    by WindBourne (631190) on Saturday February 16, 2013 @11:10PM (#42925583) Journal
    Exactly. Think about all of the devices out there that are simple ones. I know that my in-laws have BP cuff with USB. I have thought about writting a driver for it, but it just seems like a lot of work for a minimal amount of info. Now, if there is something simple, then this could be useful. In addition, I have been thinking that batteries interface should be standardized. It does not matter wether it is a laptop battery, or a UPS. They accomplish the same thing and the same programs should control them. Simple as that.
  • Re:Stupid (Score:5, Interesting)

    by dalias (1978986) on Sunday February 17, 2013 @12:13AM (#42925787)
    It is potentially stupid, but the reason is much more subtle than most people realize. For all its limitations and headache, C does have one key feature that makes it suitable for kernel programming where most other languages are not: the concept of well-defined storage durations and reserving storage for an object. I really question whether Lua code running as part of the kernel can be made robust under out-of-memory conditions which a kernel must be able to survive.

The unfacts, did we have them, are too imprecisely few to warrant our certitude.

Working...