lkml.org 
[lkml]   [2006]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Slimming down struct inode
Theodore,

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
i_bdev.

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
devices.


> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  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