From 806ba6409061ae49421319e3745026014abc49c2 Mon Sep 17 00:00:00 2001 From: Rudolf Marek Date: Mon, 9 Jan 2006 22:46:14 +0100 Subject: [PATCH] i2c: Rename i2c-sis96x documentation file This patch just renames the documentation file to correct file name. i2c-sis69x -> i2c-sis96x. Signed-off-by: Rudolf Marek Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/busses/i2c-sis69x | 73 ------------------------------------- Documentation/i2c/busses/i2c-sis96x | 73 +++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+), 73 deletions(-) delete mode 100644 Documentation/i2c/busses/i2c-sis69x create mode 100644 Documentation/i2c/busses/i2c-sis96x (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-sis69x b/Documentation/i2c/busses/i2c-sis69x deleted file mode 100644 index b88953dfd58..00000000000 --- a/Documentation/i2c/busses/i2c-sis69x +++ /dev/null @@ -1,73 +0,0 @@ -Kernel driver i2c-sis96x - -Replaces 2.4.x i2c-sis645 - -Supported adapters: - * Silicon Integrated Systems Corp (SiS) - 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) - -Author: Mark M. Hoffman - -Description ------------ - -This SMBus only driver is known to work on motherboards with the above -named chipset combinations. The driver was developed without benefit of a -proper datasheet from SiS. The SMBus registers are assumed compatible with -those of the SiS630, although they are located in a completely different -place. Thanks to Alexander Malysh for providing the -SiS630 datasheet (and driver). - -The command "lspci" as root should produce something like these lines: - -00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645 -00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 -00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016 - -or perhaps this... - -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 - -(kernel versions later than 2.4.18 may fill in the "Unknown"s) - -If you cant see it please look on quirk_sis_96x_smbus -(drivers/pci/quirks.c) (also if southbridge detection fails) - -I suspect that this driver could be made to work for the following SiS -chipsets as well: 635, and 635T. If anyone owns a board with those chips -AND is willing to risk crashing & burning an otherwise well-behaved kernel -in the name of progress... please contact me at or -via the project's mailing list: . Please -send bug reports and/or success stories as well. - - -TO DOs ------- - -* The driver does not support SMBus block reads/writes; I may add them if a -scenario is found where they're needed. - - -Thank You ---------- - -Mark D. Studebaker - - design hints and bug fixes -Alexander Maylsh - - ditto, plus an important datasheet... almost the one I really wanted -Hans-Günter Lütke Uphues - - patch for SiS735 -Robert Zwerus - - testing for SiS645DX -Kianusch Sayah Karadji - - patch for SiS645DX/962 -Ken Healy - - patch for SiS655 - -To anyone else who has written w/ feedback, thanks! - diff --git a/Documentation/i2c/busses/i2c-sis96x b/Documentation/i2c/busses/i2c-sis96x new file mode 100644 index 00000000000..00a009b977e --- /dev/null +++ b/Documentation/i2c/busses/i2c-sis96x @@ -0,0 +1,73 @@ +Kernel driver i2c-sis96x + +Replaces 2.4.x i2c-sis645 + +Supported adapters: + * Silicon Integrated Systems Corp (SiS) + 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) + +Author: Mark M. Hoffman + +Description +----------- + +This SMBus only driver is known to work on motherboards with the above +named chipset combinations. The driver was developed without benefit of a +proper datasheet from SiS. The SMBus registers are assumed compatible with +those of the SiS630, although they are located in a completely different +place. Thanks to Alexander Malysh for providing the +SiS630 datasheet (and driver). + +The command "lspci" as root should produce something like these lines: + +00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645 +00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 +00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016 + +or perhaps this... + +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 + +(kernel versions later than 2.4.18 may fill in the "Unknown"s) + +If you cant see it please look on quirk_sis_96x_smbus +(drivers/pci/quirks.c) (also if southbridge detection fails) + +I suspect that this driver could be made to work for the following SiS +chipsets as well: 635, and 635T. If anyone owns a board with those chips +AND is willing to risk crashing & burning an otherwise well-behaved kernel +in the name of progress... please contact me at or +via the project's mailing list: . Please +send bug reports and/or success stories as well. + + +TO DOs +------ + +* The driver does not support SMBus block reads/writes; I may add them if a +scenario is found where they're needed. + + +Thank You +--------- + +Mark D. Studebaker + - design hints and bug fixes +Alexander Maylsh + - ditto, plus an important datasheet... almost the one I really wanted +Hans-Günter Lütke Uphues + - patch for SiS735 +Robert Zwerus + - testing for SiS645DX +Kianusch Sayah Karadji + - patch for SiS645DX/962 +Ken Healy + - patch for SiS655 + +To anyone else who has written w/ feedback, thanks! + -- cgit v1.2.3 From 5db3d3da93fb93875c719239892ac526cfd2d584 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Mon, 9 Jan 2006 23:32:57 +0100 Subject: [PATCH] hwmon: Add f71805f documentation Add some documentation for the new f71805f driver. This is almost the same help that was present in lm_sensors, with a few minor layout fixes. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/f71805f | 105 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 Documentation/hwmon/f71805f (limited to 'Documentation') diff --git a/Documentation/hwmon/f71805f b/Documentation/hwmon/f71805f new file mode 100644 index 00000000000..28c5b7d1eb9 --- /dev/null +++ b/Documentation/hwmon/f71805f @@ -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 + +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. -- cgit v1.2.3 From e53004e20a58e9d28347e02adccb37a33e0d771a Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Mon, 9 Jan 2006 23:26:14 +0100 Subject: [PATCH] hwmon: New f71805f driver This is my f71805f hardware monitoring driver ported from lm_sensors to Linux 2.6. This new driver differs from the other hardware monitoring drivers in that it is implemented as a platform driver. This might not be optimal yet (we would probably need a generic infrastructure and bus type for Super-I/O logical devices) but it is certainly much better than the i2c-isa solution. Note that this driver requires lm_sensors CVS. I hope to get it released as 2.10.0 soon. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/hwmon/sysfs-interface | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index 764cdc5480e..a0d0ab24288 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -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. -- cgit v1.2.3 From c5e3fbf22ccba0879b174fab7ec0e322b1266c2c Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Wed, 18 Jan 2006 22:39:48 +0100 Subject: [PATCH] hwmon: Fix reboot on it87 driver load Only scan I2C address 0x2d. This is the default address and no IT87xxF chip was ever seen on I2C at a different address. These chips are better accessed through their ISA interface anyway. This fixes bug #5889, although it doesn't address the whole class of problems. We'd need the ability to blacklist arbitrary I2C addresses on systems known to contain I2C devices which behave badly when probed. Plan the I2C interface for removal as well. If nobody complains within a year, it will confirm my impression that the I2C interface isn't actually needed by anyone. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- Documentation/feature-removal-schedule.txt | 9 +++++++++ Documentation/hwmon/it87 | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 4d4897c8ef9..b730d765b52 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -162,3 +162,12 @@ What: pci_module_init(driver) When: January 2007 Why: Is replaced by pci_register_driver(pci_driver). Who: Richard Knutsson and Greg Kroah-Hartman + +--------------------------- + +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 diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 7f42e441c64..9555be1ed99 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -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/ -- cgit v1.2.3 From 9c1da3cb46316e40bac766ce45556dc4fd8df3ca Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sat, 21 Jan 2006 13:21:43 -0800 Subject: [PATCH] SPI: spi_butterfly, restore lost deltas This resolves some minor version skew glitches that accumulated for the AVR Butterfly adapter driver, which caused among other things the existence of a duplicate Kconfig entry. Most of it boils down to comment updates, but in one case it removes some now-superfluous code that would be better if not copied into other controller-level drivers. Signed-off-by: David Brownell --- Documentation/spi/butterfly | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/spi/butterfly b/Documentation/spi/butterfly index a2e8c8d90e3..9927af7a629 100644 --- a/Documentation/spi/butterfly +++ b/Documentation/spi/butterfly @@ -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) ------ --------- --------------- -- cgit v1.2.3 From 7d4b95ae8e946e5754122220644c865ec3735428 Mon Sep 17 00:00:00 2001 From: Becky Bruce Date: Mon, 6 Feb 2006 14:26:31 -0600 Subject: [PATCH] documentation/powerpc: add bus-frequency property to SOC node Updated SOC node definition in documentation to include bus-frequency property. Also extended mdio example to match specification. Signed-off-by: Becky Bruce Signed-off-by: Kumar Gala Signed-off-by: Paul Mackerras --- Documentation/powerpc/booting-without-of.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 1284498e847..54e5f9b1536 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -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 = ; + 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 = ; + bus-frequency = <0>; mdio@24520 { reg = <24520 20>; -- cgit v1.2.3 From 0d4c3e7a8c65892c7d6a748fdbb4499e988880db Mon Sep 17 00:00:00 2001 From: JANAK DESAI Date: Tue, 7 Feb 2006 12:58:56 -0800 Subject: [PATCH] unshare system call -v5: Documentation file Documents the new feature, why it is needed, it's cost, design, implementation, and test plan. Signed-off-by: Janak Desai Cc: Al Viro Cc: Christoph Hellwig Cc: Andi Kleen Cc: Paul Mackerras Acked-by: Michael Kerrisk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/unshare.txt | 295 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 295 insertions(+) create mode 100644 Documentation/unshare.txt (limited to 'Documentation') diff --git a/Documentation/unshare.txt b/Documentation/unshare.txt new file mode 100644 index 00000000000..90a5e9e5bef --- /dev/null +++ b/Documentation/unshare.txt @@ -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 + + 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. + -- cgit v1.2.3