Ask a kernel developer, part 2

One in a series of columns in which questions are asked of a kernel developer and he tries to answer them. If you have unanswered questions relating to technical or procedural things around Linux kernel development, ask them in the comment section, or email them directly to the author.

How do I open an effective communication channel with a kernel developer to get my issues fixed?

Despite the size of most kernel subsystem maintainer's inbox, this is a question that comes up a lot in conversations with users, so it is good to get it out there.

The easiest way to communicate with a kernel developer about a problem is to write an email and send it to the subsystem list that handles the area in which you are having problems, and to copy the developers as well to make sure that they see the message.

Ah, but how do you figure out what subsystem or mailing list to use? Luckily the kernel contains a list of the mailing lists and the developers responsible for the different kernel subsystems. The file, MAINTAINERS in the Linux kernel source tree, lists all of the different subsystems, the name of the maintainer, the email address, and the mailing list that is the best place to bring up things on. If there is no mailing list specified, then use the default linux-kernel mailing list address.

If you narrow the problem down to a file that you are having questions about, the script scripts/get_maintainer.pl in the kernel source tree can find the proper people responsible for changing it last, as well as any maintainer and mailing lists automatically. For example, suppose you have a problem with the ftdi_sio driver, which is located in drivers/usb/serial/ftdio_sio.c. By running the get_maintainer.pl script with the -f option, you would get the following:

    $ scripts/get_maintainer.pl -f drivers/usb/serial/ftdi_sio.c
    Greg Kroah-Hartman <gregkh@suse.de>
    Alan Cox <alan@linux.intel.com>
    linux-usb@vger.kernel.org
    linux-kernel@vger.kernel.org

Make sure you always send a copy to a development mailing list, do not just email kernel developers privately, as their email load is quite high. By emailing the mailing list, you offer up the ability for anyone to help you out with your question - taking advantage of the large development community - and you avoid overloading the individual maintainers any more than they are already overloaded.

What happens if I get no response from my email?

Be persistent. If you do not hear back within a week, send a friendly "did you miss this email?" type response.

In the BSD world, there is a "security officer." Why is there no "security officer" for the Linux kernel?"

It is true there is no one person responsible for security for the Linux kernel, it is a group of developers who have taken this role on. The email address security@kernel.org goes directly to this group of developers who will quickly respond to any reported problems.

Instructions on how to contact this list, and the rules around which they operate concerning disclosure and amount of time before publicly fixing the problem, can be found in the Linux kernel file Documentation/SecurityBugs. If anyone has any questions about these rules, feel free to contact the security team for clarification.

Do you look at the code of the BSDs in order to find new ideas and concepts, or do you ignore them completely?

This is a personal decision on where to find ideas to implement in Linux. As far as I am concerned, I have not looked at the BSDs in many many years, as I have been busy with lots of Linux-only things (driver model, USB, Linux Driver Project, etc.) But other kernel developers do work with the BSD developers on coming up with solutions to different problems, or to get proper hardware support for types of devices.

Back in the early days of USB support in Linux, I did work with a number of the BSD USB kernel developers to share how specific devices operated so that drivers could be written for both operating systems, and overall, the developers are quite friendly toward each other, as we are working toward solving the same types of problems, but usually in different ways.

---

(Log in to post comments)