Should struct inode be made available to userspace?
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.
Signature · 4 lines
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 }Quoted 8 lines · Mariusz Mazur
Inside
__KERNEL__block inlinux/fs.hthere 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
Quoted 8 lines
("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.hfiles 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/*.
Quoted 5 lines · [email protected] wrote:
struct inode and structures containing it should not be used outside of kernel. Moreover,
foo_fs.hshould be seriously trimmed down and everything _not_ useful outside of kernel should be taken intofs/foo/*; other kernel code also doesn't give a fsck for that stuff, so it should be private to filesystem instead of pollutinginclude/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.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 10 lines · Bill Davidsen
Quoted 7 lines · [email protected] wrote:
struct inode and structures containing it should not be used outside of kernel.
Moreover,foo_fs.hshould be seriously trimmed down and everything _not_ useful outside of kernel should be taken intofs/foo/*; other kernel code also doesn't give a fsck for that stuff, so it should be private to filesystem
instead of pollutinginclude/linux/*.
Quoted 4 lines
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.
Quoted 11 lines · [email protected] wrote:
Quoted 9 lines · Bill Davidsen
Quoted 5 lines · [email protected] wrote:
struct inode and structures containing it should not be used outside of kernel. Moreover,
foo_fs.hshould be seriously trimmed down and everything _not_ useful outside of kernel should be taken intofs/foo/*; other kernel code also doesn't give a fsck for that stuff, so it should be private to filesystem instead of pollutinginclude/linux/*.
Quoted 5 lines
Quoted 1 line
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.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 4 lines · At 1/3/2004 06:57 PM +0000, [email protected] wrote:
Quoted 1 line · Bill Davidsen
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 <[email protected]>
Quoted 7 lines · Jeff Woods
Quoted 6 lines · At 1/3/2004 06:57 PM +0000, [email protected] wrote:
Quoted 4 lines · Bill Davidsen
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.
Quoted 6 lines
Quoted 2 lines
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.