mirror of
https://github.com/linux-msm/laptops-kernel.git
synced 2026-08-13 14:19:53 -07:00
Merge branch 'upstream-fixes'
This commit is contained in:
Jeff Garzik committed
commit
725b2805fd
859 files changed
+14731
-8285
No files matched your search
@@ -3101,7 +3101,7 @@ S: Minto, NSW, 2566
|
||||
S: Australia
|
||||
|
||||
N: Stephen Smalley
|
||||
E: sds@epoch.ncsc.mil
|
||||
E: sds@tycho.nsa.gov
|
||||
D: portions of the Linux Security Module (LSM) framework and security modules
|
||||
|
||||
N: Chris Smith
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
|
||||
Export cpu topology info by sysfs. Items (attributes) are similar
|
||||
to /proc/cpuinfo.
|
||||
|
||||
1) /sys/devices/system/cpu/cpuX/topology/physical_package_id:
|
||||
represent the physical package id of cpu X;
|
||||
2) /sys/devices/system/cpu/cpuX/topology/core_id:
|
||||
represent the cpu core id to cpu X;
|
||||
3) /sys/devices/system/cpu/cpuX/topology/thread_siblings:
|
||||
represent the thread siblings to cpu X in the same core;
|
||||
4) /sys/devices/system/cpu/cpuX/topology/core_siblings:
|
||||
represent the thread siblings to cpu X in the same physical package;
|
||||
|
||||
To implement it in an architecture-neutral way, a new source file,
|
||||
driver/base/topology.c, is to export the 5 attributes.
|
||||
|
||||
If one architecture wants to support this feature, it just needs to
|
||||
implement 4 defines, typically in file include/asm-XXX/topology.h.
|
||||
The 4 defines are:
|
||||
#define topology_physical_package_id(cpu)
|
||||
#define topology_core_id(cpu)
|
||||
#define topology_thread_siblings(cpu)
|
||||
#define topology_core_siblings(cpu)
|
||||
|
||||
The type of **_id is int.
|
||||
The type of siblings is cpumask_t.
|
||||
|
||||
To be consistent on all architectures, the 4 attributes should have
|
||||
deafult values if their values are unavailable. Below is the rule.
|
||||
1) physical_package_id: If cpu has no physical package id, -1 is the
|
||||
default value.
|
||||
2) core_id: If cpu doesn't support multi-core, its core id is 0.
|
||||
3) thread_siblings: Just include itself, if the cpu doesn't support
|
||||
HT/multi-thread.
|
||||
4) core_siblings: Just include itself, if the cpu doesn't support
|
||||
multi-core and HT/Multi-thread.
|
||||
|
||||
So be careful when declaring the 4 defines in include/asm-XXX/topology.h.
|
||||
|
||||
If an attribute isn't defined on an architecture, it won't be exported.
|
||||
|
||||
@@ -1,50 +1,43 @@
|
||||
The Linux Kernel Device Model
|
||||
|
||||
Patrick Mochel <mochel@osdl.org>
|
||||
Patrick Mochel <mochel@digitalimplant.org>
|
||||
|
||||
26 August 2002
|
||||
Drafted 26 August 2002
|
||||
Updated 31 January 2006
|
||||
|
||||
|
||||
Overview
|
||||
~~~~~~~~
|
||||
|
||||
This driver model is a unification of all the current, disparate driver models
|
||||
that are currently in the kernel. It is intended to augment the
|
||||
The Linux Kernel Driver Model is a unification of all the disparate driver
|
||||
models that were previously used in the kernel. It is intended to augment the
|
||||
bus-specific drivers for bridges and devices by consolidating a set of data
|
||||
and operations into globally accessible data structures.
|
||||
|
||||
Current driver models implement some sort of tree-like structure (sometimes
|
||||
just a list) for the devices they control. But, there is no linkage between
|
||||
the different bus types.
|
||||
Traditional driver models implemented some sort of tree-like structure
|
||||
(sometimes just a list) for the devices they control. There wasn't any
|
||||
uniformity across the different bus types.
|
||||
|
||||
A common data structure can provide this linkage with little overhead: when a
|
||||
bus driver discovers a particular device, it can insert it into the global
|
||||
tree as well as its local tree. In fact, the local tree becomes just a subset
|
||||
of the global tree.
|
||||
|
||||
Common data fields can also be moved out of the local bus models into the
|
||||
global model. Some of the manipulations of these fields can also be
|
||||
consolidated. Most likely, manipulation functions will become a set
|
||||
of helper functions, which the bus drivers wrap around to include any
|
||||
bus-specific items.
|
||||
|
||||
The common device and bridge interface currently reflects the goals of the
|
||||
modern PC: namely the ability to do seamless Plug and Play, power management,
|
||||
and hot plug. (The model dictated by Intel and Microsoft (read: ACPI) ensures
|
||||
us that any device in the system may fit any of these criteria.)
|
||||
|
||||
In reality, not every bus will be able to support such operations. But, most
|
||||
buses will support a majority of those operations, and all future buses will.
|
||||
In other words, a bus that doesn't support an operation is the exception,
|
||||
instead of the other way around.
|
||||
The current driver model provides a comon, uniform data model for describing
|
||||
a bus and the devices that can appear under the bus. The unified bus
|
||||
model includes a set of common attributes which all busses carry, and a set
|
||||
of common callbacks, such as device discovery during bus probing, bus
|
||||
shutdown, bus power management, etc.
|
||||
|
||||
The common device and bridge interface reflects the goals of the modern
|
||||
computer: namely the ability to do seamless device "plug and play", power
|
||||
management, and hot plug. In particular, the model dictated by Intel and
|
||||
Microsoft (namely ACPI) ensures that almost every device on almost any bus
|
||||
on an x86-compatible system can work within this paradigm. Of course,
|
||||
not every bus is able to support all such operations, although most
|
||||
buses support a most of those operations.
|
||||
|
||||
|
||||
Downstream Access
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Common data fields have been moved out of individual bus layers into a common
|
||||
data structure. But, these fields must still be accessed by the bus layers,
|
||||
data structure. These fields must still be accessed by the bus layers,
|
||||
and sometimes by the device-specific drivers.
|
||||
|
||||
Other bus layers are encouraged to do what has been done for the PCI layer.
|
||||
@@ -53,7 +46,7 @@ struct pci_dev now looks like this:
|
||||
struct pci_dev {
|
||||
...
|
||||
|
||||
struct device device;
|
||||
struct device dev;
|
||||
};
|
||||
|
||||
Note first that it is statically allocated. This means only one allocation on
|
||||
@@ -64,9 +57,9 @@ the two.
|
||||
|
||||
The PCI bus layer freely accesses the fields of struct device. It knows about
|
||||
the structure of struct pci_dev, and it should know the structure of struct
|
||||
device. PCI devices that have been converted generally do not touch the fields
|
||||
of struct device. More precisely, device-specific drivers should not touch
|
||||
fields of struct device unless there is a strong compelling reason to do so.
|
||||
device. Individual PCI device drivers that have been converted the the current
|
||||
driver model generally do not and should not touch the fields of struct device,
|
||||
unless there is a strong compelling reason to do so.
|
||||
|
||||
This abstraction is prevention of unnecessary pain during transitional phases.
|
||||
If the name of the field changes or is removed, then every downstream driver
|
||||
|
||||
@@ -162,3 +162,12 @@ What: pci_module_init(driver)
|
||||
When: January 2007
|
||||
Why: Is replaced by pci_register_driver(pci_driver).
|
||||
Who: Richard Knutsson <ricknu-0@student.ltu.se> and Greg Kroah-Hartman <gregkh@suse.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: I2C interface of the it87 driver
|
||||
When: January 2007
|
||||
Why: The ISA interface is faster and should be always available. The I2C
|
||||
probing is also known to cause trouble in at least one case (see
|
||||
bug #5889.)
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
@@ -320,6 +320,7 @@ static struct config_item_type simple_children_type = {
|
||||
.ct_item_ops = &simple_children_item_ops,
|
||||
.ct_group_ops = &simple_children_group_ops,
|
||||
.ct_attrs = simple_children_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct configfs_subsystem simple_children_subsys = {
|
||||
@@ -403,6 +404,7 @@ static struct config_item_type group_children_type = {
|
||||
.ct_item_ops = &group_children_item_ops,
|
||||
.ct_group_ops = &group_children_group_ops,
|
||||
.ct_attrs = group_children_attrs,
|
||||
.ct_owner = THIS_MODULE,
|
||||
};
|
||||
|
||||
static struct configfs_subsystem group_children_subsys = {
|
||||
|
||||
@@ -35,6 +35,7 @@ Features which OCFS2 does not support yet:
|
||||
be cluster coherent.
|
||||
- quotas
|
||||
- cluster aware flock
|
||||
- cluster aware lockf
|
||||
- Directory change notification (F_NOTIFY)
|
||||
- Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease)
|
||||
- POSIX ACLs
|
||||
|
||||
@@ -0,0 +1,105 @@
|
||||
Kernel driver f71805f
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Fintek F71805F/FG
|
||||
Prefix: 'f71805f'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Provided by Fintek on request
|
||||
|
||||
Author: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
Thanks to Denis Kieft from Barracuda Networks for the donation of a
|
||||
test system (custom Jetway K8M8MS motherboard, with CPU and RAM) and
|
||||
for providing initial documentation.
|
||||
|
||||
Thanks to Kris Chen from Fintek for answering technical questions and
|
||||
providing additional documentation.
|
||||
|
||||
Thanks to Chris Lin from Jetway for providing wiring schematics and
|
||||
anwsering technical questions.
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The Fintek F71805F/FG Super I/O chip includes complete hardware monitoring
|
||||
capabilities. It can monitor up to 9 voltages (counting its own power
|
||||
source), 3 fans and 3 temperature sensors.
|
||||
|
||||
This chip also has fan controlling features, using either DC or PWM, in
|
||||
three different modes (one manual, two automatic). The driver doesn't
|
||||
support these features yet.
|
||||
|
||||
The driver assumes that no more than one chip is present, which seems
|
||||
reasonable.
|
||||
|
||||
|
||||
Voltage Monitoring
|
||||
------------------
|
||||
|
||||
Voltages are sampled by an 8-bit ADC with a LSB of 8 mV. The supported
|
||||
range is thus from 0 to 2.040 V. Voltage values outside of this range
|
||||
need external resistors. An exception is in0, which is used to monitor
|
||||
the chip's own power source (+3.3V), and is divided internally by a
|
||||
factor 2.
|
||||
|
||||
The two LSB of the voltage limit registers are not used (always 0), so
|
||||
you can only set the limits in steps of 32 mV (before scaling).
|
||||
|
||||
The wirings and resistor values suggested by Fintek are as follow:
|
||||
|
||||
pin expected
|
||||
name use R1 R2 divider raw val.
|
||||
|
||||
in0 VCC VCC3.3V int. int. 2.00 1.65 V
|
||||
in1 VIN1 VTT1.2V 10K - 1.00 1.20 V
|
||||
in2 VIN2 VRAM 100K 100K 2.00 ~1.25 V (1)
|
||||
in3 VIN3 VCHIPSET 47K 100K 1.47 2.24 V (2)
|
||||
in4 VIN4 VCC5V 200K 47K 5.25 0.95 V
|
||||
in5 VIN5 +12V 200K 20K 11.00 1.05 V
|
||||
in6 VIN6 VCC1.5V 10K - 1.00 1.50 V
|
||||
in7 VIN7 VCORE 10K - 1.00 ~1.40 V (1)
|
||||
in8 VIN8 VSB5V 200K 47K 1.00 0.95 V
|
||||
|
||||
(1) Depends on your hardware setup.
|
||||
(2) Obviously not correct, swapping R1 and R2 would make more sense.
|
||||
|
||||
These values can be used as hints at best, as motherboard manufacturers
|
||||
are free to use a completely different setup. As a matter of fact, the
|
||||
Jetway K8M8MS uses a significantly different setup. You will have to
|
||||
find out documentation about your own motherboard, and edit sensors.conf
|
||||
accordingly.
|
||||
|
||||
Each voltage measured has associated low and high limits, each of which
|
||||
triggers an alarm when crossed.
|
||||
|
||||
|
||||
Fan Monitoring
|
||||
--------------
|
||||
|
||||
Fan rotation speeds are reported as 12-bit values from a gated clock
|
||||
signal. Speeds down to 366 RPM can be measured. There is no theoretical
|
||||
high limit, but values over 6000 RPM seem to cause problem. The effective
|
||||
resolution is much lower than you would expect, the step between different
|
||||
register values being 10 rather than 1.
|
||||
|
||||
The chip assumes 2 pulse-per-revolution fans.
|
||||
|
||||
An alarm is triggered if the rotation speed drops below a programmable
|
||||
limit or is too low to be measured.
|
||||
|
||||
|
||||
Temperature Monitoring
|
||||
----------------------
|
||||
|
||||
Temperatures are reported in degrees Celsius. Each temperature measured
|
||||
has a high limit, those crossing triggers an alarm. There is an associated
|
||||
hysteresis value, below which the temperature has to drop before the
|
||||
alarm is cleared.
|
||||
|
||||
All temperature channels are external, there is no embedded temperature
|
||||
sensor. Each channel can be used for connecting either a thermal diode
|
||||
or a thermistor. The driver reports the currently selected mode, but
|
||||
doesn't allow changing it. In theory, the BIOS should have configured
|
||||
everything properly.
|
||||
@@ -9,7 +9,7 @@ Supported chips:
|
||||
http://www.ite.com.tw/
|
||||
* IT8712F
|
||||
Prefix: 'it8712'
|
||||
Addresses scanned: I2C 0x28 - 0x2f
|
||||
Addresses scanned: I2C 0x2d
|
||||
from Super I/O config space (8 I/O ports)
|
||||
Datasheet: Publicly available at the ITE website
|
||||
http://www.ite.com.tw/
|
||||
|
||||
@@ -179,11 +179,12 @@ temp[1-*]_auto_point[1-*]_temp_hyst
|
||||
****************
|
||||
|
||||
temp[1-3]_type Sensor type selection.
|
||||
Integers 1, 2, 3 or thermistor Beta value (3435)
|
||||
Integers 1 to 4 or thermistor Beta value (typically 3435)
|
||||
Read/Write.
|
||||
1: PII/Celeron Diode
|
||||
2: 3904 transistor
|
||||
3: thermal diode
|
||||
4: thermistor (default/unknown Beta)
|
||||
Not all types are supported by all chips
|
||||
|
||||
temp[1-4]_max Temperature max value.
|
||||
@@ -261,6 +262,21 @@ alarms Alarm bitmask.
|
||||
of individual bits.
|
||||
Bits are defined in kernel/include/sensors.h.
|
||||
|
||||
alarms_in Alarm bitmask relative to in (voltage) channels
|
||||
Read only
|
||||
A '1' bit means an alarm, LSB corresponds to in0 and so on
|
||||
Prefered to 'alarms' for newer chips
|
||||
|
||||
alarms_fan Alarm bitmask relative to fan channels
|
||||
Read only
|
||||
A '1' bit means an alarm, LSB corresponds to fan1 and so on
|
||||
Prefered to 'alarms' for newer chips
|
||||
|
||||
alarms_temp Alarm bitmask relative to temp (temperature) channels
|
||||
Read only
|
||||
A '1' bit means an alarm, LSB corresponds to temp1 and so on
|
||||
Prefered to 'alarms' for newer chips
|
||||
|
||||
beep_enable Beep/interrupt enable
|
||||
0 to disable.
|
||||
1 to enable.
|
||||
|
||||
@@ -7,7 +7,7 @@ Supported adapters:
|
||||
Any combination of these host bridges:
|
||||
645, 645DX (aka 646), 648, 650, 651, 655, 735, 745, 746
|
||||
and these south bridges:
|
||||
961, 962, 963(L)
|
||||
961, 962, 963(L)
|
||||
|
||||
Author: Mark M. Hoffman <mhoffman@lightlink.com>
|
||||
|
||||
@@ -29,7 +29,7 @@ The command "lspci" as root should produce something like these lines:
|
||||
|
||||
or perhaps this...
|
||||
|
||||
00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
|
||||
00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
|
||||
00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0961
|
||||
00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
|
||||
|
||||
@@ -427,6 +427,23 @@ icmp_ignore_bogus_error_responses - BOOLEAN
|
||||
will avoid log file clutter.
|
||||
Default: FALSE
|
||||
|
||||
icmp_errors_use_inbound_ifaddr - BOOLEAN
|
||||
|
||||
If zero, icmp error messages are sent with the primary address of
|
||||
the exiting interface.
|
||||
|
||||
If non-zero, the message will be sent with the primary address of
|
||||
the interface that received the packet that caused the icmp error.
|
||||
This is the behaviour network many administrators will expect from
|
||||
a router. And it can make debugging complicated network layouts
|
||||
much easier.
|
||||
|
||||
Note that if no primary address exists for the interface selected,
|
||||
then the primary address of the first non-loopback interface that
|
||||
has one will be used regarldess of this setting.
|
||||
|
||||
Default: 0
|
||||
|
||||
igmp_max_memberships - INTEGER
|
||||
Change the maximum number of multicast groups we can subscribe to.
|
||||
Default: 20
|
||||
|
||||
@@ -1068,7 +1068,7 @@ SYNOPSIS
|
||||
|
||||
struct parport_operations {
|
||||
...
|
||||
void (*write_status) (struct parport *port, unsigned char s);
|
||||
void (*write_control) (struct parport *port, unsigned char s);
|
||||
...
|
||||
};
|
||||
|
||||
@@ -1097,9 +1097,9 @@ SYNOPSIS
|
||||
|
||||
struct parport_operations {
|
||||
...
|
||||
void (*frob_control) (struct parport *port,
|
||||
unsigned char mask,
|
||||
unsigned char val);
|
||||
unsigned char (*frob_control) (struct parport *port,
|
||||
unsigned char mask,
|
||||
unsigned char val);
|
||||
...
|
||||
};
|
||||
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
@@ -880,6 +880,10 @@ address which can extend beyond that limit.
|
||||
- device_type : Should be "soc"
|
||||
- ranges : Should be defined as specified in 1) to describe the
|
||||
translation of SOC addresses for memory mapped SOC registers.
|
||||
- bus-frequency: Contains the bus frequency for the SOC node.
|
||||
Typically, the value of this field is filled in by the boot
|
||||
loader.
|
||||
|
||||
|
||||
Recommended properties:
|
||||
|
||||
@@ -919,6 +923,7 @@ SOC.
|
||||
device_type = "soc";
|
||||
ranges = <00000000 e0000000 00100000>
|
||||
reg = <e0000000 00003000>;
|
||||
bus-frequency = <0>;
|
||||
}
|
||||
|
||||
|
||||
@@ -1170,6 +1175,8 @@ platforms are moved over to use the flattened-device-tree model.
|
||||
|
||||
mdio@24520 {
|
||||
reg = <24520 20>;
|
||||
device_type = "mdio";
|
||||
compatible = "gianfar";
|
||||
|
||||
ethernet-phy@0 {
|
||||
......
|
||||
@@ -1317,6 +1324,7 @@ not necessary as they are usually the same as the root node.
|
||||
device_type = "soc";
|
||||
ranges = <00000000 e0000000 00100000>
|
||||
reg = <e0000000 00003000>;
|
||||
bus-frequency = <0>;
|
||||
|
||||
mdio@24520 {
|
||||
reg = <24520 20>;
|
||||
|
||||
@@ -12,13 +12,20 @@ You can make this adapter from an old printer cable and solder things
|
||||
directly to the Butterfly. Or (if you have the parts and skills) you
|
||||
can come up with something fancier, providing ciruit protection to the
|
||||
Butterfly and the printer port, or with a better power supply than two
|
||||
signal pins from the printer port.
|
||||
signal pins from the printer port. Or for that matter, you can use
|
||||
similar cables to talk to many AVR boards, even a breadboard.
|
||||
|
||||
This is more powerful than "ISP programming" cables since it lets kernel
|
||||
SPI protocol drivers interact with the AVR, and could even let the AVR
|
||||
issue interrupts to them. Later, your protocol driver should work
|
||||
easily with a "real SPI controller", instead of this bitbanger.
|
||||
|
||||
|
||||
The first cable connections will hook Linux up to one SPI bus, with the
|
||||
AVR and a DataFlash chip; and to the AVR reset line. This is all you
|
||||
need to reflash the firmware, and the pins are the standard Atmel "ISP"
|
||||
connector pins (used also on non-Butterfly AVR boards).
|
||||
connector pins (used also on non-Butterfly AVR boards). On the parport
|
||||
side this is like "sp12" programming cables.
|
||||
|
||||
Signal Butterfly Parport (DB-25)
|
||||
------ --------- ---------------
|
||||
@@ -40,10 +47,14 @@ by clearing PORTB.[0-3]); (b) configure the mtd_dataflash driver; and
|
||||
SELECT = J400.PB0/nSS = pin 17/C3,nSELECT
|
||||
GND = J400.GND = pin 24/GND
|
||||
|
||||
The "USI" controller, using J405, can be used for a second SPI bus. That
|
||||
would let you talk to the AVR over SPI, running firmware that makes it act
|
||||
as an SPI slave, while letting either Linux or the AVR use the DataFlash.
|
||||
There are plenty of spare parport pins to wire this one up, such as:
|
||||
Or you could flash firmware making the AVR into an SPI slave (keeping the
|
||||
DataFlash in reset) and tweak the spi_butterfly driver to make it bind to
|
||||
the driver for your custom SPI-based protocol.
|
||||
|
||||
The "USI" controller, using J405, can also be used for a second SPI bus.
|
||||
That would let you talk to the AVR using custom SPI-with-USI firmware,
|
||||
while letting either Linux or the AVR use the DataFlash. There are plenty
|
||||
of spare parport pins to wire this one up, such as:
|
||||
|
||||
Signal Butterfly Parport (DB-25)
|
||||
------ --------- ---------------
|
||||
|
||||
@@ -0,0 +1,295 @@
|
||||
|
||||
unshare system call:
|
||||
--------------------
|
||||
This document describes the new system call, unshare. The document
|
||||
provides an overview of the feature, why it is needed, how it can
|
||||
be used, its interface specification, design, implementation and
|
||||
how it can be tested.
|
||||
|
||||
Change Log:
|
||||
-----------
|
||||
version 0.1 Initial document, Janak Desai (janak@us.ibm.com), Jan 11, 2006
|
||||
|
||||
Contents:
|
||||
---------
|
||||
1) Overview
|
||||
2) Benefits
|
||||
3) Cost
|
||||
4) Requirements
|
||||
5) Functional Specification
|
||||
6) High Level Design
|
||||
7) Low Level Design
|
||||
8) Test Specification
|
||||
9) Future Work
|
||||
|
||||
1) Overview
|
||||
-----------
|
||||
Most legacy operating system kernels support an abstraction of threads
|
||||
as multiple execution contexts within a process. These kernels provide
|
||||
special resources and mechanisms to maintain these "threads". The Linux
|
||||
kernel, in a clever and simple manner, does not make distinction
|
||||
between processes and "threads". The kernel allows processes to share
|
||||
resources and thus they can achieve legacy "threads" behavior without
|
||||
requiring additional data structures and mechanisms in the kernel. The
|
||||
power of implementing threads in this manner comes not only from
|
||||
its simplicity but also from allowing application programmers to work
|
||||
outside the confinement of all-or-nothing shared resources of legacy
|
||||
threads. On Linux, at the time of thread creation using the clone system
|
||||
call, applications can selectively choose which resources to share
|
||||
between threads.
|
||||
|
||||
unshare system call adds a primitive to the Linux thread model that
|
||||
allows threads to selectively 'unshare' any resources that were being
|
||||
shared at the time of their creation. unshare was conceptualized by
|
||||
Al Viro in the August of 2000, on the Linux-Kernel mailing list, as part
|
||||
of the discussion on POSIX threads on Linux. unshare augments the
|
||||
usefulness of Linux threads for applications that would like to control
|
||||
shared resources without creating a new process. unshare is a natural
|
||||
addition to the set of available primitives on Linux that implement
|
||||
the concept of process/thread as a virtual machine.
|
||||
|
||||
2) Benefits
|
||||
-----------
|
||||
unshare would be useful to large application frameworks such as PAM
|
||||
where creating a new process to control sharing/unsharing of process
|
||||
resources is not possible. Since namespaces are shared by default
|
||||
when creating a new process using fork or clone, unshare can benefit
|
||||
even non-threaded applications if they have a need to disassociate
|
||||
from default shared namespace. The following lists two use-cases
|
||||
where unshare can be used.
|
||||
|
||||
2.1 Per-security context namespaces
|
||||
-----------------------------------
|
||||
unshare can be used to implement polyinstantiated directories using
|
||||
the kernel's per-process namespace mechanism. Polyinstantiated directories,
|
||||
such as per-user and/or per-security context instance of /tmp, /var/tmp or
|
||||
per-security context instance of a user's home directory, isolate user
|
||||
processes when working with these directories. Using unshare, a PAM
|
||||
module can easily setup a private namespace for a user at login.
|
||||
Polyinstantiated directories are required for Common Criteria certification
|
||||
with Labeled System Protection Profile, however, with the availability
|
||||
of shared-tree feature in the Linux kernel, even regular Linux systems
|
||||
can benefit from setting up private namespaces at login and
|
||||
polyinstantiating /tmp, /var/tmp and other directories deemed
|
||||
appropriate by system administrators.
|
||||
|
||||
2.2 unsharing of virtual memory and/or open files
|
||||
-------------------------------------------------
|
||||
Consider a client/server application where the server is processing
|
||||
client requests by creating processes that share resources such as
|
||||
virtual memory and open files. Without unshare, the server has to
|
||||
decide what needs to be shared at the time of creating the process
|
||||
which services the request. unshare allows the server an ability to
|
||||
disassociate parts of the context during the servicing of the
|
||||
request. For large and complex middleware application frameworks, this
|
||||
ability to unshare after the process was created can be very
|
||||
useful.
|
||||
|
||||
3) Cost
|
||||
-------
|
||||
In order to not duplicate code and to handle the fact that unshare
|
||||
works on an active task (as opposed to clone/fork working on a newly
|
||||
allocated inactive task) unshare had to make minor reorganizational
|
||||
changes to copy_* functions utilized by clone/fork system call.
|
||||
There is a cost associated with altering existing, well tested and
|
||||
stable code to implement a new feature that may not get exercised
|
||||
extensively in the beginning. However, with proper design and code
|
||||
review of the changes and creation of an unshare test for the LTP
|
||||
the benefits of this new feature can exceed its cost.
|
||||
|
||||
4) Requirements
|
||||
---------------
|
||||
unshare reverses sharing that was done using clone(2) system call,
|
||||
so unshare should have a similar interface as clone(2). That is,
|
||||
since flags in clone(int flags, void *stack) specifies what should
|
||||
be shared, similar flags in unshare(int flags) should specify
|
||||
what should be unshared. Unfortunately, this may appear to invert
|
||||
the meaning of the flags from the way they are used in clone(2).
|
||||
However, there was no easy solution that was less confusing and that
|
||||
allowed incremental context unsharing in future without an ABI change.
|
||||
|
||||
unshare interface should accommodate possible future addition of
|
||||
new context flags without requiring a rebuild of old applications.
|
||||
If and when new context flags are added, unshare design should allow
|
||||
incremental unsharing of those resources on an as needed basis.
|
||||
|
||||
5) Functional Specification
|
||||
---------------------------
|
||||
NAME
|
||||
unshare - disassociate parts of the process execution context
|
||||
|
||||
SYNOPSIS
|
||||
#include <sched.h>
|
||||
|
||||
int unshare(int flags);
|
||||
|
||||
DESCRIPTION
|
||||
unshare allows a process to disassociate parts of its execution
|
||||
context that are currently being shared with other processes. Part
|
||||
of execution context, such as the namespace, is shared by default
|
||||
when a new process is created using fork(2), while other parts,
|
||||
such as the virtual memory, open file descriptors, etc, may be
|
||||
shared by explicit request to share them when creating a process
|
||||
using clone(2).
|
||||
|
||||
The main use of unshare is to allow a process to control its
|
||||
shared execution context without creating a new process.
|
||||
|
||||
The flags argument specifies one or bitwise-or'ed of several of
|
||||
the following constants.
|
||||
|
||||
CLONE_FS
|
||||
If CLONE_FS is set, file system information of the caller
|
||||
is disassociated from the shared file system information.
|
||||
|
||||
CLONE_FILES
|
||||
If CLONE_FILES is set, the file descriptor table of the
|
||||
caller is disassociated from the shared file descriptor
|
||||
table.
|
||||
|
||||
CLONE_NEWNS
|
||||
If CLONE_NEWNS is set, the namespace of the caller is
|
||||
disassociated from the shared namespace.
|
||||
|
||||
CLONE_VM
|
||||
If CLONE_VM is set, the virtual memory of the caller is
|
||||
disassociated from the shared virtual memory.
|
||||
|
||||
RETURN VALUE
|
||||
On success, zero returned. On failure, -1 is returned and errno is
|
||||
|
||||
ERRORS
|
||||
EPERM CLONE_NEWNS was specified by a non-root process (process
|
||||
without CAP_SYS_ADMIN).
|
||||
|
||||
ENOMEM Cannot allocate sufficient memory to copy parts of caller's
|
||||
context that need to be unshared.
|
||||
|
||||
EINVAL Invalid flag was specified as an argument.
|
||||
|
||||
CONFORMING TO
|
||||
The unshare() call is Linux-specific and should not be used
|
||||
in programs intended to be portable.
|
||||
|
||||
SEE ALSO
|
||||
clone(2), fork(2)
|
||||
|
||||
6) High Level Design
|
||||
--------------------
|
||||
Depending on the flags argument, the unshare system call allocates
|
||||
appropriate process context structures, populates it with values from
|
||||
the current shared version, associates newly duplicated structures
|
||||
with the current task structure and releases corresponding shared
|
||||
versions. Helper functions of clone (copy_*) could not be used
|
||||
directly by unshare because of the following two reasons.
|
||||
1) clone operates on a newly allocated not-yet-active task
|
||||
structure, where as unshare operates on the current active
|
||||
task. Therefore unshare has to take appropriate task_lock()
|
||||
before associating newly duplicated context structures
|
||||
2) unshare has to allocate and duplicate all context structures
|
||||
that are being unshared, before associating them with the
|
||||
current task and releasing older shared structures. Failure
|
||||
do so will create race conditions and/or oops when trying
|
||||
to backout due to an error. Consider the case of unsharing
|
||||
both virtual memory and namespace. After successfully unsharing
|
||||
vm, if the system call encounters an error while allocating
|
||||
new namespace structure, the error return code will have to
|
||||
reverse the unsharing of vm. As part of the reversal the
|
||||
system call will have to go back to older, shared, vm
|
||||
structure, which may not exist anymore.
|
||||
|
||||
Therefore code from copy_* functions that allocated and duplicated
|
||||
current context structure was moved into new dup_* functions. Now,
|
||||
copy_* functions call dup_* functions to allocate and duplicate
|
||||
appropriate context structures and then associate them with the
|
||||
task structure that is being constructed. unshare system call on
|
||||
the other hand performs the following:
|
||||
1) Check flags to force missing, but implied, flags
|
||||
2) For each context structure, call the corresponding unshare
|
||||
helper function to allocate and duplicate a new context
|
||||
structure, if the appropriate bit is set in the flags argument.
|
||||
3) If there is no error in allocation and duplication and there
|
||||
are new context structures then lock the current task structure,
|
||||
associate new context structures with the current task structure,
|
||||
and release the lock on the current task structure.
|
||||
4) Appropriately release older, shared, context structures.
|
||||
|
||||
7) Low Level Design
|
||||
-------------------
|
||||
Implementation of unshare can be grouped in the following 4 different
|
||||
items:
|
||||
a) Reorganization of existing copy_* functions
|
||||
b) unshare system call service function
|
||||
c) unshare helper functions for each different process context
|
||||
d) Registration of system call number for different architectures
|
||||
|
||||
7.1) Reorganization of copy_* functions
|
||||
Each copy function such as copy_mm, copy_namespace, copy_files,
|
||||
etc, had roughly two components. The first component allocated
|
||||
and duplicated the appropriate structure and the second component
|
||||
linked it to the task structure passed in as an argument to the copy
|
||||
function. The first component was split into its own function.
|
||||
These dup_* functions allocated and duplicated the appropriate
|
||||
context structure. The reorganized copy_* functions invoked
|
||||
their corresponding dup_* functions and then linked the newly
|
||||
duplicated structures to the task structure with which the
|
||||
copy function was called.
|
||||
|
||||
7.2) unshare system call service function
|
||||
* Check flags
|
||||
Force implied flags. If CLONE_THREAD is set force CLONE_VM.
|
||||
If CLONE_VM is set, force CLONE_SIGHAND. If CLONE_SIGHAND is
|
||||
set and signals are also being shared, force CLONE_THREAD. If
|
||||
CLONE_NEWNS is set, force CLONE_FS.
|
||||
* For each context flag, invoke the corresponding unshare_*
|
||||
helper routine with flags passed into the system call and a
|
||||
reference to pointer pointing the new unshared structure
|
||||
* If any new structures are created by unshare_* helper
|
||||
functions, take the task_lock() on the current task,
|
||||
modify appropriate context pointers, and release the
|
||||
task lock.
|
||||
* For all newly unshared structures, release the corresponding
|
||||
older, shared, structures.
|
||||
|
||||
7.3) unshare_* helper functions
|
||||
For unshare_* helpers corresponding to CLONE_SYSVSEM, CLONE_SIGHAND,
|
||||
and CLONE_THREAD, return -EINVAL since they are not implemented yet.
|
||||
For others, check the flag value to see if the unsharing is
|
||||
required for that structure. If it is, invoke the corresponding
|
||||
dup_* function to allocate and duplicate the structure and return
|
||||
a pointer to it.
|
||||
|
||||
7.4) Appropriately modify architecture specific code to register the
|
||||
the new system call.
|
||||
|
||||
8) Test Specification
|
||||
---------------------
|
||||
The test for unshare should test the following:
|
||||
1) Valid flags: Test to check that clone flags for signal and
|
||||
signal handlers, for which unsharing is not implemented
|
||||
yet, return -EINVAL.
|
||||
2) Missing/implied flags: Test to make sure that if unsharing
|
||||
namespace without specifying unsharing of filesystem, correctly
|
||||
unshares both namespace and filesystem information.
|
||||
3) For each of the four (namespace, filesystem, files and vm)
|
||||
supported unsharing, verify that the system call correctly
|
||||
unshares the appropriate structure. Verify that unsharing
|
||||
them individually as well as in combination with each
|
||||
other works as expected.
|
||||
4) Concurrent execution: Use shared memory segments and futex on
|
||||
an address in the shm segment to synchronize execution of
|
||||
about 10 threads. Have a couple of threads execute execve,
|
||||
a couple _exit and the rest unshare with different combination
|
||||
of flags. Verify that unsharing is performed as expected and
|
||||
that there are no oops or hangs.
|
||||
|
||||
9) Future Work
|
||||
--------------
|
||||
The current implementation of unshare does not allow unsharing of
|
||||
signals and signal handlers. Signals are complex to begin with and
|
||||
to unshare signals and/or signal handlers of a currently running
|
||||
process is even more complex. If in the future there is a specific
|
||||
need to allow unsharing of signals and/or signal handlers, it can
|
||||
be incrementally added to unshare without affecting legacy
|
||||
applications using unshare.
|
||||
|
||||
@@ -42,4 +42,4 @@
|
||||
41 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid (Low Profile) [0070:9800,0070:9802]
|
||||
42 -> digitalnow DNTV Live! DVB-T Pro [1822:0025]
|
||||
43 -> KWorld/VStream XPert DVB-T with cx22702 [17de:08a1]
|
||||
44 -> DViCO FusionHDTV DVB-T Dual Digital [18ac:db50]
|
||||
44 -> DViCO FusionHDTV DVB-T Dual Digital [18ac:db50,18ac:db54]
|
||||
@@ -1,7 +1,7 @@
|
||||
0 -> UNKNOWN/GENERIC
|
||||
1 -> Proteus Pro [philips reference design] [1131:2001,1131:2001]
|
||||
2 -> LifeView FlyVIDEO3000 [5168:0138,4e42:0138]
|
||||
3 -> LifeView FlyVIDEO2000 [5168:0138]
|
||||
3 -> LifeView/Typhoon FlyVIDEO2000 [5168:0138,4e42:0138]
|
||||
4 -> EMPRESS [1131:6752]
|
||||
5 -> SKNet Monster TV [1131:4e85]
|
||||
6 -> Tevion MD 9717
|
||||
@@ -53,12 +53,12 @@
|
||||
52 -> AverMedia AverTV/305 [1461:2108]
|
||||
53 -> ASUS TV-FM 7135 [1043:4845]
|
||||
54 -> LifeView FlyTV Platinum FM [5168:0214,1489:0214]
|
||||
55 -> LifeView FlyDVB-T DUO [5168:0502,5168:0306]
|
||||
55 -> LifeView FlyDVB-T DUO [5168:0306]
|
||||
56 -> Avermedia AVerTV 307 [1461:a70a]
|
||||
57 -> Avermedia AVerTV GO 007 FM [1461:f31f]
|
||||
58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0351,1421:0370,1421:1370]
|
||||
59 -> Kworld/Tevion V-Stream Xpert TV PVR7134
|
||||
60 -> Typhoon DVB-T Duo Digital/Analog Cardbus [4e42:0502]
|
||||
60 -> LifeView/Typhoon FlyDVB-T Duo Cardbus [5168:0502,4e42:0502]
|
||||
61 -> Philips TOUGH DVB-T reference design [1131:2004]
|
||||
62 -> Compro VideoMate TV Gold+II
|
||||
63 -> Kworld Xpert TV PVR7134
|
||||
|
||||
@@ -40,6 +40,18 @@ APICs
|
||||
no_timer_check Don't check the IO-APIC timer. This can work around
|
||||
problems with incorrect timer initialization on some boards.
|
||||
|
||||
apicmaintimer Run time keeping from the local APIC timer instead
|
||||
of using the PIT/HPET interrupt for this. This is useful
|
||||
when the PIT/HPET interrupts are unreliable.
|
||||
|
||||
noapicmaintimer Don't do time keeping using the APIC timer.
|
||||
Useful when this option was auto selected, but doesn't work.
|
||||
|
||||
apicpmtimer
|
||||
Do APIC timer calibration using the pmtimer. Implies
|
||||
apicmaintimer. Useful when your PIT timer is totally
|
||||
broken.
|
||||
|
||||
Early Console
|
||||
|
||||
syntax: earlyprintk=vga
|
||||
|
||||
+16
-7
@@ -540,7 +540,8 @@ S: Supported
|
||||
|
||||
BTTV VIDEO4LINUX DRIVER
|
||||
P: Mauro Carvalho Chehab
|
||||
M: mchehab@brturbo.com.br
|
||||
M: mchehab@infradead.org
|
||||
M: v4l-dvb-maintainer@linuxtv.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://linuxtv.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
|
||||
@@ -557,7 +558,8 @@ S: Supported
|
||||
|
||||
CONFIGFS
|
||||
P: Joel Becker
|
||||
M: Joel Becker <joel.becker@oracle.com>
|
||||
M: joel.becker@oracle.com
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
CIRRUS LOGIC GENERIC FBDEV DRIVER
|
||||
@@ -836,11 +838,12 @@ S: Maintained
|
||||
|
||||
DVB SUBSYSTEM AND DRIVERS
|
||||
P: LinuxTV.org Project
|
||||
M: linux-dvb-maintainer@linuxtv.org
|
||||
M: mchehab@infradead.org
|
||||
M: v4l-dvb-maintainer@linuxtv.org
|
||||
L: linux-dvb@linuxtv.org (subscription required)
|
||||
W: http://linuxtv.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
|
||||
S: Supported
|
||||
S: Maintained
|
||||
|
||||
EATA-DMA SCSI DRIVER
|
||||
P: Michael Neuffer
|
||||
@@ -928,6 +931,12 @@ M: sct@redhat.com, akpm@osdl.org, adilger@clusterfs.com
|
||||
L: ext3-users@redhat.com
|
||||
S: Maintained
|
||||
|
||||
F71805F HARDWARE MONITORING DRIVER
|
||||
P: Jean Delvare
|
||||
M: khali@linux-fr.org
|
||||
L: lm-sensors@lm-sensors.org
|
||||
S: Maintained
|
||||
|
||||
FARSYNC SYNCHRONOUS DRIVER
|
||||
P: Kevin Curtis
|
||||
M: kevin.curtis@farsite.co.uk
|
||||
@@ -1984,7 +1993,6 @@ M: philb@gnu.org
|
||||
P: Tim Waugh
|
||||
M: tim@cyberelk.net
|
||||
P: David Campbell
|
||||
M: campbell@torque.net
|
||||
P: Andrea Arcangeli
|
||||
M: andrea@suse.de
|
||||
L: linux-parport@lists.infradead.org
|
||||
@@ -2298,7 +2306,7 @@ S: Supported
|
||||
|
||||
SELINUX SECURITY MODULE
|
||||
P: Stephen Smalley
|
||||
M: sds@epoch.ncsc.mil
|
||||
M: sds@tycho.nsa.gov
|
||||
P: James Morris
|
||||
M: jmorris@namei.org
|
||||
L: linux-kernel@vger.kernel.org (kernel issues)
|
||||
@@ -2956,7 +2964,8 @@ S: Maintained
|
||||
|
||||
VIDEO FOR LINUX
|
||||
P: Mauro Carvalho Chehab
|
||||
M: mchehab@brturbo.com.br
|
||||
M: mchehab@infradead.org
|
||||
M: v4l-dvb-maintainer@linuxtv.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://linuxtv.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
|
||||
|
||||
Loaded 20 of 859 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user