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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
