On 02/02/2023 12:56, Carsten Haitzler wrote:
On 2/2/23 08:12, Kevin Brodsky wrote:
On 30/01/2023 14:50, carsten.haitzler@foss.arm.com wrote:
From: Carsten Haitzler carsten.haitzler@foss.arm.com
Careful, it looks like you ended up committing with a different email address from the one you S-o-b with.
As they are both me... :) the problem is I had to use @foss because of complaints about arm adding its disclaimer blurbs to my @arm.com mails
- si i send from my @foss.arm.com to avoid that. So far upstreams have
not cared about the mix.
Not a big issue - it's just better to have the author email and S-o-b email matching, foss or not. It's strange that you ended up with a mismatch, because the From: line should come from the author email (i.e. git config user.email), and the S-o-b too if you use git commit -s.
DRM compat code totally assumes 32bit is compat. This is not always
Nit: rather "compat is 32-bit", native can also be 32-bit :)
That is true. I guess from the morello context it is... but in the event of native 32bit we have no comapt at all so it's moot. :) but the drm compat code actually is literally all 32bit only. It totally assumes that.
Sure, just a matter of formulation, the underlying idea is the same.
the case. This allows for compat to be defined universally to typedefed types like compat_ulong_t and so on. This converts some of the drm compat handling for ioctl's to use these types.
Signed-off-by: Carsten Haitzler Carsten.Haitzler@arm.com
drivers/gpu/drm/drm_ioc32.c | 209 ++++++++++++++++++------------------ include/drm/drm_ioctl.h | 2 +- 2 files changed, 106 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c index 5d82891c3222..13e7d25dcbae 100644 --- a/drivers/gpu/drm/drm_ioc32.c +++ b/drivers/gpu/drm/drm_ioc32.c @@ -38,21 +38,21 @@ #include "drm_internal.h" #include "drm_legacy.h" -#define DRM_IOCTL_VERSION32 DRM_IOWR(0x00, drm_version32_t) -#define DRM_IOCTL_GET_UNIQUE32 DRM_IOWR(0x01, drm_unique32_t) +#define DRM_IOCTL_VERSION_COMPAT DRM_IOWR(0x00, drm_version_compat_t) +#define DRM_IOCTL_GET_UNIQUE_COMPAT DRM_IOWR(0x01, drm_unique_compat_t)
On balance, I don't think this partial 32 -> compat renaming is really helping. A large number of structs / constants in this file remain suffixed with 32, making it look like some of them are 32-bit-specific and some are not. If we really want to go for renaming here, we should rename everything in this file, and even the file name itself. That would be extremely noisy, which is rather undesirable for a patch we will keep rebasing. AFAICT the functional changes in this patch are fairly small, so I would stick to those and skip the renaming.
If I do that then I start fixing legacy (which is not needed) and x86 only 32bit compat code (CONFIG_X86). If you start doing this path, the patch starts getting a lot bigger as I have to change various other files in the tree. I start having to make changes to struct file (or was it struct file_operations ... I can't remember .. something along these lines). I started walking down this path and went "oh dear" as I noticed I'd have to touch 100's of files and then unwound that work and ketp it to the necessary pieces. The hybrid nature of this kis a result of keeping this concise and not sprawling as well as sticking to what is being actually tested.
Agreed, that's why it's better to choose one clear path and just not rename anything.
Kevin