Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   CentOS (http://www.linux-archive.org/centos/)
-   -   Correct way to provide kernel patch (http://www.linux-archive.org/centos/264324-correct-way-provide-kernel-patch.html)

Chris Miller 03-16-2009 07:24 PM

Correct way to provide kernel patch
 
I work with a USB device that is intercepted by the USB HID driver.
In order to stop this behavior, the device needs to be added to the
HID blacklist (hid-core.c) and a custom kernel needs to be compiled.

If I create a CentOS specific patch, it appears I need to create the
patch against an already patched source tree (i.e. after running
rpmbuild -bp) because other patches exist that add items to the
blacklist that would break my diff patch. Seems like this would be a
never ending battle as new patches get added to new kernels.

What's the correct way to get this device added to the kernel? Do I
submit my patch to the CentOS dev team, to the kernel.org folks, or
both? What's the timeline (if accepted) to actually seeing this in a
production kernel? On the CentOS kernel build how-to, the kABI fixes
won't make it into CentOS until 5.4, and 5.3 hasn't been released yet.

Thanks in advance...

Regards,
Chris
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Akemi Yagi 03-18-2009 01:53 PM

Correct way to provide kernel patch
 
On Mon, Mar 16, 2009 at 1:24 PM, Chris Miller <centos@scratchspace.com> wrote:
>
> I work with a USB device that is intercepted by the USB HID driver.
> In order to stop this behavior, the device needs to be added to the
> HID blacklist (hid-core.c) and a custom kernel needs to be compiled.
>
> If I create a CentOS specific patch, it appears I need to create the
> patch against an already patched source tree (i.e. after running
> rpmbuild -bp) because other patches exist that add items to the
> blacklist that would break my diff patch. Seems like this would be a
> never ending battle as new patches get added to new kernels.
>
> What's the correct way to get this device added to the kernel? Do I
> submit my patch to the CentOS dev team, to the kernel.org folks, or
> both? What's the timeline (if accepted) to actually seeing this in a
> production kernel? On the CentOS kernel build how-to, the kABI fixes
> won't make it into CentOS until 5.4, and 5.3 hasn't been released yet.

CentOS will not make changes to the distro kernel because it aims to
be 100% binary compatible (including bugs). However, it you submit
the patch you have, it might be included in the centosplus kernel. I
suggest you open a report at http://bugs.centos.org with a detailed
description of the problem and upload your patch.

Another thing you want to try is to open a bugzilla upstream. If the
patch is incorporated in the upstream kernel, it will then be in the
CentOS kernel.

The kABI fix you mentioned is not a problem. It is just a note. You
can still build custom kernels by following the instructions on the
Wiki.

Akemi
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Robert Heller 03-18-2009 03:14 PM

Correct way to provide kernel patch
 
At Wed, 18 Mar 2009 07:53:46 -0700 CentOS mailing list <centos@centos.org> wrote:

>
> On Mon, Mar 16, 2009 at 1:24 PM, Chris Miller <centos@scratchspace.com> wrote:
> >
> > I work with a USB device that is intercepted by the USB HID driver.
> > In order to stop this behavior, the device needs to be added to the
> > HID blacklist (hid-core.c) and a custom kernel needs to be compiled.
> >
> > If I create a CentOS specific patch, it appears I need to create the
> > patch against an already patched source tree (i.e. after running
> > rpmbuild -bp) because other patches exist that add items to the
> > blacklist that would break my diff patch. Seems like this would be a
> > never ending battle as new patches get added to new kernels.
> >
> > What's the correct way to get this device added to the kernel? Do I
> > submit my patch to the CentOS dev team, to the kernel.org folks, or
> > both? What's the timeline (if accepted) to actually seeing this in a
> > production kernel? On the CentOS kernel build how-to, the kABI fixes
> > won't make it into CentOS until 5.4, and 5.3 hasn't been released yet.
>
> CentOS will not make changes to the distro kernel because it aims to
> be 100% binary compatible (including bugs). However, it you submit
> the patch you have, it might be included in the centosplus kernel. I
> suggest you open a report at http://bugs.centos.org with a detailed
> description of the problem and upload your patch.
>
> Another thing you want to try is to open a bugzilla upstream. If the
> patch is incorporated in the upstream kernel, it will then be in the
> CentOS kernel.
>
> The kABI fix you mentioned is not a problem. It is just a note. You
> can still build custom kernels by following the instructions on the
> Wiki.

If the OP has written a libusb (user mode) driver for his device, he
does not really have to add the device to the usb core blacklist and
rebuild the kernel. Libusb has a call, usb_detach_kernel_driver_np,
that will detach the device from the kernel HID driver. I use this
call with the code I wrote for the Rail Driver device.

>
> Akemi
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
heller@deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


All times are GMT. The time now is 02:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.