[Qtextended] Kernel modules from mwester
Hi, I am using the current kernel for qtexended on FR available from mwester. I also downloaded the minimal kernel module set from http://moko.mwester.net/dl.html#kernels. The version of the module set and the kernel seems to be matching, but after extracting the modules on my system, I now have two directories under /lib/modules (as I had expected): 2.6.24 (the original kernel) and 2.6.24mw-g291a9d50 (the minimal module set). My question is if I was actually supposed to install the module set, and if so, whether they would be in use, and what difference they are supposed to make. The file names therein match the module names inside the kernel, but the sizes are obviously smaller, so they weren't meant to be a replacement. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Qtextended] Kernel modules from mwester
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nishit Dave wrote: > Hi, > > I am using the current kernel for qtexended on FR available from > mwester. I also downloaded the minimal kernel module set from > http://moko.mwester.net/dl.html#kernels. > > The version of the module set and the kernel seems to be matching, but > after extracting the modules on my system, I now have two directories > under /lib/modules (as I had expected): 2.6.24 (the original kernel) and > 2.6.24mw-g291a9d50 (the minimal module set). A given kernel is going to look for its modules down only one path. We have been using these build-specific paths in the git build system for some time, they eliminate the problem that incorrect modules get loaded into kernel space when you change the main kernel binary. I dunno what our packaging side is doing about modules because it's not discussed anywhere that I read. Anyway it's good news mwester is using the same system, it just means that you only actually need the dir that matches the build stamp of the monolithic kernel you are using; any other dirs left lying around don't make any trouble except waste space if you will never revert to the kernel that matches them. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjt7DcACgkQOjLpvpq7dMqymwCfcs6sGhJSWnb6tydDS/SRfJp1 BVwAn2GDr16d9CZlfkKSkxbGKAbLRKlQ =TLS0 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Qtextended] Kernel modules from mwester
On Thu, Oct 9, 2008 at 5:04 PM, Andy Green <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Nishit Dave wrote: > > Hi, > > > > I am using the current kernel for qtexended on FR available from > > mwester. I also downloaded the minimal kernel module set from > > http://moko.mwester.net/dl.html#kernels. > > > > The version of the module set and the kernel seems to be matching, but > > after extracting the modules on my system, I now have two directories > > under /lib/modules (as I had expected): 2.6.24 (the original kernel) and > > 2.6.24mw-g291a9d50 (the minimal module set). > > A given kernel is going to look for its modules down only one path. We > have been using these build-specific paths in the git build system for > some time, they eliminate the problem that incorrect modules get loaded > into kernel space when you change the main kernel binary. I dunno what > our packaging side is doing about modules because it's not discussed > anywhere that I read. > > Anyway it's good news mwester is using the same system, it just means > that you only actually need the dir that matches the build stamp of the > monolithic kernel you are using; any other dirs left lying around don't > make any trouble except waste space if you will never revert to the > kernel that matches them. > > Update: After deleting the 2.6.24mw-g291a9d50 branch from under /lib/modules and rebooting, I found that the original kernel looks for modules under it (the deleted branch). So it is useful, after all. I don't know what additional utility it provides, though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
