My big issue is that this will work for this one issue, but we have issues with more than one of our drivers and increasing the complexity of our kcompat by adding grep is not ideal.
Bruce is probably better at figuring out whether UTS_UBUNTU_RELEASE is set in the right place for us. I'd much rather use that as that's what we're using for Red Hat and SuSE. At the very least we need to hold off on this until we can discuss this internally and we may not hold the critical meeting for this until after the start of the year. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -----Original Message----- From: Allan, Bruce W Sent: Friday, December 12, 2014 8:15 AM To: Chris J Arges; Fujinaka, Todd Cc: e1000-devel@lists.sourceforge.net Subject: RE: [E1000-devel] [PATCH] Issues with compiling ixgbevf-2.15.3 on Ubuntu 3.13.0-30 > -----Original Message----- > From: Chris J Arges [mailto:chris.j.ar...@canonical.com] > Sent: Thursday, December 11, 2014 6:35 PM > To: Allan, Bruce W; Fujinaka, Todd > Cc: e1000-devel@lists.sourceforge.net > Subject: Re: [E1000-devel] [PATCH] Issues with compiling > ixgbevf-2.15.3 on Ubuntu 3.13.0-30 > > <snip> > >>> > >>> I'm not running Ubuntu, I'm looking at the 3.16.4-based kernel > >>> source in our local LXR database reportedly from the Ubuntu > >>> 14.10 linux-source package. IIRC, I ran 'make modules_prepare' > >>> using the 14.10 kernel config file which is supposed to generate > >>> the appropriate header files necessary for compiling out-of-tree > >>> drivers, but the only thing in ./include/generated/utsrelease.h > >>> is: > >>> > >>> #define UTS_RELEASE "3.16.4" > >>> > >>> How is it the stuff in /usr/src/linux-headers-`uname > >>> -r`/include/generated/utsrelease.h is different? Is it generated > >>> from a different config file or build scripts? > >>> > >> > >> Sorry for the confusion. Yes, this particular identifier is > >> generated in the Ubuntu distro linux packaging. > > > > So, are you saying the identifier will be found in a distro release > > package (like a "linux-headers" package or something similar) but > > *not* found in the Ubuntu linux-source-x.y.z package even after > > doing some level of processing of the source in that package? If > > that is the case, we will have to also load the Ubuntu > > linux-headers-x.y.z-n package into our LXR database if we want to be > > able to find the identifier to make Ubuntu-specific changes to our driver > > code. > > > > It's actually generated by the Linux Debian source packaging (for > example in Ubuntu Trusty 3.13 kernel: > http://zinc.ubuntu.com/git?p=ubuntu/ubuntu- > trusty.git;a=blob;f=debian/rules.d/2-binary-arch.mk;hb=HEAD > > This generates the file that eventually is packaged in the built > linux-headers* Debian package. So, if you install something like > 'linux-headers-`uname -r`', this will contain the generated file. > > This all being said, the original patch I submitted actually _doesn't_ > use UTS_UBUNTU_RELEASE. It greps for the affected function names and > defines a macro in order to ifdef the appropriate C code. So it should > work without having to update any database. Let me know if that patch > is acceptable. > > Thanks, > --chris j arges I'll leave it up to the folks here at Intel who own/work on the ixgbevf driver to decide what to do with your patch. I am more interested in, going forward, how to properly code for Ubuntu-specific back-ports. Thanks, Bruce. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
