[TUHS] Tech Sq elevator [ really type-checking ]

[Theodore Y. Ts'o]

(Not sure this is appropriate for TUHS)

On Sun, Jan 12, 2020 at 04:01:02PM -0800, Jon Steinhart wrote:
> Larry McVoy writes:
> > On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote:
> > > 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.
> 
> 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)

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