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
> >thing?

	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()/
> seekdir().

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.

eric