bsp; Working OK now, still has problems with seeky
OLTP-style loads.
PRI1
o CFQ scheduler. Seems to work but Jens planning significant rework.
PRI2
o cryptoloop: jmorris: There''''s no cryptoloop in the 2.4 mainline kernel,
but I think every distro ships some version. It would probably be useful
to have crypto natively supported in 2.6, with backward compatibility for
the majority of 2.4 users.
problem: lack of a loop maintainer
PRI2
o viro: paride drivers need a big cleanup
PRI2
drivers/char/rtc/
~~~~~~~~~~~~~~~~~
o rmk, trini: add support for alarms to the existing generic rtc driver.
PRI2
device mapper
~~~~~~~~~~~~~
o ioctl interface cleanup patch is ready (redo the structure layouts)
PRI1
o A port of the 2.4 snapshot target is in progress
PRI1
o the fs interface to dm needs to be redone. gregkh was going to work on
this. viro is interested in seeing work thus-far.
PRI2
drivers/net/wireless/
~~~~~~~~~~~~~~~~~~~~~
(Jean Tourrilhes <jt@bougret.hpl.hp.com>)
o get latest orinoco changes from David.
PRI1
o get the latest airo.c fixes from CVS. This will hopefully fix problems
people have reported on the LKML.
PRI1
o get HostAP driver in the kernel. No consolidation of the 802.11
management across driver can happen until this one is in (which is probably
2.7.X material). I think Jouni is mostly ready but didn''''t find time for
it.
PRI2
o get more wireless drivers into the kernel. The most "integrable" drivers
at this point seem the NWN driver, Pavel''''s Spectrum driver and the Atmel
driver.
PRI1
o The last two drivers mentioned above are held up by firmware issues (see
flamewar on LKML a few days ago). So maybe fixing those firmware issues
should be a requirement for 2.6.X, because we can expect more wireless
devices to need firmware upload at startup coming to market.
(in progress?)
PRI1
drivers/usb/gadget/
~~~~~~~~~~~~~~~~~~~
o rmk: SA11xx USB client/gadget code (David B has been doing some work on
this, and keeps trying to prod me, but unfortunately I haven''''t had the time
to look at his work, sorry David.)
PRI3
fs/
~~~
o ext3 lock_kernel() removal: that part works OK and is mergeable. But
we''''ll also need to make lock_journal() a spinlock, and that''''s deep surgery.
Patches exist in -mm.
PRI1
o ext3 and ext2 block allocators have serious failure modes - interleaved
allocations.
PRI3
o 32bit quota needs a lot more testing but may work now
PRI2
o Integrate Chris Mason''''s 2.4 reiserfs ordered data and data journaling
patches. They make reiserfs a lot safer.
Ordered: PRI2
data journalled: PRI3
o (Trond:) Yes: I''''m still working on an atomic "open()", i.e. one
where we short-circuit the usual VFS path_walk() + lookup() +
permission() + create() + .... bullsh*t...
I have several reasons for wanting to do this (all of
them related to NFS of course, but much of the reasoning applies
to *all* networked file systems).
1) The above sequence is simply not atomic on *any* networked
filesystem.
2) It introduces a sh*tload of completely unnecessary RPC calls (why
do a ''''permission'''' RPC call when the server is in *any* case going to
tell you whether or not this operations is allowed. Why do a
''''lookup()'''' when the ''''create()'''' call can be made to tell you whether or
not a file already exists).
3) It is incompatible with some operations: the current create()
doesn''''t pass an ''''EXCLUSIVE'''' flag down to the filesystems.
4) (NFS specific?) open() has very different cache consistency
requirements when compared to most other VFS operations.
I''''d very much like for something like Peter Braam''''s ''''lookup with
intent'''' or (better yet) for a proper dentry->open() to be integrated with
path_walk()/open_namei(). I''''m still working on the latter (Peter has
already completed the lookup with intent stuff).
PRI2 (?)
o (Chuck Lever <cel@citi.umich.edu>): NFS O_DIRECT support must be
completed. The best approach is to fall back to something like the 2.4 NFS
O_DIRECT support, which issues RPCs synchronously and uses the RPC
completion mechanism to wait for I/O completion.
PRI2
o rmk: update acorn partition parsing code - making all acorn schemes
appear in check.c so we don''''t have to duplicate the scanning of multiple
types, and adding support for eesox partitions.
PRI2
o atomic i_size patches
PRI1
o viro: cleaning up options-parsers in filesystems. (patch exists, needs
porting).
PRI2
o aio: fs IO isn''''t async at present. suparna has restart patches, they''''re
in -mm. Need to get Ben to review/comment.
PRI1.
kernel/
~~~~~~~
o rusty: Zippel''''s Reference count simplification. Tricky code, but cuts
about 120 lines from module.c. Patch exists, needs stressing.
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.
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 pac 上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] 下一页 | 
