Ticket #773 (closed enhancement: community)

Opened 10 years ago

Last modified 9 years ago

Qemu should support -net usb -redir ......

Reported by: hozer@… Owned by: michael
Priority: high Milestone:
Component: qemu-neo1973 Version: current svn head
Severity: minor Keywords:
Cc: buglog@…, balrogg@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:


The qemu-neo1973 emulator should be able to fake a host with USB networking such
that the qemu user networking stack can allow a redirected connection without
needing a linux host with the dummy_hcd and gadgetfs modules loaded.

Change History

comment:1 Changed 10 years ago by balrogg@…

  • Status changed from new to closed
  • Cc balrogg@… added
  • Resolution set to invalid

qemu should not fake any part of the host, whatever is emulated is by definition
the emulation target. Qemu already provides enough interface for a separate
process to be able to fake this part of the host, although linux + dummy_hcd +
gadgetfs do exactly this and I don't think it's worth reimplementing in userspace.

If you are unable to run a linux kernel directly on your host (note that this
would cause you problems with a physical Neo1973 as well), run it in qemu, which
is cross-platform.

comment:2 Changed 10 years ago by hozer@…

  • Status changed from closed to reopened
  • rep_platform changed from PC to Other
  • Resolution invalid deleted
  • op_sys changed from Linux to All

The neo usb networking is supposed to work from both linux and windows (I am not
sure about MacOSX).

Having to (re)compile gadgetfs and dummy_hcd to be able to log into the emulated
neo via ssh seems quite silly to me. It's confusing for new users, and makes it
much more difficult and expensive to use the emulator on Windows or MacOSX. I
did get it working on my laptop, but not on my build host which is running
debian etch with a 2.6.18 kernel. (gadgetfs and dummy_hcd continously spewed errors)

It would be extremely nice to have a qemu binary package for both Windows and
OSX that can allow someone wanting to try out the openmoko device without having
to run an emulator in an emulator.

Must we close this? Can't we leave it open as an enhancement for someone in the
community to fix?

comment:3 Changed 10 years ago by balrogg@…

It would work in Windows and MacOS if they didn't lack gadgetfs support - this
lack should be compensated for in these projects instead of in qemu. Ofcourse if
someone implements a workaround in qemu (which shouldn't be difficult because it
would mainly consist of copying and pasting the kernel code into qemu) it can be
merged into qemu-neo1973 tree, but not upstream. See the problems qemu already
has with maintaining slirp in our cvs - this would add a very similar issue of
maintaining code that belongs in a separate project.

For networking, fixing the USB NIC from
http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00044.html may be
easier. Other possibilities are networking over emulated bluetooth or GPRS but
they will have the same problems of a lot of code not fitting in qemu.

comment:4 Changed 9 years ago by john_lee@…

  • Status changed from reopened to new
  • Owner changed from dodji@… to balrogg@…

Andrzej, please decide what to do with this. If we leave it to the community
please reassign to michael@…

comment:5 Changed 9 years ago by balrogg@…

  • Owner changed from balrogg@… to michael@…

Yes, it's an enhancement and it doesn't really belong in qemu-neo1973 (it's not
tied specifically to GTA01 emulation) so let's leave it open with Severity set
to "enhancement".

In the meantime Tuukkah proposed networking between host and the Neo through
pppd, which is also quite painless to establish.

comment:6 Changed 9 years ago by roh

  • Owner changed from michael@… to michael

comment:7 Changed 9 years ago by john_lee

  • Status changed from new to closed
  • HasPatchForReview unset
  • Resolution set to community
Note: See TracTickets for help on using tickets.