0

Im going to shorten the background this time as its all available in my previous question my previous kernel question.

Basically, i have a sm-t330nu samsung galaxy tab 4 and am trying to compile a test kernel from source.

Question #1: How is it possible that a kernel direct from samsung could have so many compile errors? would the source not be of a production ready kernel? or do they simply use a single linux kernel (depending on software number i suppose) with the ability to be built for many different platforms/models of tablet depending on configuration?

Question #2: After doing some very basic debugging (helped by google) ive gotten passed 5-6 compiling issues (badly linked mach/msm_rtb.h, missing #includes, etc) with absolutely no prior c knowledge. however im now stuck on one that i believe truly needs c knowledge to trouble shoot. My error reads:

kernel/sys.c: In function 'override_release':
kernel/sys.c:1306:10: warning: comparison of distinct pointer types lacks a cast [enabled by default]
error, forbidden warning: sys.c:1306

When i research that particular error, i got that basically, in the funtcion 'override_release' there is an equation that is not correctly balanced. However I do not understand proper c syntax to be able to make the change.

here is the code snippet 'override_release':

    if (current->personality & UNAME26) {
    const char *rest = UTS_RELEASE;
    char buf[65] = { 0 };
    int ndots = 0;
    unsigned v;
    size_t copy;

    while (*rest) {
        if (*rest == '.' && ++ndots >= 3)
            break;
        if (!isdigit(*rest) && *rest != '.')
            break;
        rest++;
    }
    v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 40;
    copy = min(sizeof(buf), max_t(size_t, 1, len));
    copy = scnprintf(buf, copy, "2.6.%u%s", v, rest);
    ret = copy_to_user(release, buf, copy + 1);
}
return ret;

Im pretty sure the issue is in the lines:

        if (*rest == '.' && ++ndots >= 3)
            break;
        if (!isdigit(*rest) && *rest != '.')
            break;


edit#1
ok so im getting my source from http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=sm-t330nu. which i believe to be a complete working source simply because it was used in this post http://forum.xda-developers.com/tab-4/development/recovery-philz-smnu-t2980094 for the recovery build. So as you say its likely a configuration issue, maybe im missing build flags or something...
There are many defconfigs to choose from when building the kernel from source so i went with my cpu type (msm8226) and my model/software type (milletwifiue) .
As for the error telling me the line where the error resides (i think you meant 1306 instead of 1310 kernel/sys.c:1306:10)..

line 1306 is 

copy = min(sizeof(buf), max_t(size_t, 1, len));
Community
  • 1
  • 1
L8NIT3TR0UBL3
  • 103
  • 11
  • Something is really wrong. There surely is a comparison there, hidden behind some macros, but it should not be a *pointer* comparison. Since you say you didn't even get to that point until you performed some source modifications, I'm inclined to think you broke something. For example, perhaps you included a header file that should not have been included, with the result that one or more macros were (re)defined to something different than they were intended to be in that source file. – John Bollinger Mar 10 '15 at 19:44
  • thank you again :) im in the process of redownloading a clean kernel source, and am going to try running my 'make variant_defconfig' with a -j 4 (as my tab runs 4 cores). when i run my modified kernel code with the -j flag it bypasses my current issue and gives me a new pointer comparison issue... so im going to try with a vanilla source and be back with results :) – L8NIT3TR0UBL3 Mar 10 '15 at 19:57

1 Answers1

1

Question #1: How is it possible that a kernel direct from samsung could have so many compile errors? would the source not be of a production ready kernel? or do they simply use a single linux kernel (depending on software number i suppose) with the ability to be built for many different platforms/models of tablet depending on configuration?

Either it is not correct / complete source, or you are using a different compiler to build the kernel than Samsumg does, or you are configuring the build in a way that is not supported by the source and build system, or in some other way you are not performing the build as it needs to be performed. I'd bet that at least you have a configuration problem, but it's impossible for me to be sure from here.

The kernel's license requires Samsung to provide you the source from which they built the kernel they distributed to you on your device, but I cannot say whether what you actually downloaded is in fact that source.

It might very well be that they compile kernels for a range of devices from the same source, with a greater or lesser degree of difference in configuration. They should provide the configuration used to build their distributed kernels; I do not know whether they actually do. It is not safe to assume that you can build a kernel that works for your device without choosing appropriate values for various configuration options.

Question #2: [... I'm] now stuck on a build issue

Well, the code you are "pretty sure" is the source of the error is perfectly fine, and moreover contains nothing that even could match up with the error message you presented (there are no pointer comparisons in it). In any case, the error message tells you precisely where the error is: line 1310 of file kernel/sys.c.

In any case, it is highly unlikely that the source code distributed to you is in error in any way that you are in a position to fix. In fact, chances are good that it really is the source from which your original kernel was built. I recommend you focus on configuring the kernel correctly for your device, and perhaps on details of the build process, such as the working directory from which you launch it.

Furthermore, if I were you, I would go back to the original kernel source obtained from Samsung. If it doesn't build cleanly then it is more likely that you're doing it wrong than that the source is wrong.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157