mirror of
https://github.com/torvalds/linux.git
synced 2024-12-27 21:33:00 +00:00
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (44 commits) vlynq: make whole Kconfig-menu dependant on architecture add descriptive comment for TIF_MEMDIE task flag declaration. EEPROM: max6875: Header file cleanup EEPROM: 93cx6: Header file cleanup EEPROM: Header file cleanup agp: use NULL instead of 0 when pointer is needed rtc-v3020: make bitfield unsigned PCI: make bitfield unsigned jbd2: use NULL instead of 0 when pointer is needed cciss: fix shadows sparse warning doc: inode uses a mutex instead of a semaphore. uml: i386: Avoid redefinition of NR_syscalls fix "seperate" typos in comments cocbalt_lcdfb: correct sections doc: Change urls for sparse Powerpc: wii: Fix typo in comment i2o: cleanup some exit paths Documentation/: it's -> its where appropriate UML: Fix compiler warning due to missing task_struct declaration UML: add kernel.h include to signal.c ...
This commit is contained in:
commit
f39d01be4c
@ -43,7 +43,7 @@ Date: September 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/state
|
||||
is read-write. When read, it's contents show the
|
||||
is read-write. When read, its contents show the
|
||||
online/offline state of the memory section. When written,
|
||||
root can toggle the the online/offline state of a removable
|
||||
memory section (see removable file description above)
|
||||
|
@ -742,7 +742,7 @@ failure can be determined by:
|
||||
|
||||
Closing
|
||||
|
||||
This document, and the API itself, would not be in it's current
|
||||
This document, and the API itself, would not be in its current
|
||||
form without the feedback and suggestions from numerous individuals.
|
||||
We would like to specifically mention, in no particular order, the
|
||||
following people:
|
||||
|
@ -477,7 +477,7 @@ void (*host_stop) (struct ata_host_set *host_set);
|
||||
allocates space for a legacy IDE PRD table and returns.
|
||||
</para>
|
||||
<para>
|
||||
->port_stop() is called after ->host_stop(). It's sole function
|
||||
->port_stop() is called after ->host_stop(). Its sole function
|
||||
is to release DMA/memory resources, now that they are no longer
|
||||
actively being used. Many drivers also free driver-private
|
||||
data from port at this time.
|
||||
|
@ -216,7 +216,7 @@ The driver should return one of the following result codes:
|
||||
|
||||
- PCI_ERS_RESULT_NEED_RESET
|
||||
Driver returns this if it thinks the device is not
|
||||
recoverable in it's current state and it needs a slot
|
||||
recoverable in its current state and it needs a slot
|
||||
reset to proceed.
|
||||
|
||||
- PCI_ERS_RESULT_DISCONNECT
|
||||
@ -241,7 +241,7 @@ in working condition.
|
||||
|
||||
The driver is not supposed to restart normal driver I/O operations
|
||||
at this point. It should limit itself to "probing" the device to
|
||||
check it's recoverability status. If all is right, then the platform
|
||||
check its recoverability status. If all is right, then the platform
|
||||
will call resume() once all drivers have ack'd link_reset().
|
||||
|
||||
Result codes:
|
||||
|
@ -73,7 +73,7 @@ NOTE: Smack labels are limited to 23 characters. The attr command
|
||||
If you don't do anything special all users will get the floor ("_")
|
||||
label when they log in. If you do want to log in via the hacked ssh
|
||||
at other labels use the attr command to set the smack value on the
|
||||
home directory and it's contents.
|
||||
home directory and its contents.
|
||||
|
||||
You can add access rules in /etc/smack/accesses. They take the form:
|
||||
|
||||
|
@ -32,7 +32,7 @@ Notes:
|
||||
|
||||
- The flash on board is divided into 3 partitions.
|
||||
You should be careful to use flash on board.
|
||||
It's partition is different from GraphicsClient Plus and GraphicsMaster
|
||||
Its partition is different from GraphicsClient Plus and GraphicsMaster
|
||||
|
||||
- 16bpp mode requires a different cable than what ships with the board.
|
||||
Contact ADS or look through the manual to wire your own. Currently,
|
||||
|
@ -7,7 +7,7 @@ The driver only implements a four-wire touch panel protocol.
|
||||
|
||||
The touchscreen driver is maintenance free except for the pen-down or
|
||||
touch threshold. Some resistive displays and board combinations may
|
||||
require tuning of this threshold. The driver exposes some of it's
|
||||
require tuning of this threshold. The driver exposes some of its
|
||||
internal state in the sys filesystem. If the kernel is configured
|
||||
with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a
|
||||
directory
|
||||
|
@ -320,7 +320,7 @@ counter decrement would not become globally visible until the
|
||||
obj->active update does.
|
||||
|
||||
As a historical note, 32-bit Sparc used to only allow usage of
|
||||
24-bits of it's atomic_t type. This was because it used 8 bits
|
||||
24-bits of its atomic_t type. This was because it used 8 bits
|
||||
as a spinlock for SMP safety. Sparc32 lacked a "compare and swap"
|
||||
type instruction. However, 32-bit Sparc has since been moved over
|
||||
to a "hash table of spinlocks" scheme, that allows the full 32-bit
|
||||
|
@ -43,7 +43,7 @@
|
||||
void bfin_gpio_irq_free(unsigned gpio);
|
||||
|
||||
The request functions will record the function state for a certain pin,
|
||||
the free functions will clear it's function state.
|
||||
the free functions will clear its function state.
|
||||
Once a pin is requested, it can't be requested again before it is freed by
|
||||
previous caller, otherwise kernel will dump stacks, and the request
|
||||
function fail.
|
||||
|
@ -5,7 +5,7 @@
|
||||
|
||||
This document describes the cache/tlb flushing interfaces called
|
||||
by the Linux VM subsystem. It enumerates over each interface,
|
||||
describes it's intended purpose, and what side effect is expected
|
||||
describes its intended purpose, and what side effect is expected
|
||||
after the interface is invoked.
|
||||
|
||||
The side effects described below are stated for a uniprocessor
|
||||
@ -231,7 +231,7 @@ require a whole different set of interfaces to handle properly.
|
||||
The biggest problem is that of virtual aliasing in the data cache
|
||||
of a processor.
|
||||
|
||||
Is your port susceptible to virtual aliasing in it's D-cache?
|
||||
Is your port susceptible to virtual aliasing in its D-cache?
|
||||
Well, if your D-cache is virtually indexed, is larger in size than
|
||||
PAGE_SIZE, and does not prevent multiple cache lines for the same
|
||||
physical address from existing at once, you have this problem.
|
||||
@ -249,7 +249,7 @@ one way to solve this (in particular SPARC_FLAG_MMAPSHARED).
|
||||
Next, you have to solve the D-cache aliasing issue for all
|
||||
other cases. Please keep in mind that fact that, for a given page
|
||||
mapped into some user address space, there is always at least one more
|
||||
mapping, that of the kernel in it's linear mapping starting at
|
||||
mapping, that of the kernel in its linear mapping starting at
|
||||
PAGE_OFFSET. So immediately, once the first user maps a given
|
||||
physical page into its address space, by implication the D-cache
|
||||
aliasing problem has the potential to exist since the kernel already
|
||||
|
@ -572,7 +572,7 @@ void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
|
||||
Called when a task attach operation has failed after can_attach() has succeeded.
|
||||
A subsystem whose can_attach() has some side-effects should provide this
|
||||
function, so that the subsytem can implement a rollback. If not, not necessary.
|
||||
function, so that the subsystem can implement a rollback. If not, not necessary.
|
||||
This will be called only about subsystems whose can_attach() operation have
|
||||
succeeded.
|
||||
|
||||
|
@ -42,7 +42,7 @@ Nodes to a set of tasks. In this document "Memory Node" refers to
|
||||
an on-line node that contains memory.
|
||||
|
||||
Cpusets constrain the CPU and Memory placement of tasks to only
|
||||
the resources within a tasks current cpuset. They form a nested
|
||||
the resources within a task's current cpuset. They form a nested
|
||||
hierarchy visible in a virtual file system. These are the essential
|
||||
hooks, beyond what is already present, required to manage dynamic
|
||||
job placement on large systems.
|
||||
@ -53,11 +53,11 @@ Documentation/cgroups/cgroups.txt.
|
||||
Requests by a task, using the sched_setaffinity(2) system call to
|
||||
include CPUs in its CPU affinity mask, and using the mbind(2) and
|
||||
set_mempolicy(2) system calls to include Memory Nodes in its memory
|
||||
policy, are both filtered through that tasks cpuset, filtering out any
|
||||
policy, are both filtered through that task's cpuset, filtering out any
|
||||
CPUs or Memory Nodes not in that cpuset. The scheduler will not
|
||||
schedule a task on a CPU that is not allowed in its cpus_allowed
|
||||
vector, and the kernel page allocator will not allocate a page on a
|
||||
node that is not allowed in the requesting tasks mems_allowed vector.
|
||||
node that is not allowed in the requesting task's mems_allowed vector.
|
||||
|
||||
User level code may create and destroy cpusets by name in the cgroup
|
||||
virtual file system, manage the attributes and permissions of these
|
||||
@ -121,9 +121,9 @@ Cpusets extends these two mechanisms as follows:
|
||||
- Each task in the system is attached to a cpuset, via a pointer
|
||||
in the task structure to a reference counted cgroup structure.
|
||||
- Calls to sched_setaffinity are filtered to just those CPUs
|
||||
allowed in that tasks cpuset.
|
||||
allowed in that task's cpuset.
|
||||
- Calls to mbind and set_mempolicy are filtered to just
|
||||
those Memory Nodes allowed in that tasks cpuset.
|
||||
those Memory Nodes allowed in that task's cpuset.
|
||||
- The root cpuset contains all the systems CPUs and Memory
|
||||
Nodes.
|
||||
- For any cpuset, one can define child cpusets containing a subset
|
||||
@ -141,11 +141,11 @@ into the rest of the kernel, none in performance critical paths:
|
||||
- in init/main.c, to initialize the root cpuset at system boot.
|
||||
- in fork and exit, to attach and detach a task from its cpuset.
|
||||
- in sched_setaffinity, to mask the requested CPUs by what's
|
||||
allowed in that tasks cpuset.
|
||||
allowed in that task's cpuset.
|
||||
- in sched.c migrate_live_tasks(), to keep migrating tasks within
|
||||
the CPUs allowed by their cpuset, if possible.
|
||||
- in the mbind and set_mempolicy system calls, to mask the requested
|
||||
Memory Nodes by what's allowed in that tasks cpuset.
|
||||
Memory Nodes by what's allowed in that task's cpuset.
|
||||
- in page_alloc.c, to restrict memory to allowed nodes.
|
||||
- in vmscan.c, to restrict page recovery to the current cpuset.
|
||||
|
||||
@ -155,7 +155,7 @@ new system calls are added for cpusets - all support for querying and
|
||||
modifying cpusets is via this cpuset file system.
|
||||
|
||||
The /proc/<pid>/status file for each task has four added lines,
|
||||
displaying the tasks cpus_allowed (on which CPUs it may be scheduled)
|
||||
displaying the task's cpus_allowed (on which CPUs it may be scheduled)
|
||||
and mems_allowed (on which Memory Nodes it may obtain memory),
|
||||
in the two formats seen in the following example:
|
||||
|
||||
@ -323,17 +323,17 @@ stack segment pages of a task.
|
||||
|
||||
By default, both kinds of memory spreading are off, and memory
|
||||
pages are allocated on the node local to where the task is running,
|
||||
except perhaps as modified by the tasks NUMA mempolicy or cpuset
|
||||
except perhaps as modified by the task's NUMA mempolicy or cpuset
|
||||
configuration, so long as sufficient free memory pages are available.
|
||||
|
||||
When new cpusets are created, they inherit the memory spread settings
|
||||
of their parent.
|
||||
|
||||
Setting memory spreading causes allocations for the affected page
|
||||
or slab caches to ignore the tasks NUMA mempolicy and be spread
|
||||
or slab caches to ignore the task's NUMA mempolicy and be spread
|
||||
instead. Tasks using mbind() or set_mempolicy() calls to set NUMA
|
||||
mempolicies will not notice any change in these calls as a result of
|
||||
their containing tasks memory spread settings. If memory spreading
|
||||
their containing task's memory spread settings. If memory spreading
|
||||
is turned off, then the currently specified NUMA mempolicy once again
|
||||
applies to memory page allocations.
|
||||
|
||||
@ -357,7 +357,7 @@ pages from the node returned by cpuset_mem_spread_node().
|
||||
|
||||
The cpuset_mem_spread_node() routine is also simple. It uses the
|
||||
value of a per-task rotor cpuset_mem_spread_rotor to select the next
|
||||
node in the current tasks mems_allowed to prefer for the allocation.
|
||||
node in the current task's mems_allowed to prefer for the allocation.
|
||||
|
||||
This memory placement policy is also known (in other contexts) as
|
||||
round-robin or interleave.
|
||||
@ -594,7 +594,7 @@ is attached, is subtle.
|
||||
If a cpuset has its Memory Nodes modified, then for each task attached
|
||||
to that cpuset, the next time that the kernel attempts to allocate
|
||||
a page of memory for that task, the kernel will notice the change
|
||||
in the tasks cpuset, and update its per-task memory placement to
|
||||
in the task's cpuset, and update its per-task memory placement to
|
||||
remain within the new cpusets memory placement. If the task was using
|
||||
mempolicy MPOL_BIND, and the nodes to which it was bound overlap with
|
||||
its new cpuset, then the task will continue to use whatever subset
|
||||
@ -603,13 +603,13 @@ was using MPOL_BIND and now none of its MPOL_BIND nodes are allowed
|
||||
in the new cpuset, then the task will be essentially treated as if it
|
||||
was MPOL_BIND bound to the new cpuset (even though its NUMA placement,
|
||||
as queried by get_mempolicy(), doesn't change). If a task is moved
|
||||
from one cpuset to another, then the kernel will adjust the tasks
|
||||
from one cpuset to another, then the kernel will adjust the task's
|
||||
memory placement, as above, the next time that the kernel attempts
|
||||
to allocate a page of memory for that task.
|
||||
|
||||
If a cpuset has its 'cpuset.cpus' modified, then each task in that cpuset
|
||||
will have its allowed CPU placement changed immediately. Similarly,
|
||||
if a tasks pid is written to another cpusets 'cpuset.tasks' file, then its
|
||||
if a task's pid is written to another cpusets 'cpuset.tasks' file, then its
|
||||
allowed CPU placement is changed immediately. If such a task had been
|
||||
bound to some subset of its cpuset using the sched_setaffinity() call,
|
||||
the task will be allowed to run on any CPU allowed in its new cpuset,
|
||||
@ -626,16 +626,16 @@ cpusets memory placement policy 'cpuset.mems' subsequently changes.
|
||||
If the cpuset flag file 'cpuset.memory_migrate' is set true, then when
|
||||
tasks are attached to that cpuset, any pages that task had
|
||||
allocated to it on nodes in its previous cpuset are migrated
|
||||
to the tasks new cpuset. The relative placement of the page within
|
||||
to the task's new cpuset. The relative placement of the page within
|
||||
the cpuset is preserved during these migration operations if possible.
|
||||
For example if the page was on the second valid node of the prior cpuset
|
||||
then the page will be placed on the second valid node of the new cpuset.
|
||||
|
||||
Also if 'cpuset.memory_migrate' is set true, then if that cpusets
|
||||
Also if 'cpuset.memory_migrate' is set true, then if that cpuset's
|
||||
'cpuset.mems' file is modified, pages allocated to tasks in that
|
||||
cpuset, that were on nodes in the previous setting of 'cpuset.mems',
|
||||
will be moved to nodes in the new setting of 'mems.'
|
||||
Pages that were not in the tasks prior cpuset, or in the cpusets
|
||||
Pages that were not in the task's prior cpuset, or in the cpuset's
|
||||
prior 'cpuset.mems' setting, will not be moved.
|
||||
|
||||
There is an exception to the above. If hotplug functionality is used
|
||||
@ -655,7 +655,7 @@ There is a second exception to the above. GFP_ATOMIC requests are
|
||||
kernel internal allocations that must be satisfied, immediately.
|
||||
The kernel may drop some request, in rare cases even panic, if a
|
||||
GFP_ATOMIC alloc fails. If the request cannot be satisfied within
|
||||
the current tasks cpuset, then we relax the cpuset, and look for
|
||||
the current task's cpuset, then we relax the cpuset, and look for
|
||||
memory anywhere we can find it. It's better to violate the cpuset
|
||||
than stress the kernel.
|
||||
|
||||
|
@ -244,7 +244,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
||||
we have to check if OLDPAGE/NEWPAGE is a valid page after commit().
|
||||
|
||||
8. LRU
|
||||
Each memcg has its own private LRU. Now, it's handling is under global
|
||||
Each memcg has its own private LRU. Now, its handling is under global
|
||||
VM's control (means that it's handled under global zone->lru_lock).
|
||||
Almost all routines around memcg's LRU is called by global LRU's
|
||||
list management functions under zone->lru_lock().
|
||||
|
@ -263,7 +263,7 @@ some of the pages cached in the cgroup (page cache pages).
|
||||
|
||||
4.2 Task migration
|
||||
|
||||
When a task migrates from one cgroup to another, it's charge is not
|
||||
When a task migrates from one cgroup to another, its charge is not
|
||||
carried forward by default. The pages allocated from the original cgroup still
|
||||
remain charged to it, the charge is dropped when the page is freed or
|
||||
reclaimed.
|
||||
|
@ -88,7 +88,7 @@ int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask);
|
||||
int gfp_mask - GFP mask.
|
||||
|
||||
Note: When registering new callback user, connector core assigns
|
||||
netlink group to the user which is equal to it's id.idx.
|
||||
netlink group to the user which is equal to its id.idx.
|
||||
|
||||
/*****************************************/
|
||||
Protocol description.
|
||||
|
@ -41,7 +41,7 @@ This application requires the following to function properly as of now.
|
||||
|
||||
* Cards that fall in this category
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
At present the cards that fall in this category are the Twinhan and it's
|
||||
At present the cards that fall in this category are the Twinhan and its
|
||||
clones, these cards are available as VVMER, Tomato, Hercules, Orange and
|
||||
so on.
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
Thanks go to the following people for patches and contributions:
|
||||
|
||||
Michael Hunold <m.hunold@gmx.de>
|
||||
for the initial saa7146 driver and it's recent overhaul
|
||||
for the initial saa7146 driver and its recent overhaul
|
||||
|
||||
Christian Theiss
|
||||
for his work on the initial Linux DVB driver
|
||||
|
@ -178,7 +178,7 @@ prototypes:
|
||||
locking rules:
|
||||
All except set_page_dirty may block
|
||||
|
||||
BKL PageLocked(page) i_sem
|
||||
BKL PageLocked(page) i_mutex
|
||||
writepage: no yes, unlocks (see below)
|
||||
readpage: no yes, unlocks
|
||||
sync_page: no maybe
|
||||
@ -429,7 +429,7 @@ check_flags: no
|
||||
implementations. If your fs is not using generic_file_llseek, you
|
||||
need to acquire and release the appropriate locks in your ->llseek().
|
||||
For many filesystems, it is probably safe to acquire the inode
|
||||
semaphore. Note some filesystems (i.e. remote ones) provide no
|
||||
mutex. Note some filesystems (i.e. remote ones) provide no
|
||||
protection for i_size so you will need to use the BKL.
|
||||
|
||||
Note: ext2_release() was *the* source of contention on fs-intensive
|
||||
|
@ -146,7 +146,7 @@ found to be inadequate, in this case. The Generic Netlink system was
|
||||
used for this as raw Netlink would lead to a significant increase in
|
||||
complexity. There's no question that the Generic Netlink system is an
|
||||
elegant solution for common case ioctl functions but it's not a complete
|
||||
replacement probably because it's primary purpose in life is to be a
|
||||
replacement probably because its primary purpose in life is to be a
|
||||
message bus implementation rather than specifically an ioctl replacement.
|
||||
While it would be possible to work around this there is one concern
|
||||
that lead to the decision to not use it. This is that the autofs
|
||||
|
@ -90,7 +90,7 @@ Mount Options
|
||||
Specify the IP and/or port the client should bind to locally.
|
||||
There is normally not much reason to do this. If the IP is not
|
||||
specified, the client's IP address is determined by looking at the
|
||||
address it's connection to the monitor originates from.
|
||||
address its connection to the monitor originates from.
|
||||
|
||||
wsize=X
|
||||
Specify the maximum write size in bytes. By default there is no
|
||||
|
@ -47,7 +47,7 @@ You'll want to start heartbeating on a volume which all the nodes in
|
||||
your lockspace can access. The easiest way to do this is via
|
||||
ocfs2_hb_ctl (distributed with ocfs2-tools). Right now it requires
|
||||
that an OCFS2 file system be in place so that it can automatically
|
||||
find it's heartbeat area, though it will eventually support heartbeat
|
||||
find its heartbeat area, though it will eventually support heartbeat
|
||||
against raw disks.
|
||||
|
||||
Please see the ocfs2_hb_ctl and mkfs.ocfs2 manual pages distributed
|
||||
|
@ -38,7 +38,7 @@ flags, it will return EBADR and the contents of fm_flags will contain
|
||||
the set of flags which caused the error. If the kernel is compatible
|
||||
with all flags passed, the contents of fm_flags will be unmodified.
|
||||
It is up to userspace to determine whether rejection of a particular
|
||||
flag is fatal to it's operation. This scheme is intended to allow the
|
||||
flag is fatal to its operation. This scheme is intended to allow the
|
||||
fiemap interface to grow in the future but without losing
|
||||
compatibility with old software.
|
||||
|
||||
@ -56,7 +56,7 @@ If this flag is set, the kernel will sync the file before mapping extents.
|
||||
|
||||
* FIEMAP_FLAG_XATTR
|
||||
If this flag is set, the extents returned will describe the inodes
|
||||
extended attribute lookup tree, instead of it's data tree.
|
||||
extended attribute lookup tree, instead of its data tree.
|
||||
|
||||
|
||||
Extent Mapping
|
||||
@ -89,7 +89,7 @@ struct fiemap_extent {
|
||||
};
|
||||
|
||||
All offsets and lengths are in bytes and mirror those on disk. It is valid
|
||||
for an extents logical offset to start before the request or it's logical
|
||||
for an extents logical offset to start before the request or its logical
|
||||
length to extend past the request. Unless FIEMAP_EXTENT_NOT_ALIGNED is
|
||||
returned, fe_logical, fe_physical, and fe_length will be aligned to the
|
||||
block size of the file system. With the exception of extents flagged as
|
||||
@ -125,7 +125,7 @@ been allocated for the file yet.
|
||||
|
||||
* FIEMAP_EXTENT_DELALLOC
|
||||
- This will also set FIEMAP_EXTENT_UNKNOWN.
|
||||
Delayed allocation - while there is data for this extent, it's
|
||||
Delayed allocation - while there is data for this extent, its
|
||||
physical location has not been allocated yet.
|
||||
|
||||
* FIEMAP_EXTENT_ENCODED
|
||||
@ -159,7 +159,7 @@ Data is located within a meta data block.
|
||||
Data is packed into a block with data from other files.
|
||||
|
||||
* FIEMAP_EXTENT_UNWRITTEN
|
||||
Unwritten extent - the extent is allocated but it's data has not been
|
||||
Unwritten extent - the extent is allocated but its data has not been
|
||||
initialized. This indicates the extent's data will be all zero if read
|
||||
through the filesystem but the contents are undefined if read directly from
|
||||
the device.
|
||||
@ -176,7 +176,7 @@ VFS -> File System Implementation
|
||||
|
||||
File systems wishing to support fiemap must implement a ->fiemap callback on
|
||||
their inode_operations structure. The fs ->fiemap call is responsible for
|
||||
defining it's set of supported fiemap flags, and calling a helper function on
|
||||
defining its set of supported fiemap flags, and calling a helper function on
|
||||
each discovered extent:
|
||||
|
||||
struct inode_operations {
|
||||
|
@ -91,7 +91,7 @@ Mount options
|
||||
'default_permissions'
|
||||
|
||||
By default FUSE doesn't check file access permissions, the
|
||||
filesystem is free to implement it's access policy or leave it to
|
||||
filesystem is free to implement its access policy or leave it to
|
||||
the underlying file access mechanism (e.g. in case of network
|
||||
filesystems). This option enables permission checking, restricting
|
||||
access based on file mode. It is usually useful together with the
|
||||
@ -171,7 +171,7 @@ or may honor them by sending a reply to the _original_ request, with
|
||||
the error set to EINTR.
|
||||
|
||||
It is also possible that there's a race between processing the
|
||||
original request and it's INTERRUPT request. There are two possibilities:
|
||||
original request and its INTERRUPT request. There are two possibilities:
|
||||
|
||||
1) The INTERRUPT request is processed before the original request is
|
||||
processed
|
||||
|
@ -103,7 +103,7 @@ to analyze or change OS2SYS.INI.
|
||||
Codepages
|
||||
|
||||
HPFS can contain several uppercasing tables for several codepages and each
|
||||
file has a pointer to codepage it's name is in. However OS/2 was created in
|
||||
file has a pointer to codepage its name is in. However OS/2 was created in
|
||||
America where people don't care much about codepages and so multiple codepages
|
||||
support is quite buggy. I have Czech OS/2 working in codepage 852 on my disk.
|
||||
Once I booted English OS/2 working in cp 850 and I created a file on my 852
|
||||
|
@ -59,7 +59,7 @@ Levels
|
||||
------
|
||||
|
||||
Garbage collection (GC) may fail if all data is written
|
||||
indiscriminately. One requirement of GC is that data is seperated
|
||||
indiscriminately. One requirement of GC is that data is separated
|
||||
roughly according to the distance between the tree root and the data.
|
||||
Effectively that means all file data is on level 0, indirect blocks
|
||||
are on levels 1, 2, 3 4 or 5 for 1x, 2x, 3x, 4x or 5x indirect blocks,
|
||||
@ -67,7 +67,7 @@ respectively. Inode file data is on level 6 for the inodes and 7-11
|
||||
for indirect blocks.
|
||||
|
||||
Each segment contains objects of a single level only. As a result,
|
||||
each level requires its own seperate segment to be open for writing.
|
||||
each level requires its own separate segment to be open for writing.
|
||||
|
||||
Inode File
|
||||
----------
|
||||
@ -106,9 +106,9 @@ Vim
|
||||
---
|
||||
|
||||
By cleverly predicting the life time of data, it is possible to
|
||||
seperate long-living data from short-living data and thereby reduce
|
||||
separate long-living data from short-living data and thereby reduce
|
||||
the GC overhead later. Each type of distinc life expectency (vim) can
|
||||
have a seperate segment open for writing. Each (level, vim) tupel can
|
||||
have a separate segment open for writing. Each (level, vim) tupel can
|
||||
be open just once. If an open segment with unknown vim is encountered
|
||||
at mount time, it is closed and ignored henceforth.
|
||||
|
||||
|
@ -185,7 +185,7 @@ failed lookup meant a definite 'no'.
|
||||
request/response format
|
||||
-----------------------
|
||||
|
||||
While each cache is free to use it's own format for requests
|
||||
While each cache is free to use its own format for requests
|
||||
and responses over channel, the following is recommended as
|
||||
appropriate and support routines are available to help:
|
||||
Each request or response record should be printable ASCII
|
||||
|
@ -305,7 +305,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
|
||||
cgtime guest time of the task children in jiffies
|
||||
..............................................................................
|
||||
|
||||
The /proc/PID/map file containing the currently mapped memory regions and
|
||||
The /proc/PID/maps file containing the currently mapped memory regions and
|
||||
their access permissions.
|
||||
|
||||
The format is:
|
||||
@ -968,7 +968,7 @@ your system and how much traffic was routed over those devices:
|
||||
...] 1375103 17405 0 0 0 0 0 0
|
||||
...] 1703981 5535 0 0 0 3 0 0
|
||||
|
||||
In addition, each Channel Bond interface has it's own directory. For
|
||||
In addition, each Channel Bond interface has its own directory. For
|
||||
example, the bond0 device will have a directory called /proc/net/bond0/.
|
||||
It will contain information that is specific to that bond, such as the
|
||||
current slaves of the bond, the link status of the slaves, and how
|
||||
@ -1365,7 +1365,7 @@ been accounted as having caused 1MB of write.
|
||||
In other words: The number of bytes which this process caused to not happen,
|
||||
by truncating pagecache. A task can cause "negative" IO too. If this task
|
||||
truncates some dirty pagecache, some IO which another task has been accounted
|
||||
for (in it's write_bytes) will not be happening. We _could_ just subtract that
|
||||
for (in its write_bytes) will not be happening. We _could_ just subtract that
|
||||
from the truncating task's write_bytes, but there is information loss in doing
|
||||
that.
|
||||
|
||||
|
@ -3,6 +3,6 @@ protocol used by Windows for Workgroups, Windows 95 and Windows NT.
|
||||
Smbfs was inspired by Samba, the program written by Andrew Tridgell
|
||||
that turns any Unix host into a file server for DOS or Windows clients.
|
||||
|
||||
Smbfs is a SMB client, but uses parts of samba for it's operation. For
|
||||
Smbfs is a SMB client, but uses parts of samba for its operation. For
|
||||
more info on samba, including documentation, please go to
|
||||
http://www.samba.org/ and then on to your nearest mirror.
|
||||
|
@ -72,7 +72,7 @@ structure (this is the kernel-side implementation of file
|
||||
descriptors). The freshly allocated file structure is initialized with
|
||||
a pointer to the dentry and a set of file operation member functions.
|
||||
These are taken from the inode data. The open() file method is then
|
||||
called so the specific filesystem implementation can do it's work. You
|
||||
called so the specific filesystem implementation can do its work. You
|
||||
can see that this is another switch performed by the VFS. The file
|
||||
structure is placed into the file descriptor table for the process.
|
||||
|
||||
|
@ -157,7 +157,7 @@ temperature configuration points:
|
||||
|
||||
There are three PWM outputs. The LM85 datasheet suggests that the
|
||||
pwm3 output control both fan3 and fan4. Each PWM can be individually
|
||||
configured and assigned to a zone for it's control value. Each PWM can be
|
||||
configured and assigned to a zone for its control value. Each PWM can be
|
||||
configured individually according to the following options.
|
||||
|
||||
* pwm#_auto_pwm_min - this specifies the PWM value for temp#_auto_temp_off
|
||||
|
@ -402,7 +402,7 @@ for the port of the SoundFusion is supported by the cs461x.c module.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The Live! has a special PCI gameport, which, although it doesn't provide
|
||||
any "Enhanced" stuff like 4DWave and friends, is quite a bit faster than
|
||||
it's ISA counterparts. It also requires special support, hence the
|
||||
its ISA counterparts. It also requires special support, hence the
|
||||
emu10k1-gp.c module for it instead of the normal ns558.c one.
|
||||
|
||||
3.15 SoundBlaster 64 and 128 - ES1370 and ES1371, ESS Solo1 and S3 SonicVibes
|
||||
|
@ -126,7 +126,7 @@ o Tboot then applies an (optional) user-defined launch policy to
|
||||
o Tboot adjusts the e820 table provided by the bootloader to reserve
|
||||
its own location in memory as well as to reserve certain other
|
||||
TXT-related regions.
|
||||
o As part of it's launch, tboot DMA protects all of RAM (using the
|
||||
o As part of its launch, tboot DMA protects all of RAM (using the
|
||||
VT-d PMRs). Thus, the kernel must be booted with 'intel_iommu=on'
|
||||
in order to remove this blanket protection and use VT-d's
|
||||
page-level protection.
|
||||
|
@ -181,7 +181,7 @@ Expressions are listed in decreasing order of precedence.
|
||||
(7) Returns the result of max(/expr/, /expr/).
|
||||
|
||||
An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2
|
||||
respectively for calculations). A menu entry becomes visible when it's
|
||||
respectively for calculations). A menu entry becomes visible when its
|
||||
expression evaluates to 'm' or 'y'.
|
||||
|
||||
There are two types of symbols: constant and non-constant symbols.
|
||||
|
@ -96,7 +96,7 @@ Environment variables for 'silentoldconfig'
|
||||
KCONFIG_NOSILENTUPDATE
|
||||
--------------------------------------------------
|
||||
If this variable has a non-blank value, it prevents silent kernel
|
||||
config udpates (requires explicit updates).
|
||||
config updates (requires explicit updates).
|
||||
|
||||
KCONFIG_AUTOCONFIG
|
||||
--------------------------------------------------
|
||||
|
@ -116,7 +116,7 @@
|
||||
Author: Ingo Molnar, Gadi Oxman and Miguel de Icaza.
|
||||
URL: http://www.linuxjournal.com/article.php?sid=2391
|
||||
Keywords: RAID, MD driver.
|
||||
Description: Linux Journal Kernel Korner article. Here is it's
|
||||
Description: Linux Journal Kernel Korner article. Here is its
|
||||
abstract: "A description of the implementation of the RAID-1,
|
||||
RAID-4 and RAID-5 personalities of the MD device driver in the
|
||||
Linux kernel, providing users with high performance and reliable,
|
||||
@ -127,7 +127,7 @@
|
||||
URL: http://www.linuxjournal.com/article.php?sid=1219
|
||||
Keywords: device driver, module, loading/unloading modules,
|
||||
allocating resources.
|
||||
Description: Linux Journal Kernel Korner article. Here is it's
|
||||
Description: Linux Journal Kernel Korner article. Here is its
|
||||
abstract: "This is the first of a series of four articles
|
||||
co-authored by Alessandro Rubini and Georg Zezchwitz which present
|
||||
a practical approach to writing Linux device drivers as kernel
|
||||
@ -141,7 +141,7 @@
|
||||
Keywords: character driver, init_module, clean_up module,
|
||||
autodetection, mayor number, minor number, file operations,
|
||||
open(), close().
|
||||
Description: Linux Journal Kernel Korner article. Here is it's
|
||||
Description: Linux Journal Kernel Korner article. Here is its
|
||||
abstract: "This article, the second of four, introduces part of
|
||||
the actual code to create custom module implementing a character
|
||||
device driver. It describes the code for module initialization and
|
||||
@ -152,7 +152,7 @@
|
||||
URL: http://www.linuxjournal.com/article.php?sid=1221
|
||||
Keywords: read(), write(), select(), ioctl(), blocking/non
|
||||
blocking mode, interrupt handler.
|
||||
Description: Linux Journal Kernel Korner article. Here is it's
|
||||
Description: Linux Journal Kernel Korner article. Here is its
|
||||
abstract: "This article, the third of four on writing character
|
||||
device drivers, introduces concepts of reading, writing, and using
|
||||
ioctl-calls".
|
||||
@ -161,7 +161,7 @@
|
||||
Author: Alessandro Rubini and Georg v. Zezschwitz.
|
||||
URL: http://www.linuxjournal.com/article.php?sid=1222
|
||||
Keywords: interrupts, irqs, DMA, bottom halves, task queues.
|
||||
Description: Linux Journal Kernel Korner article. Here is it's
|
||||
Description: Linux Journal Kernel Korner article. Here is its
|
||||
abstract: "This is the fourth in a series of articles about
|
||||
writing character device drivers as loadable kernel modules. This
|
||||
month, we further investigate the field of interrupt handling.
|
||||
|
@ -326,7 +326,7 @@ occurs during execution of kp->pre_handler or kp->post_handler,
|
||||
or during single-stepping of the probed instruction, Kprobes calls
|
||||
kp->fault_handler. Any or all handlers can be NULL. If kp->flags
|
||||
is set KPROBE_FLAG_DISABLED, that kp will be registered but disabled,
|
||||
so, it's handlers aren't hit until calling enable_kprobe(kp).
|
||||
so, its handlers aren't hit until calling enable_kprobe(kp).
|
||||
|
||||
NOTE:
|
||||
1. With the introduction of the "symbol_name" field to struct kprobe,
|
||||
|
@ -207,7 +207,7 @@ Tips & Tricks
|
||||
* Drew Scott Daniels observed: "I don't know why, but when I decrease the number
|
||||
of colours that my display uses it consumes less battery power. I've seen
|
||||
this on powerbooks too. I hope that this is a piece of information that
|
||||
might be useful to the Laptop Mode patch or it's users."
|
||||
might be useful to the Laptop Mode patch or its users."
|
||||
|
||||
* In syslog.conf, you can prefix entries with a dash ``-'' to omit syncing the
|
||||
file after every logging. When you're using laptop-mode and your disk doesn't
|
||||
|
@ -263,7 +263,7 @@ static u8 *get_feature_bits(struct device *dev)
|
||||
* Launcher virtual with an offset.
|
||||
*
|
||||
* This can be tough to get your head around, but usually it just means that we
|
||||
* use these trivial conversion functions when the Guest gives us it's
|
||||
* use these trivial conversion functions when the Guest gives us its
|
||||
* "physical" addresses:
|
||||
*/
|
||||
static void *from_guest_phys(unsigned long addr)
|
||||
|
@ -136,7 +136,7 @@ raid_disks != 0.
|
||||
|
||||
Then uninitialized devices can be added with ADD_NEW_DISK. The
|
||||
structure passed to ADD_NEW_DISK must specify the state of the device
|
||||
and it's role in the array.
|
||||
and its role in the array.
|
||||
|
||||
Once started with RUN_ARRAY, uninitialized spares can be added with
|
||||
HOT_ADD_DISK.
|
||||
|
@ -38,7 +38,7 @@ Depending on the exact configuration, translation between the network packet
|
||||
label and the internal LSM security identifier can be time consuming. The
|
||||
NetLabel label mapping cache is a caching mechanism which can be used to
|
||||
sidestep much of this overhead once a mapping has been established. Once the
|
||||
LSM has received a packet, used NetLabel to decode it's security attributes,
|
||||
LSM has received a packet, used NetLabel to decode its security attributes,
|
||||
and translated the security attributes into a LSM internal identifier the LSM
|
||||
can use the NetLabel caching functions to associate the LSM internal
|
||||
identifier with the network packet's label. This means that in the future
|
||||
|
@ -756,7 +756,7 @@ static int enslave(char *master_ifname, char *slave_ifname)
|
||||
*/
|
||||
if (abi_ver < 1) {
|
||||
/* For old ABI, the master needs to be
|
||||
* down before setting it's hwaddr
|
||||
* down before setting its hwaddr
|
||||
*/
|
||||
res = set_if_down(master_ifname, master_flags.ifr_flags);
|
||||
if (res) {
|
||||
|
@ -100,7 +100,7 @@ by the kernel.
|
||||
The destruction of the socket and all associated resources
|
||||
is done by a simple call to close(fd).
|
||||
|
||||
Next I will describe PACKET_MMAP settings and it's constraints,
|
||||
Next I will describe PACKET_MMAP settings and its constraints,
|
||||
also the mapping of the circular buffer in the user process and
|
||||
the use of this buffer.
|
||||
|
||||
@ -432,7 +432,7 @@ TP_STATUS_LOSING : indicates there were packet drops from last time
|
||||
the PACKET_STATISTICS option.
|
||||
|
||||
TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which
|
||||
it's checksum will be done in hardware. So while
|
||||
its checksum will be done in hardware. So while
|
||||
reading the packet we should not try to check the
|
||||
checksum.
|
||||
|
||||
|
@ -8,11 +8,11 @@ Please see overview.txt for a description of the terms used in this text.
|
||||
1. Consumer Regulator Access (static & dynamic drivers)
|
||||
=======================================================
|
||||
|
||||
A consumer driver can get access to it's supply regulator by calling :-
|
||||
A consumer driver can get access to its supply regulator by calling :-
|
||||
|
||||
regulator = regulator_get(dev, "Vcc");
|
||||
|
||||
The consumer passes in it's struct device pointer and power supply ID. The core
|
||||
The consumer passes in its struct device pointer and power supply ID. The core
|
||||
then finds the correct regulator by consulting a machine specific lookup table.
|
||||
If the lookup is successful then this call will return a pointer to the struct
|
||||
regulator that supplies this consumer.
|
||||
@ -34,7 +34,7 @@ usually be called in your device drivers probe() and remove() respectively.
|
||||
2. Regulator Output Enable & Disable (static & dynamic drivers)
|
||||
====================================================================
|
||||
|
||||
A consumer can enable it's power supply by calling:-
|
||||
A consumer can enable its power supply by calling:-
|
||||
|
||||
int regulator_enable(regulator);
|
||||
|
||||
@ -49,7 +49,7 @@ int regulator_is_enabled(regulator);
|
||||
This will return > zero when the regulator is enabled.
|
||||
|
||||
|
||||
A consumer can disable it's supply when no longer needed by calling :-
|
||||
A consumer can disable its supply when no longer needed by calling :-
|
||||
|
||||
int regulator_disable(regulator);
|
||||
|
||||
@ -140,7 +140,7 @@ by calling :-
|
||||
int regulator_set_optimum_mode(struct regulator *regulator, int load_uA);
|
||||
|
||||
This will cause the core to recalculate the total load on the regulator (based
|
||||
on all it's consumers) and change operating mode (if necessary and permitted)
|
||||
on all its consumers) and change operating mode (if necessary and permitted)
|
||||
to best match the current operating load.
|
||||
|
||||
The load_uA value can be determined from the consumers datasheet. e.g.most
|
||||
|
@ -52,7 +52,7 @@ static struct regulator_init_data regulator1_data = {
|
||||
};
|
||||
|
||||
Regulator-1 supplies power to Regulator-2. This relationship must be registered
|
||||
with the core so that Regulator-1 is also enabled when Consumer A enables it's
|
||||
with the core so that Regulator-1 is also enabled when Consumer A enables its
|
||||
supply (Regulator-2). The supply regulator is set by the supply_regulator_dev
|
||||
field below:-
|
||||
|
||||
|
@ -35,16 +35,16 @@ Some terms used in this document:-
|
||||
o Consumer - Electronic device that is supplied power by a regulator.
|
||||
Consumers can be classified into two types:-
|
||||
|
||||
Static: consumer does not change it's supply voltage or
|
||||
Static: consumer does not change its supply voltage or
|
||||
current limit. It only needs to enable or disable it's
|
||||
power supply. It's supply voltage is set by the hardware,
|
||||
power supply. Its supply voltage is set by the hardware,
|
||||
bootloader, firmware or kernel board initialisation code.
|
||||
|
||||
Dynamic: consumer needs to change it's supply voltage or
|
||||
current limit to meet operation demands.
|
||||
|
||||
|
||||
o Power Domain - Electronic circuit that is supplied it's input power by the
|
||||
o Power Domain - Electronic circuit that is supplied its input power by the
|
||||
output power of a regulator, switch or by another power
|
||||
domain.
|
||||
|
||||
|
@ -1289,7 +1289,7 @@ link between a device node and its interrupt parent in
|
||||
the interrupt tree. The value of interrupt-parent is the
|
||||
phandle of the parent node.
|
||||
|
||||
If the interrupt-parent property is not defined for a node, it's
|
||||
If the interrupt-parent property is not defined for a node, its
|
||||
interrupt parent is assumed to be an ancestor in the node's
|
||||
_device tree_ hierarchy.
|
||||
|
||||
|
@ -11,7 +11,7 @@
|
||||
control how the core is synthesized. Historically, the EDK tool would
|
||||
extract the device parameters relevant to device drivers and copy them
|
||||
into an 'xparameters.h' in the form of #define symbols. This tells the
|
||||
device drivers how the IP cores are configured, but it requres the kernel
|
||||
device drivers how the IP cores are configured, but it requires the kernel
|
||||
to be recompiled every time the FPGA bitstream is resynthesized.
|
||||
|
||||
The new approach is to export the parameters into the device tree and
|
||||
|
@ -19,7 +19,7 @@ dump offers several strong, practical advantages:
|
||||
immediately available to the system for normal use.
|
||||
-- After the dump is completed, no further reboots are
|
||||
required; the system will be fully usable, and running
|
||||
in it's normal, production mode on it normal kernel.
|
||||
in its normal, production mode on its normal kernel.
|
||||
|
||||
The above can only be accomplished by coordination with,
|
||||
and assistance from the hypervisor. The procedure is
|
||||
|
@ -657,7 +657,7 @@ here.
|
||||
|
||||
The waiter structure has a "task" field that points to the task that is blocked
|
||||
on the mutex. This field can be NULL the first time it goes through the loop
|
||||
or if the task is a pending owner and had it's mutex stolen. If the "task"
|
||||
or if the task is a pending owner and had its mutex stolen. If the "task"
|
||||
field is NULL then we need to set up the accounting for it.
|
||||
|
||||
Task blocks on mutex
|
||||
|
@ -707,7 +707,7 @@ Changes from 20040920 to 20041018
|
||||
* Integrate patches from Christoph Hellwig: two new helpers common
|
||||
to lpfc_sli_resume_iocb and lpfc_sli_issue_iocb - singificant
|
||||
cleanup of those two functions - the unused SLI_IOCB_USE_TXQ is
|
||||
gone - lpfc_sli_issue_iocb_wait loses it's flags argument
|
||||
gone - lpfc_sli_issue_iocb_wait loses its flags argument
|
||||
totally.
|
||||
* Fix in lpfc_sli.c: we can not store a 5 bit value in a 4-bit
|
||||
field.
|
||||
@ -1028,7 +1028,7 @@ Changes from 20040614 to 20040709
|
||||
* Remove the need for buf_tmo.
|
||||
* Changed ULP_BDE64 to struct ulp_bde64.
|
||||
* Changed ULP_BDE to struct ulp_bde.
|
||||
* Cleanup lpfc_os_return_scsi_cmd() and it's call path.
|
||||
* Cleanup lpfc_os_return_scsi_cmd() and its call path.
|
||||
* Removed lpfc_no_device_delay.
|
||||
* Consolidating lpfc_hba_put_event() into lpfc_put_event().
|
||||
* Removed following attributes and their functionality:
|
||||
|
@ -71,7 +71,7 @@ peters@mylex.com
|
||||
|
||||
Ever since its introduction last October, the BusLogic FlashPoint LT has
|
||||
been problematic for members of the Linux community, in that no Linux
|
||||
drivers have been available for this new Ultra SCSI product. Despite it's
|
||||
drivers have been available for this new Ultra SCSI product. Despite its
|
||||
officially being positioned as a desktop workstation product, and not being
|
||||
particularly well suited for a high performance multitasking operating
|
||||
system like Linux, the FlashPoint LT has been touted by computer system
|
||||
|
@ -12,7 +12,7 @@ The 3180 does not. Otherwise, they are identical.
|
||||
The DTC3x80 does not support DMA but it does have Pseudo-DMA which is
|
||||
supported by the driver.
|
||||
|
||||
It's DTC406 scsi chip is supposedly compatible with the NCR 53C400.
|
||||
Its DTC406 scsi chip is supposedly compatible with the NCR 53C400.
|
||||
It is memory mapped, uses an IRQ, but no dma or io-port. There is
|
||||
internal DMA, between SCSI bus and an on-chip 128-byte buffer. Double
|
||||
buffering is done automagically by the chip. Data is transferred
|
||||
|
@ -1479,7 +1479,7 @@ Wide16 SCSI.
|
||||
Enabling serial NVRAM support enables detection of the serial NVRAM included
|
||||
on Symbios and some Symbios compatible host adaptors, and Tekram boards. The
|
||||
serial NVRAM is used by Symbios and Tekram to hold set up parameters for the
|
||||
host adaptor and it's attached drives.
|
||||
host adaptor and its attached drives.
|
||||
|
||||
The Symbios NVRAM also holds data on the boot order of host adaptors in a
|
||||
system with more than one host adaptor. This enables the order of scanning
|
||||
|
@ -40,7 +40,7 @@ behavior looks very much the same as st to the userspace applications.
|
||||
|
||||
History
|
||||
-------
|
||||
In the first place, osst shared it's identity very much with st. That meant
|
||||
In the first place, osst shared its identity very much with st. That meant
|
||||
that it used the same kernel structures and the same device node as st.
|
||||
So you could only have either of them being present in the kernel. This has
|
||||
been fixed by registering an own device, now.
|
||||
|
@ -70,7 +70,7 @@ Overview:
|
||||
up to an administrative entity controlling the vport. For example,
|
||||
if vports are to be associated with virtual machines, a XEN mgmt
|
||||
utility would be responsible for creating wwpn/wwnn's for the vport,
|
||||
using it's own naming authority and OUI. (Note: it already does this
|
||||
using its own naming authority and OUI. (Note: it already does this
|
||||
for virtual MAC addresses).
|
||||
|
||||
|
||||
@ -81,7 +81,7 @@ Device Trees and Vport Objects:
|
||||
with rports and scsi target objects underneath it. Currently the FC
|
||||
transport creates the vport object and places it under the scsi_host
|
||||
object corresponding to the physical adapter. The LLDD will allocate
|
||||
a new scsi_host for the vport and link it's object under the vport.
|
||||
a new scsi_host for the vport and link its object under the vport.
|
||||
The remainder of the tree under the vports scsi_host is the same
|
||||
as the non-NPIV case. The transport is written currently to easily
|
||||
allow the parent of the vport to be something other than the scsi_host.
|
||||
|
@ -687,7 +687,7 @@ maintain the driver code.
|
||||
Enabling serial NVRAM support enables detection of the serial NVRAM included
|
||||
on Symbios and some Symbios compatible host adaptors, and Tekram boards. The
|
||||
serial NVRAM is used by Symbios and Tekram to hold set up parameters for the
|
||||
host adaptor and it's attached drives.
|
||||
host adaptor and its attached drives.
|
||||
|
||||
The Symbios NVRAM also holds data on the boot order of host adaptors in a
|
||||
system with more than one host adaptor. This information is no longer used
|
||||
|
@ -188,8 +188,8 @@ The WM8731 output mixer has 3 inputs (sources)
|
||||
3. Mic Sidetone Input
|
||||
|
||||
Each input in this example has a kcontrol associated with it (defined in example
|
||||
above) and is connected to the output mixer via it's kcontrol name. We can now
|
||||
connect the destination widget (wrt audio signal) with it's source widgets.
|
||||
above) and is connected to the output mixer via its kcontrol name. We can now
|
||||
connect the destination widget (wrt audio signal) with its source widgets.
|
||||
|
||||
/* output mixer */
|
||||
{"Output Mixer", "Line Bypass Switch", "Line Input"},
|
||||
|
@ -67,7 +67,7 @@ static struct snd_soc_dai_link corgi_dai = {
|
||||
.ops = &corgi_ops,
|
||||
};
|
||||
|
||||
struct snd_soc_card then sets up the machine with it's DAIs. e.g.
|
||||
struct snd_soc_card then sets up the machine with its DAIs. e.g.
|
||||
|
||||
/* corgi audio machine driver */
|
||||
static struct snd_soc_card snd_soc_corgi = {
|
||||
|
@ -33,7 +33,7 @@ features :-
|
||||
and machines.
|
||||
|
||||
* Easy I2S/PCM audio interface setup between codec and SoC. Each SoC
|
||||
interface and codec registers it's audio interface capabilities with the
|
||||
interface and codec registers its audio interface capabilities with the
|
||||
core and are subsequently matched and configured when the application
|
||||
hardware parameters are known.
|
||||
|
||||
|
@ -54,12 +54,12 @@ Getting sparse
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
You can get latest released versions from the Sparse homepage at
|
||||
http://www.kernel.org/pub/linux/kernel/people/josh/sparse/
|
||||
https://sparse.wiki.kernel.org/index.php/Main_Page
|
||||
|
||||
Alternatively, you can get snapshots of the latest development version
|
||||
of sparse using git to clone..
|
||||
|
||||
git://git.kernel.org/pub/scm/linux/kernel/git/josh/sparse.git
|
||||
git://git.kernel.org/pub/scm/devel/sparse/sparse.git
|
||||
|
||||
DaveJ has hourly generated tarballs of the git tree available at..
|
||||
|
||||
|
@ -125,7 +125,7 @@ versions of the sysfs interface.
|
||||
- Block
|
||||
The converted block subsystem at /sys/class/block or
|
||||
/sys/subsystem/block will contain the links for disks and partitions
|
||||
at the same level, never in a hierarchy. Assuming the block subsytem to
|
||||
at the same level, never in a hierarchy. Assuming the block subsystem to
|
||||
contain only disks and not partition devices in the same flat list is
|
||||
a bug in the application.
|
||||
|
||||
|
@ -239,7 +239,7 @@ subsystem's filter file.
|
||||
|
||||
For convenience, filters for every event in a subsystem can be set or
|
||||
cleared as a group by writing a filter expression into the filter file
|
||||
at the root of the subsytem. Note however, that if a filter for any
|
||||
at the root of the subsystem. Note however, that if a filter for any
|
||||
event within the subsystem lacks a field specified in the subsystem
|
||||
filter, or if the filter can't be applied for any other reason, the
|
||||
filter for that event will retain its previous setting. This can
|
||||
@ -251,7 +251,7 @@ fields can be guaranteed to propagate successfully to all events.
|
||||
Here are a few subsystem filter examples that also illustrate the
|
||||
above points:
|
||||
|
||||
Clear the filters on all events in the sched subsytem:
|
||||
Clear the filters on all events in the sched subsystem:
|
||||
|
||||
# cd /sys/kernel/debug/tracing/events/sched
|
||||
# echo 0 > filter
|
||||
@ -261,7 +261,7 @@ none
|
||||
none
|
||||
|
||||
Set a filter using only common fields for all events in the sched
|
||||
subsytem (all events end up with the same filter):
|
||||
subsystem (all events end up with the same filter):
|
||||
|
||||
# cd /sys/kernel/debug/tracing/events/sched
|
||||
# echo common_pid == 0 > filter
|
||||
@ -271,7 +271,7 @@ common_pid == 0
|
||||
common_pid == 0
|
||||
|
||||
Attempt to set a filter using a non-common field for all events in the
|
||||
sched subsytem (all events but those that have a prev_pid field retain
|
||||
sched subsystem (all events but those that have a prev_pid field retain
|
||||
their old filters):
|
||||
|
||||
# cd /sys/kernel/debug/tracing/events/sched
|
||||
|
@ -381,7 +381,7 @@ descriptor that gives us the status of the transfer, its identification
|
||||
we issue another URB to read into the destination buffer the chunk of
|
||||
data coming out of the remote endpoint. Done, wait for the next guy. The
|
||||
callbacks for the URBs issued from here are the ones that will declare
|
||||
the xfer complete at some point and call it's callback.
|
||||
the xfer complete at some point and call its callback.
|
||||
|
||||
Seems simple, but the implementation is not trivial.
|
||||
|
||||
|
@ -45,7 +45,7 @@ most general to most specific:
|
||||
to establish the task policy for a child task exec()'d from an
|
||||
executable image that has no awareness of memory policy. See the
|
||||
MEMORY POLICY APIS section, below, for an overview of the system call
|
||||
that a task may use to set/change it's task/process policy.
|
||||
that a task may use to set/change its task/process policy.
|
||||
|
||||
In a multi-threaded task, task policies apply only to the thread
|
||||
[Linux kernel task] that installs the policy and any threads
|
||||
@ -301,7 +301,7 @@ decrement this reference count, respectively. mpol_put() will only free
|
||||
the structure back to the mempolicy kmem cache when the reference count
|
||||
goes to zero.
|
||||
|
||||
When a new memory policy is allocated, it's reference count is initialized
|
||||
When a new memory policy is allocated, its reference count is initialized
|
||||
to '1', representing the reference held by the task that is installing the
|
||||
new policy. When a pointer to a memory policy structure is stored in another
|
||||
structure, another reference is added, as the task's reference will be dropped
|
||||
|
@ -25,7 +25,7 @@ When a w1 master driver registers with the w1 subsystem, the following occurs:
|
||||
- sysfs entries for that w1 master are created
|
||||
- the w1 bus is periodically searched for new slave devices
|
||||
|
||||
When a device is found on the bus, w1 core checks if driver for it's family is
|
||||
When a device is found on the bus, w1 core checks if driver for its family is
|
||||
loaded. If so, the family driver is attached to the slave.
|
||||
If there is no driver for the family, default one is assigned, which allows to perform
|
||||
almost any kind of operations. Each logical operation is a transaction
|
||||
|
@ -2701,16 +2701,12 @@ F: Documentation/timers/hpet.txt
|
||||
F: drivers/char/hpet.c
|
||||
F: include/linux/hpet.h
|
||||
|
||||
HPET: i386
|
||||
M: "Venkatesh Pallipadi (Venki)" <venkatesh.pallipadi@intel.com>
|
||||
HPET: x86
|
||||
M: "Venkatesh Pallipadi (Venki)" <venki@google.com>
|
||||
S: Maintained
|
||||
F: arch/x86/kernel/hpet.c
|
||||
F: arch/x86/include/asm/hpet.h
|
||||
|
||||
HPET: x86_64
|
||||
M: Vojtech Pavlik <vojtech@suse.cz>
|
||||
S: Maintained
|
||||
|
||||
HPET: ACPI
|
||||
M: Bob Picco <bob.picco@hp.com>
|
||||
S: Maintained
|
||||
|
@ -77,7 +77,7 @@ register struct thread_info *__current_thread_info __asm__("$8");
|
||||
#define TIF_UAC_NOPRINT 10 /* see sysinfo.h */
|
||||
#define TIF_UAC_NOFIX 11
|
||||
#define TIF_UAC_SIGBUS 12
|
||||
#define TIF_MEMDIE 13
|
||||
#define TIF_MEMDIE 13 /* is terminating due to OOM killer */
|
||||
#define TIF_RESTORE_SIGMASK 14 /* restore signal mask in do_signal */
|
||||
#define TIF_FREEZE 16 /* is freezing for suspend */
|
||||
|
||||
|
@ -141,7 +141,7 @@ extern void vfp_flush_hwstate(struct thread_info *);
|
||||
#define TIF_SYSCALL_TRACE 8
|
||||
#define TIF_POLLING_NRFLAG 16
|
||||
#define TIF_USING_IWMMXT 17
|
||||
#define TIF_MEMDIE 18
|
||||
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
|
||||
#define TIF_FREEZE 19
|
||||
#define TIF_RESTORE_SIGMASK 20
|
||||
|
||||
|
@ -241,7 +241,7 @@ static struct clk clk_hsmmc = {
|
||||
|
||||
/* i2s_eplldiv
|
||||
*
|
||||
* This clock is the output from the I2S divisor of ESYSCLK, and is seperate
|
||||
* This clock is the output from the I2S divisor of ESYSCLK, and is separate
|
||||
* from the mux that comes after it (cannot merge into one single clock)
|
||||
*/
|
||||
|
||||
|
@ -107,7 +107,7 @@ extern void s3c_gpiolib_add(struct s3c_gpio_chip *chip);
|
||||
* others = Special functions (dependant on bank)
|
||||
*
|
||||
* Note, since the code to deal with the case where there are two control
|
||||
* registers instead of one, we do not have a seperate set of function
|
||||
* registers instead of one, we do not have a separate set of function
|
||||
* (samsung_gpiolib_add_4bit2_chips)for each case.
|
||||
*/
|
||||
extern void samsung_gpiolib_add_4bit_chips(struct s3c_gpio_chip *chip,
|
||||
|
@ -81,7 +81,7 @@ static inline struct thread_info *current_thread_info(void)
|
||||
TIF_NEED_RESCHED */
|
||||
#define TIF_BREAKPOINT 4 /* enter monitor mode on return */
|
||||
#define TIF_SINGLE_STEP 5 /* single step in progress */
|
||||
#define TIF_MEMDIE 6
|
||||
#define TIF_MEMDIE 6 /* is terminating due to OOM killer */
|
||||
#define TIF_RESTORE_SIGMASK 7 /* restore signal mask in do_signal */
|
||||
#define TIF_CPU_GOING_TO_SLEEP 8 /* CPU is entering sleep 0 mode */
|
||||
#define TIF_NOTIFY_RESUME 9 /* callback before returning to user */
|
||||
|
@ -98,7 +98,7 @@ static inline struct thread_info *current_thread_info(void)
|
||||
#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
|
||||
#define TIF_POLLING_NRFLAG 3 /* true if poll_idle() is polling
|
||||
TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 4
|
||||
#define TIF_MEMDIE 4 /* is terminating due to OOM killer */
|
||||
#define TIF_RESTORE_SIGMASK 5 /* restore signal mask in do_signal() */
|
||||
#define TIF_FREEZE 6 /* is freezing for suspend */
|
||||
#define TIF_IRQ_SYNC 7 /* sync pipeline stage */
|
||||
|
@ -85,7 +85,7 @@ struct thread_info {
|
||||
#define TIF_NEED_RESCHED 3 /* rescheduling necessary */
|
||||
#define TIF_RESTORE_SIGMASK 9 /* restore signal mask in do_signal() */
|
||||
#define TIF_POLLING_NRFLAG 16 /* true if poll_idle() is polling TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 17
|
||||
#define TIF_MEMDIE 17 /* is terminating due to OOM killer */
|
||||
#define TIF_FREEZE 18 /* is freezing for suspend */
|
||||
|
||||
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
|
||||
|
@ -113,7 +113,7 @@ register struct thread_info *__current_thread_info asm("gr15");
|
||||
#define TIF_SINGLESTEP 4 /* restore singlestep on return to user mode */
|
||||
#define TIF_RESTORE_SIGMASK 5 /* restore signal mask in do_signal() */
|
||||
#define TIF_POLLING_NRFLAG 16 /* true if poll_idle() is polling TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 17 /* OOM killer killed process */
|
||||
#define TIF_MEMDIE 17 /* is terminating due to OOM killer */
|
||||
#define TIF_FREEZE 18 /* freezing for suspend */
|
||||
|
||||
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
|
||||
|
@ -87,7 +87,7 @@ static inline struct thread_info *current_thread_info(void)
|
||||
#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
|
||||
#define TIF_POLLING_NRFLAG 3 /* true if poll_idle() is polling
|
||||
TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 4
|
||||
#define TIF_MEMDIE 4 /* is terminating due to OOM killer */
|
||||
#define TIF_RESTORE_SIGMASK 5 /* restore signal mask in do_signal() */
|
||||
#define TIF_NOTIFY_RESUME 6 /* callback before returning to user */
|
||||
#define TIF_FREEZE 16 /* is freezing for suspend */
|
||||
|
@ -102,7 +102,7 @@ struct thread_info {
|
||||
#define TIF_SINGLESTEP 4 /* restore singlestep on return to user mode */
|
||||
#define TIF_NOTIFY_RESUME 6 /* resumption notification requested */
|
||||
#define TIF_POLLING_NRFLAG 16 /* true if poll_idle() is polling TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 17
|
||||
#define TIF_MEMDIE 17 /* is terminating due to OOM killer */
|
||||
#define TIF_MCA_INIT 18 /* this task is processing MCA or INIT */
|
||||
#define TIF_DB_DISABLED 19 /* debug trap disabled for fsyscall */
|
||||
#define TIF_FREEZE 20 /* is freezing for suspend */
|
||||
|
@ -142,7 +142,7 @@ static inline unsigned int get_thread_fault_code(void)
|
||||
#define TIF_RESTORE_SIGMASK 8 /* restore signal mask in do_signal() */
|
||||
#define TIF_USEDFPU 16 /* FPU was used by this task this quantum (SMP) */
|
||||
#define TIF_POLLING_NRFLAG 17 /* true if poll_idle() is polling TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 18 /* OOM killer killed process */
|
||||
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
|
||||
#define TIF_FREEZE 19 /* is freezing for suspend */
|
||||
|
||||
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
|
||||
|
@ -65,7 +65,7 @@ struct thread_info {
|
||||
#define TIF_NEED_RESCHED 7 /* rescheduling necessary */
|
||||
#define TIF_DELAYED_TRACE 14 /* single step a syscall */
|
||||
#define TIF_SYSCALL_TRACE 15 /* syscall trace active */
|
||||
#define TIF_MEMDIE 16
|
||||
#define TIF_MEMDIE 16 /* is terminating due to OOM killer */
|
||||
#define TIF_FREEZE 17 /* thread is freezing for suspend */
|
||||
|
||||
#endif /* _ASM_M68K_THREAD_INFO_H */
|
||||
|
@ -85,7 +85,7 @@ static inline struct thread_info *current_thread_info(void)
|
||||
#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
|
||||
#define TIF_POLLING_NRFLAG 3 /* true if poll_idle() is polling
|
||||
TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 4
|
||||
#define TIF_MEMDIE 4 /* is terminating due to OOM killer */
|
||||
#define TIF_FREEZE 16 /* is freezing for suspend */
|
||||
|
||||
/* as above, but as bit values */
|
||||
|
@ -122,7 +122,7 @@ static inline struct thread_info *current_thread_info(void)
|
||||
/* restore singlestep on return to user mode */
|
||||
#define TIF_SINGLESTEP 4
|
||||
#define TIF_IRET 5 /* return with iret */
|
||||
#define TIF_MEMDIE 6
|
||||
#define TIF_MEMDIE 6 /* is terminating due to OOM killer */
|
||||
#define TIF_SYSCALL_AUDIT 9 /* syscall auditing active */
|
||||
#define TIF_SECCOMP 10 /* secure computing */
|
||||
#define TIF_FREEZE 14 /* Freezing for suspend */
|
||||
|
@ -112,7 +112,7 @@ register struct thread_info *__current_thread_info __asm__("$28");
|
||||
#define TIF_RESTORE_SIGMASK 9 /* restore signal mask in do_signal() */
|
||||
#define TIF_USEDFPU 16 /* FPU was used by this task this quantum (SMP) */
|
||||
#define TIF_POLLING_NRFLAG 17 /* true if poll_idle() is polling TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 18
|
||||
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
|
||||
#define TIF_FREEZE 19
|
||||
#define TIF_FIXADE 20 /* Fix address errors in software */
|
||||
#define TIF_LOGADE 21 /* Log address errors to syslog */
|
||||
|
@ -253,7 +253,7 @@ void __init init_bcm1480_irqs(void)
|
||||
* On the second cpu, everything is set to IP5, which is
|
||||
* ignored, EXCEPT the mailbox interrupt. That one is
|
||||
* set to IP[2] so it is handled. This is needed so we
|
||||
* can do cross-cpu function calls, as requred by SMP
|
||||
* can do cross-cpu function calls, as required by SMP
|
||||
*/
|
||||
|
||||
#define IMR_IP2_VAL K_BCM1480_INT_MAP_I0
|
||||
|
@ -236,7 +236,7 @@ void __init init_sb1250_irqs(void)
|
||||
* On the second cpu, everything is set to IP5, which is
|
||||
* ignored, EXCEPT the mailbox interrupt. That one is
|
||||
* set to IP[2] so it is handled. This is needed so we
|
||||
* can do cross-cpu function calls, as requred by SMP
|
||||
* can do cross-cpu function calls, as required by SMP
|
||||
*/
|
||||
|
||||
#define IMR_IP2_VAL K_INT_MAP_I0
|
||||
|
@ -148,7 +148,7 @@ static inline unsigned long current_stack_pointer(void)
|
||||
#define TIF_SINGLESTEP 4 /* restore singlestep on return to user mode */
|
||||
#define TIF_RESTORE_SIGMASK 5 /* restore signal mask in do_signal() */
|
||||
#define TIF_POLLING_NRFLAG 16 /* true if poll_idle() is polling TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 17 /* OOM killer killed process */
|
||||
#define TIF_MEMDIE 17 /* is terminating due to OOM killer */
|
||||
#define TIF_FREEZE 18 /* freezing for suspend */
|
||||
|
||||
#define _TIF_SYSCALL_TRACE +(1 << TIF_SYSCALL_TRACE)
|
||||
|
@ -56,7 +56,7 @@ struct thread_info {
|
||||
#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
|
||||
#define TIF_POLLING_NRFLAG 3 /* true if poll_idle() is polling TIF_NEED_RESCHED */
|
||||
#define TIF_32BIT 4 /* 32 bit binary */
|
||||
#define TIF_MEMDIE 5
|
||||
#define TIF_MEMDIE 5 /* is terminating due to OOM killer */
|
||||
#define TIF_RESTORE_SIGMASK 6 /* restore saved signal mask */
|
||||
#define TIF_FREEZE 7 /* is freezing for suspend */
|
||||
#define TIF_NOTIFY_RESUME 8 /* callback before returning to user */
|
||||
|
@ -104,7 +104,7 @@ static inline struct thread_info *current_thread_info(void)
|
||||
#define TIF_PERFMON_CTXSW 6 /* perfmon needs ctxsw calls */
|
||||
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
|
||||
#define TIF_SINGLESTEP 8 /* singlestepping active */
|
||||
#define TIF_MEMDIE 9
|
||||
#define TIF_MEMDIE 9 /* is terminating due to OOM killer */
|
||||
#define TIF_SECCOMP 10 /* secure computing */
|
||||
#define TIF_RESTOREALL 11 /* Restore all regs (implies NOERROR) */
|
||||
#define TIF_NOERROR 12 /* Force successful syscall return */
|
||||
|
@ -69,10 +69,10 @@ void __init wii_memory_fixups(void)
|
||||
|
||||
/*
|
||||
* This is part of a workaround to allow the use of two
|
||||
* discontiguous RAM ranges on the Wii, even if this is
|
||||
* discontinuous RAM ranges on the Wii, even if this is
|
||||
* currently unsupported on 32-bit PowerPC Linux.
|
||||
*
|
||||
* We coealesce the two memory ranges of the Wii into a
|
||||
* We coalesce the two memory ranges of the Wii into a
|
||||
* single range, then create a reservation for the "hole"
|
||||
* between both ranges.
|
||||
*/
|
||||
|
@ -97,7 +97,7 @@ static inline struct thread_info *current_thread_info(void)
|
||||
#define TIF_POLLING_NRFLAG 16 /* true if poll_idle() is polling
|
||||
TIF_NEED_RESCHED */
|
||||
#define TIF_31BIT 17 /* 32bit process */
|
||||
#define TIF_MEMDIE 18
|
||||
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
|
||||
#define TIF_RESTORE_SIGMASK 19 /* restore signal mask in do_signal() */
|
||||
#define TIF_FREEZE 20 /* thread is freezing for suspend */
|
||||
|
||||
|
@ -92,7 +92,7 @@ register struct thread_info *__current_thread_info __asm__("r28");
|
||||
#define TIF_RESTORE_SIGMASK 9 /* restore signal mask in do_signal() */
|
||||
#define TIF_POLLING_NRFLAG 17 /* true if poll_idle() is polling
|
||||
TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 18
|
||||
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
|
||||
|
||||
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
|
||||
#define _TIF_SIGPENDING (1<<TIF_SIGPENDING)
|
||||
|
@ -121,7 +121,7 @@ extern void init_thread_xstate(void);
|
||||
#define TIF_NOTIFY_RESUME 7 /* callback before returning to user */
|
||||
#define TIF_SYSCALL_TRACEPOINT 8 /* for ftrace syscall instrumentation */
|
||||
#define TIF_POLLING_NRFLAG 17 /* true if poll_idle() is polling TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 18
|
||||
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
|
||||
#define TIF_FREEZE 19 /* Freezing for suspend */
|
||||
|
||||
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
|
||||
|
@ -132,7 +132,7 @@ BTFIXUPDEF_CALL(void, free_thread_info, struct thread_info *)
|
||||
* this quantum (SMP) */
|
||||
#define TIF_POLLING_NRFLAG 9 /* true if poll_idle() is polling
|
||||
* TIF_NEED_RESCHED */
|
||||
#define TIF_MEMDIE 10
|
||||
#define TIF_MEMDIE 10 /* is terminating due to OOM killer */
|
||||
#define TIF_FREEZE 11 /* is freezing for suspend */
|
||||
|
||||
/* as above, but as bit values */
|
||||
|
@ -223,7 +223,7 @@ register struct thread_info *current_thread_info_reg asm("g6");
|
||||
* an immediate value in instructions such as andcc.
|
||||
*/
|
||||
/* flag bit 12 is available */
|
||||
#define TIF_MEMDIE 13
|
||||
#define TIF_MEMDIE 13 /* is terminating due to OOM killer */
|
||||
#define TIF_POLLING_NRFLAG 14
|
||||
#define TIF_FREEZE 15 /* is freezing for suspend */
|
||||
|
||||
|
@ -19,7 +19,6 @@ static irqreturn_t line_interrupt(int irq, void *data)
|
||||
{
|
||||
struct chan *chan = data;
|
||||
struct line *line = chan->line;
|
||||
struct tty_struct *tty;
|
||||
|
||||
if (line)
|
||||
chan_interrupt(&line->chan_list, &line->task, line->tty, irq);
|
||||
|
@ -3,11 +3,8 @@
|
||||
|
||||
#include "sysdep/system.h"
|
||||
|
||||
extern void *switch_to(void *prev, void *next, void *last);
|
||||
|
||||
extern int get_signals(void);
|
||||
extern int set_signals(int enable);
|
||||
extern int get_signals(void);
|
||||
extern void block_signals(void);
|
||||
extern void unblock_signals(void);
|
||||
|
||||
|
@ -63,10 +63,9 @@ static inline struct thread_info *current_thread_info(void)
|
||||
#define TIF_SIGPENDING 1 /* signal pending */
|
||||
#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
|
||||
#define TIF_POLLING_NRFLAG 3 /* true if poll_idle() is polling
|
||||
* TIF_NEED_RESCHED
|
||||
*/
|
||||
#define TIF_RESTART_BLOCK 4
|
||||
#define TIF_MEMDIE 5
|
||||
* TIF_NEED_RESCHED */
|
||||
#define TIF_RESTART_BLOCK 4
|
||||
#define TIF_MEMDIE 5 /* is terminating due to OOM killer */
|
||||
#define TIF_SYSCALL_AUDIT 6
|
||||
#define TIF_RESTORE_SIGMASK 7
|
||||
#define TIF_FREEZE 16 /* is freezing for suspend */
|
||||
|
@ -10,7 +10,7 @@
|
||||
#include "sysdep/syscalls.h"
|
||||
|
||||
extern int syscall_table_size;
|
||||
#define NR_syscalls (syscall_table_size / sizeof(void *))
|
||||
#define NR_SYSCALLS (syscall_table_size / sizeof(void *))
|
||||
|
||||
void handle_syscall(struct uml_pt_regs *r)
|
||||
{
|
||||
@ -30,7 +30,7 @@ void handle_syscall(struct uml_pt_regs *r)
|
||||
* in case it's a compiler bug.
|
||||
*/
|
||||
syscall = UPT_SYSCALL_NR(r);
|
||||
if ((syscall >= NR_syscalls) || (syscall < 0))
|
||||
if ((syscall >= NR_SYSCALLS) || (syscall < 0))
|
||||
result = -ENOSYS;
|
||||
else result = EXECUTE_SYSCALL(syscall, regs);
|
||||
|
||||
|
@ -75,6 +75,8 @@ typedef struct user_i387_struct elf_fpregset_t;
|
||||
pr_reg[16] = PT_REGS_SS(regs); \
|
||||
} while (0);
|
||||
|
||||
struct task_struct;
|
||||
|
||||
extern int elf_core_copy_fpregs(struct task_struct *t, elf_fpregset_t *fpu);
|
||||
|
||||
#define ELF_CORE_COPY_FPREGS(t, fpu) elf_core_copy_fpregs(t, fpu)
|
||||
|
@ -95,6 +95,8 @@ typedef struct user_i387_struct elf_fpregset_t;
|
||||
(pr_reg)[25] = 0; \
|
||||
(pr_reg)[26] = 0;
|
||||
|
||||
struct task_struct;
|
||||
|
||||
extern int elf_core_copy_fpregs(struct task_struct *t, elf_fpregset_t *fpu);
|
||||
|
||||
#define ELF_CORE_COPY_FPREGS(t, fpu) elf_core_copy_fpregs(t, fpu)
|
||||
|
@ -6,6 +6,7 @@
|
||||
|
||||
#include <linux/personality.h>
|
||||
#include <linux/ptrace.h>
|
||||
#include <linux/kernel.h>
|
||||
#include <asm/unistd.h>
|
||||
#include <asm/uaccess.h>
|
||||
#include <asm/ucontext.h>
|
||||
@ -165,8 +166,6 @@ struct rt_sigframe
|
||||
struct _fpstate fpstate;
|
||||
};
|
||||
|
||||
#define round_down(m, n) (((m) / (n)) * (n))
|
||||
|
||||
int setup_signal_stack_si(unsigned long stack_top, int sig,
|
||||
struct k_sigaction *ka, struct pt_regs * regs,
|
||||
siginfo_t *info, sigset_t *set)
|
||||
|
@ -105,7 +105,7 @@ do { \
|
||||
|
||||
/*
|
||||
* Generate a percpu add to memory instruction and optimize code
|
||||
* if a one is added or subtracted.
|
||||
* if one is added or subtracted.
|
||||
*/
|
||||
#define percpu_add_op(var, val) \
|
||||
do { \
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user