All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Sasha Levin <sashal@kernel.org>
Cc: linux-hyperv@vger.kernel.org, sthemmin@microsoft.com,
	tvrtko.ursulin@intel.com, haiyangz@microsoft.com,
	spronovo@microsoft.com, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	wei.liu@kernel.org, linux-fbdev@vger.kernel.org,
	iourit@microsoft.com, alexander.deucher@amd.com,
	kys@microsoft.com, Hawking.Zhang@amd.com
Subject: Re: [RFC PATCH 1/4] gpu: dxgkrnl: core code
Date: Wed, 20 May 2020 06:13:56 +0000	[thread overview]
Message-ID: <20200520061356.GA2269481@kroah.com> (raw)
In-Reply-To: <20200519174553.GF33628@sasha-vm>

On Tue, May 19, 2020 at 01:45:53PM -0400, Sasha Levin wrote:
> On Tue, May 19, 2020 at 07:21:05PM +0200, Greg KH wrote:
> > On Tue, May 19, 2020 at 12:32:31PM -0400, Sasha Levin wrote:
> > > +
> > > +#define DXGK_MAX_LOCK_DEPTH	64
> > > +#define W_MAX_PATH		260
> > 
> > We already have a max path number, why use a different one?
> 
> It's max path for Windows, not Linux (thus the "W_" prefix) :)

Ah, not obvious :)

> Maybe changing it to WIN_MAX_PATH or such will make it better?

Probably.

> > > +#define d3dkmt_handle		u32
> > > +#define d3dgpu_virtual_address	u64
> > > +#define winwchar		u16
> > > +#define winhandle		u64
> > > +#define ntstatus		int
> > > +#define winbool			u32
> > > +#define d3dgpu_size_t		u64
> > 
> > These are all ripe for a simple search/replace in your editor before you
> > do your next version :)
> 
> I've actually attempted that, and reverted that change, mostly because
> the whole 'handle' thing became very confusing.

Yeah, "handles" in windows can be a mess, with some being pointers and
others just integers.  Trying to make a specific typedef for it is
usually the better way overall, that way you can get the compiler to
check for mistakes.  These #defines will not really help with that.

But, 'ntstatus' should be ok to just make "int" everywhere, right?

> Note that we have a few 'handles', each with a different size, and thus
> calling get_something_something_handle() type of functions becase very
> confusing since it's not clear what handle we're working with in that
> case.

Yeah, typedefs can help there.

> With regards to the rest, I wanted to leave stuff like 'winbool' to
> document the expected ABI between the Windows and Linux side of things.
> Ideally it would be 'bool' or 'u8', but as you see we had to use 'u32'
> here which I feel lessens our ability to have the code document itself.

'bool' probably will not work as I think it's compiler dependent, __u8
is probably best.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Sasha Levin <sashal@kernel.org>
Cc: alexander.deucher@amd.com, chris@chris-wilson.co.uk,
	ville.syrjala@linux.intel.com, Hawking.Zhang@amd.com,
	tvrtko.ursulin@intel.com, linux-kernel@vger.kernel.org,
	linux-hyperv@vger.kernel.org, kys@microsoft.com,
	haiyangz@microsoft.com, sthemmin@microsoft.com,
	wei.liu@kernel.org, spronovo@microsoft.com, iourit@microsoft.com,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] gpu: dxgkrnl: core code
Date: Wed, 20 May 2020 08:13:56 +0200	[thread overview]
Message-ID: <20200520061356.GA2269481@kroah.com> (raw)
In-Reply-To: <20200519174553.GF33628@sasha-vm>

On Tue, May 19, 2020 at 01:45:53PM -0400, Sasha Levin wrote:
> On Tue, May 19, 2020 at 07:21:05PM +0200, Greg KH wrote:
> > On Tue, May 19, 2020 at 12:32:31PM -0400, Sasha Levin wrote:
> > > +
> > > +#define DXGK_MAX_LOCK_DEPTH	64
> > > +#define W_MAX_PATH		260
> > 
> > We already have a max path number, why use a different one?
> 
> It's max path for Windows, not Linux (thus the "W_" prefix) :)

Ah, not obvious :)

> Maybe changing it to WIN_MAX_PATH or such will make it better?

Probably.

> > > +#define d3dkmt_handle		u32
> > > +#define d3dgpu_virtual_address	u64
> > > +#define winwchar		u16
> > > +#define winhandle		u64
> > > +#define ntstatus		int
> > > +#define winbool			u32
> > > +#define d3dgpu_size_t		u64
> > 
> > These are all ripe for a simple search/replace in your editor before you
> > do your next version :)
> 
> I've actually attempted that, and reverted that change, mostly because
> the whole 'handle' thing became very confusing.

Yeah, "handles" in windows can be a mess, with some being pointers and
others just integers.  Trying to make a specific typedef for it is
usually the better way overall, that way you can get the compiler to
check for mistakes.  These #defines will not really help with that.

But, 'ntstatus' should be ok to just make "int" everywhere, right?

> Note that we have a few 'handles', each with a different size, and thus
> calling get_something_something_handle() type of functions becase very
> confusing since it's not clear what handle we're working with in that
> case.

Yeah, typedefs can help there.

> With regards to the rest, I wanted to leave stuff like 'winbool' to
> document the expected ABI between the Windows and Linux side of things.
> Ideally it would be 'bool' or 'u8', but as you see we had to use 'u32'
> here which I feel lessens our ability to have the code document itself.

'bool' probably will not work as I think it's compiler dependent, __u8
is probably best.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Sasha Levin <sashal@kernel.org>
Cc: linux-hyperv@vger.kernel.org, sthemmin@microsoft.com,
	tvrtko.ursulin@intel.com, haiyangz@microsoft.com,
	spronovo@microsoft.com, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	wei.liu@kernel.org, linux-fbdev@vger.kernel.org,
	iourit@microsoft.com, alexander.deucher@amd.com,
	kys@microsoft.com, Hawking.Zhang@amd.com
Subject: Re: [RFC PATCH 1/4] gpu: dxgkrnl: core code
Date: Wed, 20 May 2020 08:13:56 +0200	[thread overview]
Message-ID: <20200520061356.GA2269481@kroah.com> (raw)
In-Reply-To: <20200519174553.GF33628@sasha-vm>

On Tue, May 19, 2020 at 01:45:53PM -0400, Sasha Levin wrote:
> On Tue, May 19, 2020 at 07:21:05PM +0200, Greg KH wrote:
> > On Tue, May 19, 2020 at 12:32:31PM -0400, Sasha Levin wrote:
> > > +
> > > +#define DXGK_MAX_LOCK_DEPTH	64
> > > +#define W_MAX_PATH		260
> > 
> > We already have a max path number, why use a different one?
> 
> It's max path for Windows, not Linux (thus the "W_" prefix) :)

Ah, not obvious :)

> Maybe changing it to WIN_MAX_PATH or such will make it better?

Probably.

> > > +#define d3dkmt_handle		u32
> > > +#define d3dgpu_virtual_address	u64
> > > +#define winwchar		u16
> > > +#define winhandle		u64
> > > +#define ntstatus		int
> > > +#define winbool			u32
> > > +#define d3dgpu_size_t		u64
> > 
> > These are all ripe for a simple search/replace in your editor before you
> > do your next version :)
> 
> I've actually attempted that, and reverted that change, mostly because
> the whole 'handle' thing became very confusing.

Yeah, "handles" in windows can be a mess, with some being pointers and
others just integers.  Trying to make a specific typedef for it is
usually the better way overall, that way you can get the compiler to
check for mistakes.  These #defines will not really help with that.

But, 'ntstatus' should be ok to just make "int" everywhere, right?

> Note that we have a few 'handles', each with a different size, and thus
> calling get_something_something_handle() type of functions becase very
> confusing since it's not clear what handle we're working with in that
> case.

Yeah, typedefs can help there.

> With regards to the rest, I wanted to leave stuff like 'winbool' to
> document the expected ABI between the Windows and Linux side of things.
> Ideally it would be 'bool' or 'u8', but as you see we had to use 'u32'
> here which I feel lessens our ability to have the code document itself.

'bool' probably will not work as I think it's compiler dependent, __u8
is probably best.

thanks,

greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-05-20  6:13 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 16:32 [RFC PATCH 0/4] DirectX on Linux Sasha Levin
2020-05-19 16:32 ` Sasha Levin
2020-05-19 16:32 ` Sasha Levin
2020-05-19 16:32 ` [RFC PATCH 1/4] gpu: dxgkrnl: core code Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 17:19   ` Greg KH
2020-05-19 17:19     ` Greg KH
2020-05-19 17:19     ` Greg KH
2020-05-19 17:21   ` Greg KH
2020-05-19 17:21     ` Greg KH
2020-05-19 17:21     ` Greg KH
2020-05-19 17:45     ` Sasha Levin
2020-05-19 17:45       ` Sasha Levin
2020-05-19 17:45       ` Sasha Levin
2020-05-20  6:13       ` Greg KH [this message]
2020-05-20  6:13         ` Greg KH
2020-05-20  6:13         ` Greg KH
2020-05-19 17:27   ` Greg KH
2020-05-19 17:27     ` Greg KH
2020-05-19 17:27     ` Greg KH
2020-05-19 16:32 ` [RFC PATCH 2/4] gpu: dxgkrnl: hook up dxgkrnl Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 23:27   ` kbuild test robot
2020-05-19 23:27   ` kbuild test robot
2020-05-20  7:05   ` kbuild test robot
2020-05-22  8:10   ` Dan Carpenter
2020-05-22  8:10     ` [kbuild] " Dan Carpenter
2020-05-30 13:48   ` kbuild test robot
2020-05-19 16:32 ` [RFC PATCH 3/4] Drivers: hv: vmbus: " Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 16:32 ` [RFC PATCH 4/4] gpu: dxgkrnl: create a MAINTAINERS entry Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 16:32   ` Sasha Levin
2020-05-19 19:21 ` [RFC PATCH 0/4] DirectX on Linux Daniel Vetter
2020-05-19 19:21   ` Daniel Vetter
2020-05-19 19:21   ` Daniel Vetter
2020-05-19 20:36   ` Sasha Levin
2020-05-19 20:36     ` Sasha Levin
2020-05-19 20:36     ` Sasha Levin
2020-05-20 10:37     ` Jan Engelhardt
2020-05-20 10:37       ` Jan Engelhardt
2020-05-20 10:37       ` Jan Engelhardt
2020-06-28 23:39     ` James Hilliard
2020-06-28 23:39       ` James Hilliard
2020-06-28 23:39       ` James Hilliard
2020-05-19 22:42 ` Dave Airlie
2020-05-19 22:42   ` Dave Airlie
2020-05-19 22:42   ` Dave Airlie
2020-05-19 23:01   ` Daniel Vetter
2020-05-19 23:01     ` Daniel Vetter
2020-05-19 23:01     ` Daniel Vetter
2020-05-20  3:47     ` [EXTERNAL] " Steve Pronovost
2020-05-20  3:47       ` Steve Pronovost
2020-05-20  3:47       ` Steve Pronovost
2020-05-20  7:40       ` Daniel Vetter
2020-05-20  8:19         ` Steve Pronovost
2020-05-20 15:34           ` Steve Pronovost
2020-05-20 15:34             ` Steve Pronovost
2020-05-20 15:34             ` Steve Pronovost
2020-06-16 10:51       ` Pavel Machek
2020-06-16 10:51         ` Pavel Machek
2020-06-16 10:51         ` Pavel Machek
2020-05-19 23:12   ` Dave Airlie
2020-05-19 23:12     ` Dave Airlie
2020-05-19 23:12     ` Dave Airlie
2020-06-16 10:51     ` Pavel Machek
2020-06-16 10:51       ` Pavel Machek
2020-06-16 10:51       ` Pavel Machek
2020-06-16 13:21       ` Sasha Levin
2020-06-16 13:21         ` Sasha Levin
2020-06-16 13:21         ` Sasha Levin
2020-05-20  7:10 ` Thomas Zimmermann
2020-05-20  7:10   ` Thomas Zimmermann
2020-05-20  7:10   ` Thomas Zimmermann
2020-05-20  7:42   ` [EXTERNAL] " Steve Pronovost
2020-05-20  7:42     ` Steve Pronovost
2020-05-20  7:42     ` Steve Pronovost
2020-05-20 11:06     ` Thomas Zimmermann
2020-05-20 11:06       ` Thomas Zimmermann
2020-05-20 11:06       ` Thomas Zimmermann
2020-06-16 10:51   ` Pavel Machek
2020-06-16 10:51     ` Pavel Machek
2020-06-16 10:51     ` Pavel Machek
2020-06-16 13:28     ` Sasha Levin
2020-06-16 13:28       ` Sasha Levin
2020-06-16 13:28       ` Sasha Levin
2020-06-16 14:41       ` Pavel Machek
2020-06-16 14:41         ` Pavel Machek
2020-06-16 14:41         ` Pavel Machek
2020-06-16 16:00         ` Sasha Levin
2020-06-16 16:00           ` Sasha Levin
2020-06-16 16:00           ` Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200520061356.GA2269481@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Hawking.Zhang@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=haiyangz@microsoft.com \
    --cc=iourit@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=spronovo@microsoft.com \
    --cc=sthemmin@microsoft.com \
    --cc=tvrtko.ursulin@intel.com \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.