From: Ethan Benson <erbenson@alaska.net>
To: linuxppc-dev@lists.linuxppc.org
Subject: Re: RFC: Performance Monitor Counters device
Date: Fri, 13 Sep 2002 20:41:42 -0800 [thread overview]
Message-ID: <20020914044142.GR714@plato.local.lan> (raw)
In-Reply-To: <3D80F2F7.3FB3AE4B@koffie.nl>
On Thu, Sep 12, 2002 at 10:03:02PM +0200, Segher Boessenkool wrote:
>
> Now the questions ;)
>
> 1) What's the best interface for this kind of thing? A char
> device? With ioctl()'s? a sysctl? something in /proc?
> I'm not interested in ease of implementation (I'll have to
> hack some on gprof too, for this -- so I'm not afraid of
> the kernel ;) ), but in what's philosophically/technically/
> procatically the best interface.
just my humble opinions but:
ioctl() is the sewer of unix, its satanic don't use it.
/proc is a linux dumping ground for endless random cruft that belongs
somewhere else. stop the pollution.
sysctl doesn't seem applicable since its more to flip flags and
switchs in the kernel at runtime. (it sounds like your developing a
more involved interface then that).
that leaves a /dev node which i think is probably most appropriate
(and gives you simple access control via standard permissions for
free)
> 4) Security: I want to generate most of the settings in userland,
> for maximum ease of use and ease of implementation; but that
> brings up some security issues. Only allowing root to
> profile code isn't ideal, either. So:
> a) Don't automagically load the module; if root loads it, let's
> hope he knows what he's doing;
just loading the module shouldn't remove all security IMO.
> b) Have the pmc device be accessible only to a 'trusted' group;
this i think is the best way, just implement the interface solely
though a /dev device node, the admin can set the mode to 660 and group
to whatever and thus control access through standard unix permissions.
> c) A setuid driver program to start profiling;
ugh, don't do setuid, its a massive ammount of work to try and make it
safe.
--
Ethan Benson
http://www.alaska.net/~erbenson/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-09-14 4:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-12 20:03 RFC: Performance Monitor Counters device Segher Boessenkool
2002-09-12 9:52 ` Benjamin Herrenschmidt
2002-09-12 21:45 ` Segher Boessenkool
2002-09-12 10:25 ` Benjamin Herrenschmidt
2002-09-14 11:28 ` Segher Boessenkool
2002-09-15 12:50 ` samuel
2002-09-16 12:38 ` Benjamin Herrenschmidt
2002-09-16 23:50 ` Segher Boessenkool
2002-09-13 3:32 ` Paul Mackerras
2002-09-14 11:36 ` Segher Boessenkool
2002-09-13 10:04 ` Anton Blanchard
2002-09-14 11:39 ` Segher Boessenkool
2002-09-13 22:21 ` David Engebretsen
2002-09-14 11:22 ` Segher Boessenkool
2002-09-16 15:14 ` Dave Engebretsen
2002-09-17 4:59 ` Segher Boessenkool
2002-09-14 4:41 ` Ethan Benson [this message]
2002-09-15 1:37 ` Rob Latham
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=20020914044142.GR714@plato.local.lan \
--to=erbenson@alaska.net \
--cc=linuxppc-dev@lists.linuxppc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).