Loading CREDITS +8 −0 Original line number Diff line number Diff line Loading @@ -3364,6 +3364,14 @@ S: Braunschweiger Strasse 79 S: 31134 Hildesheim S: Germany N: Martin Schwidefsky D: Martin was the most significant contributor to the initial s390 D: port of the Linux Kernel and later the maintainer of the s390 D: architecture backend for almost two decades. D: He passed away in 2019, and will be greatly missed. S: Germany W: https://lwn.net/Articles/789028/ N: Marcel Selhorst E: tpmdd@selhorst.net D: TPM driver Loading Documentation/admin-guide/cgroup-v2.rst +9 −0 Original line number Diff line number Diff line Loading @@ -177,6 +177,15 @@ cgroup v2 currently supports the following mount options. ignored on non-init namespace mounts. Please refer to the Delegation section for details. memory_localevents Only populate memory.events with data for the current cgroup, and not any subtrees. This is legacy behaviour, the default behaviour without this option is to include subtree counts. This option is system wide and can only be set on mount or modified through remount from the init namespace. The mount option is ignored on non-init namespace mounts. Organizing Processes and Threads -------------------------------- Loading Documentation/filesystems/overlayfs.txt +14 −2 Original line number Diff line number Diff line Loading @@ -336,8 +336,20 @@ the copied layers will fail the verification of the lower root file handle. Non-standard behavior --------------------- Overlayfs can now act as a POSIX compliant filesystem with the following features turned on: Current version of overlayfs can act as a mostly POSIX compliant filesystem. This is the list of cases that overlayfs doesn't currently handle: a) POSIX mandates updating st_atime for reads. This is currently not done in the case when the file resides on a lower layer. b) If a file residing on a lower layer is opened for read-only and then memory mapped with MAP_SHARED, then subsequent changes to the file are not reflected in the memory mapping. The following options allow overlayfs to act more like a standards compliant filesystem: 1) "redirect_dir" Loading Documentation/usb/rio.txt +13 −53 Original line number Diff line number Diff line Loading @@ -76,70 +76,30 @@ Additional Information and userspace tools Requirements ============ A host with a USB port. Ideally, either a UHCI (Intel) or OHCI (Compaq and others) hardware port should work. A host with a USB port running a Linux kernel with RIO 500 support enabled. A Linux development kernel (2.3.x) with USB support enabled or a backported version to linux-2.2.x. See http://www.linux-usb.org for more information on accomplishing this. The driver is a module called rio500, which should be automatically loaded as you plug in your device. If that fails you can manually load it with A Linux kernel with RIO 500 support enabled. 'lspci' which is only needed to determine the type of USB hardware available in your machine. Configuration Using `lspci -v`, determine the type of USB hardware available. If you see something like:: USB Controller: ...... Flags: ..... I/O ports at .... Then you have a UHCI based controller. If you see something like:: USB Controller: ..... Flags: .... Memory at ..... Then you have a OHCI based controller. Using `make menuconfig` or your preferred method for configuring the kernel, select 'Support for USB', 'OHCI/UHCI' depending on your hardware (determined from the steps above), 'USB Diamond Rio500 support', and 'Preliminary USB device filesystem'. Compile and install the modules (you may need to execute `depmod -a` to update the module dependencies). modprobe rio500 Add a device for the USB rio500:: Udev should automatically create a device node as soon as plug in your device. If that fails, you can manually add a device for the USB rio500:: mknod /dev/usb/rio500 c 180 64 Set appropriate permissions for /dev/usb/rio500 (don't forget about group and world permissions). Both read and write permissions are In that case, set appropriate permissions for /dev/usb/rio500 (don't forget about group and world permissions). Both read and write permissions are required for proper operation. Load the appropriate modules (if compiled as modules): OHCI:: modprobe usbcore modprobe usb-ohci modprobe rio500 UHCI:: modprobe usbcore modprobe usb-uhci (or uhci) modprobe rio500 That's it. The Rio500 Utils at: http://rio500.sourceforge.net should be able to access the rio500. Limits ====== You can use only a single rio500 device at a time with your computer. Bugs ==== Loading Documentation/vm/hmm.rst +5 −3 Original line number Diff line number Diff line Loading @@ -288,15 +288,17 @@ For instance if the device flags for device entries are: WRITE (1 << 62) Now let say that device driver wants to fault with at least read a range then it does set: range->default_flags = (1 << 63) it does set:: range->default_flags = (1 << 63); range->pfn_flags_mask = 0; and calls hmm_range_fault() as described above. This will fill fault all page in the range with at least read permission. Now let say driver wants to do the same except for one page in the range for which its want to have write. Now driver set: which its want to have write. Now driver set:: range->default_flags = (1 << 63); range->pfn_flags_mask = (1 << 62); range->pfns[index_of_write] = (1 << 62); Loading Loading
CREDITS +8 −0 Original line number Diff line number Diff line Loading @@ -3364,6 +3364,14 @@ S: Braunschweiger Strasse 79 S: 31134 Hildesheim S: Germany N: Martin Schwidefsky D: Martin was the most significant contributor to the initial s390 D: port of the Linux Kernel and later the maintainer of the s390 D: architecture backend for almost two decades. D: He passed away in 2019, and will be greatly missed. S: Germany W: https://lwn.net/Articles/789028/ N: Marcel Selhorst E: tpmdd@selhorst.net D: TPM driver Loading
Documentation/admin-guide/cgroup-v2.rst +9 −0 Original line number Diff line number Diff line Loading @@ -177,6 +177,15 @@ cgroup v2 currently supports the following mount options. ignored on non-init namespace mounts. Please refer to the Delegation section for details. memory_localevents Only populate memory.events with data for the current cgroup, and not any subtrees. This is legacy behaviour, the default behaviour without this option is to include subtree counts. This option is system wide and can only be set on mount or modified through remount from the init namespace. The mount option is ignored on non-init namespace mounts. Organizing Processes and Threads -------------------------------- Loading
Documentation/filesystems/overlayfs.txt +14 −2 Original line number Diff line number Diff line Loading @@ -336,8 +336,20 @@ the copied layers will fail the verification of the lower root file handle. Non-standard behavior --------------------- Overlayfs can now act as a POSIX compliant filesystem with the following features turned on: Current version of overlayfs can act as a mostly POSIX compliant filesystem. This is the list of cases that overlayfs doesn't currently handle: a) POSIX mandates updating st_atime for reads. This is currently not done in the case when the file resides on a lower layer. b) If a file residing on a lower layer is opened for read-only and then memory mapped with MAP_SHARED, then subsequent changes to the file are not reflected in the memory mapping. The following options allow overlayfs to act more like a standards compliant filesystem: 1) "redirect_dir" Loading
Documentation/usb/rio.txt +13 −53 Original line number Diff line number Diff line Loading @@ -76,70 +76,30 @@ Additional Information and userspace tools Requirements ============ A host with a USB port. Ideally, either a UHCI (Intel) or OHCI (Compaq and others) hardware port should work. A host with a USB port running a Linux kernel with RIO 500 support enabled. A Linux development kernel (2.3.x) with USB support enabled or a backported version to linux-2.2.x. See http://www.linux-usb.org for more information on accomplishing this. The driver is a module called rio500, which should be automatically loaded as you plug in your device. If that fails you can manually load it with A Linux kernel with RIO 500 support enabled. 'lspci' which is only needed to determine the type of USB hardware available in your machine. Configuration Using `lspci -v`, determine the type of USB hardware available. If you see something like:: USB Controller: ...... Flags: ..... I/O ports at .... Then you have a UHCI based controller. If you see something like:: USB Controller: ..... Flags: .... Memory at ..... Then you have a OHCI based controller. Using `make menuconfig` or your preferred method for configuring the kernel, select 'Support for USB', 'OHCI/UHCI' depending on your hardware (determined from the steps above), 'USB Diamond Rio500 support', and 'Preliminary USB device filesystem'. Compile and install the modules (you may need to execute `depmod -a` to update the module dependencies). modprobe rio500 Add a device for the USB rio500:: Udev should automatically create a device node as soon as plug in your device. If that fails, you can manually add a device for the USB rio500:: mknod /dev/usb/rio500 c 180 64 Set appropriate permissions for /dev/usb/rio500 (don't forget about group and world permissions). Both read and write permissions are In that case, set appropriate permissions for /dev/usb/rio500 (don't forget about group and world permissions). Both read and write permissions are required for proper operation. Load the appropriate modules (if compiled as modules): OHCI:: modprobe usbcore modprobe usb-ohci modprobe rio500 UHCI:: modprobe usbcore modprobe usb-uhci (or uhci) modprobe rio500 That's it. The Rio500 Utils at: http://rio500.sourceforge.net should be able to access the rio500. Limits ====== You can use only a single rio500 device at a time with your computer. Bugs ==== Loading
Documentation/vm/hmm.rst +5 −3 Original line number Diff line number Diff line Loading @@ -288,15 +288,17 @@ For instance if the device flags for device entries are: WRITE (1 << 62) Now let say that device driver wants to fault with at least read a range then it does set: range->default_flags = (1 << 63) it does set:: range->default_flags = (1 << 63); range->pfn_flags_mask = 0; and calls hmm_range_fault() as described above. This will fill fault all page in the range with at least read permission. Now let say driver wants to do the same except for one page in the range for which its want to have write. Now driver set: which its want to have write. Now driver set:: range->default_flags = (1 << 63); range->pfn_flags_mask = (1 << 62); range->pfns[index_of_write] = (1 << 62); Loading