On Fri, Aug 14, 2020 at 08:38:53AM -0400, Sasha Levin wrote:
Add support for a Hyper-V based vGPU implementation that exposes the
DirectX API to Linux userspace.
Signed-off-by: Sasha Levin <sashal@kernel.org>
Better, but what is this mess:
+#define ISERROR(ret) (ret < 0)
?
+#define EINTERNALERROR EINVAL
And that?
+
+#define DXGKRNL_ASSERT(exp)
+#define UNUSED(x) (void)(x)
Ick, no, please.
+#undef pr_fmt
In a .h file?
+#define pr_fmt(fmt) "dxgk:err: " fmt
+#define pr_fmt1(fmt) "dxgk: " fmt
+#define pr_fmt2(fmt) "dxgk: " fmt
Why?
+
+#define DXGKDEBUG 1
+/* #define USEPRINTK 1 */
+
+#ifndef DXGKDEBUG
+#define TRACE_DEBUG(...)
+#define TRACE_DEFINE(...)
+#define TRACE_FUNC_ENTER(...)
+#define TRACE_FUNC_EXIT(...)
No, please do not to custom "trace" printk messages, that is what ftrace
is for, no individual driver should ever need to do that.
Just use the normal dev_*() calls for error messages and the like, do
not try to come up with a custom tracing framework for one tiny
individual driver. If every driver in kernel did that, we would have a
nightmare...
thanks,
greg k-h
On 8/14/2020 5:55 AM, Greg KH wrote:
On Fri, Aug 14, 2020 at 08:38:53AM -0400, Sasha Levin wrote:
quoted
Add support for a Hyper-V based vGPU implementation that exposes the
DirectX API to Linux userspace.
Signed-off-by: Sasha Levin <sashal@kernel.org>
Better, but what is this mess:
quoted
+#define ISERROR(ret) (ret < 0)
The VM bus messages return the NTSTATUS error code from the host.
NTSTATUS is integer and the positive values indicate success.
The success error code needs to be returned by IOCTLs to the DxCore
applications. The ISERROR() macro is used in places where the NTSTATUS
success code could be returned from a function. "if (ret)" cannot be
used. I will add a comment to the macro in the next patch.
?
quoted
+#define EINTERNALERROR EINVAL
This macro will be removed in the next patch
And that?
quoted
+
+#define DXGKRNL_ASSERT(exp)
+#define UNUSED(x) (void)(x)
The UNUSED macro will be removed.
The DXGKRNL_ASSERT() macro will be changed to generate a memory dump and
BUG_ON when DXGDEBUG is enabled. It is used to catch internal errors in
the debug code. There will be no bugcheck in the released driver.
Ick, no, please.
quoted
+#undef pr_fmt
In a .h file?
quoted
+#define pr_fmt(fmt) "dxgk:err: " fmt
+#define pr_fmt1(fmt) "dxgk: " fmt
+#define pr_fmt2(fmt) "dxgk: " fmt
This will be fixed in the next patch set.
Why?
quoted
+
+#define DXGKDEBUG 1
+/* #define USEPRINTK 1 */
+
+#ifndef DXGKDEBUG
+#define TRACE_DEBUG(...)
+#define TRACE_DEFINE(...)
+#define TRACE_FUNC_ENTER(...)
+#define TRACE_FUNC_EXIT(...)
No, please do not to custom "trace" printk messages, that is what ftrace
is for, no individual driver should ever need to do that.
Just use the normal dev_*() calls for error messages and the like, do
not try to come up with a custom tracing framework for one tiny
individual driver. If every driver in kernel did that, we would have a
nightmare...
I understand the concern. This will be fixed later when we learn and
pick the final tracing technology for the driver. The current
implementation allows the hardware vendors to quickly identify issues
without learning about ftrace. They just need to enable the WSL debug
console and mount debugfs.
thanks,
greg k-h
Thank you for your time and good comments.
Iouri
On Thu, Aug 27, 2020 at 04:29:59PM -0700, Iouri Tarassov wrote:
On 8/14/2020 5:55 AM, Greg KH wrote:
quoted
On Fri, Aug 14, 2020 at 08:38:53AM -0400, Sasha Levin wrote:
quoted
Add support for a Hyper-V based vGPU implementation that exposes the
DirectX API to Linux userspace.
quoted
Signed-off-by: Sasha Levin <sashal@kernel.org>
Better, but what is this mess:
quoted
+#define ISERROR(ret) (ret < 0)
The VM bus messages return the NTSTATUS error code from the host. NTSTATUS
is integer and the positive values indicate success.
The success error code needs to be returned by IOCTLs to the DxCore
applications. The ISERROR() macro is used in places where the NTSTATUS
success code could be returned from a function. "if (ret)" cannot be used. I
will add a comment to the macro in the next patch.
No, please just "open code" this, there is no need for a macro that is
actually more characters than the original test.
quoted
quoted
+#define DXGKDEBUG 1
+/* #define USEPRINTK 1 */
+
+#ifndef DXGKDEBUG
+#define TRACE_DEBUG(...)
+#define TRACE_DEFINE(...)
+#define TRACE_FUNC_ENTER(...)
+#define TRACE_FUNC_EXIT(...)
No, please do not to custom "trace" printk messages, that is what ftrace
is for, no individual driver should ever need to do that.
Just use the normal dev_*() calls for error messages and the like, do
not try to come up with a custom tracing framework for one tiny
individual driver. If every driver in kernel did that, we would have a
nightmare...
I understand the concern. This will be fixed later when we learn and pick
the final tracing technology for the driver.
When is "later"? We don't want to review something that you do not
think is ready to be merged, do it now so we don't trip over things that
you know you want to fix up.
The current implementation
allows the hardware vendors to quickly identify issues without learning
about ftrace. They just need to enable the WSL debug console and mount
debugfs.
Hardware vendors who know Linux already know about ftrace, don't make
people have to read up and learn about custom ways to debug
just-your-tiny-individual-driver. Instead follow the customs and ways
the _WHOLE_ kernel works, that is just polite, don't you think?
thanks,
greg k-h