From: "Gerald V. Livingston II" <gerald.hotplug@sysmatrix.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev not running new rules
Date: Mon, 13 Aug 2007 07:06:27 +0000 [thread overview]
Message-ID: <4115.65.170.133.237.1186988787.squirrel@webmail.sysmatrix.net> (raw)
In-Reply-To: <1186927115.3225.10.camel@tigger>
Peter Gordon said:
>> > > > The rule z19_persistent-anet.rules is:
>> > > >
>> > > > PROGRAM="/var/www/lib/produce_persistent_rules.pl"
>> > > >
>> > > > The object of the program is to rename one of the NICs, and simply
>> produces a rule
>> > > > SUBSYSTEMS="pci", KERNELS="0000:09:01.0", NAME="ctl"
>> > > >
>> > > > It runs a Perl program that creates the file
>> ../persistent-net.rules.
Kay Siever said:
>> You need to apply the result of the rule creation in the same event,
>> with the same rule that created the rules file for future events. Just
>> look at the standard solution for persistent network interfaces that
>> comes with udev, which probably just solves your problem anyway, or what
>> do you miss from it?
Peter Gordon said:
> My problem is this. I need to create the rules file at boot up since the
> devices available may change from boot to boot, and the PCI addresses
> are not guaranteed to be the same.
>
> So I need to create the rules file and then get those rules run.
>
> I had a look at the persistent network interfaces but I can't see how
> that helps, since the rules are already extant.
What does your perl program DO to get the info to write into the new rules
file? It obviously somehow knows it needs to write "SUBSYSTEMS="pci",
KERNELS="0000:09:01.0"" into the file.
Rather than writing that to a file, USE it to name the device.
Have it spit the PCI slot info into an environment variable the way the
other persistent rules do then use that var in the naming rule.
Now, I HONESTLY don't know if an environment variable can be used on the
right side of an "=" but what I've typed below looks reasonable if it
can.
If I'm way off base I'm sure the fine folks on this list will explain a
more proper way to use an ENV{VAR} that your perl program has made
available. I'm not trying to write the rule, just point in the right
direction.
SUBSYSTEMS="pci", KERNELS=ENV{CTLCARD}, NAME="ctl"
If ENV{CTLCARD} can't be used to the right of = then you have to think
about what your perl program is using to identify the correct card and use
THAT in the rule:
SUBSYSTEMS="pci" ENV{IDENT}={what perl uses to find the card}, NAME="ctl"
You have to find a way to make your perl program write identifying info
for all of the cards into the environment the way scsi_id writes drive
serial numbers into the environment, then use something from that list to
grab the right card. You may have to poke around in the scsi_id source and
write something similar for your NIC problem.
All rules are read into memory when udev loads at boot time then never
again. Run udevtest against a device to see it in action.
Gerald
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2007-08-13 7:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-12 13:58 udev not running new rules Peter Gordon
2007-08-12 14:10 ` Marco d'Itri
2007-08-12 14:19 ` Kay Sievers
2007-08-12 19:03 ` Peter Gordon
2007-08-12 19:28 ` Kay Sievers
2007-08-12 19:39 ` Peter Gordon
2007-08-13 7:06 ` Gerald V. Livingston II [this message]
2007-08-13 11:09 ` Bryan Kadzban
2007-08-13 11:38 ` Kay Sievers
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=4115.65.170.133.237.1186988787.squirrel@webmail.sysmatrix.net \
--to=gerald.hotplug@sysmatrix.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.