On Thu, Jan 25, 2024 at 04:23:58PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Jan 25, 2024 at 04:11:28PM -0800, Joe Damato wrote:
> > On Thu, Jan 25, 2024 at 03:21:46PM -0800, Greg Kroah-Hartman wrote:
> > > On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote:
> > > > +struct epoll_params {
> > > > + u64 busy_poll_usecs;
> > > > + u16 busy_poll_budget;
> > > > +
> > > > + /* for future fields */
> > > > + u8 data[118];
> > > > +} EPOLL_PACKED;
> > >
> > > variables that cross the user/kernel boundry need to be __u64, __u16,
> > > and __u8 here.
> >
> > I'll make that change for the next version, thank you.
> >
> > > And why 118?
> >
> > I chose this arbitrarily. I figured that a 128 byte struct would support 16
> > u64s in the event that other fields needed to be added in the future. 118
> > is what was left after the existing fields. There's almost certainly a
> > better way to do this - or perhaps it is unnecessary as per your other
> > message.
> >
> > I am not sure if leaving extra space in the struct is a recommended
> > practice for ioctls or not - I thought I noticed some code that did and
> > some that didn't in the kernel so I err'd on the side of leaving the space
> > and probably did it in the worst way possible.
>
> It's not really a good idea unless you know exactly what you are going
> to do with it. Why not just have a new ioctl if you need new
> information in the future? That's simpler, right?
Sure, that makes sense to me. I'll remove it in the v4 alongside the other
changes you've requested.
Thanks for your time and patience reviewing my code. I greatly appreciate
your helpful comments and feedback.
Thanks,
Joe
