On 07/28/2008 09:34:59 PM, Marco d'Itri wrote:
I have still not found a good solution to this problem, and it's not
practical anymore to emulate the 75-persistent-net-generator.rules
logic
in a shell script.
I'm not sure I'm on-topic here, or whether this has been
discussed before, or whether my sleep deprived brain
is entirely missing the point, but...
I've looked at the persistent-net-generator rules/scripts
(et-al) and find them a kludge. This is not (necessarily)
because they write rules, but because they attempt
to interpret the udev rule language in order to figure out
what to do. (Reading and interpreting the udev rules
they generated to do things like figure out the
next device name in the ethN sequence to choose, etc.)
It seems to me that a more robust approach would be
to instead generate a (flat file, text based) database
and have a udev rule/shell script generate the necessary
rules and then execute them every time -- with perhaps
a bit of caching thrown in somehow so that the rules
are not really re-generated every time.
The user/admin would then muck with the text file,
aka database, aka configuration file, when desiring
a change in the the persistent device mapping.
By storing state explicitly in a "database" rather
than in udev rules you open up the possibility of
additional semantics not present in the udev rules.
Maybe the introduction of new semantics (lordy!,
more complication) tailored to the problems of
persistent devices could address the issues raised?
Karl <kop@xxxxxxxx>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
