Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Userland PCI drivers

wiki.netbsd.org

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Userland PCI drivers

#41

Post by TickleSteve »

dfox wrote: post #26
digi_owl wrote: post #18

Earlier quoted context omitted.

Most real life implementations of "microkernels" end up being hybrids. NT started out as a micro, but Microsoft have been moving things (the graphics subsystem in particular) in and out of kernel space in the hunt for the optimal tradeoff between stability and performance. Similarly i think the Mach kernel powering Apple's OSs are a "fat micro" where various things that should be in userspace, if one followed the mic…

Mac OS/XNU is in fact derivate of DEC's OSF/1 (later called Tru64 Unix). It has very weird hybrid design where essentially anything that would be in monolitic kernel runs as one big Mach process. Edit: it is somewhat ironic that Alpha's memory protection model is designed such way that the natural way to implement any OS would be to write your own microkernel as OS-specific PALcode (something between firmware and mic…

Sorry, but MacOS/OSX is a deriviative of NeXTStep, not Tru64.

There is no relationship to Tru64 except that HP did also support OpenSTEP at one point.

Re: Userland PCI drivers

#42

Post by wean_irdeh »

snvzz wrote: post #40
nickpsecurity wrote: post #17

Earlier quoted context omitted.

See Tannenbaum et al's paper on reliability/security mechanisms for a nice intro: http://cs.furman.edu/~chealy/cs75/important%20papers/secure%... The main benefit is reliability. Driver code is usually lower-quality than other code that runs in kernels. The hardware itself can act weird in a way that messed the drivers up. The infamous Blue Screen of Death on Windows was usually driver errors. Isolating them in their…

Somewhat related, Minix3 finally fixed the release blocker for 3.4.0. Expect a release soon, for the first time in years. And it's a major one.

Where I can hear more about this one? Link please

Re: Userland PCI drivers

#43

Post by lukeh »

TickleSteve wrote: post #41
dfox wrote: post #26

Earlier quoted context omitted.

Mac OS/XNU is in fact derivate of DEC's OSF/1 (later called Tru64 Unix). It has very weird hybrid design where essentially anything that would be in monolitic kernel runs as one big Mach process. Edit: it is somewhat ironic that Alpha's memory protection model is designed such way that the natural way to implement any OS would be to write your own microkernel as OS-specific PALcode (something between firmware and mic…

Sorry, but MacOS/OSX is a deriviative of NeXTStep, not Tru64. There is no relationship to Tru64 except that HP did also support OpenSTEP at one point.

From memory, they did swap out Mach from the version 2.5 used in NS/OS for version 3 from MkLinux (which was from OSF). This was at the time of the Rhapsody to OS X transition. My memory is hazy on the BSD kernel mode component history.

Re: Userland PCI drivers

#44

Post by snvzz »

wean_irdeh wrote: post #42
snvzz wrote: post #40

Earlier quoted context omitted.

Somewhat related, Minix3 finally fixed the release blocker for 3.4.0. Expect a release soon, for the first time in years. And it's a major one.

Where I can hear more about this one? Link please

Wikipedia article[1] has a list of changes, based on the rc. See the column at the right.

[1] https://en.wikipedia.org/wiki/MINIX_3#History

Re: Userland PCI drivers

#45

Post by wean_irdeh »

snvzz wrote: post #44
wean_irdeh wrote: post #42

Earlier quoted context omitted.

Where I can hear more about this one? Link please

Wikipedia article[1] has a list of changes, based on the rc. See the column at the right. [1] https://en.wikipedia.org/wiki/MINIX_3#History

Thanks! Where's the announcement about the fixed release blocker for 3.4.0?

Re: Userland PCI drivers

#46

Post by zaarn »

digi_owl wrote: post #18
Retr0spectrum wrote: post #14

I guess monolithic kernels have gone full-circle now.

Most real life implementations of "microkernels" end up being hybrids. NT started out as a micro, but Microsoft have been moving things (the graphics subsystem in particular) in and out of kernel space in the hunt for the optimal tradeoff between stability and performance. Similarly i think the Mach kernel powering Apple's OSs are a "fat micro" where various things that should be in userspace, if one followed the mic…

Personally I feel like hybrids are the best implementation variant. Simply sticking to either monolithic or micro just ends up with kernels that are impractical or consist of a thousand moving parts that can crash independently when one goes down.

There are also modular kernels, which are also neat when implemented right (Linux is basically a modular kernel at this point)

Re: Userland PCI drivers

#47

Post by snvzz »

wean_irdeh wrote: post #45
snvzz wrote: post #44

Earlier quoted context omitted.

Wikipedia article[1] has a list of changes, based on the rc. See the column at the right. [1] https://en.wikipedia.org/wiki/MINIX_3#History

Thanks! Where's the announcement about the fixed release blocker for 3.4.0?

See https://github.com/Stichting-MINIX-Research-Foundation/minix...

It "only" delayed Minix 3.4 for 2 years.

Re: Userland PCI drivers

#48

Post by tinus_hn »

kijiki wrote: post #30
FooBarWidget wrote: post #19

Earlier quoted context omitted.

From what I know, the reason they moved device setup to the kernel was to avoid flickering when the system switches from the boot screen to the login manager.

There were a bunch of reasons. One important one is that accessing the PCI config space via IO ports 0xCF8/0xCFC is racy with the kernel, since a read or write requires writing the BDF address to 0xCF8, and then reading/writing the data from 0xCFC. If the kernel tries to do this dance while the X server is doing it as well one of them is going to read or write the wrong address. Interestingly, this design required in…

Csrss.exe is the userspace part of the win32 personality. It controls all win32 processes, which on a Windows system is just about every process.

It is not very useful to limit its privileges.

Re: Userland PCI drivers

#49

Post by tinus_hn »

nickpsecurity wrote: post #17
mey wrote: post #12

Isn't the advantage of running hardware drivers in userspace to limit the attack surface of a driver being exploited?

See Tannenbaum et al's paper on reliability/security mechanisms for a nice intro: http://cs.furman.edu/~chealy/cs75/important%20papers/secure%... The main benefit is reliability. Driver code is usually lower-quality than other code that runs in kernels. The hardware itself can act weird in a way that messed the drivers up. The infamous Blue Screen of Death on Windows was usually driver errors. Isolating them in their…

It’s nice if drivers are not running in the kernel but even if your graphics drivers are running in userspace, if they crash you can’t use your pc anymore.

The main advantage is that you don’t have to deal with all the limitations of kernel mode programming.

Post reply on HN