Reboot Mode Driver Added To Linux 4.8 Kernel

[phoronix]

Phoronix: Reboot Mode Driver Added To Linux 4.8 Kernel

The power supply updates for Linux 4.8 adds a "reboot mode" driver to the kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Reboot-Mode-Driver-Linux-4.8

[milkylainen]

I don't see why this would be allowed into the kernel at all. Writing flash somewhere can be done from userland. The kernel has absolutely zero need to know that the user intends to write some special flash area for this specific device. It needs to map that area for the user to access.. But that is about it. I have done several similar modifications both to redboot, u-boot etc. Redundant transparent boot loading with multiple images etc. None of which ever involved any kernel knowledge or driver.

[doublez13]

I don't see why this would be allowed into the kernel at all. Writing flash somewhere can be done from userland. The kernel has absolutely zero need to know that the user intends to write some special flash area for this specific device. It needs to map that area for the user to access.. But that is about it. I have done several similar modifications both to redboot, u-boot etc. Redundant transparent boot loading with multiple images etc. None of which ever involved any kernel knowledge or driver.

Yeah I was thinkin the same thing. I'm sure there's somethin we don't know.

[AdamOne]

I love it, but what does it do???

[milkylainen]

Yeah I was thinkin the same thing. I'm sure there's somethin we don't know.

I'm pretty sure it's not. This type of handling is also severely limited. It is a "reboot to" function via kernel.
Most "reboot" or "reboot to" functions issued would want additional data in some systems. Some reboot to commands are issued by software during factory modes etc.
I see absolutely zero use of this function in the kernel. It's better for userspace to write whatever structures and data it chooses fit.
Then bootloaders or factory modes can act upon that data on reboot. It does not need kernel knowledge or involvement.

But then again. The Linux kernel has become a sorry state of bloated driver hell that all exist in kernelspace. A bucketload of kernel drivers could easily be done from userspace with only relevant interfaces to the kernel with little or no significant performance loss.

[caligula]

But then again. The Linux kernel has become a sorry state of bloated driver hell that all exist in kernelspace. A bucketload of kernel drivers could easily be done from userspace with only relevant interfaces to the kernel with little or no significant performance loss.

Especially stuff like the IoT/industrial drivers. I'm really confused why they had to include drivers to pressure / temperature sensors etc. in the kernel. Many embedded boards implement the whole I2C stack in software, in userspace. They're hardly performance critical. Reading a value could take hundreds of milliseconds. I mean, if filesystems can be implemented in userspace, why not slow sensors? The bus is like 0.1 - 5.0 Mbps. Typically less than 1-2 Mbps is needed for a read.

[Philip]

I don't see why this would be allowed into the kernel at all. Writing flash somewhere can be done from userland.

It's often not stored in flash - as the article quote says, it's "some place like special register or ram", which will persist over a soft reboot (though obviously won't persist after a power-off) and can be picked up by the bootloader.

It also needs to be settable by non-root processes (e.g. adb on an unrooted Android device), so it needs some appropriately secured kernel interface to access that register/RAM. And rather than requiring vendor-specific userspace code to set it differently on every platform, it makes sense to have some standard API. (And actually I think the standard API already exists, and is just the reboot syscall - it sounds like this patch is probably just making the argument passed into that syscall be available to the bootloader.)

Providing a consistent interface to varied hardware is exactly the kernel's job. And it's particularly useful if you want real Linux to ever run well on a mobile SoC, rather than this kind of functionality being stuck in a hundred different obsolete device-specific forks of the kernel or a hundred different undocumented closed-source device-specific Android libraries.

[Jumbotron]

It's often not stored in flash - as the article quote says, it's "some place like special register or ram", which will persist over a soft reboot (though obviously won't persist after a power-off) and can be picked up by the bootloader.

It also needs to be settable by non-root processes (e.g. adb on an unrooted Android device), so it needs some appropriately secured kernel interface to access that register/RAM. And rather than requiring vendor-specific userspace code to set it differently on every platform, it makes sense to have some standard API. (And actually I think the standard API already exists, and is just the reboot syscall - it sounds like this patch is probably just making the argument passed into that syscall be available to the bootloader.)

Providing a consistent interface to varied hardware is exactly the kernel's job. And it's particularly useful if you want real Linux to ever run well on a mobile SoC, rather than this kind of functionality being stuck in a hundred different obsolete device-specific forks of the kernel or a hundred different undocumented closed-source device-specific Android libraries.

Thanks for that. Makes more sense now.

[Azrael5]

to pass directly to the hardware is the best solution.

[milkylainen]

Especially stuff like the IoT/industrial drivers. I'm really confused why they had to include drivers to pressure / temperature sensors etc. in the kernel. Many embedded boards implement the whole I2C stack in software, in userspace. They're hardly performance critical. Reading a value could take hundreds of milliseconds. I mean, if filesystems can be implemented in userspace, why not slow sensors? The bus is like 0.1 - 5.0 Mbps. Typically less than 1-2 Mbps is needed for a read.

Exactly. I think the reason has become more like. "If it can get included in the kernel bloat, then it can be maintained. Then I don't have to do it anymore."