Here is another in our series of articles with questions posed to a kernel
developer. If you have
about technical or procedural things involving Linux kernel
development, ask them in the comment section, or email them directly to
the author. This time, we look at UEFI booting, real-time kernels, driver
configuration, and building kernels.
I’d like to follow a mailing list on UEFI-booting-related topics but don’t
seem to find any specific subsystem in the MAINTAINERS file, would you please
share some pointers?
Because of the wide range of topics involved in UEFI booting, there is
no "one specific" mailing list where you can track just the UEFI issues.
I recommend filtering the fast-moving linux-kernel mailing list, as
most of the topics that kernel developers discuss cross that list.
As the kernel isn't directly involved in UEFI, there is no one specific
"maintainer" of this area at the moment. That being said, there are
lots of different people working on this task right now.
From the kernel side itself, there has been some wonderful work from
Matt Flemming and other Intel developers, in making it so that the
kernel can be built as an image that is bootable from EFI directly. There were some recent
patches that went into the 3.6-rc1 kernel that have made it
easier for bootloaders to load the kernel in EFI mode. See the patch
for the details about how this is done, but note that some bootloader
work is also needed to take advantage of this.
From the "secure boot" UEFI mode side, James Bottomley, chair of the
Technical Advisory Board of the Linux Foundation (and kernel SCSI
subsystem maintainer), has been working through a lot of the "how do you
get a distribution to boot in secure mode" effort and documenting it all for
all distributions to use. He's published his results,
with code; I also recommend reading his previous blog posts about this topic for
more information about the subject and how it pertains to Linux.
As for distribution-specific work, both Canonical and Red Hat have been
working with the UEFI Forum to help make Linux work properly on
UEFI-enabled machines. I recommend asking those companies about how they
plan to handle this issue, on their respective mailing lists, if you are
interested in finding out what they are planning to do. Other distributions
are aware of the issue, but as of this point in time, I do not believe
they are working with the UEFI Forum.
I am evaluating Linux for use as an operating system in a real-time embedded
application, however, I find it hard to find recent data with respect
to the real-time performance of Linux.
Do you have, or know of someone who has, information on the real-time
performance of the Linux kernel, preferably under various load
I get this type of question a lot, in various forms. The
very simple answer is: "No, there is no data, you should evaluate it
yourself on your hardware platform, with your system loads, to determine
if it meets your requirements." And in reality, that's what you should
be doing in the first place even if there were "numbers" published
anywhere. Don't trust a vendor, or a project, to know exactly how you
are going to be using the operating system. Only you know best, so only
you know how to determine if it solves your problem or not.
So, go forth, download the code, run it, and see if it works. It's
really that simple.
Note, if it doesn't work for you, let the developers know about it. If
they don't know about any problems, then they can't fix them.
What is the best way to get configuration data into a driver? (This is
paraphrased from many different questions all asking almost the same
In the past (i.e. 10+ years ago), lots of developers used module
parameters in order to pass configuration options into a driver to
control a device. That started to break down very quickly when multiple
devices of the same type were in the same system, as there isn't a
simple way to use module parameters for this.
When the sysfs filesystem was created, lots of developers started using
it to help configure devices, as the individual devices controlled by a
single driver are much easier to see and write values to. This works
today, for simple sets of configuration options (such as calibrating an
input device). But, for more complex types of configurations, the best
thing to use is configfs (kernel
documentation, LWN article), which was written specifically for this task.
It handles ways to tie configurations to sysfs devices easily, and
handles notifying drivers when things have been changed by the user. At
this point in time, I strongly recommend using that interface for any
reasonably complex configuration task that a driver or subsystem might
What is a good, fast and reliable way to compile a custom kernel
for a system? In the past, people have used lspci,
lsusb, and others, combined with the old autokernelconf
tool, but that can be difficult, is there a better way?
As Linus pointed out a few weeks ago,
configuring a kernel is getting more and
more complex, with different options being needed by different distributions.
The simplest way I have found to get a custom kernel up and running on a
machine is to take a distribution-built kernel that you know works, and then
use the "make localmodconfig" build option.
To use this option, first boot the distribution kernel, and plug in any
devices that you expect to use on the system, which will load the kernel
drivers for them. Then go into your kernel source directory, and run "make localmodconfig". That option will dig through your system and find the
kernel configuration for the running kernel (which is
usually at /proc/config.gz, but can sometimes be located in the boot
partition, depending on the distribution). Then, the script will remove
all options for kernel modules that are not currently loaded, stripping
down the number of drivers that will be built significantly. The
resulting configuration file will be written to the .config file, and
then you can build the kernel and install it as normal. The time to
build this stripped-down kernel should be very short, compared to the
full configuration that the distribution provides.
to post comments)