=== himcesjf_ is now known as him-cesjf
[07:45] <claudiof> Hi all, I have a question about Ubuntu kernel versioning vs mainline.
[07:45] <claudiof> In my application, I need to look at the output of ftrace, which has seen incompatible changes in mainline version 4.14
[07:46] <claudiof> Currently I am using version.h LINUX_VERSION_CODE to detect this, but this breaks with Ubuntu kernels
[07:47] <claudiof> Does anybody have a suggestion on how to properly detect this on Ubuntu?
[07:50] <apw> claudiof, if the stable kernel version is enough, that is exposed in /proc/version_signature
[07:55] <claudiof> Hello apw, thanks for this pointer; how do you think I can map that information to the feature?
[07:56] <apw> claudiof, i thought you were saying that from a real kernel version you can intuit it
[07:56] <claudiof> yes
[07:56] <apw> i am saying the raw mainline kernel version is in there, from Makefile
[07:57] <claudiof> is it the same as the one reported in the Ubuntu kernel header linux/version.h?
[07:58] <claudiof> I ask because the raw mainline base version on which Ubuntu is based is much older, and the ftrace features (and output) does not seem to correspond with the reported mainline base version
[08:02] <claudiof> For example on my Ubuntu kernel 4.10.0-38-generic
[08:03] <claudiof> there is the ftrace trace_marker_raw feature
[08:03] <claudiof> while the version.h reports a mainline kernel version that does not have the feature
[08:04] <claudiof> cat /usr/include/linux/version.h #define LINUX_VERSION_CODE 263266
[08:05] <apw> 4.10?
[08:07] <claudiof> Yes, Ubuntu version is 4.10
[08:07] <claudiof> but the LINUX_VERSION_CODE is < 4.10
[08:08] <claudiof> the feature appears in mainline version 4.10
[08:08] <claudiof> and changes substantially in behaviour in 4.14
[08:09] <claudiof> The Ubuntu 4.10.0-38-generic appears to shows the linux mainline 4.10.x behaviour regarding trac_marker_raw
[08:10] <claudiof> The Ubuntu 4.10.0-38-generic appears to show the linux mainline 4.10.x behaviour regarding trace_marker_raw
[08:34] <apw> oh you are looking at the linux-libc-dev version on an lts, with a lts backport kernel installed
[08:34] <apw> that is tue ga kernel base
[08:34] <apw> the
[08:39] <claudiof> Sorry I could not understand your suggestion, could you come again?
[10:22] <claudiof> Hi apw, sorry I had to reboot into the distro kernel to check, were you mentioning before some specific thing I should check instead of version.h to understand which User-visible behaviour I am going to experience with a particular kernel version?
[10:22] <claudiof> Is  /proc/version_signature the one that counts?
[10:23] <claudiof> So in my case I have "Ubuntu 4.10.0-38.42~16.04.1-generic 4.10.17" -> which means that the output I get should be similar to upstream version 4.10.17?
[10:30] <ricotz> claudiof, despite your question, you should check your installation since only 4.4.0-* and 4.15.0-* are still maintained for 16.04/xenial
[10:31] <ricotz> https://launchpad.net/ubuntu/+source/linux and https://launchpad.net/ubuntu/+source/linux-hwe
[10:50] <claudiof> I'll check that ricotz thanks
[10:52] <apw> claudiof, right, as ricotz says there is no live 4.10 branches so something is off
[10:53] <apw> claudiof, but the live kernel version is only available from teh kernel; the clearest there is proc/version_signature; but that is ubuntu specific in form
[10:59] <claudiof> thank you - Do you think that should be the same as include/linux.h from the linux-libc-dev package? Or should I expect differences there?
[10:59] <apw> claudiof, the include/linux.h can only match one kernel at best; and indeed should match the GA kernel in theory (iirc)
[11:00] <apw> claudiof, but as we have at times 3 kernels in an LTS at different versions it can never be accurate en-toto
[11:00] <apw> claudiof, also if a semantic change is introduced in 4.15.8, it is entirely possible for one kernel on your system to have that
[11:01] <apw> claudiof, and a second one not, even if they were at the same base versions ... so you can only rely on information
[11:01] <apw> claudiof, from the actual running kernel to know
[11:01] <claudiof> good point.. checking version.h says nothing about the kernel that is effectively going to run the app
[11:01] <apw> if you do an update, you get a new version.h and new kernel on disk, but you arn't running it
[11:01] <apw> or you could opt to only update the kernel itself, and not the headers package
[11:02] <apw> and the headers be out of sync the other way
[11:02] <apw> now, i will admit that out version exposure is a little poor to say the least
[11:02] <claudiof> thanks apw for your comments, I think I have a slighly better grasp now.. 
[11:03] <claudiof> I will check the reported version at runtime then
[11:06] <apw> the equivalent of uname -r would be the best way in a perfect world; except for (mostly stupid now) reasons we do not include the full version
[11:07] <apw> which i realllllly should fix
[11:15] <claudiof> hehe that would be good :-)
[11:15] <claudiof> thanks again for the help
[13:17] <cascardo> ftrace should be versioned itself
=== lan3y is now known as Laney
=== SimonNL is now known as SimonNL_Afk
=== SimonNL_Afk is now known as SimonNL
[22:08] <TJ-> Someone's just reported nvidia drivers failing to build on 4.15.0-29 the Makefile reports missing libelf-dev and I don't see it as a Depends: of any of the nvidia-graphics-drivers packages. Can't find a bug on this but looks like we'd need a report for each nvidia version