aboutsummaryrefslogtreecommitdiff
path: root/migration-tcp.c
diff options
context:
space:
mode:
authorAnthony Liguori <aliguori@us.ibm.com>2011-12-12 14:29:30 -0600
committerAnthony Liguori <aliguori@us.ibm.com>2011-12-15 09:20:48 -0600
commitdc45c21f39f826e7ab4b8e86fc4d0c987fad3fb7 (patch)
treec87467c8059f86f5d8725754e7183cae1131432a /migration-tcp.c
parentf9fbd2fd0e1ffe666487a072226dd87753db66f9 (diff)
qdev: provide a path resolution (v2)
There are two types of supported paths--absolute paths and partial paths. Absolute paths are derived from the root device and can follow child<> or link<> properties. Since they can follow link<> properties, they can be arbitrarily long. Absolute paths look like absolute filenames and are prefixed with a leading slash. Partial paths are look like relative filenames. They do not begin with a prefix. The matching rules for partial paths are subtle but designed to make specifying devices easy. At each level of the composition tree, the partial path is matched as an absolute path. The first match is not returned. At least two matches are searched for. A successful result is only returned if only one match is founded. If more than one match is found, a flag is returned to indicate that the match was ambiguous. At the end of the day, partial path support means that if you create a device called 'ide0', you can just say 'ide0' as the path name and it will Just Work. If we internally create a device called 'i440fx', you can just say 'i440fx' and it will Just Work and long as you don't do anything silly. A management tool should probably always use absolute paths since then they don't have to deal with the possibility of ambiguity. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'migration-tcp.c')
0 files changed, 0 insertions, 0 deletions