Specifications

16 | august 2008 www.linuxjournal.com
UPFRONT
NEWS + FUN
Having to reboot
production systems
to incorporate
security patches is
a pain. How much
better would it be
simply to graft the
patch onto an already running kernel,
and let it keep running? This is exactly
what Jeff Arnold has been working on.
He calls it KSplice, and at least for the
moment, it supports any kernel that can
load a module. The kernel itself doesn’t
have to support the feature explicitly.
The way it works is that the user sup-
plies the source tree for the running
kernel and the patch to graft on. Then,
KSplice compiles the patch and loads
modules that apply the patch internally.
Because of the interest it has generated,
it’s looking very likely that KSplice will be
accepted into the kernel tree, at which
point it might stop supporting kernels
that don’t know about it.
One obstacle standing in the way of
Jeff’s work is Microsoft’s legal depart-
ment. During the course of discussion,
it came out that patent application
10/307,902 from 2002 seemed to cover
Jeff’s idea. And, although a number of
folks, including Gilles Espinasse and
Willy Tarreau, said they’d been “hot-
patching” operating systems since the
1990s and earlier, Bill Davidsen felt
that trying to launch a challenge against
a Microsoft patent would be prohibitive-
ly expensive. However, according to Jeff,
the patent application was rejected by
the patent office. So, Microsoft may
give up at this point, depending on its
current internal weirdness level.
NFS is a lovely filesystem, but it has
various problems that make people want
to replace it. One of the latest attempts
is POHMELFS, or Parallel Optimized
Host Message Exchange Layered File
System. POHMELFS is written by
Evgeniy Polyakov, and it is a user-
space layer that can be applied to any
back-end filesystem, such as ReiserFS or
XFS. It also seems to outperform NFS
fairly significantly, at least according to
the tests Evgeniy has performed so far.
But, it’s still only ready for playing
around with. People shouldn’t use it to
store data they want to keep. Evgeniy
says it’s too soon to talk about the
filesystem being reliable for use. He’s
been able to do regular user activity on
it without a problem, but he expects to
find bugs, POSIX conformance issues
and other issues.
ReiserFS has migrated its develop-
ment from the NameSys servers to
kernel.org, where work is continuing.
Edward Shishkin and others continue
to develop the filesystem in spite of
Hans Reiser’s murder conviction.
There have been various other main-
tainer updates. Greg Kroah-Hartman is
no longer the PCI maintainer; he’s handed
the whole kit and kaboodle off to Jesse
Barnes. Timur Tabi has listed himself
as the official maintainer of the Cirrus
Logic CS4270 sound driver, the
Freescale QUICC engine library, the
QUICC engine UCC UART driver and
the Freescale SOC sound drivers. And,
Zhang Wei has abdicated maintainer-
ship of the Freescale DMA driver and
handed that project over to Li Yang.
The politics of competing filesystems
is never pretty. LogFS wants to support
Flash drives, but its development has
been slower than some people would
like. So, Artem Bityutskiy and Adrian
Hunter recently announced their own
alternative, UBIFS, that is apparently
quite a bit further along than LogFS. It’s
faster, more stable and more featureful,
although it still has trouble with devices
larger than 64G. LogFS, developed by
Jorn Engel, also came out with a new
release, perhaps partly in response to
the UBIFS announcement. Of course,
nothing says there can’t be two co-
existing Flash filesystems, but apparently
one of the motivations for UBIFS was
the relatively slow pace of LogFS
development. Artem in particular
seemed bitter about this, especially
since it appeared that various folks
were suggesting waiting for LogFS
instead of developing UBIFS, while
UBIFS was already superior to LogFS.
Matthew Wilcox and others are
trying to eliminate as many semaphores
as they can from the kernel, and replace
them with simpler locking structures,
such as mutexes, spinlocks and comple-
tions. The problem is that semaphores
provide additional features that are hard
to mimic with those other types of locks.
For example, semaphores can manage
access to a cluster of resources, while
other locks basically are just on/off
switches. The benefit of eliminating
semaphores is that it’s possible to gain
speed and, in the case of single-proces-
sor systems, to optimize the lock entirely
out of the compiled binary, resulting in
further speed gains. But to do this, key
features of semaphores have to be mim-
icked near any lock that replaces one.
Matthew, Arjan van de Ven and Ingo
Molnar are addressing this by develop-
ing kcounter, which will provide ways of
managing access to clusters of resources,
similar to how semaphores do it.
Unfortunately, kcounter takes a cookie-
based approach, similar to other things
that have been seen in the kernel before,
which have resulted in what David
Chinner characterized as a very ugly inter-
face. Hopefully, kcounter will avoid that
pitfall, although it does seem as though a
significant speedup might justify a little
cookie ugliness. That question undoubt-
edly will spawn some lively debate.
—ZACK BROWN
WHAT’S NEW
IN KERNEL
DEVELOPMENT
diff -u