On Tue, 9 Apr 2019 19:14:53 +0200 Cornelia Huck <cohuck@xxxxxxxxxx> wrote: [..] > > > At this point, you're always going via the css0 device. I'm > > > wondering whether you should pass in the cssid here and use > > > css_by_id(cssid) to make this future proof. But then, I'm not > > > quite clear from which context this will be called. > > > > As said before I don't see MCSS-E coming. Regarding the client code, > > please check out the rest of the series. Especially patch 6. > > > > From my perspective it would be at this stage saner to make it more > > obvious that only one css is supported (at the moment), than to > > implement MCSS-E, or to make this (kind of) MCSS-E ready. > > I disagree. I think there's value in keeping the interfaces clean > (within reasonable bounds, of course.) Even if there is no > implementation of MCSS-E other than QEMU... it is probably a good idea > to spend some brain cycles to make this conceptually clean. AFAIU Linux currently does not support MCSS-E. I don't have the bandwidth to implement MCSS-E support in the kernel. I fully agree for external interfaces should be MCSS-E conform, so should we ever decide to implement we don't have to overcome self-made obstacles. Kernel internal stuff however, IMHO, should avoid carrying a ballast of an 20%-30% implemented MCSS-E support. I see no benefit. But I don't insist. If you have a good idea how to make this more MCSS-E conform, you are welcome. In think something like this is best done on top of a series that provides a basic working solution. Especially if the conceptually clean thing is conceptually or code-wise more complex than the basic solution. If you have something in mind that is simpler and more lightweight than what I did here, I would be more than happy to make that happen. Regards, Halil
