can i simply "re-version" the kernel down to 2.x?
for reasons that don't need explaining, i need to rebuild my current 3.0.0... kernel so that it returns a "uname" version number of "2.whatever". i simply have an app i want to run that checks the output of "uname" and if it doesn't see a major number of "2", it goes a bit squirrelly. there's no *technical* reason i can see for the app to be that restrictive, so i was just going to hack the top level Makefile of my git clone and label this as a 2.99.99 kernel. is there anything that would break because of that kind of hackery? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Fri, Aug 05, 2011 at 10:36:00AM -0400, Robert P. J. Day wrote:
for reasons that don't need explaining, i need to rebuild my current 3.0.0... kernel so that it returns a "uname" version number of "2.whatever". i simply have an app i want to run that checks the output of "uname" and if it doesn't see a major number of "2", it goes a bit squirrelly.
there's no *technical* reason i can see for the app to be that restrictive, so i was just going to hack the top level Makefile of my git clone and label this as a 2.99.99 kernel. is there anything that would break because of that kind of hackery?
Why not just call it 2.6.40 like Fedora is doing for this very reason?
On Fri, 5 Aug 2011, Greg KH wrote:
On Fri, Aug 05, 2011 at 10:36:00AM -0400, Robert P. J. Day wrote:
for reasons that don't need explaining, i need to rebuild my current 3.0.0... kernel so that it returns a "uname" version number of "2.whatever". i simply have an app i want to run that checks the output of "uname" and if it doesn't see a major number of "2", it goes a bit squirrelly.
there's no *technical* reason i can see for the app to be that restrictive, so i was just going to hack the top level Makefile of my git clone and label this as a 2.99.99 kernel. is there anything that would break because of that kind of hackery?
Why not just call it 2.6.40 like Fedora is doing for this very reason?
i could do that as well, i just wanted to verify that manually tweaking it this way wouldn't clash with any other versioning info hidden somewhere else in the source tree. i'll know in about 10 minutes once this build is done. rday
On Fri, Aug 05, 2011 at 10:36:00AM -0400, Robert P. J. Day wrote:
for reasons that don't need explaining, i need to rebuild my current 3.0.0... kernel so that it returns a "uname" version number of "2.whatever". i simply have an app i want to run that checks the output of "uname" and if it doesn't see a major number of "2", it goes a bit squirrelly.
If it is just one poorly written app you are trying to deal with, it might just be easier to create a wrapper dll that traps the glibc uname wrapper and hijacks the returned version. Something like this: --- /dev/null 2011-08-02 20:23:03.358999850 -0500 +++ b/trapuname.c 2011-08-05 22:45:02.000000000 -0500 @@ -0,0 +1,43 @@ +/* trapuname: tool to fake uname release + * Copyright (C) 2011 Josh Cartwright <joshc@linux.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + */ +#define _GNU_SOURCE +#include <dlfcn.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <sys/utsname.h> + +int uname(struct utsname *u) +{ + const char *err; + int ret; + int (*old_uname)(struct utsname *u); + + dlerror(); + old_uname = dlsym(RTLD_NEXT, "uname"); + + if ((err = dlerror())) { + fprintf(stderr, "Unable to load uname: %s\n", err); + exit(EXIT_FAILURE); + } + + if (!(ret = old_uname(u))) + strcpy(u->release, "2.6.40"); + + return ret; +} Build it into a dynamic library, the use LD_PRELOAD to load it before your application is run: $ gcc -shared -fPIC trapuname.c -ldl -o libtrapuname.so $ LD_PRELOAD=./libtrapuname.so stupidapp At least this way, you won't be carting around a local kernel patch just for a version change :\. -- joshc
participants (3)
-
Greg KH -
Josh Cartwright -
Robert P. J. Day