> > > that also suggests that a passage on p. 91 of LKD3 is > inaccurate, > > > where it claims that "because the lists are circular, you can > > > generally pass any element for head." but that can't be right, > > > since you must *always* keep track of the head node for > any list, to > > > avoid processing it normally. if you simply drop someone into the > > > middle of a circular, doubly-linked kernel list, there is no way > > > that i can see to know which node in that list is the > head node when > > > you run across it during iteration. > > > > > > does this make sense? > > > > I think you are assuming that all lists have a separate list_head > > structure to locate the head of the list. I am not sure that is > > correct. For example, the task structures are linked toghether in a > > curcular list with no separate list_head structure. The > > init_task->tasks.next field is usually the starting point, but > > current->tasks.next should work just as well. > > that may be true, but if it is, it's a *very* special case > in that it represents a list that *starts* with an initial > entry (init_task), so it can be processed differently. can > you point out where a new entry is added to that particular list? >
New task structures are added into the list in kernel/fork.c (line 1743 in my source). But, my question is, how common is it for there to be a list without an external list_head structure. This is one example. It looks like some of the macros in list.h also assume there is an external list_head structure. For example, the list passed to list_splice() assumes it points to the list but is not part of the list. If the list parameter is an entry in the list, it will be lost. Bruce -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [email protected] Please read the FAQ at http://kernelnewbies.org/FAQ
