John Sonnenschein wrote: > so, speaking of QEmu... > > QEmu is IMO the ideal solution since it would allow anyone to wander > off with the code and a working target to help out. > > Other option I thought of was that at the Dev summit there was an ODW > hooked up to be powered on by ethernet. Something like that with a > terminal server hooked up as well posted somewhere public might be an > idea as well. > > For example if people could reserve time on the ODW to run things & be > given an easy way to lay down a tarball of the boot stuff ( nfsroot and > tftpboot ) and have at it for a few hours
What John describes is pretty much how we have been developing here. We have in our lab host machines that have an ODW target attached. We have a network based power switch that we telnet into that can power cycle or reset the target. Each host machine has a secondary ethernet port that the targets sit on. We ssh into the box, fire up the tip session and boot the target. It is done on a shared basis between remote developers as you describe. So right now we are in the process of building 2 more such servers that we plan will be externally accessible, one to be hosted by Dennis (he promised), the other by someone yet to be named. We were trolling for ODW systems to send with these. We have 2 bare ODW boards that we could part with but they have a problem of incorrect MAC addresses on power-on boot. Basically they won't respond and have been trying to figure out with Genesi how to get them functional. (John, this is why we haven't sent you one by now, sorry) Timelines are a bit hazy for all this to happen but hopefully in the next few weeks. We also believe we are very close to having init and sh up on the ODW. Of course all of the code out on the svn repo is current, and the tools just got updated. Others could then build and test bits and pieces of cmd and other parts of the tree. We certainly need a parallel path for community development that is cost effective and obtainable. QEMU has both of those attributes, but we are working for the best short-term solution which probably is shared access to ODW targets on externally accessed build environments. Tom
