![]() | |||||||||||||
Messages in this thread |
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 [from the cache] ©2003-2008 | |||||||||||||