Re: [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in sysfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Chris Wilson (2020-02-29 18:34:49)
> 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!

Though it is still a libc structure rather than the syscall definition
:(
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux