getting new driver into kernel, boot.iso
Michael K. Johnson
johnsonm at redhat.com
Wed Aug 13 13:12:53 UTC 2003
On Tue, Aug 12, 2003 at 09:16:39PM -0700, David Kewley wrote:
> I got the updated sk98lin (version 6.14) driver disk working, and
> successfully used it along with a modified boot.iso CD to do a network
> kickstart using the on-board ethernet chip. I'll be writing up what I did,
> and posting the writeup and the driver disk files to the web soon. Thanks
> again, Michael, for the pointer to Doug Ledford's driver disk kit.
> I haven't contacted SysKonnect yet, but I'll be doing that, to urge them to
> submit their driver for inclusion in the kernel, and to offer them the
> driver disks I made, and the method for making them in the future.
In particular, they need to incorporate into their driver upstream
bugfixes, then submit it upstream...
> I wanted to reply to a few of Dave Jones' comments:
> Dave Jones wrote on Friday 08 August 2003 09:01:
> > (click the disk icon 8-)
Dave was telling me where to find it when it didn't occur to me that the
icon was clickable...
> > That aside ISTR someone mentioning that this update backs out
> > some stuff that has been fixed in mainline since they last did a push,
> > so that needs fixing,
> Huh, that could be, I don't know the mainline history of changes to this
> driver (and didn't attempt to look them up). I see that there's one RH
> patch in 2.4.21 (rawhide) that affects sk98lin slightly, in
> It'd be useful for someone who knows the history of sk98lin to give SK
> feedback about what needs patching...
That's really their job -- to follow the changes made upstream and make
sure that they keep their updates in sync.
> > Fishing out the good bits of the patch is a worthwhile thing for
> > someone to do, but its not a 10 minute job.
> I imagine so. What would be the most useful way for this to happen? Who
> would best do this? The SK developers?
Absolutely. No other solution scales. There are lots of drivers out
there, and for someone else besides the driver author to be responsible
for this just doesn't work in practice.
> (Then I guess they'd need to know
> what was fixed in the mainline kernel version of sk98lin.)
And they will have in their internal version control all the
versions of sk98lin they have worked on; they should diff the
version they previously submitted against what is upstream,
and intelligently apply that patch to their sources.
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
More information about the devel