On Fri, Jul 05, 2013 at 04:41:00PM -0400, Jörn Engel wrote:
> On Mon, 3 June 2013 13:28:03 -0400, Joern Engel wrote:
> >
> > A purely janitorial patchset. A fairly common pattern is to take a
> > list, remove every object from it and do something with this object -
> > usually kfree() some varian
On Mon, 3 June 2013 13:28:03 -0400, Joern Engel wrote:
>
> A purely janitorial patchset. A fairly common pattern is to take a
> list, remove every object from it and do something with this object -
> usually kfree() some variant. A stupid grep identified roughly 300
> instances, with many more h
On Wed, Jun 05, 2013 at 08:53:50AM +0200, Arne Jansen wrote:
> On 05.06.2013 04:09, Jörn Engel wrote:
> > On Tue, 4 June 2013 14:44:35 -0400, Jörn Engel wrote:
> >>
> >> Or while_list_drain?
>
> I'm fine with while_list_drain, although a name starting with list_
> like all other list macros would
On 05.06.2013 04:09, Jörn Engel wrote:
> On Tue, 4 June 2013 14:44:35 -0400, Jörn Engel wrote:
>>
>> Or while_list_drain?
I'm fine with while_list_drain, although a name starting with list_
like all other list macros would be nice. How about just list_drain?
The next question is where to put it in
On Tue, 4 June 2013 14:44:35 -0400, Jörn Engel wrote:
>
> Or while_list_drain?
Not sure if the silence is approval or lack of interest, but a new set
of patches is posted. By playing around with the implementation a
bit, I have actually found a variant that makes the object code
shrink. Not one
On Tue, 4 June 2013 22:09:13 +0200, Arne Jansen wrote:
> On 06/04/13 16:53, Chris Mason wrote:
> > Quoting Christoph Hellwig (2013-06-04 10:48:56)
> >> On Mon, Jun 03, 2013 at 03:55:55PM -0400, J??rn Engel wrote:
> >>> Actually, when I compare the two invocations, I prefer the
> >>> list_for_each_e
On 06/04/13 16:53, Chris Mason wrote:
> Quoting Christoph Hellwig (2013-06-04 10:48:56)
>> On Mon, Jun 03, 2013 at 03:55:55PM -0400, J??rn Engel wrote:
>>> Actually, when I compare the two invocations, I prefer the
>>> list_for_each_entry_del() variant over list_pop_entry().
>>>
>>> while (
Quoting Christoph Hellwig (2013-06-04 10:48:56)
> On Mon, Jun 03, 2013 at 03:55:55PM -0400, J??rn Engel wrote:
> > Actually, when I compare the two invocations, I prefer the
> > list_for_each_entry_del() variant over list_pop_entry().
> >
> > while ((ref = list_pop_entry(&prefs, struct __p
On Mon, Jun 03, 2013 at 03:55:55PM -0400, J??rn Engel wrote:
> Actually, when I compare the two invocations, I prefer the
> list_for_each_entry_del() variant over list_pop_entry().
>
> while ((ref = list_pop_entry(&prefs, struct __prelim_ref, list))) {
> list_for_each_entry_del(ref
On Mon, 3 June 2013 15:36:47 -0400, Jörn Engel wrote:
> On Mon, 3 June 2013 13:49:30 -0700, Christoph Hellwig wrote:
> >
> > I can't say I like the structure.
> >
> > A list_pop that removes and entry from the head or returns NULL if the
> > list is empty would lead to nice while loops that are o
On Mon, 3 June 2013 13:49:30 -0700, Christoph Hellwig wrote:
>
> I can't say I like the structure.
>
> A list_pop that removes and entry from the head or returns NULL if the
> list is empty would lead to nice while loops that are obviously
> readable instead.
Something like this?
#define list_p
I can't say I like the structure.
A list_pop that removes and entry from the head or returns NULL if the
list is empty would lead to nice while loops that are obviously
readable instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
On Mon, 3 June 2013 13:28:03 -0400, Joern Engel wrote:
>
> Drawback is that object size is growing. I think an ideal compiler
> should be able to optimize all the overhead away, but 4.7 just isn't
> there yet. Or maybe I just messed up - patches are only
> compile-tested after all. Comments/ide
13 matches
Mail list logo
