Slashdot Mirror
NetBSD To Support Kernel Development In Lua Scripting
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 is, quite possibly, the stupidest kernel feature that has ever been unleashed upon this poor planet.
"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.
Looking for people to chat about multicopters, coding, music. skype: gtsiros
Won't that kill performance?
I mean that's the reason we still write kernels in C. Every cycle counts..
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.
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"?
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.
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.
...there will finally be something Perl CAN'T do?
Okay, sure. But...why Lua? :/
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.
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.
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?!
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
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
Because Lua suffers from none of those shortcomings.
Surely this article deserves the whatcouldpossiblygowrong tag more than any other this year. And possibly last year too...
MediaWiki developers are almost ready for Lua scripting to be enabled for all Wikipedia and related sites, and It has already been deployed to http://mediawiki.org./ Lua was chosen mostly because of how easy it is to sandbox and limit memory consumption.
http://www.mediawiki.org/wiki/Lua_scripting/Tutorial -- Introduction
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.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
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
you are pretty ignorant if you think COBOL or LISP compiled to assembly is slower than C code
With the BSD's, there no such thing as a tainted kernel. But with Linux, non-GPL drivers are actively discouraged. If they were to add scripting to the Linux kernel, it would actually make it easier to write proprietary drivers, so they'd never go for that. Forget the fact that it would make it a hell of a lot easier to sandbox drivers so they don't clobber other kernel memory. Forget the fact that code in a higher-level language is smaller; countless drivers would suffer no appreciable performance hit by being written in an interpreted language (especially Lua), so you'd have one small interpreter and many shrunken drivers, which would make the kernel memory footprint smaller. Forget the fact that mutually exclusive access to shared variables could be made implicit in a majority of cases, eliminating a whole class of bugs in one shot. No. We've got our precious GPL to protect. (Oh, and forget the fact that nVidia basically gets a free pass on this.)
There are multiple non-"C" DSL languages and virtual machines in the BSD kernels already and they have been there for over 20 years.
Here is a prime example http://en.wikipedia.org/wiki/Berkeley_Packet_Filter
Lua is a very clean, small, and relatively fast object oriented language. It is probably the best possible choice for a general purpose dynamic language to embed in a kernel.
I have one question. If the Japanese Ministry of Agriculture is not in charge of Gundam, then who is?
How about
peek(xx)
poke(xx)
The best aprt of Commodore BASIC
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
I'm in no way a kernel expert, I done some C and C++ programming.
But if you want to expose kernel API to scripting language, why you don't just expose those kernel API to userspace?
Anything performance or memory critical should be still written in C, so just expose those API to user space and not only get the benefit that you can now use not only LUA but any other language, you get the benefits of separation between kernel and user space: security.
Just expose those API to userspace and offer a libnetbsd.so so that for example, LUA, Python, Ruby, etc. can use the kernel API. Why would the Netbsd developers limit it to just LUA? Or are they planning to add more script engines in the kernel?
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
No.
But if it doesn't need to be quick, why is it in the kernel in the first place? I would have thought that if you are tempted to put a scripting language in the kernel, it's a pretty good indication that the division between kernel and non kernel is somehow wrong.
There was very advanced and expensive Lisp OS once http://en.wikipedia.org/wiki/Genera_(operating_system)
That line of reasoning sounds like "All applications will be written in Python, therefor all applications will be written in Python. And since Python is not native code, it's a waste of CPU cycles. Therefor Python is a bad idea".
"possibility exists" != "everyone will do it all the time".
The lua features are for prototyping, playing around and just testing crazy ideas. Don't expect NetBSD to ship with any production drivers written in lua.
I use Python to prototype, but I always release applications and libraries written in plain C. I don't see why the existence of a feature must imply that it's used everywhere?
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=perl&lang2=lua
In some tests, one is faster than the other, but by no more than 4x to 1/9th each way.
At least they didnt choose ruby.
Liberty freedom are no1, not dicks in suits.
their Lego port.
none
Won't somebody think of the precious CPU cycles!
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
512MB is a massive amout of memory. I have personally run GUIs on 4MB. I ran an excellent HPUX/PA RISC workstation with just 128MB RAM. It had a very functional GUI (based on X11 and Motif) and it was indestructible without water.
There was a time national police mainframes ran on 512 KILObytes. Boy, you are sitting in front of a supercomputer !
I mean it very serious when I say that these days we are pissing away memory for essentially no tangible benefit.
the entire point of the free software movement and the PC movement is that users should be able to do whatever the hell they want with their machine. they bought it.
Process A calls kernel. That's okay, kernel-userspace transitions can be reasonably fast. Function called is actually implemented in userspace process B. Whoa, context switch. You can easily have a 100x slowdown in your kernelspace interpreter and still come out ahead compared to incurring that context switch. This all assuming that the driver will not do a lot of complicated processing. Rather, it will probably just need to check some basic data structures to identify whether the operation is currently allowed and maintain some shared state between processes. (Not) surprisingly enough, that's all there is to many drivers. I would even think that some file systems currently implemented in FUSE would be faster using a reasonably well-behaving "safe" kernel language.
You don't need Java or C# (and all their inefficiencies such as the GC and "allocate everything on heap")
I'm not sure that's entirely true. Primitive types in Java and value types (including structs) in C# are by-value. I may be showing my inexperience here, but why would you want to allocate a value type on the heap? And does it even matter, given that value types are passed on the stack anyway?
I had a sig once. It was lost in the great storm of '09.
There is no widely used, memory safe implementation of C or C++. Even if there were, building a memory safe language on top of C and C++ is itself shoddy decision making because those languages are completely unsuitable to the task.
The C program only launches quickly because all of its shared libraries are kept in memory by the kernel. If you loaded it from scratch, it would likely take much longer. C++ is even worse because its libraries are huge and bloated. Lua, in contrast, has a tiny memory footprint and tiny dependencies. By your own measure of "crappiness", it beats Java, C, and C++ hands down.
Lua interpreter instances are small. In a kernel environment, you'd like run lots of tiny Lua interpreters, one for every "task" you want to perform. You can impose limits on memory and CPU usage on each instance. Under an out-of-memory condition, you can also ask each of them to reclaim a maximum amount of memory, via a hook and via the GC interface. And if that fails, you can start killing them off one by one in order of least importance, just like you might with other processes or functions. The fact that Lua has better defined semantics and interfaces for resource management than a chunk of C code means that it's actually easier to deal with out of memory conditions with Lua interpreters than for general C code.
Regardless of how much this would simplify kernel hacking, it means that a lot of controversial or legally restricted code can be added to the kernel with just some tiny text files being passed around. Users could likely add exFAT support, cryptography, DVD decryption, etc. with nothing more than a command like "cat exfat-support > /proc/lua".
And this would also be available at boot time, making it much easier to work around all the weird problems that keep Linux systems from starting; instead of ever increasingly complex configuration files, blacklists, and C-based workarounds, most of those boot problems could be handled by loading a little bit of Lua code at boot time.
If they have a JIT compiler for it, then it actually won't hurt too much, except at the initial use of a feature. Unless they have the incredible stability of Windows 9x... This shouldn't be a problem.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).