Merge Linux 2.6.23
This commit is contained in:
David Woodhouse
@@ -134,8 +134,6 @@ dvb/
|
||||
- info on Linux Digital Video Broadcast (DVB) subsystem.
|
||||
early-userspace/
|
||||
- info about initramfs, klibc, and userspace early during boot.
|
||||
ecryptfs.txt
|
||||
- docs on eCryptfs: stacked cryptographic filesystem for Linux.
|
||||
eisa.txt
|
||||
- info on EISA bus support.
|
||||
exception.txt
|
||||
|
||||
@@ -316,7 +316,8 @@ CPU B: spin_unlock_irqrestore(&dev_lock, flags)
|
||||
|
||||
<chapter id="pubfunctions">
|
||||
<title>Public Functions Provided</title>
|
||||
!Einclude/asm-i386/io.h
|
||||
!Iinclude/asm-i386/io.h
|
||||
!Elib/iomap.c
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
||||
@@ -208,7 +208,7 @@ tools. One such tool that is particularly recommended is the Linux
|
||||
Cross-Reference project, which is able to present source code in a
|
||||
self-referential, indexed webpage format. An excellent up-to-date
|
||||
repository of the kernel code may be found at:
|
||||
http://sosdg.org/~coywolf/lxr/
|
||||
http://users.sosdg.org/~qiyong/lxr/
|
||||
|
||||
|
||||
The development process
|
||||
@@ -384,7 +384,7 @@ One of the best ways to put into practice your hacking skills is by fixing
|
||||
bugs reported by other people. Not only you will help to make the kernel
|
||||
more stable, you'll learn to fix real world problems and you will improve
|
||||
your skills, and other developers will be aware of your presence. Fixing
|
||||
bugs is one of the best ways to earn merit amongst the developers, because
|
||||
bugs is one of the best ways to get merits among other developers, because
|
||||
not many people like wasting time fixing other people's bugs.
|
||||
|
||||
To work in the already reported bug reports, go to http://bugzilla.kernel.org.
|
||||
|
||||
@@ -166,7 +166,7 @@ To solve this problem, you really only have two options:
|
||||
The option of being unfailingly polite really doesn't exist. Nobody will
|
||||
trust somebody who is so clearly hiding his true character.
|
||||
|
||||
(*) Paul Simon sang "Fifty Ways to Lose Your Lover", because quite
|
||||
(*) Paul Simon sang "Fifty Ways to Leave Your Lover", because quite
|
||||
frankly, "A Million Ways to Tell a Developer He Is a D*ckhead" doesn't
|
||||
scan nearly as well. But I'm sure he thought about it.
|
||||
|
||||
|
||||
@@ -126,7 +126,7 @@ the reviewers time and will get your patch rejected, probably
|
||||
without even being read.
|
||||
|
||||
At a minimum you should check your patches with the patch style
|
||||
checker prior to submission (scripts/patchcheck.pl). You should
|
||||
checker prior to submission (scripts/checkpatch.pl). You should
|
||||
be able to justify all violations that remain in your patch.
|
||||
|
||||
|
||||
@@ -560,7 +560,7 @@ NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
||||
<http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
|
||||
|
||||
Kernel Documentation/CodingStyle:
|
||||
<http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle>
|
||||
<http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
|
||||
|
||||
Linus Torvalds's mail on the canonical patch format:
|
||||
<http://lkml.org/lkml/2005/4/7/183>
|
||||
|
||||
219
Documentation/crypto/async-tx-api.txt
Normal file
219
Documentation/crypto/async-tx-api.txt
Normal file
@@ -0,0 +1,219 @@
|
||||
Asynchronous Transfers/Transforms API
|
||||
|
||||
1 INTRODUCTION
|
||||
|
||||
2 GENEALOGY
|
||||
|
||||
3 USAGE
|
||||
3.1 General format of the API
|
||||
3.2 Supported operations
|
||||
3.3 Descriptor management
|
||||
3.4 When does the operation execute?
|
||||
3.5 When does the operation complete?
|
||||
3.6 Constraints
|
||||
3.7 Example
|
||||
|
||||
4 DRIVER DEVELOPER NOTES
|
||||
4.1 Conformance points
|
||||
4.2 "My application needs finer control of hardware channels"
|
||||
|
||||
5 SOURCE
|
||||
|
||||
---
|
||||
|
||||
1 INTRODUCTION
|
||||
|
||||
The async_tx API provides methods for describing a chain of asynchronous
|
||||
bulk memory transfers/transforms with support for inter-transactional
|
||||
dependencies. It is implemented as a dmaengine client that smooths over
|
||||
the details of different hardware offload engine implementations. Code
|
||||
that is written to the API can optimize for asynchronous operation and
|
||||
the API will fit the chain of operations to the available offload
|
||||
resources.
|
||||
|
||||
2 GENEALOGY
|
||||
|
||||
The API was initially designed to offload the memory copy and
|
||||
xor-parity-calculations of the md-raid5 driver using the offload engines
|
||||
present in the Intel(R) Xscale series of I/O processors. It also built
|
||||
on the 'dmaengine' layer developed for offloading memory copies in the
|
||||
network stack using Intel(R) I/OAT engines. The following design
|
||||
features surfaced as a result:
|
||||
1/ implicit synchronous path: users of the API do not need to know if
|
||||
the platform they are running on has offload capabilities. The
|
||||
operation will be offloaded when an engine is available and carried out
|
||||
in software otherwise.
|
||||
2/ cross channel dependency chains: the API allows a chain of dependent
|
||||
operations to be submitted, like xor->copy->xor in the raid5 case. The
|
||||
API automatically handles cases where the transition from one operation
|
||||
to another implies a hardware channel switch.
|
||||
3/ dmaengine extensions to support multiple clients and operation types
|
||||
beyond 'memcpy'
|
||||
|
||||
3 USAGE
|
||||
|
||||
3.1 General format of the API:
|
||||
struct dma_async_tx_descriptor *
|
||||
async_<operation>(<op specific parameters>,
|
||||
enum async_tx_flags flags,
|
||||
struct dma_async_tx_descriptor *dependency,
|
||||
dma_async_tx_callback callback_routine,
|
||||
void *callback_parameter);
|
||||
|
||||
3.2 Supported operations:
|
||||
memcpy - memory copy between a source and a destination buffer
|
||||
memset - fill a destination buffer with a byte value
|
||||
xor - xor a series of source buffers and write the result to a
|
||||
destination buffer
|
||||
xor_zero_sum - xor a series of source buffers and set a flag if the
|
||||
result is zero. The implementation attempts to prevent
|
||||
writes to memory
|
||||
|
||||
3.3 Descriptor management:
|
||||
The return value is non-NULL and points to a 'descriptor' when the operation
|
||||
has been queued to execute asynchronously. Descriptors are recycled
|
||||
resources, under control of the offload engine driver, to be reused as
|
||||
operations complete. When an application needs to submit a chain of
|
||||
operations it must guarantee that the descriptor is not automatically recycled
|
||||
before the dependency is submitted. This requires that all descriptors be
|
||||
acknowledged by the application before the offload engine driver is allowed to
|
||||
recycle (or free) the descriptor. A descriptor can be acked by one of the
|
||||
following methods:
|
||||
1/ setting the ASYNC_TX_ACK flag if no child operations are to be submitted
|
||||
2/ setting the ASYNC_TX_DEP_ACK flag to acknowledge the parent
|
||||
descriptor of a new operation.
|
||||
3/ calling async_tx_ack() on the descriptor.
|
||||
|
||||
3.4 When does the operation execute?
|
||||
Operations do not immediately issue after return from the
|
||||
async_<operation> call. Offload engine drivers batch operations to
|
||||
improve performance by reducing the number of mmio cycles needed to
|
||||
manage the channel. Once a driver-specific threshold is met the driver
|
||||
automatically issues pending operations. An application can force this
|
||||
event by calling async_tx_issue_pending_all(). This operates on all
|
||||
channels since the application has no knowledge of channel to operation
|
||||
mapping.
|
||||
|
||||
3.5 When does the operation complete?
|
||||
There are two methods for an application to learn about the completion
|
||||
of an operation.
|
||||
1/ Call dma_wait_for_async_tx(). This call causes the CPU to spin while
|
||||
it polls for the completion of the operation. It handles dependency
|
||||
chains and issuing pending operations.
|
||||
2/ Specify a completion callback. The callback routine runs in tasklet
|
||||
context if the offload engine driver supports interrupts, or it is
|
||||
called in application context if the operation is carried out
|
||||
synchronously in software. The callback can be set in the call to
|
||||
async_<operation>, or when the application needs to submit a chain of
|
||||
unknown length it can use the async_trigger_callback() routine to set a
|
||||
completion interrupt/callback at the end of the chain.
|
||||
|
||||
3.6 Constraints:
|
||||
1/ Calls to async_<operation> are not permitted in IRQ context. Other
|
||||
contexts are permitted provided constraint #2 is not violated.
|
||||
2/ Completion callback routines cannot submit new operations. This
|
||||
results in recursion in the synchronous case and spin_locks being
|
||||
acquired twice in the asynchronous case.
|
||||
|
||||
3.7 Example:
|
||||
Perform a xor->copy->xor operation where each operation depends on the
|
||||
result from the previous operation:
|
||||
|
||||
void complete_xor_copy_xor(void *param)
|
||||
{
|
||||
printk("complete\n");
|
||||
}
|
||||
|
||||
int run_xor_copy_xor(struct page **xor_srcs,
|
||||
int xor_src_cnt,
|
||||
struct page *xor_dest,
|
||||
size_t xor_len,
|
||||
struct page *copy_src,
|
||||
struct page *copy_dest,
|
||||
size_t copy_len)
|
||||
{
|
||||
struct dma_async_tx_descriptor *tx;
|
||||
|
||||
tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len,
|
||||
ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL);
|
||||
tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len,
|
||||
ASYNC_TX_DEP_ACK, tx, NULL, NULL);
|
||||
tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len,
|
||||
ASYNC_TX_XOR_DROP_DST | ASYNC_TX_DEP_ACK | ASYNC_TX_ACK,
|
||||
tx, complete_xor_copy_xor, NULL);
|
||||
|
||||
async_tx_issue_pending_all();
|
||||
}
|
||||
|
||||
See include/linux/async_tx.h for more information on the flags. See the
|
||||
ops_run_* and ops_complete_* routines in drivers/md/raid5.c for more
|
||||
implementation examples.
|
||||
|
||||
4 DRIVER DEVELOPMENT NOTES
|
||||
4.1 Conformance points:
|
||||
There are a few conformance points required in dmaengine drivers to
|
||||
accommodate assumptions made by applications using the async_tx API:
|
||||
1/ Completion callbacks are expected to happen in tasklet context
|
||||
2/ dma_async_tx_descriptor fields are never manipulated in IRQ context
|
||||
3/ Use async_tx_run_dependencies() in the descriptor clean up path to
|
||||
handle submission of dependent operations
|
||||
|
||||
4.2 "My application needs finer control of hardware channels"
|
||||
This requirement seems to arise from cases where a DMA engine driver is
|
||||
trying to support device-to-memory DMA. The dmaengine and async_tx
|
||||
implementations were designed for offloading memory-to-memory
|
||||
operations; however, there are some capabilities of the dmaengine layer
|
||||
that can be used for platform-specific channel management.
|
||||
Platform-specific constraints can be handled by registering the
|
||||
application as a 'dma_client' and implementing a 'dma_event_callback' to
|
||||
apply a filter to the available channels in the system. Before showing
|
||||
how to implement a custom dma_event callback some background of
|
||||
dmaengine's client support is required.
|
||||
|
||||
The following routines in dmaengine support multiple clients requesting
|
||||
use of a channel:
|
||||
- dma_async_client_register(struct dma_client *client)
|
||||
- dma_async_client_chan_request(struct dma_client *client)
|
||||
|
||||
dma_async_client_register takes a pointer to an initialized dma_client
|
||||
structure. It expects that the 'event_callback' and 'cap_mask' fields
|
||||
are already initialized.
|
||||
|
||||
dma_async_client_chan_request triggers dmaengine to notify the client of
|
||||
all channels that satisfy the capability mask. It is up to the client's
|
||||
event_callback routine to track how many channels the client needs and
|
||||
how many it is currently using. The dma_event_callback routine returns a
|
||||
dma_state_client code to let dmaengine know the status of the
|
||||
allocation.
|
||||
|
||||
Below is the example of how to extend this functionality for
|
||||
platform-specific filtering of the available channels beyond the
|
||||
standard capability mask:
|
||||
|
||||
static enum dma_state_client
|
||||
my_dma_client_callback(struct dma_client *client,
|
||||
struct dma_chan *chan, enum dma_state state)
|
||||
{
|
||||
struct dma_device *dma_dev;
|
||||
struct my_platform_specific_dma *plat_dma_dev;
|
||||
|
||||
dma_dev = chan->device;
|
||||
plat_dma_dev = container_of(dma_dev,
|
||||
struct my_platform_specific_dma,
|
||||
dma_dev);
|
||||
|
||||
if (!plat_dma_dev->platform_specific_capability)
|
||||
return DMA_DUP;
|
||||
|
||||
. . .
|
||||
}
|
||||
|
||||
5 SOURCE
|
||||
include/linux/dmaengine.h: core header file for DMA drivers and clients
|
||||
drivers/dma/dmaengine.c: offload engine channel management routines
|
||||
drivers/dma/: location for offload engine drivers
|
||||
include/linux/async_tx.h: core header file for the async_tx api
|
||||
crypto/async_tx/async_tx.c: async_tx interface to dmaengine and common code
|
||||
crypto/async_tx/async_memcpy.c: copy offload
|
||||
crypto/async_tx/async_memset.c: memory fill offload
|
||||
crypto/async_tx/async_xor.c: xor and xor zero sum offload
|
||||
@@ -94,6 +94,8 @@ Your cooperation is appreciated.
|
||||
9 = /dev/urandom Faster, less secure random number gen.
|
||||
10 = /dev/aio Asynchronous I/O notification interface
|
||||
11 = /dev/kmsg Writes to this come out as printk's
|
||||
12 = /dev/oldmem Used by crashdump kernels to access
|
||||
the memory of the kernel that crashed.
|
||||
|
||||
1 block RAM disk
|
||||
0 = /dev/ram0 First RAM disk
|
||||
|
||||
@@ -197,6 +197,14 @@ Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /proc/acpi/event
|
||||
When: February 2008
|
||||
Why: /proc/acpi/event has been replaced by events via the input layer
|
||||
and netlink since 2.6.23.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Compaq touchscreen device emulation
|
||||
When: Oct 2007
|
||||
Files: drivers/input/tsdev.c
|
||||
@@ -290,3 +298,11 @@ Why: All mthca hardware also supports MSI-X, which provides
|
||||
Who: Roland Dreier <rolandd@cisco.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: sk98lin network driver
|
||||
When: Feburary 2008
|
||||
Why: In kernel tree version of driver is unmaintained. Sk98lin driver
|
||||
replaced by the skge driver.
|
||||
Who: Stephen Hemminger <shemminger@linux-foundation.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
@@ -32,6 +32,8 @@ directory-locking
|
||||
- info about the locking scheme used for directory operations.
|
||||
dlmfs.txt
|
||||
- info on the userspace interface to the OCFS2 DLM.
|
||||
ecryptfs.txt
|
||||
- docs on eCryptfs: stacked cryptographic filesystem for Linux.
|
||||
ext2.txt
|
||||
- info, mount options and specifications for the Ext2 filesystem.
|
||||
ext3.txt
|
||||
|
||||
@@ -6,12 +6,26 @@ ABOUT
|
||||
|
||||
v9fs is a Unix implementation of the Plan 9 9p remote filesystem protocol.
|
||||
|
||||
This software was originally developed by Ron Minnich <rminnich@lanl.gov>
|
||||
and Maya Gokhale <maya@lanl.gov>. Additional development by Greg Watson
|
||||
This software was originally developed by Ron Minnich <rminnich@sandia.gov>
|
||||
and Maya Gokhale. Additional development by Greg Watson
|
||||
<gwatson@lanl.gov> and most recently Eric Van Hensbergen
|
||||
<ericvh@gmail.com>, Latchesar Ionkov <lucho@ionkov.net> and Russ Cox
|
||||
<rsc@swtch.com>.
|
||||
|
||||
The best detailed explanation of the Linux implementation and applications of
|
||||
the 9p client is available in the form of a USENIX paper:
|
||||
http://www.usenix.org/events/usenix05/tech/freenix/hensbergen.html
|
||||
|
||||
Other applications are described in the following papers:
|
||||
* XCPU & Clustering
|
||||
http://www.xcpu.org/xcpu-talk.pdf
|
||||
* KVMFS: control file system for KVM
|
||||
http://www.xcpu.org/kvmfs.pdf
|
||||
* CellFS: A New ProgrammingModel for the Cell BE
|
||||
http://www.xcpu.org/cellfs-talk.pdf
|
||||
* PROSE I/O: Using 9p to enable Application Partitions
|
||||
http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
|
||||
|
||||
USAGE
|
||||
=====
|
||||
|
||||
@@ -90,9 +104,9 @@ subset of the namespace by extending the path: '#U*'/tmp would just export
|
||||
and export.
|
||||
|
||||
A Linux version of the 9p server is now maintained under the npfs project
|
||||
on sourceforge (http://sourceforge.net/projects/npfs). There is also a
|
||||
more stable single-threaded version of the server (named spfs) available from
|
||||
the same CVS repository.
|
||||
on sourceforge (http://sourceforge.net/projects/npfs). The currently
|
||||
maintained version is the single-threaded version of the server (named spfs)
|
||||
available from the same CVS repository.
|
||||
|
||||
There are user and developer mailing lists available through the v9fs project
|
||||
on sourceforge (http://sourceforge.net/projects/v9fs).
|
||||
|
||||
@@ -28,11 +28,7 @@ Manish Singh <manish.singh@oracle.com>
|
||||
Caveats
|
||||
=======
|
||||
Features which OCFS2 does not support yet:
|
||||
- sparse files
|
||||
- extended attributes
|
||||
- shared writable mmap
|
||||
- loopback is supported, but data written will not
|
||||
be cluster coherent.
|
||||
- quotas
|
||||
- cluster aware flock
|
||||
- cluster aware lockf
|
||||
@@ -57,3 +53,12 @@ nointr Do not allow signals to interrupt cluster
|
||||
atime_quantum=60(*) OCFS2 will not update atime unless this number
|
||||
of seconds has passed since the last update.
|
||||
Set to zero to always update atime.
|
||||
data=ordered (*) All data are forced directly out to the main file
|
||||
system prior to its metadata being committed to the
|
||||
journal.
|
||||
data=writeback Data ordering is not preserved, data may be written
|
||||
into the main file system after its metadata has been
|
||||
committed to the journal.
|
||||
preferred_slot=0(*) During mount, try to use this filesystem slot first. If
|
||||
it is in use by another node, the first empty one found
|
||||
will be chosen. Invalid values will be ignored.
|
||||
|
||||
@@ -6,7 +6,7 @@ Supported adapters:
|
||||
Datasheet: Publicly available at the Intel website
|
||||
* ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges
|
||||
Datasheet: Only available via NDA from ServerWorks
|
||||
* ATI IXP200, IXP300, IXP400, SB600 and SB700 southbridges
|
||||
* ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges
|
||||
Datasheet: Not publicly available
|
||||
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
|
||||
Datasheet: Publicly available at the SMSC website http://www.smsc.com
|
||||
|
||||
@@ -1,254 +1,254 @@
|
||||
** Introduction
|
||||
This document describes what I managed to discover about the protocol used to
|
||||
specify force effects to I-Force 2.0 devices. None of this information comes
|
||||
from Immerse. That's why you should not trust what is written in this
|
||||
document. This document is intended to help understanding the protocol.
|
||||
This is not a reference. Comments and corrections are welcome. To contact me,
|
||||
send an email to: deneux@ifrance.com
|
||||
|
||||
** WARNING **
|
||||
I may not be held responsible for any dammage or harm caused if you try to
|
||||
send data to your I-Force device based on what you read in this document.
|
||||
|
||||
** Preliminary Notes:
|
||||
All values are hexadecimal with big-endian encoding (msb on the left). Beware,
|
||||
values inside packets are encoded using little-endian. Bytes whose roles are
|
||||
unknown are marked ??? Information that needs deeper inspection is marked (?)
|
||||
|
||||
** General form of a packet **
|
||||
This is how packets look when the device uses the rs232 to communicate.
|
||||
2B OP LEN DATA CS
|
||||
CS is the checksum. It is equal to the exclusive or of all bytes.
|
||||
|
||||
When using USB:
|
||||
OP DATA
|
||||
The 2B, LEN and CS fields have disappeared, probably because USB handles frames and
|
||||
data corruption is handled or unsignificant.
|
||||
|
||||
First, I describe effects that are sent by the device to the computer
|
||||
|
||||
** Device input state
|
||||
This packet is used to indicate the state of each button and the value of each
|
||||
axis
|
||||
OP= 01 for a joystick, 03 for a wheel
|
||||
LEN= Varies from device to device
|
||||
00 X-Axis lsb
|
||||
01 X-Axis msb
|
||||
02 Y-Axis lsb, or gas pedal for a wheel
|
||||
03 Y-Axis msb, or brake pedal for a wheel
|
||||
04 Throttle
|
||||
05 Buttons
|
||||
06 Lower 4 bits: Buttons
|
||||
Upper 4 bits: Hat
|
||||
07 Rudder
|
||||
|
||||
** Device effects states
|
||||
OP= 02
|
||||
LEN= Varies
|
||||
00 ? Bit 1 (Value 2) is the value of the deadman switch
|
||||
01 Bit 8 is set if the effect is playing. Bits 0 to 7 are the effect id.
|
||||
02 ??
|
||||
03 Address of parameter block changed (lsb)
|
||||
04 Address of parameter block changed (msb)
|
||||
05 Address of second parameter block changed (lsb)
|
||||
... depending on the number of parameter blocks updated
|
||||
|
||||
** Force effect **
|
||||
OP= 01
|
||||
LEN= 0e
|
||||
00 Channel (when playing several effects at the same time, each must be assigned a channel)
|
||||
01 Wave form
|
||||
Val 00 Constant
|
||||
Val 20 Square
|
||||
Val 21 Triangle
|
||||
Val 22 Sine
|
||||
Val 23 Sawtooth up
|
||||
Val 24 Sawtooth down
|
||||
Val 40 Spring (Force = f(pos))
|
||||
Val 41 Friction (Force = f(velocity)) and Inertia (Force = f(acceleration))
|
||||
|
||||
|
||||
02 Axes affected and trigger
|
||||
Bits 4-7: Val 2 = effect along one axis. Byte 05 indicates direction
|
||||
Val 4 = X axis only. Byte 05 must contain 5a
|
||||
Val 8 = Y axis only. Byte 05 must contain b4
|
||||
Val c = X and Y axes. Bytes 05 must contain 60
|
||||
Bits 0-3: Val 0 = No trigger
|
||||
Val x+1 = Button x triggers the effect
|
||||
When the whole byte is 0, cancel the previously set trigger
|
||||
|
||||
03-04 Duration of effect (little endian encoding, in ms)
|
||||
|
||||
05 Direction of effect, if applicable. Else, see 02 for value to assign.
|
||||
|
||||
06-07 Minimum time between triggering.
|
||||
|
||||
08-09 Address of periodicity or magnitude parameters
|
||||
0a-0b Address of attack and fade parameters, or ffff if none.
|
||||
*or*
|
||||
08-09 Address of interactive parameters for X-axis, or ffff if not applicable
|
||||
0a-0b Address of interactive parameters for Y-axis, or ffff if not applicable
|
||||
|
||||
0c-0d Delay before execution of effect (little endian encoding, in ms)
|
||||
|
||||
|
||||
** Time based parameters **
|
||||
|
||||
*** Attack and fade ***
|
||||
OP= 02
|
||||
LEN= 08
|
||||
00-01 Address where to store the parameteres
|
||||
02-03 Duration of attack (little endian encoding, in ms)
|
||||
04 Level at end of attack. Signed byte.
|
||||
05-06 Duration of fade.
|
||||
07 Level at end of fade.
|
||||
|
||||
*** Magnitude ***
|
||||
OP= 03
|
||||
LEN= 03
|
||||
00-01 Address
|
||||
02 Level. Signed byte.
|
||||
|
||||
*** Periodicity ***
|
||||
OP= 04
|
||||
LEN= 07
|
||||
00-01 Address
|
||||
02 Magnitude. Signed byte.
|
||||
03 Offset. Signed byte.
|
||||
04 Phase. Val 00 = 0 deg, Val 40 = 90 degs.
|
||||
05-06 Period (little endian encoding, in ms)
|
||||
|
||||
** Interactive parameters **
|
||||
OP= 05
|
||||
LEN= 0a
|
||||
00-01 Address
|
||||
02 Positive Coeff
|
||||
03 Negative Coeff
|
||||
04+05 Offset (center)
|
||||
06+07 Dead band (Val 01F4 = 5000 (decimal))
|
||||
08 Positive saturation (Val 0a = 1000 (decimal) Val 64 = 10000 (decimal))
|
||||
09 Negative saturation
|
||||
|
||||
The encoding is a bit funny here: For coeffs, these are signed values. The
|
||||
maximum value is 64 (100 decimal), the min is 9c.
|
||||
For the offset, the minimum value is FE0C, the maximum value is 01F4.
|
||||
For the deadband, the minimum value is 0, the max is 03E8.
|
||||
|
||||
** Controls **
|
||||
OP= 41
|
||||
LEN= 03
|
||||
00 Channel
|
||||
01 Start/Stop
|
||||
Val 00: Stop
|
||||
Val 01: Start and play once.
|
||||
Val 41: Start and play n times (See byte 02 below)
|
||||
02 Number of iterations n.
|
||||
|
||||
** Init **
|
||||
|
||||
*** Querying features ***
|
||||
OP= ff
|
||||
Query command. Length varies according to the query type.
|
||||
The general format of this packet is:
|
||||
ff 01 QUERY [INDEX] CHECKSUM
|
||||
reponses are of the same form:
|
||||
FF LEN QUERY VALUE_QUERIED CHECKSUM2
|
||||
where LEN = 1 + length(VALUE_QUERIED)
|
||||
|
||||
**** Query ram size ****
|
||||
QUERY = 42 ('B'uffer size)
|
||||
The device should reply with the same packet plus two additionnal bytes
|
||||
containing the size of the memory:
|
||||
ff 03 42 03 e8 CS would mean that the device has 1000 bytes of ram available.
|
||||
|
||||
**** Query number of effects ****
|
||||
QUERY = 4e ('N'umber of effects)
|
||||
The device should respond by sending the number of effects that can be played
|
||||
at the same time (one byte)
|
||||
ff 02 4e 14 CS would stand for 20 effects.
|
||||
|
||||
**** Vendor's id ****
|
||||
QUERY = 4d ('M'anufacturer)
|
||||
Query the vendors'id (2 bytes)
|
||||
|
||||
**** Product id *****
|
||||
QUERY = 50 ('P'roduct)
|
||||
Query the product id (2 bytes)
|
||||
|
||||
**** Open device ****
|
||||
QUERY = 4f ('O'pen)
|
||||
No data returned.
|
||||
|
||||
**** Close device *****
|
||||
QUERY = 43 ('C')lose
|
||||
No data returned.
|
||||
|
||||
**** Query effect ****
|
||||
QUERY = 45 ('E')
|
||||
Send effect type.
|
||||
Returns nonzero if supported (2 bytes)
|
||||
|
||||
**** Firmware Version ****
|
||||
QUERY = 56 ('V'ersion)
|
||||
Sends back 3 bytes - major, minor, subminor
|
||||
|
||||
*** Initialisation of the device ***
|
||||
|
||||
**** Set Control ****
|
||||
!!! Device dependent, can be different on different models !!!
|
||||
OP= 40 <idx> <val> [<val>]
|
||||
LEN= 2 or 3
|
||||
00 Idx
|
||||
Idx 00 Set dead zone (0..2048)
|
||||
Idx 01 Ignore Deadman sensor (0..1)
|
||||
Idx 02 Enable comm watchdog (0..1)
|
||||
Idx 03 Set the strength of the spring (0..100)
|
||||
Idx 04 Enable or disable the spring (0/1)
|
||||
Idx 05 Set axis saturation threshold (0..2048)
|
||||
|
||||
**** Set Effect State ****
|
||||
OP= 42 <val>
|
||||
LEN= 1
|
||||
00 State
|
||||
Bit 3 Pause force feedback
|
||||
Bit 2 Enable force feedback
|
||||
Bit 0 Stop all effects
|
||||
|
||||
**** Set overall gain ****
|
||||
OP= 43 <val>
|
||||
LEN= 1
|
||||
00 Gain
|
||||
Val 00 = 0%
|
||||
Val 40 = 50%
|
||||
Val 80 = 100%
|
||||
|
||||
** Parameter memory **
|
||||
|
||||
Each device has a certain amount of memory to store parameters of effects.
|
||||
The amount of RAM may vary, I encountered values from 200 to 1000 bytes. Below
|
||||
is the amount of memory apparently needed for every set of parameters:
|
||||
- period : 0c
|
||||
- magnitude : 02
|
||||
- attack and fade : 0e
|
||||
- interactive : 08
|
||||
|
||||
** Appendix: How to study the protocol ? **
|
||||
|
||||
1. Generate effects using the force editor provided with the DirectX SDK, or use Immersion Studio (freely available at their web site in the developer section: www.immersion.com)
|
||||
2. Start a soft spying RS232 or USB (depending on where you connected your joystick/wheel). I used ComPortSpy from fCoder (alpha version!)
|
||||
3. Play the effect, and watch what happens on the spy screen.
|
||||
|
||||
A few words about ComPortSpy:
|
||||
At first glance, this soft seems, hum, well... buggy. In fact, data appear with a few seconds latency. Personnaly, I restart it every time I play an effect.
|
||||
Remember it's free (as in free beer) and alpha!
|
||||
|
||||
** URLS **
|
||||
Check www.immerse.com for Immersion Studio, and www.fcoder.com for ComPortSpy.
|
||||
|
||||
** Author of this document **
|
||||
Johann Deneux <deneux@ifrance.com>
|
||||
Home page at http://www.esil.univ-mrs.fr/~jdeneux/projects/ff/
|
||||
|
||||
Additions by Vojtech Pavlik.
|
||||
|
||||
I-Force is trademark of Immersion Corp.
|
||||
** Introduction
|
||||
This document describes what I managed to discover about the protocol used to
|
||||
specify force effects to I-Force 2.0 devices. None of this information comes
|
||||
from Immerse. That's why you should not trust what is written in this
|
||||
document. This document is intended to help understanding the protocol.
|
||||
This is not a reference. Comments and corrections are welcome. To contact me,
|
||||
send an email to: deneux@ifrance.com
|
||||
|
||||
** WARNING **
|
||||
I may not be held responsible for any dammage or harm caused if you try to
|
||||
send data to your I-Force device based on what you read in this document.
|
||||
|
||||
** Preliminary Notes:
|
||||
All values are hexadecimal with big-endian encoding (msb on the left). Beware,
|
||||
values inside packets are encoded using little-endian. Bytes whose roles are
|
||||
unknown are marked ??? Information that needs deeper inspection is marked (?)
|
||||
|
||||
** General form of a packet **
|
||||
This is how packets look when the device uses the rs232 to communicate.
|
||||
2B OP LEN DATA CS
|
||||
CS is the checksum. It is equal to the exclusive or of all bytes.
|
||||
|
||||
When using USB:
|
||||
OP DATA
|
||||
The 2B, LEN and CS fields have disappeared, probably because USB handles frames and
|
||||
data corruption is handled or unsignificant.
|
||||
|
||||
First, I describe effects that are sent by the device to the computer
|
||||
|
||||
** Device input state
|
||||
This packet is used to indicate the state of each button and the value of each
|
||||
axis
|
||||
OP= 01 for a joystick, 03 for a wheel
|
||||
LEN= Varies from device to device
|
||||
00 X-Axis lsb
|
||||
01 X-Axis msb
|
||||
02 Y-Axis lsb, or gas pedal for a wheel
|
||||
03 Y-Axis msb, or brake pedal for a wheel
|
||||
04 Throttle
|
||||
05 Buttons
|
||||
06 Lower 4 bits: Buttons
|
||||
Upper 4 bits: Hat
|
||||
07 Rudder
|
||||
|
||||
** Device effects states
|
||||
OP= 02
|
||||
LEN= Varies
|
||||
00 ? Bit 1 (Value 2) is the value of the deadman switch
|
||||
01 Bit 8 is set if the effect is playing. Bits 0 to 7 are the effect id.
|
||||
02 ??
|
||||
03 Address of parameter block changed (lsb)
|
||||
04 Address of parameter block changed (msb)
|
||||
05 Address of second parameter block changed (lsb)
|
||||
... depending on the number of parameter blocks updated
|
||||
|
||||
** Force effect **
|
||||
OP= 01
|
||||
LEN= 0e
|
||||
00 Channel (when playing several effects at the same time, each must be assigned a channel)
|
||||
01 Wave form
|
||||
Val 00 Constant
|
||||
Val 20 Square
|
||||
Val 21 Triangle
|
||||
Val 22 Sine
|
||||
Val 23 Sawtooth up
|
||||
Val 24 Sawtooth down
|
||||
Val 40 Spring (Force = f(pos))
|
||||
Val 41 Friction (Force = f(velocity)) and Inertia (Force = f(acceleration))
|
||||
|
||||
|
||||
02 Axes affected and trigger
|
||||
Bits 4-7: Val 2 = effect along one axis. Byte 05 indicates direction
|
||||
Val 4 = X axis only. Byte 05 must contain 5a
|
||||
Val 8 = Y axis only. Byte 05 must contain b4
|
||||
Val c = X and Y axes. Bytes 05 must contain 60
|
||||
Bits 0-3: Val 0 = No trigger
|
||||
Val x+1 = Button x triggers the effect
|
||||
When the whole byte is 0, cancel the previously set trigger
|
||||
|
||||
03-04 Duration of effect (little endian encoding, in ms)
|
||||
|
||||
05 Direction of effect, if applicable. Else, see 02 for value to assign.
|
||||
|
||||
06-07 Minimum time between triggering.
|
||||
|
||||
08-09 Address of periodicity or magnitude parameters
|
||||
0a-0b Address of attack and fade parameters, or ffff if none.
|
||||
*or*
|
||||
08-09 Address of interactive parameters for X-axis, or ffff if not applicable
|
||||
0a-0b Address of interactive parameters for Y-axis, or ffff if not applicable
|
||||
|
||||
0c-0d Delay before execution of effect (little endian encoding, in ms)
|
||||
|
||||
|
||||
** Time based parameters **
|
||||
|
||||
*** Attack and fade ***
|
||||
OP= 02
|
||||
LEN= 08
|
||||
00-01 Address where to store the parameteres
|
||||
02-03 Duration of attack (little endian encoding, in ms)
|
||||
04 Level at end of attack. Signed byte.
|
||||
05-06 Duration of fade.
|
||||
07 Level at end of fade.
|
||||
|
||||
*** Magnitude ***
|
||||
OP= 03
|
||||
LEN= 03
|
||||
00-01 Address
|
||||
02 Level. Signed byte.
|
||||
|
||||
*** Periodicity ***
|
||||
OP= 04
|
||||
LEN= 07
|
||||
00-01 Address
|
||||
02 Magnitude. Signed byte.
|
||||
03 Offset. Signed byte.
|
||||
04 Phase. Val 00 = 0 deg, Val 40 = 90 degs.
|
||||
05-06 Period (little endian encoding, in ms)
|
||||
|
||||
** Interactive parameters **
|
||||
OP= 05
|
||||
LEN= 0a
|
||||
00-01 Address
|
||||
02 Positive Coeff
|
||||
03 Negative Coeff
|
||||
04+05 Offset (center)
|
||||
06+07 Dead band (Val 01F4 = 5000 (decimal))
|
||||
08 Positive saturation (Val 0a = 1000 (decimal) Val 64 = 10000 (decimal))
|
||||
09 Negative saturation
|
||||
|
||||
The encoding is a bit funny here: For coeffs, these are signed values. The
|
||||
maximum value is 64 (100 decimal), the min is 9c.
|
||||
For the offset, the minimum value is FE0C, the maximum value is 01F4.
|
||||
For the deadband, the minimum value is 0, the max is 03E8.
|
||||
|
||||
** Controls **
|
||||
OP= 41
|
||||
LEN= 03
|
||||
00 Channel
|
||||
01 Start/Stop
|
||||
Val 00: Stop
|
||||
Val 01: Start and play once.
|
||||
Val 41: Start and play n times (See byte 02 below)
|
||||
02 Number of iterations n.
|
||||
|
||||
** Init **
|
||||
|
||||
*** Querying features ***
|
||||
OP= ff
|
||||
Query command. Length varies according to the query type.
|
||||
The general format of this packet is:
|
||||
ff 01 QUERY [INDEX] CHECKSUM
|
||||
reponses are of the same form:
|
||||
FF LEN QUERY VALUE_QUERIED CHECKSUM2
|
||||
where LEN = 1 + length(VALUE_QUERIED)
|
||||
|
||||
**** Query ram size ****
|
||||
QUERY = 42 ('B'uffer size)
|
||||
The device should reply with the same packet plus two additionnal bytes
|
||||
containing the size of the memory:
|
||||
ff 03 42 03 e8 CS would mean that the device has 1000 bytes of ram available.
|
||||
|
||||
**** Query number of effects ****
|
||||
QUERY = 4e ('N'umber of effects)
|
||||
The device should respond by sending the number of effects that can be played
|
||||
at the same time (one byte)
|
||||
ff 02 4e 14 CS would stand for 20 effects.
|
||||
|
||||
**** Vendor's id ****
|
||||
QUERY = 4d ('M'anufacturer)
|
||||
Query the vendors'id (2 bytes)
|
||||
|
||||
**** Product id *****
|
||||
QUERY = 50 ('P'roduct)
|
||||
Query the product id (2 bytes)
|
||||
|
||||
**** Open device ****
|
||||
QUERY = 4f ('O'pen)
|
||||
No data returned.
|
||||
|
||||
**** Close device *****
|
||||
QUERY = 43 ('C')lose
|
||||
No data returned.
|
||||
|
||||
**** Query effect ****
|
||||
QUERY = 45 ('E')
|
||||
Send effect type.
|
||||
Returns nonzero if supported (2 bytes)
|
||||
|
||||
**** Firmware Version ****
|
||||
QUERY = 56 ('V'ersion)
|
||||
Sends back 3 bytes - major, minor, subminor
|
||||
|
||||
*** Initialisation of the device ***
|
||||
|
||||
**** Set Control ****
|
||||
!!! Device dependent, can be different on different models !!!
|
||||
OP= 40 <idx> <val> [<val>]
|
||||
LEN= 2 or 3
|
||||
00 Idx
|
||||
Idx 00 Set dead zone (0..2048)
|
||||
Idx 01 Ignore Deadman sensor (0..1)
|
||||
Idx 02 Enable comm watchdog (0..1)
|
||||
Idx 03 Set the strength of the spring (0..100)
|
||||
Idx 04 Enable or disable the spring (0/1)
|
||||
Idx 05 Set axis saturation threshold (0..2048)
|
||||
|
||||
**** Set Effect State ****
|
||||
OP= 42 <val>
|
||||
LEN= 1
|
||||
00 State
|
||||
Bit 3 Pause force feedback
|
||||
Bit 2 Enable force feedback
|
||||
Bit 0 Stop all effects
|
||||
|
||||
**** Set overall gain ****
|
||||
OP= 43 <val>
|
||||
LEN= 1
|
||||
00 Gain
|
||||
Val 00 = 0%
|
||||
Val 40 = 50%
|
||||
Val 80 = 100%
|
||||
|
||||
** Parameter memory **
|
||||
|
||||
Each device has a certain amount of memory to store parameters of effects.
|
||||
The amount of RAM may vary, I encountered values from 200 to 1000 bytes. Below
|
||||
is the amount of memory apparently needed for every set of parameters:
|
||||
- period : 0c
|
||||
- magnitude : 02
|
||||
- attack and fade : 0e
|
||||
- interactive : 08
|
||||
|
||||
** Appendix: How to study the protocol ? **
|
||||
|
||||
1. Generate effects using the force editor provided with the DirectX SDK, or use Immersion Studio (freely available at their web site in the developer section: www.immersion.com)
|
||||
2. Start a soft spying RS232 or USB (depending on where you connected your joystick/wheel). I used ComPortSpy from fCoder (alpha version!)
|
||||
3. Play the effect, and watch what happens on the spy screen.
|
||||
|
||||
A few words about ComPortSpy:
|
||||
At first glance, this soft seems, hum, well... buggy. In fact, data appear with a few seconds latency. Personnaly, I restart it every time I play an effect.
|
||||
Remember it's free (as in free beer) and alpha!
|
||||
|
||||
** URLS **
|
||||
Check www.immerse.com for Immersion Studio, and www.fcoder.com for ComPortSpy.
|
||||
|
||||
** Author of this document **
|
||||
Johann Deneux <deneux@ifrance.com>
|
||||
Home page at http://www.esil.univ-mrs.fr/~jdeneux/projects/ff/
|
||||
|
||||
Additions by Vojtech Pavlik.
|
||||
|
||||
I-Force is trademark of Immersion Corp.
|
||||
|
||||
@@ -468,9 +468,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Format:
|
||||
<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
|
||||
|
||||
cpia_pp= [HW,PPT]
|
||||
Format: { parport<nr> | auto | none }
|
||||
|
||||
crashkernel=nn[KMG]@ss[KMG]
|
||||
[KNL] Reserve a chunk of physical memory to
|
||||
hold a kernel to switch to with kexec on panic.
|
||||
@@ -952,14 +949,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Format: <1-256>
|
||||
|
||||
maxcpus= [SMP] Maximum number of processors that an SMP kernel
|
||||
should make use of.
|
||||
Using "nosmp" or "maxcpus=0" will disable SMP
|
||||
entirely (the MPS table probe still happens, though).
|
||||
A command-line option of "maxcpus=<NUM>", where <NUM>
|
||||
is an integer greater than 0, limits the maximum number
|
||||
of CPUs activated in SMP mode to <NUM>.
|
||||
Using "maxcpus=1" on an SMP kernel is the trivial
|
||||
case of an SMP kernel with only one CPU.
|
||||
should make use of. maxcpus=n : n >= 0 limits the
|
||||
kernel to using 'n' processors. n=0 is a special case,
|
||||
it is equivalent to "nosmp", which also disables
|
||||
the IO APIC.
|
||||
|
||||
max_addr=[KMG] [KNL,BOOT,ia64] All physical memory greater than or
|
||||
equal to this physical address is ignored.
|
||||
@@ -1184,7 +1177,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
nosep [BUGS=X86-32] Disables x86 SYSENTER/SYSEXIT support.
|
||||
|
||||
nosmp [SMP] Tells an SMP kernel to act as a UP kernel.
|
||||
nosmp [SMP] Tells an SMP kernel to act as a UP kernel,
|
||||
and disable the IO APIC. legacy for "maxcpus=0".
|
||||
|
||||
nosoftlockup [KNL] Disable the soft-lockup detector.
|
||||
|
||||
@@ -1826,6 +1820,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
-1: disable all active trip points in all thermal zones
|
||||
<degrees C>: override all lowest active trip points
|
||||
|
||||
thermal.crt= [HW,ACPI]
|
||||
-1: disable all critical trip points in all thermal zones
|
||||
<degrees C>: lower all critical trip points
|
||||
|
||||
thermal.nocrt= [HW,ACPI]
|
||||
Set to disable actions on ACPI thermal zone
|
||||
critical and hot trip points.
|
||||
|
||||
623
Documentation/ko_KR/HOWTO
Normal file
623
Documentation/ko_KR/HOWTO
Normal file
@@ -0,0 +1,623 @@
|
||||
NOTE:
|
||||
This is a version of Documentation/HOWTO translated into korean
|
||||
This document is maintained by minchan Kim < minchan.kim@gmail.com>
|
||||
If you find any difference between this document and the original file or
|
||||
a problem with the translation, please contact the maintainer of this file.
|
||||
|
||||
Please also note that the purpose of this file is to be easier to
|
||||
read for non English (read: korean) speakers and is not intended as
|
||||
a fork. So if you have any comments or updates for this file please
|
||||
try to update the original English file first.
|
||||
|
||||
==================================
|
||||
이 문서는
|
||||
Documentation/HOWTO
|
||||
의 한글 번역입니다.
|
||||
|
||||
역자： 김민찬 <minchan.kim@gmail.com >
|
||||
감수： 이제이미 <jamee.lee@samsung.com>
|
||||
==================================
|
||||
|
||||
어떻게 리눅스 커널 개발을 하는가
|
||||
---------------------------------
|
||||
|
||||
이 문서는 커널 개발에 있어 가장 중요한 문서이다. 이 문서는
|
||||
리눅스 커널 개발자가 되는 법과 리눅스 커널 개발 커뮤니티와 일하는
|
||||
법을 담고있다. 커널 프로그래밍의기술적인 측면과 관련된 내용들은
|
||||
포함하지 않으려고 하였지만 올바으로 여러분을 안내하는 데 도움이
|
||||
될 것이다.
|
||||
|
||||
이 문서에서 오래된 것을 발견하면 문서의 아래쪽에 나열된 메인트너에게
|
||||
패치를 보내달라.
|
||||
|
||||
|
||||
소개
|
||||
----
|
||||
|
||||
자, 여러분은 리눅스 커널 개발자가 되는 법을 배우고 싶은가? 아니면
|
||||
상사로부터"이 장치를 위한 리눅스 드라이버를 작성하시오"라는 말을
|
||||
들었는가? 이 문서는 여러분이 겪게 될 과정과 커뮤니티와 일하는 법을
|
||||
조언하여 여러분의 목적을 달성하기 위해 필요한 것 모두를 알려주는
|
||||
것이다.
|
||||
|
||||
커널은 대부분은 C로 작성되었어고 몇몇 아키텍쳐의 의존적인 부분은
|
||||
어셈블리로 작성되었다. 커널 개발을 위해 C를 잘 이해하고 있어야 한다.
|
||||
여러분이 특정 아키텍쳐의 low-level 개발을 할 것이 아니라면
|
||||
어셈블리(특정 아키텍쳐)는 잘 알아야 할 필요는 없다.
|
||||
다음의 참고서적들은 기본에 충실한 C 교육이나 수년간의 경험에 견주지는
|
||||
못하지만 적어도 참고 용도로는 좋을 것이다
|
||||
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
|
||||
- "Practical C Programming" by Steve Oualline [O'Reilly]
|
||||
- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
|
||||
|
||||
커널은 GNU C와 GNU 툴체인을 사용하여 작성되었다. 이 툴들은 ISO C89 표준을
|
||||
따르는 반면 표준에 있지 않은 많은 확장기능도 가지고 있다. 커널은 표준 C
|
||||
라이브러리와는 관계없이 freestanding C 환경이어서 C 표준의 일부는
|
||||
지원되지 않는다. 임의의 long long 나누기나 floating point는 지원되지 않는다.
|
||||
때론 이런 이유로 커널이 그런 확장 기능을 가진 툴체인을 가지고 만들어졌다는
|
||||
것이 이해하기 어려울 수도 있고 게다가 불행하게도 그런 것을 정확하게 설명하는
|
||||
어떤 참고문서도 있지 않다. 정보를 얻기 위해서는 gcc info (`info gcc`)페이지를
|
||||
살펴보라.
|
||||
|
||||
여러분은 기존의 개발 커뮤니티와 일하는 법을 배우려고 하고 있다는 것을
|
||||
기억하라. 코딩, 스타일, 절차에 관한 훌륭한 표준을 가진 사람들이 모인
|
||||
다양한 그룹이 있다. 이 표준들은 오랜동안 크고 지역적으로 분산된 팀들에
|
||||
의해 가장 좋은 방법으로 일하기위하여 찾은 것을 기초로 만들어져왔다.
|
||||
그 표준들은 문서화가 잘 되어 있기 때문에 가능한한 미리 많은 표준들에
|
||||
관하여 배우려고 시도하라. 다른 사람들은 여러분이나 여러분의 회사가
|
||||
일하는 방식에 적응하는 것을 원하지는 않는다.
|
||||
|
||||
|
||||
법적 문제
|
||||
---------
|
||||
|
||||
리눅스 커널 소스 코드는 GPL로 배포(release)되었다. 소스트리의 메인
|
||||
디렉토리에 있는 라이센스에 관하여 상세하게 쓰여 있는 COPYING이라는
|
||||
파일을 봐라.여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면
|
||||
리눅스 커널 메일링 리스트에 묻지말고 변호사와 연락하라. 메일링
|
||||
리스트들에 있는 사람들은 변호사가 아니기 때문에 법적 문제에 관하여
|
||||
그들의 말에 의지해서는 안된다.
|
||||
|
||||
GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
|
||||
http://www.gnu.org/licenses/gpl-faq.html
|
||||
|
||||
|
||||
문서
|
||||
----
|
||||
|
||||
리눅스 커널 소스 트리는 커널 커뮤니티와 일하는 법을 배우기 위한 많은
|
||||
귀중한 문서들을 가지고 있다. 새로운 기능들이 커널에 들어가게 될 때,
|
||||
그 기능을 어떻게 사용하는지에 관한 설명을 위하여 새로운 문서 파일을
|
||||
추가하는 것을 권장한다. 커널이 유저스페이스로 노출하는 인터페이스를
|
||||
변경하게 되면 변경을 설명하는 메뉴얼 페이지들에 대한 패치나 정보를
|
||||
mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다.
|
||||
|
||||
다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다.
|
||||
README
|
||||
이 파일은 리눅스 커널에 관하여 간단한 배경 설명과 커널을 설정하고
|
||||
빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서
|
||||
시작해야 한다.
|
||||
|
||||
Documentation/Changes
|
||||
이 파일은 커널을 성공적으로 빌드하고 실행시키기 위해 필요한 다양한
|
||||
소프트웨어 패키지들의 최소 버젼을 나열한다.
|
||||
|
||||
Documentation/CodingStyle
|
||||
이 문서는 리눅스 커널 코딩 스타일과 그렇게 한 몇몇 이유를 설명한다.
|
||||
모든 새로운 코드는 이 문서에 가이드라인들을 따라야 한다. 대부분의
|
||||
메인트너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이
|
||||
그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다.
|
||||
|
||||
Documentation/SubmittingPatches
|
||||
Documentation/SubmittingDrivers
|
||||
이 파일들은 성공적으로 패치를 만들고 보내는 법을 다음의 내용들로
|
||||
굉장히 상세히 설명하고 있다(그러나 다음으로 한정되진 않는다).
|
||||
- Email 내용들
|
||||
- Email 양식
|
||||
- 그것을 누구에게 보낼지
|
||||
이러한 규칙들을 따르는 것이 성공을 보장하진 않는다(왜냐하면 모든
|
||||
패치들은 내용과 스타일에 관하여 면밀히 검토되기 때문이다).
|
||||
그러나 규칙을 따르지 않는다면 거의 성공하지도 못할 것이다.
|
||||
|
||||
올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다.
|
||||
"The Perfect Patch"
|
||||
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
|
||||
"Linux kernel patch submission format"
|
||||
http://linux.yyz.us/patch-format.html
|
||||
|
||||
Documentation/stable_api_nonsense.txt
|
||||
이 문서는 의도적으로 커널이 변하지 않는 API를 갖지 않도록 결정한
|
||||
이유를 설명하며 다음과 같은 것들을 포함한다.
|
||||
- 서브시스템 shim-layer(호환성을 위해?)
|
||||
- 운영 체제들 간의 드라이버 이식성
|
||||
- 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것)
|
||||
이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서
|
||||
리눅스로 옮겨오는 사람들에게는 매우 중요하다.
|
||||
|
||||
|
||||
Documentation/SecurityBugs
|
||||
여러분들이 리눅스 커널의 보안 문제를 발견했다고 생각한다면 이 문서에
|
||||
나온 단계에 따라서 커널 개발자들에게 알리고 그 문제를 해결할 수 있도록
|
||||
도와 달라.
|
||||
|
||||
Documentation/ManagementStyle
|
||||
이 문서는 리눅스 커널 메인트너들이 어떻게 그들의 방법론의 정신을
|
||||
어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는
|
||||
모든 사람들(또는 커널 개발에 작은 호기심이라도 있는 사람들)이
|
||||
읽어야 할 중요한 문서이다. 왜냐하면 이 문서는 커널 메인트너들의
|
||||
독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기
|
||||
때문이다.
|
||||
|
||||
Documentation/stable_kernel_rules.txt
|
||||
이 문서는 안정적인 커널 배포가 이루어지는 규칙을 설명하고 있으며
|
||||
여러분들이 이러한 배포들 중 하나에 변경을 하길 원한다면
|
||||
무엇을 해야 하는지를 설명한다.
|
||||
|
||||
Documentation/kernel-docs.txt
|
||||
커널 개발에 관계된 외부 문서의 리스트이다. 커널 내의 포함된 문서들
|
||||
중에 여러분이 찾고 싶은 문서를 발견하지 못할 경우 이 리스트를
|
||||
살펴보라.
|
||||
|
||||
Documentation/applying-patches.txt
|
||||
패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게
|
||||
적용하는지에 관하여 자세히 설명 하고 있는 좋은 입문서이다.
|
||||
|
||||
커널은 소스 코드 그 자체에서 자동적으로 만들어질 수 있는 많은 문서들을
|
||||
가지고 있다. 이것은 커널 내의 API에 대한 모든 설명, 그리고 락킹을
|
||||
올바르게 처리하는 법에 관한 규칙을 포함하고 있다. 이 문서는
|
||||
Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, HTML,
|
||||
그리고 man 페이지들로 다음과 같이 실행하여 만들어 진다.
|
||||
make pdfdocs
|
||||
make psdocs
|
||||
make htmldocs
|
||||
make mandocs
|
||||
각각의 명령을 메인 커널 소스 디렉토리로부터 실행한다.
|
||||
|
||||
|
||||
커널 개발자가 되는 것
|
||||
---------------------
|
||||
|
||||
여러분이 리눅스 커널 개발에 관하여 아무것도 모른다면 Linux KernelNewbies
|
||||
프로젝트를 봐야 한다.
|
||||
http://kernelnewbies.org
|
||||
그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저
|
||||
아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할수있는 도움이
|
||||
될만한 메일링 리스트가 있다. 또한 실시간으로 질문 할수 있는 IRC 채널도
|
||||
가지고 있으며 리눅스 커널 개발을 배우는 데 유용한 문서들을 보유하고 있다.
|
||||
|
||||
웹사이트는 코드구성, 서브시스템들, 그리고 현재 프로젝트들
|
||||
(트리 내, 외부에 존재하는)에 관한 기본적인 정보들을 가지고 있다. 또한
|
||||
그곳은 커널 컴파일이나 패치를 하는 법과 같은 기본적인 것들을 설명한다.
|
||||
|
||||
여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수
|
||||
있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라.
|
||||
http://janitor.kernelnewbies.org/
|
||||
그곳은 시작하기에 아주 딱 좋은 곳이다. 그곳은 리눅스 커널 소스 트리내에
|
||||
간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이
|
||||
프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에
|
||||
반영하기 위한 기본적인 것들을 배우게 될것이며 여러분이 아직 아이디어를
|
||||
가지고 있지 않다면 다음에 무엇을 해야할지에 관한 방향을 배울 수 있을
|
||||
것이다.
|
||||
|
||||
여러분들이 이미 커널 트리에 반영하길 원하는 코드 묶음을 가지고 있지만
|
||||
올바른 포맷으로 포장하는데 도움이 필요하다면 그러한 문제를 돕기 위해
|
||||
만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며
|
||||
다음에서 참조할 수 있다.
|
||||
http://selenic.com/mailman/listinfo/kernel-mentors
|
||||
|
||||
리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게
|
||||
동작하는지 이해하고 있어야 한다. 코드를 분석하기 위하여 특정한 툴의
|
||||
도움을 빌려서라도 코드를 직접 읽는 것보다 좋은 것은 없다(대부분의
|
||||
자잘한 부분들은 잘 코멘트되어 있다). 그런 툴들 중에 특히 추천할만한
|
||||
것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며
|
||||
소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
|
||||
코드 저장소는 다음을 통하여 참조할 수 있다.
|
||||
http://sosdg.org/~coywolf/lxr/
|
||||
|
||||
|
||||
개발 프로세스
|
||||
-------------
|
||||
|
||||
리눅스 커널 개발 프로세스는 현재 몇몇 다른 메인 커널 "브랜치들"과
|
||||
서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인
|
||||
브랜치들은 다음과 같다.
|
||||
- main 2.6.x 커널 트리
|
||||
- 2.6.x.y - 안정된 커널 트리
|
||||
- 2.6.x -git 커널 패치들
|
||||
- 2.6.x -mm 커널 패치들
|
||||
- 서브시스템을 위한 커널 트리들과 패치들
|
||||
|
||||
2.6.x 커널 트리
|
||||
---------------
|
||||
|
||||
2.6.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v2.6/
|
||||
디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
|
||||
- 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
|
||||
메인트너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
|
||||
몇 주 동안 -mm 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데
|
||||
선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은 http://git.or.cz/
|
||||
에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내도
|
||||
것도 무관하다.
|
||||
- 2주 후에 -rc1 커널이 배포되며 지금부터는 전체 커널의 안정성에 영향을
|
||||
미칠수 있는 새로운 기능들을 포함하지 않는 패치들만을 추가될 수 있다.
|
||||
완전히 새로운 드라이버(혹은 파일시스템)는 -rc1 이후에만 받아들여진다는
|
||||
것을 기억해라. 왜냐하면 변경이 자체내에서만 발생하고 추가된 코드가
|
||||
드라이버 외부의 다른 부분에는 영향을 주지 않으므로 그런 변경은
|
||||
퇴보(regression)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이
|
||||
배포된 이후에 git를 사용하여 패치들을 Linus에게 보낼수 있지만 패치들은
|
||||
공식적인 메일링 리스트로 보내서 검토를 받을 필요가 있다.
|
||||
- 새로운 -rc는 Linus는 현재 git tree가 테스트 하기에 충분히 안정된 상태에
|
||||
있다고 판단될 때마다 배포된다. 목표는 새로운 -rc 커널을 매주 배포하는
|
||||
것이다.
|
||||
- 이러한 프로세스는 커널이 "준비"되었다고 여겨질때까지 계속된다.
|
||||
프로세스는 대체로 6주간 지속된다.
|
||||
- 각 -rc 배포에 있는 알려진 퇴보의 목록들은 다음 URI에 남겨진다.
|
||||
http://kernelnewbies.org/known_regressions
|
||||
|
||||
커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의
|
||||
Andrew Morton의 글이 있다.
|
||||
"커널이 언제 배포될지는 아무로 모른다. 왜냐하면 배포는 알려진
|
||||
버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라
|
||||
배포되는 것은 아니기 때문이다."
|
||||
|
||||
2.6.x.y - 안정 커널 트리
|
||||
------------------------
|
||||
|
||||
4 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 2.6.x
|
||||
커널에서 발견된 큰 퇴보들이나 보안 문제들 중 비교적 작고 중요한 수정들을
|
||||
포함한다.
|
||||
|
||||
이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며,
|
||||
개발/실험적 버젼을 테스트하는 것을 돕는데는 별로 관심이 없다.
|
||||
|
||||
어떤 2.6.x.y 커널도 사용가능하지 않다면 그때는 가장 높은 숫자의 2.6.x
|
||||
커널이 현재의 안정 커널이다.
|
||||
|
||||
2.6.x.y는 "stable" 팀<stable@kernel.org>에 의해 관리되며 거의 매번 격주로
|
||||
배포된다.
|
||||
|
||||
커널 트리 문서들 내에 Documentation/stable_kernel_rules.txt 파일은 어떤
|
||||
종류의 변경들이 -stable 트리로 들어왔는지와 배포 프로세스가 어떻게
|
||||
진행되는지를 설명한다.
|
||||
|
||||
|
||||
2.6.x -git 패치들
|
||||
------------------
|
||||
git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의
|
||||
커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며
|
||||
Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도
|
||||
살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다.
|
||||
|
||||
2.6.x -mm 커널 패치들
|
||||
---------------------
|
||||
Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는 모든 다른
|
||||
서브시스템 커널 트리와 패치들을 가져와서 리눅스 커널 메일링 리스트로
|
||||
온 많은 패치들과 한데 묶는다. 이 트리는 새로운 기능들과 패치들을 위한
|
||||
장소를 제공하는 역할을 한다. 하나의 패치가 -mm에 한동안 있으면서 그 가치가
|
||||
증명되게 되면 Andrew나 서브시스템 메인트너는 그것을 메인라인에 포함시키기
|
||||
위하여 Linus에게 보낸다.
|
||||
|
||||
커널 트리에 포함하고 싶은 모든 새로운 패치들은 Linus에게 보내지기 전에
|
||||
-mm 트리에서 테스트를 하는 것을 적극 추천한다.
|
||||
|
||||
이 커널들은 안정되게 사용할 시스템에서에 실행하는 것은 적합하지 않으며
|
||||
다른 브랜치들의 어떤 것들보다 위험하다.
|
||||
|
||||
여러분이 커널 개발 프로세스를 돕길 원한다면 이 커널 배포들을 사용하고
|
||||
테스트한 후 어떤 문제를 발견하거나 또는 모든 것이 잘 동작한다면 리눅스
|
||||
커널 메일링 리스트로 피드백을 해달라.
|
||||
|
||||
이 커널들은 일반적으로 모든 다른 실험적인 패치들과 배포될 당시의
|
||||
사용가능한 메인라인 -git 커널들의 몇몇 변경을 포함한다.
|
||||
|
||||
-mm 커널들은 정해진 일정대로 배포되지 않는다. 하지만 대개 몇몇 -mm 커널들은
|
||||
각 -rc 커널(1부터 3이 흔함) 사이에서 배포된다.
|
||||
|
||||
서브시스템 커널 트리들과 패치들
|
||||
-------------------------------
|
||||
많은 다른 커널 서브시스템 개발자들은 커널의 다른 부분들에서 무슨 일이
|
||||
일어나고 있는지를 볼수 있도록 그들의 개발 트리를 공개한다. 이 트리들은
|
||||
위에서 설명하였던 것 처럼 -mm 커널 배포들로 합쳐진다.
|
||||
|
||||
다음은 활용가능한 커널 트리들을 나열한다.
|
||||
git trees:
|
||||
- Kbuild development tree, Sam Ravnborg < sam@ravnborg.org>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
|
||||
|
||||
- ACPI development tree, Len Brown <len.brown@intel.com >
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
|
||||
|
||||
- Block development tree, Jens Axboe <axboe@suse.de>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
|
||||
|
||||
- DRM development tree, Dave Airlie <airlied@linux.ie>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
|
||||
|
||||
- ia64 development tree, Tony Luck < tony.luck@intel.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
|
||||
|
||||
- infiniband, Roland Dreier <rolandd@cisco.com >
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
|
||||
|
||||
- libata, Jeff Garzik <jgarzik@pobox.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
|
||||
|
||||
- network drivers, Jeff Garzik <jgarzik@pobox.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
|
||||
|
||||
- pcmcia, Dominik Brodowski < linux@dominikbrodowski.net>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
|
||||
|
||||
- SCSI, James Bottomley < James.Bottomley@SteelEye.com>
|
||||
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
|
||||
|
||||
quilt trees:
|
||||
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman < gregkh@suse.de>
|
||||
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
- x86-64, partly i386, Andi Kleen < ak@suse.de>
|
||||
ftp.firstfloor.org:/pub/ak/x86_64/quilt/
|
||||
|
||||
다른 커널 트리들은 http://kernel.org/git와 MAINTAINERS 파일에서 참조할 수
|
||||
있다.
|
||||
|
||||
버그 보고
|
||||
---------
|
||||
bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다.
|
||||
사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다.
|
||||
kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
|
||||
http://test.kernel.org/bugzilla/faq.html
|
||||
|
||||
메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그일 것 같은
|
||||
것을 보고하는는 법에 관한 좋은 템플릿이고 문제를 추적하기 위해서 커널
|
||||
개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 있다.
|
||||
|
||||
|
||||
버그 리포트들의 관리
|
||||
--------------------
|
||||
|
||||
여러분의 해킹 기술을 연습하는 가장 좋은 방법 중의 하는 다른 사람들이
|
||||
보고한 버그들을 수정하는 것이다. 여러분은 커널을 더욱 안정화시키는데
|
||||
도움을 줄 뿐만이 아니라 실제있는 문제들을 수정하는 법을 배우게 되고
|
||||
그와 함께 여러분들의 기술은 향상될 것이며 다른 개발자들이 여러분의
|
||||
존재에 대해 알게 될 것이다. 버그를 수정하는 것은 개발자들 사이에서
|
||||
점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은
|
||||
다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.
|
||||
|
||||
이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernelorg를
|
||||
참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
|
||||
bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다)
|
||||
bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다)
|
||||
에 등록하면 된다.
|
||||
|
||||
http://lists.osdl.org/mailman/listinfo/bugme-new
|
||||
http://lists.osdl.org/mailman/listinfo/bugme-janitors
|
||||
|
||||
|
||||
|
||||
메일링 리스트들
|
||||
---------------
|
||||
|
||||
위의 몇몇 문서들이 설명하였지만 핵심 커널 개발자들의 대다수는
|
||||
리눅스 커널 메일링 리스트에 참여하고 있다. 리스트에 등록하고 해지하는
|
||||
방법에 관한 자세한 사항은 다음에서 참조할 수 있다.
|
||||
http://vger.kernel.org/vger-lists.html#linux-kernel
|
||||
웹상의 많은 다른 곳에도 메일링 리스트의 아카이브들이 있다.
|
||||
이러한 아카이브들을 찾으려면 검색 엔진을 사용하라. 예를 들어:
|
||||
http://dir.gmane.org/gmane.linux.kernel
|
||||
여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 대한
|
||||
것을 아카이브에서 먼저 찾기를 강력히 권장한다. 이미 상세하게 토론된 많은
|
||||
것들이 메일링 리스트의 아카이브에 기록되어 있다.
|
||||
|
||||
각각의 커널 서브시스템들의 대부분은 자신들의 개발에 관한 노력들로 이루어진
|
||||
분리된 메일링 리스트를 따로 가지고 있다. 다른 그룹들이 무슨 리스트를 가지고
|
||||
있는지는 MAINTAINERS 파일을 참조하라.
|
||||
|
||||
많은 리스트들은 kernel.org에서 호스트되고 있다. 그 정보들은 다음에서 참조될 수 있다.
|
||||
http://vger.kernel.org/vger-lists.html
|
||||
|
||||
리스트들을 사용할 때는 올바른 예절을 따를 것을 유념해라.
|
||||
대단하진 않지만 다음 URL은 리스트(혹은 모든 리스트)와 대화하는 몇몇 간단한
|
||||
가이드라인을 가지고 있다.
|
||||
http://www.albion.com/netiquette/
|
||||
|
||||
여러 사람들이 여러분의 메일에 응답한다면 CC: 즉 수신 리스트는 꽤 커지게
|
||||
될 것이다. 아무 이유없이 CC에서 어떤 사람도 제거하거나 리스트 주소로만
|
||||
회신하지 마라. 메일을 보낸 사람으로서 하나를 받고 리스트로부터 또
|
||||
하나를 받아 두번 받는 것에 익숙하여 있으니 mail-header를 조작하려고 하지
|
||||
말아라. 사람들은 그런 것을 좋아하지 않을 것이다.
|
||||
|
||||
여러분의 회신의 문맥을 원래대로 유지해야 한다. 여러분들의 회신의 윗부분에
|
||||
"John 커널해커는 작성했다...."를 유지하며 여러분들의 의견을 그 메일의 윗부분에
|
||||
작성하지 말고 각 인용한 단락들 사이에 넣어라.
|
||||
|
||||
여러분들이 패치들을 메일에 넣는다면 그것들은 Documentation/SubmittingPatches에
|
||||
나와있는데로 명백히(plain) 읽을 수 있는 텍스트여야 한다. 커널 개발자들은
|
||||
첨부파일이나 압축된 패치들을 원하지 않는다. 그들은 여러분들의 패치의
|
||||
각 라인 단위로 코멘트를 하길 원하며 압축하거나 첨부하지 않고 보내는 것이
|
||||
그렇게 할 수 있는 유일한 방법이다. 여러분들이 사용하는 메일 프로그램이
|
||||
스페이스나 탭 문자들을 조작하지 않는지 확인하라. 가장 좋은 첫 테스트는
|
||||
메일을 자신에게 보내보고 스스로 그 패치를 적용해보라. 그것이 동작하지
|
||||
않는다면 여러분의 메일 프로그램을 고치던가 제대로 동작하는 프로그램으로
|
||||
바꾸어라.
|
||||
|
||||
무엇보다도 메일링 리스트의 다른 구독자들에게 보여주려 한다는 것을 기억하라.
|
||||
|
||||
|
||||
커뮤니티와 일하는 법
|
||||
--------------------
|
||||
|
||||
커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이
|
||||
받아들여질 패치를 제출하게 되면 그 패치의 기술적인 이점으로 검토될 것이다.
|
||||
그럼 여러분들은 무엇을 기대하고 있어야 하는가?
|
||||
- 비판
|
||||
- 의견
|
||||
- 변경을 위한 요구
|
||||
- 당위성을 위한 요구
|
||||
- 고요
|
||||
|
||||
기억하라. 이것들은 여러분의 패치가 커널로 들어가기 위한 과정이다. 여러분의
|
||||
패치들은 비판과 다른 의견을 받을 수 있고 그것들을 기술적인 레벨로 평가하고
|
||||
재작업하거나 또는 왜 수정하면 안되는지에 관하여 명료하고 간결한 이유를
|
||||
말할 수 있어야 한다. 여러분이 제출한 것에 어떤 응답도 있지 않다면 몇 일을
|
||||
기다려보고 다시 시도해라. 때론 너무 많은 메일들 속에 묻혀버리기도 한다.
|
||||
|
||||
여러분은 무엇을 해서는 안되는가?
|
||||
- 여러분의 패치가 아무 질문 없이 받아들여지기를 기대하는 것
|
||||
- 방어적이 되는 것
|
||||
- 의견을 무시하는 것
|
||||
- 요청된 변경을 하지 않고 패치를 다시 제출하는 것
|
||||
|
||||
가능한한 가장 좋은 기술적인 해답을 찾고 있는 커뮤니티에서는 항상
|
||||
어떤 패치가 얼마나 좋은지에 관하여 다른 의견들이 있을 수 있다. 여러분은
|
||||
협조적이어야 하고 기꺼이 여러분의 생각을 커널 내에 맞추어야 한다. 아니면
|
||||
적어도 여러분의 것이 가치있다는 것을 중명하여야 한다. 잘못된 것도 여러분이
|
||||
올바른 방향의 해결책으로 이끌어갈 의지가 있다면 받아들여질 것이라는 점을
|
||||
기억하라.
|
||||
|
||||
여러분의 첫 패치에 여러분이 수정해야하는 십여개 정도의 회신이 오는
|
||||
경우도 흔하다. 이것은 여러분의 패치가 받아들여지지 않을 것이라는 것을
|
||||
의미하는 것이 아니고 개인적으로 여러분에게 감정이 있어서 그러는 것도
|
||||
아니다. 간단히 여러분의 패치에 제기된 문제들을 수정하고 그것을 다시
|
||||
보내라.
|
||||
|
||||
|
||||
커널 커뮤니티와 기업 조직간의 차이점
|
||||
-----------------------------------------------------------------
|
||||
커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의
|
||||
문제를 피하기 위한 목록이 있다.
|
||||
여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 :
|
||||
- " 이것은 여러 문제들을 해겹합니다."
|
||||
- "이것은 2000 라인의 코드를 제거합니다."
|
||||
- "이것은 내가 말하려는 것에 관해 설명하는 패치입니다."
|
||||
- "나는 5개의 다른 아키텍쳐에서 그것을 테스트했슴으로..."
|
||||
- "여기에 일련의 작은 패치들이 있습음로..."
|
||||
- "이것은 일반적인 머신에서 성능을 향상시키므로..."
|
||||
|
||||
여러분들이 말할 때 피해야 할 좋지 않은 것들 :
|
||||
- "우리를 그것을 AIT/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀립없다..."
|
||||
- "나는 20년동안 이것을 해왔다. 그러므로..."
|
||||
- "이것은 돈을 벌기위해 나의 회사가 필요로 하는 것이다."
|
||||
- "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다."
|
||||
- "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다."
|
||||
- "나는 6달동안 이것을 했으니..."
|
||||
- "여기세 5000라인 짜리 패치가 있으니..."
|
||||
- "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..."
|
||||
- "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다."
|
||||
|
||||
커널 커뮤니티가 전통적인 소프트웨어 엔지니어링 개발 환경들과
|
||||
또 다른 점은 얼굴을 보지 않고 일한다는 점이다. 이메일과 irc를 대화의
|
||||
주요수단으로 사용하는 것의 한가지 장점은 성별이나 인종의 차별이
|
||||
없다는 것이다. 리눅스 커널의 작업 환경에서는 단지 이메일 주소만
|
||||
알수 있기 때문에 여성과 소수 민족들도 모두 받아들여진다. 국제적으로
|
||||
일하게 되는 측면은 사람의 이름에 근거하여 성별을 추측할 수 없게
|
||||
하기때문에 차별을 없애는 데 도움을 준다. Andrea라는 이름을 가진 남자와
|
||||
Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅스 커널에서
|
||||
작업하며 생각을 표현해왔던 대부분의 여성들은 긍정적인 경험을 가지고
|
||||
있다.
|
||||
|
||||
언어 장벽은 영어에 익숙하지 않은 몇몇 사람들에게 문제가 될 수도 있다.
|
||||
언어의 훌륭한 구사는 메일링 리스트에서 올바르게 자신의 생각을
|
||||
표현하기 위하여 필요하다. 그래서 여러분은 이메일을 보내기 전에
|
||||
영어를 올바르게 사용하고 있는지를 체크하는 것이 바람직하다.
|
||||
|
||||
|
||||
여러분의 변경을 나누어라
|
||||
------------------------
|
||||
|
||||
리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음을 쉽게
|
||||
받아들이지 않는다. 변경은 적절하게 소개되고, 검토되고, 각각의
|
||||
부분으로 작게 나누어져야 한다. 이것은 회사에서 하는 것과는 정확히
|
||||
반대되는 것이다. 여러분들의 제안은 개발 초기에 일찍이 소개되야 한다.
|
||||
그래서 여러분들은 자신이 하고 있는 것에 관하여 피드백을 받을 수 있게
|
||||
된다. 커뮤니티가 여러분들이 커뮤니티와 함께 일하고 있다는 것을
|
||||
느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로서
|
||||
사용되지 않고 있다는 것을 느끼게 하자. 그러나 메일링 리스트에 한번에
|
||||
50개의 이메일을 보내지는 말아라. 여러분들의 일련의 패치들은 항상
|
||||
더 작아야 한다.
|
||||
|
||||
패치를 나누는 이유는 다음과 같다.
|
||||
|
||||
1) 작은 패치들은 여러분의 패치들이 적용될 수 있는 확률을 높여준다.
|
||||
왜냐하면 다른 사람들은 정확성을 검증하기 위하여 많은 시간과 노력을
|
||||
들이기를 원하지 않는다. 5줄의 패치는 메인트너가 거의 몇 초간 힐끗
|
||||
보면 적용될 수 있다. 그러나 500 줄의 패치는 정확성을 검토하기 위하여
|
||||
몇시간이 걸릴 수도 있다(걸리는 시간은 패치의 크기 혹은 다른 것에
|
||||
비례하여 기하급수적으로 늘어난다).
|
||||
|
||||
패치를 작게 만드는 것은 무엇인가 잘못되었을 때 디버그하는 것을
|
||||
쉽게 만든다. 즉, 그렇게 만드는 것은 매우 큰 패치를 적용한 후에
|
||||
조사하는 것 보다 작은 패치를 적용한 후에 (그리고 몇몇의 것이
|
||||
깨졌을 때) 하나씩 패치들을 제거해가며 디버그 하기 쉽도록 만들어 준다.
|
||||
|
||||
2) 작은 패치들을 보내는 것뿐만 아니라 패치들을 제출하기전에 재작성하고
|
||||
간단하게(혹은 간단한게 재배치하여) 하는 것도 중요하다.
|
||||
|
||||
여기에 커널 개발자 Al Viro의 이야기가 있다.
|
||||
"학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이
|
||||
답을 얻을때까지 겪은 시행착오를 보길 원하지 않는다. 선생님들은
|
||||
간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고
|
||||
마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다.
|
||||
|
||||
커널 개발도 마찬가지이다. 메인트너들과 검토하는 사람들은 문제를
|
||||
풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은
|
||||
간결하고 멋진 답을 보길 원한다."
|
||||
|
||||
커뮤니티와 함께 일하며 뛰어난 답을 찾고 여러분들의 완성되지 않은 일들
|
||||
사이에 균형을 유지해야 하는 어려움이 있을 수 있다. 그러므로 프로세스의
|
||||
초반에 여러분의 일을 향상시키기위한 피드백을 얻는 것 뿐만 아니라
|
||||
여러분들의 변경들을 작은 묶음으로 유지해서 심지어는 여러분의 작업의
|
||||
모든 부분이 지금은 포함될 준비가 되어있지 않지만 작은 부분은 이미
|
||||
받아들여질 수 있도록 유지하는 것이 바람직하다.
|
||||
|
||||
또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들은 포함하는
|
||||
패치들은 받아들여지지 않을 것이라는 점을 유념하라.
|
||||
|
||||
변경을 정당화해라
|
||||
-----------------
|
||||
|
||||
여러분들의 나누어진 패치들을 리눅스 커뮤니티가 왜 반영해야 하는지를
|
||||
알도록 하는 것은 매우 중요하다. 새로운 기능들이 필요하고 유용하다는
|
||||
것은 반드시 그에 맞는 이유가 있어야 한다.
|
||||
|
||||
|
||||
변경을 문서화해라
|
||||
-----------------
|
||||
|
||||
여러분이 패치를 보내려 할때는 여러분이 무엇을 말하려고 하는지를 충분히
|
||||
생각하여 이메일을 작성해야 한다. 이 정보는 패치를 위한 ChangeLog가 될
|
||||
것이다. 그리고 항상 그 내용을 보길 원하는 모든 사람들을 위해 보존될
|
||||
것이다. 패치는 완벽하게 다음과 같은 내용들을 포함하여 설명해야 한다.
|
||||
- 변경이 왜 필요한지
|
||||
- 패치에 관한 전체 설계 어프로치
|
||||
- 구현 상세들
|
||||
- 테스트 결과들
|
||||
|
||||
이것이 무엇인지 더 자세한 것을 알고 싶다면 다음 문서의 ChageLog 항을 봐라.
|
||||
"The Perfect Patch"
|
||||
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
|
||||
|
||||
|
||||
|
||||
|
||||
이 모든 것을 하는 것은 매우 어려운 일이다. 완벽히 소화하는 데는 적어도 몇년이
|
||||
걸릴 수도 있다. 많은 인내와 결의가 필요한 계속되는 개선의 과정이다. 그러나
|
||||
가능한한 포기하지 말라. 많은 사람들은 이전부터 해왔던 것이고 그 사람들도
|
||||
정확하게 여러분들이 지금 서 있는 그 곳부터 시작했었다.
|
||||
|
||||
|
||||
|
||||
|
||||
----------
|
||||
"개발 프로세스"(http://linux.tar.gz/articles/2.6-development_process) 섹션을
|
||||
작성하는데 있어 참고할 문서를 사용하도록 허락해준 Paolo Ciarrocchi에게
|
||||
감사한다. 여러분들이 말해야 할 것과 말해서는 안되는 것의 목록 중 일부를 제공해준
|
||||
Randy Dunlap과 Gerrit Huizenga에게 감사한다. 또한 검토와 의견 그리고
|
||||
공헌을 아끼지 않은 Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
|
||||
Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen,
|
||||
Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
|
||||
David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard에게도 감사를 전한다.
|
||||
그들의 도움이 없었다면 이 문서는 존재하지 않았을 것이다.
|
||||
|
||||
|
||||
|
||||
메인트너: Greg Kroah-Hartman <greg@kroah.com>
|
||||
@@ -882,7 +882,7 @@ static u32 handle_block_output(int fd, const struct iovec *iov,
|
||||
* of the block file (possibly extending it). */
|
||||
if (off + len > device_len) {
|
||||
/* Trim it back to the correct length */
|
||||
ftruncate(dev->fd, device_len);
|
||||
ftruncate64(dev->fd, device_len);
|
||||
/* Die, bad Guest, die. */
|
||||
errx(1, "Write past end %llu+%u", off, len);
|
||||
}
|
||||
|
||||
120
Documentation/lockstat.txt
Normal file
120
Documentation/lockstat.txt
Normal file
@@ -0,0 +1,120 @@
|
||||
|
||||
LOCK STATISTICS
|
||||
|
||||
- WHAT
|
||||
|
||||
As the name suggests, it provides statistics on locks.
|
||||
|
||||
- WHY
|
||||
|
||||
Because things like lock contention can severely impact performance.
|
||||
|
||||
- HOW
|
||||
|
||||
Lockdep already has hooks in the lock functions and maps lock instances to
|
||||
lock classes. We build on that. The graph below shows the relation between
|
||||
the lock functions and the various hooks therein.
|
||||
|
||||
__acquire
|
||||
|
|
||||
lock _____
|
||||
| \
|
||||
| __contended
|
||||
| |
|
||||
| <wait>
|
||||
| _______/
|
||||
|/
|
||||
|
|
||||
__acquired
|
||||
|
|
||||
.
|
||||
<hold>
|
||||
.
|
||||
|
|
||||
__release
|
||||
|
|
||||
unlock
|
||||
|
||||
lock, unlock - the regular lock functions
|
||||
__* - the hooks
|
||||
<> - states
|
||||
|
||||
With these hooks we provide the following statistics:
|
||||
|
||||
con-bounces - number of lock contention that involved x-cpu data
|
||||
contentions - number of lock acquisitions that had to wait
|
||||
wait time min - shortest (non-0) time we ever had to wait for a lock
|
||||
max - longest time we ever had to wait for a lock
|
||||
total - total time we spend waiting on this lock
|
||||
acq-bounces - number of lock acquisitions that involved x-cpu data
|
||||
acquisitions - number of times we took the lock
|
||||
hold time min - shortest (non-0) time we ever held the lock
|
||||
max - longest time we ever held the lock
|
||||
total - total time this lock was held
|
||||
|
||||
From these number various other statistics can be derived, such as:
|
||||
|
||||
hold time average = hold time total / acquisitions
|
||||
|
||||
These numbers are gathered per lock class, per read/write state (when
|
||||
applicable).
|
||||
|
||||
It also tracks 4 contention points per class. A contention point is a call site
|
||||
that had to wait on lock acquisition.
|
||||
|
||||
- USAGE
|
||||
|
||||
Look at the current lock statistics:
|
||||
|
||||
( line numbers not part of actual output, done for clarity in the explanation
|
||||
below )
|
||||
|
||||
# less /proc/lock_stat
|
||||
|
||||
01 lock_stat version 0.2
|
||||
02 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
03 class name con-bounces contentions waittime-min waittime-max waittime-total acq-bounces acquisitions holdtime-min holdtime-max holdtime-total
|
||||
04 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
05
|
||||
06 &inode->i_data.tree_lock-W: 15 21657 0.18 1093295.30 11547131054.85 58 10415 0.16 87.51 6387.60
|
||||
07 &inode->i_data.tree_lock-R: 0 0 0.00 0.00 0.00 23302 231198 0.25 8.45 98023.38
|
||||
08 --------------------------
|
||||
09 &inode->i_data.tree_lock 0 [<ffffffff8027c08f>] add_to_page_cache+0x5f/0x190
|
||||
10
|
||||
11 ...............................................................................................................................................................................................
|
||||
12
|
||||
13 dcache_lock: 1037 1161 0.38 45.32 774.51 6611 243371 0.15 306.48 77387.24
|
||||
14 -----------
|
||||
15 dcache_lock 180 [<ffffffff802c0d7e>] sys_getcwd+0x11e/0x230
|
||||
16 dcache_lock 165 [<ffffffff802c002a>] d_alloc+0x15a/0x210
|
||||
17 dcache_lock 33 [<ffffffff8035818d>] _atomic_dec_and_lock+0x4d/0x70
|
||||
18 dcache_lock 1 [<ffffffff802beef8>] shrink_dcache_parent+0x18/0x130
|
||||
|
||||
This excerpt shows the first two lock class statistics. Line 01 shows the
|
||||
output version - each time the format changes this will be updated. Line 02-04
|
||||
show the header with column descriptions. Lines 05-10 and 13-18 show the actual
|
||||
statistics. These statistics come in two parts; the actual stats separated by a
|
||||
short separator (line 08, 14) from the contention points.
|
||||
|
||||
The first lock (05-10) is a read/write lock, and shows two lines above the
|
||||
short separator. The contention points don't match the column descriptors,
|
||||
they have two: contentions and [<IP>] symbol.
|
||||
|
||||
|
||||
View the top contending locks:
|
||||
|
||||
# grep : /proc/lock_stat | head
|
||||
&inode->i_data.tree_lock-W: 15 21657 0.18 1093295.30 11547131054.85 58 10415 0.16 87.51 6387.60
|
||||
&inode->i_data.tree_lock-R: 0 0 0.00 0.00 0.00 23302 231198 0.25 8.45 98023.38
|
||||
dcache_lock: 1037 1161 0.38 45.32 774.51 6611 243371 0.15 306.48 77387.24
|
||||
&inode->i_mutex: 161 286 18446744073709 62882.54 1244614.55 3653 20598 18446744073709 62318.60 1693822.74
|
||||
&zone->lru_lock: 94 94 0.53 7.33 92.10 4366 32690 0.29 59.81 16350.06
|
||||
&inode->i_data.i_mmap_lock: 79 79 0.40 3.77 53.03 11779 87755 0.28 116.93 29898.44
|
||||
&q->__queue_lock: 48 50 0.52 31.62 86.31 774 13131 0.17 113.08 12277.52
|
||||
&rq->rq_lock_key: 43 47 0.74 68.50 170.63 3706 33929 0.22 107.99 17460.62
|
||||
&rq->rq_lock_key#2: 39 46 0.75 6.68 49.03 2979 32292 0.17 125.17 17137.63
|
||||
tasklist_lock-W: 15 15 1.45 10.87 32.70 1201 7390 0.58 62.55 13648.47
|
||||
|
||||
Clear the statistics:
|
||||
|
||||
# echo 0 > /proc/lock_stat
|
||||
@@ -96,6 +96,9 @@ routing.txt
|
||||
- the new routing mechanism
|
||||
shaper.txt
|
||||
- info on the module that can shape/limit transmitted traffic.
|
||||
sk98lin.txt
|
||||
- Marvell Yukon Chipset / SysKonnect SK-98xx compliant Gigabit
|
||||
Ethernet Adapter family driver info
|
||||
skfp.txt
|
||||
- SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info.
|
||||
smc9.txt
|
||||
|
||||
@@ -58,9 +58,13 @@ software, so it's a straight round-robin qdisc. It uses the same syntax and
|
||||
classification priomap that sch_prio uses, so it should be intuitive to
|
||||
configure for people who've used sch_prio.
|
||||
|
||||
The PRIO qdisc naturally plugs into a multiqueue device. If PRIO has been
|
||||
built with NET_SCH_PRIO_MQ, then upon load, it will make sure the number of
|
||||
bands requested is equal to the number of queues on the hardware. If they
|
||||
In order to utilitize the multiqueue features of the qdiscs, the network
|
||||
device layer needs to enable multiple queue support. This can be done by
|
||||
selecting NETDEVICES_MULTIQUEUE under Drivers.
|
||||
|
||||
The PRIO qdisc naturally plugs into a multiqueue device. If
|
||||
NETDEVICES_MULTIQUEUE is selected, then on qdisc load, the number of
|
||||
bands requested is compared to the number of queues on the hardware. If they
|
||||
are equal, it sets a one-to-one mapping up between the queues and bands. If
|
||||
they're not equal, it will not load the qdisc. This is the same behavior
|
||||
for RR. Once the association is made, any skb that is classified will have
|
||||
|
||||
568
Documentation/networking/sk98lin.txt
Normal file
568
Documentation/networking/sk98lin.txt
Normal file
@@ -0,0 +1,568 @@
|
||||
(C)Copyright 1999-2004 Marvell(R).
|
||||
All rights reserved
|
||||
===========================================================================
|
||||
|
||||
sk98lin.txt created 13-Feb-2004
|
||||
|
||||
Readme File for sk98lin v6.23
|
||||
Marvell Yukon/SysKonnect SK-98xx Gigabit Ethernet Adapter family driver for LINUX
|
||||
|
||||
This file contains
|
||||
1 Overview
|
||||
2 Required Files
|
||||
3 Installation
|
||||
3.1 Driver Installation
|
||||
3.2 Inclusion of adapter at system start
|
||||
4 Driver Parameters
|
||||
4.1 Per-Port Parameters
|
||||
4.2 Adapter Parameters
|
||||
5 Large Frame Support
|
||||
6 VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad)
|
||||
7 Troubleshooting
|
||||
|
||||
===========================================================================
|
||||
|
||||
|
||||
1 Overview
|
||||
===========
|
||||
|
||||
The sk98lin driver supports the Marvell Yukon and SysKonnect
|
||||
SK-98xx/SK-95xx compliant Gigabit Ethernet Adapter on Linux. It has
|
||||
been tested with Linux on Intel/x86 machines.
|
||||
***
|
||||
|
||||
|
||||
2 Required Files
|
||||
=================
|
||||
|
||||
The linux kernel source.
|
||||
No additional files required.
|
||||
***
|
||||
|
||||
|
||||
3 Installation
|
||||
===============
|
||||
|
||||
It is recommended to download the latest version of the driver from the
|
||||
SysKonnect web site www.syskonnect.com. If you have downloaded the latest
|
||||
driver, the Linux kernel has to be patched before the driver can be
|
||||
installed. For details on how to patch a Linux kernel, refer to the
|
||||
patch.txt file.
|
||||
|
||||
3.1 Driver Installation
|
||||
------------------------
|
||||
|
||||
The following steps describe the actions that are required to install
|
||||
the driver and to start it manually. These steps should be carried
|
||||
out for the initial driver setup. Once confirmed to be ok, they can
|
||||
be included in the system start.
|
||||
|
||||
NOTE 1: To perform the following tasks you need 'root' access.
|
||||
|
||||
NOTE 2: In case of problems, please read the section "Troubleshooting"
|
||||
below.
|
||||
|
||||
The driver can either be integrated into the kernel or it can be compiled
|
||||
as a module. Select the appropriate option during the kernel
|
||||
configuration.
|
||||
|
||||
Compile/use the driver as a module
|
||||
----------------------------------
|
||||
To compile the driver, go to the directory /usr/src/linux and
|
||||
execute the command "make menuconfig" or "make xconfig" and proceed as
|
||||
follows:
|
||||
|
||||
To integrate the driver permanently into the kernel, proceed as follows:
|
||||
|
||||
1. Select the menu "Network device support" and then "Ethernet(1000Mbit)"
|
||||
2. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support"
|
||||
with (*)
|
||||
3. Build a new kernel when the configuration of the above options is
|
||||
finished.
|
||||
4. Install the new kernel.
|
||||
5. Reboot your system.
|
||||
|
||||
To use the driver as a module, proceed as follows:
|
||||
|
||||
1. Enable 'loadable module support' in the kernel.
|
||||
2. For automatic driver start, enable the 'Kernel module loader'.
|
||||
3. Select the menu "Network device support" and then "Ethernet(1000Mbit)"
|
||||
4. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support"
|
||||
with (M)
|
||||
5. Execute the command "make modules".
|
||||
6. Execute the command "make modules_install".
|
||||
The appropriate modules will be installed.
|
||||
7. Reboot your system.
|
||||
|
||||
|
||||
Load the module manually
|
||||
------------------------
|
||||
To load the module manually, proceed as follows:
|
||||
|
||||
1. Enter "modprobe sk98lin".
|
||||
2. If a Marvell Yukon or SysKonnect SK-98xx adapter is installed in
|
||||
your computer and you have a /proc file system, execute the command:
|
||||
"ls /proc/net/sk98lin/"
|
||||
This should produce an output containing a line with the following
|
||||
format:
|
||||
eth0 eth1 ...
|
||||
which indicates that your adapter has been found and initialized.
|
||||
|
||||
NOTE 1: If you have more than one Marvell Yukon or SysKonnect SK-98xx
|
||||
adapter installed, the adapters will be listed as 'eth0',
|
||||
'eth1', 'eth2', etc.
|
||||
For each adapter, repeat steps 3 and 4 below.
|
||||
|
||||
NOTE 2: If you have other Ethernet adapters installed, your Marvell
|
||||
Yukon or SysKonnect SK-98xx adapter will be mapped to the
|
||||
next available number, e.g. 'eth1'. The mapping is executed
|
||||
automatically.
|
||||
The module installation message (displayed either in a system
|
||||
log file or on the console) prints a line for each adapter
|
||||
found containing the corresponding 'ethX'.
|
||||
|
||||
3. Select an IP address and assign it to the respective adapter by
|
||||
entering:
|
||||
ifconfig eth0 <ip-address>
|
||||
With this command, the adapter is connected to the Ethernet.
|
||||
|
||||
SK-98xx Gigabit Ethernet Server Adapters: The yellow LED on the adapter
|
||||
is now active, the link status LED of the primary port is active and
|
||||
the link status LED of the secondary port (on dual port adapters) is
|
||||
blinking (if the ports are connected to a switch or hub).
|
||||
SK-98xx V2.0 Gigabit Ethernet Adapters: The link status LED is active.
|
||||
In addition, you will receive a status message on the console stating
|
||||
"ethX: network connection up using port Y" and showing the selected
|
||||
connection parameters (x stands for the ethernet device number
|
||||
(0,1,2, etc), y stands for the port name (A or B)).
|
||||
|
||||
NOTE: If you are in doubt about IP addresses, ask your network
|
||||
administrator for assistance.
|
||||
|
||||
4. Your adapter should now be fully operational.
|
||||
Use 'ping <otherstation>' to verify the connection to other computers
|
||||
on your network.
|
||||
5. To check the adapter configuration view /proc/net/sk98lin/[devicename].
|
||||
For example by executing:
|
||||
"cat /proc/net/sk98lin/eth0"
|
||||
|
||||
Unload the module
|
||||
-----------------
|
||||
To stop and unload the driver modules, proceed as follows:
|
||||
|
||||
1. Execute the command "ifconfig eth0 down".
|
||||
2. Execute the command "rmmod sk98lin".
|
||||
|
||||
3.2 Inclusion of adapter at system start
|
||||
-----------------------------------------
|
||||
|
||||
Since a large number of different Linux distributions are
|
||||
available, we are unable to describe a general installation procedure
|
||||
for the driver module.
|
||||
Because the driver is now integrated in the kernel, installation should
|
||||
be easy, using the standard mechanism of your distribution.
|
||||
Refer to the distribution's manual for installation of ethernet adapters.
|
||||
|
||||
***
|
||||
|
||||
4 Driver Parameters
|
||||
====================
|
||||
|
||||
Parameters can be set at the command line after the module has been
|
||||
loaded with the command 'modprobe'.
|
||||
In some distributions, the configuration tools are able to pass parameters
|
||||
to the driver module.
|
||||
|
||||
If you use the kernel module loader, you can set driver parameters
|
||||
in the file /etc/modprobe.conf (or /etc/modules.conf in 2.4 or earlier).
|
||||
To set the driver parameters in this file, proceed as follows:
|
||||
|
||||
1. Insert a line of the form :
|
||||
options sk98lin ...
|
||||
For "...", the same syntax is required as described for the command
|
||||
line parameters of modprobe below.
|
||||
2. To activate the new parameters, either reboot your computer
|
||||
or
|
||||
unload and reload the driver.
|
||||
The syntax of the driver parameters is:
|
||||
|
||||
modprobe sk98lin parameter=value1[,value2[,value3...]]
|
||||
|
||||
where value1 refers to the first adapter, value2 to the second etc.
|
||||
|
||||
NOTE: All parameters are case sensitive. Write them exactly as shown
|
||||
below.
|
||||
|
||||
Example:
|
||||
Suppose you have two adapters. You want to set auto-negotiation
|
||||
on the first adapter to ON and on the second adapter to OFF.
|
||||
You also want to set DuplexCapabilities on the first adapter
|
||||
to FULL, and on the second adapter to HALF.
|
||||
Then, you must enter:
|
||||
|
||||
modprobe sk98lin AutoNeg_A=On,Off DupCap_A=Full,Half
|
||||
|
||||
NOTE: The number of adapters that can be configured this way is
|
||||
limited in the driver (file skge.c, constant SK_MAX_CARD_PARAM).
|
||||
The current limit is 16. If you happen to install
|
||||
more adapters, adjust this and recompile.
|
||||
|
||||
|
||||
4.1 Per-Port Parameters
|
||||
------------------------
|
||||
|
||||
These settings are available for each port on the adapter.
|
||||
In the following description, '?' stands for the port for
|
||||
which you set the parameter (A or B).
|
||||
|
||||
Speed
|
||||
-----
|
||||
Parameter: Speed_?
|
||||
Values: 10, 100, 1000, Auto
|
||||
Default: Auto
|
||||
|
||||
This parameter is used to set the speed capabilities. It is only valid
|
||||
for the SK-98xx V2.0 copper adapters.
|
||||
Usually, the speed is negotiated between the two ports during link
|
||||
establishment. If this fails, a port can be forced to a specific setting
|
||||
with this parameter.
|
||||
|
||||
Auto-Negotiation
|
||||
----------------
|
||||
Parameter: AutoNeg_?
|
||||
Values: On, Off, Sense
|
||||
Default: On
|
||||
|
||||
The "Sense"-mode automatically detects whether the link partner supports
|
||||
auto-negotiation or not.
|
||||
|
||||
Duplex Capabilities
|
||||
-------------------
|
||||
Parameter: DupCap_?
|
||||
Values: Half, Full, Both
|
||||
Default: Both
|
||||
|
||||
This parameters is only relevant if auto-negotiation for this port is
|
||||
not set to "Sense". If auto-negotiation is set to "On", all three values
|
||||
are possible. If it is set to "Off", only "Full" and "Half" are allowed.
|
||||
This parameter is useful if your link partner does not support all
|
||||
possible combinations.
|
||||
|
||||
Flow Control
|
||||
------------
|
||||
Parameter: FlowCtrl_?
|
||||
Values: Sym, SymOrRem, LocSend, None
|
||||
Default: SymOrRem
|
||||
|
||||
This parameter can be used to set the flow control capabilities the
|
||||
port reports during auto-negotiation. It can be set for each port
|
||||
individually.
|
||||
Possible modes:
|
||||
-- Sym = Symmetric: both link partners are allowed to send
|
||||
PAUSE frames
|
||||
-- SymOrRem = SymmetricOrRemote: both or only remote partner
|
||||
are allowed to send PAUSE frames
|
||||
-- LocSend = LocalSend: only local link partner is allowed
|
||||
to send PAUSE frames
|
||||
-- None = no link partner is allowed to send PAUSE frames
|
||||
|
||||
NOTE: This parameter is ignored if auto-negotiation is set to "Off".
|
||||
|
||||
Role in Master-Slave-Negotiation (1000Base-T only)
|
||||
--------------------------------------------------
|
||||
Parameter: Role_?
|
||||
Values: Auto, Master, Slave
|
||||
Default: Auto
|
||||
|
||||
This parameter is only valid for the SK-9821 and SK-9822 adapters.
|
||||
For two 1000Base-T ports to communicate, one must take the role of the
|
||||
master (providing timing information), while the other must be the
|
||||
slave. Usually, this is negotiated between the two ports during link
|
||||
establishment. If this fails, a port can be forced to a specific setting
|
||||
with this parameter.
|
||||
|
||||
|
||||
4.2 Adapter Parameters
|
||||
-----------------------
|
||||
|
||||
Connection Type (SK-98xx V2.0 copper adapters only)
|
||||
---------------
|
||||
Parameter: ConType
|
||||
Values: Auto, 100FD, 100HD, 10FD, 10HD
|
||||
Default: Auto
|
||||
|
||||
The parameter 'ConType' is a combination of all five per-port parameters
|
||||
within one single parameter. This simplifies the configuration of both ports
|
||||
of an adapter card! The different values of this variable reflect the most
|
||||
meaningful combinations of port parameters.
|
||||
|
||||
The following table shows the values of 'ConType' and the corresponding
|
||||
combinations of the per-port parameters:
|
||||
|
||||
ConType | DupCap AutoNeg FlowCtrl Role Speed
|
||||
----------+------------------------------------------------------
|
||||
Auto | Both On SymOrRem Auto Auto
|
||||
100FD | Full Off None Auto (ignored) 100
|
||||
100HD | Half Off None Auto (ignored) 100
|
||||
10FD | Full Off None Auto (ignored) 10
|
||||
10HD | Half Off None Auto (ignored) 10
|
||||
|
||||
Stating any other port parameter together with this 'ConType' variable
|
||||
will result in a merged configuration of those settings. This due to
|
||||
the fact, that the per-port parameters (e.g. Speed_? ) have a higher
|
||||
priority than the combined variable 'ConType'.
|
||||
|
||||
NOTE: This parameter is always used on both ports of the adapter card.
|
||||
|
||||
Interrupt Moderation
|
||||
--------------------
|
||||
Parameter: Moderation
|
||||
Values: None, Static, Dynamic
|
||||
Default: None
|
||||
|
||||
Interrupt moderation is employed to limit the maximum number of interrupts
|
||||
the driver has to serve. That is, one or more interrupts (which indicate any
|
||||
transmit or receive packet to be processed) are queued until the driver
|
||||
processes them. When queued interrupts are to be served, is determined by the
|
||||
'IntsPerSec' parameter, which is explained later below.
|
||||
|
||||
Possible modes:
|
||||
|
||||
-- None - No interrupt moderation is applied on the adapter card.
|
||||
Therefore, each transmit or receive interrupt is served immediately
|
||||
as soon as it appears on the interrupt line of the adapter card.
|
||||
|
||||
-- Static - Interrupt moderation is applied on the adapter card.
|
||||
All transmit and receive interrupts are queued until a complete
|
||||
moderation interval ends. If such a moderation interval ends, all
|
||||
queued interrupts are processed in one big bunch without any delay.
|
||||
The term 'static' reflects the fact, that interrupt moderation is
|
||||
always enabled, regardless how much network load is currently
|
||||
passing via a particular interface. In addition, the duration of
|
||||
the moderation interval has a fixed length that never changes while
|
||||
the driver is operational.
|
||||
|
||||
-- Dynamic - Interrupt moderation might be applied on the adapter card,
|
||||
depending on the load of the system. If the driver detects that the
|
||||
system load is too high, the driver tries to shield the system against
|
||||
too much network load by enabling interrupt moderation. If - at a later
|
||||
time - the CPU utilization decreases again (or if the network load is
|
||||
negligible) the interrupt moderation will automatically be disabled.
|
||||
|
||||
Interrupt moderation should be used when the driver has to handle one or more
|
||||
interfaces with a high network load, which - as a consequence - leads also to a
|
||||
high CPU utilization. When moderation is applied in such high network load
|
||||
situations, CPU load might be reduced by 20-30%.
|
||||
|
||||
NOTE: The drawback of using interrupt moderation is an increase of the round-
|
||||
trip-time (RTT), due to the queueing and serving of interrupts at dedicated
|
||||
moderation times.
|
||||
|
||||
Interrupts per second
|
||||
---------------------
|
||||
Parameter: IntsPerSec
|
||||
Values: 30...40000 (interrupts per second)
|
||||
Default: 2000
|
||||
|
||||
This parameter is only used if either static or dynamic interrupt moderation
|
||||
is used on a network adapter card. Using this parameter if no moderation is
|
||||
applied will lead to no action performed.
|
||||
|
||||
This parameter determines the length of any interrupt moderation interval.
|
||||
Assuming that static interrupt moderation is to be used, an 'IntsPerSec'
|
||||
parameter value of 2000 will lead to an interrupt moderation interval of
|
||||
500 microseconds.
|
||||
|
||||
NOTE: The duration of the moderation interval is to be chosen with care.
|
||||
At first glance, selecting a very long duration (e.g. only 100 interrupts per
|
||||
second) seems to be meaningful, but the increase of packet-processing delay
|
||||
is tremendous. On the other hand, selecting a very short moderation time might
|
||||
compensate the use of any moderation being applied.
|
||||
|
||||
|
||||
Preferred Port
|
||||
--------------
|
||||
Parameter: PrefPort
|
||||
Values: A, B
|
||||
Default: A
|
||||
|
||||
This is used to force the preferred port to A or B (on dual-port network
|
||||
adapters). The preferred port is the one that is used if both are detected
|
||||
as fully functional.
|
||||
|
||||
RLMT Mode (Redundant Link Management Technology)
|
||||
------------------------------------------------
|
||||
Parameter: RlmtMode
|
||||
Values: CheckLinkState,CheckLocalPort, CheckSeg, DualNet
|
||||
Default: CheckLinkState
|
||||
|
||||
RLMT monitors the status of the port. If the link of the active port
|
||||
fails, RLMT switches immediately to the standby link. The virtual link is
|
||||
maintained as long as at least one 'physical' link is up.
|
||||
|
||||
Possible modes:
|
||||
|
||||
-- CheckLinkState - Check link state only: RLMT uses the link state
|
||||
reported by the adapter hardware for each individual port to
|
||||
determine whether a port can be used for all network traffic or
|
||||
not.
|
||||
|
||||
-- CheckLocalPort - In this mode, RLMT monitors the network path
|
||||
between the two ports of an adapter by regularly exchanging packets
|
||||
between them. This mode requires a network configuration in which
|
||||
the two ports are able to "see" each other (i.e. there must not be
|
||||
any router between the ports).
|
||||
|
||||
-- CheckSeg - Check local port and segmentation: This mode supports the
|
||||
same functions as the CheckLocalPort mode and additionally checks
|
||||
network segmentation between the ports. Therefore, this mode is only
|
||||
to be used if Gigabit Ethernet switches are installed on the network
|
||||
that have been configured to use the Spanning Tree protocol.
|
||||
|
||||
-- DualNet - In this mode, ports A and B are used as separate devices.
|
||||
If you have a dual port adapter, port A will be configured as eth0
|
||||
and port B as eth1. Both ports can be used independently with
|
||||
distinct IP addresses. The preferred port setting is not used.
|
||||
RLMT is turned off.
|
||||
|
||||
NOTE: RLMT modes CLP and CLPSS are designed to operate in configurations
|
||||
where a network path between the ports on one adapter exists.
|
||||
Moreover, they are not designed to work where adapters are connected
|
||||
back-to-back.
|
||||
***
|
||||
|
||||
|
||||
5 Large Frame Support
|
||||
======================
|
||||
|
||||
The driver supports large frames (also called jumbo frames). Using large
|
||||
frames can result in an improved throughput if transferring large amounts
|
||||
of data.
|
||||
To enable large frames, set the MTU (maximum transfer unit) of the
|
||||
interface to the desired value (up to 9000), execute the following
|
||||
command:
|
||||
ifconfig eth0 mtu 9000
|
||||
This will only work if you have two adapters connected back-to-back
|
||||
or if you use a switch that supports large frames. When using a switch,
|
||||
it should be configured to allow large frames and auto-negotiation should
|
||||
be set to OFF. The setting must be configured on all adapters that can be
|
||||
reached by the large frames. If one adapter is not set to receive large
|
||||
frames, it will simply drop them.
|
||||
|
||||
You can switch back to the standard ethernet frame size by executing the
|
||||
following command:
|
||||
ifconfig eth0 mtu 1500
|
||||
|
||||
To permanently configure this setting, add a script with the 'ifconfig'
|
||||
line to the system startup sequence (named something like "S99sk98lin"
|
||||
in /etc/rc.d/rc2.d).
|
||||
***
|
||||
|
||||
|
||||
6 VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad)
|
||||
==================================================================
|
||||
|
||||
The Marvell Yukon/SysKonnect Linux drivers are able to support VLAN and
|
||||
Link Aggregation according to IEEE standards 802.1, 802.1q, and 802.3ad.
|
||||
These features are only available after installation of open source
|
||||
modules available on the Internet:
|
||||
For VLAN go to: http://www.candelatech.com/~greear/vlan.html
|
||||
For Link Aggregation go to: http://www.st.rim.or.jp/~yumo
|
||||
|
||||
NOTE: SysKonnect GmbH does not offer any support for these open source
|
||||
modules and does not take the responsibility for any kind of
|
||||
failures or problems arising in connection with these modules.
|
||||
|
||||
NOTE: Configuring Link Aggregation on a SysKonnect dual link adapter may
|
||||
cause problems when unloading the driver.
|
||||
|
||||
|
||||
7 Troubleshooting
|
||||
==================
|
||||
|
||||
If any problems occur during the installation process, check the
|
||||
following list:
|
||||
|
||||
|
||||
Problem: The SK-98xx adapter cannot be found by the driver.
|
||||
Solution: In /proc/pci search for the following entry:
|
||||
'Ethernet controller: SysKonnect SK-98xx ...'
|
||||
If this entry exists, the SK-98xx or SK-98xx V2.0 adapter has
|
||||
been found by the system and should be operational.
|
||||
If this entry does not exist or if the file '/proc/pci' is not
|
||||
found, there may be a hardware problem or the PCI support may
|
||||
not be enabled in your kernel.
|
||||
The adapter can be checked using the diagnostics program which
|
||||
is available on the SysKonnect web site:
|
||||
www.syskonnect.com
|
||||
|
||||
Some COMPAQ machines have problems dealing with PCI under Linux.
|
||||
This problem is described in the 'PCI howto' document
|
||||
(included in some distributions or available from the
|
||||
web, e.g. at 'www.linux.org').
|
||||
|
||||
|
||||
Problem: Programs such as 'ifconfig' or 'route' cannot be found or the
|
||||
error message 'Operation not permitted' is displayed.
|
||||
Reason: You are not logged in as user 'root'.
|
||||
Solution: Logout and login as 'root' or change to 'root' via 'su'.
|
||||
|
||||
|
||||
Problem: Upon use of the command 'ping <address>' the message
|
||||
"ping: sendto: Network is unreachable" is displayed.
|
||||
Reason: Your route is not set correctly.
|
||||
Solution: If you are using RedHat, you probably forgot to set up the
|
||||
route in the 'network configuration'.
|
||||
Check the existing routes with the 'route' command and check
|
||||
if an entry for 'eth0' exists, and if so, if it is set correctly.
|
||||
|
||||
|
||||
Problem: The driver can be started, the adapter is connected to the
|
||||
network, but you cannot receive or transmit any packets;
|
||||
e.g. 'ping' does not work.
|
||||
Reason: There is an incorrect route in your routing table.
|
||||
Solution: Check the routing table with the command 'route' and read the
|
||||
manual help pages dealing with routes (enter 'man route').
|
||||
|
||||
NOTE: Although the 2.2.x kernel versions generate the routing entry
|
||||
automatically, problems of this kind may occur here as well. We've
|
||||
come across a situation in which the driver started correctly at
|
||||
system start, but after the driver has been removed and reloaded,
|
||||
the route of the adapter's network pointed to the 'dummy0'device
|
||||
and had to be corrected manually.
|
||||
|
||||
|
||||
Problem: Your computer should act as a router between multiple
|
||||
IP subnetworks (using multiple adapters), but computers in
|
||||
other subnetworks cannot be reached.
|
||||
Reason: Either the router's kernel is not configured for IP forwarding
|
||||
or the routing table and gateway configuration of at least one
|
||||
computer is not working.
|
||||
|
||||
Problem: Upon driver start, the following error message is displayed:
|
||||
"eth0: -- ERROR --
|
||||
Class: internal Software error
|
||||
Nr: 0xcc
|
||||
Msg: SkGeInitPort() cannot init running ports"
|
||||
Reason: You are using a driver compiled for single processor machines
|
||||
on a multiprocessor machine with SMP (Symmetric MultiProcessor)
|
||||
kernel.
|
||||
Solution: Configure your kernel appropriately and recompile the kernel or
|
||||
the modules.
|
||||
|
||||
|
||||
|
||||
If your problem is not listed here, please contact SysKonnect's technical
|
||||
support for help (linux@syskonnect.de).
|
||||
When contacting our technical support, please ensure that the following
|
||||
information is available:
|
||||
- System Manufacturer and HW Informations (CPU, Memory... )
|
||||
- PCI-Boards in your system
|
||||
- Distribution
|
||||
- Kernel version
|
||||
- Driver version
|
||||
***
|
||||
|
||||
|
||||
|
||||
***End of Readme File***
|
||||
@@ -43,7 +43,7 @@ On x86 - You press the key combo 'ALT-SysRq-<command key>'. Note - Some
|
||||
keyboards may not have a key labeled 'SysRq'. The 'SysRq' key is
|
||||
also known as the 'Print Screen' key. Also some keyboards cannot
|
||||
handle so many keys being pressed at the same time, so you might
|
||||
have better luck with "press Alt", "press SysRq", "release Alt",
|
||||
have better luck with "press Alt", "press SysRq", "release SysRq",
|
||||
"press <command key>", release everything.
|
||||
|
||||
On SPARC - You press 'ALT-STOP-<command key>', I believe.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
ThinkPad ACPI Extras Driver
|
||||
|
||||
Version 0.15
|
||||
July 1st, 2007
|
||||
Version 0.16
|
||||
August 2nd, 2007
|
||||
|
||||
Borislav Deianov <borislav@users.sf.net>
|
||||
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
|
||||
@@ -161,20 +161,22 @@ system. Enabling the hotkey functionality of thinkpad-acpi signals the
|
||||
firmware that such a driver is present, and modifies how the ThinkPad
|
||||
firmware will behave in many situations.
|
||||
|
||||
The driver enables the hot key feature automatically when loaded. The
|
||||
feature can later be disabled and enabled back at runtime. The driver
|
||||
will also restore the hot key feature to its previous state and mask
|
||||
when it is unloaded.
|
||||
|
||||
When the hotkey feature is enabled and the hot key mask is set (see
|
||||
below), the various hot keys either generate ACPI events in the
|
||||
following format:
|
||||
below), the driver will report HKEY events in the following format:
|
||||
|
||||
ibm/hotkey HKEY 00000080 0000xxxx
|
||||
|
||||
or events over the input layer. The input layer support accepts the
|
||||
standard IOCTLs to remap the keycodes assigned to each hotkey.
|
||||
Some of these events refer to hot key presses, but not all.
|
||||
|
||||
When the input device is open, the driver will suppress any ACPI hot key
|
||||
events that get translated into a meaningful input layer event, in order
|
||||
to avoid sending duplicate events to userspace. Hot keys that are
|
||||
mapped to KEY_RESERVED in the keymap are not translated, and will always
|
||||
generate an ACPI ibm/hotkey HKEY event, and no input layer events.
|
||||
The driver will generate events over the input layer for hot keys and
|
||||
radio switches, and over the ACPI netlink layer for other events. The
|
||||
input layer support accepts the standard IOCTLs to remap the keycodes
|
||||
assigned to each hot key.
|
||||
|
||||
The hot key bit mask allows some control over which hot keys generate
|
||||
events. If a key is "masked" (bit set to 0 in the mask), the firmware
|
||||
@@ -256,6 +258,20 @@ sysfs notes:
|
||||
disabled" postition, and 1 if the switch is in the
|
||||
"radios enabled" position.
|
||||
|
||||
hotkey_report_mode:
|
||||
Returns the state of the procfs ACPI event report mode
|
||||
filter for hot keys. If it is set to 1 (the default),
|
||||
all hot key presses are reported both through the input
|
||||
layer and also as ACPI events through procfs (but not
|
||||
through netlink). If it is set to 2, hot key presses
|
||||
are reported only through the input layer.
|
||||
|
||||
This attribute is read-only in kernels 2.6.23 or later,
|
||||
and read-write on earlier kernels.
|
||||
|
||||
May return -EPERM (write access locked out by module
|
||||
parameter) or -EACCES (read-only).
|
||||
|
||||
input layer notes:
|
||||
|
||||
A Hot key is mapped to a single input layer EV_KEY event, possibly
|
||||
@@ -393,21 +409,63 @@ unknown by the driver if the ThinkPad firmware triggered these events on
|
||||
hot key press or release, but the firmware will do it for either one, not
|
||||
both.
|
||||
|
||||
If a key is mapped to KEY_RESERVED, it generates no input events at all,
|
||||
and it may generate a legacy thinkpad-acpi ACPI hotkey event.
|
||||
|
||||
If a key is mapped to KEY_RESERVED, it generates no input events at all.
|
||||
If a key is mapped to KEY_UNKNOWN, it generates an input event that
|
||||
includes an scan code, and it may also generate a legacy thinkpad-acpi
|
||||
ACPI hotkey event.
|
||||
|
||||
If a key is mapped to anything else, it will only generate legacy
|
||||
thinkpad-acpi ACPI hotkey events if nobody has opened the input device.
|
||||
includes an scan code. If a key is mapped to anything else, it will
|
||||
generate input device EV_KEY events.
|
||||
|
||||
Non hot-key ACPI HKEY event map:
|
||||
0x5001 Lid closed
|
||||
0x5002 Lid opened
|
||||
0x7000 Radio Switch may have changed state
|
||||
|
||||
The above events are not propagated by the driver, except for legacy
|
||||
compatibility purposes when hotkey_report_mode is set to 1.
|
||||
|
||||
Compatibility notes:
|
||||
|
||||
ibm-acpi and thinkpad-acpi 0.15 (mainline kernels before 2.6.23) never
|
||||
supported the input layer, and sent events over the procfs ACPI event
|
||||
interface.
|
||||
|
||||
To avoid sending duplicate events over the input layer and the ACPI
|
||||
event interface, thinkpad-acpi 0.16 implements a module parameter
|
||||
(hotkey_report_mode), and also a sysfs device attribute with the same
|
||||
name.
|
||||
|
||||
Make no mistake here: userspace is expected to switch to using the input
|
||||
layer interface of thinkpad-acpi, together with the ACPI netlink event
|
||||
interface in kernels 2.6.23 and later, or with the ACPI procfs event
|
||||
interface in kernels 2.6.22 and earlier.
|
||||
|
||||
If no hotkey_report_mode module parameter is specified (or it is set to
|
||||
zero), the driver defaults to mode 1 (see below), and on kernels 2.6.22
|
||||
and earlier, also allows one to change the hotkey_report_mode through
|
||||
sysfs. In kernels 2.6.23 and later, where the netlink ACPI event
|
||||
interface is available, hotkey_report_mode cannot be changed through
|
||||
sysfs (it is read-only).
|
||||
|
||||
If the hotkey_report_mode module parameter is set to 1 or 2, it cannot
|
||||
be changed later through sysfs (any writes will return -EPERM to signal
|
||||
that hotkey_report_mode was locked. On 2.6.23 and later, where
|
||||
hotkey_report_mode cannot be changed at all, writes will return -EACES).
|
||||
|
||||
hotkey_report_mode set to 1 makes the driver export through the procfs
|
||||
ACPI event interface all hot key presses (which are *also* sent to the
|
||||
input layer). This is a legacy compatibility behaviour, and it is also
|
||||
the default mode of operation for the driver.
|
||||
|
||||
hotkey_report_mode set to 2 makes the driver filter out the hot key
|
||||
presses from the procfs ACPI event interface, so these events will only
|
||||
be sent through the input layer. Userspace that has been updated to use
|
||||
the thinkpad-acpi input layer interface should set hotkey_report_mode to
|
||||
2.
|
||||
|
||||
Hot key press events are never sent to the ACPI netlink event interface.
|
||||
Really up-to-date userspace under kernel 2.6.23 and later is to use the
|
||||
netlink interface and the input layer interface, and don't bother at all
|
||||
with hotkey_report_mode.
|
||||
|
||||
|
||||
Bluetooth
|
||||
---------
|
||||
|
||||
@@ -407,8 +407,10 @@ Description
|
||||
u32 length; // Length of this frame
|
||||
u32 offset_low; // Offset in the file of the
|
||||
u32 offset_high; // start of this frame
|
||||
u32 mask1; // Bits 0-1 are the type mask:
|
||||
u32 mask1; // Bits 0-2 are the type mask:
|
||||
// 1=I, 2=P, 4=B
|
||||
// 0=End of Program Index, other fields
|
||||
// are invalid.
|
||||
u32 pts; // The PTS of the frame
|
||||
u32 mask2; // Bit 0 is bit 32 of the pts.
|
||||
};
|
||||
|
||||
Reference in New Issue
Block a user