Markus Armbruster wrote: > Jan Kiszka <jan.kis...@siemens.com> writes: > >> Markus Armbruster wrote: >>> Jan Kiszka <jan.kis...@web.de> writes: >>> >>>> Avi Kivity wrote: >>>>> On 05/29/2010 11:14 AM, Jan Kiszka wrote: >>>>>>> Currently breaks down when IDs contain '/', but permitting that is a >>>>>>> bug. There may be more problems; the path lookup code is way too >>>>>>> clever. >>>>>>> >>>>>> Indeed. Less can sometimes be more. My impression is that some of the >>>>>> cleverness was motivated by lacking qtree completion for the HMP. >>>>>> >>>>> Can we disable abbreviations for QMP and only allow them for HMP? >>>>> >>>>> We can support that by adding a hidden argument to commands specifying >>>>> whether the input comes from a human or machine. Abbreviations are >>>>> dangerous if they become ambiguous; a human can recover while a machine >>>>> can't. >>>>> >>>> Both QMP _and_ HMP suffer from ambitious and inconsistent addressing >>>> schemes. Therefore, I'm more and more in favor of [1]. We just need to >>>> add command line completion for option values, something that would be >>>> beneficial for 'drive_add file=...' as well. >>>> >>>> Jan >>>> >>>> [1] http://article.gmane.org/gmane.comp.emulators.qemu/72152 >>> [1] = abolish the clever abbreviations in path lookup. I agree we >>> should do that. >> Fine. No concerns regarding overlaying IDs and path specifications as well? > > I'm fine with that. > > Calling the overlayed argument "id" is not so nice. We got a bunch of > other not-so-nice names in QMP, maybe we'll have a flag day to clean > them all up.
For this case (device_del and device_show), I think we should simply call it 'device'. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
