Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17

Hi -

> [...]
> - It _does not_ change the compiler optimisations.

Like any similar mechanism, it does force the compiler to change its
code generation, so one can't claim this too strongly.

> [...]  Comments are welcome,

I'm still uneasy about the use of varargs.  The current code now uses
the formatting string as metadata to be matched (strcmp) between
producer and consumer.  A general tool that would use them would have
to start parsing general printf directives.  I believe they are not
quite general enough either e.g. to describe a raw binary blob.

I realize they serve a useful purpose in abbreviating what otherwise
one might have to do (like that multiplicity of STAP_MARK_* type/arity
permutations).  But maybe there is a better way.

Also, while regparm(0) may provide some comfort on x86, is there good
reason to believe that the same trick works (and will continue to
work) on non-x86 platforms to invoke a non-varargs callee with a
varargs caller?


- FChE

Attachment: pgpevC4jqPI0Q.pgp
Description: PGP signature

---

• Follow-Ups:
  • Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
    • From: Mathieu Desnoyers <[email protected]>

• References:
  • [PATCH] Linux Kernel Markers 0.11 for 2.6.17
    • From: Mathieu Desnoyers <[email protected]>

• Prev by Date: Re: Smaller compressed kernel source tarballs?
• Next by Date: Re: GPLv3 Position Statement
• Previous by thread: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
• Next by thread: Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]