From: David Howells <dhowells@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: David Howells <dhowells@redhat.com>,
torvalds@osdl.org, linux-kernel@vger.kernel.org,
uclinux-dev@uclinux.org
Subject: Re: [PATCH 1/2] NOMMU: Set BDI capabilities for /dev/mem and /dev/kmem
Date: Wed, 30 Aug 2006 09:38:42 +0100 [thread overview]
Message-ID: <19020.1156927122@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <20060829122851.690e5219.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
> Or you could use the approach I suggested, like wot everyone else does.
Ummm... I don't recall ever coming across a construct like that in the
kernel. That's not to say there isn't one, but if I did come across it, it
can't have been clear.
I have seen the use #ifdefs to selectively fill in an ops structure. Take
Ext3 for example:
struct inode_operations ext3_file_inode_operations = {
.truncate = ext3_truncate,
.setattr = ext3_setattr,
#ifdef CONFIG_EXT3_FS_XATTR
.setxattr = generic_setxattr,
.getxattr = generic_getxattr,
.listxattr = ext3_listxattr,
.removexattr = generic_removexattr,
#endif
.permission = ext3_permission,
};
So, no, _not_ everyone else follows your suggestion. This example makes it
instantly clear to anyone looking at it that those four ops are only used if
Ext3 is configured to use xattrs. Anything else lacks clarity.
> > Is doing a private mapping of /dev/mem a valid thing to do anyway, even if
> > there is an MMU?
>
> It would be strange, I guess. But the important thing is to not change
> behaviour.
Yeah, okay.
David
next prev parent reply other threads:[~2006-08-30 8:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-29 17:59 David Howells
2006-08-29 17:59 ` [PATCH 2/2] NOMMU: Check that access_process_vm() has a valid target David Howells
2006-08-29 18:20 ` [PATCH 1/2] NOMMU: Set BDI capabilities for /dev/mem and /dev/kmem Andrew Morton
2006-08-29 18:39 ` David Howells
2006-08-29 19:28 ` Andrew Morton
2006-08-30 8:38 ` David Howells [this message]
2006-08-30 15:05 ` Andrew Morton
2006-08-30 9:24 ` David Howells
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=19020.1156927122@warthog.cambridge.redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=uclinux-dev@uclinux.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
all inboxes | Powered by JetHome®