Could you elaborate more on why this is necessary and what's the use case? Asking because I never used servod like this.

We already have that mechanism.

1. You can name servo soraka and hammer by put this in ~/.servodrc in chroot
# name serial-number port-number board
soraka, xxxxxx-xxxxx, 9900, soraka
hammer, yyyyyy-yyyyy, 9901, hammer

2. Route command to soraka or hammer via "-n" argument in dut-control


I think this solution is already good enough and "-n" is cleaner than prefix every command with hammer_

@#1, the usage in this case is for detachables where there's an individual servo connected to both the lid (soraka) & base (hammer) which presumably are also connected via their prescribed interface (USB) such that we'd want to avoid doing certain things to one w/o the other knowing about it.


@#2, agreed that mechanism should provide a means to join lid & base accordingly.

Thanks for #2, I hadn't looked at multiservo logic yet. 
We had a quick chat about this today, and the concern that Waihong had (and feel free to correct me if I'm explaining this wrong) is that right now the faft pipeline and lab also relies on this assumption that there is one 'servod' instance per device, one server to talk to. So -n just replaces the need for a -p parameter, but ultimately you still don't have one server to talk to.
https://chromium.googlesource.com/chromiumos/third_party/autotest/+/master/server/hosts/servo_host.py#173
So it made sense to me to honor that assumption by having a sort of muxing-server that handles the forwarding & command exposure. How exactly we do that I'm not sure yet. Maybe there's a much cleaner way than the prefixes as Opal pointed out to do the routing.

So far we identified the following use cases that right now use complicated logic:
- controlling base and lid with one servod instance
- controlling base and lid where both are micro servos attached to a v4
- v4's post_init where we make assumptions on the order of config files being loaded
- flash_ec with the v4_and_micro setup, where we want to be able to flash the lid and base ec

The other alternatives would be to leverage command routing in dut-control either by using servorc file, or other means, and rewriting the autotest pipeline to not use a server proxy, but to issue dut-control commands on the cmdline, or create servo_client instances on the fly.

Waihong already added the support for one servod process enumerating both base + lid. It's what I'm using to write hammer tests.
Setup:
Servo v4, with ccd on lid and uservo on base. 
'sudo servod -b soraka' brings up controls with hammer_blah for the uservo. If only base/lid is connected it defaults to the controls without a prefix. 
However, if base ec fw is bricked, then the hammer controls don't enumerate (with both base + lid connected). There's another bug to fix this.

We also added support to flash_ec to recognize when a base is connected and look for 'base_' controls. Patch will be uploaded soon.
https://chromium-review.googlesource.com/#/c/chromiumos/platform/ec/+/977322/

#5: Right, but:

 a. The flash_ec patch looks quite terrible
 b. hammer_servo_type is currently broken (see patch)
 c. servod --subboard parameter (b/76185690) will not be very easy to generalize

For staff FAFT, given the time constraints, we can still go with the current approach, but it'd be nice to think if we can do better in the long run.

Pretty sure everyone here is added to that document, but design-doc for the upgrade is at go/servoarch

De-prioritizing to '3' given 'available' status & removing milestones accordingly.  If you disagree please mark 'untriaged'.