Linux filesystem development
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@debian.org>
To: linux-fsdevel@vger.kernel.org
Subject: consting operations
Date: Fri, 11 Jul 2003 23:19:01 +0100	[thread overview]
Message-ID: <20030711221901.GO20424@parcelfarce.linux.theplanet.co.uk> (raw)


I was having an argument with Jeff Garzik about a completely unrelated
part of the kernel.  He wants to have an setup routine that initialises
various members of an ->*_ops vector to some default methods.  I wanted
to retaliate with "But that will be in read-only storage, so you can't
do that", but I realised that wasn't the case.

Which got me to wondering why our filesystem ops vectors aren't in
read-only storage.  As a test, I did ext2 and moved 764 bytes from .data
to .text -- not too significant, but not bad either (4 bytes disappeared
somewhere.  let's call it a rounding error).

Of course, just converting ext2 yields all kinds of warnings from the
compiler about discarding qualifiers.  We need to change linux/fs.h to
make all those things const .... and that splatters out to about 20 places
we need to let gcc know that yes, this local pointer really is const.

Worth it?  dunno.  Opinions?

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

             reply	other threads:[~2003-07-11 22:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-11 22:19 Matthew Wilcox [this message]
2003-07-11 22:30 ` consting operations Andrew Morton
2003-07-12  3:02   ` Matthew Wilcox
2003-07-11 22:47 ` Herbert Pötzl
2003-07-11 23:16   ` Trond Myklebust
2003-07-12 12:21     ` Herbert Pötzl
2003-07-14  7:08 ` David Woodhouse

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=20030711221901.GO20424@parcelfarce.linux.theplanet.co.uk \
    --to=willy@debian.org \
    --cc=linux-fsdevel@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