Gosh, thanks for mentioning that, you're right, it hasn't. I saw
git pull updating mm/tiny-shmem.c a few days ago, and took it for
granted that that was the #ifndef CONFIG_MMU fixed version; but it
was the earlier one without that fix, despite us all knowing that
fix was needed. I'd have pushed it myself for -rc8 if I'd realized
it was still missing: Nick, please push it to Linus a.s.a.p. (with
Acks from Matt and David and me) - or ask me to do so (I'm not sure
That's much nicer than I'd been imagining, thanks Matt: I've no qualms
about the few #ifdefs you're adding to mm/shmem.c, it does seem an
outright improvement that you're bringing them together.
(It's slightly confusing that !CONFIG_SHMEM now builds mm/shmem.c;
This ifndef is the ugliest part of it: and looking into it, guess
what, shmem_get_unmapped_area() hasn't been used since 2.6.20 -
that's right, isn't it, David?
So please make a separate preliminary patch to remove it from
mm/tiny-shmem.c and include/linux/mm.h, so that little ugliness
never gets here - or if you think that's the wrong way around,
I'd prefer to rearrange that:
#define shmem_vm_ops generic_file_vm_ops
#define shmem_file_operations ramfs_file_operations
#define shmem_get_inode ramfs_get_inode
#define shmem_acct_size(a, b) 0
#define shmem_unacct_size(a, b) do { } while (0)
#define SHMEM_MAX_BYTES LLONG_MAX
Your LONG_MAX is too limiting, since it's on a loff_t:
CONFIG_SHMEM limits files according to the range of its swap
tables, but ramfs doesn't require that extra limitation, and
LONG_MAX could be too small on 32-bit. And hopefully gcc will
On a different but related subject:
do you think we need to retain the CONFIG_TMPFS option? It's rather
odd these days, since everybody gets ramfs, and you give them tmpfs
via ramfs without CONFIG_SHMEM. If anybody wants to cut out the
TMPFS code overhead these days, wouldn't they be using !CONFIG_SHMEM?
Hugh
--
