All of lore.kernel.org
 help / color / mirror / Atom feed
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;
}
*/



             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.