advanced device mapping use case blocked by lack of "detailed specification" docs

[Kent Dorfman]

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
real hardware)

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
guest driver.
2) confidence that the usb-serial device is a "proper implementation"
that doesn't make limiting assumptions about things like clocal or
crtscts
3) considerations regarding translating a chardev ttyUSBn to a host
socket on and maintaining unbuffered char io instead of buffered line
io.

Let the silence become deafenning.