Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752028Ab2HUEro (ORCPT ); Tue, 21 Aug 2012 00:47:44 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:47777 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750902Ab2HUErk (ORCPT ); Tue, 21 Aug 2012 00:47:40 -0400 MIME-Version: 1.0 In-Reply-To: <50328258.9030800@wwwdotorg.org> References: <502EC16C.4030007@wwwdotorg.org> <20120820182254.GQ24861@google.com> <50328258.9030800@wwwdotorg.org> Date: Mon, 20 Aug 2012 23:47:39 -0500 Message-ID: Subject: Re: root=PARTUUID for MBR/NT disk signatures? From: Will Drewry To: Stephen Warren Cc: Tejun Heo , "linux-kernel@vger.kernel.org" , "cross-distro@lists.linaro.org" , Jens Axboe , Kay Sievers Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2733 Lines: 62 On Mon, Aug 20, 2012 at 1:30 PM, Stephen Warren wrote: > On 08/20/2012 12:22 PM, Tejun Heo wrote: >> Hello, >> >> On Fri, Aug 17, 2012 at 04:10:52PM -0600, Stephen Warren wrote: >>> I was considering extending the kernel command-line option >>> root=PARTUUID= to also support MBR (NT disk signatures). I was thinking >>> of a syntax along the lines of: >>> >>> root=PARTUUID=UUUUUUUU-PP[/PARTNROFF=%d] >>> >>> ... where UUUUUUUU is the hex representation of the NT disk signature, >>> and PP is the hex representation of the partition number. Like GPT, >>> /PARTNROFF could be used too if desired. >>> >>> Related, I was thinking of changing struct partition_meta_info's uuid >>> field to be a string, so that it could simply be strcmp'd against the >>> UUID value on the kernel command-line. That way, the type of the UUID is >>> irrelevant. >>> >>> Does anyone have any objection to that? >> >> Wouldn't that be able to break setups which work currently? > > I don't believe so: > > Since the newly supported UUID syntax wouldn't ever match any EFI UUID > (the lengths differ in all cases), I don't believe the new syntax would > affect behavior for any existing usage. > > Obviously, part_efi.c would be modified to initialize struct > partition_meta_info's uuid field to the appropriate string > representation of the UUID so that the str(case)cmp would still succeed > for existing command-lines. I ended up coding up that part of the change > late Friday, and the feature was certainly still working OK. Functionally, I suspect this will work fine, but I am concerned that it is a bad move from an efficiency perspective (not unfixable though). Right now, the user-supplied value is converted from string-uuid to packed-uuid. This is then memcmp'd across any and all partitions - be it 2 or 200 - across all attached storage. If we move to a pure string, then we end up needing to unpack every packed UUID at disk scan time (or search, depending on impl) rather than just the one user supplied value. Perhaps the cost is negligible on modern machines, but it seems like the wrong place to put the cost (per entry rather than per search value). I'd be happy to test out any proposed patch to see if I can measure any differences in my specific environments, but I don't know if it will slow down partition scanning for other EFI UUID users out there. Maybe the NT disk sigs could be massaged to be memcmp friendly instead of the opposite? thanks! will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/