getting new driver into kernel, boot.iso

Michael K. Johnson johnsonm at redhat.com
Fri Aug 8 15:01:23 UTC 2003


On Thu, Aug 07, 2003 at 10:12:18PM -0700, David Kewley wrote:
> If you go to the Asus website, they give you a driver to download, which 
> appears to be a 3Com-hacked version of an old sk98lin driver from 
> SysConnect.  (It appears that the logic on the 3C940 is licensed from 
> SysConnect.)  The sk98lin in the kernel.org kernel, and in the RH kernel, 
> do not support the 3C940.  However, SysKonnect has since provided newer 
> versions of sk98lin on their website which do support the 3C940:
> 
> http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin.htm

It's important for drivers to be submitted for inclusion in the upstream
kernel.  As I've written in other threads, it doesn't make sense to have
Red Hat's kernel be comprised of parts we have to poll a large selection
of sources for -- that way we'll always be behind on everything.  The
whole point of having a mainstream kernel is that it is mainstream, that
all updates happen in that context, that there's one point of integration
that all process participants push to.

I find it interesting that the name of the patch isn't actually a link;
in my quick perusal it wasn't even clear that it's available...  I also
find it interesting that it is listed as a >.5MB patch against 2.4.21;
that's not small or easy to verify/review, even if you actually can get at
the source, which it isn't clear from the page describing it:
http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin_2.4.21.htm

> I want to see the latest sk98lin integrated into the Red Hat kernel (for RHL 
> 9, and for the beta or the next release).  I'm willing to do work on this 
> myself.  Once I have something that works to my satisfaction, I'll offer it 
> on my website for others to use.  I'll also offer my work to RH, if they're 
> interested.
> 
> My goal is to integrate the latest sk98lin in a way that adheres to RH's 
> practices and which promotes maintainability and portability to future 
> kernel releases (until the latest sk98lin gets officially incorporated).  
> But I need some guidance to arrive at this destination.

As I mentioned above, our first policy is to get things upstream.

> I've already made a boot.iso which I can use to kickstart the P4P800.  But I 
> made it in an ugly, unmaintainable way (by hacking the initrd).  I think 

Actually, you can make driver disks (Doug Ledford has a kit on his
page at http://people.redhat.com/dledford/ ) and I think you can drop
the updates on the iso somehow (installer folks would have details on
that; not my area of expertise).


All that about upstream and driver kit said, I'll answer the rest of
the questions about building kernel per se as best as I can, as they
are probably more generically useful.

> First of all, it appears that I need to pick an appropriate patch serial 
> number for the specfile.  What should I use?

Just grab one at the end of the block for new devices.  We go by 10s
so that we can interpolate later easily.

# Patches 1000 to 5000 are reserved for bugfixes to drivers and filesystems

This is not an entirely new driver; those go in the "addon" directory
and are in the next block:
# Patches 5000 to 6000 are reserved for new drivers

> Second, if my patch is applied midway through the patching process, I need 
> to be careful how I produce the patch, so as not to interfere with later 
> patches.  How do I do this?

Well, which patches actually interfere?  Often it just doesn't matter.
In this case I doubt it will.  There really aren't many patches applied
after that block.

When it does matter, and you do need to slot a patch in the middle,
it does take some work.  Usually, you put an "exit 0" in the
spec file right before the place where you want to put the patch.
Then you build the patch against the resulting source tree, and
then you have to keep moving the exit 0 down through the spec file
as you modify subsequent patches to deal with the conflict.  You
clearly need to understand that patch you are working with fully
in order to do this manipulation correctly.  This would include
a clear understanding of why the patches go in the order your are
putting them in.

But a driver update won't normally create this hassle.

> Third, I expect that I'll have to pick a custom build string until and 
> unless RH accepts my patch or builds their own.  I suppose if I start with 
> e.g. kernel-2.4.20-18.9, I could make mine by kernel-2.4.20-18.9.dk.1.  Is 
> that appropriate?

Yup, that's exactly what we ask for!

michaelkjohnson

 "He that composes himself is wiser than he that composes a book."
 Linux Application Development                     -- Ben Franklin
 http://people.redhat.com/johnsonm/lad/





More information about the devel mailing list