Messages in this thread | | | Date | Sun, 8 Aug 2004 17:22:58 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [PATCH] Allow to disable shmem.o |
| |
On 8 Aug 2004, Andi Kleen wrote: > On Sun, Aug 08, 2004 at 09:07:05AM -0500, Matt Mackall wrote: > > +extern struct inode *ramfs_get_inode(struct super_block *sb, int mode, dev_t dev); > > +extern struct super_block *ramfs_get_sb(struct file_system_type *fs_type, > > + int flags, const char *dev_name, void *data); > > +extern struct file_operations ramfs_file_operations; > > +extern struct vm_operations_struct generic_file_vm_ops; > > This should be all in header files.
Yes.
> > + if (IS_ERR(shm_mnt)) > > + return (void *)shm_mnt; > > Why this strange cast?
Matt copied from shmem.c, so blame me. Strange cast because it's one of those IS_ERR things, an -errno hiding inside a pointer, and it's being propagated from an initialization error on shm_mnt to a runtime error on any struct file for that mount. I wrote (void *) because it seemed to express the ambiguity better than pretending struct file *.
> > + inode = ramfs_get_inode(root->d_sb, S_IFREG | S_IRWXUGO, 0); > > Hmm, won't this allow everybody else to open it in /proc/pid/fd/ ? > (existing shmem.c seems to use it too, but it looks a bit bogus)
But there's no fd associated with it?
Hugh
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |