On 02/06/2015 10:49 AM, Daniel P. Berrange wrote: >> I'm still trying to figure out how virCommandReorderFDs() got into the >> picture (I didn't write that section of the code); when I originally >> worked on virCommand, the only way to pass fds to the child was in >> direct positions (same fd in child as in parent), not by remapping one >> fd in the parent to another position in the child, except for the three >> standard descriptors. It looks like virCommandReorderFDs was added to >> allow remapping other fds and populates the LISTEN_FDS environment >> variable with how many fds were thus mapped. So the two approaches >> don't really mix. Do we ever use virCommandPassListenFDs() on a >> virCommand that will also do raw fd passthrough? Maybe the real thing >> to do is to track at virCommand build-up time that only one of the two >> passthrough methods can be used, and fail loudly if a programmer tries >> to do both methods at once. > > Or instead of virCommandPassFD() which only takes a source FD number, > we could have added a virComandPassFDRemap which takes a source and > target FD number. That way we don't have a global "reorder FDs" concept > that can break in unexpected ways - we would only ever re-order FDs for > which an explicitly target FD was requested. But then we have to be careful that there are no collisions between inherited-in-place and reordered fds. My argument is that reordering ALWAYS ensures we don't have to worry about collisions between different registration styles, because we no longer have different registration styles. > >> Or maybe we should ALWAYS prepare to remap fds in the child, so that the >> child receives fds in contiguous order with no gaps. It might simplify >> the code base to always reorder things, and have the mapping done up >> front. That is, change the virCommandPassFD() function to return an >> integer of which next consecutive fd the child will see, or -1 on >> failure. Callers that then need to alter the command line of the child >> will have to pay attention to the return value (something a bit >> different than most virCommand build-up, which intentionally defer error >> checking to the very end), but it might be worth it. > > This might be simplest way to go - I'm just wondering if it will cause > us any other type of fun problems And it sounds like Stefan is looking to me to play with it and see what breaks. Oh well, I guess I walked into that one :) -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list