[elrepo] request for updated sis190 driver

[Phil Perry]

Del wrote:
> Hi Phil,
> 
> Thanks for the reply.
> 
>> OK, that sounds promising. Which patch are you looking at in the git tree:
>>
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=history;f=drivers/net/sis190.c;h=55ccd51d247efc3fa20cddd6616ddc8607637e17;hb=a616b3e5a8c7a379f2fd4bc4e153868509fec94a
> 
> This is the one that specifically fixes the 64 bit issue:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=744c6b2976778ac6944e580fc413842df85be84e
> 

Right, that one has not made it into the latest released kernel hence 
why I missed it when looking. Thanks.

> However I see a number of sis190 patches in the git tree for the latest 
> kernel.  There's obviously been a fair amount of development work going 
> on there.  What probably needs to happen is that the latest 2.6.30 sis 
> driver needs a backport.
> 

Indeed. However the latest kernel driver doesn't build against our 
kernel tree.

>> Also, please could you test the latest testing kernel from here:
>>
>> http://people.redhat.com/dzickus/el5/
>>
>> just to be sure these issues aren't fixed in the upcoming 5.4 release.
> 
> Have done, no success.  The same issues exist.
> 

Thanks for confirming that - no simple fix there then so we need to look 
at doing a backport.

>> Alan has handled network drivers to date, so I don't know if he'll want 
>> to pick this one up too, but he's not around for a few days. In the 
>> meantime, if you could please report back on the state of play with the 
>> latest testing kernel and we'll take it from there :)
> 
> OK, cool.
> 
> In addition, we've recently acquired a Linux hardware dealer -- 
> Everything Linux http://www.elx.com.au/
> 
> It would be useful for our sysadmin guy (who isn't here today) to have a 
> bit of an understanding on how the process worked in case we needed to 
> do this for other drivers in future.  Both he and I have a fair amount 
> of experience in messing with kernels but no exposure to how the ELrepo 
> packaging process works, or how the kmod driver system is used.
> 

Well, this might be a reasonably good example to learn the process, 
being just a single file driver (sis190.c).

To start with you need source code for the driver you can build against 
your EL5.3 kernel. If we take the source code from the upstream mainline 
kernel (say, 2.6.30), and try to build it against our EL kernel, this is 
known as building the driver out of tree. Sometimes it works and the 
process is easy, other times it doesn't and the process of backporting 
becomes a lot harder.

If the driver doesn't depend on anything else in the tree then the 
process is simpler whereas if the driver depends on other software 
stacks then it's often a non starter. For example I recently looked at a 
driver for a USB device that also depended on the storage stack and 
would have needed the complete USB and SCSI code within the kernel to 
also be backported - not going to happen.

So I would start by grabbing the latest upstream source and see if it 
builds cleanly against our tree - it doesn't in this case. Now go back 
and randomly grab source version until you find one that does build (the 
  revision snapshot from 2006-03-04 does). Now move forward testing each 
patch to see what works and what fails to build fixing what you can as 
you go. It may be the case that we just need to omit (or fix) the odd 
patch to allow the source to build cleanly out of tree against 5.3.

Once we have backported source code that cleanly builds, it's easy to 
drop it into a kmod package. One of the first kmod packages we did for a 
single driver file (like sis190) was kmod-it87 so you could take the 
src.rpm for that package and use it as a template to drop in your own 
driver.

As you can hopefully see, the difficult/time consuming part is 
backporting working code. Sometimes it's easy and the latest code builds 
cleanly straight away, other times it's a non-starter, or you can spend 
hours reaching a point where you find it's not really viable. Once you 
have working source code then it's very quick to package that as a kmod.

Hope that helps explain the process a little.