+ PRI3 + o rusty: /proc/kallsyms. What most people really wanted from /proc/ksyms. Patch exists.
+ PRI3 + o rusty: Fix module-failed-init races by starting module "disabled". Patch exists, requires some subsystems (ie. add_partition) to explicitly say "make module live now". Without patch we are no worse off than 2.4 etc.
+ PRI1 + o Integrate userspace irq balancing daemon.
-o kexec. Seems to work, is in -mm. + PRI2 + +o kexec. Seems to work, was in -mm. + + PRI3
o rmk: modules / /proc/kcore / vmalloc This needs sorting and testing to ensure that stuff like gdb vmlinux /proc/kcore works as expected. I believe this is the only show stopper preventing any ARM platform being built in Linus'''' kernel.
+ Patch exists in -mm, nobody has tested it for the above afaik. + + PRI1 + o kcore is a problem for ia64 (Tony Luck)
+ Patch exists in -mm. + + PRI1 + o rmk: lib/inflate.c must not use static variables (causes these to be referenced via GOTOFF relocations in PIC decompressor. We have a PIC decompressor to avoid having to hard code a per platform zImage link address into the makefiles.)
+ PRI2 + o klibc merge?
+ PRI2 + mm/ ~~~
o objrmap: concerns over page reclaim performance at high sharing levels, and interoperation with nonlinear mappings is hairy.
o Reintroduce and make /proc/sys/vm/freepages writable again so that boxes can be tuned for heavy interrupt load.
+ Patch exists in -mm. + + PRI1 + o oxymoron''''s async write-error-handling patch
+ PRI1 + +o dropbehind for large files + + PRI2 + net/ ~~~~
(davem)
o Real serious use of IPSEC is hampered by lack of MPLS support. MPLS is a switching technology that works by switching based upon fixed length labels prepended to packets. Many people use this and IPSEC to implement VPNs over public networks, it is also used for things like traffic engineering.
A good reference site is:
http://www.mplsrc.com/
Anyways, an existing (crappy) implementation exists. I''''ve almost completed a rewrite, I should have something in the tree next week.
+ PRI1 + o Sometimes we generate IP fragments when it truly isn''''t necessary.
The way IP fragmentation is specified, each fragment must be modulo 8 bytes in length. So suppose the device has an MTU that is not 0 modulo 8, ethernet even classifies in this way. 1500 == (8 * 187) + 4
Our IP fragmenting engine can fragment on packets that are sized within the last modulo 8 bytes of the MTU. This happens in obscure cases, but it does happen.
I''''ve proposed a fix to Alexey, whereby very late in the output path we check the packet, if we fragmented but the data length would fit into the MTU we unfragment the packet.
This is low priority, because technically it creates suboptimal behavior rather than mis-operation.
+ PRI1 + net/*/netfilter/ ~~~~~~~~~~~~~~~~
o Lots of misc. cleanups, which are happening slowly.
+ PRI2 + o davem: Netfilter needs to stop linearizing packets as much as possible.
Zerocopy output packets are basically undone by netfilter becuase all of it assumed it was working with linear socket buffers.
Rusty is fixing this piece by piece. He is nearly done with this work.
+ PRI1 + power management ~~~~~~~~~~~~~~~~
(Pat) There is some preliminary work at bk://ldm.bkbits.net/linux-2.5-power, though I''''m currently in the process of reworking it.
It includes:
o New device power management core code, both for individual devices, and for global state transitions.
+ PRI1 + o A generic user interface for triggering system power state transitions.
+ PRI1 + o Arch-independent code for performing state transitions, that calls platform-specific methods along the way.
+ PRI1 + o A better suspend-to-disk mechanism than swsusp.
There are various other details to be worked out, which are the real fun part. And of course, driver support, but that is something that can happen at any time.
(Alan)
+ PRI2 + o Frame buffer restore codepaths (that requires some deep PCI magic)
+ PRI2 + o XFree86 hooks
+ PRI2 + o AGP restoration
+ PRI2 + o DRI restoration
(davej/Alan: not super-critical, can crash laptop on restore. davej looking into it.)
+ PRI2 + o IDE suspend/resume without races (Ben is looking at this a little)
+ PRI2 + o Pat: There are already CPU device structures; MTRRs should be a dynamically registered interface of CPUs, which implies there needs to be some other glue to know that there are MTRRs that need to be saved/restored.
+ PRI1 + global ~~~~~~
o 64-bit dev_t. Seems almost ready, but it''''s not really known how much work is still to do. Patches exist in -mm but with the recent rise of the neo-viro I''''m not sure where things are at.
+ PRI1 + o We need a kernel side API for reporting error events to userspace (could be async to 2.6 itself)
(Prototype core based on netlink exists)
+ PRI2 + o Kai: Introduce a sane, easy and standard way to build external modules
+ PRI2 + o Kai: Allow separate src/objdir
+ PRI2 + o general confusion over firmware policy:
o do we mandate that it be uploaded from userspace?
o Is binary-blob-in-kernel-image OK?
o Each driver (wireless, scsi, etc) seems to do it in a different, private manner.
gregkh: patch exists, drivers can be ported to use new infrastructure at any time.
+ PRI1 + o larger cpumask_t - supporting more than BITS_PER_LONG CPUs.
wli: patch exists. ia32, ppc are done. ppc64 in progress. Needs work for other architectures.
+ PRI1 + +o pavel: ioctl32 emulation should be shared across architectures. (patch + exists). + + PRI2 + drivers ~~~~~~~
-o Some network drivers don''''t even build - o Alan: Cardbus/PCMCIA requires all Russell''''s stuff is merged to do multiheader right and so on
+ PRI1 + drivers/acpi/ ~~~~~~~~~~~~~
-o davej: ACPI has a number of failures right now. There are a number of - entries in bugzilla which could all be the same bug. It manifests as a - "network card doesn''''t recieve packets" booting with ''''acpi=off noapic'''' fixes - it. - - alan: VIA APIC stuff is one bit of this, there are also some other +o alan: VIA APIC stuff is one bit of this, there are also some other reports that were caused by ACPI not setting level v edge trigger some times
-o davej: There''''s also another nasty ''''doesnt boot'''' bug which quite a few - people (myself included) are seeing on some boxes (especially laptops). + PRI1
o mochel: it seems the acpi irq routing code could use a serious rewrite.
+ grover: The problem is the ACPI irq routing code is trying to piggyback + on the existing MPS-specific data structures, and it''''s generally a hack. + So yes mochel is right, but it is also purging MPS-ities from common code + as well. I''''ve done some preliminary work in this area and it doesn''''t seem + to break anything (yet) but a rewrite in this area imho should not be + rushed out the door. And, I think the above bugs can be fixed w/o the + rewrite. + + PRI2 + o mochel: ACPI suspend doesn''''t work. Important, not cricital. Pat is working it.
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
