Messages in this thread | | | Subject | Re: [PATCH v1 03/19] fs/anon_inodes: new interface to create new inode | From | Gioh Kim <> | Date | Fri, 11 Mar 2016 15:24:36 +0100 |
| |
On 11.03.2016 09:05, Al Viro wrote: > On Fri, Mar 11, 2016 at 04:30:07PM +0900, Minchan Kim wrote: >> From: Gioh Kim <gurugio@hanmail.net> >> >> The anon_inodes has already complete interfaces to create manage >> many anonymous inodes but don't have interface to get >> new inode. Other sub-modules can create anonymous inode >> without creating and mounting it's own pseudo filesystem. > IMO that's a bad idea. In case of aio "creating and mounting" takes this: > static struct dentry *aio_mount(struct file_system_type *fs_type, > int flags, const char *dev_name, void *data) > { > static const struct dentry_operations ops = { > .d_dname = simple_dname, > }; > return mount_pseudo(fs_type, "aio:", NULL, &ops, AIO_RING_MAGIC); > } > and > static struct file_system_type aio_fs = { > .name = "aio", > .mount = aio_mount, > .kill_sb = kill_anon_super, > }; > aio_mnt = kern_mount(&aio_fs); > > All of 12 lines. Your export is not much shorter. To quote old mail on > the same topic: I know what aio_setup() does. It can be a solution. But I thought creating anon_inode_new() is simpler than several drivers create its own pseudo filesystem. Creating a filesystem requires memory allocation and locking some lists even though it is pseudo.
Could you inform me if there is a reason we should avoid creating anonymous inode?
> >> Note that anon_inodes.c reason to exist was "it's for situations where >> all context lives on struct file and we don't need separate inode for >> them". Going from that to "it happens to contain a handy function for inode >> allocation"...
-- Best regards, Gioh Kim
| |