Hello again<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The "native-build.sh" script in each system image launches qemu with a<br>

build control image as the third drive (/dev/hdc).  The init scripts<br>
attempt to mount /dev/hdc on /mnt, and then run /mnt/init.  If that<br>
works, it runs the build control image.  If that doesn't work, it falls<br>
back to a shell prompt.<br></blockquote><div><br>Workin exactly as u said....(Bcoz u wrote it 2 behave that way :D)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

This lets you plug a separate, device-independent filesystem into your<br>
system image and have it automaticaly take over when the emulator<br>
finishes booting. </blockquote><div><br>What i felt the best is the same image runs for all the targets<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The images I made mostly use this to build more<br>
software in an automated fashion, but really they could do anything.<br></blockquote><div><br>Know your boundaries...let it be a native compiler testing image<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

(The busybox one runs the busybox test suite, although that hasnt' been<br>
fully converted to build in a separate tree yet.)<font color="#888888"><br></font></blockquote><div> </div></div>Keep it going....will help wen i understand the scripts completely<br>Thanks<br>prazzb<br>