From: "Joseph D. Wagner" <wagnerjd@prodigy.net>
To: "Linux Kernel Development List" <linux-kernel@vger.kernel.org>
Subject: Good Idea (tm): Code Consolidation for Functions and Macros that Access the Process Address Space
Date: Sat, 5 Oct 2002 19:58:55 -0500 [thread overview]
Message-ID: <000001c26cd3$950ef580$7975d73f@joe> (raw)
SUBJECT: Good Idea (tm): Code Consolidation for Functions and Macros
that Access the Process Address Space
PROBLEM: Eight (8) functions/macros are near duplicates of, and
equivalent to, other functions/macros that access the process address
space. Specifically:
get_user duplicates get_user_ret
__get_user duplicates __get_user_ret
put_user duplicates put_user_ret
__put_user duplicates __put_user_ret
copy_from_user duplicates copy_from_user_ret
__copy_from_user duplicates copy_from_user_ret
copy_to_user duplicates copy_to_user_ret
__copy_to_user duplicates copy_to_user_ret
EXPLAINATION: One functional difference exists between the
functions/macros with "_ret" and those without: functions/macros with
"_ret" return an error code; those without "_ret" return void.
Since the only difference is whether or not an error code is returned,
the functions/macros can be used interchangeably.
Remember, if a function call has no place for a returned value to go,
nothing bad happens; the returned value is simply ignored/discarded.
WHY THIS SHOULD BE CHANGED:
1) Easier to maintain code (because there's less of it to maintain).
2) Less code means smaller kernel.
3) Forces better coding structures and procedures (because no matter
which function the user will choose under the new system, an error code
will always be returned).
4) Is backward compatible with all existing code.
5) The solution can be seamlessly integrated.
6) The overhead for returning an error code is nominal.
SOLUTION:
Use the #define Preprocessor Directive for Symbolic Constants. Here's
some sample code:
#define get_user get_user_ret
#define __get_user __get_user_ret
#define put_user put_user_ret
#define __put_user __put_user_ret
#define copy_from_user copy_from_user_ret
#define __copy_from_user copy_from_user_ret
#define copy_to_user copy_to_user_ret
#define __copy_to_user copy_to_user_ret
By placing that code in the appropriate header file(s), the #define
statements will trickle down to the appropriate source files.
Hence the functions/macros without "_ret" can be eliminated, resulting
in code consolidation.
NOTE: The validity of using a #define Preprocessor Directive as a
Symbolic Constant on a function has been tested, and proven viable, in
the following sample program:
#include <iostream>
using std::cout;
using std::cin;
using std::endl;
void Hello();
void Hello_Again();
#define Hi Hello
#define Hi_Again Hello_Again
/*
void Hi();
void Hi_Again();
*/
int main() {
Hello();
Hello_Again();
Hi();
Hi_Again();
}
void Hello () {
cout << "Hello." << endl;
}
void Hello_Again() {
cout << "Hello, again." << endl;
}
/*
void Hi() {
cout << "Hi." << endl;
}
void Hi_Again() {
cout << "Hi, again." << endl;
}
*/
next reply other threads:[~2002-10-06 0:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-06 0:58 Joseph D. Wagner [this message]
2002-10-06 9:50 ` Good Idea (tm): Code Consolidation for Functions and Macros that Access the Process Address Space Russell King
2002-10-06 12:40 ` Joseph D. Wagner
2002-10-06 13:29 ` 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='000001c26cd3$950ef580$7975d73f@joe' \
--to=wagnerjd@prodigy.net \
--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 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.