Quoting Andi Shyti (2020-02-29 12:45:27)
> > > > > > + char buf[512];
> > > > > > + int len;
> > > > > > +
> > > > > > + lseek(engines, 0, SEEK_SET);
> > > > > > + while ((len = syscall(SYS_getdents64, engines, buf, sizeof(buf))) > 0) {
> > > > > > + void *ptr = buf;
> > > > > > +
> > > > > > + while (len) {
> > > > > > + struct linux_dirent64 {
> > > > > > + ino64_t d_ino;
> > > > > > + off64_t d_off;
> > > > > > + unsigned short d_reclen;
> > > > > > + unsigned char d_type;
> > > > > > + char d_name[];
> > > > > > + } *de = ptr;
> > > > >
> > > > > what is the need for having your own linux_dirent64?
> > > >
> > > > fdopendir() takes ownership of the fd, preventing reuse. And
> > > > fdopendir(dup()) is getting ridiculous.
> > >
> > > why not using dirent64?
> >
> > It's still the same problem that it takes a DIR, assuming ownership of
> > the fd. Why using linux_dirent64 because the manpage says so -- if you
> > are going to use the syscall, you need to match it's calling
> > conventions, not a middleman's.
>
> I understand, but in bits/dirent.h there is, with some
> assumptions, this part:
>
> #ifdef __USE_LARGEFILE64
> struct dirent64
> {
> __ino64_t d_ino;
> __off64_t d_off;
> unsigned short int d_reclen;
> unsigned char d_type;
> char d_name[256]; /* We must not include limits.h! */
> };
> #endif
>
> why redefine a struct linux_dirent64?
Because the manpage didn't mention that!
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
