How to get deep information on different modules?
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
I am following this guide: https://trisquel.info/en/wiki/optimizing-battery-time
and there is a neat tip/trick about "Blacklist kernel modules".
But how to find out what the modules actual are, which component(s) they are made for and what they do?
The guide says "If you want a very terse info about a module, you can
$ sudo modinfo modulename
".
But if I for example do: $ sudo modinfo ufs
I only get this:
"filename: /lib/modules/4.13.0-36-generic/kernel/fs/ufs/ufs.ko
license: GPL
alias: fs-ufs
srcversion: F6ABBA92046E490492C24FD
depends:
intree: Y
name: ufs
vermagic: 4.13.0-36-generic SMP mod_unload"
Which doesn't tell me anything.
I've searched the web for how to open .ko files, but to no avail.
Does anyone in here have more information about this matter?
Well, you've certainly opened a can of worms.
"I've searched the web for how to open .ko files, but to no avail."
Those are compiled files not the source code.
Most anything in the kernel can be compiled as a built-in thing or as a module so your question also kinda touches on how a given kernel was configured.
If you go into your /boot directory you should see a config-something file If you open it you'll find lots of CONFIG_SOMETHING=something.
An example in there:
CONFIG_ATH9K=m
Means that the ath9k driver was built as a module (as opposed to a built-in thing.)
And this means that different people's kernels can be different, depending on what kernel configuration was used to build it.
So, to continue down this rabbit hole, it would also be good to read up on configuring the Linux kernel.
I share configs I use in the kernels I build. You can get them:
sudo apt install git
git clone https://jxself.org/git/kernel-configs.git
You can then edit away:
sudo apt install libncurses-dev
wget http://linux-libre.fsfla.org/pub/linux-libre/releases/4.17-gnu/linux-libre-4.17-gnu.tar.xz
tar xf linux-libre-4.17-gnu.tar.xz
Copy the desired configuration over and name the file ".config" (without the quotes.) Kernel configs are both processor specific (so a .config for 32-bit Intel CPUs will be different from 64-bit Intel and will be different from ARM...) and also version-specific because each major kernel release will have changes stemming from new features added and etc. If you use an old one and type "make oldconfig" it will actually upgrade the old config by prompting you with changes that have happened since then and what you want to do (built-in, module, disabled, etc.)
Anyway, continuing with the example:
cd linux-4.17
make nconfig
Now you're able to see things and edit away. You can use the arrow keys to move up/down to move around within menus and left/right along with enter to select things.
Anyway, if you notice there are helpful things along the button where you can press function keys: Help, SymInfo, etc. I encourage you to explore those options. They apply to the thing you have currently selected on the screen.
So -- continuing on with my CONFIG_ATH9K. What is that? If you press F8 for SymSearch you can look for it. This is useful in case you know that name (CONFIG_ATH9K) but not where it is inside that nest of menus.
You'll see some stuff:
│ Symbol: ATH9K [=m]
│ Type : tristate
│ Prompt: Atheros 802.11n wireless cards support
│ Location:
│ -> Device Drivers
│ -> Network device support (NETDEVICES [=y])
│ -> Wireless LAN (WLAN [=y])
│ -> Atheros/Qualcomm devices (WLAN_VENDOR_ATH [=y])
│ Defined at drivers/net/wireless/ath/ath9k/Kconfig:20
│ Depends on: NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && MAC80211 [=m] && HAS_DMA [=y]
│ Selects: ATH9K_HW [=m] && MAC80211_LEDS [=y] && LEDS_CLASS [=y] && NEW_LEDS [=y] && ATH9K_COMMON [=m]
There's a lot here. It tells you the symbol name (ATH9K) which is effectively just the ATH9K part after the CONFIG_ATH9K. The module name is also important because you'll see it eventually ends up in (for me) /lib/modules/4.4.0-119-generic/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko and is one of those things that could be blacklisted.
It also tells you that it's "tristate" which means "Built-in (meaning part of the kernel itself and NOT a module) or as a module or disabled."
It also gives you the prompt. So you can think to yourself "Oh, so this is for Atheros 802.11n wireless cards." Different things have different levels of information about them. Some are more detailed than others.
It also tell you where it is in that nest of menus so that you can then go find it and change that tristate status to built-in, module, or disabled.
It tells you where it appears in the KConfig file which is probably not useful for your purposes.
The others Depends On: and Selects: I think are self-evident. If you want ATH9K support those other things will also need to be on. Think of them like dependencies.
If I jump back to your question of ufs.ko, if I go do a SymSearch for CONFIG_UFS I find:
│ Symbol: UFS_FS [=m]
│ Type : tristate
│ Prompt: UFS file system support (read only)
│ Location:
│ -> File systems
│ -> Miscellaneous filesystems (MISC_FILESYSTEMS [=y])
│ Defined at fs/ufs/Kconfig:1
│ Depends on: MISC_FILESYSTEMS [=y] && BLOCK [=y]
This tells me that it provides read-only support for the UFS file system. More information about UFS: https://en.wikipedia.org/wiki/Unix_File_System which has: "Linux includes a UFS implementation for binary compatibility at the read level with other Unixes, but since there is no standard implementation for the vendor extensions to UFS, Linux does not have full support for writing to UFS."
That seems to jive with what the info from the kernel says, that it's read-only.
You can, of course, do all of this same stuff by telling the Trisquel package manager to get the Trisquel kernel source for you. You don't have to download the mainline version of Linux-libre.
Anyway, this is probably way more information than you ever wanted.
"Anyway, this is probably way more information than you ever wanted."
Hey, I read all of this thoroughly and really appreciated it :)
Thank you :)
Also, I should say that I find the "Blacklist kernel modules" section of that wiki page questionable.
A kernel module doesn't take up any memory unless it's loaded so there is no point in blacklisting kernel modules that aren't in active use (i.e., that you can see with lsmod.) And even then all you're saving is memory, not necessarily power.
An example: Blacklisting the BTRFS kernel module won't give you any extra battery life. It just means that the kernel won't have support for that file system. If you were to plug in a drive that used that file system you wouldn't be able to read it. (And plugging in a bus-powered drive into a laptop would be the primary source of power drain, not the file system that was used on the drive.)
If you want to save the disk space you'd need to recompile the kernel with the appropriate changes and change the desired stuff to be disabled; then they're not even compiled and wouldn't exist on disk at all.
Then I propose to remove the whole blacklist thing from the wiki page, should I create a post about it? Or maybe an issue?
I don't feel comfortable with removing it from the wiki without getting at least a few more people agreeing on it.
But I also think it is important do remove it as quickly as possible if it is as you say, because overflooding the wiki with useless confusing information is not good.
I do not see how blacklisting unloaded modules could make any difference. I also doubt that disabling text session (tty) does make any measurable difference in the energy consumption.
Okay, then I'll remove the whole blacklisting thing from the wiki. If someone has strong opinions on havng it there, they can put it back up or speak up about it I think.
But when jxself do not think is has any effect, and you do not think it has any effect... I'll remove it.
- Vous devez vous identifier ou créer un compte pour écrire des commentaires