> " " == H J Lu <[EMAIL PROTECTED]> writes:
> On Tue, Feb 27, 2001 at 03:04:32PM -0800, H . J . Lu wrote:
>> >entry->prev_cookie = entry->cookie;
>> > - p = xdr_decode_hyper(p, >cookie);
>> > + p = xdr_decode_hyper(p, cookie);
>> > + entry->cookie =
" " == H J Lu [EMAIL PROTECTED] writes:
On Tue, Feb 27, 2001 at 03:04:32PM -0800, H . J . Lu wrote:
entry-prev_cookie = entry-cookie;
- p = xdr_decode_hyper(p, entry-cookie);
+ p = xdr_decode_hyper(p, cookie);
+ entry-cookie = nfs_transform_cookie64(cookie);
On Tue, Feb 27, 2001 at 03:04:32PM -0800, H . J . Lu wrote:
> > entry->prev_cookie = entry->cookie;
> > - p = xdr_decode_hyper(p, >cookie);
> > + p = xdr_decode_hyper(p, cookie);
> > + entry->cookie = nfs_transform_cookie64(cookie);
>
> I don't understand this. As far as I can tell,
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote:
>
> The above fixes should ensure that all cookies taking values between 0
> and (2^32-1) on the NFS server are preserved through the 32-bit VFS
> interface, and are accepted by glibc as valid entries. It should also
> work fine
Trond Myklebust wrote:
> > " " == H J Lu <[EMAIL PROTECTED]> writes:
>
> > I much prefer to have a new getdents system call which will
> > also return d_type so that the 32 bit function in glibc can use
> > this new getdents instead of getdents64.
>
> That could also be done,
Trond Myklebust wrote:
" " == H J Lu [EMAIL PROTECTED] writes:
I much prefer to have a new getdents system call which will
also return d_type so that the 32 bit function in glibc can use
this new getdents instead of getdents64.
That could also be done, however it seems
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote:
The above fixes should ensure that all cookies taking values between 0
and (2^32-1) on the NFS server are preserved through the 32-bit VFS
interface, and are accepted by glibc as valid entries. It should also
work fine with
On Tue, Feb 27, 2001 at 03:04:32PM -0800, H . J . Lu wrote:
entry-prev_cookie = entry-cookie;
- p = xdr_decode_hyper(p, entry-cookie);
+ p = xdr_decode_hyper(p, cookie);
+ entry-cookie = nfs_transform_cookie64(cookie);
I don't understand this. As far as I can tell, "cookie"
> " " == H J Lu <[EMAIL PROTECTED]> writes:
> I much prefer to have a new getdents system call which will
> also return d_type so that the 32 bit function in glibc can use
> this new getdents instead of getdents64.
That could also be done, however it seems odd to be adding a
On Tue, Feb 27, 2001 at 07:57:36AM +0100, Trond Myklebust wrote:
> > " " == H J Lu <[EMAIL PROTECTED]> writes:
>
> > I don't know how it will work with real 64bit cookies on a
> > 32bit host for NFS V3 since you truncate it into 32bit during
> > sign extension.
>
> It won't
> " " == H J Lu <[EMAIL PROTECTED]> writes:
> I don't know how it will work with real 64bit cookies on a
> 32bit host for NFS V3 since you truncate it into 32bit during
> sign extension.
It won't for the moment, but that's a problem with the readdir() API
which uses the
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote:
>
> Hi,
>
> After having tried to thrash out what exactly is the kernel
> interface for telldir/seekdir w.r.t. the existence of negative offsets
> with the glibc people, I've finally found a way to work within the
> current
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote:
Hi,
After having tried to thrash out what exactly is the kernel
interface for telldir/seekdir w.r.t. the existence of negative offsets
with the glibc people, I've finally found a way to work within the
current scheme.
" " == H J Lu [EMAIL PROTECTED] writes:
I don't know how it will work with real 64bit cookies on a
32bit host for NFS V3 since you truncate it into 32bit during
sign extension.
It won't for the moment, but that's a problem with the readdir() API
which uses the 32-bit off_t
On Tue, Feb 27, 2001 at 07:57:36AM +0100, Trond Myklebust wrote:
" " == H J Lu [EMAIL PROTECTED] writes:
I don't know how it will work with real 64bit cookies on a
32bit host for NFS V3 since you truncate it into 32bit during
sign extension.
It won't for the moment,
" " == H J Lu [EMAIL PROTECTED] writes:
I much prefer to have a new getdents system call which will
also return d_type so that the 32 bit function in glibc can use
this new getdents instead of getdents64.
That could also be done, however it seems odd to be adding a new
32-bit
16 matches
Mail list logo
