Should struct inode be made available to userspace?

Should struct inode be made available to userspace?

[Mariusz Mazur]

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.



-- 
Każdy człowiek, który naprawdę żyje, nie ma charakteru, nie może go mieć.
Charakter jest zawsze martwy, otacza cię zgniła struktura przeniesiona z 
przeszłości. Jeżeli działasz zgodnie z charakterem wtedy nie działasz w ogóle
- jedynie mechanicznie reagujesz.                 { Osho }

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

Re: Should struct inode be made available to userspace?

[Bill Davidsen]

viro@parcelfarce.linux.theplanet.co.uk wrote:

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

Moving the definitions is fine, but some user programs, like backup 
programs, do benefit from direct interpretation of the inode. Clearly 
that's not a normal user program, but this information is not only 
useful inside the kernel.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: Should struct inode be made available to userspace?

[viro]

On Sat, Jan 03, 2004 at 01:39:41PM -0500, Bill Davidsen wrote:
> viro@parcelfarce.linux.theplanet.co.uk wrote:
> 
> >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/*.
> 
> Moving the definitions is fine, but some user programs, like backup 
> programs, do benefit from direct interpretation of the inode. Clearly 
> that's not a normal user program, but this information is not only 
> useful inside the kernel.

No, they do not.  They care about on-disk structures, not the in-core
ones fs driver happens to build.

Re: Should struct inode be made available to userspace?

[Bill Davidsen]

viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Sat, Jan 03, 2004 at 01:39:41PM -0500, Bill Davidsen wrote:
> 
>>viro@parcelfarce.linux.theplanet.co.uk wrote:
>>
>>
>>>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/*.
>>
>>Moving the definitions is fine, but some user programs, like backup 
>>programs, do benefit from direct interpretation of the inode. Clearly 
>>that's not a normal user program, but this information is not only 
>>useful inside the kernel.
> 
> 
> No, they do not.  They care about on-disk structures, not the in-core
> ones fs driver happens to build.

Pardon, I thought that was exactly what was being suggested to hide.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: Should struct inode be made available to userspace?

[Jeff Woods]

At 1/3/2004 06:57 PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
>On Sat, Jan 03, 2004 at 01:39:41PM -0500, Bill Davidsen wrote:
>>Moving the definitions is fine, but some user programs, like backup 
>>programs, do benefit from direct interpretation of the inode. Clearly 
>>that's not a normal user program, but this information is not only useful 
>>inside the kernel.
>
>No, they do not.  They care about on-disk structures, not the in-core ones 
>fs driver happens to build.

They may if trying to do an online backup of open files, especially if 
attempting to maintain transactional integrity (i.e. make the backup 
logically atomic).

--
Jeff Woods <kazrak+kernel@cesmail.net> 

Re: Should struct inode be made available to userspace?

[viro]

On Sat, Jan 03, 2004 at 09:45:47PM -0800, Jeff Woods wrote:
> At 1/3/2004 06:57 PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> >On Sat, Jan 03, 2004 at 01:39:41PM -0500, Bill Davidsen wrote:
> >>Moving the definitions is fine, but some user programs, like backup 
> >>programs, do benefit from direct interpretation of the inode. Clearly 
> >>that's not a normal user program, but this information is not only useful 
> >>inside the kernel.
> >
> >No, they do not.  They care about on-disk structures, not the in-core ones 
> >fs driver happens to build.
> 
> They may if trying to do an online backup of open files, especially if 
> attempting to maintain transactional integrity (i.e. make the backup 
> logically atomic).

*ROTFL*

Excuse me, what sort of atomicity are you talking about?  If that "program"
pokes around in kernel memory and accesses (nevermind how found) in-core
inodes, it's not just not atomic, it's obviously racy in all sorts of
interesting ways.  struct inode can be freed at any point _and_ userland
code can lose timeslice and not regain it in quite a while.

If any backup program tries to pull that off, I would really like to see
the names of its "designers" posted for public ridicule.  If such duhvelopers
actually exist, they more than deserve recognition.