From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Karl O. Pinc" Date: Tue, 29 Jul 2008 04:32:08 +0000 Subject: Re: generation of persistent network devices rules at install time Message-Id: <1217305928l.476l.0l@mofo> List-Id: References: <20080729023459.GA5224@bongo.bofh.it> In-Reply-To: <20080729023459.GA5224@bongo.bofh.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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 Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein