From: Dave Hansen <haveblue@us.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org,
Linux Containers <containers@lists.osdl.org>,
dave@sr71.net
Subject: Re: [PATCH 2/7] proc: Modify proc_pident_lookup to be completely table driven.
Date: Tue, 15 Aug 2006 11:31:51 -0700 [thread overview]
Message-ID: <1155666711.12700.54.camel@localhost.localdomain> (raw)
In-Reply-To: <11556651312499-git-send-email-ebiederm@xmission.com>
On Tue, 2006-08-15 at 12:05 -0600, Eric W. Biederman wrote:
> Currently proc_pident_lookup gets the names and types from a table
> and then has a huge switch statement to get the inode and file
> operations it needs. That is silly and is becoming increasingly hard
> to maintain so I just put all of the information in the table.
Looks pretty reasonable.
> +#define INF(TYPE, NAME, MODE, OTYPE) \
> + NOD(TYPE, NAME, (S_IFREG|(MODE)), \
> + NULL, &proc_info_file_operations, \
> + { .proc_read = &proc_##OTYPE } )
...
> + INF(PROC_TID_OOM_SCORE, "oom_score", S_IRUGO, oom_score),
> + REG(PROC_TID_OOM_ADJUST, "oom_adj", S_IRUGO|S_IWUSR, oom_adjust),
Could we give these some slightly more intuitive names? INF is a bit
terse ;)
Since these #defines and function are also all in base.c, and not
referenced elsewhere, might it be reasonable to take some of the PROC_
headers off of them? I know I've been frustrated more than once by
popping things like "oom_score" in to cscope and finding no definitions.
-- Dave
next prev parent reply other threads:[~2006-08-15 18:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-15 18:00 The rest of my proc cleanup Eric W. Biederman
2006-08-15 18:05 ` [PATCH 1/7] proc: Reorder the functions in base.c Eric W. Biederman
2006-08-15 18:05 ` [PATCH 2/7] proc: Modify proc_pident_lookup to be completely table driven Eric W. Biederman
2006-08-15 18:31 ` Dave Hansen [this message]
2006-08-15 18:55 ` Eric W. Biederman
2006-08-16 14:48 ` Jan Engelhardt
2006-08-15 18:05 ` [PATCH 3/7] proc: Give the root directory a task Eric W. Biederman
2006-08-15 18:05 ` [PATCH 4/7] proc: Make the generation of the self symlink table driven Eric W. Biederman
2006-08-19 8:06 ` Andrew Morton
2006-08-19 9:07 ` Eric W. Biederman
2006-08-19 16:03 ` Andrew Morton
2006-08-19 19:04 ` Eric W. Biederman
2006-08-19 9:54 ` Eric W. Biederman
2006-08-15 18:05 ` [PATCH 5/7] proc: Factor out an instantiate method from every lookup method Eric W. Biederman
2006-08-16 14:52 ` Jan Engelhardt
2006-08-15 18:05 ` [PATCH 6/7] proc: Remove the hard coded inode numbers Eric W. Biederman
2006-08-15 18:05 ` [PATCH 7/7] proc: Merge proc_tid_attr and proc_tgid_attr Eric W. Biederman
2006-08-15 18:33 ` The rest of my proc cleanup Paul Jackson
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=1155666711.12700.54.camel@localhost.localdomain \
--to=haveblue@us.ibm.com \
--cc=akpm@osdl.org \
--cc=containers@lists.osdl.org \
--cc=dave@sr71.net \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.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
Powered by JetHome