×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

NetBSD To Support Kernel Development In Lua Scripting

timothy posted about a year ago | from the point-of-entry dept.

Open Source 311

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

311 comments

Stupid (1, Insightful)

Anonymous Coward | about a year ago | (#42924613)

This is, quite possibly, the stupidest kernel feature that has ever been unleashed upon this poor planet.

Re:Stupid (0)

Anonymous Coward | about a year ago | (#42924627)

I agree that's special ed level of stupid.

The Truth About Adobe and The US (-1)

Anonymous Coward | about a year ago | (#42924685)

Adobe had a lot more to do with the human rights abuses of the last decade than most people realize.

Adobe clearly has a secret deal with Youtube-- all videos highlighting the abuses it committed while in the US are taken down without explanation.

Billions of dollars in funding have been funneled away in the US's so-called "dark-budget," a slush fund for what is typically regarded as a cover for top-secret human medical testing programs.

Is this really the world we want our children to grow up in?

On more than one occasion, the US government has forbidden travelers from the US from flying to the United Arab Emirates, without ever giving a cause.

Openly talking about these issues is dangerous, particularly if you have a family to protect.

If you don't act on this, who will? And who will suffer while you remain indecisive?

Re:The Truth About Adobe and The US (0)

Anonymous Coward | about a year ago | (#42924723)

Adobe had a lot more to do with the human rights abuses of the last decade than most people realize

I agree, celebrities are dressing like tramps these days for the paparazzi sites.

Re:Stupid (0)

Anonymous Coward | about a year ago | (#42924695)

Why?

Re:Stupid (0)

Anonymous Coward | about a year ago | (#42924801)

Because Lua can run in userspace just fine.

April? (0)

Anonymous Coward | about a year ago | (#42924623)

Surely they are joking, right?

users? (5, Insightful)

gTsiros (205624) | about a year ago | (#42924631)

"modifying software written in C is hard for users."

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

of course if they had said "modifying software written in C is hard for programmers." it would gather a fierce shitstorm.

Re:users? (4, Interesting)

TheRealMindChild (743925) | about a year ago | (#42924701)

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:users? (4, Funny)

KiloByte (825081) | about a year ago | (#42924811)

So let's invent a sandboxed layer that can interface with the kernel, but can't do damage to it? Also, make the API stable, unlike innards of the kernel. Let's call this novel idea "userspace" or such.

Re:users? (4, Interesting)

Lodragandraoidh (639696) | about a year ago | (#42924905)

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:users? (2)

Natales (182136) | about a year ago | (#42925331)

One possible answer to your point is to use Parallax OS [returninfinity.com] or a similar concept. I find very appealing the self-contained nature of FCAPS to an individual core.

Interestingly, they leverage Bare Metal OS [returninfinity.com] and the coding is done mostly in Assembly (although C is possible). I think the fattening of all kernels is making these kind of projects look more interesting.

Re:users? (4, Insightful)

Mindcontrolled (1388007) | about a year ago | (#42924823)

The moment you even expect that users should, could, would or even remotely in their most maddened fever dreams WOULD WANT to modify the kernel, you lost it.

Re:users? (3, Interesting)

Jane Q. Public (1010737) | about a year ago | (#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? (1)

Anonymous Coward | about a year ago | (#42924919)

Lua is 12k lines of C code, comments included. Once compiled it weights like 200KB.

Re:users? (5, Funny)

Anonymous Coward | about a year ago | (#42925069)

I only have 640 KB you insensitive clod!

Re:users? (1)

Anonymous Coward | about a year ago | (#42925297)

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.

Sounds like a few tens of lines of C code. But no, let's bring in a whole new language interpreter AND write a few lines of code in the other language.

Scripting languages are fantastic for some things. Kernel or driver development is not one of them. Low level things need to be as efficient as possible - even the keyboard driver. Imagine you're playing a FPS using the keyboard and suddenly the game freezes for an instant for garbage collection when you press a key. ;-)

arrogant [expletive deleted] (-1)

Anonymous Coward | about a year ago | (#42924847)

It is that kind of arrogant self-annointing deprecation of the PURCHASERS of the product by the SELLERS of the product which is at the center of my refusal to "upgrade" anything I own personally.
It is also why I refuse to answer phone calls or emails from a wide variety of companies who attempt to use government regulations to force "upgrades" to technologies which this kind of arrogant [expletive deleted] have demonstrated a keen interest in establishing as a new form of wizardry and witchcraft which the commoners must never be allowed to see behind the curtains used to hide the deliberate ignorance and incompetence of the creators from public inspection.

Re:users? (5, Insightful)

MacTO (1161105) | about a year ago | (#42924881)

Keep in mind that NetBSD users are quite different from Windows/Macintosh/Linux users (at least on average).

"Hard" may also be a reference to the implementation, rather than the language. Interpreted languages tend to bypass the compile and link part of the development process. This means that interpreted languages are easier to develop with and compiled languages are hard to develop with (at least in some respects). I'd also comment on the arcane nature of C, but I haven't used lua so I don't know if it is any better.

Re:users? (1)

jbolden (176878) | about a year ago | (#42925281)

Lua is specifically designed to be an easy embeddedable scripting language when one needs a light scripting language but not a full featured programming language. Luas are way way easier.

Re:users? (0)

Anonymous Coward | about a year ago | (#42924927)

So, they chose Lua to make it easier for users? Because apparenly more people know Lua than C?

I don't think I've actually ever seen anything written in Lua.

Re:users? (0)

Anonymous Coward | about a year ago | (#42925013)

What, you haven't played a video game in the past 15 years?

Re:users? (4, Interesting)

jbolden (176878) | about a year ago | (#42925257)

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.

Performance (5, Informative)

Anonymous Coward | about a year ago | (#42924633)

Won't that kill performance?

I mean that's the reason we still write kernels in C. Every cycle counts..

Re:Performance (0)

Marxdot (2699183) | about a year ago | (#42924653)

That's not the reason we write kernels in C.

Re: Performance (0)

Anonymous Coward | about a year ago | (#42924689)

Enlighten me. What's the reason?

Re: Performance (0, Interesting)

Anonymous Coward | about a year ago | (#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: Performance (5, Funny)

Anonymous Coward | about a year ago | (#42924747)

So we use it for performance. Ok I get it now.

Re: Performance (1)

Anonymous Coward | about a year ago | (#42924961)

Powerful is not the same as fast.

C can mingle with memory in ways that other higher-level languages can't.

It's also ubiquitous; almost every device that exists supports some version of C.

It's also fast, but it's not the main reason (assembly is faster).

Re: Performance (3, Interesting)

Anonymous Coward | about a year ago | (#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 (3, Insightful)

Anonymous Coward | about a year ago | (#42925303)

Multiple execution units, long pipelines and modern caching makes it hard for assembly to be faster than C. The human brain can not visualize the pipeline like a compiler can.

Re: Performance (0)

Anonymous Coward | about a year ago | (#42925083)

By the way "powerful" is not unambiguous characterisation. C++ is powerful. Assembly is powerful. Perl is as well. So is LUA.

Re: Performance (1)

Anonymous Coward | about a year ago | (#42924839)

In my opinion one of the best reasons is it produces good, straightforward machine code. Other languages make it too easy to write allocation-heavy code, or large code size. These things are bad for a kernel.

Re: Performance (3, Insightful)

larry bagina (561269) | about a year ago | (#42924939)

I believe the word you're looking for is "performance".

Re: Performance (2, Interesting)

Anonymous Coward | about a year ago | (#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: Performance (0)

Anonymous Coward | about a year ago | (#42925129)

You are right in the essence of your reply.

But comparing function pointers to inlinable templates is unfair. If anything you should compare them to virtual functions.

Re:Performance (0)

Anonymous Coward | about a year ago | (#42924697)

Then I await a kernel written in javascript!

Re:Performance (1)

Anonymous Coward | about a year ago | (#42924983)

Does this count?
http://linux.slashdot.org/story/11/10/08/1340253/linux-in-javascript-with-persistent-storage

My P4 (1)

Anonymous Coward | about a year ago | (#42924715)

I have an old P4 with 512MB and FreeBSD with no desktop: I do everything from a terminal - old school. It runs wonderfully.

I would really hate to install a package that uses this Lua to extend the kernal (and god knows what security issues that will bring up!) and have that system slow down to the point where I can't use it.

See folks, I keep my hardware until the wheels fall of and then some. There's very little of MY old hardware polluting third world countries and I'm cheap - this buying the latest and greatest thing is just a waste of money.

If *BSD turns into something that I can't use on old hardware anymore, I'll be really sad.

Re:My P4 (2)

jones_supa (887896) | about a year ago | (#42924865)

That sounds quite cool, but how can you cope with only the terminal?

Re:My P4 (3, Interesting)

MacTO (1161105) | about a year ago | (#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:My P4 (1)

Osgeld (1900440) | about a year ago | (#42925091)

oh no not a P4, that thing is like stone age!

seriously though I often use lua on a 90Mhz pentium1 8 meg laptop for various test's where I may need to log data once an hour for 3 months and I dont want to waste a real computer

its faster than qbasic, its hardly noticeable against a poorly written compiled program, its not even terrible to a decently written compiled program. lua is a pretty darn fast interpreted language, and since its all bound to C on the backend anyway its easy to rapid develop with lua and strip it away later

Re:My P4 (0)

Anonymous Coward | about a year ago | (#42925153)

Lua is small and efficient and worked well in commercial video games way back even before your P4 existed.

Lua's code base is tiny (less than 20k lines) and thus is easily audit-able for bugs and security issues. And Lua scripts cannot access anything that the C host program does not give them explicit access to. Due to sheer lines of code and complexity, chances are any security issues will be in the kernel itself, not Lua.

Memory exploits (used as common attack vectors) are often caused by programmers making mistakes. Using Lua may reduce those mistakes since any sensible scripting binding should insulate scripters from dealing directly with pointers.

Re:Performance (2)

Anonymous Coward | about a year ago | (#42924841)

Lua is the fastest available scripting language for the task that NetBSD needs it for. It compiles to a byte code, is designed for efficiency and most importantly has excellent hooks for C integration. I have to commend the NetBSD team for their decision - hopefully it will be very successful and lead to a similar implementation in Linux.

Re:Performance (1)

Anonymous Coward | about a year ago | (#42924973)

Perl compiles to byte code and has hooks for C integration. It's probably not as fast, but more than ten people actually know how to use Perl. :)

Re:Performance (0)

Anonymous Coward | about a year ago | (#42925207)

Perl isn't even remotely close to as fast or as efficient as Lua and Perl implementations are far, far more complex. Perl is deprecated, deal with it.

Re:Performance (1)

aliquis (678370) | about a year ago | (#42925367)

Lua is also used by World of Warcraft, "which got more users than Linux" ;), JK :)

Anyway, point being I think more than 10 people know how to use it :)

Re:Performance (3, Informative)

Anonymous Coward | about a year ago | (#42924911)

Lua is designed to be a embedded companion language to C. You still use C where it makes sense (i.e. pointer manipulation/performance). You use Lua for expressing higher level logic more easily. Lua is very fast. Writing the same higher level logic in raw C might not be any faster because you have to build up all the infrastructure that Lua has already provided and optimized like associative arrays.

Re:Performance (4, Informative)

stenvar (2789879) | about a year ago | (#42925029)

Kernel code is like lots of other code: a lot of it is executed rarely and not performance critical. There's setup code, occasional permissions checking, etc.

In addition, this is not to replace plain C modules (although it may be useful for prototyping), it's for complex and dynamic configurability.

Right now, there are two ways of handling that. One is to invent complex configuration files and data structures, sometimes even little interpreters. The kernel is full of those. They are error prone, complicated, and require a lot of effort to maintain. The other is to put complex decision making into user-space, but that involves context switches and other overhead. It also means lots of special-purpose and redundant code, and lots of documentation and complexity. The kernel uses both of those strategies extensively, one reason why it's so big.

Putting Lua+LuaJIT in the kernel is likely faster than either of those approaches, while at the same time also being easier to maintain and document.

Re:Performance (1)

synthespian (563437) | about a year ago | (#42925063)

I'm not sure, but there might be non-C system code in OS X (Objective-C) and Windows (C++, C#). In FreeBSD, there's Forth in the bootloader (does that count?).

I think you meant: Linux developers only use C for system programming.

long overdue (4, Interesting)

stenvar (2789879) | about a year ago | (#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.

Re:long overdue (3, Interesting)

Anonymous Coward | about a year ago | (#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:long overdue (0, Troll)

Anonymous Coward | about a year ago | (#42924737)

Sounds like you fail at programming in general, including algorithm selection, if what you say is true.

Re:long overdue (1)

Anonymous Coward | about a year ago | (#42924829)

Sounds like you fail at understanding the tradeoffs between being locked into static code determined at compile time for vs. code that can be dynamically optimized at runtime based on things like available hardware and current invariants.

Re:long overdue (3, Interesting)

Anonymous Coward | about a year ago | (#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:long overdue (1)

tibit (1762298) | about a year ago | (#42924945)

Especially that the trace is equivalent to gcc profile-guided optimizations. It can rock your world.

Re:long overdue (0)

synthespian (563437) | about a year ago | (#42925033)

Sounds like you are unaware of the algorithm benchmarks regarding Lua's register-based JIT.

Sounds like you are unaware that heavy-players in the video game industry *all* mix & match Lua and C++ for their engines.

Wow! You must know something we don't! Why don't you get a job in a big software house in the games industry and tell them how *wrong* they all are?

Re:long overdue (0)

tibit (1762298) | about a year ago | (#42924935)

Lua by itself is pretty abysmal, performance wise and IMHO, but LuaJIT is perhaps the best thing since sliced bread. I've been playing with the recent 2.0 release on ARM, and it looks like I may quite comfortably write a big chunk of an industrial process controller in Lua. Now that's something. No more messing with IEC PLC programming languages that are still stuck in the 80s.

Re:long overdue (2)

stenvar (2789879) | about a year ago | (#42924963)

I don't know what you mean by "pretty abysmal, performance wise". Lua is one of the fastest scripting languages around, even without LuaJIT.

Re:long overdue (0)

Anonymous Coward | about a year ago | (#42925247)

Care to provide some examples?

Re:long overdue (0)

Anonymous Coward | about a year ago | (#42924827)

Yes, if i had a choice between JS and Lua to script Lua would win in this case. Lua is lightweight and extensible enough to get the job done.

Class in lua:
Account = class(function(acc,balance)
acc.balance = balance
end)

Class in js:
function MyClass(){
}
MyClass.prototype.aFunction(){
}

That's not to say one is better than the other however the lua example is way more "C" wrapper friendly. Of course using all sorts of JS libraries you get tons of help with things like that. I would prefer CoffeeScript kernel support than plain JS if it had to run in JS. I could easily see on NetBSD something like node.js server-side code written with this new Lua support- I'm interested at looking at some benchmarks now.

Re:long overdue (1)

Anonymous Coward | about a year ago | (#42924991)

Linux should do the same.

There is a similar project for Linux. See ljsyscall [github.com].

Re:long overdue (2)

sourcerror (1718066) | about a year ago | (#42925007)

I would be happier if the major window managers supported Lua. I'm not sure I would want to mess with device drivers.

Re:long overdue (3, Insightful)

stenvar (2789879) | about a year ago | (#42925059)

It's not mainly for messing with device drivers (although it may be useful for that too).

It's mainly useful for all the stuff that people right now create /proc devices, ioctls, and user-level kernel-related daemons for. Those mechanisms are both slow and complicated. With Lua in the kernel, a lot of that stuff can be handled much more easily, without the overhead of context switches and with much less code.

It probably won't replace all the bloated configuration stuff that already exists, but at least when writing new device drivers and new functionality, developers could save a lot of time and effort.

April First came early this year.... (0)

Anonymous Coward | about a year ago | (#42924647)

Apparently the groundhog is really off his game :D

Wow, I bet the performance will be fabulous (0)

Anonymous Coward | about a year ago | (#42924661)

And it gives me great confidence to install kernel components from developers who aren't able to master C.

What, it's april already? (0)

Anonymous Coward | about a year ago | (#42924665)

On the one hand, well, wanting to reach out to "users" is purdy nice and all that, yanno. On the other hand, the consequences of running lua with kernel privileges, written by people not good enough to grok C pointers? I think they've gone off their rocker.

Then again, weird stuff's been done before in this realm. I recall something about SCSI drivers written in perl, until they got around to redo it in C. So hey, innovation and all that, let's give them a chance. We'll see if this stands. Though I do suspect it'll go down in flames before not all that long.

Re:What, it's april already? (1)

synthespian (563437) | about a year ago | (#42924999)

Apparently, a lot of people in the software business have trouble with pointers. That includes Linux, and its many, many security breaches and flaws in its history. Of course, I'm not calling people stupid. I'm simply stating what is widely known. Safe programming is hard. Pointers are error-prone. People who deny that are either superbly arrogant or ignorant of the many serious events in the software industry. If you can avoid unsafe code by using a safer language, than you ought to. You don't seem to have read this bit: "No access to kernel memory, -functions but through predefined binding."

Your assuming NetBSD developers are morons shows how ignorant you are. Have you ever even looked at *BSD system code?!

Fucking LOL. (1, Funny)

Anonymous Coward | about a year ago | (#42924673)

Why LUA? Why not implement BASIC while you're at it?

This is one of the most retarded ideas I have ever heard. I'm sorry, but kernel level stuff should be kept as close to the machine hardware as possible, and that means using C or assembly. Deal with it. If you can't be bothered to learn C like a real goddam programmer, then you have no fucking business sticking your head in something as complicated as an operating system kernel.

I swear to god, this mentality of "let's appease everyone, including the idiots who aren't smart enough to figure it out as it is right now" needs to stop. If you can't grasp C, then kernels are off limits to you. Either you lack the ambition to learn C, or you're too stupid to comprehend it- in which case you're going to be useless drifting around the kernel source code anyways.

So what the hell is wrong with saying "no, sorry, you're too stupid to understand this"?

Re:Fucking LOL. (3, Funny)

Anonymous Coward | about a year ago | (#42924873)

Linus?

Re:Fucking LOL. (0)

Anonymous Coward | about a year ago | (#42924897)

Your view is completely outdated - we're not coding in the 80's any more. Clearly you have no experience with Lua as a language either... or touched any kernel code for that matter. Perhaps you should educate yourself on the subject you're commenting on instead of making backward statements that do nothing more than expose your inexperience.

Re:Fucking LOL. (0)

Anonymous Coward | about a year ago | (#42924981)

Your medication. Take it now.

Re:Fucking LOL. (0)

Anonymous Coward | about a year ago | (#42925183)

Hey, don't poke fun until you've tried it. After all, I love their LOGO interface for the kernel. I've spent many an hour making that turtle submit to my will.

Re:Fucking LOL. (1)

jbolden (176878) | about a year ago | (#42925301)

Why LUA? Why not implement BASIC while you're at it?

You meant that sarcastically but you do realize in the CP/M and early PC days BASICs were implemented in hardware!

Re:Fucking LOL. (0)

Anonymous Coward | about a year ago | (#42925343)

that's not true. basic being stored in rom != "implemented in hardware".
if it were, then i could say that linux is "implemented in hardware."

Great idea. (5, Interesting)

Meshugga (581651) | about a year ago | (#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.

Does this mean... (1)

Anonymous Coward | about a year ago | (#42924773)

...there will finally be something Perl CAN'T do?

Uhm... (1)

noobermin (1950642) | about a year ago | (#42924859)

Okay, sure. But...why Lua? :/

Re:Uhm... (1)

Fuzzums (250400) | about a year ago | (#42924883)

Indeed. What is wrong with java script?

Re:Uhm... (0)

Anonymous Coward | about a year ago | (#42925075)

Lua was designed to be embedded in C applications. Javascript was not designed to be embedded at all (hence no standardized C-API in Javascript). Lua is among the fastest of scripting languages. Javascript tends to be among the slowest. (And every time they manage to speed up Javascript with JIT, LuaJIT blows it away again.)

Re:Uhm... (0)

Anonymous Coward | about a year ago | (#42925099)

There's nothing wrong with Javascript, there's just that Lua already has this: http://www.luajit.org/ext_ffi.html

Am I blind? (1)

Anonymous Coward | about a year ago | (#42924909)

For I cannot see any actual purpose for doing this. Just because you can run Lua script in the kernel does not mean that you SHOULD. And also, I could really not give a rat's ass that some script kiddie finds kernels too hard to mess with. (Awwww, poor widdle script kiddie...) There's a reason even I don't muck around in the kernel, and I do software dev in C and C++ amongst other compiled and scripted languages...

Please do NOT bring this type of feature into the Linux kernel.

Is there a shark jumping contest going on? (0)

Anonymous Coward | about a year ago | (#42924925)

This looks like a symptom of Zawinkski's Law: http://catb.org/jargon/html/Z/Zawinskis-Law.html

This is cool already, but with RUMP, OMG (2, Insightful)

Anonymous Coward | about a year ago | (#42924947)

This is awesome. What is old is new again. Lisp machines were some of the most beloved equipment for os and ai hackers because of the ability to get to the underbelly easily. This is no different. Making the operating system more approachable makes doing operating systems research easier. This is a great idea.

Besides, it's a natural extension of the RUMP kernel paradigm. If you can run a netbsd kernel, as part of a userspace process on linux, then it only makes sense to be able to talk to these 'kernels' under the hood easily. THIS IS WAY FRIGGING COOL.

Natural Selection 2 (0)

Anonymous Coward | about a year ago | (#42924955)

After playing Natural Selection 2 on the Spark engine, I'm not at all surprised more projects are taking up LUA.

NS2 is 95% LUA and runs incredibly fast for what its doing.

Modifying C? (1)

Osgeld (1900440) | about a year ago | (#42925049)

I dont know what packages are going to be bound with this, but in many cases your right back in C adding bindings for lua. Thats one of the good points about lua, is that it can be tied to anything, but the bare bones basic lua is not too much more complicated than a batch file

Why Lua? (0)

Anonymous Coward | about a year ago | (#42925095)

From TFA:

Rather than Lua, other language possibilities were Python and Java. Python is not difficult to integrate with C but has problems with being a huge library, memory consumption, and difficult object mapping. Java is easy to write but also poses problems with object mapping and memory might be an issue, but it's worked out before for driver development.

A positive development (0)

Anonymous Coward | about a year ago | (#42925261)

This is excellent imho because I will now be able to code NETBSD kernal extensions so I can run a Beowulf cluster of naked and petrified hot grits on my Natalie Portmen! All the while you people are complaining about the inefficiencies of using LUA in a kernal, you are forgetting about the thousands of people who have died from a terrorist attack! GET SOME PRIORITIES!

Sorta interested in this... (1)

seebs (15766) | about a year ago | (#42925285)

I like to think I'm okay at C. I certainly don't generally find it particularly intimidating. I've written kernel code, though not much. I maintain a program that emulates root privileges by intercepting syscalls -- and which works on Linux and OS X. I'm basically clear on how this works.

But when I do iOS/Android stuff, I have a pretty strong preference for Lua, because I don't always want to be thinking about pointers. And yes, LuaJIT is... plenty fast. The mere fact that it's a JIT implementation means that it can beat precompiled code for real use cases, and even when it doesn't, it's not as though it's particularly slow.

Don't assume this is only of interest to people who think C is hard. C's by far the language I'm best in, and I still see plenty of appeal here.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...