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
next prev parent reply other threads:[~2020-05-20 6:13 UTC|newest]
Thread overview: 28+ 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 ` [RFC PATCH 2/4] gpu: dxgkrnl: hook up dxgkrnl Sasha Levin
2020-05-19 16:32 ` [RFC PATCH 3/4] Drivers: hv: vmbus: " Sasha Levin
2020-05-19 16:32 ` [RFC PATCH 4/4] gpu: dxgkrnl: create a MAINTAINERS entry Sasha Levin
[not found] ` <20200519163234.226513-2-sashal@kernel.org>
2020-05-19 17:19 ` [RFC PATCH 1/4] gpu: dxgkrnl: core code Greg KH
2020-05-19 17:21 ` Greg KH
2020-05-19 17:45 ` Sasha Levin
2020-05-20 6:13 ` Greg KH [this message]
2020-05-19 17:27 ` Greg KH
2020-05-19 19:21 ` [RFC PATCH 0/4] DirectX on Linux Daniel Vetter
2020-05-19 20:36 ` Sasha Levin
2020-05-20 10:37 ` Jan Engelhardt
2020-06-28 23:39 ` James Hilliard
2020-05-19 22:42 ` Dave Airlie
2020-05-19 23:01 ` Daniel Vetter
2020-05-20 3:47 ` [EXTERNAL] " Steve Pronovost
[not found] ` <CAKMK7uFubAxtMEeCOYtvgjGYtmDVJeXcPFzmRD7t5BUm_GPP0w@mail.gmail.com>
[not found] ` <MWHPR21MB02870909F08EBA08EB903635C7B60@MWHPR21MB0287.namprd21.prod.outlook.com>
2020-05-20 15:34 ` Steve Pronovost
2020-06-16 10:51 ` Pavel Machek
2020-05-19 23:12 ` Dave Airlie
2020-06-16 10:51 ` Pavel Machek
2020-06-16 13:21 ` Sasha Levin
2020-05-20 7:10 ` Thomas Zimmermann
2020-05-20 7:42 ` [EXTERNAL] " Steve Pronovost
2020-05-20 11:06 ` Thomas Zimmermann
2020-06-16 10:51 ` Pavel Machek
2020-06-16 13:28 ` Sasha Levin
2020-06-16 14:41 ` Pavel Machek
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).