You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'x86/urgent' into x86/pat
Reason: Change to is_new_memtype_allowed() in x86/urgent Resolved semantic conflicts in: arch/x86/mm/pat.c arch/x86/mm/ioremap.c Signed-off-by: H. Peter Anvin <hpa@zytor.com>
This commit is contained in:
H. Peter Anvin
@@ -27,6 +27,7 @@
|
||||
*.gz
|
||||
*.lzma
|
||||
*.patch
|
||||
*.gcno
|
||||
|
||||
#
|
||||
# Top-level generic files
|
||||
|
||||
@@ -1856,7 +1856,7 @@ E: rfkoenig@immd4.informatik.uni-erlangen.de
|
||||
D: The Linux Support Team Erlangen
|
||||
|
||||
N: Andreas Koensgen
|
||||
E: ajk@iehk.rwth-aachen.de
|
||||
E: ajk@comnets.uni-bremen.de
|
||||
D: 6pack driver for AX.25
|
||||
|
||||
N: Harald Koerfgen
|
||||
@@ -2006,6 +2006,9 @@ E: paul@laufernet.com
|
||||
D: Soundblaster driver fixes, ISAPnP quirk
|
||||
S: California, USA
|
||||
|
||||
N: Jonathan Layes
|
||||
D: ARPD support
|
||||
|
||||
N: Tom Lees
|
||||
E: tom@lpsg.demon.co.uk
|
||||
W: http://www.lpsg.demon.co.uk/
|
||||
@@ -3802,6 +3805,9 @@ S: van Bronckhorststraat 12
|
||||
S: 2612 XV Delft
|
||||
S: The Netherlands
|
||||
|
||||
N: Thomas Woller
|
||||
D: CS461x Cirrus Logic sound driver
|
||||
|
||||
N: David Woodhouse
|
||||
E: dwmw2@infradead.org
|
||||
D: JFFS2 file system, Memory Technology Device subsystem,
|
||||
|
||||
@@ -94,28 +94,37 @@ What: /sys/block/<disk>/queue/physical_block_size
|
||||
Date: May 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
This is the smallest unit the storage device can write
|
||||
without resorting to read-modify-write operation. It is
|
||||
usually the same as the logical block size but may be
|
||||
bigger. One example is SATA drives with 4KB sectors
|
||||
that expose a 512-byte logical block size to the
|
||||
operating system.
|
||||
This is the smallest unit a physical storage device can
|
||||
write atomically. It is usually the same as the logical
|
||||
block size but may be bigger. One example is SATA
|
||||
drives with 4KB sectors that expose a 512-byte logical
|
||||
block size to the operating system. For stacked block
|
||||
devices the physical_block_size variable contains the
|
||||
maximum physical_block_size of the component devices.
|
||||
|
||||
What: /sys/block/<disk>/queue/minimum_io_size
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Storage devices may report a preferred minimum I/O size,
|
||||
which is the smallest request the device can perform
|
||||
without incurring a read-modify-write penalty. For disk
|
||||
drives this is often the physical block size. For RAID
|
||||
arrays it is often the stripe chunk size.
|
||||
Storage devices may report a granularity or preferred
|
||||
minimum I/O size which is the smallest request the
|
||||
device can perform without incurring a performance
|
||||
penalty. For disk drives this is often the physical
|
||||
block size. For RAID arrays it is often the stripe
|
||||
chunk size. A properly aligned multiple of
|
||||
minimum_io_size is the preferred request size for
|
||||
workloads where a high number of I/O operations is
|
||||
desired.
|
||||
|
||||
What: /sys/block/<disk>/queue/optimal_io_size
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Storage devices may report an optimal I/O size, which is
|
||||
the device's preferred unit of receiving I/O. This is
|
||||
rarely reported for disk drives. For RAID devices it is
|
||||
usually the stripe width or the internal block size.
|
||||
the device's preferred unit for sustained I/O. This is
|
||||
rarely reported for disk drives. For RAID arrays it is
|
||||
usually the stripe width or the internal track size. A
|
||||
properly aligned multiple of optimal_io_size is the
|
||||
preferred request size for workloads where sustained
|
||||
throughput is desired. If no optimal I/O size is
|
||||
reported this file contains 0.
|
||||
|
||||
@@ -449,8 +449,8 @@ printk(KERN_INFO "i = %u\n", i);
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
__u32 ipaddress;
|
||||
printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
|
||||
__be32 ipaddress;
|
||||
printk(KERN_INFO "my ip: %pI4\n", &ipaddress);
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
|
||||
@@ -184,8 +184,6 @@ usage should require reading the full document.
|
||||
!Finclude/net/mac80211.h ieee80211_ctstoself_get
|
||||
!Finclude/net/mac80211.h ieee80211_ctstoself_duration
|
||||
!Finclude/net/mac80211.h ieee80211_generic_frame_duration
|
||||
!Finclude/net/mac80211.h ieee80211_get_hdrlen_from_skb
|
||||
!Finclude/net/mac80211.h ieee80211_hdrlen
|
||||
!Finclude/net/mac80211.h ieee80211_wake_queue
|
||||
!Finclude/net/mac80211.h ieee80211_stop_queue
|
||||
!Finclude/net/mac80211.h ieee80211_wake_queues
|
||||
|
||||
@@ -83,11 +83,12 @@ not detect it missed following items in original chain.
|
||||
obj = kmem_cache_alloc(...);
|
||||
lock_chain(); // typically a spin_lock()
|
||||
obj->key = key;
|
||||
atomic_inc(&obj->refcnt);
|
||||
/*
|
||||
* we need to make sure obj->key is updated before obj->next
|
||||
* or obj->refcnt
|
||||
*/
|
||||
smp_wmb();
|
||||
atomic_set(&obj->refcnt, 1);
|
||||
hlist_add_head_rcu(&obj->obj_node, list);
|
||||
unlock_chain(); // typically a spin_unlock()
|
||||
|
||||
@@ -159,6 +160,10 @@ out:
|
||||
obj = kmem_cache_alloc(cachep);
|
||||
lock_chain(); // typically a spin_lock()
|
||||
obj->key = key;
|
||||
/*
|
||||
* changes to obj->key must be visible before refcnt one
|
||||
*/
|
||||
smp_wmb();
|
||||
atomic_set(&obj->refcnt, 1);
|
||||
/*
|
||||
* insert obj in RCU way (readers might be traversing chain)
|
||||
|
||||
@@ -21,6 +21,8 @@ ffff8000 ffffffff copy_user_page / clear_user_page use.
|
||||
For SA11xx and Xscale, this is used to
|
||||
setup a minicache mapping.
|
||||
|
||||
ffff4000 ffffffff cache aliasing on ARMv6 and later CPUs.
|
||||
|
||||
ffff1000 ffff7fff Reserved.
|
||||
Platforms must not use this address range.
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
/*
|
||||
* cn_test.c
|
||||
*
|
||||
* 2004-2005 Copyright (c) Evgeniy Polyakov <johnpol@2ka.mipt.ru>
|
||||
* 2004+ Copyright (c) Evgeniy Polyakov <zbr@ioremap.net>
|
||||
* All rights reserved.
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
@@ -194,5 +194,5 @@ module_init(cn_test_init);
|
||||
module_exit(cn_test_fini);
|
||||
|
||||
MODULE_LICENSE("GPL");
|
||||
MODULE_AUTHOR("Evgeniy Polyakov <johnpol@2ka.mipt.ru>");
|
||||
MODULE_AUTHOR("Evgeniy Polyakov <zbr@ioremap.net>");
|
||||
MODULE_DESCRIPTION("Connector's test module");
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
/*
|
||||
* ucon.c
|
||||
*
|
||||
* Copyright (c) 2004+ Evgeniy Polyakov <johnpol@2ka.mipt.ru>
|
||||
* Copyright (c) 2004+ Evgeniy Polyakov <zbr@ioremap.net>
|
||||
*
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
|
||||
@@ -207,8 +207,8 @@ Attributes
|
||||
~~~~~~~~~~
|
||||
struct driver_attribute {
|
||||
struct attribute attr;
|
||||
ssize_t (*show)(struct device_driver *, char * buf, size_t count, loff_t off);
|
||||
ssize_t (*store)(struct device_driver *, const char * buf, size_t count, loff_t off);
|
||||
ssize_t (*show)(struct device_driver *driver, char *buf);
|
||||
ssize_t (*store)(struct device_driver *, const char * buf, size_t count);
|
||||
};
|
||||
|
||||
Device drivers can export attributes via their sysfs directories.
|
||||
|
||||
@@ -25,7 +25,7 @@ use IO::Handle;
|
||||
"tda10046lifeview", "av7110", "dec2000t", "dec2540t",
|
||||
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
|
||||
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
|
||||
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2" );
|
||||
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718" );
|
||||
|
||||
# Check args
|
||||
syntax() if (scalar(@ARGV) != 1);
|
||||
@@ -381,6 +381,57 @@ sub cx18 {
|
||||
$allfiles;
|
||||
}
|
||||
|
||||
sub mpc718 {
|
||||
my $archive = 'Yuan MPC718 TV Tuner Card 2.13.10.1016.zip';
|
||||
my $url = "ftp://ftp.work.acer-euro.com/desktop/aspire_idea510/vista/Drivers/$archive";
|
||||
my $fwfile = "dvb-cx18-mpc718-mt352.fw";
|
||||
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
|
||||
|
||||
checkstandard();
|
||||
wgetfile($archive, $url);
|
||||
unzip($archive, $tmpdir);
|
||||
|
||||
my $sourcefile = "$tmpdir/Yuan MPC718 TV Tuner Card 2.13.10.1016/mpc718_32bit/yuanrap.sys";
|
||||
my $found = 0;
|
||||
|
||||
open IN, '<', $sourcefile or die "Couldn't open $sourcefile to extract $fwfile data\n";
|
||||
binmode IN;
|
||||
open OUT, '>', $fwfile;
|
||||
binmode OUT;
|
||||
{
|
||||
# Block scope because we change the line terminator variable $/
|
||||
my $prevlen = 0;
|
||||
my $currlen;
|
||||
|
||||
# Buried in the data segment are 3 runs of almost identical
|
||||
# register-value pairs that end in 0x5d 0x01 which is a "TUNER GO"
|
||||
# command for the MT352.
|
||||
# Pull out the middle run (because it's easy) of register-value
|
||||
# pairs to make the "firmware" file.
|
||||
|
||||
local $/ = "\x5d\x01"; # MT352 "TUNER GO"
|
||||
|
||||
while (<IN>) {
|
||||
$currlen = length($_);
|
||||
if ($prevlen == $currlen && $currlen <= 64) {
|
||||
chop; chop; # Get rid of "TUNER GO"
|
||||
s/^\0\0//; # get rid of leading 00 00 if it's there
|
||||
printf OUT "$_";
|
||||
$found = 1;
|
||||
last;
|
||||
}
|
||||
$prevlen = $currlen;
|
||||
}
|
||||
}
|
||||
close OUT;
|
||||
close IN;
|
||||
if (!$found) {
|
||||
unlink $fwfile;
|
||||
die "Couldn't find valid register-value sequence in $sourcefile for $fwfile\n";
|
||||
}
|
||||
$fwfile;
|
||||
}
|
||||
|
||||
sub cx23885 {
|
||||
my $url = "http://linuxtv.org/downloads/firmware/";
|
||||
|
||||
|
||||
@@ -458,3 +458,13 @@ Why: Remove the old legacy 32bit machine check code. This has been
|
||||
but the old version has been kept around for easier testing. Note this
|
||||
doesn't impact the old P5 and WinChip machine check handlers.
|
||||
Who: Andi Kleen <andi@firstfloor.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be
|
||||
exported interface anymore.
|
||||
When: 2.6.33
|
||||
Why: cpu_policy_rwsem has a new cleaner definition making it local to
|
||||
cpufreq core and contained inside cpufreq.c. Other dependent
|
||||
drivers should not use it in order to safely avoid lockdep issues.
|
||||
Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
|
||||
|
||||
@@ -23,7 +23,8 @@ interface.
|
||||
Using sysfs
|
||||
~~~~~~~~~~~
|
||||
|
||||
sysfs is always compiled in. You can access it by doing:
|
||||
sysfs is always compiled in if CONFIG_SYSFS is defined. You can access
|
||||
it by doing:
|
||||
|
||||
mount -t sysfs sysfs /sys
|
||||
|
||||
|
||||
@@ -139,6 +139,7 @@ Code Seq# Include File Comments
|
||||
'm' all linux/synclink.h conflict!
|
||||
'm' 00-1F net/irda/irmod.h conflict!
|
||||
'n' 00-7F linux/ncp_fs.h
|
||||
'n' 80-8F linux/nilfs2_fs.h NILFS2
|
||||
'n' E0-FF video/matrox.h matroxfb
|
||||
'o' 00-1F fs/ocfs2/ocfs2_fs.h OCFS2
|
||||
'o' 00-03 include/mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
|
||||
|
||||
@@ -1115,6 +1115,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
libata.dma=4 Compact Flash DMA only
|
||||
Combinations also work, so libata.dma=3 enables DMA
|
||||
for disks and CDROMs, but not CFs.
|
||||
|
||||
libata.ignore_hpa= [LIBATA] Ignore HPA limit
|
||||
libata.ignore_hpa=0 keep BIOS limits (default)
|
||||
libata.ignore_hpa=1 ignore limits, using full disk
|
||||
|
||||
libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume
|
||||
when set.
|
||||
@@ -1720,8 +1724,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
oprofile.cpu_type= Force an oprofile cpu type
|
||||
This might be useful if you have an older oprofile
|
||||
userland or if you want common events.
|
||||
Format: { archperfmon }
|
||||
archperfmon: [X86] Force use of architectural
|
||||
Format: { arch_perfmon }
|
||||
arch_perfmon: [X86] Force use of architectural
|
||||
perfmon on Intel CPUs instead of the
|
||||
CPU specific event set.
|
||||
|
||||
|
||||
@@ -36,8 +36,6 @@ detailed description):
|
||||
- Bluetooth enable and disable
|
||||
- video output switching, expansion control
|
||||
- ThinkLight on and off
|
||||
- limited docking and undocking
|
||||
- UltraBay eject
|
||||
- CMOS/UCMS control
|
||||
- LED control
|
||||
- ACPI sounds
|
||||
@@ -729,131 +727,6 @@ cannot be read or if it is unknown, thinkpad-acpi will report it as "off".
|
||||
It is impossible to know if the status returned through sysfs is valid.
|
||||
|
||||
|
||||
Docking / undocking -- /proc/acpi/ibm/dock
|
||||
------------------------------------------
|
||||
|
||||
Docking and undocking (e.g. with the X4 UltraBase) requires some
|
||||
actions to be taken by the operating system to safely make or break
|
||||
the electrical connections with the dock.
|
||||
|
||||
The docking feature of this driver generates the following ACPI events:
|
||||
|
||||
ibm/dock GDCK 00000003 00000001 -- eject request
|
||||
ibm/dock GDCK 00000003 00000002 -- undocked
|
||||
ibm/dock GDCK 00000000 00000003 -- docked
|
||||
|
||||
NOTE: These events will only be generated if the laptop was docked
|
||||
when originally booted. This is due to the current lack of support for
|
||||
hot plugging of devices in the Linux ACPI framework. If the laptop was
|
||||
booted while not in the dock, the following message is shown in the
|
||||
logs:
|
||||
|
||||
Mar 17 01:42:34 aero kernel: thinkpad_acpi: dock device not present
|
||||
|
||||
In this case, no dock-related events are generated but the dock and
|
||||
undock commands described below still work. They can be executed
|
||||
manually or triggered by Fn key combinations (see the example acpid
|
||||
configuration files included in the driver tarball package available
|
||||
on the web site).
|
||||
|
||||
When the eject request button on the dock is pressed, the first event
|
||||
above is generated. The handler for this event should issue the
|
||||
following command:
|
||||
|
||||
echo undock > /proc/acpi/ibm/dock
|
||||
|
||||
After the LED on the dock goes off, it is safe to eject the laptop.
|
||||
Note: if you pressed this key by mistake, go ahead and eject the
|
||||
laptop, then dock it back in. Otherwise, the dock may not function as
|
||||
expected.
|
||||
|
||||
When the laptop is docked, the third event above is generated. The
|
||||
handler for this event should issue the following command to fully
|
||||
enable the dock:
|
||||
|
||||
echo dock > /proc/acpi/ibm/dock
|
||||
|
||||
The contents of the /proc/acpi/ibm/dock file shows the current status
|
||||
of the dock, as provided by the ACPI framework.
|
||||
|
||||
The docking support in this driver does not take care of enabling or
|
||||
disabling any other devices you may have attached to the dock. For
|
||||
example, a CD drive plugged into the UltraBase needs to be disabled or
|
||||
enabled separately. See the provided example acpid configuration files
|
||||
for how this can be accomplished.
|
||||
|
||||
There is no support yet for PCI devices that may be attached to a
|
||||
docking station, e.g. in the ThinkPad Dock II. The driver currently
|
||||
does not recognize, enable or disable such devices. This means that
|
||||
the only docking stations currently supported are the X-series
|
||||
UltraBase docks and "dumb" port replicators like the Mini Dock (the
|
||||
latter don't need any ACPI support, actually).
|
||||
|
||||
|
||||
UltraBay eject -- /proc/acpi/ibm/bay
|
||||
------------------------------------
|
||||
|
||||
Inserting or ejecting an UltraBay device requires some actions to be
|
||||
taken by the operating system to safely make or break the electrical
|
||||
connections with the device.
|
||||
|
||||
This feature generates the following ACPI events:
|
||||
|
||||
ibm/bay MSTR 00000003 00000000 -- eject request
|
||||
ibm/bay MSTR 00000001 00000000 -- eject lever inserted
|
||||
|
||||
NOTE: These events will only be generated if the UltraBay was present
|
||||
when the laptop was originally booted (on the X series, the UltraBay
|
||||
is in the dock, so it may not be present if the laptop was undocked).
|
||||
This is due to the current lack of support for hot plugging of devices
|
||||
in the Linux ACPI framework. If the laptop was booted without the
|
||||
UltraBay, the following message is shown in the logs:
|
||||
|
||||
Mar 17 01:42:34 aero kernel: thinkpad_acpi: bay device not present
|
||||
|
||||
In this case, no bay-related events are generated but the eject
|
||||
command described below still works. It can be executed manually or
|
||||
triggered by a hot key combination.
|
||||
|
||||
Sliding the eject lever generates the first event shown above. The
|
||||
handler for this event should take whatever actions are necessary to
|
||||
shut down the device in the UltraBay (e.g. call idectl), then issue
|
||||
the following command:
|
||||
|
||||
echo eject > /proc/acpi/ibm/bay
|
||||
|
||||
After the LED on the UltraBay goes off, it is safe to pull out the
|
||||
device.
|
||||
|
||||
When the eject lever is inserted, the second event above is
|
||||
generated. The handler for this event should take whatever actions are
|
||||
necessary to enable the UltraBay device (e.g. call idectl).
|
||||
|
||||
The contents of the /proc/acpi/ibm/bay file shows the current status
|
||||
of the UltraBay, as provided by the ACPI framework.
|
||||
|
||||
EXPERIMENTAL warm eject support on the 600e/x, A22p and A3x (To use
|
||||
this feature, you need to supply the experimental=1 parameter when
|
||||
loading the module):
|
||||
|
||||
These models do not have a button near the UltraBay device to request
|
||||
a hot eject but rather require the laptop to be put to sleep
|
||||
(suspend-to-ram) before the bay device is ejected or inserted).
|
||||
The sequence of steps to eject the device is as follows:
|
||||
|
||||
echo eject > /proc/acpi/ibm/bay
|
||||
put the ThinkPad to sleep
|
||||
remove the drive
|
||||
resume from sleep
|
||||
cat /proc/acpi/ibm/bay should show that the drive was removed
|
||||
|
||||
On the A3x, both the UltraBay 2000 and UltraBay Plus devices are
|
||||
supported. Use "eject2" instead of "eject" for the second bay.
|
||||
|
||||
Note: the UltraBay eject support on the 600e/x, A22p and A3x is
|
||||
EXPERIMENTAL and may not work as expected. USE WITH CAUTION!
|
||||
|
||||
|
||||
CMOS/UCMS control
|
||||
-----------------
|
||||
|
||||
|
||||
+483
-238
File diff suppressed because it is too large
Load Diff
@@ -30,9 +30,9 @@ State
|
||||
The validator tracks lock-class usage history into 4n + 1 separate state bits:
|
||||
|
||||
- 'ever held in STATE context'
|
||||
- 'ever head as readlock in STATE context'
|
||||
- 'ever head with STATE enabled'
|
||||
- 'ever head as readlock with STATE enabled'
|
||||
- 'ever held as readlock in STATE context'
|
||||
- 'ever held with STATE enabled'
|
||||
- 'ever held as readlock with STATE enabled'
|
||||
|
||||
Where STATE can be either one of (kernel/lockdep_states.h)
|
||||
- hardirq
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
This is the 6pack-mini-HOWTO, written by
|
||||
|
||||
Andreas Könsgen DG3KQ
|
||||
Internet: ajk@iehk.rwth-aachen.de
|
||||
Internet: ajk@comnets.uni-bremen.de
|
||||
AMPR-net: dg3kq@db0pra.ampr.org
|
||||
AX.25: dg3kq@db0ach.#nrw.deu.eu
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ The remaining CPU time will be used for user input and other tasks. Because
|
||||
realtime tasks have explicitly allocated the CPU time they need to perform
|
||||
their tasks, buffer underruns in the graphics or audio can be eliminated.
|
||||
|
||||
NOTE: the above example is not fully implemented as of yet (2.6.25). We still
|
||||
NOTE: the above example is not fully implemented yet. We still
|
||||
lack an EDF scheduler to make non-uniform periods usable.
|
||||
|
||||
|
||||
@@ -140,14 +140,15 @@ The other option is:
|
||||
|
||||
.o CONFIG_CGROUP_SCHED (aka "Basis for grouping tasks" = "Control groups")
|
||||
|
||||
This uses the /cgroup virtual file system and "/cgroup/<cgroup>/cpu.rt_runtime_us"
|
||||
to control the CPU time reserved for each control group instead.
|
||||
This uses the /cgroup virtual file system and
|
||||
"/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each
|
||||
control group instead.
|
||||
|
||||
For more information on working with control groups, you should read
|
||||
Documentation/cgroups/cgroups.txt as well.
|
||||
|
||||
Group settings are checked against the following limits in order to keep the configuration
|
||||
schedulable:
|
||||
Group settings are checked against the following limits in order to keep the
|
||||
configuration schedulable:
|
||||
|
||||
\Sum_{i} runtime_{i} / global_period <= global_runtime / global_period
|
||||
|
||||
@@ -189,7 +190,7 @@ Implementing SCHED_EDF might take a while to complete. Priority Inheritance is
|
||||
the biggest challenge as the current linux PI infrastructure is geared towards
|
||||
the limited static priority levels 0-99. With deadline scheduling you need to
|
||||
do deadline inheritance (since priority is inversely proportional to the
|
||||
deadline delta (deadline - now).
|
||||
deadline delta (deadline - now)).
|
||||
|
||||
This means the whole PI machinery will have to be reworked - and that is one of
|
||||
the most complex pieces of code we have.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user