Re: [PATCH] linux/kernel.h: add container_from()

2020-08-28 Thread Allen
> > > You really have to pick some pretty excessive type names (or variable > > > names) to get close to 80 characters. Again, to pick an example: > > > > > > struct timer_group_priv *priv = container_of(handle, > > > struct timer_group_priv, timer[handle->num]); >

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-28 Thread Allen
> > I don't see that kind of redundancy being a _problem_, though. "So > much redundancy" is just over-stating the issue completely. > > In fact, we often encourage people to split declaration from > initialization exactly because it results in simpler expressions and > more legible code, even if

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread Kees Cook
On Thu, Aug 27, 2020 at 10:36:36PM +0100, Al Viro wrote: > On Thu, Aug 27, 2020 at 01:46:33PM -0700, Linus Torvalds wrote: > > You really have to pick some pretty excessive type names (or variable > > names) to get close to 80 characters. Again, to pick an example: > > > > struct

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread Al Viro
On Thu, Aug 27, 2020 at 01:46:33PM -0700, Linus Torvalds wrote: > You really have to pick some pretty excessive type names (or variable > names) to get close to 80 characters. Again, to pick an example: > > struct timer_group_priv *priv = container_of(handle, >

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread Linus Torvalds
On Thu, Aug 27, 2020 at 12:28 PM Kees Cook wrote: > > The common raw pattern for callbacks is: > > void callback(struct callback_handle *inner) > { > struct outer *instance; > ... > instance = container_of(inner, struct outer, member_name_of_inner); > > There's so much

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread Kees Cook
On Thu, Aug 27, 2020 at 11:48:19AM -0700, Linus Torvalds wrote: > On Thu, Aug 27, 2020 at 11:40 AM Linus Torvalds > wrote: > > > > On Thu, Aug 27, 2020 at 11:32 AM James Bottomley > > wrote: > > > > > > > > > The tasklet rework people don't want to use container_of, which was our > > > first

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread Linus Torvalds
On Thu, Aug 27, 2020 at 11:40 AM Linus Torvalds wrote: > > On Thu, Aug 27, 2020 at 11:32 AM James Bottomley > wrote: > > > > > > The tasklet rework people don't want to use container_of, which was our > > first suggestion, because it produces lines which are "too long". > > WTF? Side note: I'm

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread Linus Torvalds
On Thu, Aug 27, 2020 at 11:32 AM James Bottomley wrote: > > > The tasklet rework people don't want to use container_of, which was our > first suggestion, because it produces lines which are "too long". WTF? Next somebody will decide that our list handling macros don't match their mood, and make

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread James Bottomley
On Thu, 2020-08-27 at 11:04 -0700, Linus Torvalds wrote: > On Wed, Aug 26, 2020 at 6:36 PM Allen Pais > wrote: > > > > Introduce container_from() as a generic helper instead of > > sub-systems defining a private from_ > > NAK. > > This seems completely broken. > > The documentation comment

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread Rasmus Villemoes
On 27/08/2020 03.36, Allen Pais wrote: > Introduce container_from() as a generic helper instead of > sub-systems defining a private from_* API > (Eg: from_tasklets recently introduced in > 12cc923f1ccc: Tasklet: Introduce new initialization API) > > The helper is similar to container_of() in

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread Linus Torvalds
On Wed, Aug 26, 2020 at 6:36 PM Allen Pais wrote: > > Introduce container_from() as a generic helper instead of > sub-systems defining a private from_ NAK. This seems completely broken. The documentation comment doesn't even match the macro, and claims that "container" is a type. Which it

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread Kees Cook
On Thu, Aug 27, 2020 at 02:19:41PM +0200, Greg Kroah-Hartman wrote: > On Wed, Aug 26, 2020 at 07:31:40PM -0700, Kees Cook wrote: > > On Thu, Aug 27, 2020 at 07:06:36AM +0530, Allen Pais wrote: > > > Introduce container_from() as a generic helper instead of > > > sub-systems defining a private

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-27 Thread Greg Kroah-Hartman
On Wed, Aug 26, 2020 at 07:31:40PM -0700, Kees Cook wrote: > On Thu, Aug 27, 2020 at 07:06:36AM +0530, Allen Pais wrote: > > Introduce container_from() as a generic helper instead of > > sub-systems defining a private from_* API > > (Eg: from_tasklets recently introduced in > > 12cc923f1ccc:

Re: [PATCH] linux/kernel.h: add container_from()

2020-08-26 Thread Kees Cook
On Thu, Aug 27, 2020 at 07:06:36AM +0530, Allen Pais wrote: > Introduce container_from() as a generic helper instead of > sub-systems defining a private from_* API > (Eg: from_tasklets recently introduced in > 12cc923f1ccc: Tasklet: Introduce new initialization API) > > The helper is similar to

[PATCH] linux/kernel.h: add container_from()

2020-08-26 Thread Allen Pais
Introduce container_from() as a generic helper instead of sub-systems defining a private from_* API (Eg: from_tasklets recently introduced in 12cc923f1ccc: Tasklet: Introduce new initialization API) The helper is similar to container_of() in argument order with the difference of naming the