From: Andrei Borzenkov <arvidjaar@gmail.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev syntax and features
Date: Fri, 19 Oct 2018 04:27:06 +0000 [thread overview]
Message-ID: <a0916533-f152-19b7-ec04-4d3cdfc69a0c@gmail.com> (raw)
In-Reply-To: <04a28467-5e2d-238f-8812-29ba4f34311c@telus.net>
17.10.2018 23:06, Greg пишет:
> Hello all.
>
> I have a few questions about udev.
>
> I have tried the net for several hours/days, but much of the udev
> documentation out there is over 5 years old and I have had no lucuck
> with the following questions:
>
> Udev. Q1. is it case sensitive? i.e. is kernel="sd?*" allowed as a
> synonym for KERNEL="sd?*"
>
It is case sensitive.
> Udev Q2. What does UDEV define as a "long running process"? Are
> there some docs or a udevadm cmd that will report udev compile time
> options? A config file that specs that? a systemd unit file that
> specs that?
>
Default is 3 minutes. It can be changed with udevd argument or kernel
command line. Note that it applies only to external (non-builtin) commands.
> Udev. Q3. Would a command like: systemctl set-environment
> GKH="Gregory the Great" qualify as long running? (it takes about
> 0.132 secs)
>
Should not unless connection hangs.
> Udev Q4. Could ANY list variable that can be modded with += have TWO
> (or more) new terms added to it?
>
> such as say SYMLINK+="/media/%k","/mnt/%k" ?
>
As far as I know everything after "+=" is treated as single value which
gets added to list of values of this "variable". Where have you seen
example of such usage? You would need two "+=" statements with different
values. Your example would fail with invalid syntax (unknown keyword
after comma).
> Udev Q5. Similar to the above I would like to have
> RUN+="/path/to/Somecmd %k %n","/path/to/Someothercmd $foo" in some
> rule. is that OK?
>
See above. You need two "RUN+=" statements. Note that timeout is applied
to each individual command, not to overall execution time. At least if I
interpret code correctly.
> Udev. Q6. Is RUN guaranteed to be last? so that PROGRAM will set the
> var RESULT before RUN starts its stuff?
>
Yes, RUN are started after all other rules have been processed. I am not
aware of formal design specification, but changing this would have quite
some compatibility impact.
> Udev. Q7. At what point does SYSTEMD_WANTS take effect? How would I
> ensure that say my PROGRAM had set RESULT before the SYSTEMD_WANTS
> magic happened?
>
SYSTEMD_WANTS is evaluated by systemd when it gets notified by udev
about device event. This notification is sent by udev after kernel event
processing has been completed (including after all RUN have been
executed). What follows, it should see any RESULT assignment done as
part of rules processing.
Note that you need to save RESULT in some environment variable to be
accessible.
> Udev. Q8. IMPORT and RUN and PROGRAM all have a "type" option one of
> which is "builtin" which refers to bultin cmds. where do I get a list
> of such builtins? there is nothing in man udev.
>
I do not think such list exists. You may want to direct your question to
systemd list where udev development happens now.
prev parent reply other threads:[~2018-10-19 4:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-17 20:06 udev syntax and features Greg
2018-10-19 4:27 ` Andrei Borzenkov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a0916533-f152-19b7-ec04-4d3cdfc69a0c@gmail.com \
--to=arvidjaar@gmail.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).