[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
advanced device mapping use case blocked by lack of "detailed specificat
advanced device mapping use case blocked by lack of "detailed specification" docs
Sun, 7 Mar 2021 13:42:51 -0500
My use case is a bit more sophisticated than the typical user (at
least in my own mind). I need to create an x86_64 linux guest that
contains 8-16 serial ttys and where the host backend is backed by some
sort of socket server. (for component data path testing in lieu of
could be something as simple as on the host:
while [ 1 ]; do date; sleep 1; done | socat - TCP_LISTEN:host:port,fork
or as complicated as a compiled socket interface binary.
Problem as I see it is that most of the qemu docs are "documentation
by example" instead of "documentation by specification": an expected
side-effect of a non-commercial colaborative endeavour.
I need to understand the available options for "-chardev socket" and
"-device usb-serial" instead of spinning my wheels for weeks on end
trying to figure out what options are relevant, or what the useful
content of those parameters would be, or what the implied behaviour
becomes when selecting those options.
specific things that are current hotbeds include properly
1) being able to consistently link host socket port to a specific
guest ttyUSBn based on something like a udev rule using the USB/SERIAL
field instead of product/vendor since all devices use the same FTDI
2) confidence that the usb-serial device is a "proper implementation"
that doesn't make limiting assumptions about things like clocal or
3) considerations regarding translating a chardev ttyUSBn to a host
socket on and maintaining unbuffered char io instead of buffered line
Let the silence become deafenning.
|[Prev in Thread]
||[Next in Thread]|
- advanced device mapping use case blocked by lack of "detailed specification" docs,
Kent Dorfman <=