Messages in this thread | | | Date | Fri, 15 Oct 1999 16:35:08 +0200 | From | Jamie Lokier <> | Subject | Re: How to extend struct stat? |
| |
Matti Aarnio wrote: > +/* > + * New, some-improved getdents64() (for LFS) interface. > + */ > +struct linux_dirent64 { > + __u64 d_ino; /* 64-bit inode */ > + unsigned long d_off; /* Offset within the directory */ > + unsigned short d_reclen; > + char d_name[1]; > +};
This is not correct. Take a look at Glibc's <bits/types.h>. Glibc 2.1 defines __ino64_t as *32* bits on 32 bit architectures.
So your call is not binary compatible with Glibc and existing programs and Glibc would have to parse and reformat the results of getdents64 as it does already with getdents. I'd rather eliminate that overhead.
Perhaps this is a bug in Glibc, I don't know. If so, they should change __ino64_t and do the appropriate hacks for binary compatibility with old stuff.
> +struct getdents_callback64 { > + struct linux_dirent64 * current_dir; > + struct linux_dirent64 * previous; > + int count; > + int error; > +};
What's this used for?
> That done (after you tell me which fields to add into that dirent), > you have only the glibc side to do... And what parameters to add > to sys_getdents64() syscall.
We were discussing the d_type field, which goes in the new dirent structure. The structure is already defined in Glibc 2.1's <dirent.h> and <bits/dirent.h>. Note that d_ino is always unsigned long, and d_off is either unsigned long or unsigned long long depending on dirent/dirent64.
> I have infact wondered, how many of stat64 parameters could be > carried in to supply speeded up processing; mode, size, mtime ? > Full 'struct stat' ? (propably not)
None of them, unless you make the stat contents optional like NFSv3's readdirplus. Reading an inode implies considerable disk overhead.
> fs/readdir.c: sys_getdents() doesn't have user-space > supplied flag parameter to control call behaviour. > D'uh.. Must have separate call.
Yes, it should do what Glibc's getdirentries does because that's the call that almost all applications use. Currently there are also redundent lseek() calls for all apps that read directories because of the difference between getdents and getdirentries (BASEP).
fwiw, I have done the internal kernel API stuff. Patch to be posted soon.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |