lkml.org 
[lkml]   [2016]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v1 03/19] fs/anon_inodes: new interface to create new inode
From
Date


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

\
 
 \ /
  Last update: 2016-03-11 16:01    [W:0.052 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site