mirror of
https://github.com/torvalds/linux.git
synced 2024-11-25 21:51:40 +00:00
There is a nice new document from Neil on how pathname lookups work and
some new CAN driver documentation. Beyond that, we have kernel-doc fixes, a bit more work to support reproducible builds, and the usual collection of small fixes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJWO6HiAAoJEI3ONVYwIuV6ihwQAK0KC72h0706bdwDJ1p1/aJU QLuPeiKYWgGAXq2zgOyw3Povj4bkMwkiq1IGHLyK0Id4tg3ngxOXjimk4YKrqarI BD5HdpOm7IyQEe66ZU9b1RFDVst+bg3yp6ZIZsH5vQxl/KnyJ6AyaaDk8TPYId8S 1+CykJzxyi7GyT/jlLpHbKtBKrraoVke+cNPMAvOf0NjSyO7Ix5B+qH50sttG6Eu 9qcQ8hlKXOdZRTiGW6P+jeZNA+e5+CRpnG9VHBquHy4lI85kQThhWq41UMH690PP eRbLipeUybb0FwW2KwuMjGKEMDkMvrGJh0TzSXX9lGHd+5/41v7zcyKh8vJcpLjh bNQ2WOAKUBd2d15EP1MNoKXDLGJXusJczLwOjigWiSCQvgouAWwMrpWEw+Obv8Yl rdoH1oQqDFfDnk6mnKrSaqLWGNuLxDtkEl/1P0jsGSK6lM3FDkOgTuNPYXTJJgxN rXuGmPhyUlS2srERUeQJw2rISN0WRBvcKJGkMX6IpvrXHkItbelqK+yY1DeKPmcm qgbIx9ZWNqtltFpG22VVByqAVwucO5Nu8cAIQ2ysJsTnKOvQCQmhu5UKTjBCkEJM VpeMm32BfNiJFLuLTQGWBZ8bkRl2shQyXhOaR3uyqG4T+rpPD3qJi6dtFRpsAzOB q1nZuJCpOaxJFzjSKvpJ =emZ7 -----END PGP SIGNATURE----- Merge tag 'docs-for-linus' of git://git.lwn.net/linux Pull documentation update from Jon Corbet: "There is a nice new document from Neil on how pathname lookups work and some new CAN driver documentation. Beyond that, we have kernel-doc fixes, a bit more work to support reproducible builds, and the usual collection of small fixes" * tag 'docs-for-linus' of git://git.lwn.net/linux: (34 commits) Documentation: add new description of path-name lookup. Documentation/vm/slub.txt: document slabinfo-gnuplot.sh Doc: ABI/stable: Fix typo in ABI/stable doc: Clarify that nmi_watchdog param is for hardlockups Typo correction for description in gpio document. DocBook: Fix kernel-doc to be case-insensitive for private: kernel-docs.txt: update kernelnewbies reference Doc:kvm: Fix typo in Doc/virtual/kvm Documentation/Changes: Add bc in "Current Minimal Requirements" section Documentation/email-clients.txt: remove trailing whitespace DocBook: Use a fixed encoding for output MAINTAINERS: The docs tree has moved Docs/kernel-parameters: Add earlycon devicetree usage SubmittingPatches: make Subject examples match the de facto standard Documentation: gpio: mention that <function>-gpio has been deprecated Documentation: cgroups: just fix a few typos Documentation: Update kselftest.txt Documentation: DMA API: Be more explicit that nents is always the same Documentation: Update the default value of crashkernel low zram: update documentation ...
This commit is contained in:
commit
5ebe0ee802
@ -116,7 +116,7 @@ Description: The "pubek" property will return the TPM's public endorsement
|
||||
owner's authorization. Since the TPM driver doesn't store any
|
||||
secrets, it can't authorize its own request for the pubek,
|
||||
making it unaccessible. The public endorsement key is gener-
|
||||
ated at TPM menufacture time and exists for the life of the
|
||||
ated at TPM manufacture time and exists for the life of the
|
||||
chip.
|
||||
|
||||
Example output:
|
||||
@ -163,7 +163,7 @@ Date: April 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
Description: The "temp_deactivated" property returns a '1' if the chip has
|
||||
been temporarily dectivated, usually until the next power
|
||||
been temporarily deactivated, usually until the next power
|
||||
cycle. Whether a warm boot (reboot) will clear a TPM chip
|
||||
from a temp_deactivated state is platform specific.
|
||||
|
||||
|
@ -57,4 +57,4 @@ Description:
|
||||
Shortly after acknowledging it, the log
|
||||
entry will be removed from sysfs.
|
||||
Reading this file will list the supported
|
||||
operations (curently just acknowledge).
|
||||
operations (currently just acknowledge).
|
||||
|
@ -44,6 +44,7 @@ o grub 0.93 # grub --version || grub-insta
|
||||
o mcelog 0.6 # mcelog --version
|
||||
o iptables 1.4.2 # iptables -V
|
||||
o openssl & libcrypto 1.0.0 # openssl version
|
||||
o bc 1.06.95 # bc --version
|
||||
|
||||
|
||||
Kernel compilation
|
||||
|
@ -681,6 +681,11 @@ or:
|
||||
|
||||
as appropriate.
|
||||
|
||||
PLEASE NOTE: The 'nents' argument to dma_sync_sg_for_cpu() and
|
||||
dma_sync_sg_for_device() must be the same passed to
|
||||
dma_map_sg(). It is _NOT_ the count returned by
|
||||
dma_map_sg().
|
||||
|
||||
After the last DMA transfer call one of the DMA unmap routines
|
||||
dma_unmap_{single,sg}(). If you don't touch the data from the first
|
||||
dma_map_*() call till dma_unmap_*(), then you don't have to call the
|
||||
|
@ -340,7 +340,7 @@ accessed sg->address and sg->length as shown above.
|
||||
|
||||
void
|
||||
dma_unmap_sg(struct device *dev, struct scatterlist *sg,
|
||||
int nhwentries, enum dma_data_direction direction)
|
||||
int nents, enum dma_data_direction direction)
|
||||
|
||||
Unmap the previously mapped scatter/gather list. All the parameters
|
||||
must be the same as those and passed in to the scatter/gather mapping
|
||||
@ -356,10 +356,10 @@ void
|
||||
dma_sync_single_for_device(struct device *dev, dma_addr_t dma_handle, size_t size,
|
||||
enum dma_data_direction direction)
|
||||
void
|
||||
dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nelems,
|
||||
dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nents,
|
||||
enum dma_data_direction direction)
|
||||
void
|
||||
dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems,
|
||||
dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nents,
|
||||
enum dma_data_direction direction)
|
||||
|
||||
Synchronise a single contiguous or scatter/gather mapping for the CPU
|
||||
|
2
Documentation/DocBook/.gitignore
vendored
2
Documentation/DocBook/.gitignore
vendored
@ -11,5 +11,7 @@
|
||||
*.png
|
||||
*.gif
|
||||
*.svg
|
||||
*.proc
|
||||
*.db
|
||||
media-indices.tmpl
|
||||
media-entities.tmpl
|
||||
|
@ -69,6 +69,12 @@ installmandocs: mandocs
|
||||
KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
|
||||
KERNELDOC = $(srctree)/scripts/kernel-doc
|
||||
DOCPROC = $(objtree)/scripts/docproc
|
||||
CHECK_LC_CTYPE = $(objtree)/scripts/check-lc_ctype
|
||||
|
||||
# Use a fixed encoding - UTF-8 if the C library has support built-in
|
||||
# or ASCII if not
|
||||
LC_CTYPE := $(call try-run, LC_CTYPE=C.UTF-8 $(CHECK_LC_CTYPE),C.UTF-8,C)
|
||||
export LC_CTYPE
|
||||
|
||||
XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
|
||||
XMLTOFLAGS += --skip-validation
|
||||
|
@ -659,8 +659,8 @@ succinct and descriptive, but that is what a well-written summary
|
||||
should do.
|
||||
|
||||
The "summary phrase" may be prefixed by tags enclosed in square
|
||||
brackets: "Subject: [PATCH tag] <summary phrase>". The tags are not
|
||||
considered part of the summary phrase, but describe how the patch
|
||||
brackets: "Subject: [PATCH <tag>...] <summary phrase>". The tags are
|
||||
not considered part of the summary phrase, but describe how the patch
|
||||
should be treated. Common tags might include a version descriptor if
|
||||
the multiple versions of the patch have been sent out in response to
|
||||
comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
|
||||
@ -672,8 +672,8 @@ the patch series.
|
||||
|
||||
A couple of example Subjects:
|
||||
|
||||
Subject: [patch 2/5] ext2: improve scalability of bitmap searching
|
||||
Subject: [PATCHv2 001/207] x86: fix eflags tracking
|
||||
Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
|
||||
Subject: [PATCH v2 01/27] x86: fix eflags tracking
|
||||
|
||||
The "from" line must be the very first line in the message body,
|
||||
and has the form:
|
||||
|
@ -14,8 +14,43 @@ Statistics for individual zram devices are exported through sysfs nodes at
|
||||
|
||||
* Usage
|
||||
|
||||
There are several ways to configure and manage zram device(-s):
|
||||
a) using zram and zram_control sysfs attributes
|
||||
b) using zramctl utility, provided by util-linux (util-linux@vger.kernel.org).
|
||||
|
||||
In this document we will describe only 'manual' zram configuration steps,
|
||||
IOW, zram and zram_control sysfs attributes.
|
||||
|
||||
In order to get a better idea about zramctl please consult util-linux
|
||||
documentation, zramctl man-page or `zramctl --help'. Please be informed
|
||||
that zram maintainers do not develop/maintain util-linux or zramctl, should
|
||||
you have any questions please contact util-linux@vger.kernel.org
|
||||
|
||||
Following shows a typical sequence of steps for using zram.
|
||||
|
||||
WARNING
|
||||
=======
|
||||
For the sake of simplicity we skip error checking parts in most of the
|
||||
examples below. However, it is your sole responsibility to handle errors.
|
||||
|
||||
zram sysfs attributes always return negative values in case of errors.
|
||||
The list of possible return codes:
|
||||
-EBUSY -- an attempt to modify an attribute that cannot be changed once
|
||||
the device has been initialised. Please reset device first;
|
||||
-ENOMEM -- zram was not able to allocate enough memory to fulfil your
|
||||
needs;
|
||||
-EINVAL -- invalid input has been provided.
|
||||
|
||||
If you use 'echo', the returned value that is changed by 'echo' utility,
|
||||
and, in general case, something like:
|
||||
|
||||
echo 3 > /sys/block/zram0/max_comp_streams
|
||||
if [ $? -ne 0 ];
|
||||
handle_error
|
||||
fi
|
||||
|
||||
should suffice.
|
||||
|
||||
1) Load Module:
|
||||
modprobe zram num_devices=4
|
||||
This creates 4 devices: /dev/zram{0,1,2,3}
|
||||
@ -47,7 +82,7 @@ max_comp_streams adjustment.
|
||||
|
||||
3) Select compression algorithm
|
||||
Using comp_algorithm device attribute one can see available and
|
||||
currently selected (shown in square brackets) compression algortithms,
|
||||
currently selected (shown in square brackets) compression algorithms,
|
||||
change selected compression algorithm (once the device is initialised
|
||||
there is no way to change compression algorithm).
|
||||
|
||||
@ -119,7 +154,7 @@ execute
|
||||
8) Stats:
|
||||
Per-device statistics are exported as various nodes under /sys/block/zram<id>/
|
||||
|
||||
A brief description of exported device attritbutes. For more details please
|
||||
A brief description of exported device attributes. For more details please
|
||||
read Documentation/ABI/testing/sysfs-block-zram.
|
||||
|
||||
Name access description
|
||||
@ -140,8 +175,9 @@ zero_pages RO the number of zero filled pages written to this disk
|
||||
orig_data_size RO uncompressed size of data stored in this disk
|
||||
compr_data_size RO compressed size of data stored in this disk
|
||||
mem_used_total RO the amount of memory allocated for this disk
|
||||
mem_used_max RW the maximum amount memory zram have consumed to
|
||||
store compressed data
|
||||
mem_used_max RW the maximum amount of memory zram have consumed to
|
||||
store the data (to reset this counter to the actual
|
||||
current value, write 1 to this attribute)
|
||||
mem_limit RW the maximum amount of memory ZRAM can use to store
|
||||
the compressed data
|
||||
pages_compacted RO the number of pages freed during compaction
|
||||
|
@ -59,7 +59,7 @@ cgroups. Here is what you can do.
|
||||
- At macro level, first dd should finish first. To get more precise data, keep
|
||||
on looking at (with the help of script), at blkio.disk_time and
|
||||
blkio.disk_sectors files of both test1 and test2 groups. This will tell how
|
||||
much disk time (in milli seconds), each group got and how many secotors each
|
||||
much disk time (in milliseconds), each group got and how many sectors each
|
||||
group dispatched to the disk. We provide fairness in terms of disk time, so
|
||||
ideally io.disk_time of cgroups should be in proportion to the weight.
|
||||
|
||||
|
@ -50,7 +50,7 @@ being frozen. This allows the bash example above and gdb to run as
|
||||
expected.
|
||||
|
||||
The cgroup freezer is hierarchical. Freezing a cgroup freezes all
|
||||
tasks beloning to the cgroup and all its descendant cgroups. Each
|
||||
tasks belonging to the cgroup and all its descendant cgroups. Each
|
||||
cgroup has its own state (self-state) and the state inherited from the
|
||||
parent (parent-state). Iff both states are THAWED, the cgroup is
|
||||
THAWED.
|
||||
|
@ -494,7 +494,7 @@ may be specified in any order and not all pairs have to be specified.
|
||||
${R|W}BPS are read/write bytes per second and ${R|W}IOPS are
|
||||
read/write IOs per second. "max" indicates no limit. Writing
|
||||
to the file follows the same format but the individual
|
||||
settings may be ommitted or specified in any order.
|
||||
settings may be omitted or specified in any order.
|
||||
|
||||
This file is available only on non-root cgroups.
|
||||
|
||||
|
@ -220,7 +220,7 @@ to coerce it into behaving.
|
||||
Compose dialog.
|
||||
|
||||
Please note that "external editor" requires that your editor must not
|
||||
fork, or in other words, the editor must not return before closing.
|
||||
fork, or in other words, the editor must not return before closing.
|
||||
You may have to pass additional flags or change the settings of your
|
||||
editor. Most notably if you are using gvim then you must pass the -f
|
||||
option to gvim by putting "/usr/bin/gvim -f" (if the binary is in
|
||||
|
1297
Documentation/filesystems/path-lookup.md
Normal file
1297
Documentation/filesystems/path-lookup.md
Normal file
File diff suppressed because it is too large
Load Diff
@ -379,4 +379,4 @@ Papers and other documentation on dcache locking
|
||||
|
||||
2. http://lse.sourceforge.net/locking/dcache/dcache.html
|
||||
|
||||
|
||||
3. path-lookup.md in this directory.
|
||||
|
@ -17,13 +17,13 @@ the sysfs directory entries we ensure that we don't have conflicts
|
||||
in the directories and applications only see a limited set of
|
||||
the network devices.
|
||||
|
||||
Each sysfs directory entry may be tagged with zero or one
|
||||
namespaces. A sysfs_dirent is augmented with a void *s_ns. If a
|
||||
directory entry is tagged, then sysfs_dirent->s_flags will have a
|
||||
flag between KOBJ_NS_TYPE_NONE and KOBJ_NS_TYPES, and s_ns will
|
||||
point to the namespace to which it belongs.
|
||||
Each sysfs directory entry may be tagged with a namespace via the
|
||||
void *ns member of its kernfs_node. If a directory entry is tagged,
|
||||
then kernfs_node->flags will have a flag between KOBJ_NS_TYPE_NONE
|
||||
and KOBJ_NS_TYPES, and ns will point to the namespace to which it
|
||||
belongs.
|
||||
|
||||
Each sysfs superblock's sysfs_super_info contains an array void
|
||||
Each sysfs superblock's kernfs_super_info contains an array void
|
||||
*ns[KOBJ_NS_TYPES]. When a task in a tagging namespace
|
||||
kobj_nstype first mounts sysfs, a new superblock is created. It
|
||||
will be differentiated from other sysfs mounts by having its
|
||||
@ -31,7 +31,7 @@ s_fs_info->ns[kobj_nstype] set to the new namespace. Note that
|
||||
through bind mounting and mounts propagation, a task can easily view
|
||||
the contents of other namespaces' sysfs mounts. Therefore, when a
|
||||
namespace exits, it will call kobj_ns_exit() to invalidate any
|
||||
sysfs_dirent->s_ns pointers pointing to it.
|
||||
kernfs_node->ns pointers pointing to it.
|
||||
|
||||
Users of this interface:
|
||||
- define a type in the kobj_ns_type enumeration.
|
||||
|
@ -40,7 +40,7 @@ ancestors of object hierarchies; i.e. the subsystems the objects
|
||||
belong to.
|
||||
|
||||
Sysfs internally stores a pointer to the kobject that implements a
|
||||
directory in the sysfs_dirent object associated with the directory. In
|
||||
directory in the kernfs_node object associated with the directory. In
|
||||
the past this kobject pointer has been used by sysfs to do reference
|
||||
counting directly on the kobject whenever the file is opened or closed.
|
||||
With the current sysfs implementation the kobject reference count is
|
||||
@ -191,9 +191,10 @@ implementations:
|
||||
be called again, rearmed, to fill the buffer.
|
||||
|
||||
- On write(2), sysfs expects the entire buffer to be passed during the
|
||||
first write. Sysfs then passes the entire buffer to the store()
|
||||
method.
|
||||
|
||||
first write. Sysfs then passes the entire buffer to the store() method.
|
||||
A terminating null is added after the data on stores. This makes
|
||||
functions like sysfs_streq() safe to use.
|
||||
|
||||
When writing sysfs files, userspace processes should first read the
|
||||
entire file, modify the values it wishes to change, then write the
|
||||
entire buffer back.
|
||||
|
@ -21,8 +21,8 @@ exact way to do it depends on the GPIO controller providing the GPIOs, see the
|
||||
device tree bindings for your controller.
|
||||
|
||||
GPIOs mappings are defined in the consumer device's node, in a property named
|
||||
either <function>-gpios or <function>-gpio, where <function> is the function
|
||||
the driver will request through gpiod_get(). For example:
|
||||
<function>-gpios, where <function> is the function the driver will request
|
||||
through gpiod_get(). For example:
|
||||
|
||||
foo_device {
|
||||
compatible = "acme,foo";
|
||||
@ -31,9 +31,13 @@ the driver will request through gpiod_get(). For example:
|
||||
<&gpio 16 GPIO_ACTIVE_HIGH>, /* green */
|
||||
<&gpio 17 GPIO_ACTIVE_HIGH>; /* blue */
|
||||
|
||||
power-gpio = <&gpio 1 GPIO_ACTIVE_LOW>;
|
||||
power-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
|
||||
};
|
||||
|
||||
Properties named <function>-gpio are also considered valid and old bindings use
|
||||
it but are only supported for compatibility reasons and should not be used for
|
||||
newer bindings since it has been deprecated.
|
||||
|
||||
This property will make GPIOs 15, 16 and 17 available to the driver under the
|
||||
"led" function, and GPIO 1 as the "power" GPIO:
|
||||
|
||||
|
@ -20,14 +20,14 @@ userspace GPIO can be used to determine system configuration data that
|
||||
standard kernels won't know about. And for some tasks, simple userspace
|
||||
GPIO drivers could be all that the system really needs.
|
||||
|
||||
DO NOT ABUSE SYFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS.
|
||||
DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS.
|
||||
PLEASE READ THE DOCUMENT NAMED "drivers-on-gpio.txt" IN THIS DOCUMENTATION
|
||||
DIRECTORY TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT.
|
||||
REALLY.
|
||||
|
||||
Paths in Sysfs
|
||||
--------------
|
||||
There are three kinds of entry in /sys/class/gpio:
|
||||
There are three kinds of entries in /sys/class/gpio:
|
||||
|
||||
- Control interfaces used to get userspace control over GPIOs;
|
||||
|
||||
@ -106,7 +106,7 @@ read-only attributes:
|
||||
|
||||
"label" ... provided for diagnostics (not always unique)
|
||||
|
||||
"ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)
|
||||
"ngpio" ... how many GPIOs this manages (N to N + ngpio - 1)
|
||||
|
||||
Board documentation should in most cases cover what GPIOs are used for
|
||||
what purposes. However, those numbers are not always stable; GPIOs on
|
||||
|
@ -696,18 +696,18 @@
|
||||
Memory related patches, HOWTOs, links, mm developers... Don't miss
|
||||
it if you are interested in memory management development!
|
||||
|
||||
* Name: "Kernel Newbies IRC Channel"
|
||||
* Name: "Kernel Newbies IRC Channel and Website"
|
||||
URL: http://www.kernelnewbies.org
|
||||
Keywords: IRC, newbies, channel, asking doubts.
|
||||
Description: #kernelnewbies on irc.openprojects.net. From the web
|
||||
page: "#kernelnewbies is an IRC network dedicated to the 'newbie'
|
||||
Description: #kernelnewbies on irc.oftc.net.
|
||||
#kernelnewbies is an IRC network dedicated to the 'newbie'
|
||||
kernel hacker. The audience mostly consists of people who are
|
||||
learning about the kernel, working on kernel projects or
|
||||
professional kernel hackers that want to help less seasoned kernel
|
||||
people. [...] #kernelnewbies is on the Open Projects IRC Network,
|
||||
try irc.openprojects.net or irc.<country>.openprojects.net as your
|
||||
server and then /join #kernelnewbies". It also hosts articles,
|
||||
documents, FAQs...
|
||||
people.
|
||||
#kernelnewbies is on the OFTC IRC Network.
|
||||
Try irc.oftc.net as your server and then /join #kernelnewbies.
|
||||
The kernelnewbies website also hosts articles, documents, FAQs...
|
||||
|
||||
* Name: "linux-kernel mailing list archives and search engines"
|
||||
URL: http://vger.kernel.org/vger-lists.html
|
||||
|
@ -790,8 +790,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
is passed, kernel could allocate physical memory region
|
||||
above 4G, that cause second kernel crash on system
|
||||
that require some amount of low memory, e.g. swiotlb
|
||||
requires at least 64M+32K low memory. Kernel would
|
||||
try to allocate 72M below 4G automatically.
|
||||
requires at least 64M+32K low memory, also enough extra
|
||||
low memory is needed to make sure DMA buffers for 32-bit
|
||||
devices won't run out. Kernel would try to allocate at
|
||||
at least 256M below 4G automatically.
|
||||
This one let user to specify own low range under 4G
|
||||
for second kernel instead.
|
||||
0: to disable low allocation.
|
||||
@ -972,6 +974,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
|
||||
earlycon= [KNL] Output early console device and options.
|
||||
|
||||
When used with no options, the early console is
|
||||
determined by the stdout-path property in device
|
||||
tree's chosen node.
|
||||
|
||||
cdns,<addr>
|
||||
Start an early, polled-mode console on a cadence serial
|
||||
port at the specified address. The cadence serial port
|
||||
@ -2340,11 +2346,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
nmi_watchdog= [KNL,BUGS=X86] Debugging features for SMP kernels
|
||||
Format: [panic,][nopanic,][num]
|
||||
Valid num: 0 or 1
|
||||
0 - turn nmi_watchdog off
|
||||
1 - turn nmi_watchdog on
|
||||
0 - turn hardlockup detector in nmi_watchdog off
|
||||
1 - turn hardlockup detector in nmi_watchdog on
|
||||
When panic is specified, panic when an NMI watchdog
|
||||
timeout occurs (or 'nopanic' to override the opposite
|
||||
default).
|
||||
default). To disable both hard and soft lockup detectors,
|
||||
please see 'nowatchdog'.
|
||||
This is useful when you use a panic=... timeout and
|
||||
need the box quickly up again.
|
||||
|
||||
|
@ -54,6 +54,22 @@ To run the hotplug tests:
|
||||
- note that some tests will require root privileges.
|
||||
|
||||
|
||||
Install selftests
|
||||
=================
|
||||
|
||||
You can use kselftest_install.sh tool installs selftests in default
|
||||
location which is tools/testing/selftests/kselftest or an user specified
|
||||
location.
|
||||
|
||||
To install selftests in default location:
|
||||
$ cd tools/testing/selftests
|
||||
$ ./kselftest_install.sh
|
||||
|
||||
To install selftests in an user specified location:
|
||||
$ cd tools/testing/selftests
|
||||
$ ./kselftest_install.sh install_dir
|
||||
|
||||
|
||||
Contributing new tests
|
||||
======================
|
||||
|
||||
|
@ -30,7 +30,7 @@ lead to false interrupt, but that doesn't harm.
|
||||
|
||||
ALS contains 4 different gain steps. Driver automatically
|
||||
selects suitable gain step. After each measurement, reliability of the results
|
||||
is estimated and new measurement is trigged if necessary.
|
||||
is estimated and new measurement is triggered if necessary.
|
||||
|
||||
Platform data can provide tuned values to the conversion formulas if
|
||||
values are known. Otherwise plain sensor default values are used.
|
||||
|
@ -29,7 +29,7 @@ Detection
|
||||
|
||||
The ISL29003 does not have an ID register which could be used to identify
|
||||
it, so the detection routine will just try to read from the configured I2C
|
||||
addess and consider the device to be present as soon as it ACKs the
|
||||
address and consider the device to be present as soon as it ACKs the
|
||||
transfer.
|
||||
|
||||
|
||||
|
@ -22,7 +22,7 @@ At reset, the MAX6875 reads the configuration EEPROM into its configuration
|
||||
registers. The chip then begins to operate according to the values in the
|
||||
registers.
|
||||
|
||||
The Maxim MAX6874 is a similar, mostly compatible device, with more intputs
|
||||
The Maxim MAX6874 is a similar, mostly compatible device, with more inputs
|
||||
and outputs:
|
||||
vin gpi vout
|
||||
MAX6874 6 4 8
|
||||
|
@ -1018,25 +1018,34 @@ solution for a couple of reasons:
|
||||
|
||||
$ ip link set can0 type can help
|
||||
Usage: ip link set DEVICE type can
|
||||
[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
|
||||
[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
|
||||
phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
|
||||
[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
|
||||
[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
|
||||
phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
|
||||
|
||||
[ loopback { on | off } ]
|
||||
[ listen-only { on | off } ]
|
||||
[ triple-sampling { on | off } ]
|
||||
[ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] |
|
||||
[ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
|
||||
dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
|
||||
|
||||
[ restart-ms TIME-MS ]
|
||||
[ restart ]
|
||||
[ loopback { on | off } ]
|
||||
[ listen-only { on | off } ]
|
||||
[ triple-sampling { on | off } ]
|
||||
[ one-shot { on | off } ]
|
||||
[ berr-reporting { on | off } ]
|
||||
[ fd { on | off } ]
|
||||
[ fd-non-iso { on | off } ]
|
||||
[ presume-ack { on | off } ]
|
||||
|
||||
Where: BITRATE := { 1..1000000 }
|
||||
SAMPLE-POINT := { 0.000..0.999 }
|
||||
TQ := { NUMBER }
|
||||
PROP-SEG := { 1..8 }
|
||||
PHASE-SEG1 := { 1..8 }
|
||||
PHASE-SEG2 := { 1..8 }
|
||||
SJW := { 1..4 }
|
||||
RESTART-MS := { 0 | NUMBER }
|
||||
[ restart-ms TIME-MS ]
|
||||
[ restart ]
|
||||
|
||||
Where: BITRATE := { 1..1000000 }
|
||||
SAMPLE-POINT := { 0.000..0.999 }
|
||||
TQ := { NUMBER }
|
||||
PROP-SEG := { 1..8 }
|
||||
PHASE-SEG1 := { 1..8 }
|
||||
PHASE-SEG2 := { 1..8 }
|
||||
SJW := { 1..4 }
|
||||
RESTART-MS := { 0 | NUMBER }
|
||||
|
||||
- Display CAN device details and statistics:
|
||||
|
||||
@ -1178,7 +1187,55 @@ solution for a couple of reasons:
|
||||
The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
|
||||
N.B. CAN FD capable devices can also handle and send legacy CAN frames.
|
||||
|
||||
FIXME: Add details about the CAN FD controller configuration when available.
|
||||
When configuring CAN FD capable CAN controllers an additional 'data' bitrate
|
||||
has to be set. This bitrate for the data phase of the CAN FD frame has to be
|
||||
at least the bitrate which was configured for the arbitration phase. This
|
||||
second bitrate is specified analogue to the first bitrate but the bitrate
|
||||
setting keywords for the 'data' bitrate start with 'd' e.g. dbitrate,
|
||||
dsample-point, dsjw or dtq and similar settings. When a data bitrate is set
|
||||
within the configuration process the controller option "fd on" can be
|
||||
specified to enable the CAN FD mode in the CAN controller. This controller
|
||||
option also switches the device MTU to 72 (CANFD_MTU).
|
||||
|
||||
The first CAN FD specification presented as whitepaper at the International
|
||||
CAN Conference 2012 needed to be improved for data integrity reasons.
|
||||
Therefore two CAN FD implementations have to be distinguished today:
|
||||
|
||||
- ISO compliant: The ISO 11898-1:2015 CAN FD implementation (default)
|
||||
- non-ISO compliant: The CAN FD implementation following the 2012 whitepaper
|
||||
|
||||
Finally there are three types of CAN FD controllers:
|
||||
|
||||
1. ISO compliant (fixed)
|
||||
2. non-ISO compliant (fixed, like the M_CAN IP core v3.0.1 in m_can.c)
|
||||
3. ISO/non-ISO CAN FD controllers (switchable, like the PEAK PCAN-USB FD)
|
||||
|
||||
The current ISO/non-ISO mode is announced by the CAN controller driver via
|
||||
netlink and displayed by the 'ip' tool (controller option FD-NON-ISO).
|
||||
The ISO/non-ISO-mode can be altered by setting 'fd-non-iso {on|off}' for
|
||||
switchable CAN FD controllers only.
|
||||
|
||||
Example configuring 500 kbit/s arbitration bitrate and 4 Mbit/s data bitrate:
|
||||
|
||||
$ ip link set can0 up type can bitrate 500000 sample-point 0.75 \
|
||||
dbitrate 4000000 dsample-point 0.8 fd on
|
||||
$ ip -details link show can0
|
||||
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UNKNOWN \
|
||||
mode DEFAULT group default qlen 10
|
||||
link/can promiscuity 0
|
||||
can <FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
|
||||
bitrate 500000 sample-point 0.750
|
||||
tq 50 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
|
||||
pcan_usb_pro_fd: tseg1 1..64 tseg2 1..16 sjw 1..16 brp 1..1024 \
|
||||
brp-inc 1
|
||||
dbitrate 4000000 dsample-point 0.800
|
||||
dtq 12 dprop-seg 7 dphase-seg1 8 dphase-seg2 4 dsjw 1
|
||||
pcan_usb_pro_fd: dtseg1 1..16 dtseg2 1..8 dsjw 1..4 dbrp 1..1024 \
|
||||
dbrp-inc 1
|
||||
clock 80000000
|
||||
|
||||
Example when 'fd-non-iso on' is added on this switchable CAN FD adapter:
|
||||
can <FD,FD-NON-ISO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
|
||||
|
||||
6.7 Supported CAN hardware
|
||||
|
||||
|
@ -203,7 +203,7 @@ functions with the user provided augmentation callback when inserting
|
||||
and erasing nodes.
|
||||
|
||||
C files implementing augmented rbtree manipulation must include
|
||||
<linux/rbtree_augmented.h> instead of <linus/rbtree.h>. Note that
|
||||
<linux/rbtree_augmented.h> instead of <linux/rbtree.h>. Note that
|
||||
linux/rbtree_augmented.h exposes some rbtree implementations details
|
||||
you are not expected to rely on; please stick to the documented APIs
|
||||
there and do not include <linux/rbtree_augmented.h> from header files
|
||||
|
@ -1774,7 +1774,7 @@ has been called, this interface is completely emulated within the kernel.
|
||||
To use this to emulate the LINT1 input with KVM_CREATE_IRQCHIP, use the
|
||||
following algorithm:
|
||||
|
||||
- pause the vpcu
|
||||
- pause the vcpu
|
||||
- read the local APIC's state (KVM_GET_LAPIC)
|
||||
- check whether changing LINT1 will queue an NMI (see the LVT entry for LINT1)
|
||||
- if so, issue KVM_NMI
|
||||
@ -2798,7 +2798,7 @@ Returns: = 0 on success,
|
||||
< 0 on generic error (e.g. -EFAULT or -ENOMEM),
|
||||
> 0 if an exception occurred while walking the page tables
|
||||
|
||||
Read or write data from/to the logical (virtual) memory of a VPCU.
|
||||
Read or write data from/to the logical (virtual) memory of a VCPU.
|
||||
|
||||
Parameters are specified via the following structure:
|
||||
|
||||
|
@ -74,7 +74,7 @@ struct kvm_s390_vm_cpu_processor {
|
||||
|
||||
KVM does not enforce or limit the cpu model data in any form. Take the information
|
||||
retrieved by means of KVM_S390_VM_CPU_MACHINE as hint for reasonable configuration
|
||||
setups. Instruction interceptions triggered by additionally set facilitiy bits that
|
||||
setups. Instruction interceptions triggered by additionally set facility bits that
|
||||
are not handled by KVM need to by imlemented in the VM driver code.
|
||||
|
||||
Parameters: address of buffer to store/set the processor related cpu
|
||||
|
@ -110,7 +110,7 @@ Flags are passed to the host in the low 12 bits of the Effective Address.
|
||||
|
||||
The following flags are currently available for a guest to expose:
|
||||
|
||||
MAGIC_PAGE_FLAG_NOT_MAPPED_NX Guest handles NX bits correclty wrt magic page
|
||||
MAGIC_PAGE_FLAG_NOT_MAPPED_NX Guest handles NX bits correctly wrt magic page
|
||||
|
||||
MSR bits
|
||||
========
|
||||
|
@ -280,4 +280,63 @@ of other objects.
|
||||
|
||||
slub_debug=FZ,dentry
|
||||
|
||||
Extended slabinfo mode and plotting
|
||||
-----------------------------------
|
||||
|
||||
The slabinfo tool has a special 'extended' ('-X') mode that includes:
|
||||
- Slabcache Totals
|
||||
- Slabs sorted by size (up to -N <num> slabs, default 1)
|
||||
- Slabs sorted by loss (up to -N <num> slabs, default 1)
|
||||
|
||||
Additionally, in this mode slabinfo does not dynamically scale sizes (G/M/K)
|
||||
and reports everything in bytes (this functionality is also available to
|
||||
other slabinfo modes via '-B' option) which makes reporting more precise and
|
||||
accurate. Moreover, in some sense the `-X' mode also simplifies the analysis
|
||||
of slabs' behaviour, because its output can be plotted using the
|
||||
slabinfo-gnuplot.sh script. So it pushes the analysis from looking through
|
||||
the numbers (tons of numbers) to something easier -- visual analysis.
|
||||
|
||||
To generate plots:
|
||||
a) collect slabinfo extended records, for example:
|
||||
|
||||
while [ 1 ]; do slabinfo -X >> FOO_STATS; sleep 1; done
|
||||
|
||||
b) pass stats file(-s) to slabinfo-gnuplot.sh script:
|
||||
slabinfo-gnuplot.sh FOO_STATS [FOO_STATS2 .. FOO_STATSN]
|
||||
|
||||
The slabinfo-gnuplot.sh script will pre-processes the collected records
|
||||
and generates 3 png files (and 3 pre-processing cache files) per STATS
|
||||
file:
|
||||
- Slabcache Totals: FOO_STATS-totals.png
|
||||
- Slabs sorted by size: FOO_STATS-slabs-by-size.png
|
||||
- Slabs sorted by loss: FOO_STATS-slabs-by-loss.png
|
||||
|
||||
Another use case, when slabinfo-gnuplot can be useful, is when you need
|
||||
to compare slabs' behaviour "prior to" and "after" some code modification.
|
||||
To help you out there, slabinfo-gnuplot.sh script can 'merge' the
|
||||
`Slabcache Totals` sections from different measurements. To visually
|
||||
compare N plots:
|
||||
|
||||
a) Collect as many STATS1, STATS2, .. STATSN files as you need
|
||||
while [ 1 ]; do slabinfo -X >> STATS<X>; sleep 1; done
|
||||
|
||||
b) Pre-process those STATS files
|
||||
slabinfo-gnuplot.sh STATS1 STATS2 .. STATSN
|
||||
|
||||
c) Execute slabinfo-gnuplot.sh in '-t' mode, passing all of the
|
||||
generated pre-processed *-totals
|
||||
slabinfo-gnuplot.sh -t STATS1-totals STATS2-totals .. STATSN-totals
|
||||
|
||||
This will produce a single plot (png file).
|
||||
|
||||
Plots, expectedly, can be large so some fluctuations or small spikes
|
||||
can go unnoticed. To deal with that, `slabinfo-gnuplot.sh' has two
|
||||
options to 'zoom-in'/'zoom-out':
|
||||
a) -s %d,%d overwrites the default image width and heigh
|
||||
b) -r %d,%d specifies a range of samples to use (for example,
|
||||
in `slabinfo -X >> FOO_STATS; sleep 1;' case, using
|
||||
a "-r 40,60" range will plot only samples collected
|
||||
between 40th and 60th seconds).
|
||||
|
||||
Christoph Lameter, May 30, 2007
|
||||
Sergey Senozhatsky, October 23, 2015
|
||||
|
@ -61,7 +61,7 @@ Documentation/kobject.txt 文档以获得更多关于 kobject 接口的
|
||||
内核的对象层次到用户空间。sysfs 中的顶层目录代表着内核对象层次的
|
||||
共同祖先;例如:某些对象属于某个子系统。
|
||||
|
||||
Sysfs 在与其目录关联的 sysfs_dirent 对象中内部保存一个指向实现
|
||||
Sysfs 在与其目录关联的 kernfs_node 对象中内部保存一个指向实现
|
||||
目录的 kobject 的指针。以前,这个 kobject 指针被 sysfs 直接用于
|
||||
kobject 文件打开和关闭的引用计数。而现在的 sysfs 实现中,kobject
|
||||
引用计数只能通过 sysfs_schedule_callback() 函数直接修改。
|
||||
|
@ -3528,13 +3528,15 @@ M: Jonathan Corbet <corbet@lwn.net>
|
||||
L: linux-doc@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/
|
||||
F: scripts/docproc.c
|
||||
F: scripts/kernel-doc*
|
||||
X: Documentation/ABI/
|
||||
X: Documentation/devicetree/
|
||||
X: Documentation/acpi
|
||||
X: Documentation/power
|
||||
X: Documentation/spi
|
||||
X: Documentation/DocBook/media
|
||||
T: git git://git.lwn.net/linux-2.6.git docs-next
|
||||
T: git git://git.lwn.net/linux.git docs-next
|
||||
|
||||
DOUBLETALK DRIVER
|
||||
M: "James R. Van Zandt" <jrv@vanzandt.mv.com>
|
||||
|
2
Makefile
2
Makefile
@ -1336,7 +1336,7 @@ $(help-board-dirs): help-%:
|
||||
# Documentation targets
|
||||
# ---------------------------------------------------------------------------
|
||||
%docs: scripts_basic FORCE
|
||||
$(Q)$(MAKE) $(build)=scripts build_docproc
|
||||
$(Q)$(MAKE) $(build)=scripts build_docproc build_check-lc_ctype
|
||||
$(Q)$(MAKE) $(build)=Documentation/DocBook $@
|
||||
|
||||
else # KBUILD_EXTMOD
|
||||
|
2
README
2
README
@ -24,7 +24,7 @@ ON WHAT HARDWARE DOES IT RUN?
|
||||
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
|
||||
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
|
||||
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
|
||||
Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures.
|
||||
Xtensa, Tilera TILE, AVR32, ARC and Renesas M32R architectures.
|
||||
|
||||
Linux is easily portable to most general-purpose 32- or 64-bit architectures
|
||||
as long as they have a paged memory management unit (PMMU) and a port of the
|
||||
|
1
scripts/.gitignore
vendored
1
scripts/.gitignore
vendored
@ -8,6 +8,7 @@ unifdef
|
||||
ihex2fw
|
||||
recordmcount
|
||||
docproc
|
||||
check-lc_ctype
|
||||
sortextable
|
||||
asn1_compiler
|
||||
extract-cert
|
||||
|
@ -7,6 +7,7 @@
|
||||
# conmakehash: Create chartable
|
||||
# conmakehash: Create arrays for initializing the kernel console tables
|
||||
# docproc: Used in Documentation/DocBook
|
||||
# check-lc_ctype: Used in Documentation/DocBook
|
||||
|
||||
HOST_EXTRACFLAGS += -I$(srctree)/tools/include
|
||||
|
||||
@ -27,14 +28,16 @@ HOSTLOADLIBES_extract-cert = -lcrypto
|
||||
always := $(hostprogs-y) $(hostprogs-m)
|
||||
|
||||
# The following hostprogs-y programs are only build on demand
|
||||
hostprogs-y += unifdef docproc
|
||||
hostprogs-y += unifdef docproc check-lc_ctype
|
||||
|
||||
# These targets are used internally to avoid "is up to date" messages
|
||||
PHONY += build_unifdef build_docproc
|
||||
PHONY += build_unifdef build_docproc build_check-lc_ctype
|
||||
build_unifdef: $(obj)/unifdef
|
||||
@:
|
||||
build_docproc: $(obj)/docproc
|
||||
@:
|
||||
build_check-lc_ctype: $(obj)/check-lc_ctype
|
||||
@:
|
||||
|
||||
subdir-$(CONFIG_MODVERSIONS) += genksyms
|
||||
subdir-y += mod
|
||||
|
11
scripts/check-lc_ctype.c
Normal file
11
scripts/check-lc_ctype.c
Normal file
@ -0,0 +1,11 @@
|
||||
/*
|
||||
* Check that a specified locale works as LC_CTYPE. Used by the
|
||||
* DocBook build system to probe for C.UTF-8 support.
|
||||
*/
|
||||
|
||||
#include <locale.h>
|
||||
|
||||
int main(void)
|
||||
{
|
||||
return !setlocale(LC_CTYPE, "");
|
||||
}
|
@ -206,59 +206,73 @@ my $type_env = '(\$\w+)';
|
||||
# One for each output format
|
||||
|
||||
# these work fairly well
|
||||
my %highlights_html = ( $type_constant, "<i>\$1</i>",
|
||||
$type_func, "<b>\$1</b>",
|
||||
$type_struct_xml, "<i>\$1</i>",
|
||||
$type_env, "<b><i>\$1</i></b>",
|
||||
$type_param, "<tt><b>\$1</b></tt>" );
|
||||
my @highlights_html = (
|
||||
[$type_constant, "<i>\$1</i>"],
|
||||
[$type_func, "<b>\$1</b>"],
|
||||
[$type_struct_xml, "<i>\$1</i>"],
|
||||
[$type_env, "<b><i>\$1</i></b>"],
|
||||
[$type_param, "<tt><b>\$1</b></tt>"]
|
||||
);
|
||||
my $local_lt = "\\\\\\\\lt:";
|
||||
my $local_gt = "\\\\\\\\gt:";
|
||||
my $blankline_html = $local_lt . "p" . $local_gt; # was "<p>"
|
||||
|
||||
# html version 5
|
||||
my %highlights_html5 = ( $type_constant, "<span class=\"const\">\$1</span>",
|
||||
$type_func, "<span class=\"func\">\$1</span>",
|
||||
$type_struct_xml, "<span class=\"struct\">\$1</span>",
|
||||
$type_env, "<span class=\"env\">\$1</span>",
|
||||
$type_param, "<span class=\"param\">\$1</span>" );
|
||||
my @highlights_html5 = (
|
||||
[$type_constant, "<span class=\"const\">\$1</span>"],
|
||||
[$type_func, "<span class=\"func\">\$1</span>"],
|
||||
[$type_struct_xml, "<span class=\"struct\">\$1</span>"],
|
||||
[$type_env, "<span class=\"env\">\$1</span>"],
|
||||
[$type_param, "<span class=\"param\">\$1</span>]"]
|
||||
);
|
||||
my $blankline_html5 = $local_lt . "br /" . $local_gt;
|
||||
|
||||
# XML, docbook format
|
||||
my %highlights_xml = ( "([^=])\\\"([^\\\"<]+)\\\"", "\$1<quote>\$2</quote>",
|
||||
$type_constant, "<constant>\$1</constant>",
|
||||
$type_func, "<function>\$1</function>",
|
||||
$type_struct_xml, "<structname>\$1</structname>",
|
||||
$type_env, "<envar>\$1</envar>",
|
||||
$type_param, "<parameter>\$1</parameter>" );
|
||||
my @highlights_xml = (
|
||||
["([^=])\\\"([^\\\"<]+)\\\"", "\$1<quote>\$2</quote>"],
|
||||
[$type_constant, "<constant>\$1</constant>"],
|
||||
[$type_struct_xml, "<structname>\$1</structname>"],
|
||||
[$type_param, "<parameter>\$1</parameter>"],
|
||||
[$type_func, "<function>\$1</function>"],
|
||||
[$type_env, "<envar>\$1</envar>"]
|
||||
);
|
||||
my $blankline_xml = $local_lt . "/para" . $local_gt . $local_lt . "para" . $local_gt . "\n";
|
||||
|
||||
# gnome, docbook format
|
||||
my %highlights_gnome = ( $type_constant, "<replaceable class=\"option\">\$1</replaceable>",
|
||||
$type_func, "<function>\$1</function>",
|
||||
$type_struct, "<structname>\$1</structname>",
|
||||
$type_env, "<envar>\$1</envar>",
|
||||
$type_param, "<parameter>\$1</parameter>" );
|
||||
my @highlights_gnome = (
|
||||
[$type_constant, "<replaceable class=\"option\">\$1</replaceable>"],
|
||||
[$type_func, "<function>\$1</function>"],
|
||||
[$type_struct, "<structname>\$1</structname>"],
|
||||
[$type_env, "<envar>\$1</envar>"],
|
||||
[$type_param, "<parameter>\$1</parameter>" ]
|
||||
);
|
||||
my $blankline_gnome = "</para><para>\n";
|
||||
|
||||
# these are pretty rough
|
||||
my %highlights_man = ( $type_constant, "\$1",
|
||||
$type_func, "\\\\fB\$1\\\\fP",
|
||||
$type_struct, "\\\\fI\$1\\\\fP",
|
||||
$type_param, "\\\\fI\$1\\\\fP" );
|
||||
my @highlights_man = (
|
||||
[$type_constant, "\$1"],
|
||||
[$type_func, "\\\\fB\$1\\\\fP"],
|
||||
[$type_struct, "\\\\fI\$1\\\\fP"],
|
||||
[$type_param, "\\\\fI\$1\\\\fP"]
|
||||
);
|
||||
my $blankline_man = "";
|
||||
|
||||
# text-mode
|
||||
my %highlights_text = ( $type_constant, "\$1",
|
||||
$type_func, "\$1",
|
||||
$type_struct, "\$1",
|
||||
$type_param, "\$1" );
|
||||
my @highlights_text = (
|
||||
[$type_constant, "\$1"],
|
||||
[$type_func, "\$1"],
|
||||
[$type_struct, "\$1"],
|
||||
[$type_param, "\$1"]
|
||||
);
|
||||
my $blankline_text = "";
|
||||
|
||||
# list mode
|
||||
my %highlights_list = ( $type_constant, "\$1",
|
||||
$type_func, "\$1",
|
||||
$type_struct, "\$1",
|
||||
$type_param, "\$1" );
|
||||
my @highlights_list = (
|
||||
[$type_constant, "\$1"],
|
||||
[$type_func, "\$1"],
|
||||
[$type_struct, "\$1"],
|
||||
[$type_param, "\$1"]
|
||||
);
|
||||
my $blankline_list = "";
|
||||
|
||||
# read arguments
|
||||
@ -273,7 +287,7 @@ my $verbose = 0;
|
||||
my $output_mode = "man";
|
||||
my $output_preformatted = 0;
|
||||
my $no_doc_sections = 0;
|
||||
my %highlights = %highlights_man;
|
||||
my @highlights = @highlights_man;
|
||||
my $blankline = $blankline_man;
|
||||
my $modulename = "Kernel API";
|
||||
my $function_only = 0;
|
||||
@ -374,31 +388,31 @@ while ($ARGV[0] =~ m/^-(.*)/) {
|
||||
my $cmd = shift @ARGV;
|
||||
if ($cmd eq "-html") {
|
||||
$output_mode = "html";
|
||||
%highlights = %highlights_html;
|
||||
@highlights = @highlights_html;
|
||||
$blankline = $blankline_html;
|
||||
} elsif ($cmd eq "-html5") {
|
||||
$output_mode = "html5";
|
||||
%highlights = %highlights_html5;
|
||||
@highlights = @highlights_html5;
|
||||
$blankline = $blankline_html5;
|
||||
} elsif ($cmd eq "-man") {
|
||||
$output_mode = "man";
|
||||
%highlights = %highlights_man;
|
||||
@highlights = @highlights_man;
|
||||
$blankline = $blankline_man;
|
||||
} elsif ($cmd eq "-text") {
|
||||
$output_mode = "text";
|
||||
%highlights = %highlights_text;
|
||||
@highlights = @highlights_text;
|
||||
$blankline = $blankline_text;
|
||||
} elsif ($cmd eq "-docbook") {
|
||||
$output_mode = "xml";
|
||||
%highlights = %highlights_xml;
|
||||
@highlights = @highlights_xml;
|
||||
$blankline = $blankline_xml;
|
||||
} elsif ($cmd eq "-list") {
|
||||
$output_mode = "list";
|
||||
%highlights = %highlights_list;
|
||||
@highlights = @highlights_list;
|
||||
$blankline = $blankline_list;
|
||||
} elsif ($cmd eq "-gnome") {
|
||||
$output_mode = "gnome";
|
||||
%highlights = %highlights_gnome;
|
||||
@highlights = @highlights_gnome;
|
||||
$blankline = $blankline_gnome;
|
||||
} elsif ($cmd eq "-module") { # not needed for XML, inherits from calling document
|
||||
$modulename = shift @ARGV;
|
||||
@ -1746,7 +1760,7 @@ sub output_declaration {
|
||||
my $func = "output_${functype}_$output_mode";
|
||||
if (($function_only==0) ||
|
||||
( $function_only == 1 && defined($function_table{$name})) ||
|
||||
( $function_only == 2 && !defined($function_table{$name})))
|
||||
( $function_only == 2 && !($functype eq "function" && defined($function_table{$name}))))
|
||||
{
|
||||
&$func(@_);
|
||||
$section_counter++;
|
||||
@ -1791,8 +1805,8 @@ sub dump_struct($$) {
|
||||
$nested = $1;
|
||||
|
||||
# ignore members marked private:
|
||||
$members =~ s/\/\*\s*private:.*?\/\*\s*public:.*?\*\///gos;
|
||||
$members =~ s/\/\*\s*private:.*//gos;
|
||||
$members =~ s/\/\*\s*private:.*?\/\*\s*public:.*?\*\///gosi;
|
||||
$members =~ s/\/\*\s*private:.*//gosi;
|
||||
# strip comments:
|
||||
$members =~ s/\/\*.*?\*\///gos;
|
||||
$nested =~ s/\/\*.*?\*\///gos;
|
||||
@ -2416,12 +2430,13 @@ sub process_file($) {
|
||||
my $descr;
|
||||
my $in_purpose = 0;
|
||||
my $initial_section_counter = $section_counter;
|
||||
my ($orig_file) = @_;
|
||||
|
||||
if (defined($ENV{'SRCTREE'})) {
|
||||
$file = "$ENV{'SRCTREE'}" . "/" . "@_";
|
||||
$file = "$ENV{'SRCTREE'}" . "/" . $orig_file;
|
||||
}
|
||||
else {
|
||||
$file = "@_";
|
||||
$file = $orig_file;
|
||||
}
|
||||
if (defined($source_map{$file})) {
|
||||
$file = $source_map{$file};
|
||||
@ -2665,7 +2680,7 @@ sub process_file($) {
|
||||
print "<refentry>\n";
|
||||
print " <refnamediv>\n";
|
||||
print " <refname>\n";
|
||||
print " ${file}\n";
|
||||
print " ${orig_file}\n";
|
||||
print " </refname>\n";
|
||||
print " <refpurpose>\n";
|
||||
print " Document generation inconsistency\n";
|
||||
@ -2679,7 +2694,7 @@ sub process_file($) {
|
||||
print " <para>\n";
|
||||
print " The template for this document tried to insert\n";
|
||||
print " the structured comment from the file\n";
|
||||
print " <filename>${file}</filename> at this point,\n";
|
||||
print " <filename>${orig_file}</filename> at this point,\n";
|
||||
print " but none was found.\n";
|
||||
print " This dummy section is inserted to allow\n";
|
||||
print " generation to continue.\n";
|
||||
@ -2696,9 +2711,11 @@ $kernelversion = get_kernel_version();
|
||||
|
||||
# generate a sequence of code that will splice in highlighting information
|
||||
# using the s// operator.
|
||||
foreach my $pattern (sort keys %highlights) {
|
||||
# print STDERR "scanning pattern:$pattern, highlight:($highlights{$pattern})\n";
|
||||
$dohighlight .= "\$contents =~ s:$pattern:$highlights{$pattern}:gs;\n";
|
||||
foreach my $k (keys @highlights) {
|
||||
my $pattern = $highlights[$k][0];
|
||||
my $result = $highlights[$k][1];
|
||||
# print STDERR "scanning pattern:$pattern, highlight:($result)\n";
|
||||
$dohighlight .= "\$contents =~ s:$pattern:$result:gs;\n";
|
||||
}
|
||||
|
||||
# Read the file that maps relative names to absolute names for
|
||||
|
Loading…
Reference in New Issue
Block a user