lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y9E+dGgQXFUQnIb8@pappasbrent.com>
Date:   Wed, 25 Jan 2023 09:36:36 -0500
From:   Brent Pappas <bpappas@...pasbrent.com>
To:     Dan Carpenter <error27@...il.com>
Cc:     sakari.ailus@...ux.intel.com, bingbu.cao@...el.com,
        tian.shu.qiu@...el.com, mchehab@...nel.org,
        gregkh@...uxfoundation.org, linux-media@...r.kernel.org,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mdeia: ipu3: ipu33-mmu: Replace macro IPU3_ADDR2PTE()
 with a function

Hi Dan,

> When you say "Linux coding style standards" what exactly does that mean?

I am specifically referring to this line of
Documentation/process/coding-style.rst, from the section "Macros, Enums,
and RTL":

> Generally, inline functions are preferable to macros resembling
> functions.

This is the first reason I chose this specific macro.
IPU3_ADD2PTE() would behave the same as a function, so based on my
reading of coding-style.rst, I thought it would be appropriate to
proprose turning it into a function.

Full disclosure, I am university student, and my current research
project is on creating a static analysis framework for finding macros
that can be easily turned into functions.
I want this project to have an impact on widely-used code,
and so I have been using this framework to find such macros in Linux.
That is why I have recently been submitting patches to turn macros into
functions.
So the second reason I chose this macro was because my framework
identifies it as transformable.

> This code is in the middle of a big section full of macros.  Why did you
> pick this particular macro?  Now it doesn't mirror the IPU3_PTE2ADDR()
> so this patch hurts readability.

The reason why I did not try to turn the macro IPU3_PTE2ADDR() into a
function is that it is never invoked, and my framework does not identify
uninvoked macros as transformable.

There are more macros in drivers/staging that I think could be turned
into functions, and I would like to continue submitting patches to do
so.
However, if you would rather I change the way I am doing this,
or that I stop submitting these sorts of patches altogether,
please let me know.

Thank you,
Brent

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ