Change udev in runtime (not permanent)

maziar · 2023-07-20 18:02:28

Hi

I Use udev to block the Nvidia card in my laptop :

ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x03[0-9]*", ATTR{power/control}="auto", ATTR{remove}="1"

I try to unblock this PCI card sometimes for vfio in runtime without changing the up code to

 ...  ATTR{remove}="0"

(PERMANENT not suitable )

Any suggestions?

Last edited by maziar (2023-07-20 18:03:16)

Trilby · 2023-07-20 20:06:56

maziar wrote:

I try to unblock...

You try? Does this work or not? Do you reboot after making that change? Or at least use udevadm to rescan/trigger the rule?

maziar wrote:

(PERMANENT not suitable )

Please elaborate. What does this mean?

maziar · 2023-07-21 15:29:03

Trilby wrote:

maziar wrote:
I try to unblock...
You try? Does this work or not? Do you reboot after making that change? Or at least use udevadm to rescan/trigger the rule?
maziar wrote:
(PERMANENT not suitable )
Please elaborate. What does this mean?

1. Yes, it works without calling udevadm, but as described need to change the file (then it is PERMANENTLY)

2. I search for ways to change this udev temporarily without changing the udev rules file. Currently, I do it manually.

Last edited by maziar (2023-07-21 15:30:04)

Trilby · 2023-07-21 16:23:19

I'm still confused about your use of the word "permanently", but it sounds like changing the file works, but you just don't want to change the file, is this correct?

What's wrong with changing the file, e.g.

sed -i '/ATTR{vendor}=="0x10de"/s/\(ATTR{remove}=\)"[0-9]"/\1"0"/' /etc/udev/rules.d/RULENAME.rules
# run command with remove=0 here
sed -i '/ATTR{vendor}=="0x10de"/s/\(ATTR{remove}=\)"[0-9]"/\1"1"/' /etc/udev/rules.d/RULENAME.rules

Or perhaps just have two versions of the rule file (one with each value) and (re)symlink as needed, e.g.:

## initial setup (only done once):
cd /etc/udev/rules.d
echo 'ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x03[0-9]*", ATTR{power/control}="auto", ATTR{remove}="1"' > RULENAME.on
echo 'ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x03[0-9]*", ATTR{power/control}="auto", ATTR{remove}="0"' > RULENAME.off
ln -s RULENAME.rule RULENAME.on

## toggle usage (run each time you want to swtich off):
ln -s /etc/udev/rules.d/RULENAME.rule /etc/udev/rules.d/RULENAME.off
# do something here with alternative rule
ln -s /etc/udev/rules.d/RULENAME.rule /etc/udev/rules.d/RULENAME.on

seth · 2023-07-21 16:28:40

What do you mean by "temporarily"? That's not a thing.

Add a rule w/ higher priority, reload the rules, do your thing, remove the rule you added, reload the rules again.
Or sed the relevant rule, reload teh rules, do your thing, sed-revert the edit, reload the rules again.

Edit: F5xx

Last edited by seth (2023-07-21 16:29:06)

maziar · 2023-07-21 16:59:32

Sorry for the bad English :

First, You got it right.
Why change the file not suitable for me? Because If I need back GPU by changing a rule file, I need a back change before shutdown!

"temporarily" ... Try to find a way to override the udev rule without changing the file, and it is nice because If I reset Linux back to my defined default rules ... like a local variable in the bash terminal!

Adding a rule w/ higher priority with & without udevadm does not override my last rule! I don't check with restart because this is not suitable.

Last edited by maziar (2023-07-21 17:07:12)

Trilby · 2023-07-21 17:25:26

Changing the file is not really relevant to whether or not this is "temporary" or "permanent".

Imagine there was a way to change the setting without editing the file. If you change the setting, run your unblocked program, and then forget to change it back, you're in the same situation.

Whether or not you edit the file, you still need to remember to change your setting back when you are done. But this is what scripting is for. Use a script that changes the setting (by editing the file) then runs the program you want to be "unblocked" and then change the setting back again just as I provided examples of in my previous post. More specifically, create the following script:

#!/bin/sh

ln -s /etc/udev/rules.d/RULENAME.rule /etc/udev/rules.d/RULENAME.off

"$@"

ln -s /etc/udev/rules.d/RULENAME.rule /etc/udev/rules.d/RULENAME.on

Call that script something like "use_nvidia" and store it in your PATH. Then when you want to run a program with nvidia unblocked you just use this wrapper script:

use_nvidia mycoolprogram --option=foo argument1 argument2

EDIT: although now having actually looked at what were doing I can't help but suspect you are reinventing the wheel. Isn't this what tools like prime-run are for? I really don't know as I've never had / used nvidia myself, but this use-case seems explitly covered in the hybrid graphics wiki page(s).

Last edited by Trilby (2023-07-21 17:30:44)

seth · 2023-07-21 19:44:59

You could have a rule with *actually* higher priority that's a symlink to some tmpfs location, this way a reboot will lose the rule.
The superseeding rule mus also ensure that the other one is skipped. The easiest way is to have the main rule in /usr/lib and shadow it w/ the other in /etc.

Or you use service that sed-fixes the rule during the boot.

OP wrote:

I try to unblock this PCI card sometimes for vfio in runtime without changing the up code to

He wants to generally disable the device (probably to, though not sure whether that'll actually save power, might have the opposite effect) but conditionally make it available to vfio to pass it to some virtual machine.

maziar · 2023-07-21 20:02:45

He wants to generally disable the device (probably to, though not sure whether that'll actually save power, might have the opposite effect) but conditionally make it available to vfio to pass it to some virtual machine.

True, also note this way sure DisplayManager & desktop & ... don't use it and also 10W power saved!
Then prime far as my need ...

But I don't understand the upper priority did not work for me 999 in /etc/... or /lib/... is not any help!
I MUST edit the last rule to work!

thanx for Trilby's way: try your way tomorrow

seth · 2023-07-21 20:05:13

Is your native tongue covered by deepl.com ?

maziar · 2023-07-21 20:24:47

seth wrote:

Is your native tongue covered by deepl.com?

Also, my local (default) language, for some reason not very good!
but your answer is NO, but use another translator, and sure same as my lang is not very good

Arch Linux

#1 2023-07-20 18:02:28

Change udev in runtime (not permanent)

#2 2023-07-20 20:06:56

Re: Change udev in runtime (not permanent)

#3 2023-07-21 15:29:03

Re: Change udev in runtime (not permanent)

#4 2023-07-21 16:23:19

Re: Change udev in runtime (not permanent)

#5 2023-07-21 16:28:40

Re: Change udev in runtime (not permanent)

#6 2023-07-21 16:59:32

Re: Change udev in runtime (not permanent)

#7 2023-07-21 17:25:26

Re: Change udev in runtime (not permanent)

#8 2023-07-21 19:44:59

Re: Change udev in runtime (not permanent)

#9 2023-07-21 20:02:45

Re: Change udev in runtime (not permanent)

#10 2023-07-21 20:05:13

Re: Change udev in runtime (not permanent)

#11 2023-07-21 20:24:47

Re: Change udev in runtime (not permanent)

Board footer