On Sat, 2014-02-15 at 12:19 -0600, Yoder Stuart-B08248 wrote: > > > -----Original Message----- > > From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > > Sent: Saturday, February 15, 2014 11:34 AM > > To: Yoder Stuart-B08248 > > Cc: Antonios Motakis; alex.williamson@xxxxxxxxxx; > > kvmarm@xxxxxxxxxxxxxxxxxxxxx; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux- > > kernel@xxxxxxxxxxxxxxx; tech@xxxxxxxxxxxxxxxxxxxxxx; > > a.rigo@xxxxxxxxxxxxxxxxxxxxxx; kim.phillips@xxxxxxxxxx; > > jan.kiszka@xxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; Bhushan Bharat-R65777; Wood > > Scott-B07421; christoffer.dall@xxxxxxxxxx; agraf@xxxxxxx; Sethi Varun- > > B16395; will.deacon@xxxxxxx; Tejun Heo; Rafael J. Wysocki; Guenter Roeck; > > Toshi Kani; Joe Perches; Dmitry Kasatkin; Michal Hocko; Bjorn Helgaas > > Subject: Re: [RFC PATCH v4 01/10] driver core: export > > driver_probe_device() > > > > On Sat, Feb 15, 2014 at 04:33:44PM +0000, Stuart Yoder wrote: > > > Are you in principle opposed to any mechanism that would allow 2 > > drivers > > > to be resident/active and allow a sysadmin to explicitly bind a > > > particular device instance to the driver of their choice? > > > > No, that works today with the bind/unbind/new_id files, it's just that > > you don't like it :) > > We don't like it because of the ambiguities/race-conditions with > the current situation. Plus, it's semantically weird (a.k.a. a hack). The user isn't trying to bind an entire type of device to the vfio driver, but rather a specific device. Races and similar ugliness is often what you get when you try to pile things on top of the wrong abstraction. That you can hack around the races with a userspace loop (and hope that no damage was done by the wrong driver in the meantime -- packets sent, filesystems automounted, other inappropriate I/O performed, driver unbind bugs/unwillingness encountered, etc) is not a particularly satisfying answer. At best the race fixup will end up being a poorly tested code path (if the person scripting userspace thinks of doing it at all). It also doesn't "work today" because there is no new_id for platform devices, and the matching situation for platform devices is more complicated than on PCI, so it would be more awkward to implement and more awkward to use. We can apply enough grease and pound the square peg through the round hole if we must, but we'd like to first exhaust our options for doing it in a simple, straightforward, robust, and semantically sensible manner -- especially since once we start supporting the new_id approach for vfio binding on platform devices it'll be ABI that we're stuck with. -Scott _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
