Subject: Re: problem with tmpfs and linux emulation?
To: Steven M. Bellovin <firstname.lastname@example.org>
From: Eric Haszlakiewicz <email@example.com>
Date: 11/15/2005 02:30:26
On Mon, Nov 14, 2005 at 07:31:14PM -0500, Steven M. Bellovin wrote:
> In message <20051114233622.GA12603@gurney.reilly.home>, Andrew Reilly writes:
> >On Sun, Nov 13, 2005 at 07:49:38PM -0500, Steven M. Bellovin wrote:
> >> It seems likely that nothing will make this work short of a real byte
> >> offset in d_off. This in turn suggests that either the linux emulation
> >> layer has to have a way of knowing if it needs to do a conversion, or
> >> the file system layer needs to do the conversion, possibly as a result
> >> of a mount-time flag. I'd really rather avoid the latter if possible
> >> -- how expensive would it be for tmpfs to maintain a real byte count?
> >> (Seeking to that point need not be cheap; it's an infrequent operation,
> >> I suspect.)
> >Is it not possible to have the emulated lseek understand the
> >opaque cookies (perhaps with a hash lookup) and do the right
It _does_ do the right thing. Calling lseek saves that opaque
cookie in the fp->fp_offset, which then (int vn_readdir) ends up in a
uio_offset, which then gets used by tmpfs_dir_offset().
tmpfs directories are linked lists, so there _isn't_ a byte offset.
> I haven't looked at the code, but I suspect that that doesn't work well
> -- when do you purge the table?
How about when the directory is closed?
> >What is the good of passing an opaque cookie out to user-land if
> >it's not subsequently useful for something?
> Good question, unless it's the sort of cookie used by telldir()/
fwiw, it looks like glibc when built on a bsd system has a telldir()/seekdir()
implementation that uses a process-global hashtable to causes telldir()
to always return an increasing value each time it is called, even if the
d_off "cookies" that getdents returned aren't.