From: Joel Brobecker <brobecker@adacore.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA/commit] procfs.c: Remove unused functions and make many functions static
Date: Fri, 04 May 2012 12:35:00 -0000 [thread overview]
Message-ID: <20120504123512.GP15555@adacore.com> (raw)
In-Reply-To: <alpine.DEB.1.10.1205040935240.18334@tp.orcam.me.uk>
> I hesitated doing that in the change you must obviously have in mind
> because it appeared to me that this source file wants to present a
> complete API to /proc services, even if some parts are not actually
> (currently) used by GDB (but may be or may have been sometime).
[...]
> What is unclear to me of course is whether the availability of the
> complete API (if my perception is indeed correct) is relevant any longer
> and why the prototypes have never been moved to a header clients could
> use.
Even if the initial intention was to provide an API, I do not think
it's a good idea to keep maintaining dead code. Making functions
static is often a big help in figuring out the potential call sites
(you immediately know that you do not have to grep the entire repo).
But the procfs.c file in particular is one file that would deserve
a good cleanup (too many #ifdefs to support the various systems,
and their different versions). The problem is that I'm not sure
such cleanup would be worth the effort, because I don't think that
the /proc interface has much future in general... Even LynxOS uses
ptrace :). So, my view is that we should contain and isolate that
code as much as we can.
--
Joel
next prev parent reply other threads:[~2012-05-04 12:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 23:15 Joel Brobecker
2012-05-04 9:10 ` Maciej W. Rozycki
2012-05-04 12:35 ` Joel Brobecker [this message]
2012-05-04 22:49 ` Maciej W. Rozycki
2012-05-07 8:24 ` Maciej W. Rozycki
2012-05-17 17:35 ` Joel Brobecker
2012-05-17 19:26 ` Maciej W. Rozycki
2012-05-17 20:43 ` Joel Brobecker
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=20120504123512.GP15555@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=macro@codesourcery.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox