LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 07-13-2018, 11:40 PM   #1
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 542

Rep: Reputation: 329Reputation: 329Reputation: 329Reputation: 329
Proposal/suggestion for rc.modules


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
Code:
# Enable DKMS module rebuilding
if [ -x /usr/lib/dkms/dkms_autoinstaller ]; then
  echo "Running DKMS autoinstaller"
  /usr/lib/dkms/dkms_autoinstaller start
fi
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
 
Old 07-14-2018, 01:20 AM   #2
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 740Reputation: 740Reputation: 740Reputation: 740Reputation: 740Reputation: 740Reputation: 740
Quote:
Originally Posted by chris.willing View Post
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
Code:
# Enable DKMS module rebuilding
if [ -x /usr/lib/dkms/dkms_autoinstaller ]; then
  echo "Running DKMS autoinstaller"
  /usr/lib/dkms/dkms_autoinstaller start
fi
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.
Old 07-14-2018, 02:04 AM   #3
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235
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...

Quote:
Originally Posted by a4z View Post
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.
Not everybody owns NVIDIA graphics cards, you know...

Quote:
Originally Posted by a4z View Post
There have been quite some kernel updates in 14.2, so the usefulness of DKMS is out of doubt.
Useful? Maybe.

Out of doubt? Questionable.

Quote:
Originally Posted by a4z View Post
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
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.

Last edited by Darth Vader; 07-14-2018 at 12:06 PM.
 
1 members found this post helpful.
Old 07-14-2018, 11:07 AM   #4
upnort
Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu MATE
Posts: 859

Rep: Reputation: Disabled
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.
Old 07-15-2018, 04:35 PM   #5
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,483

Rep: Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915
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
 
Old 07-15-2018, 05:02 PM   #6
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 542

Original Poster
Rep: Reputation: 329Reputation: 329Reputation: 329Reputation: 329
Quote:
Originally Posted by kjhambrick View Post
And OBTW ... thanks to chris.willing for the SBo dkms.SlackBuild !
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
 
Old 07-16-2018, 04:46 PM   #7
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 5,877

Rep: Reputation: 3587Reputation: 3587Reputation: 3587Reputation: 3587Reputation: 3587Reputation: 3587Reputation: 3587Reputation: 3587Reputation: 3587Reputation: 3587Reputation: 3587
Quote:
Originally Posted by chris.willing View Post
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.
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.

Code:
# If our line isn't already in there, add it
cp /etc/ld.so.conf $PKG/etc/ld.so.conf.newif ! grep /opt/amdgpu-pro/lib/$DRIARCH-linux-gnu/ /etc/ld.so.conf 1> /dev/null 2> /dev/null; then
  cp /etc/ld.so.conf $PKG/etc/ld.so.conf.new
  echo -e "/opt/amdgpu-pro/lib/$DRIARCH-linux-gnu/\n\$(cat etc/ld.so.conf.new)" > etc/ld.so.conf.new
fi
 
Old 07-16-2018, 05:42 PM   #8
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 542

Original Poster
Rep: Reputation: 329Reputation: 329Reputation: 329Reputation: 329
Quote:
Originally Posted by bassmadrigal View Post
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.

Code:
# If our line isn't already in there, add it
cp /etc/ld.so.conf $PKG/etc/ld.so.conf.newif ! grep /opt/amdgpu-pro/lib/$DRIARCH-linux-gnu/ /etc/ld.so.conf 1> /dev/null 2> /dev/null; then
  cp /etc/ld.so.conf $PKG/etc/ld.so.conf.new
  echo -e "/opt/amdgpu-pro/lib/$DRIARCH-linux-gnu/\n\$(cat etc/ld.so.conf.new)" > etc/ld.so.conf.new
fi
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
Code:
include /etc/ld.so.conf.d/*.conf
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

Last edited by chris.willing; 07-17-2018 at 05:49 AM.
 
Old 07-16-2018, 06:08 PM   #9
upnort
Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu MATE
Posts: 859

Rep: Reputation: Disabled
Quote:
how about a /etc/rc.d/rc.modules.d into which SlackBuilds could put their own .conf files for additional module processing?
Great idea!
 
Old 07-16-2018, 06:32 PM   #10
ZhaoLin1457
Member
 
Registered: Jan 2018
Posts: 238

Rep: Reputation: 205Reputation: 205Reputation: 205
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:
Code:
# REQUIRE: networking syslog
# REQUIRE: usr
# PROVIDE: dns nscd
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.

Last edited by ZhaoLin1457; 07-16-2018 at 10:38 PM.
 
Old 07-17-2018, 05:27 AM   #11
briselec
Member
 
Registered: Jun 2013
Location: Ipswich, Australia
Distribution: Slackware
Posts: 74

Rep: Reputation: Disabled
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.
 
Old 07-17-2018, 05:47 AM   #12
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 542

Original Poster
Rep: Reputation: 329Reputation: 329Reputation: 329Reputation: 329
Quote:
Originally Posted by briselec View Post
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

Last edited by chris.willing; 07-17-2018 at 05:52 AM.
 
Old 07-17-2018, 08:29 AM   #13
1337_powerslacker
Member
 
Registered: Nov 2009
Distribution: Slackware64-current
Posts: 720
Blog Entries: 1

Rep: Reputation: 469Reputation: 469Reputation: 469Reputation: 469Reputation: 469
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!

Last edited by 1337_powerslacker; 07-17-2018 at 09:56 AM. Reason: Clarity
 
Old 07-18-2018, 02:17 AM   #14
chris.willing
Member
 
Registered: Jun 2014
Location: Brisbane, Australia
Distribution: Slackware,LFS
Posts: 542

Original Poster
Rep: Reputation: 329Reputation: 329Reputation: 329Reputation: 329
Quote:
Originally Posted by a4z View Post
adding init scripts for something that is not part of a distribution feels wrong.
Do you mean things like, for instance,
Code:
if [ -x /usr/sbin/gdm ]; then
  exec /usr/sbin/gdm -nodaemon
fi
(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

Last edited by chris.willing; 07-18-2018 at 02:50 AM.
 
1 members found this post helpful.
Old 07-18-2018, 09:33 AM   #15
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 740Reputation: 740Reputation: 740Reputation: 740Reputation: 740Reputation: 740Reputation: 740
Quote:
Originally Posted by chris.willing View Post
Do you mean things like, for instance,
Code:
if [ -x /usr/sbin/gdm ]; then
  exec /usr/sbin/gdm -nodaemon
fi
(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
interesting question that only Pat can answer.
sddm is the choice of KDE5, is it already in Slackware 14.2?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] [Suggestion] Linux Kernel 3.18 it's Longterm now, suggestion for Slackware Current sardinha Slackware 27 04-03-2015 05:17 PM
Research Proposal zeeshanhayat General 7 09-25-2006 03:31 PM
A Modest Proposal shane25119 General 4 09-30-2004 06:24 PM
Re: modprobe: Note: /etc/modules.conf is more recent than lib/modules/2.4.9/modules.d Andy.M Linux - General 1 01-24-2002 01:50 AM
Re: modprobe: Note: /etc/modules.conf is more recent than lib/modules/2.4.9/modules.d Andy.M Linux - Newbie 2 01-24-2002 01:40 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 09:08 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration