Re: [RFC PATCH for-next 1/4] epoll: struct epoll userspace definiton

[Nathaniel Yazdani <n1ght.4nd.d4y@gmail.com>]

On Tue, 2014-02-25 at 10:15 +0000, Eric Wong wrote:
> (Did you intend to Cc LKML on your original reply?)
> 
> Nathaniel Yazdani <n1ght.4nd.d4y@gmail.com> wrote:
> > On Sun, Feb 23, 2014 at 9:29 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > > Nathaniel Yazdani <n1ght.4nd.d4y@gmail.com> wrote:
> > >> +++ b/include/uapi/linux/eventpoll.h
> > >> @@ -61,6 +61,12 @@ struct epoll_event {
> > >>       __u64 data;
> > >>  } EPOLL_PACKED;
> > >>
> > >> +struct epoll {
> > >> +     int ep_fildes; /* file descriptor */
> > >> +     int ep_events; /* triggering events */
> > >> +     long long ep_ident; /* entry ID (cf. epoll_event->data) */
> > >> +} EPOLL_PACKED;
> > >
> > > Why not reuse the existing epoll_event struct?
> > >
> > >         struct epoll {
> > >                 int ep_fildes; /* file descriptor */
> > >                 struct epoll_event event;
> > >         } EPOLL_PACKED;
> > 
> > Well my first instinct was that doing it like that would be too messy,
> > but now that you mention it that'd probably be a much better
> > approach. In fact we could even do something like:
> > 
> > struct epoll {
> >         int ep_fildes; /* file descriptor */
> >         union {
> >                 struct epoll_event event;
> >                 struct {
> >                         int ep_events;
> >                         long long ep_ident;
> >                 } EPOLL_PACKED;
> >         };
> > } EPOLL_PACKED;
> > 
> > In order to keep things looking spiffy while also easing migration
> > from the old struct :)
> 
> I think you miss the point of my question.  What is the point of
> changing:
> 
> 	event.events => ep_events
> 	event.data   => ep_ident
> 
> in the first place?

Whoops, my bad, still haven't gotten my email client totally figured
out. I'll CC this back the mailing list so everyone else can follow
along.

My intent was just to give the struct a more Unix-like style (so
to speak), because when I started, it looked like entirely
different code paths would be needed for this sort of functionality.
Thankfully that wasn't the case, but still a new struct was
necessary. All that to say I don't have an issue embedding an
epoll_event over defining the fields directly, but I'd just
prefer not to.