On Fri, 24 Apr 2020 13:07:38 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:
We are talking interface design. The relevance of discussing a tool is
On 4/23/20 11:33 PM, Halil Pasic wrote:
On Thu, 16 Apr 2020 11:37:21 +0200I don't believe there is no right or wrong answer here; I simply don't
Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
On Wed, 15 Apr 2020 13:10:10 -0400Logging may not be the right answer here. Imagine somebody wants to build
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:
On 4/14/20 8:58 AM, Cornelia Huck wrote:Sounds reasonable. My main issue was what an admin was supposed to do
On Tue, 7 Apr 2020 15:20:03 -0400One of the things on my TODO list is to add logging to the vfio_ap
Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:
+Can we log the offending apm somewhere, preferably with additional info
+ if (ap_drv->in_use)
+ if (ap_drv->in_use(newapm, ap_perms.aqm))
that allows the admin to figure out why an error was returned?
module which will track all significant activity within the device
driver. I plan to do that with a patch or set of patches specifically
put together for that purpose. Having said that, the best place to
log this would be in the in_use callback in the vfio_ap device driver
(see next patch) where the APQNs that are in use can be identified.
For now, I will log a message to the dmesg log indicating which
APQNs are in use by the matrix mdev.
until logging was in place :)
a nice web-tool for managing this stuff at scale -- e.g. something HMC. I
don't think the solution is to let this tool parse the kernel messages
and try to relate that to its own transactions.
see the relevance of discussing a tool in this context. We are talking
about a sysfs attribute interface here, so - correct me if I'm
mistaken - our options for notifying the user that a queue is in use are
limited to the return code from the sysfs interface and logging. I would
expect that a tool would have to do something similar to the callback
implemented in the vfio_ap device driver and check the APQNs
removed against the APQNs assigned to the mdevs to determine which
is in use.
that any userspace tool must come by with whatever interface we come up
now. IMHO thinking about the usage (and the client code) is very helpful
in avoiding broken interface designs. AFAIK this is one of the basic
ideas behind test driven development.
Regards,
Halil