[email protected] 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 <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Sat, Jan 03, 2004 at 01:39:41PM -0500, Bill Davidsen wrote:
> [email protected] 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.
At 1/3/2004 06:57 PM +0000, [email protected] 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 <[email protected]>
[email protected] wrote:
> On Sat, Jan 03, 2004 at 01:39:41PM -0500, Bill Davidsen wrote:
>
>>[email protected] 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 <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Sat, Jan 03, 2004 at 09:45:47PM -0800, Jeff Woods wrote:
> At 1/3/2004 06:57 PM +0000, [email protected] 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.