can i simply "re-version" the kernel down to 2.x?

can i simply "re-version" the kernel down to 2.x?

[Robert P. J. Day]

  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
========================================================================

can i simply "re-version" the kernel down to 2.x?

[Greg KH]

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?

can i simply "re-version" the kernel down to 2.x?

[Robert P. J. Day]

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

can i simply "re-version" the kernel down to 2.x?

[Josh Cartwright]

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