Re: [PATCH v4 1/3] kbuild: add mod(name,file)_flags to assembler flags for module objects

[Kris Van Hees <kris.van.hees@oracle.com>]

On Fri, Jun 14, 2024 at 02:26:21PM -0400, Steven Rostedt wrote:
> On Fri, 14 Jun 2024 14:10:58 -0400
> Kris Van Hees <kris.van.hees@oracle.com> wrote:
> 
> > On Fri, Jun 14, 2024 at 01:46:51PM -0400, Steven Rostedt wrote:
> > > On Fri, 14 Jun 2024 13:14:26 -0400
> > > Kris Van Hees <kris.van.hees@oracle.com> wrote:
> > >   
> > > > Module objects compiled from C source can be identified by the presence
> > > > of -DKBUILD_MODFILE and -DKBUILD_MODNAME on their compile command lines.
> > > > However, module objects from assembler source do not have this defines.
> > > > 
> > > > Add $(modfile_flags) to modkern_aflags (similar to modkern_cflahs), and
> > > > add $(modname_flags) to a_flags (similar to c_flags).  
> > > 
> > > You explain what this does but not why it does it.  
> > 
> > The first paragraph is meant to estabish the "why" (being able to identify
> > what objects are module objects, even if they are compiled from assembler
> > source).
> 
> Perhaps there's a lack of context. Sure, the cover letter can help in
> this regard, but I always look at each commit as a stand alone.
> 
> > 
> > As I mention, for objects compiled from C source code, those defines being
> > present identifies those objects as belonging to a module.  For objects
> > compiled from assembler source code, those defines are not present.  Passing
> > them on the compile command line for assembler source code files for objects
> > that are part of one or more modules allows us to identify all objects that
> > are part of modules with a single consistent mechanism.
> 
> Sure, but why do we care? Again, if this was the only patch you sent,
> it should explain why it is being done.
> 
> Perhaps something like: "In order to be able to identify what code is
> from a module, even if it is built in, ..."
> 
> But what you are saying is just "C code has these flags, make
> assembly have them too". Which is meaningless.
> 
> The other patches could use some more explanation too.

Hi Steve,

Thank you for your feedback.  I hope that my new patch series [0] addresses
your questions.

Kris