All of lore.kernel.org
 help / color / mirror / Atom feed
From: viro@parcelfarce.linux.theplanet.co.uk
To: Mariusz Mazur <mmazur@kernel.pl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Should struct inode be made available to userspace?
Date: Mon, 29 Dec 2003 19:57:42 +0000	[thread overview]
Message-ID: <20031229195742.GL4176@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <200312292040.00409.mmazur@kernel.pl>

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/*.

  reply	other threads:[~2003-12-29 20:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-29 19:40 Should struct inode be made available to userspace? Mariusz Mazur
2003-12-29 19:57 ` viro [this message]
2004-01-03 18:39   ` Bill Davidsen
2004-01-03 18:57     ` viro
2004-01-04  5:43       ` Bill Davidsen
2004-01-04  5:45       ` Jeff Woods
2004-01-04  6:28         ` viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031229195742.GL4176@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmazur@kernel.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.