From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Owens Date: Sat, 03 Feb 2001 23:48:44 +0000 Subject: Re: hotplug TTD Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Sat, 03 Feb 2001 15:37:06 -0800, Miles Lane wrote: >So, are we going to attempt to use the persistent module data for any >Hotplug related development? Might this be helpful for giving some >more consistent mapping of a device node to a physical device resource >(e.g., /dev/eth0 -> the 3c575 with a particular set of device >characteristics -- memory ranges, IRQ, DMA, etc)> I would be very wary of doing anything like that. Persistent data is a good fit for user controlled settings like volume and TV tuner values, where the worst case is a wrong volume or the wrong TV channel at start up. If you use it for critical data such as IRQ then the worst case is the module does not load. It will confuse users when the data becomes obsolete and the module fails to load. It is not at all obvious where the insmod data is coming from. One option does make sense to me. Use persistent data and rmmod -e to extract the persistent data to a file. Because rmmod -e does not remove the module (it only extracts the data), hotplug can use this mechanism as a way to extract data from the module and save it. Then the next hotplug load can decide if it wants to use the existing data or not, erasing the saved persistent data before issuing modprobe. Alternatively hotplug can try to load the module twice, once leaving the persistent data alone, the second time it renames the saved data file. If one works, issue rmmod -e. If neither work, reinstate the persistent data file. _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel