The Jury Is In: Monolithic OS Design Is Flawed [pdf] • Hacker News Board

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#121

Post by ysleepy » Wed, Aug 15, 2018, 9:22 PM UTC

pjmlp wrote: post #106

ysleepy wrote: post #97

Earlier quoted context omitted.

I don't see a microkernel architecture here. Requiring drivers to be loadable modules is just arriving in the 1990s of monolithic kernels. Also, only new devices with SoCs introduced for Android 9 are required to use kernel modules and kernels newer than 3.18. [1] This means most (updated) Android 8 devices in the field are not Project Treble and are running old-style module-less kernels and don't have A/B system par…

Because you just stopped at the kernel modules part and haven't spent time reading how HAL in Android actually works, starting at the HIDL link. There are two HALs in Android. The old HAL, previous to Treble, which was hardly used by OEMs. And the new HAL, which is enforced by Treble. On the new HAL, drivers are implemented as Android services using Android IPC via interfaces defined in HIDL, or by using the new shar…

I actually looked into the HAL/HIDL docs before posting and found no evidence that they are there to implement drivers in userspace.

As I understand it HALs and HIDL are used to provide a standardized way to implement new device features in a compatible way. So a vendor introduces a odor-sensor and can define an HIDL interface for the userspace to call the device driver provided in a kernel module.

I do not see a requirement to implement drivers in userspace, nor provisions for it, like interrupt handling, i2c/spi access or similar.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#122

Post by CGamesPlay » Wed, Aug 15, 2018, 9:24 PM UTC

enitihas wrote: post #77

Reminds me of the famous Torvalds Tanenbaum debate. https://groups.google.com/forum/m/#!topic/comp.os.minix/wlhw...

Ah, this was great!

> Linus "my first, and hopefully last flamefest" Torvalds

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#123

Post by namibj » Wed, Aug 15, 2018, 9:38 PM UTC

monocasa wrote: post #104

mrsteveman1 wrote: post #82

Earlier quoted context omitted.

Any recent iPhone/iPad, Apple Watch, the iMac Pro, and Macbook Pro touch bar, all contain Apple's "Secure Enclave", which runs the L4 microkernel: > The Secure Enclave runs an Apple-customized version of the L4 microkernel. This microkernel is signed by Apple, verified as part of the iOS secure boot chain, and updated through a personalized software update process. https://www.apple.com/business/docs/iOS_Security_Gui…

I wonder which L4 they use. L4 is more a family than a single kernel. The different variants are essentially totally different kernels from the same school of thought.

For that security I'd assume seL4, though I did not see anyone obviously apple on the devel mailing list...

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#124

Post by Sporktacular » Wed, Aug 15, 2018, 9:45 PM UTC

Some super low quality commentary here. Straight to the Monolithic/Microkernal tribalism, talk of parallel dimensions, as long as we ignore the content of the paper - which remains far more empirical and convincing than any rebuttal seen here.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#125

Post by GirlsCanCode » Wed, Aug 15, 2018, 9:46 PM UTC

That's why I use the most popular microkernel OS ever: Windows 10.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#126

Post by monocasa » Wed, Aug 15, 2018, 9:59 PM UTC

namibj wrote: post #123

monocasa wrote: post #104

Earlier quoted context omitted.

I wonder which L4 they use. L4 is more a family than a single kernel. The different variants are essentially totally different kernels from the same school of thought.

For that security I'd assume seL4, though I did not see anyone obviously apple on the devel mailing list...

Looking into it more, it looks like a heavily modified fork of L4Ka::Pistachio. That's pretty fun, I may have to go exploit hunting this weekend.

https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#127

Post by MisterTea » Wed, Aug 15, 2018, 10:14 PM UTC

pweissbrod wrote: post #8

I wonder if there exists a parallel dimension where linux is microkernel design and folks are pushing for monolothic citing the driver friendliness and performance

You mean a parallel universe where GNU/HURD was actually finished.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#128

Post by pjmlp » Wed, Aug 15, 2018, 10:21 PM UTC

ysleepy wrote: post #121

pjmlp wrote: post #106

Earlier quoted context omitted.

Because you just stopped at the kernel modules part and haven't spent time reading how HAL in Android actually works, starting at the HIDL link. There are two HALs in Android. The old HAL, previous to Treble, which was hardly used by OEMs. And the new HAL, which is enforced by Treble. On the new HAL, drivers are implemented as Android services using Android IPC via interfaces defined in HIDL, or by using the new shar…

I actually looked into the HAL/HIDL docs before posting and found no evidence that they are there to implement drivers in userspace. As I understand it HALs and HIDL are used to provide a standardized way to implement new device features in a compatible way. So a vendor introduces a odor-sensor and can define an HIDL interface for the userspace to call the device driver provided in a kernel module. I do not see a req…

HIDL is the basis of Android IPC between processes, known as Binder.

"Binderized HALs. HALs expressed in HAL interface definition language (HIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only.

Passthrough HALs. A HIDL-wrapped conventional or legacy HAL. These HALs wrap existing HALs and can serve the HAL in binderized and same-process (passthrough) modes. Devices upgrading to Android 8.0 can use passthrough HALs. "

https://source.android.com/devices/architecture/hal-types

Here are the user space driver APIs for i2c/spi access on Android Things.

https://developer.android.com/reference/com/google/android/t...

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#129

Post by pjmlp » Wed, Aug 15, 2018, 10:23 PM UTC

scintill76 wrote: post #116

pjmlp wrote: post #106

Earlier quoted context omitted.

Because you just stopped at the kernel modules part and haven't spent time reading how HAL in Android actually works, starting at the HIDL link. There are two HALs in Android. The old HAL, previous to Treble, which was hardly used by OEMs. And the new HAL, which is enforced by Treble. On the new HAL, drivers are implemented as Android services using Android IPC via interfaces defined in HIDL, or by using the new shar…

I'll admit to not being steeped in the terminology, so feel free to educate me.. but some quick Googling suggests nobody else has called Treble a "microkernel." There are hits about Fuchsia (a totally separate OS), and some Android forks on microkernels. I'm guessing that the Treble modules expose the traditional /dev and /sys interfaces like before, and these new HALs talk to devices through those, right? Is that no…

They use Android IPC, which is a kind of RPC between processes.

https://source.android.com/devices/architecture/hal-types

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#130

Post by pjmlp » Wed, Aug 15, 2018, 10:25 PM UTC

monocasa wrote: post #115

pjmlp wrote: post #113

Earlier quoted context omitted.

Given that the radeon driver doesn't provide the same feature set as fglrx used to provide, with the same stability, it is surely a driver issue.

... a brand new, mainline kernel will run fglrx just fine. It's user space (specifically the x srever) that decided to break fglrx. So how is that the fault of the kernel's unstable API again?

Graphics drivers run on the kernel.