Re: RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string)

2010-06-16 Thread Paul Brook
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM > is the bus number, as above. > > ### Paul proposes to either drop TYPE.NUM (and require drivers to > provide bus names), or make NUM count separately for each bus type. I revised this proposal: Drop the .NUM part, an

RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string)

2010-06-16 Thread Markus Armbruster
A number of changes to qdev paths have been proposed in various threads. It's becoming harder to keep track of them, so let me sum them up in one place. Please correct me if I misrepresent your ideas. I'm going to describe the current state of things, and the proposed changes (marked with ###).

[Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string

2010-06-13 Thread Alex Williamson
This is a follow-up to my ramblock overhaul RFC series. In trying to come up with a useful name to give to a ramblock, we seemed to be leaning towards something that represents the existing qdev hierarchy rather than creating an arbitrary new namespace. I had some pointers that I should use the s