On 6/11/05, Jim C. Brown <[EMAIL PROTECTED]> wrote: > I agree. While I believe this can be worked around (given a cooperative ftpd), > having a child process for every data connection is really not worth the > trouble. It's just too ugly. Besides, not every system will have an ftpd > installed.
since we already have a 32Mb limited tftp, could we make it first read-write? at least, this would validate what's theoretically possible, and we could use this rw tftp to develop/debug the later ftp. I had a look at the code, and can't figure out where the original tftp command like 'get' and 'put' are parsed inside the tftp. Apparently, it's just a question of recognising the 'put' cmd, then open/create a file on the host matching the tftp arguments, and that'll be it. Magnus would be the best person to do this, since it's his code. Why do I still think rw tftp could be of any use ? I personally am using on XP host linux guest doing kernel compilation. Once the kernel is done, I have 2 scenario: 1) move the compiled kernel to a vfat partition, shutdown the qemu guest, use winimage to extract the kernel, launch another qemu guest to test my latest kernel 2) lauch qemu within qemu. Slow square time :( no kqemu for windows hosts yet The 3rd possibility would be to use a tftp put back to the host, and launch a second qemu guest in parallel. Christian _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
