diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/Changes | 43 | ||||
-rw-r--r-- | Documentation/feature-removal-schedule.txt | 22 | ||||
-rw-r--r-- | Documentation/filesystems/nilfs2.txt | 1 | ||||
-rw-r--r-- | Documentation/laptops/thinkpad-acpi.txt | 5 | ||||
-rw-r--r-- | Documentation/networking/ip-sysctl.txt | 2 | ||||
-rw-r--r-- | Documentation/spinlocks.txt | 45 |
6 files changed, 53 insertions, 65 deletions
diff --git a/Documentation/Changes b/Documentation/Changes index 5f4828a034e3..b17580885273 100644 --- a/Documentation/Changes +++ b/Documentation/Changes | |||
@@ -2,13 +2,7 @@ Intro | |||
2 | ===== | 2 | ===== |
3 | 3 | ||
4 | This document is designed to provide a list of the minimum levels of | 4 | This document is designed to provide a list of the minimum levels of |
5 | software necessary to run the 2.6 kernels, as well as provide brief | 5 | software necessary to run the 3.0 kernels. |
6 | instructions regarding any other "Gotchas" users may encounter when | ||
7 | trying life on the Bleeding Edge. If upgrading from a pre-2.4.x | ||
8 | kernel, please consult the Changes file included with 2.4.x kernels for | ||
9 | additional information; most of that information will not be repeated | ||
10 | here. Basically, this document assumes that your system is already | ||
11 | functional and running at least 2.4.x kernels. | ||
12 | 6 | ||
13 | This document is originally based on my "Changes" file for 2.0.x kernels | 7 | This document is originally based on my "Changes" file for 2.0.x kernels |
14 | and therefore owes credit to the same people as that file (Jared Mauch, | 8 | and therefore owes credit to the same people as that file (Jared Mauch, |
@@ -22,11 +16,10 @@ Upgrade to at *least* these software revisions before thinking you've | |||
22 | encountered a bug! If you're unsure what version you're currently | 16 | encountered a bug! If you're unsure what version you're currently |
23 | running, the suggested command should tell you. | 17 | running, the suggested command should tell you. |
24 | 18 | ||
25 | Again, keep in mind that this list assumes you are already | 19 | Again, keep in mind that this list assumes you are already functionally |
26 | functionally running a Linux 2.4 kernel. Also, not all tools are | 20 | running a Linux kernel. Also, not all tools are necessary on all |
27 | necessary on all systems; obviously, if you don't have any ISDN | 21 | systems; obviously, if you don't have any ISDN hardware, for example, |
28 | hardware, for example, you probably needn't concern yourself with | 22 | you probably needn't concern yourself with isdn4k-utils. |
29 | isdn4k-utils. | ||
30 | 23 | ||
31 | o Gnu C 3.2 # gcc --version | 24 | o Gnu C 3.2 # gcc --version |
32 | o Gnu make 3.80 # make --version | 25 | o Gnu make 3.80 # make --version |
@@ -114,12 +107,12 @@ Ksymoops | |||
114 | 107 | ||
115 | If the unthinkable happens and your kernel oopses, you may need the | 108 | If the unthinkable happens and your kernel oopses, you may need the |
116 | ksymoops tool to decode it, but in most cases you don't. | 109 | ksymoops tool to decode it, but in most cases you don't. |
117 | In the 2.6 kernel it is generally preferred to build the kernel with | 110 | It is generally preferred to build the kernel with CONFIG_KALLSYMS so |
118 | CONFIG_KALLSYMS so that it produces readable dumps that can be used as-is | 111 | that it produces readable dumps that can be used as-is (this also |
119 | (this also produces better output than ksymoops). | 112 | produces better output than ksymoops). If for some reason your kernel |
120 | If for some reason your kernel is not build with CONFIG_KALLSYMS and | 113 | is not build with CONFIG_KALLSYMS and you have no way to rebuild and |
121 | you have no way to rebuild and reproduce the Oops with that option, then | 114 | reproduce the Oops with that option, then you can still decode that Oops |
122 | you can still decode that Oops with ksymoops. | 115 | with ksymoops. |
123 | 116 | ||
124 | Module-Init-Tools | 117 | Module-Init-Tools |
125 | ----------------- | 118 | ----------------- |
@@ -261,8 +254,8 @@ needs to be recompiled or (preferably) upgraded. | |||
261 | NFS-utils | 254 | NFS-utils |
262 | --------- | 255 | --------- |
263 | 256 | ||
264 | In 2.4 and earlier kernels, the nfs server needed to know about any | 257 | In ancient (2.4 and earlier) kernels, the nfs server needed to know |
265 | client that expected to be able to access files via NFS. This | 258 | about any client that expected to be able to access files via NFS. This |
266 | information would be given to the kernel by "mountd" when the client | 259 | information would be given to the kernel by "mountd" when the client |
267 | mounted the filesystem, or by "exportfs" at system startup. exportfs | 260 | mounted the filesystem, or by "exportfs" at system startup. exportfs |
268 | would take information about active clients from /var/lib/nfs/rmtab. | 261 | would take information about active clients from /var/lib/nfs/rmtab. |
@@ -272,11 +265,11 @@ which is not always easy, particularly when trying to implement | |||
272 | fail-over. Even when the system is working well, rmtab suffers from | 265 | fail-over. Even when the system is working well, rmtab suffers from |
273 | getting lots of old entries that never get removed. | 266 | getting lots of old entries that never get removed. |
274 | 267 | ||
275 | With 2.6 we have the option of having the kernel tell mountd when it | 268 | With modern kernels we have the option of having the kernel tell mountd |
276 | gets a request from an unknown host, and mountd can give appropriate | 269 | when it gets a request from an unknown host, and mountd can give |
277 | export information to the kernel. This removes the dependency on | 270 | appropriate export information to the kernel. This removes the |
278 | rmtab and means that the kernel only needs to know about currently | 271 | dependency on rmtab and means that the kernel only needs to know about |
279 | active clients. | 272 | currently active clients. |
280 | 273 | ||
281 | To enable this new functionality, you need to: | 274 | To enable this new functionality, you need to: |
282 | 275 | ||
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 72e238465b0b..b1c921c27519 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -583,3 +583,25 @@ Why: Superseded by the UVCIOC_CTRL_QUERY ioctl. | |||
583 | Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com> | 583 | Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
584 | 584 | ||
585 | ---------------------------- | 585 | ---------------------------- |
586 | |||
587 | What: For VIDIOC_S_FREQUENCY the type field must match the device node's type. | ||
588 | If not, return -EINVAL. | ||
589 | When: 3.2 | ||
590 | Why: It makes no sense to switch the tuner to radio mode by calling | ||
591 | VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by | ||
592 | calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a | ||
593 | move to more consistent handling of tv and radio tuners. | ||
594 | Who: Hans Verkuil <hans.verkuil@cisco.com> | ||
595 | |||
596 | ---------------------------- | ||
597 | |||
598 | What: Opening a radio device node will no longer automatically switch the | ||
599 | tuner mode from tv to radio. | ||
600 | When: 3.3 | ||
601 | Why: Just opening a V4L device should not change the state of the hardware | ||
602 | like that. It's very unexpected and against the V4L spec. Instead, you | ||
603 | switch to radio mode by calling VIDIOC_S_FREQUENCY. This is the second | ||
604 | and last step of the move to consistent handling of tv and radio tuners. | ||
605 | Who: Hans Verkuil <hans.verkuil@cisco.com> | ||
606 | |||
607 | ---------------------------- | ||
diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt index d5c0cef38a71..873a2ab2e9f8 100644 --- a/Documentation/filesystems/nilfs2.txt +++ b/Documentation/filesystems/nilfs2.txt | |||
@@ -40,7 +40,6 @@ Features which NILFS2 does not support yet: | |||
40 | - POSIX ACLs | 40 | - POSIX ACLs |
41 | - quotas | 41 | - quotas |
42 | - fsck | 42 | - fsck |
43 | - resize | ||
44 | - defragmentation | 43 | - defragmentation |
45 | 44 | ||
46 | Mount options | 45 | Mount options |
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 1565eefd6fd5..61815483efa3 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt | |||
@@ -534,6 +534,8 @@ Events that are never propagated by the driver: | |||
534 | 0x2404 System is waking up from hibernation to undock | 534 | 0x2404 System is waking up from hibernation to undock |
535 | 0x2405 System is waking up from hibernation to eject bay | 535 | 0x2405 System is waking up from hibernation to eject bay |
536 | 0x5010 Brightness level changed/control event | 536 | 0x5010 Brightness level changed/control event |
537 | 0x6000 KEYBOARD: Numlock key pressed | ||
538 | 0x6005 KEYBOARD: Fn key pressed (TO BE VERIFIED) | ||
537 | 539 | ||
538 | Events that are propagated by the driver to userspace: | 540 | Events that are propagated by the driver to userspace: |
539 | 541 | ||
@@ -545,6 +547,8 @@ Events that are propagated by the driver to userspace: | |||
545 | 0x3006 Bay hotplug request (hint to power up SATA link when | 547 | 0x3006 Bay hotplug request (hint to power up SATA link when |
546 | the optical drive tray is ejected) | 548 | the optical drive tray is ejected) |
547 | 0x4003 Undocked (see 0x2x04), can sleep again | 549 | 0x4003 Undocked (see 0x2x04), can sleep again |
550 | 0x4010 Docked into hotplug port replicator (non-ACPI dock) | ||
551 | 0x4011 Undocked from hotplug port replicator (non-ACPI dock) | ||
548 | 0x500B Tablet pen inserted into its storage bay | 552 | 0x500B Tablet pen inserted into its storage bay |
549 | 0x500C Tablet pen removed from its storage bay | 553 | 0x500C Tablet pen removed from its storage bay |
550 | 0x6011 ALARM: battery is too hot | 554 | 0x6011 ALARM: battery is too hot |
@@ -552,6 +556,7 @@ Events that are propagated by the driver to userspace: | |||
552 | 0x6021 ALARM: a sensor is too hot | 556 | 0x6021 ALARM: a sensor is too hot |
553 | 0x6022 ALARM: a sensor is extremely hot | 557 | 0x6022 ALARM: a sensor is extremely hot |
554 | 0x6030 System thermal table changed | 558 | 0x6030 System thermal table changed |
559 | 0x6040 Nvidia Optimus/AC adapter related (TO BE VERIFIED) | ||
555 | 560 | ||
556 | Battery nearly empty alarms are a last resort attempt to get the | 561 | Battery nearly empty alarms are a last resort attempt to get the |
557 | operating system to hibernate or shutdown cleanly (0x2313), or shutdown | 562 | operating system to hibernate or shutdown cleanly (0x2313), or shutdown |
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index d3d653a5f9b9..bfe924217f24 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt | |||
@@ -346,7 +346,7 @@ tcp_orphan_retries - INTEGER | |||
346 | when RTO retransmissions remain unacknowledged. | 346 | when RTO retransmissions remain unacknowledged. |
347 | See tcp_retries2 for more details. | 347 | See tcp_retries2 for more details. |
348 | 348 | ||
349 | The default value is 7. | 349 | The default value is 8. |
350 | If your machine is a loaded WEB server, | 350 | If your machine is a loaded WEB server, |
351 | you should think about lowering this value, such sockets | 351 | you should think about lowering this value, such sockets |
352 | may consume significant resources. Cf. tcp_max_orphans. | 352 | may consume significant resources. Cf. tcp_max_orphans. |
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 2e3c64b1a6a5..9dbe885ecd8d 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt | |||
@@ -13,18 +13,8 @@ static DEFINE_SPINLOCK(xxx_lock); | |||
13 | The above is always safe. It will disable interrupts _locally_, but the | 13 | The above is always safe. It will disable interrupts _locally_, but the |
14 | spinlock itself will guarantee the global lock, so it will guarantee that | 14 | spinlock itself will guarantee the global lock, so it will guarantee that |
15 | there is only one thread-of-control within the region(s) protected by that | 15 | there is only one thread-of-control within the region(s) protected by that |
16 | lock. This works well even under UP. The above sequence under UP | 16 | lock. This works well even under UP also, so the code does _not_ need to |
17 | essentially is just the same as doing | 17 | worry about UP vs SMP issues: the spinlocks work correctly under both. |
18 | |||
19 | unsigned long flags; | ||
20 | |||
21 | save_flags(flags); cli(); | ||
22 | ... critical section ... | ||
23 | restore_flags(flags); | ||
24 | |||
25 | so the code does _not_ need to worry about UP vs SMP issues: the spinlocks | ||
26 | work correctly under both (and spinlocks are actually more efficient on | ||
27 | architectures that allow doing the "save_flags + cli" in one operation). | ||
28 | 18 | ||
29 | NOTE! Implications of spin_locks for memory are further described in: | 19 | NOTE! Implications of spin_locks for memory are further described in: |
30 | 20 | ||
@@ -36,27 +26,7 @@ The above is usually pretty simple (you usually need and want only one | |||
36 | spinlock for most things - using more than one spinlock can make things a | 26 | spinlock for most things - using more than one spinlock can make things a |
37 | lot more complex and even slower and is usually worth it only for | 27 | lot more complex and even slower and is usually worth it only for |
38 | sequences that you _know_ need to be split up: avoid it at all cost if you | 28 | sequences that you _know_ need to be split up: avoid it at all cost if you |
39 | aren't sure). HOWEVER, it _does_ mean that if you have some code that does | 29 | aren't sure). |
40 | |||
41 | cli(); | ||
42 | .. critical section .. | ||
43 | sti(); | ||
44 | |||
45 | and another sequence that does | ||
46 | |||
47 | spin_lock_irqsave(flags); | ||
48 | .. critical section .. | ||
49 | spin_unlock_irqrestore(flags); | ||
50 | |||
51 | then they are NOT mutually exclusive, and the critical regions can happen | ||
52 | at the same time on two different CPU's. That's fine per se, but the | ||
53 | critical regions had better be critical for different things (ie they | ||
54 | can't stomp on each other). | ||
55 | |||
56 | The above is a problem mainly if you end up mixing code - for example the | ||
57 | routines in ll_rw_block() tend to use cli/sti to protect the atomicity of | ||
58 | their actions, and if a driver uses spinlocks instead then you should | ||
59 | think about issues like the above. | ||
60 | 30 | ||
61 | This is really the only really hard part about spinlocks: once you start | 31 | This is really the only really hard part about spinlocks: once you start |
62 | using spinlocks they tend to expand to areas you might not have noticed | 32 | using spinlocks they tend to expand to areas you might not have noticed |
@@ -120,11 +90,10 @@ Lesson 3: spinlocks revisited. | |||
120 | 90 | ||
121 | The single spin-lock primitives above are by no means the only ones. They | 91 | The single spin-lock primitives above are by no means the only ones. They |
122 | are the most safe ones, and the ones that work under all circumstances, | 92 | are the most safe ones, and the ones that work under all circumstances, |
123 | but partly _because_ they are safe they are also fairly slow. They are | 93 | but partly _because_ they are safe they are also fairly slow. They are slower |
124 | much faster than a generic global cli/sti pair, but slower than they'd | 94 | than they'd need to be, because they do have to disable interrupts |
125 | need to be, because they do have to disable interrupts (which is just a | 95 | (which is just a single instruction on a x86, but it's an expensive one - |
126 | single instruction on a x86, but it's an expensive one - and on other | 96 | and on other architectures it can be worse). |
127 | architectures it can be worse). | ||
128 | 97 | ||
129 | If you have a case where you have to protect a data structure across | 98 | If you have a case where you have to protect a data structure across |
130 | several CPU's and you want to use spinlocks you can potentially use | 99 | several CPU's and you want to use spinlocks you can potentially use |