From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SMm8Q-0003Ng-Rh for mharc-grub-devel@gnu.org; Tue, 24 Apr 2012 16:14:50 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SMm8N-0003Mi-6T for grub-devel@gnu.org; Tue, 24 Apr 2012 16:14:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SMm8L-0001zS-2W for grub-devel@gnu.org; Tue, 24 Apr 2012 16:14:46 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:35032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SMm8K-0001w5-M3 for grub-devel@gnu.org; Tue, 24 Apr 2012 16:14:44 -0400 Received: by wibhj13 with SMTP id hj13so864102wib.12 for ; Tue, 24 Apr 2012 13:14:42 -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=PsruvQPar9k9wNzZr+yl5Xxb2w3EAWZgVfS2KHtbaYQ=; b=DFgUNxqeVOief+2GLfXHkDCIhzaIUmrawq+y0Y61oWlidMqIDnX+mlIiCHy9jcj0dC mj8HaccxSryDDBbSMSf3Xfe18a0mU9d6PlnWYU7YYao5iJcgY6hKFOELo8E6xAOXv1AD ezCRo6qqQzYE0/stc677E0YQ7lHNRuahLYpItzX6xmytJ1ec13fCWoEgBAfhUJew7ug6 uGSxCHDJIv8ywhd+5NWENpn9laECccFyvxgz33KCJzt05uyhHZFspeQpxa3OHDKZhIAv ciCDB8+6dBDerCfybDummJ6iHmmZJSVudQjGispLXTTBZNmGoNQG3b439UnobfYpbN50 LtAw== Received: by 10.216.134.19 with SMTP id r19mr13234823wei.66.1335298482597; Tue, 24 Apr 2012 13:14:42 -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 k6sm32011577wiy.7.2012.04.24.13.14.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 13:14:41 -0700 (PDT) Message-ID: <4F9709A9.6090707@gmail.com> Date: Tue, 24 Apr 2012 22:14:33 +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: <4F9532B5.9050701@gmail.com> <20120423110627.GL4755@type.famille.thibault.fr> <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> In-Reply-To: <20120424171358.GT4433@type.famille.thibault.fr> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB2102306FE835809642AE142" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.177 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 20:14:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB2102306FE835809642AE142 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: >>> Vladimir '=CF=86-coder/phcoder' Serbinenko, le Tue 24 Apr 2012 11:55:= 33 +0200, a =C3=A9crit : >>>> They have iso9660 spanning through >>>> the whole disk but all of the disk other than the first sector is >>>> in some kind of partition table to avoid it being accidentally >>>> overwritten. So even though the file itself is inside a partition, = we >>>> want the whole disk. >>> The partition itself can not be mounted? >> No, since it contains FS structures at wrong offset. > Ok. BTW sometimes partition can be mounted but contains another FS which references the same file by another name or not at all. >>> 0-sized indeed poses problems. >>> >>>> I'm surprised that Hurd doesn't offer a way to just ask "What does t= his >>>> 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. But it currently always suppose that the file will be for VM and not host use. >> We don't handle loopback automatically right now since it's not clear >> whether it's a loopback for VM or loopback used on host. > You'd need to know which files to open anyway. You don't want to browse= > all filesystems for that :) So the OS-specific function has to tell you= =2E Yes. >> As for the second, we're limited to what GRUB can do and so it won't b= e >> 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, w= e > can ask the user to refrain himself when it's about /boot. We can add more translators handling as-needed. But this problem isn't Hurd-specific. A simple GNU/Linux example is unionfs: currently we can't traverse it even if it refers to something easy. Trouble is that unionfs/translator reference "foo" can point to different files depending on circumstances and we need to follow this changes if they happen behind the grub-mkconfig back (e.g. if unionfs had kernel just in branch1 and then it was moved to branch2 we would need to handle this change without rerunning grub-mkconfig). >>> But we generally don't want to impose any syntax here, it could actua= lly >>> be >>> >>> /opt/my/own/translator xyz >>> >>> I guess we'll have to impose some syntax anyway for whatever contains= >>> /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. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigB2102306FE835809642AE142 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+XCakACgkQNak7dOguQgnpbQD/YYGHsMVmfowiUUnpGUaRpBG+ q/FH6v2at6crbniMU4sBAJgItZqFW+7s1v9GCltLb2SVBdcDzVhljHyQsK3005Fm =8zge -----END PGP SIGNATURE----- --------------enigB2102306FE835809642AE142--