[RFC] Superblocks for pipes and sockets.
Alexander Viro (viro@math.psu.edu)
Mon, 22 Feb 1999 00:37:57 -0500 (EST)
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/