lkml.org 
[lkml]   [2003]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Should struct inode be made available to userspace?
On Mon, Dec 29, 2003 at 08:40:00PM +0100, Mariusz Mazur wrote:
> Inside __KERNEL__ block in linux/fs.h there is a definition (looks rather
> kernel specific) of struct inode. This structure is used all over the
> headers, specificaly in ${fsname}_fs_i.h files containing
> ${fsname}_inode_info structures. The problem is ${fsname}_fs_i.h files are
> included in ${fsname}_fs.h files which in turn are often used by various
> programs. This results in compile time errors since normal programs don't
> define __KERNEL__ (they shouldn't) and thus while parsing
> ${fsname}_inode_info structures do not have access to the inode structure
> ("error: field `vfs_inode' has incomplete type").
> What is the complete, politicaly correct solution? (workarounds are of no use
> to me)
> Is it (a) struct inode should be made available to userspace (yuck), (b) no
> !kernel code should use struct inode (linux/${fsname}_fs_i.h files shouldn't
> be included anywhere... hell... maybe all linux/${fsname}* files shouldn't be
> available outside kernel!) or (c) this kind of structures should come with
> apps using it and not be a part of any kernel derived userspace headers.

struct inode and structures containing it should not be used outside of kernel.
Moreover, foo_fs.h should be seriously trimmed down and everything _not_
useful outside of kernel should be taken into fs/foo/*; other kernel code
also doesn't give a fsck for that stuff, so it should be private to filesystem
instead of polluting include/linux/*.
-
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: 2005-03-22 13:59    [W:0.286 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site