Re: [PATCH v1 03/19] fs/anon_inodes: new interface to create new inode

[Gioh Kim]

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@xxxxxxxxxxx>
> >
> > 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