Re: Should struct inode be made available to userspace?

[viro]

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