For users with hardware requiring out of kernel modules, DKMS is a long standing mechanism to keep track of and update them whenever a new kernel is installed. I've been using it for years for the nvidia module, as well as a module for a usb wifi dongle. It's particularly useful at times when I'm tracking -current but it's also handy on -stable (which has had a few kernel updates this time around).

DKMS module updates can be run manually from the cli but there is also the capability to update & install out of date modules automagically if desired - this is probably the big feature that makes it attractive (to those who are attracted by such things). Over the years, I've added my own hooks to enable that capability in rc.S but more recently I've used rc.modules or rc.modules.local for that.

My suggestion is that DKMS enabling be added to the default rc.modules file, something along the lines of
It assumes that a user who has bothered to install DKMS (SlackBuild available at SBo) wants to use its main feature of automatic rebuilding of modules. For non DKMS users, it's a noop.

I hope this addition can be considered.

chris

adding init scripts for something that is not part of a distribution feels wrong. but please not that I am not against your suggestion in general.
the question, at least for me, is, why not adding DKMS to Slackware. It is a requirement for everyone who has own compiled modules/ drivers like nvida. and basically the standard functionality for this functionality these days, and since some time. There have been quite some kernel updates in 14.2, so the usefulness of DKMS is out of doubt.
Now I am aware that now maybe the "don't know and understand it therefor don't need it and Slackware don't need to change" trolls might be triggered and kicked in, but please don't. let people that have to do things you don't understand alone, thanks

1 members found this post helpful.

To be honest, I know well what is DKMS, but I do not need that DKMS at all. BUT, I am not the one who decide for Slackware. All the best to OP on his endeavor!

However, the only custom modules which I use are these for VirtualBox and for VMware Player, and both knows pretty well how to compile their things.

Yeah, I know, I know. NVIDIA blobs! Which are not part of Slackware, BTW...

So, what stops the SBO guys to integrate everything and to offer a complete NVIDIA with DKMS powers, within SBO?

----------------------------------
Initially, I had no intention and interest to post in this thread, BUT I felt the need to comment about some words, so I needed also to be on-topic...

Not everybody owns NVIDIA graphics cards, you know...

Useful? Maybe.

Out of doubt? Questionable.

Did you want to start yet another flamewar, or really for you anyone who has a different opinion by yours here is a "troll" ? Just asking.

I understand that you love that Fedora so much, BUT you can't transform Slackware into it.

IF Slackware disappoint you so much, how about you to use Fedora, plain and simple? It gives you everything you love. Already.

1 members found this post helpful.

A follow up of sorts from a previous conversation.

I think DKMS support is a good idea.

With the weekly changes with the Current kernel DKMS could be well tested.

3 members found this post helpful.

All --

I am still interested in DKMS and I still believe it is a good idea for Slackware too.

Especially if-or-when DKMS is ever included the Official Slackware Release that the /usr/lib/dkms/dkms_autoinstaller rc.style-script shipped with default 644 Permissions.

Or maybe there should be a wrapper script in /etc/rc.d/ ( ??? maybe rc.dkms ??? ) shipped with 644 permissions and leave /usr/lib/dkms/dkms_autoinstaller with 755 Permissions ?

Either way the ~/dkms_autoinstaller would only be executed if the user intentionally turned it on.

And as upnort and a4z said, it could certainly be tested almost weekly on Slackware Current

And OBTW ... thanks to chris.willing for the SBo dkms.SlackBuild !

-- kjh

I've only taken it over recently, hence my renewed interest for its support in rc.modules. The previous longer term maintainer (so thanks to him) was Daniel Levai.

chris

If this doesn't get added, you could add it yourself to dkms.SlackBuild. I had to do that with my amdgpu-pro driver, which would add a custom location to /etc/ld.so.conf if it didn't already exist. My code is as follows, which could be tweaked to add it to rc.modules.

I used to have this same library issue with some work related builds. Rather than adding library paths directly to ld.so.conf, I made an additional /etc/ld.so.conf.d directory so that build scripts could add a .conf file containing the additional path to that directory instead. The ld.so.conf file itself then needed just a line added to it to process contents of the .d directory. It's the same idea as /etc/(modprobe,profile,sysctl}.d (and many others) and would make a nice addition to Slackware (hint, hint).

Before I took over the dkms SlackBuild, I used to locally add the enabling scripting directory into rc.S - an idea Daniel (previous maintainer) wasn't keen on adding to the SlackBuild. I now suggest in the SlackBuild's README to add the enabling scripting into rc.modules.local. That may be good enough and I guess the SlackBuild could do that automatically (or add it to rc.modules even) but it still leaves a slightly icky feeling about modifying a system file without (potentially) the admin/user being aware of it. It would be much nicer for the enabling scripting to already be part of the system.

Another thought - extending the idea of configuration files in a .d directory similar to modprobe.d (and all those others), how about a /etc/rc.d/rc.modules.d into which SlackBuilds could put their own .conf files for additional module processing? It potentially keeps the system cleaner too since a particular package's .conf file is removed when the package is removed.

chris

Great idea!

Excuse me, but this thread in fact shows something which I think is a lack of the current Slackware init system.

It has a rigid structure which in practice needs to be ammended by hand. By user, a package builder or the Slackware maintainer.

I will not go to discuss the SysV init route because I think everyone is already aware of it, but even the BSD systems does not use a rigid init system like Slackware.

They use a program named "rcorder" to compute dynamically the order of init scripts, and then they are run accordly.

Take a look there:

https://www.freebsd.org/cgi/man.cgi?rcorder(8)

Idea is that every boot script should contain a specific comment, like:
Using rcorder is computed their order from this information.

I would like to note also that NetBSD ships a portable version of rcorder with their PkgSrc ports system, and probably it could be adapted for Slackware.

http://pkgsrc.se/pkgtools/rcorder

Maybe adopting a dynamic order for init scripts would be an idea to consider, considering that this init scripts system become more and more complex.

With a method of a dynamic order for init scripts, a rc.dkms can be plugged in a desired position on execution flow without ammeding other scripts.

The most common out of kernel modules I use are for USB Wifi dongles with manufacturer supplied code. As the mac80211/cfg80211 api frequently changes, a newer kernel usually requires modification of the driver code before it will compile, which makes using DKMS pointless.

It's not compulsory. If it's not useful to you, don't use it.

As already mentioned, if you don't have dkms installed, the proposed change to rc.modules is a noop. In fact, even if you do have it installed but no module registered with it, the proposed change is still essentially a noop.

chris

I came across DKMS some time ago, and like all other things that were new to me at the time, and I had no interest in them, they were cast aside.

However, I recently revisited the idea of implementing DKMS, especially as, having recently reinstalled the NVIDIA driver the manual way: a) Compile & install kernel; b) reboot into console mode (init 3); and c) uninstall & reinstall the NVIDIA driver. I didn't mind it at first, but over time, my tolerance for it dwindled to the point where I was looking in the NVIDIA driver .run file for options I could use to automate the building of the module, and came across a mention of DKMS. It triggered a memory of having come across it some time earlier, and decided to look into it. I did a search on this forum, and came across this thread. Sounded like just what the doctor ordered. Went to Slackbuilds.org, and installed the compiled package, but as I hadn't updated the kernel at that point, I had to bide my time.

Today was that day. I did my thing with the kernel, and, with breathless anticipation, rebooted my machine, and simply pressed Enter when the LILO menu came up. When the DKMS autoinstaller was invoked, it detected the new kernel, and went to work compiling the module for the new kernel. When it was finished, my system proceeded to boot into init 4, and KDE Plasma 5, with no difficulty whatsoever.

Needless to say, DKMS has earned a place in my system, and like chris.willing, probably will be depending on it for years to come. Thanks for taking over the maintenance of the SlackBuild, chris! Much appreciated!

Do you mean things like, for instance,
(and similar for sddm) from rc.4?

I recall gdm was once part of Slackware (so it could be argued that this enabling scripting is just left over from another era) but I don't think sddm was ever part of Slackware.

chris

1 members found this post helpful.

interesting question that only Pat can answer.
sddm is the choice of KDE5, is it already in Slackware 14.2?