SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I figured though if it is this trivial , why not? Plus I am getting old (Get off my digital lawn you young people! ) , and I just want that reminder that ' yes you old fart, you are indeed running generic and not huge.'
Trivial would depend on your definition. It would require separating the modules package and then contain two separate sets of modules, most of them being duplicates. While it's not that difficult to separate the modules package, it is different than how Slackware has been operating since it introduced the huge kernel in 2006 for the eventual Slackware 12.0.
Trivial would depend on your definition. It would require separating the modules package and then contain two separate sets of modules, most of them being duplicates. While it's not that difficult to separate the modules package, it is different than how Slackware has been operating since it introduced the huge kernel in 2006 for the eventual Slackware 12.0.
I see, I guess uname just works different - as I never understood why it doesn't already just reflect 'huge' and 'generic' , since in boot each kernel is already labeled as such, oh well.
I see, I guess uname just works different - as I never understood why it doesn't already just reflect 'huge' and 'generic' , since in boot each kernel is already labeled as such, oh well.
That is just the filename. You can pick whatever you want for the filename. However, the kernel's designation within the system is determined based on its version and anything appended to it using "local version". Adding a local version option to say huge or generic would then show the kernel's version as 5.17.1-huge, but that would then require the modules folder to match the kernel version, meaning we'd need two separate module folders for the generic and huge kernels.
That is just the filename. You can pick whatever you want for the filename. However, the kernel's designation within the system is determined based on its version and anything appended to it using "local version". Adding a local version option to say huge or generic would then show the kernel's version as 5.17.1-huge, but that would then require the modules folder to match the kernel version, meaning we'd need two separate module folders for the generic and huge kernels.
Or go the "local version" label way and symlink both modules tree to genuine tree ?
Would it work ? I guess it could.
Would it be ugly ? The Slackware way ? To each his own and Pat's choice for everybody !
Or go the "local version" label way and symlink both modules tree to genuine tree ?
Would it work ? I guess it could.
Would it be ugly ? The Slackware way ? To each his own and Pat's choice for everybody !
Nope, it will NOT work.
Because also the modules are hardwired for the kernel versions, then the 5.17.1-generic modules will not work with a 5.17.1-huge kernel, because of the version mismatch.
Because also the modules are hardwired for the kernel versions, then the 5.17.1-generic modules will not work with a 5.17.1-huge kernel, because of the version mismatch.
Are you sure about that ?
From what I see, there is only one package kernel-modules-*.txz for both
you can find the modules tree in /lib/modules/
The only difference I see, is the kernel itself:
vmlinuz-generic & vmlinuz-huge
For me, the kernel-huge is just a kernel-generic with some "built-in" modules, so there is no trouble using the same modules tree as the generic
From what I see, there is only one package kernel-modules-*.txz for both
you can find it in /lib/modules/
The only difference I see, is the kernel itself:
vmlinuz-generic & vmlinuz-huge
For me, the kernel-huge is just a kernel-generic with some "built-in" modules, so there is no trouble using the same modules tree as the generic
You are talking about the kernel package names. This is not what LuckyCyborg described.
Also he is correct. The "localversion" string will become part of the kernel version string, so from just a single "5.17.1" kernel version we would go to two different kernel versions "5.17.1-generic" and "5.17.1-huge" and like LuckyCyborg said, kernel modules for one kernel will not work with the other because of the version mismatch. Waste of effort.
You are talking about the kernel package names. This is not what LuckyCyborg described.
Also he is correct. The "localversion" string will become part of the kernel version string, so from just a single "5.17.1" kernel version we would go to two different kernel versions "5.17.1-generic" and "5.17.1-huge" and like LuckyCyborg said, kernel modules for one kernel will not work with the other because of the version mismatch. Waste of effort.
Patrick doesn't use the "localversion" to build the modules
Code:
blackstar:~:# grep CONFIG_LOCALVERSION /usr/src/linux-5.17/.config
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
# Build kernel-modules (for the just built generic kernel, but most of them
# will also work with the huge kernel):
PS: The "Waste of effort." was finally not so much a waste ;-)
The suggestion was to make a way for uname to show whether you're using a generic or huge kernel. The only way to do that is by appending it to the end of the kernel version with localversion, but that would break the existing modules package and you'd need to split it into two separate folders for modules (most likely with separate packages). Modules are built for the version (and localversion, if used), so they are not interchangeable if Pat were to use localversion to add generic or huge.
The suggestion was to make a way for uname to show whether you're using a generic or huge kernel. The only way to do that is by appending it to the end of the kernel version with localversion, but that would break the existing modules package and you'd need to split it into two separate folders for modules (most likely with separate packages). Modules are built for the version (and localversion, if used), so they are not interchangeable if Pat were to use localversion to add generic or huge.
Right
That's why I think, because, who can do more, can do less
Quote:
Originally Posted by Tonus
Or go the "local version" label way and symlink both modules tree to genuine tree ?
Would it work ? I guess it could.
Would it be ugly ? The Slackware way ? To each his own and Pat's choice for everybody !
I am not knowledgeable on it, but according to others, the modules contain the full kernel version, including localversion. Based on that, the "ugly" hack would not work.
I am not knowledgeable on it, but according to others, the modules contain the full kernel version, including localversion. Based on that, the "ugly" hack would not work.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
) , and I just want that reminder that ' yes you old fart, you are indeed running generic and not huge.' 
