On 2014-02-14 18:29, Nishanth Aravamudan wrote:
> /* Try to match a preN/rcN version */
> start = end + 1;
> if (*end == '-') {
> if (*start == 'r' && *(start + 1) == 'c')
> start += 2;
> else if (*start == 'p' &&
> *(start + 1) == 'r' &&
> *(start + 2) == 'e')
> start += 3;
>
> ver->pre = strtol(start, &end, 10);
> }
>
> I believe this will treat everything after the x.y.z- as a pre/rc level
> version, which isn't right for the following example, at least:
>
> 3.11.10-301.fc20.ppc64p7
>
> which puts 301 as the pre?
>
> I think the right think to do is:
> --- a/kernel-features.c
> +++ b/kernel-features.c
> @@ -125,6 +125,8 @@ static int str_to_ver(const char *str, struct
> kernel_version
> *(start + 1) == 'r' &&
> *(start + 2) == 'e')
> start += 3;
> + else
> + return 0;
>
> ver->pre = strtol(start, &end, 10);
> }
>
> but wanted confirmation from others before I sent a signed-off patch.
>
> Thanks,
> Nish
>
>
After reading the old code, I believe that you are correct. THe current
implementation does count 301 as the 'pre' but it should not (and didn't
before 8c075e33).
Eric
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
