Right now inodes (and dentries) belonging to pipes and sockets are treated in somewhat special way. That is, they have no associated superblocks. I mean *real* pipes and inodes, i.e. ones created by pipe(2), socket(2) and accept(2). It leads to quite a bit of special-case code in VFS. Proposed change: allocate some number (see below) of deviceless superblocks and assing said dentries/inodes to them. Required changes are surprisingly small - instead of d_alloc_root() we should call d_alloc() to allocate dentries and we should care to set the i_sb when we fill the inodes in question. Not a big deal - it's generic code present in every r/w filesystem. Additionally we should reserve several devices with major 0 (as we do for NFS) and do a very rudimentary read_super() on them (just set a few fields and allocate root inode and dentry). Making all superblock methods NULL will reproduce the current behaviour. The question being: how many superblocks do we need? In principle we can get out with a single sb for everything, but IMO it would be nice to go for 1 superblock for pipes + superblock per every protocol family (for sockets). Third variant being to to make a single sb for sockets and just create a directory for each protocol family. Reasons to separate protocol families: we may want to keep struct file's in per-sb lists (instead of single list we use now). That would speed up traversing the list of opened files (usually when we do it we are interested in files belonging to one superblock) and it would simplify the AF_UNIX garbage collector. Big way. That's a different story and material for separate patch, but I think that having separate superblocks from the very beginning will not hurt. Moreover, it will remove an ugly (IMHO) code in procfs responsible for readlink() on /proc/foo/fd/* stuff - we can simply assign the correponding names to root dentries. I.e. the special=case code for pipes and superblocks goes away and we are getting names a-la #pipe/543 or #ipx/42 for free. I'ld like to hear opinions on that. I have a preliminary patch and it adds about 100 lines of code. It also allows to remove several hundreds of lines in special-case checks ;-) It seems to work, but I'ld like to play with it for a day or so before posting it for testing. It is not going to have any impact on filesystems, but it definitely affects VFS, thus Cc: to fsdevel. Cheers, Al