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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <1393373618.2886.26.camel@linux-whg8.site>
Date:	Tue, 25 Feb 2014 16:13:38 -0800
From:	Nathaniel Yazdani <n1ght.4nd.d4y@...il.com>
To:	Eric Wong <normalperson@...t.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH for-next 1/4] epoll: struct epoll userspace definiton

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@...il.com> wrote:
> > On Sun, Feb 23, 2014 at 9:29 PM, Eric Wong <normalperson@...t.net> wrote:
> > > Nathaniel Yazdani <n1ght.4nd.d4y@...il.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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/