stat very inefficient
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · David S. Miller
1) From inode to "struct kstat"
2) From "struct kstat" to "struct stat{,64}" on local kernel stack
3) From local kernel stack to userspace
[...]
Quoted 5 lines
I was about to make sparc64 specific copies of all the stat system calls in order to optimize this properly. But that makes little sense, instead I think
fs/stat.cshould call upon arch-specific stat{,64} structure fillin routines that can do the magic, given a kstat struct.
I think wrappers are preferable to callbacks. Basically step (2) should be eliminated.
Most architectures can use a generic wrapper for that, together with a standard macro that clears all the padding in user space.
-Andi
Quoted 2 lines · On Wed, 28 Jul 2004 12:16:40 +0200 Andi Kleen <[email protected]> wrote:
Most architectures can use a generic wrapper for that, together with a standard macro that clears all the padding in user space.
They can't be seperate though, I don't want:
fill_in_stat_bits(); zero_out_padding_parts();
because that disturbs the ascending store stream which I'm trying to retain.
What I really want to do on Sparc64 is a special inline assembly that looks a lot like put_user() but uses one exception table entry for all the stores into the stat{,64} structure in userspace.
How would you wrapper look? Perhaps I'm confused and it allows what I want to do.