how to submit patches to i8k kernel driver

[Paul Sladen]

On Tue, 3 Jan 2006, Toby Murray wrote:
> I've got a patch for the i8k kernel driver that adds support for extra
> sensors found on many Dell laptops [...] My question is how to go about
> getting this into [..] the mainline kernel,

The best route to getting the patch is going to be to follow the sequence
people that got the previous patch signed-off and included upstream.  Each
of those developers already has a (hopefully) working relationship with the
next person up the chain.  For example Ubuntu->Debian->upstream->-mm->Linux.

> I have tried contacting the i8kutils maintainer, but have had no
> response yet.

If one of those people in the chain doesn't reply, try again and then try
skipping a level and contacting the person above, informing them that you
didn't have a response from the person below them in chain.

> patch adds support for the new sensors [..] in the output for /proc/i8k.

According to:

  http://people.debian.org/~dz/i8k/00-README

the format of '/proc/i8k' already has a version field at the start:
   vvvvv
    1.0 A17 2J59L02 52 2 1 8040 6420 1 2
    |   +-------------------------------------- 2.  [...]
    +------------------------------------------ 1.  /proc/i8k format version

...the best approach would probably be to bump the version number to '1.1'
and add the extra fields you require on the end.  It's a pity that the
author didn't use a "name: value" syntax already commonplace for /proc, as
this would be much more useful to 'grep from scripts and allow appending of
additional fields more safely.

> To keep the driver backwards compatible, the user must request the extra
> info by using a new ioctl

IMHO, it would be better to keep this logic out of kernel!  Patching the
userspace code is much safer and the various utilities can simply check for
which version-number of data the driver is outputting in '/proc/i8k'.  Since
you'd have to patch all the applications to send the 'ioctl' you might
aswell patch them to eat the extra data.

By moving the detection/switching logic to userspace, you keep (potentially
buggy) code out of the kernel.  In addition, ioctl() commands are quite hard
to call from shell scripts, as are probably not really a suitable interface.

An even better solution would be move this code to a 'dell_acpi' module
exposing the appropriate ACPI events and data under '/proc/acpi/dell/*'.  
This would also remove the need for the 'i8kbuttons' daemon.  My hunch is
that you might be able to get this directly into Ubuntu as it progresses the
laptop-mission goals and then have the Ubuntu kernel folks worry about
pushing it upstream!

	-Paul
-- 
This country is covered in white fluffy snow.  Helsinki, FI