13 Jan
2020
13 Jan
'20
6:44 a.m.
(Not sure this is appropriate for TUHS)
On Sun, Jan 12, 2020 at 04:01:02PM -0800, Jon Steinhart wrote:
Larry McVoy writes:
There are many places where there is a desire to
(a) add an object to the end of the list
(b) remove an object from a linked list where the object was not found
via iterating over the linked list
One or the other was true for all of the linked lists that you
complained about earlier up-thread. For example, a struct super has a
doubly linked list of struct mount where we might want to drop a
struct mount without needing iterate over the whole linked list.
So "just use an open-coded singly linked list" is really not that
simple. In addition, it should be noted that there are
read-copy-update variants of these functions (e.g.,
list_for_each_entry_rcu, list_del_rcu) that can be used with the same
struct list_head structure.
Sure, it would be simpler to just take a global kernel lock, and
iterating over the entire singly linked list to remove an object from
it, or adding an object to the end of a list. That would be
*simpler*. But that would be much more, not less, inefficient.
Cheers,
- Ted
On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon
Steinhart wrote:
I don't see it. In the cases that I've seen so far in linux the only uses are
inserting, deleting, and traversing lists. My opinion that anyone who can't
write
for (p = list; p != NULL; p = p->next) Linux contains several sets of
list_for_each_entry() macros that are essentially
obfuscated for loops that generate inefficient code.
Very common idiom in any real system. BitKeeper has them as well, they are
used everywhere. They are too useful to not use. The BitKeeper ones give
you most of Perl's list capabilities.