关于unix socket bind时socket与新创建的文件绑定问题讨论

关于unix socket bind时socket与新创建的文件绑定问题讨论

背景:unix socket bind时,会根据用户传进来的path创建一个socket文件,并和使用fd找到的socket链接在一起。但是由于socket在创建时已为inode,在bind时还要为socket创建一个带有路径的inode?这是冲突的。

目前的解决思路是找到办法使得bind时使用path创建的文件能够使用它找到被bind的socket inode。目前想到的解决方案有三个,一是在全局建立表记录所有调用过bind绑定文件地址的unix socket inode,使用path创建的文件查询unix socket inode。二是使用path创建的inode作为unix socket addr的成员,在bind时对addr进行更新,在全局建立表记记录listen状态的socket,使用该socket的addr里的path创建的文件查询。三是找个文件系统收留socket文件,使其能用link去绑定,当然实现sockfs自然是最终方案。

其实就是希望解决能使用用户传进来的path与目标socket进行绑定,后续能通过这个路径找到该socket。

2 个赞

目前如果采用path创建的inode(简称pnode)与socket inode(简称snode)建表查询,发现有两个问题,
1.pnode不能直接创建为snode类型,所以Endpoint可能得多加一个枚举,在bind时传入pnode与socket 自身snode建表,所以得在stream/seqpacket new()时就得绑定自身的snode使得在建表获取到这个snode
2.可能不能直接使用pnode作为索引见表,在测试过程中,用open的逻辑去创建和查找一个文件的inode,发现创建的inode和两次查找的inode的Arc指针都不指向同一个,但是文件名和inode_id都相同


2 个赞

建表链接pnode与inode确实可行;虽然更优雅的方法应该是把dentry抽象出来……不过对于这个索引确实没有很高的性能要求,建表查inode id我觉得没有问题。