Loading Documentation/driver-model/driver.txt +2 −2 Original line number Diff line number Diff line Loading @@ -207,8 +207,8 @@ Attributes ~~~~~~~~~~ struct driver_attribute { struct attribute attr; ssize_t (*show)(struct device_driver *, char * buf, size_t count, loff_t off); ssize_t (*store)(struct device_driver *, const char * buf, size_t count, loff_t off); ssize_t (*show)(struct device_driver *driver, char *buf); ssize_t (*store)(struct device_driver *, const char * buf, size_t count); }; Device drivers can export attributes via their sysfs directories. Loading Documentation/scheduler/sched-rt-group.txt +7 −6 Original line number Diff line number Diff line Loading @@ -73,7 +73,7 @@ The remaining CPU time will be used for user input and other tasks. Because realtime tasks have explicitly allocated the CPU time they need to perform their tasks, buffer underruns in the graphics or audio can be eliminated. NOTE: the above example is not fully implemented as of yet (2.6.25). We still NOTE: the above example is not fully implemented yet. We still lack an EDF scheduler to make non-uniform periods usable. Loading Loading @@ -140,14 +140,15 @@ The other option is: .o CONFIG_CGROUP_SCHED (aka "Basis for grouping tasks" = "Control groups") This uses the /cgroup virtual file system and "/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each control group instead. This uses the /cgroup virtual file system and "/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each control group instead. For more information on working with control groups, you should read Documentation/cgroups/cgroups.txt as well. Group settings are checked against the following limits in order to keep the configuration schedulable: Group settings are checked against the following limits in order to keep the configuration schedulable: \Sum_{i} runtime_{i} / global_period <= global_runtime / global_period Loading Loading @@ -189,7 +190,7 @@ Implementing SCHED_EDF might take a while to complete. Priority Inheritance is the biggest challenge as the current linux PI infrastructure is geared towards the limited static priority levels 0-99. With deadline scheduling you need to do deadline inheritance (since priority is inversely proportional to the deadline delta (deadline - now). deadline delta (deadline - now)). This means the whole PI machinery will have to be reworked - and that is one of the most complex pieces of code we have. Documentation/x86/00-INDEX +2 −0 Original line number Diff line number Diff line Loading @@ -2,3 +2,5 @@ - this file mtrr.txt - how to use x86 Memory Type Range Registers to increase performance exception-tables.txt - why and how Linux kernel uses exception tables on x86 Documentation/exception.txt→Documentation/x86/exception-tables.txt +101 −101 Original line number Diff line number Diff line Kernel level exception handling in Linux 2.1.8 Kernel level exception handling in Linux Commentary by Joerg Pommnitz <joerg@raleigh.ibm.com> When a process runs in kernel mode, it often has to access user Loading Loading @@ -29,8 +29,8 @@ page fault handler void do_page_fault(struct pt_regs *regs, unsigned long error_code) in arch/i386/mm/fault.c. The parameters on the stack are set up by the low level assembly glue in arch/i386/kernel/entry.S. The parameter in arch/x86/mm/fault.c. The parameters on the stack are set up by the low level assembly glue in arch/x86/kernel/entry_32.S. The parameter regs is a pointer to the saved registers on the stack, error_code contains a reason code for the exception. Loading @@ -52,12 +52,12 @@ Where does fixup point to? Since we jump to the contents of fixup, fixup obviously points to executable code. This code is hidden inside the user access macros. I have picked the get_user macro defined in include/asm/uaccess.h as an example. The definition is somewhat hard to follow, so let's peek at I have picked the get_user macro defined in arch/x86/include/asm/uaccess.h as an example. The definition is somewhat hard to follow, so let's peek at the code generated by the preprocessor and the compiler. I selected the get_user call in drivers/char/console.c for a detailed examination. the get_user call in drivers/char/sysrq.c for a detailed examination. The original code in console.c line 1405: The original code in sysrq.c line 587: get_user(c, buf); The preprocessor output (edited to become somewhat readable): Loading MAINTAINERS +7 −4 Original line number Diff line number Diff line Loading @@ -3287,11 +3287,11 @@ F: include/linux/ivtv* JFS FILESYSTEM P: Dave Kleikamp M: shaggy@austin.ibm.com M: shaggy@linux.vnet.ibm.com L: jfs-discussion@lists.sourceforge.net W: http://jfs.sourceforge.net/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6.git S: Supported S: Maintained F: Documentation/filesystems/jfs.txt F: fs/jfs/ Loading Loading @@ -4407,7 +4407,7 @@ W: http://www.nongnu.org/orinoco/ S: Maintained F: drivers/net/wireless/orinoco/ OSD LIBRARY OSD LIBRARY and FILESYSTEM P: Boaz Harrosh M: bharrosh@panasas.com P: Benny Halevy Loading @@ -4416,6 +4416,9 @@ L: osd-dev@open-osd.org W: http://open-osd.org T: git git://git.open-osd.org/open-osd.git S: Maintained F: drivers/scsi/osd/ F: drivers/include/scsi/osd_* F: fs/exofs/ P54 WIRELESS DRIVER P: Michael Wu Loading Loading @@ -5851,7 +5854,7 @@ UBI FILE SYSTEM (UBIFS) P: Artem Bityutskiy M: dedekind@infradead.org P: Adrian Hunter M: ext-adrian.hunter@nokia.com M: adrian.hunter@nokia.com L: linux-mtd@lists.infradead.org T: git git://git.infradead.org/ubifs-2.6.git W: http://www.linux-mtd.infradead.org/doc/ubifs.html Loading Loading
Documentation/driver-model/driver.txt +2 −2 Original line number Diff line number Diff line Loading @@ -207,8 +207,8 @@ Attributes ~~~~~~~~~~ struct driver_attribute { struct attribute attr; ssize_t (*show)(struct device_driver *, char * buf, size_t count, loff_t off); ssize_t (*store)(struct device_driver *, const char * buf, size_t count, loff_t off); ssize_t (*show)(struct device_driver *driver, char *buf); ssize_t (*store)(struct device_driver *, const char * buf, size_t count); }; Device drivers can export attributes via their sysfs directories. Loading
Documentation/scheduler/sched-rt-group.txt +7 −6 Original line number Diff line number Diff line Loading @@ -73,7 +73,7 @@ The remaining CPU time will be used for user input and other tasks. Because realtime tasks have explicitly allocated the CPU time they need to perform their tasks, buffer underruns in the graphics or audio can be eliminated. NOTE: the above example is not fully implemented as of yet (2.6.25). We still NOTE: the above example is not fully implemented yet. We still lack an EDF scheduler to make non-uniform periods usable. Loading Loading @@ -140,14 +140,15 @@ The other option is: .o CONFIG_CGROUP_SCHED (aka "Basis for grouping tasks" = "Control groups") This uses the /cgroup virtual file system and "/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each control group instead. This uses the /cgroup virtual file system and "/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each control group instead. For more information on working with control groups, you should read Documentation/cgroups/cgroups.txt as well. Group settings are checked against the following limits in order to keep the configuration schedulable: Group settings are checked against the following limits in order to keep the configuration schedulable: \Sum_{i} runtime_{i} / global_period <= global_runtime / global_period Loading Loading @@ -189,7 +190,7 @@ Implementing SCHED_EDF might take a while to complete. Priority Inheritance is the biggest challenge as the current linux PI infrastructure is geared towards the limited static priority levels 0-99. With deadline scheduling you need to do deadline inheritance (since priority is inversely proportional to the deadline delta (deadline - now). deadline delta (deadline - now)). This means the whole PI machinery will have to be reworked - and that is one of the most complex pieces of code we have.
Documentation/x86/00-INDEX +2 −0 Original line number Diff line number Diff line Loading @@ -2,3 +2,5 @@ - this file mtrr.txt - how to use x86 Memory Type Range Registers to increase performance exception-tables.txt - why and how Linux kernel uses exception tables on x86
Documentation/exception.txt→Documentation/x86/exception-tables.txt +101 −101 Original line number Diff line number Diff line Kernel level exception handling in Linux 2.1.8 Kernel level exception handling in Linux Commentary by Joerg Pommnitz <joerg@raleigh.ibm.com> When a process runs in kernel mode, it often has to access user Loading Loading @@ -29,8 +29,8 @@ page fault handler void do_page_fault(struct pt_regs *regs, unsigned long error_code) in arch/i386/mm/fault.c. The parameters on the stack are set up by the low level assembly glue in arch/i386/kernel/entry.S. The parameter in arch/x86/mm/fault.c. The parameters on the stack are set up by the low level assembly glue in arch/x86/kernel/entry_32.S. The parameter regs is a pointer to the saved registers on the stack, error_code contains a reason code for the exception. Loading @@ -52,12 +52,12 @@ Where does fixup point to? Since we jump to the contents of fixup, fixup obviously points to executable code. This code is hidden inside the user access macros. I have picked the get_user macro defined in include/asm/uaccess.h as an example. The definition is somewhat hard to follow, so let's peek at I have picked the get_user macro defined in arch/x86/include/asm/uaccess.h as an example. The definition is somewhat hard to follow, so let's peek at the code generated by the preprocessor and the compiler. I selected the get_user call in drivers/char/console.c for a detailed examination. the get_user call in drivers/char/sysrq.c for a detailed examination. The original code in console.c line 1405: The original code in sysrq.c line 587: get_user(c, buf); The preprocessor output (edited to become somewhat readable): Loading
MAINTAINERS +7 −4 Original line number Diff line number Diff line Loading @@ -3287,11 +3287,11 @@ F: include/linux/ivtv* JFS FILESYSTEM P: Dave Kleikamp M: shaggy@austin.ibm.com M: shaggy@linux.vnet.ibm.com L: jfs-discussion@lists.sourceforge.net W: http://jfs.sourceforge.net/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6.git S: Supported S: Maintained F: Documentation/filesystems/jfs.txt F: fs/jfs/ Loading Loading @@ -4407,7 +4407,7 @@ W: http://www.nongnu.org/orinoco/ S: Maintained F: drivers/net/wireless/orinoco/ OSD LIBRARY OSD LIBRARY and FILESYSTEM P: Boaz Harrosh M: bharrosh@panasas.com P: Benny Halevy Loading @@ -4416,6 +4416,9 @@ L: osd-dev@open-osd.org W: http://open-osd.org T: git git://git.open-osd.org/open-osd.git S: Maintained F: drivers/scsi/osd/ F: drivers/include/scsi/osd_* F: fs/exofs/ P54 WIRELESS DRIVER P: Michael Wu Loading Loading @@ -5851,7 +5854,7 @@ UBI FILE SYSTEM (UBIFS) P: Artem Bityutskiy M: dedekind@infradead.org P: Adrian Hunter M: ext-adrian.hunter@nokia.com M: adrian.hunter@nokia.com L: linux-mtd@lists.infradead.org T: git git://git.infradead.org/ubifs-2.6.git W: http://www.linux-mtd.infradead.org/doc/ubifs.html Loading