From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SMoGo-000653-4D for mharc-grub-devel@gnu.org; Tue, 24 Apr 2012 18:31:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SMoGl-00064w-Be for grub-devel@gnu.org; Tue, 24 Apr 2012 18:31:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SMoGj-0001E0-5x for grub-devel@gnu.org; Tue, 24 Apr 2012 18:31:34 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:64240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SMoGi-0001Dj-QG for grub-devel@gnu.org; Tue, 24 Apr 2012 18:31:33 -0400 Received: by wibhj13 with SMTP id hj13so3419992wib.12 for ; Tue, 24 Apr 2012 15:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=eWqSjsu2nFicSYgT8VnVAzPjwDBJQrJWrkQLGeFt1as=; b=m1SfJW5mmfkQIxQPcBAKlk4rAgrGDsqTRv+931LW8gbIvjRV+LU98ZdBYQG+OTAe5Y 43OOx5oEuFRfxYQ9621NWkBhcXH7/zl9C4beRoNwwA1BzREm63qQ1qma4HDu8qPPX0RJ 3C613kqNUGbO4ytuM3gw6GWLhxdNFiQJJ9KSInHdMFJbKulPpapwu4HwuCk8c+Wz4Ojf 9uOIUhpDcLwNpgmtCmn9hGAx6Re6y/K3/fMu2+hzxZaahoCJDe2r/3J3grxCBxmkNRNn GOxU8YV+0wBQ+BcDeH9KquUqpnweeARTbTHLcFRuCnY6AcoKhKuRa3DRRllVdR+ejkSF p2lA== Received: by 10.180.24.7 with SMTP id q7mr20313540wif.11.1335306690729; Tue, 24 Apr 2012 15:31:30 -0700 (PDT) Received: from debian.x201.phnet (97-233.197-178.cust.bluewin.ch. [178.197.233.97]) by mx.google.com with ESMTPS id w10sm51392598wiy.3.2012.04.24.15.31.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 15:31:29 -0700 (PDT) Message-ID: <4F9729BE.1060105@gmail.com> Date: Wed, 25 Apr 2012 00:31:26 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: [PATCH,HURD] Fix grub-probe with userland partition support References: <4F953A3B.3000708@gmail.com> <20120423212606.GV4755@type.famille.thibault.fr> <20120423233423.GC4755@type.famille.thibault.fr> <4F966CAE.3080300@gmail.com> <20120424091915.GD4453@type.bordeaux.inria.fr> <4F967895.3010203@gmail.com> <20120424124220.GS4453@type.bordeaux.inria.fr> <4F96A85D.3040303@gmail.com> <20120424171358.GT4433@type.famille.thibault.fr> <4F9709A9.6090707@gmail.com> <20120424222110.GD29782@type.famille.thibault.fr> In-Reply-To: <20120424222110.GD29782@type.famille.thibault.fr> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig5A8A9FEA362B2DE7E2B7B181" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.171 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 22:31:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5A8A9FEA362B2DE7E2B7B181 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25.04.2012 00:21, Samuel Thibault wrote: > Vladimir '=CF=86-coder/phcoder' Serbinenko, le Tue 24 Apr 2012 22:14:33= +0200, a =C3=A9crit : >> On 24.04.2012 19:13, Samuel Thibault wrote: >>> Vladimir '=CF=86-coder/phcoder' Serbinenko, le Tue 24 Apr 2012 15:19:= 25 +0200, a =C3=A9crit : >>>> On 24.04.2012 14:42, Samuel Thibault wrote: >>>>> 0-sized indeed poses problems. >>>>> >>>>>> I'm surprised that Hurd doesn't offer a way to just ask "What does= this >>>>>> filesystem translator consume?" >>>>> Because the whole point of the Hurd is to let the user have access >>>>> to more powerful ways. A file can reside inside an iso file, which= >>>>> is stored in an ext2fs, which is stored in a file, >>>> So much GRUB can handle. >>> But how to express that to GRUB? grub_guess_root_devices only returns= >>> a series of alternative paths. See below. >> By just giving the file in question. > That will not tell you which image has to be mounted to find it. As I said: currently we assume that image is for VM use, so nothing needs to be specifically mounted. Just return image filename. When the adssumption is lifted mounting would be handled in prepare_grub_to_access_device >>>> As for the second, we're limited to what GRUB can do and so it won't= be >>>> possible to have /boot on translator from hyperspace. >>> Sure. But it can be something expressed in a complex way by the user= , >>> which can actually be reached by GRUB. That said, as I said earlier,= we >>> can ask the user to refrain himself when it's about /boot. >> We can add more translators handling as-needed. > So would it be acceptable for now as a horrible-but-works solution to > use the output of sysopts: > > ext2fs --writable --no-atime --no-inherit-dir-group --store-type=3Dtype= d device:hd1 > > and > > /hurd/ext2fs --writable --no-inherit-dir-group /dev/hd0s1 > > Drop the first parameter (translator path), -* options, and that leaves= > only the device, with additional s_device:_/dev/_ mangling. Yes it will, just we need comprehensive error messages on failure and a comment in code that it's not complete solution. >>>>> But we generally don't want to impose any syntax here, it could act= ually >>>>> be >>>>> >>>>> /opt/my/own/translator xyz >>>>> >>>>> I guess we'll have to impose some syntax anyway for whatever contai= ns >>>>> /boot, so that grub can open it itself. >>>> There should be a standartised way to get this information for any >>>> conventional FS, otherwise it makes porting programs which use this >>>> information much more difficult and in most cases results in dirty >>>> workarounds. >>> So far, I've mostly seen GRUB really needing that information. >> I suppose that databases would want to know this for optimisations. > libstore does provide the best thing for that: the actual area on the > disk, which is what was used in the very first patch already, and which= > is used for swap, etc. But that reveals to be actually too precise for= > GRUB. It's more of it not being stable. You could access all the files by blocklists but it would fail very quickly > Samuel > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig5A8A9FEA362B2DE7E2B7B181 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk+XKb4ACgkQNak7dOguQgktvwD7BLknP4tMZVUQ+qRJvIgOjOyU IXavIFOuH4VVHwoDhSMA/jZeHoBTs7EU1bSw0btEJn/RvCZlIN1jYOUyEtgBl/ui =MaYK -----END PGP SIGNATURE----- --------------enig5A8A9FEA362B2DE7E2B7B181--