On Mon, Dec 12, 2016 at 03:17:16PM +0000, Chris Wilson wrote: > On Mon, Dec 12, 2016 at 03:52:05PM +0100, Arkadiusz Hiler wrote: > > On Mon, Dec 12, 2016 at 02:21:41PM +0000, Chris Wilson wrote: > > > As for userspace simply asking where huc is enabled, we already have > > > that in the ABI via the module parameter, so you need to justify why > > > this is preferred (in addition to the available information). > > > > Yeah, we do change the values of module parameters. But a lot of them > > are uid 0 only and we have PARAMS for those. > > > > Do anything userspace use those actually? Do we plan to use them instead > > of the getparams since now on? > > I've done both from userspace... I don't really have a preference, once > you have an fd, an ioctl/GETPARAM is trivial. But for quick querying and > reporting of driver state, reading the module parameter is easier. So I > have a tendency to use an ioctl in production code and module parameter > in igt. (And I would say that for one-off validation purposes, i.e. did > hte module actually enable huc?, just check the module parameter. Thank you for explaining it :) > If userspace is expected to interact and respond to the setting > during its early probe, make it an ioctl so it fits in with the > similar code also being run at that time.) Okay. Seems like the scenario Anusha's got. > It is just worth explaining the intended usecase in the cover note, so > that the use can be sanity checked and reflected upon later if need be. > -Chris The cover letter links patches from the libva which is pretty much a template usecase, but I agree, it wold be nice if it used words/pseudocode instead of portions of code from some other project. > -- > Chris Wilson, Intel Open Source Technology Centre -- Cheers, Arek _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
