[lkml]   [2006]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Slimming down struct inode

On Thu, 15 Jun 2006, Theodore Tso wrote:
> I'm not particularly sympathetic to out of tree implementations,

I believe you asked for comments; not proposed to offer sympathy.

> especially one which is as (NOT!) likely to be merged as STREAMS
> support. Out of tree patches can always patch struct inode to add all
> the bloat they want.

Bloat that nobody complained about for 10 years or so... Sounds pretty
antagonistic to me. Streams are pretty basic character devices.

> Also, it souinds like you're not usually using
> i_pipe as a true pointer to a struct pipe_inode_info, but rather as
> kludged location to stash your v_str pointer.

It points to a STREAMS-based FIFO which, of course, uses a Stream head
structure instead of a pipe_inode_info structure. Is is used in the
same fashion as Linux FIFOs use the pointer: to attach information to
an inode in a foreign filesystem. generic_ip and such does not help
here because they are already used by the foreign filesystem.

The cdev structure used to have a private pointer (cd_private) that
could be used to the same effect, but it disappeared some time ago when
char_device was reworked into cdev. block_device still has a bd_private
pointer. Merging i_pipe will remove the ability for a character
device driver to association a private pointer with the inode at open
to obtain FIFO-like behaviour (where the device is associated with the
specific inode rather than the device number), reducing the flexibility
of the Linux VFS.

i_pipe is not necessary for Unnamed FIFOs or pipes in Linux (those
inodes are allocated from the pipefs and could very well use the
generic_ip pointer. i_pipe is only necessary for named FIFOs because
these are attached to inodes belonging to filesystems foreign to the
pipefs. It is a slim special case of file on file mounting. Regardless
of STREAMS I think that it deserves to be separate from i_cdev and

All other basic character device mechanisms either allocate their own
inodes or hang their private data off of the open file pointer. As
do STREAMS, which, aside from STREAMS-based FIFOs are basic character

> Why not just have your
> STREAMS implementation patch include/linux/fs.h to add a v_str pointer?

Because it does not patch the kernel but simply loads as a set of
GPL'ed kernel modules.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-15 10:29    [W:0.035 / U:2.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site