From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary_Lerhaupt@Dell.com Date: Mon, 16 Sep 2002 22:54:50 +0000 Subject: RE: Did you try devlabel 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 Yes, this approach is reasonable. The differences between implementing devlabel for 2.4 and 2.5 should be negligible. I simply need to add some code to check driverfs for the UUID before I go using the methods that I currently do for 2.4. Since I suspect working with driverfs will only necessitate reading a file off in some directory somewhere, making this change should be *easy*. As far as hotplug's direction for 2.5, its really just a matter of where to put the devlabel restart command. In my mind, I see devlabel as an e2label replacement (good feedback permitting) in which all linux boxes use it in the same manner. Some convention needs to be determined for naming symlinks but once an agreed upon standard is set, start using the symlinks completely within fstab. As my original post states, though, I may need to add some code to comment out references in fstab in the event that the symlink does not exist (which I think is the better alternative to having your system fail to boot because of this). I actually intend on seeing how all this works with LVM which I have not tried yet. I am sure there are other management tools to consider but as all we're really working with here are symlinks, any good management tool should be able to handle it. Its all just a matter of running /sbin/devlabel restart just before you kick off the manager to ensure that all your symlinks point to the right place. Gary -----Original Message----- From: David Brownell [mailto:david-b@pacbell.net] Sent: Sunday, September 15, 2002 6:52 PM To: Greg KH; Gary_Lerhaupt@exchange.dell.com Cc: Linux-hotplug-devel@lists.sourceforge.net Subject: Re: Did you try devlabel The hard question is how, and my preferred answer would be to focus all user mode tools/training/docs on what'll be the 2.5 solution ("disk" hotplug), with the 2.4 based solution mostly a "workalike" or even backport. Certainly "evolve together" so the end-user (and sysadmin) experience isn't of two rather divergent solutions, but just one (that likely works better on 2.5 systems but behaves also on 2.4). Sounds to me like a 2.5ish start isn't that far away, so a short delay seems reasonable to me. So far as I can tell, "devlabel" is in that interesting stage where it's not got that many users (yet) and so it's easy to change based on experience/feedback ... and we really ought to seek that feedback and use it to improve both 2.4 and 2.5 based systems. So I'll install devlabel and run it myself for a while. And I encourage other folk to do so, and submit feedback to this list over the next month or so. At which point I think it'll be more practical to decide in detail what the next steps are. Gary, can you work with that approach? And in any case, could you provide a short email describing how devlabel would work on different kinds of Linux systems? I have in mind a range, including desktop, small server, larger servers, and so on. Aren't there other volume management tools a "devlabel" would need to play with? - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ 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