All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Alexander van Heukelum <heukelum@fastmail.fm>,
	linux-arch@vger.kernel.org,
	Alexander van Heukelum <heukelum@mailshack.com>,
	Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/many] PROC macro to annotate functions in assembly files
Date: Wed, 17 Dec 2008 20:38:24 +0300	[thread overview]
Message-ID: <20081217173824.GF8078@localhost> (raw)
In-Reply-To: <20081217172640.GB5436@uranus.ravnborg.org>

[Sam Ravnborg - Wed, Dec 17, 2008 at 06:26:40PM +0100]
| On Wed, Dec 17, 2008 at 10:17:54AM +0100, Alexander van Heukelum wrote:
| > Introduce the PROC macro in the generic header file
| > include/linux/linkage.h to annotate functions in assembly
| > files. This is a first step to fully annotate functions
| > (procedures) in .S-files. The PROC macro complements the
| > already existing and being used ENDPROC macro. The generic
| > implementation of PROC is exactly the same as ENTRY.
| > 
| > The goal is to annotate functions, at least those called
| > from C code, with PROC at the beginning and ENDPROC at the
| > end. This is for the benefit of debugging and tracing. It
| > will also allow to introduce a framework to check for
| > nesting problems and missing annotations in a later stage
| > by overriding ENTRY/END and PROC/ENDPROC in architecture-
| > specific code, after the annotation errors have been fixed.
| > 
| > Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm>
| > Cc: Sam Ravnborg <sam@ravnborg.org>
| > Cc: Andrew Morton <akpm@linux-foundation.org>
| 
| I understand where you are coming from with these.
| But what I see now is:
| 
| ENTRY/END
| PROC/ENDPROC
| KPROBE_ENTRY/KPROBE_END
| 
| And it is not obvious for me reading the comment when I should
| expect which one to be used.
| 
| Could we try to keep it down to two variants?
| And then document when to use which one.
| 
| 	Sam
| 

Sam, I think eventually we should get something like this:

- KPROBE will be eliminated and explicit section descriptions
  are to be used
- ENTRY could be used / or renamed for something more descriptive
  and being used aligned jmp targets or in case of procs with
  shared body
- PROC/ENDPROC are to replace old ENTRY/END for procs being called
  mostly from C code

Did I miss something? Does it sound like a good/bad plan?

		- Cyrill -

  reply	other threads:[~2008-12-17 17:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-17  9:17 PROC macro to annotate functions in assembly files Alexander van Heukelum
2008-12-17  9:17 ` [PATCH 1/many] " Alexander van Heukelum
2008-12-17  9:17   ` [PATCH last/many] x86: checking framework for correct use of ENTRY/PROC Alexander van Heukelum
2008-12-17 11:51     ` Cyrill Gorcunov
2008-12-17 12:04       ` Alexander van Heukelum
2008-12-17 14:43         ` Cyrill Gorcunov
2008-12-17 17:26   ` [PATCH 1/many] PROC macro to annotate functions in assembly files Sam Ravnborg
2008-12-17 17:38     ` Cyrill Gorcunov [this message]
2008-12-17 18:00       ` Sam Ravnborg
2008-12-17 18:33         ` Cyrill Gorcunov
2008-12-18  9:51         ` Alexander van Heukelum
2008-12-18 10:07           ` Russell King
2008-12-18 11:30             ` Alexander van Heukelum
2008-12-18 10:20           ` Jan Beulich
2008-12-18 10:20             ` Jan Beulich
2008-12-18 12:03           ` Cyrill Gorcunov
2008-12-18 12:40             ` Alexander van Heukelum
2008-12-18 16:05               ` Cyrill Gorcunov
2008-12-18  9:23     ` Alexander van Heukelum
2008-12-18 12:52     ` Ingo Molnar
2008-12-17 10:53 ` David Howells
2008-12-17 11:12   ` Alexander van Heukelum
2008-12-18 11:44     ` Russell King
2008-12-18 12:35       ` Alexander van Heukelum
2008-12-18 15:53         ` Russell King

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=20081217173824.GF8078@localhost \
    --to=gorcunov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=heukelum@fastmail.fm \
    --cc=heukelum@mailshack.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sam@ravnborg.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.