[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19020.1156927122@warthog.cambridge.redhat.com>
Date: Wed, 30 Aug 2006 09:38:42 +0100
From: David Howells <dhowells@...hat.com>
To: Andrew Morton <akpm@...l.org>
Cc: David Howells <dhowells@...hat.com>, torvalds@...l.org,
linux-kernel@...r.kernel.org, uclinux-dev@...inux.org
Subject: Re: [PATCH 1/2] NOMMU: Set BDI capabilities for /dev/mem and /dev/kmem
Andrew Morton <akpm@...l.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists