Linked by Thom Holwerda on Wed 28th Apr 2010 08:42 UTC, submitted by ZacharyM
NetBSD "Since early 2009 NetBSD and rump has supported execution of stock kernel module binaries in userspace on x86 architectures. Starting in -current as of today, kernel modules will automatically be loaded from the host into the rump kernel. For example, when mounting a file system in a rump kernel, support will be automatically loaded before mounting is attempted."
Order by: Score:
This is real news...
by fithisux on Wed 28th Apr 2010 10:35 UTC
fithisux
Member since:
2006-01-22

I hope someday all the drivers run and driver development is done in user-space (even if its slower).

Reply Score: 4

RE: This is real news...
by ZacharyM on Wed 28th Apr 2010 12:32 UTC in reply to "This is real news..."
ZacharyM Member since:
2007-05-28

I hope someday all the drivers run and driver development is done in user-space (even if its slower).


I agree that this is great news for NetBSD, but I do believe that there are items that should be left in the kernel as well. Now it's time to install the world's most portable operating system on a Sun Netra T1.

Reply Score: 1

RE[2]: This is real news...
by Zbigniew on Wed 28th Apr 2010 21:22 UTC in reply to "RE: This is real news..."
Zbigniew Member since:
2008-08-28

I heard, that on the hardware using SPARC processors OpenBSD is doing much better, than NetBSD. But don't ask me for details; didn't dig into this deep enough.

One of the reasons AFAIR was that Theo de Raadt is fond of SPARC.

Reply Score: 1

RE[3]: This is real news...
by cb88 on Thu 29th Apr 2010 15:04 UTC in reply to "RE[2]: This is real news..."
cb88 Member since:
2009-04-23

Everyone should be fond of SPARC not just because I say of course but because SPARC is a standardized design (IEEE) no lisensing required... SPARC is what loongson claims to be and I'm sorry to say but Richard Stallman was duped when he got that loongson netbook as its hardware isn't open at all in fact its all extremely proprietary.

SPARC has inroads in space computing (high radiation environments)... mobile (S1 core) and Desktop/Server/Workstation with T1 and T2 processors.... if only companies would realise the advantage of using a design people can't sue you for useing versus ARM or MIPS which require expensive lisensing.

Interesting what netbsd is doing here I wonder if it works on SPARC32? this sounds alot like exokernel ideas are being implemented (optimised userspace libraries for usuaully kernel tasks) ... there was a comparison with MIT's exokenrel work that showed mind boggling proformance increases when libraries were optimised to the workload.

Edited 2010-04-29 15:07 UTC

Reply Score: 0

RE[4]: This is real news...
by phoenix on Thu 29th Apr 2010 18:50 UTC in reply to "RE[3]: This is real news..."
phoenix Member since:
2005-07-11

Loongson is MIPS-based, not SPARC-based.

Reply Score: 2

RE[5]: This is real news...
by lucas_maximus on Thu 29th Apr 2010 21:03 UTC in reply to "RE[4]: This is real news..."
lucas_maximus Member since:
2009-08-18

"SPARC is what loongson claims to be" ...

He wasn't saying that it was MIPS at all. Read his commment properly.

Reply Score: 1

RE[4]: This is real news...
by Zbigniew on Thu 29th Apr 2010 18:53 UTC in reply to "RE[3]: This is real news..."
Zbigniew Member since:
2008-08-28

Everyone should be fond of SPARC not just because I say of course but because SPARC is a standardized design (IEEE) no lisensing required...

Well, actually I fully agree - being an owner of Sun Ultra 10. ;)

But ARM new processors look interesting as well.

Reply Score: 1

RE[4]: This is real news...
by coreyography on Fri 30th Apr 2010 00:50 UTC in reply to "RE[3]: This is real news..."
coreyography Member since:
2009-03-06

In what way does Loongson "claim to be" SPARC? From what I read the instruction set is clearly MIPS-based.

I didn't think it was all that proprietary; the OpenBSD guys have a port already, and they usually don't have much fondness for closed hardware. Reading some of the devs' posts, it seems that the problems are that documentation is sparse (at least English documentation), and that certain aspects of the implementation are buggy.

All that said, for the $500 it costs to buy one in the US, I'll take a cheap i386 laptop.

Reply Score: 0

RE[5]: This is real news...
by robertson on Fri 30th Apr 2010 06:50 UTC in reply to "RE[4]: This is real news..."
robertson Member since:
2010-04-30

In what way does Loongson "claim to be" SPARC? From what I read the instruction set is clearly MIPS-based.

I think he's trying to say that SPARC is truly an open platform as the Loongson claims to be. Clearly cb88 thinks Loongson's claim to be open is false.

Reply Score: 1

Interesting
by strcpy on Wed 28th Apr 2010 17:41 UTC
strcpy
Member since:
2009-05-20

The whole "rump" (what a name...) deal is really interesting.

I would like to see it being used even more. Push many more things to the user space, that's they to go (unlike in Linux where the kernel absorbs more and more user space tasks). Even traditional Unix kernels can this way benefit from the "kind of L4-approach".

Reply Score: 3

RE: Interesting
by sorpigal on Thu 29th Apr 2010 13:27 UTC in reply to "Interesting"
sorpigal Member since:
2005-11-02

Linux does absorb a lot, but it's funny to see someone complaining about that rather than the far more common "Why are udev and dmix not in the kernel?" complaints.

Reply Score: 3

RE[2]: Interesting
by boldingd on Thu 29th Apr 2010 17:09 UTC in reply to "RE: Interesting"
boldingd Member since:
2009-02-19

That's what I was thinking. You can't please everyone.

But, what has the kernel absorbed lately?

Reply Score: 1

RE[3]: Interesting
by phoenix on Thu 29th Apr 2010 18:51 UTC in reply to "RE[2]: Interesting"
phoenix Member since:
2005-07-11

Ingo Molnar was involved in a long flamewar on the KVM mailing list as he want QEmu pulled into the kernel. ;)

Reply Score: 2

RE[4]: Interesting
by boldingd on Thu 29th Apr 2010 19:14 UTC in reply to "RE[3]: Interesting"
boldingd Member since:
2009-02-19

KVM did make it into the kernel, but that's not pointless kernel bloat; virtualization legitimately requires bits of code performing low-level hardware manipulation in a time-sensitive fashion, and needs bits in the kernel to achieve decent performance.

And, that's one. Keep going. ;)

Reply Score: 2

RE[5]: Interesting
by phoenix on Thu 29th Apr 2010 19:32 UTC in reply to "RE[4]: Interesting"
phoenix Member since:
2005-07-11

KVM == kernel-based virtual machine. It would be pretty silly to have that outsiide of the kernel. ;)

Ingo wanted the whole of the QEmu userspace split in two: the KVM bits and everything else. And the KVM bits of QEmu pulled into the kernel. In effect, forking QEmu.

Thankfully, the KVM guys were able to convince him of just how wrong that would be. ;)

Reply Score: 2

RE[6]: Interesting
by boldingd on Thu 29th Apr 2010 20:03 UTC in reply to "RE[5]: Interesting"
boldingd Member since:
2009-02-19

I'm not entirely sure I'm following you here. What of QEmu did he want pulled in, that wasn't already covered by KVM?

(If you don't wanna type a long, dry answer, you can just give me a link to thread and let me read it myself.)

Reply Score: 2

RE[7]: Interesting
by phoenix on Thu 29th Apr 2010 20:17 UTC in reply to "RE[6]: Interesting"
phoenix Member since:
2005-07-11

Search the archives for the thread: [RFC] Unify KVM kernel-space and user-space code into a single project

Reply Score: 2

RE[4]: Interesting
by anarxia on Sun 2nd May 2010 11:21 UTC in reply to "RE[3]: Interesting"
anarxia Member since:
2006-06-02

If I remember correctly, he wanted to put the qemu code in the kernel source tree and not to run the whole qemu in kernel space. It's hardly the same thing.

Reply Score: 1

RE: Interesting
by siride on Thu 29th Apr 2010 15:22 UTC in reply to "Interesting"
siride Member since:
2006-01-02

Linux isn't absorbing more and more into the kernel. Things continue to move out of the kernel, or remain out of the kernel.

I'm guessing you are complaining about KMS. Well, hardware resource allocation and management SHOULD be in the kernel and should have never been in userspace.

Reply Score: 2

Very interesting
by Bill Shooter of Bul on Wed 28th Apr 2010 19:31 UTC
Bill Shooter of Bul
Member since:
2006-07-14

Was not previously aware of rump. Very cool. I wonder what are the disadvantages of this kind of a set up.

* Duplication of code in memory ?
* Slower execution speed when going through rump?
* SMP Performance hit maybe?


Its like a mutant between micro and macro kernels. You get the macro kernel benefits of easy kernel aware development with some of the isolation of microkernels.

Reply Score: 2

RE: Very interesting
by boldingd on Thu 29th Apr 2010 17:12 UTC in reply to "Very interesting"
boldingd Member since:
2009-02-19

I'd really like to see some (rigorous!) performance measures. It sounds technologically nifty, but I'd also expect a significant performance hit (from wandering back out of the kernel and into userspace again, and then probably at some point crossing the kernel/userspace boundary the other way several times while the driver operates). I'd really love to know what the real stability gain vs. performance penalty trade-off that we're talking about is.

Reply Score: 2

RE[2]: Very interesting
by strcpy on Thu 29th Apr 2010 18:42 UTC in reply to "RE: Very interesting"
strcpy Member since:
2009-05-20

I'd really like to see some (rigorous!) performance measures. It sounds technologically nifty, but I'd also expect a significant performance hit (from wandering back out of the kernel and into userspace again, and then probably at some point crossing the kernel/userspace boundary the other way several times while the driver operates).


Me too. I am not sure where they are heading with this, but on the other hand, many things are not performance-critical. Anyone know if they are using this by default for... I don't know, say FAT file system or USB sticks or something like that?

Reply Score: 2

cool!
by sergio on Thu 29th Apr 2010 00:25 UTC
sergio
Member since:
2005-07-06

Really interesting... I'd love to see this kind of innovation in the (boring) Linux world.

BSDs are like Linux 10 years ago... hot and sexy. ;)

Reply Score: 4