I’m running Slackware 8.1 (don’t ask) with 2.4.20 kernel that has been patched with some Real Time Application Interface stuff that I really know very little about, but the system works.

I’ve been trying to get usb keyboard and mouse to work and succeeded in this by recompiling the kernel with this support, basic stuff, so at this point all good.

But I have a problem, when booting with my new kernel, the main application for which this system exists no longer works, due to there being modules compiled for a different kernel version and adding -f to any insmod commands just makes my eyes bleed, so to get around this, I made my custom kernel to have the same EXTRAVERSION as the previous one, all looked good, but there is still a problem.

When some of these custom RTAI modules are being loaded, there are numerous warnings about missing dependencies and unresolved symbols. This is becoming a nightmare so I have taken a step back and asking a different question that I think may accomplish my needs.





TLDR;

In the /usr/src/2.4.20/drivers/usb folder, there are many .c and .h files and I’m assuming these are what are used to build the modules depending on the options in my .config file after running make menuconfig for example, so I’m now wondering is it possible (I cant see why not), that I cant build the modules I’m needing and then use insmod to insert them into the running kernel as opposed to my original method of building a new custom kernel?

How would this be accomplished?


All thoughts are greatly appreciated…

2.4.20 is quite old - older than some guys posting here.

The rule is: you can keep running it as long as you don't mind getting hacked if you go online, and you don't use any modern software. I gather you have used modern software, thus bringing the Compatibility Curse upon yourself.

Everything's changed since those days. In the software versions x.y.z,
x = break in compatibility
y = feature(s) addition
z = bug fix / security enhancement.

The kernel is now at 4.x.x; gcc is now 8.x.x. The linux headers now live in a different place. Everything is different. Meltdown & Spectre are alive, well, & you are unpatched. Please get real and update. Endure whatever down-time that involves. You can probably bring another server up, start it accepting new connections, & stop yours.

To be exact, the ChangeLog was released on 28-Nov-2002. There have been newer updates in the 2.4 series, though, the last one was 2.4.31 released on 1-Jun-2005. That one fixes at least some problems with that kernel.
And Slackware 8.1 itself is from 19-Jun-2002, so even older still. It has received updates until juy 2012, more then 10 years!

5.1.15 is the latest stable kernel, although Slackware keeps to the longterm 4.19.x ones.
The gcc compiler suite already is at 9.x (9.1 in -current, with glibc 2.29).

I'm not being funny and certainly don't wish to seem ungrateful for the replies thus far, but did you guys even read my post?

I am more than aware how old and outdated this system is, not mentioning the security flaws that it has. This system can not be updated to a current kernel or distribution and running in a VM is also not an option. The system is isolated and will never be exposed to software other than what is running currently.

What I'm asking is how to compile kernel modules for the 2.4.20 kernel (that list in /usr/src/linux-2.4.20/drivers) that I can then insert into the running kernel without reconfiguring and compiling the kernel to support the additional features as would be done with make menuconfig or similar, such as usb keyboard support. I've already tried recompiling the kernel and this of course works and in part achieves my goal but in turn breaks the system, as mentioned in my post.

I'd really appreciate some direction here.

Would running make menuconfig in the current tree which is /usr/src/linux-2.4.20 and choosing the options I need, as modules. Then instead of recompiling the kennel by running make bzImage, I choose to only run make modules and make modules_install?

I'm assuming I can then insert the modules using mod probe or insmod?


Would there be any risk in doing this?

maybe check this "How to Compile Just One Kernel Module", build/rebuild your module(s), then depmod/reboot?

you'd need to get appropriate kernel and more or less hack through first link steps

The problem is here that that kernel is so old that almost all of us have long forgotten HOW to do that. People can give you generic hints, but nothing specific to that kernel.
Even the source tree has long changed a lot, so that without access to a 2.4.20 one something like /usr/src/linux-2.4.20/drivers doesn't say a lot.
To change "built-in" drivers to modules you will have to go through a complete kernel rebuild, though, just changing the option(s) to module won't work as the built kernel will still have that code internally so will never load the module as its already there.

Only if the kernel has the "hook" for the module but its code wasn't built-in.
So you can (re)build separately a module which is already configured AS being a module in the kernel, but not when the kernel has NO support for that module AS a module yet.
Most kernel options have one of three states:To take just a simple example(all from one of the last kernels I did compile/tune completely for my system)

1 members found this post helpful.

This was my worry.

I'll have an opportunity again tomorrow to be hands on with the machine so will update progress, if for nothing else than interest sakes.

If only I knew something more about these RTAI modules

Seems a very standard thing. Plenty online about RTAI in kernel docs, e.g.https://www.kernel.org/doc/ols/2001/rtai.pdf

Was passing through and thought I'd bring closure to this as, especially as I've since moved on from the company but did find it particularly interesting.

I wrote a brief blog post to document the process, albeit mostly how to install the kernel and not the actual process involved in getting to that stage, but regardless, it can be found here:
https://blog.david14.com/2020/06/scs...mouse-and.html.

I think essentially I just used the same source and didn't change the EXTRAVERSION in Makefile so that once built, the modules would have no issues being inserted into the new kernel (I believe thinking it was the same?).

I used the same .config file and then;

make menuconfig
make dep
make bzimage

copy bzimage to /boot
copy System.map to /boot
update lilo.conf

I added any additional support needed, specifically the usb stuff into the kernel as opposed to modules, hence not needing to build any new modules and rebuild any existing modules.

In the end, I think I was overthinking things and over complicating things but it was nice to use some old Slackware again. Unfortunately, my new company (old company as I've returned after some 23 years or so) use Debian servers (several versions old) so I'm on the learning curve again.

No comments needed, this was just for closure...

Then please mark this thread as [Solved]