From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YENAw-0008Uf-V7 for mharc-grub-devel@gnu.org; Thu, 22 Jan 2015 14:12:18 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YENAu-0008UU-5L for grub-devel@gnu.org; Thu, 22 Jan 2015 14:12:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YENAs-0001Qa-SX for grub-devel@gnu.org; Thu, 22 Jan 2015 14:12:16 -0500 Received: from mail-we0-x229.google.com ([2a00:1450:400c:c03::229]:49468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YENAs-0001QV-L1 for grub-devel@gnu.org; Thu, 22 Jan 2015 14:12:14 -0500 Received: by mail-we0-f169.google.com with SMTP id u56so3634072wes.0 for ; Thu, 22 Jan 2015 11:12:14 -0800 (PST) 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:content-type; bh=bY+CCapV0V8+3maYBshhle+WsO1v0q70pk7fARMpIGw=; b=KZwToLesaVZO7GKRpnsRbfN8JbW0tQTtqTl72+/Y/hchJwgXqVmoEG5fh8d88JxOCy WDzY0iK/JpcRw0Lxc/Byfz1a1whHGhBZSi/BkaMIs3YKr/pPZI0SleGoVEGbZ/MMclxU Dnb0WFB6SZnIHpWEW+Erg7gPFgpxurz49tNKtrk51t8RrKUdDPV2PbeW3hZ9SQDerAXi bu6kKaJGW3o6Vg6yUXhrKfuf+IRLCet6KtIwGJLw+xxqQ6DeKb1zvQour2oJn63IhCU4 47jqZ1TWIMAEY9Mp5EOQJmg92HzyiNQ3s1F78TuslTm8/lxtyJnXEMXXWA20qmE0rmCm xTIw== X-Received: by 10.194.110.69 with SMTP id hy5mr5935794wjb.121.1421953934091; Thu, 22 Jan 2015 11:12:14 -0800 (PST) Received: from ?IPv6:2620:0:105f:fd00:c6e9:2fff:fe57:96ed? ([2620:0:105f:fd00:c6e9:2fff:fe57:96ed]) by mx.google.com with ESMTPSA id dn2sm4189856wib.14.2015.01.22.11.12.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jan 2015 11:12:13 -0800 (PST) Message-ID: <54C14B8C.1090700@gmail.com> Date: Thu, 22 Jan 2015 20:12:12 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Patch to fix kldstat(2) / dtrace when booting FreeBSD References: <54B0025E.4020407@pcbsd.org> <20150111212748.153e7951@opensuse.site> <54B3F245.6020708@pcbsd.org> In-Reply-To: <54B3F245.6020708@pcbsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="439irTc4SukVHEAvb26wq3aMEmDqlXsTK" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::229 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: Thu, 22 Jan 2015 19:12:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --439irTc4SukVHEAvb26wq3aMEmDqlXsTK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12.01.2015 17:11, Kris Moore wrote: > On 01/11/2015 13:27, Andrei Borzenkov wrote: >> =D0=92 Fri, 09 Jan 2015 11:31:26 -0500 >> Kris Moore =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >>> The following patch fixes an important issue when booting FreeBSD. >>> FreeBSD's kldstat(2) function expects that the full pathname will be >>> provided to kernel / modules. The current GRUB was striping this out = and >>> only leaving the filename itself. This broke dtrace and other things >>> which used the full pathname to locate the kernel or modules on disk.= >>> >>> The attached patch fixes this behavior. >>> >>> diff --git a/grub-core/loader/i386/bsd.c b/grub-core/loader/i386/bsd.= c >>> index 8f691e0..fb47969 100644 >>> --- a/grub-core/loader/i386/bsd.c >>> +++ b/grub-core/loader/i386/bsd.c >>> @@ -415,11 +415,15 @@ grub_freebsd_add_meta_module (const char *filen= ame, const char *type, >>> grub_addr_t addr, grub_uint32_t size) >>> { >>> const char *name; >>> - name =3D grub_strrchr (filename, '/'); >>> + /* Don't strip the full path, some FreeBSD functionality, such >>> + * as kldstat(2) / dtrace, rely on this. Instead we only need to re= move >>> + * any ZFS dataset information first. */ >>> + name =3D grub_strrchr (filename, '@'); >> What if filename itself contains '@'? Is it possible? >> > I don't see anything in the manpages that explicitly prohibits certain > characters, however, all the modules FreeBSD uses, and ones in ports, > don't use any special characters of any kind. I suspect that having a > module with a '@' in it would cause other potential breakage as well. >=20 * dataset name never contains @. So it should be grub_strchr. * You don't handle the case when name doesn't contain @ * Disk name needs to be stripped first. * This code is ZFS specific. You need a separate code path for other filesystems. >=20 >>> if (name) >>> name++; >>> else >>> name =3D filename; >>> + >> Please, could we avoid unrelated formatting changes? >> >>> if (grub_strcmp (type, "/boot/zfs/zpool.cache") =3D=3D 0) >>> name =3D "/boot/zfs/zpool.cache"; >>> =20 >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >=20 > Here you go, without the formatting changes. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 --439irTc4SukVHEAvb26wq3aMEmDqlXsTK 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 iF4EAREKAAYFAlTBS4wACgkQmBXlbbo5nOvs6QD9GE/pGlZCtPEAmWAnQ7WBW6zF KXOWE+qthVirJGc7bx4A/AjPPlRiOaR6gkfEqlcNvFz0Yv7c6PPNYU2Vlk6lbHDR =WtOk -----END PGP SIGNATURE----- --439irTc4SukVHEAvb26wq3aMEmDqlXsTK--