[Dev] External kernel module building and kernel ABI/API check.

Jacek Pielaszkiewicz j.pielaszkie at samsung.com
Thu Dec 12 12:28:23 GMT 2013


Hi 

	The fingerprint file it is in fact Module.symvers file. The file is produced during kernel build process. It contains all CRC for each exported symbol by the kernel. As far as I know any changes in exported kernel symbol cause the CRC value change for the symbol. 

	I don't know how deep change cause CRC change for the given symbol. You can find "Linux Kernel ABI Tracker" tool. It seems that tool very deeply checks changes in API/API, but is very costly. I have tried to run for one kernel image and after few hours the process was still running in my development environment and finally I didn't receive any results.


Best regards


Jacek Pielaszkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Email: j.pielaszkie at samsung.com



> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: Wednesday, December 11, 2013 12:56 PM
> To: Jacek Pielaszkiewicz
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] External kernel module building and kernel ABI/API
> check.
> 
> On Tue, 2013-12-10 at 13:13 +0100, Jacek Pielaszkiewicz wrote:
> > 	The second one - detection API/API kernel changes is ongoing. The
> > solution assumes that kernel sources will be extended by "repository"
> > of kernel API/ABI fingerprints.
> 
> How is such a fingerprint generated? The description of that step
> wasn't very clear to me.
> 
> You mentioned a list of symbols, but that's not enough to describe the
> API or ABI. Data structures and their content are also relevant. It's
> of course fine to deliberately ignore that (some minimal checking is
> still better than none), but then there should be a section with "known
> limitations" where that is called out.
> 
> --
> Best Regards, Patrick Ohly
> 
> The content of this message is my personal opinion only and although I
> am an employee of Intel, the statements I make here in no way represent
> Intel's position on the issue, nor am I authorized to speak on behalf
> of Intel on this matter.





More information about the Dev mailing list