Thomas Vaughan <tevaug...@gmail.com> writes: >>> isn't supported per se. But when [the software], or the makefiles, parse >>> the string >>> 3.12-1-amd64 >>> they don't get the expected result. If the uname -r were the string >>> 3.12.9-1 >>> then parsing it would yield the expected result. >>> ---END QUOTE FROM VENDOR--- >>> >>> Is the reported kernel-version string, "3.12-1-amd64", >>> something that I could change by compiling a custom kernel? >> >> Might a shell script that output the expected string work? > > An appropriately named shell script in the right place in the path > might take care of uname(1), but I don't see how to take care of > uname(2), the system call. > > When the vendor says that the software parses the string, I think that > the software is calling uname(). > > So my question is whether there is a way by compiling a custom kernel > for me to alter what the uname() system call reports. >
You can replace functions from dynamically linked libraries using LD_PRELOAD. Check using ldd on your third party binary to verify it is dynamically linked. A quick search found this fragment of code: http://www.technovelty.org/c/using-ld_preload-to-override-a-function.html. That example is replacing getpid with a function that calls the original getpid and prints a message, but you can use the same trick for uname and modify the utsname structure to taste before returning. There are restrictions on what you can LD_PRELOAD, which are covered in the manpage for ld.so(8). But as long as you satisfy those constraints, this should be significantly easier than building your own kernel. -- regards, kushal
pgp77iOTL_sm5.pgp
Description: PGP signature
