[parisc-linux] getdents

[parisc-linux] getdents

[Matthew Wilcox]

I'm trying to implement the HPUX getdents syscall so that we can `-ls'
in sash.  Unfortunately, there appears to be no manual page on this.
Could someone let me know exactly what libc is expecting getdents
to return?  So far I have deduced the following:

It takes three parameters; a file descriptor, an address and a length
in bytes.  On return, that block of memory is filled with as many of
the following struct as will fit:

struct hpux_dirent {
	ino_t	d_ino;
	short	d_reclen;
	short	d_namlen;
	char	d_name[1];
};

But checking through the other compatibility implementations of getdents;
there is so much variation about what else might be returned in that
block that I would prefer to not speculate further unless I have to.

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] getdents

[Kevin Vajk]

On Wed, 3 Nov 1999, Matthew Wilcox wrote:

> struct hpux_dirent {
> 	ino_t	d_ino;
> 	short	d_reclen;
> 	short	d_namlen;
> 	char	d_name[1];
> };

Shouldn't that be d_name[256]?

Anyhow, here's how I think it works on HP-UX (somebody please correct
me if I'm wrong!):

There is a struct dirent, which applications know about, and then
there is a struct __dirent32 and a struct __dirent64, depending on
whether this is a 32- or 64-bit process.  sizeof(ino_t) is the
only difference between the 32- and 64-bit structures.
Let's just call this struct __dirent.

Now, this struct __dirent is just struct dirent, with some additional
stuff at the front.  The trouble is, I don't know what's tacked onto
the front of it, yet...  I'm looking.  If anybody knows, please
tell me!!!

Anyhow, here's the prototype:
    int getdents(int fd, char *buf, unsigned int count);
It fills in buf with struct __dirent entries.  libc then turns each
struct __dirent into a struct dirent for user consumption by just
returning &(__dirent->d_ino).

I realize this isn't much use, without a concrete definition of
the extra field(s) of struct __dirent, but I'll get one tomorrow,
I expect.  (I'm probably just looking in the wrong place or something.)

- Kevin Vajk
  <kvajk@ricochet.net>

Re: [parisc-linux] getdents

[Kevin Vajk]

OK, here we go:

   struct __dirent {
      uint64_t __d_off;                 /* "magic cookie" */
      _T_INO_T __d_ino;                 /* file number of entry */
      short    __d_reclen;              /* length of this record */
      short    __d_namlen;              /* length of string in d_name */
      char     __d_name[_MAXNAMLEN + 1];/* name must be no longer than this */
   };

Note that sizeof(_T_INO_T) varies depending on your system's bit-ness,
so this is really two structure definitions.

The d_off structure member is an offset for that directory entry.  I
don't know if anybody in user-space ever uses it; I doubt it.

- Kevin Vajk
  <kvajk@ricochet.net>

Re: [parisc-linux] getdents

[Matthew Wilcox]

On Wed, Nov 03, 1999 at 05:29:30PM -0800, Kevin Vajk wrote:
> 
> 
> OK, here we go:
> 
>    struct __dirent {
>       uint64_t __d_off;                 /* "magic cookie" */
>       _T_INO_T __d_ino;                 /* file number of entry */
>       short    __d_reclen;              /* length of this record */
>       short    __d_namlen;              /* length of string in d_name */
>       char     __d_name[_MAXNAMLEN + 1];/* name must be no longer than this */
>    };
> 
> Note that sizeof(_T_INO_T) varies depending on your system's bit-ness,
> so this is really two structure definitions.
> 
> The d_off structure member is an offset for that directory entry.  I
> don't know if anybody in user-space ever uses it; I doubt it.

I've done the following:

struct hpux_dirent {
	long	d_off_pad; /* we only have a 32-bit off_t */
	long	d_off;
	ino_t	d_ino;
	short	d_reclen;
	short	d_namlen;
	char	d_name[1];
};

I think that's the right way round to put the padding for a big-endian
machine.  Yes, I know it ought to be done properly, but we don't have
a put_user() that will cope with an 8-byte quantity yet.  Any volunteers?

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] getdents

[Grant Grundler]

Matthew Wilcox wrote:
...
> I've done the following:
> 
> struct hpux_dirent {
> 	long	d_off_pad; /* we only have a 32-bit off_t */
> 	long	d_off;
> 	ino_t	d_ino;
> 	short	d_reclen;
> 	short	d_namlen;
> 	char	d_name[1];
> };
> 
> I think that's the right way round to put the padding for a big-endian
> machine.

Mathew,
Sorry, it doesn't look right to me.
I not sure the following is "right" either but "looks more right":

#ifdef __LP64__
	long d_off;
#else
	int d_off_pad;
	int d_off;
#endif

The problem is the offset for the d_off has to be different for
32-bit applications than it will be for 64-bit applications.
gcc has to behave the same way if we want binary compatibility.
In "wide-mode" HP-UX compiler uses 64-bit long/pointer and int
remains 32-bit.  Ergo the name "LP64".

devresource.hp.com has a "HP-UX 64-bit Porting and Transition Guide,
June 1998" in the Document library. It's an interesting reference on
HP-UX kernel interacts with 32/64-bit binaries and has some interesting
gotchas.

hope this helps,
grant

Grant Grundler
Unix Developement Lab
+1.408.447.7253

Re: [parisc-linux] getdents

[Matthew Wilcox]

On Wed, Nov 03, 1999 at 05:12:57PM -0800, Kevin Vajk wrote:
> 
> On Wed, 3 Nov 1999, Matthew Wilcox wrote:
> 
> > struct hpux_dirent {
> > 	ino_t	d_ino;
> > 	short	d_reclen;
> > 	short	d_namlen;
> > 	char	d_name[1];
> > };
> 
> Shouldn't that be d_name[256]?

It's OK, that's only used as an offset to tell the kernel where to put the
string.

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson