Re: [Xen-devel] [PATCH osstest 00/10] Add initial support for testing arm32 on arm servers (Calxeda Midway)

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] [PATCH osstest 00/10] Add initial support 
for testing arm32 on arm servers (Calxeda Midway)"):
> I've ended up with a bunch of Wheezy related fixes in here too, all
> mixed in I'm afraid...

Excellent, thanks.  Here's my review notes, from irc.

Ian.

16:25 <Diziet> ijc: Thanks :-).
16:25 <Diziet> I'll read them and maybe throw them in.
16:25 <Diziet> throw them in> Depends if I get a push of my switch to 3.4.y
16:28 <ijc> Thanks. I'm not totally convinced by the parameteriztion of the 
            consoles and stuff, if you have any better ideas please let me know.
16:29 <Diziet> It looks OK to me.
16:29 <Diziet> You mean the ttyS0 thing
16:30 <ijc> yeah
16:30 <ijc> if you are fine with it then great ;-)
16:31 <Diziet> That uboot thing ("New host flag need-uboot-bootstr") is a bit 
               full of magic, but it's ARM magic so I'll just take it I think.
16:31 <Diziet> Does the d-i pkgsel/include thing work on x86 ?
16:32 <ijc> it'll eventually need teaching about different arm and uboot 
            platforms. I think it'll do for now though
16:32 <Diziet> Or I guess, I mean, if u-boot-tools does not exist (which maybe 
               it doesn't on x86 squeeze)
16:32 <ijc> I thought it did, but I may be thinking of Wheezy
16:32 <ijc> there was a second transitional/dummy package now I think about it
16:33 <Diziet> "make an armhf flight" should be called "make some armhf jobs" 
               but no matter.
16:33 <Diziet> ijc: Hmm.  You might want to test that before I merge it and 
               complain.
16:33 <ijc> it was called uboot-envtools in Squeeze
16:34 <Diziet> So what happens if you mention an unknown package there ?
16:34 <ijc> I have no idea... I'll need to dig out an x86 box to test on I guess
16:34 <ijc> Or I could just make it conditiona;
16:34 <Diziet> Well, you could wait until I complain.  Right.
16:35 <Diziet> "PDU: support for xenuse controlled machines" has a mysterious 
               ipmitool rune in it which surely doesn't belong.
16:35 <ijc> oh, oops, that's peculiar to this machine
16:35 <ijc> which seems to have a oneshot pxe thing in its firmware....
16:35 <Diziet> Right
16:35 <Diziet> I think if "xenuse --on" doesn't work that means xenuse needs to 
               do the weird rune.
16:36 <ijc> xenuse --on would work though, just the system will boot from hdd 
            not pXE
16:36 <ijc> I have a feeling this is a firmware bug -- the docs suggest the pxe 
            thing should be permanent...
16:36 <Diziet> "TestSupport: Massage host props with space in them" can you 
               turn them to _ ?  Because I think we currently distinguish 
               "-"-aka-"StudlyCaps" from " "
16:37 <ijc> AH, I used - precisely so it would get further munged into 
            StudlyCps for consistency -- you don't want that?
16:38 <Diziet> Some existing property names are of the form "some-words 
               other-words"
16:38 <Diziet> - binds more tightly, in other words.
16:39 <ijc> ok
16:39 <Diziet> "ts-xen-install: wheezy has libyajl2 not 1" <- Does this work ?  
               Because qw() doesn't do $-interpolation.
16:40 <ijc> It succeeds but yajl isn't installed, I guess because the shell hid 
            the $yajl...
16:40 <ijc> For all these -- do you prefer I rebase or incrementally fgix?
16:41 <Diziet> You might as well incrementally fix, esp. since you seem already 
               to have merged.
16:42 <ijc> I can rebase -i -p if you prefer.
16:42 <Diziet> Nah.
16:42 <Diziet> Might as well have the history as you wrote it.
16:42 <Diziet> I don't think we need to stand on a nice tidy history in osstest
16:43 <Diziet> "ts-xen-build: allow per-host CONFIG_EARLY_PRINTK"   definitely 
               wrong
16:43 <Diziet> This should be done on the kernel command line.
16:43 <Diziet> Or maybe arch-specific.
16:43 <Diziet> You mustn't make the results of the build depend on the build 
               host like that.  Builds can get reused.
16:44 <Diziet> kernel command line> Which I think there should already be a 
               host property to add to.  If not there should be one created.
16:46 <Diziet> "$xenkopt" and "$kopt" in the bootloader setup code
16:47 <ijc> CONFIG_EARLY_PRINTK is a compile time option I'm afraid. It's 
            debug=y onlkly
16:47  * Diziet gets to the end.
16:47 <Diziet> How unpleasant.
16:47 <ijc> As I said in the comment, this is only really useful for standalone 
            builds
16:47 <Diziet> Surely even standalone things can build here and test there ?
16:48 <ijc> only really useful for standalone builds ... if you know what you 
            are doing
16:48 <ijc> I don't hitnk it is technically possible to make our earlyprintk 
            more flexible, it is used from before we have anything like an FDT 
            parser avaiable, from the early asm code
16:49 <Diziet> How annoying.
16:49 <Diziet> That's before the command line is read ?
16:49 <Diziet> Can it be binary-edited into the kernel image ?
16:49 <Diziet> A la that rootdev utility or whatever it used to be called.
16:51 <ijc> no, it defines asm macros which are inlined into the head.S code. 
            We can just revert that patch for oSStest, it was just conveinent 
            for me locally
16:52 <ijc> (it's start of day code which needs to be PIC and often has no 
            stack)
16:52 <Diziet> I guess we can leave it in, but can you put a comment near the 
               call to get_host_property warning about not setting it ?

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