## page was renamed from KernelProjects/common-kernel-read

= Common kernel file loader =

This page documents progress the original goal behind creating common kernel file loader routine on the kernel. For a while it was looked down upon to directly read files from Linux. Then for a while a few kernel mechanisms started creeping up which read files from the filesystem directly from the kernel which did this in a generic from by loading a file into a local kernel buffer. There used to be minor but important checks differences on each, Mimi Zohar looked at each one, took all the best practices from each of them, and generalized a solution. The new APIs available are then:

  * kernel_read_file()
  * kernel_read_file_from_path()
  * kernel_read_file_from_fd()

<<TableOfContents(4)>>

= Current file loader locations =

These are the currently known file loader solutions in place on the kernel. As you grep the kernel feel free to add more here to help document its use.

  * firmware_class: Used to be fw_read_file() (see [[http://kernelnewbies.org/KernelProjects/firmware-class-enhancements|this page for further enhancements on firmware_class]])
  * module: Used to be kernel_read()
  * kexec: Used to be copy_file_fd()
  * IMA: Used to be integrity_read_file()
  * sound: Used to be do_mod_firmware_load()

= Desired enhancements =

This lists a few set of enhancement considerations for the core kernel common file loaders.

== Userspace notification of path availability ==

Some device drivers (input, wireless) load require loading firmware on probe in order to be able to read any capability information from the device. History on firmware_class has shown though that races can exist on users of its APIs on init/probe due to uses of pivot_root() (as an example), we probably should devise a ''generic'' userspace hint helper that informs the kernel when a path is available. The core kernel file loader could use this to ensure that when it returns 'file not found' it actually means it. Due to things like pivot_root() a system administrator and userspace then can really only know when a given path really is ready for files to be read from it. The requirements for when a given path is to be ready should then be determined in userspace as well. Core file loader users might want to use async file loaders then to wait for such signals.

An example of one of the most recent attempts and discussions on this:

[[https://marc.info/?t=147286207700002&r=1&w=2|RFC: fs add userspace critical mounts event support]] - by Luis Rodriguez

== Races on suspend/resume ==

The firmware API implements its own firmware cache to avoid races with request to read files from userspace on suspend and resume. It relies on creating custom devices for each non-UMH request and devres to allocate the name of the firmware for the device, used later to create the new custom device. This could be a generic solution if devices are required or used on the other paths, however, it may also suffices to simply use freeze_super() as well to queue file system requests on a superblock as the filesystem is known to be not available. This later idea is also being considered for the use of the core kernel usermode helper as it also reads a file from the kernel to execute it, this idea is described on the [[https://kernelnewbies.org/KernelProjects/usermode-helper-enhancements|usermode helper enhancement page]].