Hi Andrei On 26 February 2016 at 01:34, Andrei Borzenkov <arvidj...@gmail.com> wrote: > 25.02.2016 09:39, fu....@linaro.org пишет: >> From: Fu Wei <fu....@linaro.org> >> >> delete: xen_linux, xen_initrd, xen_xsm >> add: xen_module >> >> This update bases on >> commit 0edd750e50698854068358ea53528100a9192902 >> Author: Vladimir Serbinenko <phco...@gmail.com> >> Date: Fri Jan 22 10:18:47 2016 +0100 >> >> xen_boot: Remove obsolete module type distinctions. >> >> Signed-off-by: Fu Wei <fu....@linaro.org> >> --- >> docs/grub.texi | 32 +++++++++----------------------- >> 1 file changed, 9 insertions(+), 23 deletions(-) >> >> diff --git a/docs/grub.texi b/docs/grub.texi >> index 82f6fa4..0f99c50 100644 >> --- a/docs/grub.texi >> +++ b/docs/grub.texi >> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command >> @command{help} >> * videoinfo:: List available video modes >> @comment * xen_*:: Xen boot commands >> * xen_hypervisor:: Load xen hypervisor binary >> -* xen_linux:: Load dom0 kernel for xen hypervisor >> -* xen_initrd:: Load dom0 initrd for dom0 kernel >> -* xen_xsm:: Load xen security module for xen hypervisor >> +* xen_module:: Load xen modules for xen hypervisor >> @end menu >> >> >> @@ -5141,30 +5139,18 @@ verbatim as the @dfn{kernel command-line}. Any other >> binaries must be >> reloaded after using this command. >> @end deffn >> >> -@node xen_linux >> -@subsection xen_linux >> +@node xen_module >> +@subsection xen_module >> >> -@deffn Command xen_linux file [arguments] >> -Load a dom0 kernel image for xen hypervisor at the booting process of xen. >> +@deffn Command xen_module [--nounzip] file [arguments] >> +Load a module for xen hypervisor at the booting process of xen. >> The rest of the line is passed verbatim as the module command line. >> +Each module will be identified by the order in which the modules are added. >> +The 1st module: dom0 kernel image >> +The 2nd module: dom0 ramdisk >> +All subsequent modules: UNKNOW >> @end deffn >> > > Hmm ... from previous discussion I gathered that Xen can detect module > type. What if there is no initrd for dom0? How can subsequent modules be
Now , Xen detect module type by the order. (at least on ARM64). I think i386 is using Multiboot(2) protocol, so maybe this order is nothing to do with i386. so maybe we can say: ----------------------------- On ARM64, each module will be identified by the order in which the modules are added. The 1st module: dom0 kernel image The 2nd module: dom0 ramdisk (optional) All subsequent modules: UNKNOWN On i386, the modules will be identified by Multiboot(2) protocol. ----------------------------- Is that better? please correct me if I miss something. > loaded then? > >> -@node xen_initrd >> -@subsection xen_initrd >> - >> -@deffn Command xen_initrd file >> -Load a initrd image for dom0 kernel at the booting process of xen. >> -@end deffn >> - >> -@node xen_xsm >> -@subsection xen_xsm >> - >> -@deffn Command xen_xsm file >> -Load a xen security module for xen hypervisor at the booting process of xen. >> -See @uref{http://wiki.xen.org/wiki/XSM} for more detail. >> -@end deffn >> - >> - >> @node Networking commands >> @section The list of networking commands >> >> > -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel