From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aMXnM-0001DY-Uv for mharc-grub-devel@gnu.org; Fri, 22 Jan 2016 04:14:16 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMXnK-0001Cx-9R for grub-devel@gnu.org; Fri, 22 Jan 2016 04:14:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMXnJ-0003PZ-1z for grub-devel@gnu.org; Fri, 22 Jan 2016 04:14:14 -0500 Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:36514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMXnI-0003PO-M2 for grub-devel@gnu.org; Fri, 22 Jan 2016 04:14:12 -0500 Received: by mail-wm0-x235.google.com with SMTP id l65so252495011wmf.1 for ; Fri, 22 Jan 2016 01:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=aWLeiDDGotG+juqTgqtIPOi00+cy7IGKjuYDbeyci0k=; b=spstjM/VJWR/GuGrPHmm5uTiRcyY+5XjUPTMOqOhHnr6byl8suZtlwWBh3kdvrKWak 7ckxvbk+NuM/MUaaTg5hkFg2Dit/RujULGkjRNGpXo4NUOPQCBqPPJSba1Q9eEFgfRxZ RfcYD7zdxEQZWXZPaAU51pxAzFO3FlmryrBFtpLqbe07oM+MFPmiLJDK7onOVnuLYZA0 Buw3Z4fw83BnzORymoWgcWUXWGCaBrjvURsJ4d/vb3eZom557dEToD21p3sriB0qVvKK UQlm5dqSYPWUd0F3+O1niEVW6GdbhbU6ms2b6GBKImt51mTuCBhNeNHQiXvaPd1MzVE2 lNZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=aWLeiDDGotG+juqTgqtIPOi00+cy7IGKjuYDbeyci0k=; b=OTaplkeU6d1RUovqpMqMdsCVm6sqCQAddFgs7KdPywsgZHscd+fzxqPFgxBHyIM7Lx 3e9SEzLTpzT9fIXj6r7P+D1kCBMC+QjwJU1nrsDhP29Z3NT7aNtaQ68Kuk1XqZVbcvMX Gol6afbdENxZWW4fEswzrR96u5bGiTiFKggDuvOKOu7A64tSHDs08XGSPrFQc/S+/dML 3pKHcH9G6WvgvtpXVFIXVubafGdrcJfsUf2xb2JEQPMWy9LXt3WwLm03dT+BhK4n6iim SxnU59zJWX++yyc32B3P4Z04DjM0zwL696GXG8ikBIwiwBTxQQsYyynlwQXhh7b9lWh4 BZHw== X-Gm-Message-State: AG10YOSidcKYiakH3zsMDMD+tLPzjs6xBO8yvZxtJzW7Tio7NqoC0NTL9tXN4HmlPjGt7A== X-Received: by 10.194.82.199 with SMTP id k7mr2266366wjy.65.1453454051758; Fri, 22 Jan 2016 01:14:11 -0800 (PST) Received: from ?IPv6:2a02:120b:2c41:63f0:a2a8:cdff:fe64:b3b5? ([2a02:120b:2c41:63f0:a2a8:cdff:fe64:b3b5]) by smtp.gmail.com with ESMTPSA id fx8sm5029735wjb.13.2016.01.22.01.14.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 01:14:10 -0800 (PST) Subject: Re: [Xen-devel] Uniform commands for booting xen To: Ian Campbell , Andrei Borzenkov , The development of GNU GRUB References: <56449726.8090707@gmail.com> <5644C1F502000078000B455F@prv-mh.provo.novell.com> <1447348140.18450.92.camel@citrix.com> <5645A3E802000078000B495A@prv-mh.provo.novell.com> <1447408236.18450.117.camel@citrix.com> <5693B6E6.9030903@gmail.com> <1453112888.6020.109.camel@citrix.com> From: =?UTF-8?Q?Vladimir_'=cf=86-coder/phcoder'_Serbinenko?= Message-ID: <56A1F2DB.2040308@gmail.com> Date: Fri, 22 Jan 2016 10:14:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <1453112888.6020.109.camel@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4CXiqxUSHCC7gt9ibmV8dC5jU5VcWXMTO" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::235 Cc: Jan Beulich , "xen-devel@lists.xen.org" 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: Fri, 22 Jan 2016 09:14:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4CXiqxUSHCC7gt9ibmV8dC5jU5VcWXMTO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18.01.2016 11:28, Ian Campbell wrote: > On Mon, 2016-01-11 at 15:06 +0100, Vladimir '=CF=86-coder/phcoder' Serb= inenko > wrote: >> On 13.11.2015 10:50, Ian Campbell wrote: >>> On Fri, 2015-11-13 at 12:04 +0300, Andrei Borzenkov wrote: >>>>> How do you express modules other than kernel+initrd in that >>>>> scheme, without grub needing to be aware of any new addition we >>>>> may find necessary going forward? >>>>> >>>> >>>> Are modules used by Xen self-identifying? Is it enough to simply pas= s >>>> Xen kernel list of binary blobs or Xen kernel must be told what thes= e >>>> binary blobs are? If they are self identifying, why arm needs to be >>>> passed module type in the first place? >>> >>> At first Xen/ARM required the bootloader to identify, but that was >>> since >>> identified as causing madness and fixed by having Xen/ARM do as Xen/x= 86 >>> does and figure things out for itself, but I failed to communicate th= is >>> clearly and things got implemented on the grub side under the old >>> assumptions. >>> >> This changes a lot. This removes most of hurdles towards uniformity. A= re >> you ok with replacing xen_kernel/xen_xsm/... with just xen_module and >> dropping type altogether? >=20 > So ending up with xen_hypervisor followed by one or more xen_module lin= es? > That's fine with me. This bit: >=20 > @@ -203,15 +155,11 @@ prepare_xen_module_params (struct xen_boot_binary= *module, void *xen_boot_fdt) > grub_fdt_add_subnode (xen_boot_fdt, chosen_node, module_name); > =20 > retval =3D grub_fdt_set_prop (xen_boot_fdt, module_node, "compatible= ", > - module->node_info.compat_string, > - (grub_uint32_t) module-> > - node_info.compat_string_size); > + "deprecated", sizeof("deprecated") - 1); >=20 > Seems to be changing the compatibility string of hte node to "deprecate= d", > which isn't right (or at least won't work). The nodes still need to be > identified as being modules per http://xenbits.xen.org/docs/unstable/mi= sc/a > rm/device-tree/booting.txt that means "multiboot,module" (or if you ins= ist > "xen,multiboot-module"). >=20 Changed to "multiboot,module" and committed >> Do you think that it makes sense to have xen_initrd in order to have >> in-memory initrd concatenation like baremetal counterpart? In either >> case we can add it later. I'd rather not have a command than to change= >> its meaning later. >=20 > If it is useful on baremetal (and I can see that it would be) then I th= ink > it would be useful on Xen too. >=20 > Ian. >=20 >=20 --4CXiqxUSHCC7gt9ibmV8dC5jU5VcWXMTO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREKAAYFAlah8uEACgkQmBXlbbo5nOs10gD/YjnOBj2k+q50cSfb0/TLL1ZK m3c3NQ34REeS/95+uF4A/2fx8hFjegxNLgGVmafAMDMSjGoDK9sY3pYrKQ/uyBIW =UvHi -----END PGP SIGNATURE----- --4CXiqxUSHCC7gt9ibmV8dC5jU5VcWXMTO--