On Aug 27, 2015, at 1:39 AM, Markus Armbruster wrote: > Programmingkid <programmingk...@gmail.com> writes: > >> On Aug 26, 2015, at 6:08 PM, John Snow wrote: >> >>> >>> >>> On 08/26/2015 05:48 PM, Programmingkid wrote: >>>> >>>> On Aug 26, 2015, at 2:45 PM, Peter Maydell wrote: >>>> >>>>> On 26 August 2015 at 18:16, Programmingkid >>>>> <programmingk...@gmail.com> wrote: >>>>>> That is assuming they have the time and/or the interest in >>>>>> solving this problem. I >>>>>> suppose giving them some time to respond would be reasonable. I'm >>>>>> thinking if >>>>>> no consensus has been reached in one weeks time (starting today), >>>>>> we turn to >>>>>> Peter Maydell for the answer. Hopefully he will just pick which >>>>>> of the patches he >>>>>> likes the best. Judging by how long this problem has been ongoing, >>>>>> someone >>>>>> pick the answer is probably the best we can expect. >>>>> >>>>> This is the kind of thing I strongly prefer to leave to the >>>>> relevant subsystem maintainer(s). My opinion is not worth >>>>> a great deal since I don't have a strong familiarity with >>>>> this bit of QEMU. >>>> >>>> It looks unreasonable to assume any consensus can be reached over this >>>> issue. >>>> The easy thing to do is to just let each maintainer deal with this problem >>>> his own way. >>>> >>> >>> What feedback was there that seemed insurmountable? Last I talked to >>> Jeff Cody he said there was no "overwhelming pushback" against his >>> patches, just a list of concerns. >> >> Markus Armbruster sent me four different threads each trying to solve >> this problem. >> Some of those threads were many years old. The situation is the same then as >> it >> is now. There is no judicator to decide how this problem is to be >> solved. Expecting >> all the maintainers to agree on one patch is unrealistic. >> >>> This doesn't sound like a dead end so much as it sounds like we haven't >>> planned the feature enough yet. >> >> The threads did have some really good patches that did seem to solve >> the problem. >> I could send you the threads if you haven't read them yet. > > Back then was then and now is now. I understand your impatience to get > stuff done, but things may have changed, people may have changed. We > really need to talk it over one more time. If we can reach rough > consensus, swell. If we can't, we can still narrow the scope to > subsystems where we can. > >>>> Markus: >>>> I know you really wanted a single ID generating system, but it just >>>> isn't going >>>> to happen. I will make a patch that would only effect USB devices. All >>>> other >>>> devices would be untouched. At least the device_del problem will be solved. >>>> >>> >>> I think this is being unnecessarily hasty. We should make sure that an >>> auto-generated ID system does not create problems for other areas of >>> code before we rush ahead with one to solve a single problem. > > Right. > >> I would make sure my patch only affects USB devices. No other systems >> would be affected. > > Device IDs are in the qdev/QOM subsystem, so that's the subsystem you > have to attack should QEMU-wide consensus remain elusive. The USB > subsystem is merely a user of qdev/QOM here.
I could make a patch that detects if the device is a USB device, then give it an ID if none was specified. This patch would have no affect on other non-USB devices. We could implement this patch for the time being. Then *if* an universal device ID system does become available, then just start using it instead. > >>> Let's give the universal approach some more time before we jump to the >>> conclusion that it's impossible. >> >> I suppose 5 more years will do ;) >> >> Maybe that's too soon... > > I understand your frustration with our collective inability to solve > this problem for 5+ years. Heck, I share it! I certainly don't want > the problem to be shelved *again*. But a proper discussion should take > us perhaps days, at worst weeks (KVM Forum was last week, several folks > are taking time off right now), certainly not months, let alone years. Ok. I know you don't want a deadline. What about a goal. Our goal could be solving this universal device ID problem within two weeks, or we switch over to plan b. Plan b would be giving only USB devices an ID if none were specified. That way device_del would always work, and we can finally move on from this device ID problem. > We can afford time for discussion. That's how we work. Rough consensus > and running code. You're welcome to provide running code early, just be > prepared for it to be thrown out and redone :) Is it possible you would accept a patch that *only* gives USB devices an ID if none were specified. If you would, I will gladly make this patch and send it in. Given all the different views expressed so far, this universal device ID problem will not likely be solved soon.
