On Wed 22 Jun 2016 05:49:28 PM CEST, Kevin Wolf wrote: >> I thought adding a new 'ID' field was simpler. The device name is >> still a device name (where it makes sense). The default ID is >> guaranteed to be valid and guaranteed not to clash with user-defined >> IDs. The API is (in my opinion) more clear. >> >> The only problems that I can think of: >> >> - BlockJobInfo and the events expose the 'device' field which is >> superfluous. >> - block-job-{pause,resume,...} can take an ID or a device name. > > Yes. There are two parts that I don't like about this. > > The first one is that we need additional code to keep track of the > device name and to look it up.
I think this part is negligible, but ok. > The other, more important one is that it couples block jobs more > tightly with a BDS: > > * What do you with a background job that doesn't have a device name > because it doesn't work on a BDS? Will 'device' become optional > everywhere? But how is this less problematic for compatibility than > returning non-device-name IDs? (To be clear, I don't think either is > a real problem, but you can hardly dismiss one and accept the > other.) > * And what do you do once we allow more than one job per device? Then > the device name isn't suitable for addressing the job any more. And > letting the client use the device name after it started the first > job, but not any more after it started the second one, feels wrong. Fair enough. Unless Max, Eric or someone else has something else to add I'll give it a try and see how it looks. Berto