You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'linus' into x86/quirks
Conflicts: arch/x86/kernel/early-quirks.c
This commit is contained in:
@@ -251,8 +251,6 @@ mono.txt
|
||||
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
||||
moxa-smartio
|
||||
- file with info on installing/using Moxa multiport serial driver.
|
||||
mtrr.txt
|
||||
- how to use PPro Memory Type Range Registers to increase performance.
|
||||
mutex-design.txt
|
||||
- info on the generic mutex subsystem.
|
||||
namespaces/
|
||||
|
||||
@@ -337,7 +337,7 @@ With scatterlists, you use the resulting mapping like this:
|
||||
int i, count = dma_map_sg(dev, sglist, nents, direction);
|
||||
struct scatterlist *sg;
|
||||
|
||||
for (i = 0, sg = sglist; i < count; i++, sg++) {
|
||||
for_each_sg(sglist, sg, count, i) {
|
||||
hw_address[i] = sg_dma_address(sg);
|
||||
hw_len[i] = sg_dma_len(sg);
|
||||
}
|
||||
|
||||
@@ -283,6 +283,7 @@ X!Earch/x86/kernel/mca_32.c
|
||||
<chapter id="security">
|
||||
<title>Security Framework</title>
|
||||
!Isecurity/security.c
|
||||
!Esecurity/inode.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="audit">
|
||||
@@ -364,6 +365,10 @@ X!Edrivers/pnp/system.c
|
||||
!Eblock/blk-barrier.c
|
||||
!Eblock/blk-tag.c
|
||||
!Iblock/blk-tag.c
|
||||
!Eblock/blk-integrity.c
|
||||
!Iblock/blktrace.c
|
||||
!Iblock/genhd.c
|
||||
!Eblock/genhd.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="chrdev">
|
||||
|
||||
@@ -145,7 +145,6 @@ usage should require reading the full document.
|
||||
this though and the recommendation to allow only a single
|
||||
interface in STA mode at first!
|
||||
</para>
|
||||
!Finclude/net/mac80211.h ieee80211_if_types
|
||||
!Finclude/net/mac80211.h ieee80211_if_init_conf
|
||||
!Finclude/net/mac80211.h ieee80211_if_conf
|
||||
</chapter>
|
||||
@@ -177,8 +176,7 @@ usage should require reading the full document.
|
||||
<title>functions/definitions</title>
|
||||
!Finclude/net/mac80211.h ieee80211_rx_status
|
||||
!Finclude/net/mac80211.h mac80211_rx_flags
|
||||
!Finclude/net/mac80211.h ieee80211_tx_control
|
||||
!Finclude/net/mac80211.h ieee80211_tx_status_flags
|
||||
!Finclude/net/mac80211.h ieee80211_tx_info
|
||||
!Finclude/net/mac80211.h ieee80211_rx
|
||||
!Finclude/net/mac80211.h ieee80211_rx_irqsafe
|
||||
!Finclude/net/mac80211.h ieee80211_tx_status
|
||||
@@ -189,12 +187,11 @@ usage should require reading the full document.
|
||||
!Finclude/net/mac80211.h ieee80211_ctstoself_duration
|
||||
!Finclude/net/mac80211.h ieee80211_generic_frame_duration
|
||||
!Finclude/net/mac80211.h ieee80211_get_hdrlen_from_skb
|
||||
!Finclude/net/mac80211.h ieee80211_get_hdrlen
|
||||
!Finclude/net/mac80211.h ieee80211_hdrlen
|
||||
!Finclude/net/mac80211.h ieee80211_wake_queue
|
||||
!Finclude/net/mac80211.h ieee80211_stop_queue
|
||||
!Finclude/net/mac80211.h ieee80211_start_queues
|
||||
!Finclude/net/mac80211.h ieee80211_stop_queues
|
||||
!Finclude/net/mac80211.h ieee80211_wake_queues
|
||||
!Finclude/net/mac80211.h ieee80211_stop_queues
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
@@ -230,8 +227,7 @@ usage should require reading the full document.
|
||||
<title>Multiple queues and QoS support</title>
|
||||
<para>TBD</para>
|
||||
!Finclude/net/mac80211.h ieee80211_tx_queue_params
|
||||
!Finclude/net/mac80211.h ieee80211_tx_queue_stats_data
|
||||
!Finclude/net/mac80211.h ieee80211_tx_queue
|
||||
!Finclude/net/mac80211.h ieee80211_tx_queue_stats
|
||||
</chapter>
|
||||
|
||||
<chapter id="AP">
|
||||
|
||||
@@ -210,7 +210,7 @@ over a rather long period of time, but improvements are always welcome!
|
||||
number of updates per grace period.
|
||||
|
||||
9. All RCU list-traversal primitives, which include
|
||||
rcu_dereference(), list_for_each_rcu(), list_for_each_entry_rcu(),
|
||||
rcu_dereference(), list_for_each_entry_rcu(),
|
||||
list_for_each_continue_rcu(), and list_for_each_safe_rcu(),
|
||||
must be either within an RCU read-side critical section or
|
||||
must be protected by appropriate update-side locks. RCU
|
||||
|
||||
@@ -29,9 +29,9 @@ release_referenced() delete()
|
||||
}
|
||||
|
||||
If this list/array is made lock free using RCU as in changing the
|
||||
write_lock() in add() and delete() to spin_lock and changing read_lock
|
||||
in search_and_reference to rcu_read_lock(), the atomic_get in
|
||||
search_and_reference could potentially hold reference to an element which
|
||||
write_lock() in add() and delete() to spin_lock() and changing read_lock()
|
||||
in search_and_reference() to rcu_read_lock(), the atomic_inc() in
|
||||
search_and_reference() could potentially hold reference to an element which
|
||||
has already been deleted from the list/array. Use atomic_inc_not_zero()
|
||||
in this scenario as follows:
|
||||
|
||||
@@ -40,20 +40,20 @@ add() search_and_reference()
|
||||
{ {
|
||||
alloc_object rcu_read_lock();
|
||||
... search_for_element
|
||||
atomic_set(&el->rc, 1); if (atomic_inc_not_zero(&el->rc)) {
|
||||
write_lock(&list_lock); rcu_read_unlock();
|
||||
atomic_set(&el->rc, 1); if (!atomic_inc_not_zero(&el->rc)) {
|
||||
spin_lock(&list_lock); rcu_read_unlock();
|
||||
return FAIL;
|
||||
add_element }
|
||||
... ...
|
||||
write_unlock(&list_lock); rcu_read_unlock();
|
||||
spin_unlock(&list_lock); rcu_read_unlock();
|
||||
} }
|
||||
3. 4.
|
||||
release_referenced() delete()
|
||||
{ {
|
||||
... write_lock(&list_lock);
|
||||
... spin_lock(&list_lock);
|
||||
if (atomic_dec_and_test(&el->rc)) ...
|
||||
call_rcu(&el->head, el_free); delete_element
|
||||
... write_unlock(&list_lock);
|
||||
... spin_unlock(&list_lock);
|
||||
} ...
|
||||
if (atomic_dec_and_test(&el->rc))
|
||||
call_rcu(&el->head, el_free);
|
||||
|
||||
@@ -786,8 +786,6 @@ RCU pointer/list traversal:
|
||||
list_for_each_entry_rcu
|
||||
hlist_for_each_entry_rcu
|
||||
|
||||
list_for_each_rcu (to be deprecated in favor of
|
||||
list_for_each_entry_rcu)
|
||||
list_for_each_continue_rcu (to be deprecated in favor of new
|
||||
list_for_each_entry_continue_rcu)
|
||||
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
If you want to use SELinux, chances are you will want
|
||||
to use the distro-provided policies, or install the
|
||||
latest reference policy release from
|
||||
http://oss.tresys.com/projects/refpolicy
|
||||
|
||||
However, if you want to install a dummy policy for
|
||||
testing, you can do using 'mdp' provided under
|
||||
scripts/selinux. Note that this requires the selinux
|
||||
userspace to be installed - in particular you will
|
||||
need checkpolicy to compile a kernel, and setfiles and
|
||||
fixfiles to label the filesystem.
|
||||
|
||||
1. Compile the kernel with selinux enabled.
|
||||
2. Type 'make' to compile mdp.
|
||||
3. Make sure that you are not running with
|
||||
SELinux enabled and a real policy. If
|
||||
you are, reboot with selinux disabled
|
||||
before continuing.
|
||||
4. Run install_policy.sh:
|
||||
cd scripts/selinux
|
||||
sh install_policy.sh
|
||||
|
||||
Step 4 will create a new dummy policy valid for your
|
||||
kernel, with a single selinux user, role, and type.
|
||||
It will compile the policy, will set your SELINUXTYPE to
|
||||
dummy in /etc/selinux/config, install the compiled policy
|
||||
as 'dummy', and relabel your filesystem.
|
||||
@@ -30,12 +30,18 @@ write_expire (in ms)
|
||||
Similar to read_expire mentioned above, but for writes.
|
||||
|
||||
|
||||
fifo_batch
|
||||
fifo_batch (number of requests)
|
||||
----------
|
||||
|
||||
When a read request expires its deadline, we must move some requests from
|
||||
the sorted io scheduler list to the block device dispatch queue. fifo_batch
|
||||
controls how many requests we move.
|
||||
Requests are grouped into ``batches'' of a particular data direction (read or
|
||||
write) which are serviced in increasing sector order. To limit extra seeking,
|
||||
deadline expiries are only checked between batches. fifo_batch controls the
|
||||
maximum number of requests per batch.
|
||||
|
||||
This parameter tunes the balance between per-request latency and aggregate
|
||||
throughput. When low latency is the primary concern, smaller is better (where
|
||||
a value of 1 yields first-come first-served behaviour). Increasing fifo_batch
|
||||
generally improves throughput, at the cost of latency variation.
|
||||
|
||||
|
||||
writes_starved (number of dispatches)
|
||||
|
||||
@@ -145,8 +145,7 @@ useful for reading photocds.
|
||||
|
||||
To play an audio CD, you should first unmount and remove any data
|
||||
CDROM. Any of the CDROM player programs should then work (workman,
|
||||
workbone, cdplayer, etc.). Lacking anything else, you could use the
|
||||
cdtester program in Documentation/cdrom/sbpcd.
|
||||
workbone, cdplayer, etc.).
|
||||
|
||||
On a few drives, you can read digital audio directly using a program
|
||||
such as cdda2wav. The only types of drive which I've heard support
|
||||
|
||||
@@ -35,11 +35,9 @@ Mailing List
|
||||
------------
|
||||
There is a CPU frequency changing CVS commit and general list where
|
||||
you can report bugs, problems or submit patches. To post a message,
|
||||
send an email to cpufreq@lists.linux.org.uk, to subscribe go to
|
||||
http://lists.linux.org.uk/mailman/listinfo/cpufreq. Previous post to the
|
||||
mailing list are available to subscribers at
|
||||
http://lists.linux.org.uk/mailman/private/cpufreq/.
|
||||
|
||||
send an email to cpufreq@vger.kernel.org, to subscribe go to
|
||||
http://vger.kernel.org/vger-lists.html#cpufreq and follow the
|
||||
instructions there.
|
||||
|
||||
Links
|
||||
-----
|
||||
@@ -50,7 +48,7 @@ how to access the CVS repository:
|
||||
* http://cvs.arm.linux.org.uk/
|
||||
|
||||
the CPUFreq Mailing list:
|
||||
* http://lists.linux.org.uk/mailman/listinfo/cpufreq
|
||||
* http://vger.kernel.org/vger-lists.html#cpufreq
|
||||
|
||||
Clock and voltage scaling for the SA-1100:
|
||||
* http://www.lartmaker.nl/projects/scaling
|
||||
|
||||
@@ -6,6 +6,24 @@ be removed from this file.
|
||||
|
||||
---------------------------
|
||||
|
||||
What: old static regulatory information and ieee80211_regdom module parameter
|
||||
When: 2.6.29
|
||||
Why: The old regulatory infrastructure has been replaced with a new one
|
||||
which does not require statically defined regulatory domains. We do
|
||||
not want to keep static regulatory domains in the kernel due to the
|
||||
the dynamic nature of regulatory law and localization. We kept around
|
||||
the old static definitions for the regulatory domains of:
|
||||
* US
|
||||
* JP
|
||||
* EU
|
||||
and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was
|
||||
set. We also kept around the ieee80211_regdom module parameter in case
|
||||
some applications were relying on it. Changing regulatory domains
|
||||
can now be done instead by using nl80211, as is done with iw.
|
||||
Who: Luis R. Rodriguez <lrodriguez@atheros.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: dev->power.power_state
|
||||
When: July 2007
|
||||
Why: Broken design for runtime control over driver power states, confusing
|
||||
@@ -232,6 +250,9 @@ What (Why):
|
||||
- xt_mark match revision 0
|
||||
(superseded by xt_mark match revision 1)
|
||||
|
||||
- xt_recent: the old ipt_recent proc dir
|
||||
(superseded by /proc/net/xt_recent)
|
||||
|
||||
When: January 2009 or Linux 2.7.0, whichever comes first
|
||||
Why: Superseded by newer revisions or modules
|
||||
Who: Jan Engelhardt <jengelh@computergmbh.de>
|
||||
|
||||
@@ -32,9 +32,9 @@ Mailing list: linux-ext4@vger.kernel.org
|
||||
you will need to merge your changes with the version from e2fsprogs
|
||||
1.41.x.
|
||||
|
||||
- Create a new filesystem using the ext4dev filesystem type:
|
||||
- Create a new filesystem using the ext4 filesystem type:
|
||||
|
||||
# mke2fs -t ext4dev /dev/hda1
|
||||
# mke2fs -t ext4 /dev/hda1
|
||||
|
||||
Or configure an existing ext3 filesystem to support extents and set
|
||||
the test_fs flag to indicate that it's ok for an in-development
|
||||
@@ -47,13 +47,13 @@ Mailing list: linux-ext4@vger.kernel.org
|
||||
|
||||
# tune2fs -I 256 /dev/hda1
|
||||
|
||||
(Note: we currently do not have tools to convert an ext4dev
|
||||
(Note: we currently do not have tools to convert an ext4
|
||||
filesystem back to ext3; so please do not do try this on production
|
||||
filesystems.)
|
||||
|
||||
- Mounting:
|
||||
|
||||
# mount -t ext4dev /dev/hda1 /wherever
|
||||
# mount -t ext4 /dev/hda1 /wherever
|
||||
|
||||
- When comparing performance with other filesystems, remember that
|
||||
ext3/4 by default offers higher data integrity guarantees than most.
|
||||
@@ -177,6 +177,11 @@ barrier=<0|1(*)> This enables/disables the use of write barriers in
|
||||
your disks are battery-backed in one way or another,
|
||||
disabling barriers may safely improve performance.
|
||||
|
||||
inode_readahead=n This tuning parameter controls the maximum
|
||||
number of inode table blocks that ext4's inode
|
||||
table readahead algorithm will pre-read into
|
||||
the buffer cache. The default value is 32 blocks.
|
||||
|
||||
orlov (*) This enables the new Orlov block allocator. It is
|
||||
enabled by default.
|
||||
|
||||
@@ -252,6 +257,7 @@ stripe=n Number of filesystem blocks that mballoc will try
|
||||
delalloc (*) Deferring block allocation until write-out time.
|
||||
nodelalloc Disable delayed allocation. Blocks are allocation
|
||||
when data is copied from user to page cache.
|
||||
|
||||
Data Mode
|
||||
=========
|
||||
There are 3 different data modes:
|
||||
|
||||
@@ -0,0 +1,228 @@
|
||||
============
|
||||
Fiemap Ioctl
|
||||
============
|
||||
|
||||
The fiemap ioctl is an efficient method for userspace to get file
|
||||
extent mappings. Instead of block-by-block mapping (such as bmap), fiemap
|
||||
returns a list of extents.
|
||||
|
||||
|
||||
Request Basics
|
||||
--------------
|
||||
|
||||
A fiemap request is encoded within struct fiemap:
|
||||
|
||||
struct fiemap {
|
||||
__u64 fm_start; /* logical offset (inclusive) at
|
||||
* which to start mapping (in) */
|
||||
__u64 fm_length; /* logical length of mapping which
|
||||
* userspace cares about (in) */
|
||||
__u32 fm_flags; /* FIEMAP_FLAG_* flags for request (in/out) */
|
||||
__u32 fm_mapped_extents; /* number of extents that were
|
||||
* mapped (out) */
|
||||
__u32 fm_extent_count; /* size of fm_extents array (in) */
|
||||
__u32 fm_reserved;
|
||||
struct fiemap_extent fm_extents[0]; /* array of mapped extents (out) */
|
||||
};
|
||||
|
||||
|
||||
fm_start, and fm_length specify the logical range within the file
|
||||
which the process would like mappings for. Extents returned mirror
|
||||
those on disk - that is, the logical offset of the 1st returned extent
|
||||
may start before fm_start, and the range covered by the last returned
|
||||
extent may end after fm_length. All offsets and lengths are in bytes.
|
||||
|
||||
Certain flags to modify the way in which mappings are looked up can be
|
||||
set in fm_flags. If the kernel doesn't understand some particular
|
||||
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
|
||||
fiemap interface to grow in the future but without losing
|
||||
compatibility with old software.
|
||||
|
||||
fm_extent_count specifies the number of elements in the fm_extents[] array
|
||||
that can be used to return extents. If fm_extent_count is zero, then the
|
||||
fm_extents[] array is ignored (no extents will be returned), and the
|
||||
fm_mapped_extents count will hold the number of extents needed in
|
||||
fm_extents[] to hold the file's current mapping. Note that there is
|
||||
nothing to prevent the file from changing between calls to FIEMAP.
|
||||
|
||||
The following flags can be set in fm_flags:
|
||||
|
||||
* FIEMAP_FLAG_SYNC
|
||||
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.
|
||||
|
||||
|
||||
Extent Mapping
|
||||
--------------
|
||||
|
||||
Extent information is returned within the embedded fm_extents array
|
||||
which userspace must allocate along with the fiemap structure. The
|
||||
number of elements in the fiemap_extents[] array should be passed via
|
||||
fm_extent_count. The number of extents mapped by kernel will be
|
||||
returned via fm_mapped_extents. If the number of fiemap_extents
|
||||
allocated is less than would be required to map the requested range,
|
||||
the maximum number of extents that can be mapped in the fm_extent[]
|
||||
array will be returned and fm_mapped_extents will be equal to
|
||||
fm_extent_count. In that case, the last extent in the array will not
|
||||
complete the requested range and will not have the FIEMAP_EXTENT_LAST
|
||||
flag set (see the next section on extent flags).
|
||||
|
||||
Each extent is described by a single fiemap_extent structure as
|
||||
returned in fm_extents.
|
||||
|
||||
struct fiemap_extent {
|
||||
__u64 fe_logical; /* logical offset in bytes for the start of
|
||||
* the extent */
|
||||
__u64 fe_physical; /* physical offset in bytes for the start
|
||||
* of the extent */
|
||||
__u64 fe_length; /* length in bytes for the extent */
|
||||
__u64 fe_reserved64[2];
|
||||
__u32 fe_flags; /* FIEMAP_EXTENT_* flags for this extent */
|
||||
__u32 fe_reserved[3];
|
||||
};
|
||||
|
||||
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
|
||||
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
|
||||
FIEMAP_EXTENT_MERGED, adjacent extents will not be merged.
|
||||
|
||||
The fe_flags field contains flags which describe the extent returned.
|
||||
A special flag, FIEMAP_EXTENT_LAST is always set on the last extent in
|
||||
the file so that the process making fiemap calls can determine when no
|
||||
more extents are available, without having to call the ioctl again.
|
||||
|
||||
Some flags are intentionally vague and will always be set in the
|
||||
presence of other more specific flags. This way a program looking for
|
||||
a general property does not have to know all existing and future flags
|
||||
which imply that property.
|
||||
|
||||
For example, if FIEMAP_EXTENT_DATA_INLINE or FIEMAP_EXTENT_DATA_TAIL
|
||||
are set, FIEMAP_EXTENT_NOT_ALIGNED will also be set. A program looking
|
||||
for inline or tail-packed data can key on the specific flag. Software
|
||||
which simply cares not to try operating on non-aligned extents
|
||||
however, can just key on FIEMAP_EXTENT_NOT_ALIGNED, and not have to
|
||||
worry about all present and future flags which might imply unaligned
|
||||
data. Note that the opposite is not true - it would be valid for
|
||||
FIEMAP_EXTENT_NOT_ALIGNED to appear alone.
|
||||
|
||||
* FIEMAP_EXTENT_LAST
|
||||
This is the last extent in the file. A mapping attempt past this
|
||||
extent will return nothing.
|
||||
|
||||
* FIEMAP_EXTENT_UNKNOWN
|
||||
The location of this extent is currently unknown. This may indicate
|
||||
the data is stored on an inaccessible volume or that no storage has
|
||||
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
|
||||
physical location has not been allocated yet.
|
||||
|
||||
* FIEMAP_EXTENT_ENCODED
|
||||
This extent does not consist of plain filesystem blocks but is
|
||||
encoded (e.g. encrypted or compressed). Reading the data in this
|
||||
extent via I/O to the block device will have undefined results.
|
||||
|
||||
Note that it is *always* undefined to try to update the data
|
||||
in-place by writing to the indicated location without the
|
||||
assistance of the filesystem, or to access the data using the
|
||||
information returned by the FIEMAP interface while the filesystem
|
||||
is mounted. In other words, user applications may only read the
|
||||
extent data via I/O to the block device while the filesystem is
|
||||
unmounted, and then only if the FIEMAP_EXTENT_ENCODED flag is
|
||||
clear; user applications must not try reading or writing to the
|
||||
filesystem via the block device under any other circumstances.
|
||||
|
||||
* FIEMAP_EXTENT_DATA_ENCRYPTED
|
||||
- This will also set FIEMAP_EXTENT_ENCODED
|
||||
The data in this extent has been encrypted by the file system.
|
||||
|
||||
* FIEMAP_EXTENT_NOT_ALIGNED
|
||||
Extent offsets and length are not guaranteed to be block aligned.
|
||||
|
||||
* FIEMAP_EXTENT_DATA_INLINE
|
||||
This will also set FIEMAP_EXTENT_NOT_ALIGNED
|
||||
Data is located within a meta data block.
|
||||
|
||||
* FIEMAP_EXTENT_DATA_TAIL
|
||||
This will also set FIEMAP_EXTENT_NOT_ALIGNED
|
||||
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
|
||||
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.
|
||||
|
||||
* FIEMAP_EXTENT_MERGED
|
||||
This will be set when a file does not support extents, i.e., it uses a block
|
||||
based addressing scheme. Since returning an extent for each block back to
|
||||
userspace would be highly inefficient, the kernel will try to merge most
|
||||
adjacent blocks into 'extents'.
|
||||
|
||||
|
||||
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
|
||||
each discovered extent:
|
||||
|
||||
struct inode_operations {
|
||||
...
|
||||
|
||||
int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start,
|
||||
u64 len);
|
||||
|
||||
->fiemap is passed struct fiemap_extent_info which describes the
|
||||
fiemap request:
|
||||
|
||||
struct fiemap_extent_info {
|
||||
unsigned int fi_flags; /* Flags as passed from user */
|
||||
unsigned int fi_extents_mapped; /* Number of mapped extents */
|
||||
unsigned int fi_extents_max; /* Size of fiemap_extent array */
|
||||
struct fiemap_extent *fi_extents_start; /* Start of fiemap_extent array */
|
||||
};
|
||||
|
||||
It is intended that the file system should not need to access any of this
|
||||
structure directly.
|
||||
|
||||
|
||||
Flag checking should be done at the beginning of the ->fiemap callback via the
|
||||
fiemap_check_flags() helper:
|
||||
|
||||
int fiemap_check_flags(struct fiemap_extent_info *fieinfo, u32 fs_flags);
|
||||
|
||||
The struct fieinfo should be passed in as recieved from ioctl_fiemap(). The
|
||||
set of fiemap flags which the fs understands should be passed via fs_flags. If
|
||||
fiemap_check_flags finds invalid user flags, it will place the bad values in
|
||||
fieinfo->fi_flags and return -EBADR. If the file system gets -EBADR, from
|
||||
fiemap_check_flags(), it should immediately exit, returning that error back to
|
||||
ioctl_fiemap().
|
||||
|
||||
|
||||
For each extent in the request range, the file system should call
|
||||
the helper function, fiemap_fill_next_extent():
|
||||
|
||||
int fiemap_fill_next_extent(struct fiemap_extent_info *info, u64 logical,
|
||||
u64 phys, u64 len, u32 flags, u32 dev);
|
||||
|
||||
fiemap_fill_next_extent() will use the passed values to populate the
|
||||
next free extent in the fm_extents array. 'General' extent flags will
|
||||
automatically be set from specific flags on behalf of the calling file
|
||||
system so that the userspace API is not broken.
|
||||
|
||||
fiemap_fill_next_extent() returns 0 on success, and 1 when the
|
||||
user-supplied fm_extents array is full. If an error is encountered
|
||||
while copying the extent to user memory, -EFAULT will be returned.
|
||||
@@ -923,45 +923,44 @@ CPUs.
|
||||
The "procs_blocked" line gives the number of processes currently blocked,
|
||||
waiting for I/O to complete.
|
||||
|
||||
|
||||
1.9 Ext4 file system parameters
|
||||
------------------------------
|
||||
Ext4 file system have one directory per partition under /proc/fs/ext4/
|
||||
# ls /proc/fs/ext4/hdc/
|
||||
group_prealloc max_to_scan mb_groups mb_history min_to_scan order2_req
|
||||
stats stream_req
|
||||
|
||||
mb_groups:
|
||||
This file gives the details of multiblock allocator buddy cache of free blocks
|
||||
Information about mounted ext4 file systems can be found in
|
||||
/proc/fs/ext4. Each mounted filesystem will have a directory in
|
||||
/proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or
|
||||
/proc/fs/ext4/dm-0). The files in each per-device directory are shown
|
||||
in Table 1-10, below.
|
||||
|
||||
mb_history:
|
||||
Multiblock allocation history.
|
||||
Table 1-10: Files in /proc/fs/ext4/<devname>
|
||||
..............................................................................
|
||||
File Content
|
||||
mb_groups details of multiblock allocator buddy cache of free blocks
|
||||
mb_history multiblock allocation history
|
||||
stats controls whether the multiblock allocator should start
|
||||
collecting statistics, which are shown during the unmount
|
||||
group_prealloc the multiblock allocator will round up allocation
|
||||
requests to a multiple of this tuning parameter if the
|
||||
stripe size is not set in the ext4 superblock
|
||||
max_to_scan The maximum number of extents the multiblock allocator
|
||||
will search to find the best extent
|
||||
min_to_scan The minimum number of extents the multiblock allocator
|
||||
will search to find the best extent
|
||||
order2_req Tuning parameter which controls the minimum size for
|
||||
requests (as a power of 2) where the buddy cache is
|
||||
used
|
||||
stream_req Files which have fewer blocks than this tunable
|
||||
parameter will have their blocks allocated out of a
|
||||
block group specific preallocation pool, so that small
|
||||
files are packed closely together. Each large file
|
||||
will have its blocks allocated out of its own unique
|
||||
preallocation pool.
|
||||
inode_readahead Tuning parameter which controls the maximum number of
|
||||
inode table blocks that ext4's inode table readahead
|
||||
algorithm will pre-read into the buffer cache
|
||||
..............................................................................
|
||||
|
||||
stats:
|
||||
This file indicate whether the multiblock allocator should start collecting
|
||||
statistics. The statistics are shown during unmount
|
||||
|
||||
group_prealloc:
|
||||
The multiblock allocator normalize the block allocation request to
|
||||
group_prealloc filesystem blocks if we don't have strip value set.
|
||||
The stripe value can be specified at mount time or during mke2fs.
|
||||
|
||||
max_to_scan:
|
||||
How long multiblock allocator can look for a best extent (in found extents)
|
||||
|
||||
min_to_scan:
|
||||
How long multiblock allocator must look for a best extent
|
||||
|
||||
order2_req:
|
||||
Multiblock allocator use 2^N search using buddies only for requests greater
|
||||
than or equal to order2_req. The request size is specfied in file system
|
||||
blocks. A value of 2 indicate only if the requests are greater than or equal
|
||||
to 4 blocks.
|
||||
|
||||
stream_req:
|
||||
Files smaller than stream_req are served by the stream allocator, whose
|
||||
purpose is to pack requests as close each to other as possible to
|
||||
produce smooth I/O traffic. Avalue of 16 indicate that file smaller than 16
|
||||
filesystem block size will use group based preallocation.
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
Summary
|
||||
|
||||
@@ -14,14 +14,14 @@ Description
|
||||
|
||||
This driver implements support for the Analog Devices ADT7473 chip family.
|
||||
|
||||
The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
|
||||
The ADT7473 uses the 2-wire interface compatible with the SMBUS 2.0
|
||||
specification. Using an analog to digital converter it measures three (3)
|
||||
temperatures and two (2) voltages. It has three (3) 16-bit counters for
|
||||
temperatures and two (2) voltages. It has four (4) 16-bit counters for
|
||||
measuring fan speed. There are three (3) PWM outputs that can be used
|
||||
to control fan speed.
|
||||
|
||||
A sophisticated control system for the PWM outputs is designed into the
|
||||
LM85 that allows fan speed to be adjusted automatically based on any of the
|
||||
ADT7473 that allows fan speed to be adjusted automatically based on any of the
|
||||
three temperature sensors. Each PWM output is individually adjustable and
|
||||
programmable. Once configured, the ADT7473 will adjust the PWM outputs in
|
||||
response to the measured temperatures without further host intervention.
|
||||
@@ -46,14 +46,6 @@ from the raw value to get the temperature value.
|
||||
The Analog Devices datasheet is very detailed and describes a procedure for
|
||||
determining an optimal configuration for the automatic PWM control.
|
||||
|
||||
Hardware Configurations
|
||||
-----------------------
|
||||
|
||||
The ADT7473 chips have an optional SMBALERT output that can be used to
|
||||
signal the chipset in case a limit is exceeded or the temperature sensors
|
||||
fail. Individual sensor interrupts can be masked so they won't trigger
|
||||
SMBALERT. The SMBALERT output if configured replaces the PWM2 function.
|
||||
|
||||
Configuration Notes
|
||||
-------------------
|
||||
|
||||
@@ -61,8 +53,8 @@ Besides standard interfaces driver adds the following:
|
||||
|
||||
* PWM Control
|
||||
|
||||
* pwm#_auto_point1_pwm and pwm#_auto_point1_temp and
|
||||
* pwm#_auto_point2_pwm and pwm#_auto_point2_temp -
|
||||
* pwm#_auto_point1_pwm and temp#_auto_point1_temp and
|
||||
* pwm#_auto_point2_pwm and temp#_auto_point2_temp -
|
||||
|
||||
point1: Set the pwm speed at a lower temperature bound.
|
||||
point2: Set the pwm speed at a higher temperature bound.
|
||||
|
||||
@@ -329,6 +329,10 @@ power[1-*]_average Average power use
|
||||
Unit: microWatt
|
||||
RO
|
||||
|
||||
power[1-*]_average_interval Power use averaging interval
|
||||
Unit: milliseconds
|
||||
RW
|
||||
|
||||
power[1-*]_average_highest Historical average maximum power use
|
||||
Unit: microWatt
|
||||
RO
|
||||
@@ -353,6 +357,14 @@ power[1-*]_reset_history Reset input_highest, input_lowest,
|
||||
average_highest and average_lowest.
|
||||
WO
|
||||
|
||||
**********
|
||||
* Energy *
|
||||
**********
|
||||
|
||||
energy[1-*]_input Cumulative energy use
|
||||
Unit: microJoule
|
||||
RO
|
||||
|
||||
**********
|
||||
* Alarms *
|
||||
**********
|
||||
|
||||
@@ -168,10 +168,10 @@ if ($#ARGV < 0) {
|
||||
mkdir $ARGV[0],0777;
|
||||
$state = 0;
|
||||
while (<STDIN>) {
|
||||
if (/^\.TH \"[^\"]*\" 4 \"([^\"]*)\"/) {
|
||||
if (/^\.TH \"[^\"]*\" 9 \"([^\"]*)\"/) {
|
||||
if ($state == 1) { close OUT }
|
||||
$state = 1;
|
||||
$fn = "$ARGV[0]/$1.4";
|
||||
$fn = "$ARGV[0]/$1.9";
|
||||
print STDERR "Creating $fn\n";
|
||||
open OUT, ">$fn" or die "can't open $fn: $!\n";
|
||||
print OUT $_;
|
||||
|
||||
@@ -284,6 +284,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
isolate - enable device isolation (each device, as far
|
||||
as possible, will get its own protection
|
||||
domain)
|
||||
fullflush - enable flushing of IO/TLB entries when
|
||||
they are unmapped. Otherwise they are
|
||||
flushed before they will be reused, which
|
||||
is a lot of faster
|
||||
|
||||
amd_iommu_size= [HW,X86-64]
|
||||
Define the size of the aperture for the AMD IOMMU
|
||||
driver. Possible values are:
|
||||
@@ -463,12 +468,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Range: 0 - 8192
|
||||
Default: 64
|
||||
|
||||
disable_8254_timer
|
||||
enable_8254_timer
|
||||
[IA32/X86_64] Disable/Enable interrupt 0 timer routing
|
||||
over the 8254 in addition to over the IO-APIC. The
|
||||
kernel tries to set a sensible default.
|
||||
|
||||
hpet= [X86-32,HPET] option to control HPET usage
|
||||
Format: { enable (default) | disable | force }
|
||||
disable: disable HPET and use PIT instead
|
||||
@@ -1020,6 +1019,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
(only serial suported for now)
|
||||
Format: <serial_device>[,baud]
|
||||
|
||||
kmac= [MIPS] korina ethernet MAC address.
|
||||
Configure the RouterBoard 532 series on-chip
|
||||
Ethernet adapter MAC address.
|
||||
|
||||
l2cr= [PPC]
|
||||
|
||||
l3cr= [PPC]
|
||||
@@ -1425,6 +1428,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
nolapic_timer [X86-32,APIC] Do not use the local APIC timer.
|
||||
|
||||
nox2apic [X86-64,APIC] Do not enable x2APIC mode.
|
||||
|
||||
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
|
||||
default x2apic cluster mode on platforms
|
||||
supporting x2apic.
|
||||
|
||||
noltlbs [PPC] Do not use large page/tlb entries for kernel
|
||||
lowmem mapping on PPC40x.
|
||||
|
||||
@@ -1882,6 +1891,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
shapers= [NET]
|
||||
Maximal number of shapers.
|
||||
|
||||
show_msr= [x86] show boot-time MSR settings
|
||||
Format: { <integer> }
|
||||
Show boot-time (BIOS-initialized) MSR settings.
|
||||
The parameter means the number of CPUs to show,
|
||||
for example 1 means boot CPU only.
|
||||
|
||||
sim710= [SCSI,HW]
|
||||
See header of drivers/scsi/sim710.c.
|
||||
|
||||
|
||||
@@ -0,0 +1,46 @@
|
||||
Copyright (c) 2003-2008 QLogic Corporation
|
||||
QLogic Linux Networking HBA Driver
|
||||
|
||||
This program includes a device driver for Linux 2.6 that may be
|
||||
distributed with QLogic hardware specific firmware binary file.
|
||||
You may modify and redistribute the device driver code under the
|
||||
GNU General Public License as published by the Free Software
|
||||
Foundation (version 2 or a later version).
|
||||
|
||||
You may redistribute the hardware specific firmware binary file
|
||||
under the following terms:
|
||||
|
||||
1. Redistribution of source code (only if applicable),
|
||||
must retain the above copyright notice, this list of
|
||||
conditions and the following disclaimer.
|
||||
|
||||
2. Redistribution in binary form must reproduce the above
|
||||
copyright notice, this list of conditions and the
|
||||
following disclaimer in the documentation and/or other
|
||||
materials provided with the distribution.
|
||||
|
||||
3. The name of QLogic Corporation may not be used to
|
||||
endorse or promote products derived from this software
|
||||
without specific prior written permission
|
||||
|
||||
REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE,
|
||||
THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY
|
||||
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
|
||||
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
|
||||
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
||||
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
|
||||
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
||||
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
|
||||
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
||||
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT
|
||||
CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR
|
||||
OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
|
||||
TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
|
||||
ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
|
||||
COMBINATION WITH THIS PROGRAM.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user