Microkernels and drivers in user-space

>>58927341
You might argue that the kernel could provide some form of protection against this, for example offering an API that provides the physical memory regions that are valid for the device alone. The issue, however, is that where in memory device are mapped is a completely arbitrary process and done solely at the discression of the BIOS. In other words, you'd end up with an extremely bloated API that does a bunch of redundant checking in order not to expose physical address space to user-space. This would violate the very premise for running a microkernel in itself, not to mention that you'd be exporting a bunch of functionality such as pinning pages, requesting DMA buffers at certain ranges with such and such alignment, to user-space while still having to do all the checks in kernel. If you think syscalls are a bad idea and very monolithic, imagine this monstrosity of an API.

Of course, this only addresses the issue of a driver having access to physical address space. Then there's also the issue of DMA and the device itself. When a driver does DMA, it typically requests the kernel for a continuous memory region which the device is able to reach (some devices, such as Nvidia GPUs only have 30 address bits, meaning that they can't address the entire 64-bit address space). The driver then passes the address of this range to the device (writing it into a register using MMIO) and the device will then either read or write directly to RAM without involving the CPU. In other words, Direct Memory Access (DMA).

2 / 4

>>58927351
Myth 2: IOMMUs solve everything

The problem though, is that the driver can pass along ANY physical address and make the device read or write into arbitrary memory locations (again, for example where the kernel resides). Of course, you'd might be thinking right now that this is where IOMMUs come in, and you're quite right.

In addition to eliminating the need for bounce buffers (the case mentioned above where the Nvidia GPU need to address something above 30-bit address), IOMMU can also provide address isolation by grouping devices into so-called domains. This prevents a driver from flushing data into random physical addresses. HOWEVER, the problem again is that setting these up are usually the task of the device driver. Exposing IOMMU access to user-space is a bad idea, so you'd end up incorporating this into the horrendously bloated API mentioned above.

This of course assumes that there is an IOMMU available in the first case, something architectures other than x86 usually don't have. There's also the issue with PCIe P2P, enabling the IOMMU means that every TLP (aka memory operation) is forwarded to the root complex instead of just taking the shortest path. A network card reading from a disk would experience a serious performance degradation. There is stuff like ATS but they are highly vendor specific and an AMD implementation of ATS is not respected by Intel's VT-d for example. In additon, only a minority of devices actually support ATS. Nvidia GPUs certainly don't.

3 / 4

>>58927356
Myth 3: The performance penalty of running in user-space is negligible

As I mentioned above, P2P performance is kill if you use an IOMMU. However, the biggest performance killer is the cost of context switch.

First of all, running in user-space means that your driver is subject to the scheduler and in risk of having it's memory swapped out. Of course, you could solve this by giving higher priorities to the driver as well as pinning its memory in RAM, but then you again have the situation where there is no real separation between user-space and kernel-space. The Linux kernel also runs in virtual address space and its memory is just always part of the first 1 GB of memory and protected using the hardware page protections. So in effect you blur out the differences between kernel-space and user-space and you gain none of the "benefits" of running in user-space.

The real issue here, however, is that you'd need some sort of mechanism to disable interrupts (and thus preemption) from user-space, because sometimes the device driver might do something that requires atomicity and can't be interrupted by the scheduler. So add this functionality to the already bloated driver API and in addition further blur out the hard separation between kernel-space and user-space.

Secondly, there's also the issue of device initiated interrupts. Imagine a Gigabit ethernet network controller generating an interrupt for every received packet. Normally, interrupt routines are short and do little stuff. For user-space drivers, however, you'd need to context switch back into user-space and then run some routine in user-space while at the same time providing deadline guarantees and blocking guarantees.

4 / 4

tl;dr

Someone is mad as fuck

tldr

No one cares, you fucking angry turbonerd

Sage

>>58927436
>>58927425
>>58927400
>informative argument against microkernel design
>"tl;dr"

Millennials

>>58927369
>>58927356
>>58927351
>>58927341
I guess Linus was right, then.

>>58927459
>muh millennials

It's an autistic rant spanning 4 posts about a subject no one cares about. KYS

>>58927341
>Inspired by the bunch of fucktards yesterday who knew nothing about device drivers, I decided to make this thread explaining why microkernels that run drivers in userspace is a meme and needs to die.
Now that's some dedicated shitposting

>>58927523
I made an informative rant about why I think device drivers in userspace is a bad idea, and that's your best comeback?

>>58927529
>I just slapped together some random words and hope that they sound coherent enough to seem intelligible
Fix'd. Now go back to playing with Java, pajeet, and let the grown ups discuss kernel design.

>>58927547
Why are you so mad? How about actually addressing the actual arguments instead of throwing semi-racist /g/ memes around?

>>58927573
>baaawwww it's racist!!!!

Did I hurt your little poo in loo feelings, you disgusting currynigger?

All of this is very easy to refute: managed code.

You wouldn't be willing to let heavy abstraction layers such as JVM and CLR clog up your systems in exchange for a little security to begin with if monolithic kernels weren't such a massive failure.

2/10 made me reply

Cool now go make your autism kernel that will never ever be used.

Linux, Windows, Mac and the good BSDs are popular because they deliver features instead of internet autism wars

>>58927584
Managed code would introduce even more abstractions...

>>58927592
>Cool now go make your autism kernel that will never ever be used.
I'm arguing for the design that's already used in Linux and FreeBSD, instead of some autistic pet projects

>>58927341

So for the MMIO you just map a page to that physical address, I don't see the problem here.

>>58927584
>All of this is very easy to refute: managed code.
Not OP, but you'd still at some point need to deal with physical addresses and actual pages, which is OP's argument. And when you do so, it doesn't matter how "safe" the rest of the driver is, you're still able to fuck up unless you introduce layers upon layers with bloated "security" abstractions (which entirely violates the microkernel design principle in the first place).

File: nodeos[1].png (31KB, 352x240px) Image search: [Google]

31KB, 352x240px

>Not running NodeOS

>>58927617
>So for the MMIO you just map a page to that physical address, I don't see the problem here.
The problem is that you're exposing physical addresses to user-space, which would then be able to read and write into arbitrary memory locations thus breaking out of the user-space encapsulation.

>>58927617

Read part 2. It isn't a problem to map pages to physical addresses (this is already how it's done in all systems), the problem is that you're allowing user-space access to physical memory as >>58927639 said.

>>58927341
Uh, no Richard. Linux is the operating system, not just the kernel, and correcting users to say ganoo plus Linux in a vapid attempt to stay relevant is sad.

File: rms.jpg (1MB, 1683x1725px) Image search: [Google]

1MB, 1683x1725px

>>58927675
What the fuck did you just fucking say about me, you proprietary slave? I’ll have you know I graduated top of my class at Harvard, and I’ve been involved in numerous free software projects, and I have contributed to over 300 core-utils for GNU. I am skilled in Lisp and I’m St. IGNU-cius, saint of the Church of Emacs. You are nothing to me but just another unethical non-free software advocate. I will distribute the fuck out of your source code with freedom the likes of which has never been seen before on this Earth, mark my fucking words. You think you can get away with saying that shit about me and the GPL on the Internet? Think again, fucker. As we speak I am contacting my colleagues at FSF and your binaries are being reversed engineered right now so you better prepare for the storm, maggot. The storm that wipes out the pathetic little thing you call your copyright. You're fucking dead, kid. Free software can be anywhere, anytime, and it can ensure your freedom in over four ways, and that’s just with the GPLv2. Not only am I extensively skilled at C hacking, but I have access to the source of the entire GNU userland and core-utils and I will use it to its full extent to wipe your miserable proprietary code off the face of the continent, you little shit. If only you could have known what ethical retribution your little “clever” program was about to bring down upon you, maybe you would have ensured your users' freedom. But you couldn’t, you didn’t, and now you’re paying the price, you goddamn idiot. I will shit free as in freedom all over you and you will drown in it. You’re fucking dead, kiddo.

>>58927400
>>58927425
>>58927436
>>58927523
>>58927547
>>58927578
4chan in a nutshell

>>58927675
That's Doctor Richard Matthew Stallman, PhD to you.

>>58927490
>Subject no one cares about
> /g/ - Technology
They should rename this board to mindless consumerism or something

>>58927341
I use Windows, couldn't care less about this.

>>58927341

The Kernel/user space dichotomy shouldn't exist. There should simply be an int's worth of process spaces, with no TLB or cache flushing required to switch between them.

Processor hardware is retarded.

>>58927827
>I don't care about inner workings of an operating system or how device drivers work because I'm a mindless consumer
ftfy

>it's 2017 and he still uses drivers
lmao

>>58927639
>>58927662

Like that I see. I'm actually thinking of making my own microkernel, so I thought about this. How it would work in my kernel is that the drivers get loaded in either by the init system or a command ran by the user (under root of course). Upon init the driver then requests the devices it wants to use to be mapped into their address space. If the device is already mapped the call fails and the driver is shut down. It prevents just any process taking control over a driver.

As for the part about exposing physical addresses to user-space processes, it is not any more dangerous than running a driver in a monolithic kernel. Drivers carry certain responsibilities, part of which is not fucking up the devices they are made for.

File: Smug.jpg (29KB, 500x360px) Image search: [Google]

29KB, 500x360px

>>58927341
Fuckin nerd

>>58927876
>Upon init the driver then requests the devices it wants to use to be mapped into their address space. If the device is already mapped the call fails and the driver is shut down. It prevents just any process taking control over a driver.
So what about stuff like NVMe disks that can potentially support multiple lightweight drivers (as long as one is responsible for setting up admin queues)? What about SR-IOV capable devices that have a separate driver for each virtual function (which maps to the same physical address range)?

>As for the part about exposing physical addresses to user-space processes, it is not any more dangerous than running a driver in a monolithic kernel.
This is true, and is also part of my point. You're effectively blurring out the hard line between user-space and kernel-space.

>Drivers carry certain responsibilities, part of which is not fucking up the devices they are made for.
I'm mostly concerned with breaking out of their isolation, by accessing arbitrary regions of system memory and gaining access to kernel pages. In this case, the argument for running in user-space is entirely moot.

>>58927904
>>58927876
To reformulate my posts: I'm not saying that user-space drivers are inherently any less secure than kernel-space drivers. What I'm saying is that I fail to see how the benefits of running in user-space applies when you're dealing with stuff that has full control over physical memory. Such a driver crashing will still bring down the entire system in almost all cases.

>>58927369
atlast an informative quality post. Thanks for making 4chin better.

>>58927946
>informative quality post
>pure lies
huh.... really makes you think..

>>58927962
How is it lies? Or are you baiting?

>>58927490
>b-but I'm too retarded to read one or two paragraphs so only /v/ tier GPU shitposting shoul be allowed on /g/

>>58927965
obvioua bait

>>58927965
(You)

This isn't smartphones, get out

>>58927936

I guess why people do microkernels is for the little added security such as dereferencing a null pointer or restarting drivers when they crash. Also tell me in what case a driver would crash the whole system.

>>58928047
>I guess why people do microkernels is for the little added security such as dereferencing a null pointer
This could be handled simply by adding a protection fault handler to do some gracious error handling in kernel space, seeing how most modern kernels run in virtual address space (like Linux do).

>Also tell me in what case a driver would crash the whole system.
Pointing a device DMA to kernel memory for example (which could be handled by IOMMU, assuming you've set up proper domains, something your microkernel must also do and further blurring out the lines between user-space and kernel-space). Or a malicious driver could retrieve physical address of kernel pages and inject code into them.

Then there's device initiated interrupts and having interrupt routines in user-space, you'd have to add the cost of doing a context switch.

Then there's the issue of disabling interrupts and scheduler preemption, you'd be even further blurring out the lines between user-space and kernel-space. If you disable preemption and you start a blocking call by mistake (to take a lock that's already taken or whatever), you're fucked and have deadlocked your system no matter if it runs in kernel space or user space.

>>58928103
Not the guy you're responding to, but thanks.

wtf i hate microkernels now

What does this autistic shitfest have to do with /g/ ?

Fuck off back to your friendly linux thread generals.

File: wtf-am-i-reading.jpg (156KB, 327x657px) Image search: [Google]

156KB, 327x657px

>>58928358
>what does computer architecture and OS design have to do with technology

Thamk you based Torwalds.

>>58927341
>>58927351
>>58927356
>>58927369
Thank you based OP

>>58927341
So you got butthurt and rekt in the Rust thread yesterday and now you made an 8000 character long rant about how butthurt you are? keke

>>58927341
I think your computer science teachers are still teaching you from books written in the '80s, when the word "micro-kernel" was associated with a future utopia.

>>58927341
>Tannenbaum
He is a fucking retard who spouts academic memes, because he can't into real stuff.

I would even go as far as to say that anyone who would like to see some different shit should look at Terry A. Davis's TempleOS. The way he does certain things is interesting.

>>58928546
I was actually referring to (uninformed) opinions touted in a thread yesterday, where a bunch of /g/entoo men claimed that microkernels and userspace drivers was the best thing since sliced bread yet they seemed completely unknowledgable about how device drivers actually work.

>>58928587
Terry doesn't do things interestingly. Quite the contrary, his FAT-like file system, his 1:1 virtual memory layout, his drawing to VGA buffer graphics etc are just how DOS did it 30 years ago. The only improvement upon DOS is an preemptive scheduler, which isn't fucking hard to implement.

>>58928587
>>58928587
desu Minix is a lot more interesting than Terry "I can't into virtual memory" Davis

>>58928638
>Minix is a lot more interesting than [templeOS]
This

>>58928596
Sorry, I meant that more towards them, than you.

File: notanarguememt.jpg (178KB, 699x536px) Image search: [Google]

178KB, 699x536px

>>58927547
>>58928509
>>58928587
>>58927459
>>58927436
>>58927400

>>58927369
>However, the biggest performance killer is the cost of context switch.

No, not really. See cost of context switch on Linux vs cost of context switch on seL4.

You'd need hundreds of times as many context switches on seL4 for it to even match Linux overhead of one context switch.

>took a semester of operating systems, had to implement a microkernel
>it was literally just a rip off of MIT's 6.828
>implying I didn't steal all the code
Hardware classes are more fun than operating systems. Fuck OS niggers.

>>58929273
This is not true, anon. The cost of context switching on Linux is actually very low since the kernel makes out the first 1 GB of memory of every process and is pinned to that memory.

>>58929273
seL4 is a meme, anon

https://wiki.sel4.systems/FrequentlyAskedQuestions#What_about_DMA.3F

>cannot prove that DMA is well-behaved so proof assumes that it doesn't exist

>>58929327
Hah.

Run lmbench's lat_ctx on your Linux super workstation sometime. Compare it with well known seL4 values from this well known paper.

http://sigops.org/sosp/sosp13/papers/p133-elphinstone.pdf

>>58929451
Well, DMA is more of a hardware problem.

All that drivers under seL4 can do is use the IOMMU to contain the hardware to the driver's own pagetable.

>>58929451
The only numbers I see in that papers are for "one-way IPC of various L4 kernels", which does not really give any indication of the cost of context switching.

>>58929596
>All that drivers under seL4 can do is use the IOMMU to contain the hardware to the driver's own pagetable.
It clearly states that IOMMU is experimental and for the unproved/unverified variant of seL4.

>>58929614
Was meant for >>58929578

OP you are so intelligent. I wish I could regurgitate my Intro Operating System lecture notes, and put them in my own words as well as you!

>>58929614
>IOMMU to contain the hardware to the driver's own pagetable.
That's not how IOMMUs work though. IOMMU provides virtual IO addresses (bus addresses) which translates into physical addresses. EIther the driver or the kernel needs to set up the correct IOMMU domains, it doesn't happen magically. Usually it's done by the driver in order to have full control over the device.

>>58929614

>It clearly states that IOMMU is experimental and for the unproved/unverified variant of seL4.

seL4 usually implements things and only verifies them sometime later. Personally, I don't care so much about verification as I do about the ongoing virtualization support, particularly the VMM, which is userland.

https://sel4.systems/Info/Roadmap/

> The only numbers I see in that papers are for "one-way IPC of various L4 kernels", which does not really give any indication of the cost of context switching.

That's the cost of sending one message to one process to another. That is the most relevant case of context switch, in terms of microkernel design overhead. There's also the timer causing tasks to switch so that all runnable tasks get a chance to run, but that one isn't microkernel specific.

>>58927848
>I think I'm not a mindless consumer because I use a broken operating system, with the compensation "At least I understand how my OS werks XD"

>>58929687
But it is an extremely vaguely defined metric (messages can be of an arbitrary size), and it doesn't say anything about how they measured it (did they run it once, is it an average, what is the distribution? etc). I cannot compare this number fairly, you'd need to run tests on the same hardware with fairly similar circumstances.

Anyway, as for the cost of context switching on Linux. As mentioned, it is very low because kernel memory is already mapped into the first 1 GB of every process' address space. It's only a matter of restoring a stack pointer and a couple of registers and flushing the cache (which is the highest cost of context switching). Not even seL4 can avoid this.

>>58929715
We're not discussing an actual OS here, we're discussing the cost of running drivers in user-space. Pay attention, you might learn something.

>>58929761
I was remarking your stubborn pretentiousness of not understanding people share your interests. Keep shitposting pretending to be a CS PhD, you might go somewhere.

>>58929813
*don't share your interests

>>58929813
>I was remarking your stubborn pretentiousness of not understanding people share your interests
You are free to ignore this thread completely, yet you decided to post in it and pretending to be proud of being an ignoramus.

The post literally reads "I use Windows, couldn't care less about this", yet it should be obvious that even Windows has IO device drivers and needs to do things in an optimal way.

>Keep shitposting pretending to be a CS PhD, you might go somewhere.
I am actually a PhD student.

>>58929854
I posted in this thread because I try ignoring idiots like you everyday. No it shouldn't be obvious, because he simply "doesn't care" something you fail to understand.
>I'm a PhD student
Okay kid

I agree OP.

You want to know what's really going on? Microsoft and other companies, (and even governments) are independently trying to kill linux and open source.

The GPL is a danger to every big tech company because it means they can't community driven software, re-brand it, and sell it.

Governments are also anti-FOSS because they're all abusing technology to spy on us. If all software were open source and people thought negatively of closed source, it would make it much harder to spy on people (we know the NSA was working with Microsot).

Also, these organizations use SJW tactics to try to control and destroy communities. Look what happened to Mozilla. Firefox was the alternative to the bot net, now shills post everyday about how it's an SJW company, and the SJWs have really infiltrated it.

People pushing non-Linux kernels are just attempting to disrupt the Linux and open source ecosystem.

>>58929903
>I posted in this thread because I try ignoring idiots like you everyday.
That literally doesn't make any sense.

>>58929923
What's to understand, I got tired of seeing threads like these everyday, so I started shitposting them. Was that hard Doc?

>>58929903
>No it shouldn't be obvious, because he simply "doesn't care" something you fail to understand.
You're on a technology discussion board and you get angry because people are discussing how technology works?

That's some high level autism right there.

>>58929946
>I got tired of seeing threads like these everyday,
You get tired of seeing threads discussing hardware architecture and OS design every day?

Tell me, why the fuck are you even on /g/ then?

>>58929761
>and it doesn't say anything about how they measured it

They didn't just measure it. This is WCET (Worst Case Execution Time), which is one of the proofs they do.

>>58929963
But still, you agree that it is a vague metric? I mean, the statement "message passing takes 0.05 microseconds" doesn't really say anything. What is a message? How long is it?

>>58929949
>>58929960
I get tired of reading about pseudo-intellectuals getting butthurt with other posters because they don't share interests.

>>58927801
More like "Shallow IT and PC Gaming".

Make /prog/ a thing again.

>>58929761
>it is very low because kernel memory is already mapped into the first 1 GB of every process' address space. It's only a matter of restoring a stack pointer and a couple of registers and flushing the cache (which is the highest cost of context switching)

Linux is remarkably slow at this. It takes over a whole microsecond, even on many-GHz CPUs.

Part of why is that the process concept is bloated on Linux. Part of it is that kernel memory being mapped isn't anywhere as good as a whole microkernel permanently pinned in the TLB.

> Running drivers in user-space would mean exposing physical addresses to user-space. With no additional form of protection, a bad or malicious driver could potentially read and write from arbitrary locations in RAM including where the kernel resides.

How about every driver having its virtual address space just like any ordinary process?

>>58929995
>pseudo-intellectuals
Do you have some sort of inferiority complex, anon?

I was making a case for why user-space drivers is a bad idea, by explaining how it would be implemented and why this is insufficient. What would you have me do, post memes and reaction images about Tannenbaum instead?

I'm not butthurt that you don't share my interest, all I did was commenting on the ignorant statement saying "I use Windows therefore I don't care". Obviously Windows have IO devices and drivers too, therefore Windows users aren't unaffected by driver design choices.

>>58930016
>Linux is remarkably slow at this. It takes over a whole microsecond, even on many-GHz CPUs.
No, it literally takes nanoseconds.

>Part of it is that kernel memory being mapped isn't anywhere as good as a whole microkernel permanently pinned in the TLB.
It *IS* permanently pinned in the TLB... Why do you think it is mapped into the same area of memory for every process?

>>58930027
>How about every driver having its virtual address space just like any ordinary process?
If you want an actual device to access memory, you cannot avoid having to deal with physical memory.

>>58930053
>No, it literally takes nanoseconds.

No, it literally takes microseconds.

http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html

>>58930027
>How about every driver having its virtual address space just like any ordinary process?
Drivers already run in virtual address space, they do it on Linux and they do it on most OSes I know. The point is that you have to get physical addresses for stuff like DMA buffers.

>>58930064
isn't that why IOMMU has been recently included in new processors? just to have MMU for IO devices just like the processor?
so If we have IOMMU, every driver can deal with its space without having to know the real physical address or worrying about other process stealing or modifying its data, right?

>>58930085
Anon, this is seven years old.

>>58930107
If you're saying this changed, where's your newer data?

>>58930104
It's halfway correct. See >>58927356 and >>58927369

First of all, only x86s have IOMMUs, and they are still highly vendor specific. In addition, enabling the IOMMU absolutely kills device to device access, because instead of taking the shortest PCIE path, everything is now routed through the root complex.

Secondly,
> every driver can deal with its space without having to know the real physical address or worrying about other process stealing or modifying its data, right?
Not really. Someone has to set up correct IOMMU mappings, and this is a job for the device driver (because the device driver is aware of addressing limitations of the device, knows how many DMA buffers it needs, knows when to set up and tear down these buffers, knows when to access potential other devices [to do RDMA] etc). This would still lead to the situation where the device driver has control over physical address space.

>>58930158
>This would still lead to the situation where the device driver has control over physical address space.

No, not necessarily. See openbsd's pledge() for the idea of dropping privileges after initialization, and Genode handbook 16.05 for the idea of capabilities to physical memory frames.

>>58930041
I do share your interests, you're obviously distraught when you are calling someone a "mindless consumer".

>>58930134
Again, you're using imprecise metrics because "cost of context switch" isn't clearly defined. The blog you posted to, for example, says that system calls aren't triggering what he calls a "full context switch", but he doesn't define what he considers a full context switch.

What he measures is the time it takes for a thread to wait for a mutex, which isn't the same as the cost of a context switch but how long it takes for a blocked process to be rescheduled.

Seeing that flushing the cache is the most influential cost of a context switch, you and I could agree on using the time it takes for flushing the cache as a metric of the cost of a context switch. But I imagine you wouldn't agree to this, because it is the same regardless of OS.

>>58930158
>enabling the IOMMU absolutely kills device to device access, because instead of taking the shortest PCIE path, everything is now routed through the root complex.

Please provide a common real-life example of this device to device communication which isn't DMA (as DMA always has CPU as arbiter) happening. I'm genuinely curious.

>>58930158
I read them, as far as I understand there's nothing wrong with delegating driver shit to userspace except performance (faggots are you even aware? the bloat in userspace used by Python or even many popular infrastructure user-space programs like databases? performance what?)

As long as it's not graphics or network that need real-time and high performance requirements, user-space is a prudent thing to do.

However, software in 2017 is so much bloated that this discussion has zero difference on the important issues on how to advance software

>>58930191
A person saying "I use Windows so I don't care", implied "how it works", is rightfully classified as a mindless consumer.

>>58930186
>pledge
This is not relevant. You need to pass bus addresses, virtualized or not, to a device in order for it to do DMA. Setting up virtual bus addresses is clearly best done by the driver, since the driver knows about device capabilities and how it functions.

pledge() is simply a string containing a list of resources it will use, it doesn't translate into "i will not touch these areas of memory".

>>58930240
I mean people who studied computer architecture and OSs can't even imagine how inefficent the software used in high levels are, javascript, python, ruby, databases.. the whole system is fucked beyond imagination, and it can't be fixed at this point, it just fucking works

>>58930209
Old, but relevant: https://archive.fosdem.org/2012/schedule/event/549/96_Martin_Decky-Microkernel_Overhead.pdf

>>58930209

New and relevant:

https://fosdem.org/2017/schedule/event/microkernel_microkernel_for_embedded_devices/

>>58930250
A person that doesn't care about the complex inner workings of the OS they use is a mindless consumer. Okay I'll keep that one.

>>58930218
>Please provide a common real-life example of this device to device communication which isn't DMA (as DMA always has CPU as arbiter) happening
My point is that even DMA transfer is routed through the root complex, unless you use something like ATS (which, as explained previously, is highly vendor specific and not well-supported). But for your specific request, NVMe over Fabrics is one such case.

As for applications that are severely limited by IOMMUs, GPUDirect RDMA using InfiniBand.

>>58930240
If you have a high-speed SSD or an interrupt heavy network controller, you wouldn't want to run this in user-space.

But you are correct, it isn't a problem in itself to delegate everything to userspace, but you either introduce a lot of downsides or blur out the line separating user-space and kernel-space for little to no actual benefit.

>>58930240

>As long as it's not graphics or network that need real-time and high performance requirements, user-space is a prudent thing to do.

The performance issue was fixed by Liedtke in the first 2nd generation microkernel, L4.

Current microkernels such as NOVA, F9 or seL4 are part of the 3rd generation already.

>>58930299
You are on a technology board anon, posting in a thread that is discussing the inner working of the OS.

>>58930284
I may be mistaken, but IIRC the F9 microkernel has a completely different approach to the traditional user-space/kernel-space distinction.

No wonder Hurd never took off. Thank you for the very informative thread, OP. Best thread I've seen on /g/ in a long time.

>>58930308
That's the only example I did come with when you suggested it earlier. I didn't even mention it as it's not hardware you'd see very often unless you work on a datacenter.

>>58930333
>I may be mistaken, but IIRC the F9 microkernel has a completely different approach to the traditional user-space/kernel-space distinction.
Not him, but most embedded systems do. Usually everything runs with the same privilege levels and as part of the kernel itself.

>>58930333
Started by a person that can't accept people have differing interests.

>>58930333
Do you still call people sheep too?

>>58930346
HURD never took off for a variety of reasons.

Problems with running drivers in userspace isn't one of them, as they did not run them on userspace at all until very recently (2010s).

Try as they may, it's going to suck as they're using a 1st generation microkernel (GNU Mach).

i don't know much about all this, so think might sound silly, but what about the user space makes it safer, and why can't the same be done for a driver in kernel space?
if neither kernel nor user space in their current definition is ideal, could it make sense to make another "space" for drivers?

>>58930365
>I didn't even mention it as it's not hardware you'd see very often unless you work on a datacenter.
Well, for more consumer oriented stuff, plenty of people are doing 3D reconstruction or other GPU intensive stuff (like Tensorflow or other machine learning stuff) on multiple multiple local GPUs that benefits from P2P device transfer.

>>58930374
I really don't understand the point in posting in a thread saying that "I don't care because <insert irrelevancy here>", no. That's true. Maybe I should start posting in the private tracker threads saying "I don't care, I use a bicycle".

>>58930387
>>58930374
Samefag with inferiority complex

>>58930404
this* might

>>58930371
Sadly many such systems don't even do any userspace or virtual memory.

Hopefully the IoT security disaster might set people in the right track.

>>58930387
>>58930374
Samefag

>>58930404
when you execute code in the kernel space it can see the whole real physical space, it can read any data or modify any data at any address without the kernel doing anything about it , the kernel trusts the kernel code and considers it a part of itself

>>58930404
>i don't know much about all this, so think might sound silly, but what about the user space makes it safer, and why can't the same be done for a driver in kernel space?
Not a lot, which is the point of OP.

However, in reality, user-space offers implicit protection because it's running like any other user-space process while in kernel people usually don't bother with all the security measures (because you're running with the highest privilege level anyway).

>>58930405
There was no point he was shitposting, like me.
>>58930411
Did you not notice it was posted directly after? Talk about superiority complex.

>>58930427
even if it's not malicious code, just a bug can fuck up the entire system, however in user code, if the code tries to access unauthorized data space, it segfaults or the kernel just interrupt and close it without fucking up the entire system

>>58930419
>Hopefully the IoT security disaster might set people in the right track.
Yes, hopefully.

I've actually seen positive signs though. People are currently modifying Docker to make it more lightweight and support stuff like running on embedded devices and for CUDA stuff (see nvidia-docker on GitHub).

>>58930404

>what about the user space makes it safer, and why can't the same be done for a driver in kernel space?

https://en.wikipedia.org/wiki/MINIX_3#Reliability_in_MINIX_3

Most of that can't be effectively done unless drivers are contained as userspace processes.

> if neither kernel nor user space in their current definition is ideal, could it make sense to make another "space" for drivers?

The main claim repeated ad nauseam against drivers in userspace is that the performance is severely impacted. This is true for 1st generation microkernels, not with post-Liedtke's L4 (2nd gen) microkernels. We're at the 3rd gen already.

>>58930440
>Did you not notice it was posted directly after?
It's almost 2 minutes apart. Considering how the cooldown timer is 1 minute, I would say it's a clear example of samefagging.

>>58930440
Or, maybe I'm not familiar with 4chan, and used to having an edit feature?

>>58930490
>>58930466
Was a reply to this, goes to show how well I can use this lol.

>>58930450
I'm seeing projects like seL4, camkes, genode, F9, Minix3, etc. take off.

Even Google's jumped into the microkernel train, first with LK (little kernel), now on full throttle with Magenta / Fuchsia. I expect ChromeOS/Android to be effectively rebased on it come 1-2 years.

>>58930461
No matter how many generations, it's still true unless you blur out the distinction between kernelspace and userspace.

As for fault tolerance and reliability, you can implement all those in kernelspace. A sensible protection fault handler would gracefully handle rogue pointers, liveness monitors would handle deadlocks and infinite loops and buffer overflows would be handled by doing virtual address space with proper page-level protection (which is already done in e.g. Linux).

>>58930511
Magenta has the concept of "core drivers" which run in kernel space though. But then again, all these embedded OSes are effectively blurring out the distinction between kernelspace and userspace.

>>58930514
>No matter how many generations, it's still true unless you blur out the distinction between kernelspace and userspace.

No it's not. Liedtke demonstrated single digit % overhead on server loads when he presented L4 in ~1996, with Mach (1st gen) having 2.5x slowdown in the same scenario.

>>58930490
>Or, maybe I'm not familiar with 4chan
Apparently you're not very familiar with the concept of interest-specific boards either, since you're apparently completely uninterested in discussing technology.

>>58930534
So does, say, HelenOS.

When you're getting a debug feed to the serial port, you probably want your serial port driver in the kernel. You also probably want your timer driver in the kernel.

These are very special cases which aren't really against Liedtke's principle of minimality.

>>58930557
Did you actually make a conscious effort to compare my timestamps? I'm under the impression you are mentally ill and/or really fat

>>58930545
Things have changed radically since 1996 though.

In 1996, IDE was the dominant disk bus technology and IO was objectively slow (factor of several millions compared to accessing RAM). On x86, the IO bus was also connected to the chipset on the south bridge.

Today you have high-speed IO devices on PCIE lanes that go directly to the CPU. Accessing PCIE NVME disks is a factor of a couple of hundreds compared to going to RAM.

It's a completely different game.

Nice wall of text, however:

>networking in kernel space: 10 Gbit/s max, shit SMP support
>DPDK: 100+ Gbit/s, excellent scaling

>>58930591
>telling time is an effort
You do know that the post time is like, right there.

>>58930624
DPDK works on hypervisor level (aka in the kernel of the hypervisor).

>>58930591
>I'm getting told therefore you're crazy and fat

You're visibly upset

>>58930627
You're right it isn't, but there is definitely something crazy about backtracking a persons timestamps lol.

>>58930647
False, DPDK can also work with virtual interfaces, but for real NICs it completely bypasses any kernel.

>>58930660
Dude, you got called out. Just let it go.

>>58930660
There's something even more crazy about being so emotionally invested that you pretend to be two different posters.

>>58930613
>Accessing PCIE NVME disks is a factor of a couple of hundreds compared to going to RAM.

In short, hundreds of times slower when compared to RAM. Not really an issue for the microkernel multiserver approach.

>>58930649
Or, maybe I was trying to give you a reality check?

>>58930680
>but for real NICs it completely bypasses any kernel.
Yes, because it has firmware functionality and works on hypervisor level. That is very different from running in user-space anon.

Also, it requires a LKM in both hypervisor and inside VM guests, so it clearly operates in kernel level.

File: nerd.jpg (323KB, 822x584px) Image search: [Google]

323KB, 822x584px

>>58927341
>>58927351
>>58927356
>>58927369
nerd

>>58930695
>In short, hundreds of times slower when compared to RAM
Yes, but literal millions of times faster than when your benchmarking numbers are from.

>Not really an issue for the microkernel multiserver approach.
Reducing IO overhead is always an issue for servers, anon. You'd want to reduce those times even further.

>>58930704
I'm here discussing driver models, anon. You're here making excuses for your shitposts. Which one of us do you think needs a reality check?

>>58930686
>>58930688
Yeah, Dale Gribble of 4chan pointed out that I posted two minutes after. Is it not possible that I genuinely thought of something else to say and posted it?

>>58930756
The fact that you've spent more than a minute trying to justify shitposting says everything, no matter if you intentionally samefagged or legitimately just made two posts.

>>58930743
You post educated discussions on a meme board, and get offended when no one takes you seriously.

>>58930728
>Reducing IO overhead is always an issue for servers, anon. You'd want to reduce those times even further.

Why not run your services in kernelspace? All the wasted throughput! /s

>>58930790
Services that have hundreds of thousands of lines of code to be implemented need isolation because they can do something stupid. Device drivers of a few hundred lines of code does not.

>>58930713
What fucking hypervisor, you dumb nigger?

DPDK enables direct access to the DMA buffers to userspace applications, there is no kernel involved.

>>58930787
>no one
There's only evidence of one person so far. And I clearly called you out on it, you're the one that got offended by being called a mindless consumer.

>>58930814
>DPDK enables direct access to the DMA buffers to userspace applications,
This is literally what Linux' DMA API does.

>there is no kernel involved.
Oh really, what does their LKM do then?

>>58930816
lol I was never the mindless consumer, I was the one defending the "mindless consumer" as a person interested in operating systems.

>>58930801

Code quality is TERRIBLE in drivers.

See the slides from https://fosdem.org/2017/schedule/event/microkernel_microkernel_for_embedded_devices/

>>58930855
>it's terrible because I say it is
It doesn't change the fact that it's easier to maintain correctness of a driver than for huge services, which was the point I replied to.

Anyway, you're also ignoring the fact that many drivers are open source and peer-reviewed and have to follow strict guides in order to be accepted.

>>58930814
>What fucking hypervisor,
Not him, but the whole point of DPDK is to provide direct access to network controllers to VMs.

>DPDK enables direct access to the DMA buffers to userspace applications
This process literally invokes kernel functionality (namely the DMA API in the kernel) and is the reason why there's a bunch of different purpose kernel modules included in the DPDK suite.

ITT
>you nerds will argue about anything - the thread

>>58930874
>Anyway, you're also ignoring the fact that many drivers are open source and peer-reviewed and have to follow strict guides in order to be accepted.

You mean like Linux and its horrendous driver code quality?

>>58930936
>You mean like Linux and its horrendous driver code quality?
Hi Theo, please confine yourself to the BSD thread.

No, but seriously, it's not really horrendous. Many device drivers are actually high-quality, Intel drivers generally tend to be very good for example. I know, I've examined the NVMe driver and the e1000 driver closely for my current line of work.

Anyway, this is devolving into a meaningless discussion of subjective opinions about code quality.

>>58930846
>a person interested in operating systems.
How could he be, if he, at least according to you, didn't post anything except "I don't care, I use Windows" ?

On what basis do you infer that he was, contrary to his only statement, actually interested in the discussion?

>>58930998
I don't think you get what I'm saying. I'm interested in operating systems. I'm defending someone who isn't.

>>58930932
>/g/ cherishes alternative, non-mainstream concept despite overwhelming evidence that it's ineffective
>Talk smack about said cherished concept
>/g/ goes into an autistic rage

Every time

>>58930964
>Anyway, this is devolving into a meaningless discussion of subjective opinions about code quality.

Subjective? Nah. It's been thoroughfully studied and it's bad.

>>58931076
You can claim this all you want, but the only person being autistic about it is Theo de Raadt and his opinions are hardly the basis of "thorough studies".

Unless you of course have managed to come up with some non-subjective, entirely objective set of metrics to measure code quality, which I seriously doubt.

>>58931056
>>58931056
The real question is why are you defending a literal shitpost?

It was shitpost because
1) it contributed nothing to the thread
2) it contained an irrelevancy, clearly demonstrating the poster's lack of understanding about the subject
3) it also demonstrated the poster taking pride in being ignorant about the subject

>>58931076
>Subjective? Nah. It's been thoroughfully studied and it's bad.

I'm another anon, but forgive me if I don't take your word for it

>>58931106
uuuuuuummmmmmfffff 'cus he called him a mindless consumer bruh. Why do you post powerpoint bullets on 4chan?

>>58931171
>'cus he called him a mindless consumer bruh
So you DO admit that you got triggered, then?

It's okay anon, first step is admittance.

>Why do you post powerpoint bullets on 4chan?
Lists are "powerpoint bullets" now?

>>58931171
>"""him"""
You mean I called you a mindless consumer, right?

>Why do you post powerpoint bullets on 4chan?
I would say you're showing of your mindless consumerism right now.

>>58931192
Yes, I was triggered by his stubbornness. That's why I wasted an hour arguing with him.
>bullets
No, it just adds to the fact that you are taking this too seriously.

With ARM or MIPS64 you can give a small number of drivers their own address space without performance impact, because of the 8 bit Address Space Identifier.

This gives you 256 contexts between which you can switch for just as low a cost as a x86 OS user-mode<->kernel mode switch.

>>58931684
Cool, thanks for input :)

>>58927341
>>58927351
>>58927356
>>58927369
Tldr

>>58927490
I care about it, you retarded fuck.

>>58927827
What has Windows to do with anything? Why did you feel it was important to state that? Are you implying something inherent about windows users?

>>58929903
>Okay kid
It actually does sound plausible considering OP's level of knowledge. If it's OP you're having an autism battle with, of course.

>>58927341
>>58927351
>>58927356
>>58927369
This reminds me of the notorious b.i.g.

Hi, my name is Shay, and I'm from New Rochelle
And I just don't understand; why you so mad?
Like, what are you so mad about?

"The Mad Rapper"
Yo, yo, yo-yo, y'know, yo you wanna know why, yo first of all
You can't be askin' me no question youknowhatI'msayin?
Who the fuck is you?
(Ahh, excuse me, Mr. Rapper, Mr. Rapper) YouknowhatI'msayin?
You can't be askin' me no question (It's a family oriented show)
I'mma tell you why I'm mad, youknowhatI'msayin? I'mma tell you why
I'm mad. I'mma tell you why I'm mad
These niggas is makin' five hundred thousand dollar videos, youknowsayin? They drivin' around in hot cars, youknowsayin?
They got bitches, they got all that shit
(Sir, please, please, refrain from your foul language.)
YouknowhatI'ms--? I'm still livin with my Moms, youknowhatI'msayin?
That's my word. YouknowI'ms--? I'm makin' records, I ain't made no money
Yet I done made this is my fourth album yo, this my fourth album
I ain't made a dime yet
This nigga made one album, he makin' wild records
That "Ready to Die" shit, it was aight, it was aight
YouknowI'msayin, that shit was aight, it was cool
But my shit is J--more John Blaze than that!
I got John Blaze shit
And they not resp-ecognising, they not sayin, "I recognize"
And fuck is that, who is you to be askin' me questions, youknowhatI'msayin?
Who is you?

>>58934067
What is this autism?

>>58930064
wrong

>>58934361
You're wrong

>>58930932
Kernel design is actually worthy of discussion though. Usually /g/ just discusses logos

>>58927341
Our whole memory access paradigm needs to change. Requesting massive contiguous address space is the problem in the first place. Either we have the kernel keep a lookup table mapping smaller memory regions into a virtual address space for the actual driver/application to use as usual (which some argue is slow, but really isn't), or we need to simply change our practices to avoid the need for contiguous blocks of memory in the first place, in which case the kernel allocates multiple small ranges of physical address space (this requires safe programming which pajeets unfortunately are incapable of)

If we can pick one of these solutions and work out the kinks, we will have actual safe memory access. Until then, yeah, monolithic kernels are all we can do properly.

All this shitposting in a serious discussion.
When did we become rebbit?

>>58935002
4chan was always like this

>>58931684
>low a cost as a x86 OS user-mode<->kernel mode switch.
kernel context switches are extremely expensive, on the order of hundreds of nanoseconds, even up to microseconds.

File: 1486833619182.png (1MB, 1024x768px) Image search: [Google]

1MB, 1024x768px

>2017
>not running Redox OS

Is there some book that explains this for the Linux kernel ?
Or mimix ?
Or do i have to dig up the docs?

>>58935757
You can look up the docs. Especially the DMA api stuff. There are some books but they are for older versions.

>>58935356
Context switch takes literally nanoseconds. They are nowhere near microseconds.

>inb4 you repost that seven year old blogpost

>>58935383
MemeOS

>>58929995
>>58929903
>>58929813
>>58929715
Good ol' crabs in a bucket troll. Here are your (You)s.

Drivers should have the ability to run in user space

>>58937128
Why?

File: PsychedelicPurgatory.jpg (99KB, 1023x681px) Image search: [Google]

99KB, 1023x681px

>>58937143
Because devices are installed by the user. Because drivers are provided by the systems maintainer. Because op is a faggot.

I for one enjoyed the informative argument. Thanks OP.

>>58937333
>>58937187