[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 04/12] arm: parse modules from DT during early boot.



On Tue, 2012-12-04 at 12:42 +0000, Stefano Stabellini wrote:
> On Mon, 3 Dec 2012, Ian Campbell wrote:
> > > > diff --git a/docs/misc/arm/device-tree/booting.txt 
> > > > b/docs/misc/arm/device-tree/booting.txt
> > > > new file mode 100644
> > > > index 0000000..2609450
> > > > --- /dev/null
> > > > +++ b/docs/misc/arm/device-tree/booting.txt
> > > > @@ -0,0 +1,27 @@
> > > > +Xen is passed the dom0 kernel and initrd via a reference in the /chosen
> > > > +node of the device tree.
> > > > +
> > > > +Each node has the form /chosen/module@<N> and contains the following
> > > > +properties:
> > > 
> > > Wouldn't it be better to move all the modules under /chosen/modules or
> > > /chosen/multiboot?
> > 
> > Why, what's the benefit?
> > 
> > I'm happy to do whatever is more normal in DT. Is that this:
> >     /foo/bar@1
> >     /foo/bar@2
> > or
> >     /foo/bar/bar@1
> >     /foo/bar/bar@2
> > 
> > The second (which I think is what you are suggesting) seems pretty
> > redundant.
> 
> To be precise I am suggesting:
> 
> /foo/bars/bar@0
> /foo/bars/bar@1
> 
> I think it is just clearer, especially if more stuff end up inside
> /chosen. Also see how the cpus node is defined, for example.

OK.

> > > 
> > > 
> > > > +- bootargs (optional)
> > > > +
> > > > +       Command line associated with this module
> > > > +
> > > > +The following modules are understood
> > > > +
> > > > +- 1 -- the domain 0 kernel
> > > > +- 2 -- the domain 0 ramdisk
> > > 
> > > It would be nice if we could express this via the compatible property
> > > instead.
> > > So the linux kernel could be compatible "linux,kernel" and the initrd
> > > "linux,initrd", in addition to (or instead of) "xen,multiboot-module".
> > > Given that they go from the most specific to the less specific, it would
> > > become:
> > > 
> > > compatible = "linux,kernel", "xen,multiboot-module";
> > 
> > This bakes the word "linux" into the interface and would require a new
> > compatible tag and code changes in Xen for each new dom0 kernel type,
> > which I think we want to avoid. (maybe the code changes are unavoidable
> > in practice, but in principal...)
> > 
> > "xen,dom0-kernel", "xen,multiboot-module"
> > 
> > Might be an option?
> > 
> > I'm going to repost what I have without changing this bit yet.
> 
> "xem,dom0-kernel" is OK.
> However what about the initrd? Does Xen need to know that the second
> module is the kernel's initrd or is it just another opaque module from
> Xen's point of view?
> If Xen needs to know that it is an initrd I think we need to introduce
> another compatible string. Maybe the following:
> 
> "xen,dom0-initrd"

Hr, perhaps it does need to know it is a Linux initrd, or indeed that
the kernel is Linux in order to implement the necessary boot protocol.
IOW in the absence of a more generic boot protocol for ARM maybe we
can't avoid coding OS specifics into the builder :-(


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.