LinuxLists.cc - [TRIVIAL PATCH] Remove list

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

From: William Lee Irwin III <[email protected]>
Date: Sun, 1 Sep 2002 23:02:57 -0700

On Mon, Sep 02, 2002 at 01:51:54AM -0400, Robert Love wrote:
> I am all for your cleanup here, but two nits:
> Why not rename list_head while at it? I would vote for just "struct
> list" ... the name is long, and I like my lines to fit 80 columns.

Seconded. Throw the whole frog in the blender, please, not just half.

The problem is, it isn't a "list", it's a "list header" or "list
marker", ie. a list_head.

2002-09-02 06:19:55

by NeilBrown

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Sunday September 1, [email protected] wrote:
> On Mon, 2002-09-02 at 01:23, Rusty Russell wrote:
> >> This week, it spread to SCTP.
> >> "struct list_head" isn't a great name, but having two names for
> >> everything is yet another bar to reading kernel source.
>
> On Mon, Sep 02, 2002 at 01:51:54AM -0400, Robert Love wrote:
> > I am all for your cleanup here, but two nits:
> > Why not rename list_head while at it? I would vote for just "struct
> > list" ... the name is long, and I like my lines to fit 80 columns.
>
> Seconded. Throw the whole frog in the blender, please, not just
> half.

The struct in question is a handle on an element of a list, or the
head of a list, but it is not a list itself. A list is a number of
stuctures each of which contain (inherit from?) the particular
structure. So calling it "struct list" would be wrong, because it
isn't a list, only part of one.

Maybe "struct list_element" or "struct list_entry" would be OK. But
I'm happy with "struct list_head", because the thing is, at least
sometimes, the head of a list.

NeilBrown

2002-09-02 06:28:43

by William Lee Irwin III

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Sunday September 1, [email protected] wrote:
>> Seconded. Throw the whole frog in the blender, please, not just half.

On Mon, Sep 02, 2002 at 04:23:55PM +1000, Neil Brown wrote:
> The struct in question is a handle on an element of a list, or the
> head of a list, but it is not a list itself. A list is a number of
> stuctures each of which contain (inherit from?) the particular
> structure. So calling it "struct list" would be wrong, because it
> isn't a list, only part of one.
> Maybe "struct list_element" or "struct list_entry" would be OK. But
> I'm happy with "struct list_head", because the thing is, at least
> sometimes, the head of a list.

Why bother? It's obvious what it is, and the debate weighs more in terms
of bickering over what the most descriptive possible term is than all the
supposed fluff in terms of diffsize. Just give it an obvious name that
doesn't require so many extraneous characters to type and rest assured
in that this of all things is too obvious to mistake for anything else.
This much time and effort isn't useful to spend explaining or messing with
something as trivial as lists. Let names be short and kill the typedef.

Cheers,
Bill

2002-09-02 06:41:46

by Nick Piggin

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

For the code in question, a list entry _is_ a list is it not? By how big a
stretch of the
imagination is each entry a list in a different rotation?

----- Original Message -----
From: "Neil Brown" <[email protected]>
To: "William Lee Irwin III" <[email protected]>
Cc: "Robert Love" <[email protected]>; "Rusty Russell" <[email protected]>;
<[email protected]>; <[email protected]>; <[email protected]>
Sent: Monday, September 02, 2002 4:23 PM
Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

> On Sunday September 1, [email protected] wrote:
> > On Mon, 2002-09-02 at 01:23, Rusty Russell wrote:
> > >> This week, it spread to SCTP.
> > >> "struct list_head" isn't a great name, but having two names for
> > >> everything is yet another bar to reading kernel source.
> >
> > On Mon, Sep 02, 2002 at 01:51:54AM -0400, Robert Love wrote:
> > > I am all for your cleanup here, but two nits:
> > > Why not rename list_head while at it? I would vote for just "struct
> > > list" ... the name is long, and I like my lines to fit 80 columns.
> >
> > Seconded. Throw the whole frog in the blender, please, not just
> > half.
>
> The struct in question is a handle on an element of a list, or the
> head of a list, but it is not a list itself. A list is a number of
> stuctures each of which contain (inherit from?) the particular
> structure. So calling it "struct list" would be wrong, because it
> isn't a list, only part of one.
>
> Maybe "struct list_element" or "struct list_entry" would be OK. But
> I'm happy with "struct list_head", because the thing is, at least
> sometimes, the head of a list.
>
> NeilBrown
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2002-09-02 06:54:02

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

In message <1030945918.939.3143.camel@phantasy> you write:
> On Mon, 2002-09-02 at 01:23, Rusty Russell wrote:
>
> > This week, it spread to SCTP.
> >
> > "struct list_head" isn't a great name, but having two names for
> > everything is yet another bar to reading kernel source.
>
> I am all for your cleanup here, but two nits:
>
> Why not rename list_head while at it? I would vote for just "struct
> list" ... the name is long, and I like my lines to fit 80 columns.

Because renaming breaks things for no good reason. "list_head is
ugly" is insufficient cause: it doesn't cause bugs (cf. skb_realloc).

You want to clean up some ugliness? Find every
list_for_each/list_entry pair and substitute list_for_each_entry().

> Second, if we want to force people to change, we should remove "list_t"
> too to prevent new uses creeping in. Plus, like Linus says, it is often
> to break stuff and cleanup the mess...

I did: see the patch.

Really, I don't care whether it's "struct list_head" or "list_t", but
both is stupid. And since struct list_head is backwards compatible,
that's the winner here.

As someone who has been slowly feeding ISO-C declarated initializers
into 2.5, I am acutely aware of the cost of widespread change.

Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

2002-09-02 09:59:32

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Monday 02 September 2002 08:02, William Lee Irwin III wrote:
> On Mon, 2002-09-02 at 01:23, Rusty Russell wrote:
> >> This week, it spread to SCTP.
> >> "struct list_head" isn't a great name, but having two names for
> >> everything is yet another bar to reading kernel source.
>
> On Mon, Sep 02, 2002 at 01:51:54AM -0400, Robert Love wrote:
> > I am all for your cleanup here, but two nits:
> > Why not rename list_head while at it? I would vote for just "struct
> > list" ... the name is long, and I like my lines to fit 80 columns.
>
> Seconded. Throw the whole frog in the blender, please, not just half.

Thirded.

--
Daniel

2002-09-02 10:00:53

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Monday 02 September 2002 08:23, Neil Brown wrote:
> On Sunday September 1, [email protected] wrote:
> > On Mon, 2002-09-02 at 01:23, Rusty Russell wrote:
> > >> This week, it spread to SCTP.
> > >> "struct list_head" isn't a great name, but having two names for
> > >> everything is yet another bar to reading kernel source.
> >
> > On Mon, Sep 02, 2002 at 01:51:54AM -0400, Robert Love wrote:
> > > I am all for your cleanup here, but two nits:
> > > Why not rename list_head while at it? I would vote for just "struct
> > > list" ... the name is long, and I like my lines to fit 80 columns.
> >
> > Seconded. Throw the whole frog in the blender, please, not just
> > half.
>
> The struct in question is a handle on an element of a list, or the
> head of a list, but it is not a list itself. A list is a number of
> stuctures each of which contain (inherit from?) the particular
> structure. So calling it "struct list" would be wrong, because it
> isn't a list, only part of one.

Pffft. A struct page isn't a page either.

--
Daniel

2002-09-02 10:05:43

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Monday 02 September 2002 08:20, David S. Miller wrote:
> From: William Lee Irwin III <[email protected]>
> Date: Sun, 1 Sep 2002 23:02:57 -0700
>
> On Mon, Sep 02, 2002 at 01:51:54AM -0400, Robert Love wrote:
> > I am all for your cleanup here, but two nits:
> > Why not rename list_head while at it? I would vote for just "struct
> > list" ... the name is long, and I like my lines to fit 80 columns.
>
> Seconded. Throw the whole frog in the blender, please, not just half.
>
> The problem is, it isn't a "list", it's a "list header" or "list
> marker", ie. a list_head.

No it's not, it's nothing more nor less than a list node, identically,
a list.

--
Daniel

2002-09-02 10:10:32

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Monday 02 September 2002 12:05, David S. Miller wrote:
> From: Daniel Phillips <[email protected]>
> Date: Mon, 2 Sep 2002 12:11:53 +0200
>
> On Monday 02 September 2002 08:20, David S. Miller wrote:
> > The problem is, it isn't a "list", it's a "list header" or "list
> > marker", ie. a list_head.
>
> No it's not, it's nothing more nor less than a list node, identically,
> a list.
>
> A list node is markably different from "the list" itself.
>
> A "list" is the whole of all the nodes on the list, not just one
> of them.

Admit it, you never wrote a line of lisp ;-)

--
Daniel

2002-09-02 10:07:58

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

From: Daniel Phillips <[email protected]>
Date: Mon, 2 Sep 2002 12:11:53 +0200

On Monday 02 September 2002 08:20, David S. Miller wrote:
> The problem is, it isn't a "list", it's a "list header" or "list
> marker", ie. a list_head.

No it's not, it's nothing more nor less than a list node, identically,
a list.

A list node is markably different from "the list" itself.

A "list" is the whole of all the nodes on the list, not just one
of them.

2002-09-02 10:13:28

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

From: Daniel Phillips <[email protected]>
Date: Mon, 2 Sep 2002 12:16:45 +0200

Admit it, you never wrote a line of lisp ;-)

Oh contraire:

;; The most important function in this file. Use it wisely.
(defun grrr (object)
"Growl at OBJECT"
(interactive "sWhat are you mad at: ")
(if (equal object "")
(message "You growl at %s" (buffer-name))
(message "You growl at %s" object)))

(defun xyzzy () (interactive) (message "nothing happens"))

;; Defun needed for rmail growling hack below.
;;
(defun growl-at-from ()
"Search for from header in mail and growl at that person"
(save-excursion
(save-excursion
(goto-char 0)
(let ((case-fold-search t))
(setq from-location (search-forward "From:" nil))
(setq from-location (+ from-location 1))
(end-of-line)
(setq end-of-from-string (point))
(grrr (buffer-substring from-location end-of-from-string))))))

(add-hook 'rmail-show-message-hook 'growl-at-from)

;; Magic defun to grrr at people who send you mail.
(defun rmail-maybe-set-message-counters ()
"Same as normal defun in rmail.el except here
we growl at whoever the mail is from. Pretty crufty eh?"
(if (not (and rmail-deleted-vector
rmail-message-vector
rmail-current-message
rmail-total-messages))
(rmail-set-message-counters))
(growl-at-from))

2002-09-02 10:18:59

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Monday 02 September 2002 12:11, David S. Miller wrote:
> From: Daniel Phillips <[email protected]>
> Date: Mon, 2 Sep 2002 12:16:45 +0200
>
> Admit it, you never wrote a line of lisp ;-)
>
> Oh contraire:

[lots of irritating silly parentheses]

Great! Now we can communicate. (cdr from-location) is:

a) a list

or

b) a list marker?

--
Daniel

2002-09-02 10:25:41

by William Lee Irwin III

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Mon, Sep 02, 2002 at 03:05:53AM -0700, David S. Miller wrote:
> A list node is markably different from "the list" itself.
> A "list" is the whole of all the nodes on the list, not just one
> of them.

Linus will be the final arbiter of taste here. I've largely said my
peace, but will step forth from the shadows long enough to say the
decision here (and dear gawd, this is a trivial issue) hinges on this:
(1) one may describe the data structure as accurately as possible, so
struct list_marker, struct list_node, or (gawd forbid)
struct list_head is the proper name in this context.
(2) brevity is the soul of wit, and the rest may be assumed to be the
burden of knowing how to program, so struct list must be
twisted a very small bit so it's understood this is a list node
and/or head when the abbreviated name is used.
At this point, I beg of you all, defer to Linus and produce useful
things instead of debating this kind of issue endlessly. It's basic.
It's fundamental. It's trivial. And it's his kernel. Yes, I'm
authoritarian, and no, I'm not in charge. These simple things are too
easy to debate. The real coding lies elsewhere. Now let's move on please.

Thanks,
Bill

2002-09-02 10:23:43

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

From: Daniel Phillips <[email protected]>
Date: Mon, 2 Sep 2002 12:25:13 +0200

Great! Now we can communicate. (cdr from-location) is:

a) a list

or

b) a list marker?

It is a lisp object.

2002-09-03 22:10:33

by Jamie Lokier

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

David S. Miller wrote:
> A list node is markably different from "the list" itself.
>
> A "list" is the whole of all the nodes on the list, not just one
> of them.

Quite.

And that is why there should be _two_ types:

1. struct list
2. struct list_node

With these two types, `list_add' et al. can actually _check_ that you
got the arguments the right way around.

-- Jamie

2002-09-03 23:07:21

by Linus Torvalds

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Tue, 3 Sep 2002, Jamie Lokier wrote:
>
> 1. struct list
> 2. struct list_node
>
> With these two types, `list_add' et al. can actually _check_ that you
> got the arguments the right way around.

Well, the thing is, one of the _advantages_ of "struct list_head" is
exactly the fact that the implementation is 100% agnostic about whether a
list entry is the head, or just part of the list.

This was actually _the_ major design goal for me. I know the "struct
list_head" interfaces are kind of weird (some people initially really
didn't like the fact that you had to use magic macros to convert from
lists to the containing structures etc, and it's funny to think that a few
years ago that list structure was considered "strange"), but the fact that
any list entry can be the head of the list was very important.

Some uses of list_head uses "traditional" heads for the linked lists (as
heads for hashing etc), while many others just build up the list of all
entries, and each entry is a head in its own right and there is no
"external head" at all.

That's important. And you'd lose that if list_add() and friends tried to
distinguish between a list head and a list entry.

Linus

2002-09-04 01:31:04

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

In message <[email protected]> you
write:
>
> On Tue, 3 Sep 2002, Jamie Lokier wrote:
> >
> > 1. struct list
> > 2. struct list_node
> >
> > With these two types, `list_add' et al. can actually _check_ that you
> > got the arguments the right way around.
>
> Well, the thing is, one of the _advantages_ of "struct list_head" is
> exactly the fact that the implementation is 100% agnostic about whether a
> list entry is the head, or just part of the list.

Excellent. Well I'm glad that's sorted.

Now please apply my patch (which got sidelined by nomenclature fetishers),
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Name: list_t removal patch
Author: Rusty Russell
Section: Misc
Status: Trivial

D: This removes list_t, which is a gratuitous typedef for a "struct
D: list_head". Unless there is good reason, the kernel doesn't usually
D: typedef, as typedefs cannot be predeclared unlike structs.

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/include/linux/device.h .22733-linux-2.5.33.updated/include/linux/device.h
--- .22733-linux-2.5.33/include/linux/device.h 2002-08-28 09:29:52.000000000 +1000
+++ .22733-linux-2.5.33.updated/include/linux/device.h 2002-09-02 15:15:09.000000000 +1000
@@ -57,9 +57,9 @@ struct bus_type {
rwlock_t lock;
atomic_t refcount;

- list_t node;
- list_t devices;
- list_t drivers;
+ struct list_head node;
+ struct list_head devices;
+ struct list_head drivers;

struct driver_dir_entry dir;
struct driver_dir_entry device_dir;
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/include/linux/fs.h .22733-linux-2.5.33.updated/include/linux/fs.h
--- .22733-linux-2.5.33/include/linux/fs.h 2002-08-28 09:29:52.000000000 +1000
+++ .22733-linux-2.5.33.updated/include/linux/fs.h 2002-09-02 15:15:09.000000000 +1000
@@ -322,8 +322,8 @@ struct address_space {
struct list_head io_pages; /* being prepared for I/O */
unsigned long nrpages; /* number of total pages */
struct address_space_operations *a_ops; /* methods */
- list_t i_mmap; /* list of private mappings */
- list_t i_mmap_shared; /* list of private mappings */
+ struct list_head i_mmap; /* list of private mappings */
+ struct list_head i_mmap_shared; /* list of private mappings */
spinlock_t i_shared_lock; /* and spinlock protecting it */
unsigned long dirtied_when; /* jiffies of first page dirtying */
int gfp_mask; /* how to allocate the pages */
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/include/linux/list.h .22733-linux-2.5.33.updated/include/linux/list.h
--- .22733-linux-2.5.33/include/linux/list.h 2002-09-01 12:23:07.000000000 +1000
+++ .22733-linux-2.5.33.updated/include/linux/list.h 2002-09-02 15:15:09.000000000 +1000
@@ -19,12 +19,10 @@ struct list_head {
struct list_head *next, *prev;
};

-typedef struct list_head list_t;
-
#define LIST_HEAD_INIT(name) { &(name), &(name) }

#define LIST_HEAD(name) \
- list_t name = LIST_HEAD_INIT(name)
+ struct list_head name = LIST_HEAD_INIT(name)

#define INIT_LIST_HEAD(ptr) do { \
(ptr)->next = (ptr); (ptr)->prev = (ptr); \
@@ -36,7 +34,9 @@ typedef struct list_head list_t;
* This is only for internal list manipulation where we know
* the prev/next entries already!
*/
-static inline void __list_add(list_t *new, list_t *prev, list_t *next)
+static inline void __list_add(struct list_head *new,
+ struct list_head *prev,
+ struct list_head *next)
{
next->prev = new;
new->next = next;
@@ -52,7 +52,7 @@ static inline void __list_add(list_t *ne
* Insert a new entry after the specified head.
* This is good for implementing stacks.
*/
-static inline void list_add(list_t *new, list_t *head)
+static inline void list_add(struct list_head *new, struct list_head *head)
{
__list_add(new, head, head->next);
}
@@ -65,7 +65,7 @@ static inline void list_add(list_t *new,
* Insert a new entry before the specified head.
* This is useful for implementing queues.
*/
-static inline void list_add_tail(list_t *new, list_t *head)
+static inline void list_add_tail(struct list_head *new, struct list_head *head)
{
__list_add(new, head->prev, head);
}
@@ -77,7 +77,7 @@ static inline void list_add_tail(list_t
* This is only for internal list manipulation where we know
* the prev/next entries already!
*/
-static inline void __list_del(list_t * prev, list_t * next)
+static inline void __list_del(struct list_head * prev, struct list_head * next)
{
next->prev = prev;
prev->next = next;
@@ -88,7 +88,7 @@ static inline void __list_del(list_t * p
* @entry: the element to delete from the list.
* Note: list_empty on entry does not return true after this, the entry is in an undefined state.
*/
-static inline void list_del(list_t *entry)
+static inline void list_del(struct list_head *entry)
{
__list_del(entry->prev, entry->next);
entry->next = (void *) 0;
@@ -99,7 +99,7 @@ static inline void list_del(list_t *entr
* list_del_init - deletes entry from list and reinitialize it.
* @entry: the element to delete from the list.
*/
-static inline void list_del_init(list_t *entry)
+static inline void list_del_init(struct list_head *entry)
{
__list_del(entry->prev, entry->next);
INIT_LIST_HEAD(entry);
@@ -110,7 +110,7 @@ static inline void list_del_init(list_t
* @list: the entry to move
* @head: the head that will precede our entry
*/
-static inline void list_move(list_t *list, list_t *head)
+static inline void list_move(struct list_head *list, struct list_head *head)
{
__list_del(list->prev, list->next);
list_add(list, head);
@@ -121,7 +121,8 @@ static inline void list_move(list_t *lis
* @list: the entry to move
* @head: the head that will follow our entry
*/
-static inline void list_move_tail(list_t *list, list_t *head)
+static inline void list_move_tail(struct list_head *list,
+ struct list_head *head)
{
__list_del(list->prev, list->next);
list_add_tail(list, head);
@@ -131,16 +132,17 @@ static inline void list_move_tail(list_t
* list_empty - tests whether a list is empty
* @head: the list to test.
*/
-static inline int list_empty(list_t *head)
+static inline int list_empty(struct list_head *head)
{
return head->next == head;
}

-static inline void __list_splice(list_t *list, list_t *head)
+static inline void __list_splice(struct list_head *list,
+ struct list_head *head)
{
- list_t *first = list->next;
- list_t *last = list->prev;
- list_t *at = head->next;
+ struct list_head *first = list->next;
+ struct list_head *last = list->prev;
+ struct list_head *at = head->next;

first->prev = head;
head->next = first;
@@ -154,7 +156,7 @@ static inline void __list_splice(list_t
* @list: the new list to add.
* @head: the place to add it in the first list.
*/
-static inline void list_splice(list_t *list, list_t *head)
+static inline void list_splice(struct list_head *list, struct list_head *head)
{
if (!list_empty(list))
__list_splice(list, head);
@@ -167,7 +169,8 @@ static inline void list_splice(list_t *l
*
* The list at @list is reinitialised
*/
-static inline void list_splice_init(list_t *list, list_t *head)
+static inline void list_splice_init(struct list_head *list,
+ struct list_head *head)
{
if (!list_empty(list)) {
__list_splice(list, head);
@@ -177,7 +180,7 @@ static inline void list_splice_init(list

/**
* list_entry - get the struct for this entry
- * @ptr: the &list_t pointer.
+ * @ptr: the &struct list_head pointer.
* @type: the type of the struct this is embedded in.
* @member: the name of the list_struct within the struct.
*/
@@ -186,7 +189,7 @@ static inline void list_splice_init(list

/**
* list_for_each - iterate over a list
- * @pos: the &list_t to use as a loop counter.
+ * @pos: the &struct list_head to use as a loop counter.
* @head: the head for your list.
*/
#define list_for_each(pos, head) \
@@ -194,7 +197,7 @@ static inline void list_splice_init(list
pos = pos->next, prefetch(pos->next))
/**
* list_for_each_prev - iterate over a list backwards
- * @pos: the &list_t to use as a loop counter.
+ * @pos: the &struct list_head to use as a loop counter.
* @head: the head for your list.
*/
#define list_for_each_prev(pos, head) \
@@ -203,8 +206,8 @@ static inline void list_splice_init(list

/**
* list_for_each_safe - iterate over a list safe against removal of list entry
- * @pos: the &list_t to use as a loop counter.
- * @n: another &list_t to use as temporary storage
+ * @pos: the &struct list_head to use as a loop counter.
+ * @n: another &struct list_head to use as temporary storage
* @head: the head for your list.
*/
#define list_for_each_safe(pos, n, head) \
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/include/linux/mm.h .22733-linux-2.5.33.updated/include/linux/mm.h
--- .22733-linux-2.5.33/include/linux/mm.h 2002-09-01 12:23:07.000000000 +1000
+++ .22733-linux-2.5.33.updated/include/linux/mm.h 2002-09-02 15:15:09.000000000 +1000
@@ -61,7 +61,7 @@ struct vm_area_struct {
* one of the address_space->i_mmap{,shared} lists,
* for shm areas, the list of attaches, otherwise unused.
*/
- list_t shared;
+ struct list_head shared;

/* Function pointers to deal with this struct. */
struct vm_operations_struct * vm_ops;
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/include/linux/sched.h .22733-linux-2.5.33.updated/include/linux/sched.h
--- .22733-linux-2.5.33/include/linux/sched.h 2002-09-01 12:23:07.000000000 +1000
+++ .22733-linux-2.5.33.updated/include/linux/sched.h 2002-09-02 15:15:09.000000000 +1000
@@ -264,7 +264,7 @@ struct task_struct {
int lock_depth; /* Lock depth */

int prio, static_prio;
- list_t run_list;
+ struct list_head run_list;
prio_array_t *array;

unsigned long sleep_avg;
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/include/net/sctp/structs.h .22733-linux-2.5.33.updated/include/net/sctp/structs.h
--- .22733-linux-2.5.33/include/net/sctp/structs.h 2002-09-01 12:23:08.000000000 +1000
+++ .22733-linux-2.5.33.updated/include/net/sctp/structs.h 2002-09-02 15:17:45.000000000 +1000
@@ -203,7 +203,7 @@ struct SCTP_protocol {
/* This is a list of groups of functions for each address
* family that we support.
*/
- list_t address_families;
+ struct list_head address_families;

/* This is the hash of all endpoints. */
int ep_hashsize;
@@ -225,7 +225,7 @@ struct SCTP_protocol {
*
* It is a list of struct sockaddr_storage_list.
*/
- list_t local_addr_list;
+ struct list_head local_addr_list;
spinlock_t local_addr_lock;
};

@@ -250,7 +250,7 @@ typedef struct sctp_func {
__u16 net_header_len;
int sockaddr_len;
sa_family_t sa_family;
- list_t list;
+ struct list_head list;
} sctp_func_t;

sctp_func_t *sctp_get_af_specific(const sockaddr_storage_t *address);
@@ -494,7 +494,7 @@ const sockaddr_storage_t *sctp_source(co
* sin_addr -- cast to either (struct in_addr) or (struct in6_addr)
*/
struct sockaddr_storage_list {
- list_t list;
+ struct list_head list;
sockaddr_storage_t a;
};

@@ -582,7 +582,7 @@ void sctp_packet_free(sctp_packet_t *);
*/
struct SCTP_transport {
/* A list of transports. */
- list_t transports;
+ struct list_head transports;

/* Reference counting. */
atomic_t refcnt;
@@ -863,7 +863,7 @@ struct SCTP_bind_addr {
* has bound. This information is passed to one's
* peer(s) in INIT and INIT ACK chunks.
*/
- list_t address_list;
+ struct list_head address_list;

int malloced; /* Are we kfree()able? */
};
@@ -988,7 +988,7 @@ struct SCTP_endpoint {
* is implemented.
*/
/* This is really a list of sctp_association_t entries. */
- list_t asocs;
+ struct list_head asocs;

/* Secret Key: A secret key used by this endpoint to compute
* the MAC. This SHOULD be a cryptographic quality
@@ -1070,7 +1070,7 @@ struct SCTP_association {
sctp_endpoint_common_t base;

/* Associations on the same socket. */
- list_t asocs;
+ struct list_head asocs;

/* This is a signature that lets us know that this is a
* sctp_association_t data structure. Used for mapping an
@@ -1104,7 +1104,7 @@ struct SCTP_association {
*
* It is a list of SCTP_transport's.
*/
- list_t transport_addr_list;
+ struct list_head transport_addr_list;

/* port
* The transport layer port number.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/kernel/exit.c .22733-linux-2.5.33.updated/kernel/exit.c
--- .22733-linux-2.5.33/kernel/exit.c 2002-09-01 12:23:08.000000000 +1000
+++ .22733-linux-2.5.33.updated/kernel/exit.c 2002-09-02 15:15:09.000000000 +1000
@@ -407,7 +407,7 @@ void exit_mm(struct task_struct *tsk)
static inline void forget_original_parent(struct task_struct * father)
{
struct task_struct *p, *reaper;
- list_t *_p;
+ struct list_head *_p;

read_lock(&tasklist_lock);

@@ -477,7 +477,7 @@ static inline void zap_thread(task_t *p,
static void exit_notify(void)
{
struct task_struct *t;
- list_t *_p, *_n;
+ struct list_head *_p, *_n;

forget_original_parent(current);
/*
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/kernel/sched.c .22733-linux-2.5.33.updated/kernel/sched.c
--- .22733-linux-2.5.33/kernel/sched.c 2002-09-01 12:23:08.000000000 +1000
+++ .22733-linux-2.5.33.updated/kernel/sched.c 2002-09-02 15:15:09.000000000 +1000
@@ -133,7 +133,7 @@ typedef struct runqueue runqueue_t;
struct prio_array {
int nr_active;
unsigned long bitmap[BITMAP_SIZE];
- list_t queue[MAX_PRIO];
+ struct list_head queue[MAX_PRIO];
};

/*
@@ -152,7 +152,7 @@ struct runqueue {
int prev_nr_running[NR_CPUS];

task_t *migration_thread;
- list_t migration_queue;
+ struct list_head migration_queue;

} ____cacheline_aligned;

@@ -739,7 +739,7 @@ static void load_balance(runqueue_t *thi
int imbalance, idx, this_cpu = smp_processor_id();
runqueue_t *busiest;
prio_array_t *array;
- list_t *head, *curr;
+ struct list_head *head, *curr;
task_t *tmp;

busiest = find_busiest_queue(this_rq, this_cpu, idle, &imbalance);
@@ -937,7 +937,7 @@ asmlinkage void schedule(void)
task_t *prev, *next;
runqueue_t *rq;
prio_array_t *array;
- list_t *queue;
+ struct list_head *queue;
int idx;

if (unlikely(in_interrupt()))
@@ -1899,7 +1899,7 @@ void __init init_idle(task_t *idle, int
*/

typedef struct {
- list_t list;
+ struct list_head list;
task_t *task;
struct completion done;
} migration_req_t;
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/mm/memory.c .22733-linux-2.5.33.updated/mm/memory.c
--- .22733-linux-2.5.33/mm/memory.c 2002-08-28 09:29:54.000000000 +1000
+++ .22733-linux-2.5.33.updated/mm/memory.c 2002-09-02 15:15:09.000000000 +1000
@@ -1033,11 +1033,11 @@ no_mem:
return VM_FAULT_OOM;
}

-static void vmtruncate_list(list_t *head, unsigned long pgoff)
+static void vmtruncate_list(struct list_head *head, unsigned long pgoff)
{
unsigned long start, end, len, diff;
struct vm_area_struct *vma;
- list_t *curr;
+ struct list_head *curr;

list_for_each(curr, head) {
vma = list_entry(curr, struct vm_area_struct, shared);
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/mm/page_alloc.c .22733-linux-2.5.33.updated/mm/page_alloc.c
--- .22733-linux-2.5.33/mm/page_alloc.c 2002-09-01 12:23:08.000000000 +1000
+++ .22733-linux-2.5.33.updated/mm/page_alloc.c 2002-09-02 15:15:21.000000000 +1000
@@ -237,7 +237,7 @@ int is_head_of_free_region(struct page *
struct zone *zone = page_zone(page);
unsigned long flags;
int order;
- list_t *curr;
+ struct list_head *curr;

/*
* Should not matter as we need quiescent system for
@@ -652,7 +652,7 @@ void show_free_areas(void)

for (pgdat = pgdat_list; pgdat; pgdat = pgdat->pgdat_next)
for (type = 0; type < MAX_NR_ZONES; type++) {
- list_t *elem;
+ struct list_head *elem;
struct zone *zone = &pgdat->node_zones[type];
unsigned long nr, flags, order, total = 0;

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/net/sctp/associola.c .22733-linux-2.5.33.updated/net/sctp/associola.c
--- .22733-linux-2.5.33/net/sctp/associola.c 2002-09-01 12:23:08.000000000 +1000
+++ .22733-linux-2.5.33.updated/net/sctp/associola.c 2002-09-02 15:18:21.000000000 +1000
@@ -296,7 +296,7 @@ void sctp_association_free(sctp_associat
{
sctp_transport_t *transport;
sctp_endpoint_t *ep;
- list_t *pos, *temp;
+ struct list_head *pos, *temp;
int i;

ep = asoc->ep;
@@ -482,7 +482,7 @@ sctp_transport_t *sctp_assoc_lookup_padd
const sockaddr_storage_t *address)
{
sctp_transport_t *t;
- list_t *pos;
+ struct list_head *pos;

/* Cycle through all transports searching for a peer address. */

@@ -508,7 +508,7 @@ void sctp_assoc_control_transport(sctp_a
sctp_transport_t *first;
sctp_transport_t *second;
sctp_ulpevent_t *event;
- list_t *pos;
+ struct list_head *pos;
int spc_state = 0;

/* Record the transition on the transport. */
@@ -780,7 +780,7 @@ sctp_transport_t *sctp_assoc_lookup_tsn(
{
sctp_transport_t *active;
sctp_transport_t *match;
- list_t *entry, *pos;
+ struct list_head *entry, *pos;
sctp_transport_t *transport;
sctp_chunk_t *chunk;
__u32 key = htonl(tsn);
@@ -983,8 +983,8 @@ void sctp_assoc_update(sctp_association_
sctp_transport_t *sctp_assoc_choose_shutdown_transport(sctp_association_t *asoc)
{
sctp_transport_t *t, *next;
- list_t *head = &asoc->peer.transport_addr_list;
- list_t *pos;
+ struct list_head *head = &asoc->peer.transport_addr_list;
+ struct list_head *pos;

/* If this is the first time SHUTDOWN is sent, use the active
* path.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/net/sctp/bind_addr.c .22733-linux-2.5.33.updated/net/sctp/bind_addr.c
--- .22733-linux-2.5.33/net/sctp/bind_addr.c 2002-09-01 12:23:08.000000000 +1000
+++ .22733-linux-2.5.33.updated/net/sctp/bind_addr.c 2002-09-02 15:18:29.000000000 +1000
@@ -65,7 +65,7 @@ int sctp_bind_addr_copy(sctp_bind_addr_t
sctp_scope_t scope, int priority, int flags)
{
struct sockaddr_storage_list *addr;
- list_t *pos;
+ struct list_head *pos;
int error = 0;

/* All addresses share the same port. */
@@ -119,7 +119,7 @@ void sctp_bind_addr_init(sctp_bind_addr_
static void sctp_bind_addr_clean(sctp_bind_addr_t *bp)
{
struct sockaddr_storage_list *addr;
- list_t *pos, *temp;
+ struct list_head *pos, *temp;

/* Empty the bind address list. */
list_for_each_safe(pos, temp, &bp->address_list) {
@@ -173,7 +173,7 @@ int sctp_add_bind_addr(sctp_bind_addr_t
*/
int sctp_del_bind_addr(sctp_bind_addr_t *bp, sockaddr_storage_t *del_addr)
{
- list_t *pos, *temp;
+ struct list_head *pos, *temp;
struct sockaddr_storage_list *addr;

list_for_each_safe(pos, temp, &bp->address_list) {
@@ -206,7 +206,7 @@ sctpParam_t sctp_bind_addrs_to_raw(const
sctpIpAddress_t rawaddr_space;
int len;
struct sockaddr_storage_list *addr;
- list_t *pos;
+ struct list_head *pos;

retval.v = NULL;
addrparms_len = 0;
@@ -284,7 +284,7 @@ int sctp_raw_to_bind_addrs(sctp_bind_add
int sctp_bind_addr_has_addr(sctp_bind_addr_t *bp, const sockaddr_storage_t *addr)
{
struct sockaddr_storage_list *laddr;
- list_t *pos;
+ struct list_head *pos;

list_for_each(pos, &bp->address_list) {
laddr = list_entry(pos, struct sockaddr_storage_list, list);
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/net/sctp/endpointola.c .22733-linux-2.5.33.updated/net/sctp/endpointola.c
--- .22733-linux-2.5.33/net/sctp/endpointola.c 2002-09-01 12:23:08.000000000 +1000
+++ .22733-linux-2.5.33.updated/net/sctp/endpointola.c 2002-09-02 15:18:39.000000000 +1000
@@ -257,7 +257,7 @@ sctp_association_t *__sctp_endpoint_look
{
int rport;
sctp_association_t *asoc;
- list_t *pos;
+ struct list_head *pos;

rport = paddr->v4.sin_port;

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/net/sctp/outqueue.c .22733-linux-2.5.33.updated/net/sctp/outqueue.c
--- .22733-linux-2.5.33/net/sctp/outqueue.c 2002-09-01 12:23:09.000000000 +1000
+++ .22733-linux-2.5.33.updated/net/sctp/outqueue.c 2002-09-02 15:18:44.000000000 +1000
@@ -104,7 +104,7 @@ void sctp_outqueue_init(sctp_association
void sctp_outqueue_teardown(sctp_outqueue_t *q)
{
sctp_transport_t *transport;
- list_t *lchunk, *pos;
+ struct list_head *lchunk, *pos;
sctp_chunk_t *chunk;

/* Throw away unacknowledged chunks. */
@@ -948,7 +948,7 @@ static void sctp_sack_update_unack_data(
int sctp_sack_outqueue(sctp_outqueue_t *q, sctp_sackhdr_t *sack)
{
sctp_chunk_t *tchunk;
- list_t *lchunk, *transport_list, *pos;
+ struct list_head *lchunk, *transport_list, *pos;
__u32 tsn;
__u32 sack_ctsn;
__u32 ctsn;
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/net/sctp/protocol.c .22733-linux-2.5.33.updated/net/sctp/protocol.c
--- .22733-linux-2.5.33/net/sctp/protocol.c 2002-09-01 12:23:09.000000000 +1000
+++ .22733-linux-2.5.33.updated/net/sctp/protocol.c 2002-09-02 15:18:54.000000000 +1000
@@ -198,7 +198,7 @@ static void sctp_get_local_addr_list(sct
static void __sctp_free_local_addr_list(sctp_protocol_t *proto)
{
struct sockaddr_storage_list *addr;
- list_t *pos, *temp;
+ struct list_head *pos, *temp;

list_for_each_safe(pos, temp, &proto->local_addr_list) {
addr = list_entry(pos, struct sockaddr_storage_list, list);
@@ -223,7 +223,7 @@ int sctp_copy_local_addr_list(sctp_proto
{
struct sockaddr_storage_list *addr;
int error = 0;
- list_t *pos;
+ struct list_head *pos;
long flags __attribute__ ((unused));

sctp_spin_lock_irqsave(&proto->local_addr_lock, flags);
@@ -327,7 +327,7 @@ int sctp_ctl_sock_init(void)
*/
sctp_func_t *sctp_get_af_specific(const sockaddr_storage_t *address)
{
- list_t *pos;
+ struct list_head *pos;
sctp_protocol_t *proto = sctp_get_protocol();
sctp_func_t *retval, *af;

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/net/sctp/sm_make_chunk.c .22733-linux-2.5.33.updated/net/sctp/sm_make_chunk.c
--- .22733-linux-2.5.33/net/sctp/sm_make_chunk.c 2002-09-01 12:23:09.000000000 +1000
+++ .22733-linux-2.5.33.updated/net/sctp/sm_make_chunk.c 2002-09-02 15:18:59.000000000 +1000
@@ -1417,7 +1417,7 @@ void sctp_process_init(sctp_association_
sctpParam_t param;
__u8 *end;
sctp_transport_t *transport;
- list_t *pos, *temp;
+ struct list_head *pos, *temp;

/* We must include the address that the INIT packet came from.
* This is the only address that matters for an INIT packet.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/net/sctp/sm_sideeffect.c .22733-linux-2.5.33.updated/net/sctp/sm_sideeffect.c
--- .22733-linux-2.5.33/net/sctp/sm_sideeffect.c 2002-09-01 12:23:09.000000000 +1000
+++ .22733-linux-2.5.33.updated/net/sctp/sm_sideeffect.c 2002-09-02 15:19:03.000000000 +1000
@@ -1053,7 +1053,7 @@ static void sctp_cmd_hb_timers_start(sct
sctp_association_t *asoc)
{
sctp_transport_t *t;
- list_t *pos;
+ struct list_head *pos;

/* Start a heartbeat timer for each transport on the association.
* hold a reference on the transport to make sure none of
@@ -1072,7 +1072,7 @@ static void sctp_cmd_hb_timers_start(sct
void sctp_cmd_set_bind_addrs(sctp_cmd_seq_t *cmds, sctp_association_t *asoc,
sctp_bind_addr_t *bp)
{
- list_t *pos, *temp;
+ struct list_head *pos, *temp;

list_for_each_safe(pos, temp, &bp->address_list) {
list_del_init(pos);
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/net/sctp/sm_statefuns.c .22733-linux-2.5.33.updated/net/sctp/sm_statefuns.c
--- .22733-linux-2.5.33/net/sctp/sm_statefuns.c 2002-09-01 12:23:09.000000000 +1000
+++ .22733-linux-2.5.33.updated/net/sctp/sm_statefuns.c 2002-09-02 15:19:11.000000000 +1000
@@ -1056,7 +1056,7 @@ static sctp_disposition_t sctp_sf_do_dup
sctp_ulpevent_t *ev;
sctp_chunk_t *repl;
sctp_transport_t *new_addr, *addr;
- list_t *pos, *pos2, *temp;
+ struct list_head *pos, *pos2, *temp;
int found, error;

/* new_asoc is a brand-new association, so these are not yet
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22733-linux-2.5.33/net/sctp/socket.c .22733-linux-2.5.33.updated/net/sctp/socket.c
--- .22733-linux-2.5.33/net/sctp/socket.c 2002-09-01 12:23:09.000000000 +1000
+++ .22733-linux-2.5.33.updated/net/sctp/socket.c 2002-09-02 15:19:18.000000000 +1000
@@ -439,7 +439,7 @@ err_bindx_add:
#if CONFIG_IP_SCTP_ADDIP
/* Add these addresses to all associations on this endpoint. */
if (retval >= 0) {
- list_t *pos;
+ struct list_head *pos;
sctp_endpoint_t *ep;
sctp_association_t *asoc;
ep = sctp_sk(sk)->ep;
@@ -560,7 +560,7 @@ err_bindx_rem:
#if CONFIG_IP_SCTP_ADDIP
/* Remove these addresses from all associations on this endpoint. */
if (retval >= 0) {
- list_t *pos;
+ struct list_head *pos;
sctp_endpoint_t *ep;
sctp_association_t *asoc;

@@ -666,7 +666,7 @@ static void sctp_close(struct sock *sk,
{
sctp_endpoint_t *ep;
sctp_association_t *asoc;
- list_t *pos, *temp;
+ struct list_head *pos, *temp;

SCTP_DEBUG_PRINTK("sctp_close(sk: 0x%p...)\n", sk);

@@ -1238,7 +1238,7 @@ static int sctp_setsockopt(struct sock *
int retval = 0;
char * tmp;
sctp_protocol_t *proto = sctp_get_protocol();
- list_t *pos;
+ struct list_head *pos;
sctp_func_t *af;

SCTP_DEBUG_PRINTK("sctp_setsockopt(sk: %p... optname: %d)\n",
@@ -1661,7 +1661,7 @@ static int sctp_getsockopt(struct sock *
int retval = 0;
sctp_protocol_t *proto = sctp_get_protocol();
sctp_func_t *af;
- list_t *pos;
+ struct list_head *pos;
int len;

SCTP_DEBUG_PRINTK("sctp_getsockopt(sk: %p, ...)\n", sk);
@@ -2649,7 +2649,7 @@ static void __sctp_write_space(sctp_asso
void sctp_write_space(struct sock *sk)
{
sctp_association_t *asoc;
- list_t *pos;
+ struct list_head *pos;

/* Wake up the tasks in each wait queue. */
list_for_each(pos, &((sctp_sk(sk))->ep->asocs)) {

2002-09-04 01:45:22

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Wednesday 04 September 2002 02:41, Rusty Russell wrote:
> In message <[email protected]> you
> write:
> >
> > On Tue, 3 Sep 2002, Jamie Lokier wrote:
> > >
> > > 1. struct list
> > > 2. struct list_node
> > >
> > > With these two types, `list_add' et al. can actually _check_ that you
> > > got the arguments the right way around.
> >
> > Well, the thing is, one of the _advantages_ of "struct list_head" is
> > exactly the fact that the implementation is 100% agnostic about whether a
> > list entry is the head, or just part of the list.
>
> Excellent. Well I'm glad that's sorted.
>
> Now please apply my patch (which got sidelined by nomenclature fetishers),

Yep, half a frog in the blender is better than no frog.

--
Daniel

2002-09-04 02:13:21

by Linus Torvalds

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Wed, 4 Sep 2002, Daniel Phillips wrote:
>
> Yep, half a frog in the blender is better than no frog.

Quite frankly, I'd rather have no frogs at all in my blenders, thank you
very much.

I'll take my blenders with ice, tequila, triple sec and some lemon juice,
thank you very much.

Frogs indeed! Spare me.

Linus

2002-09-04 02:39:55

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

In message <[email protected]> you wri
te:
>
> On Wed, 4 Sep 2002, Daniel Phillips wrote:
> >
> > Yep, half a frog in the blender is better than no frog.
>
> Quite frankly, I'd rather have no frogs at all in my blenders, thank you
> very much.
>
> I'll take my blenders with ice, tequila, triple sec and some lemon juice,
> thank you very much.
>
> Frogs indeed! Spare me.

I'm confused, but I do know three things:

1) list_t *bad*,

2) Grand renaming of "struct list_head" *bad*, and

3) There's a punchline about frogs, blenders and mixed metaphores
coming soon.

Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

2002-09-04 06:07:02

by Thunder from the hill

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

Hi,

On Wed, 4 Sep 2002, Daniel Phillips wrote:
> Yep, half a frog in the blender is better than no frog.

No, it's a complete frog. The thing you're talking about is another. And
since the second frog can wait...

Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-

2002-09-04 14:32:00

by J.A. Magallon

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On 2002.09.04 Rusty Russell wrote:
>In message <[email protected]> you wri
>te:
...
>
>I'm confused, but I do know three things:
>
>1) list_t *bad*,
>
>2) Grand renaming of "struct list_head" *bad*, and
>

Why not something like:

struct list_node {
struct list_node *prev;
struct list_node *next;
}

struct list {
struct list_node *prev;
struct list_node *next;
}

list_length(struct list *l)
list_add(struct list_node *new, struct list *head)
list_splice(struct list *list, struct list *head)

New:

#define list_sublist_from(node) ((struct list *)node)

So people would be forced to think if he is using a 'list_head'
as a node or as a sublist, and do the right casts to shut up the
compiler (that's why you can't do a typedef list_node list..., for
the compiler to scream...)

--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.0 (Cooker) for i586
Linux 2.4.20-pre5-j0 (gcc 3.2 (Mandrake Linux 9.0 3.2-1mdk))

2002-09-06 09:26:55

by Dan Aloni

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Mon, Sep 02, 2002 at 03:23:02PM +1000, Rusty Russell wrote:
> This week, it spread to SCTP.
>
> "struct list_head" isn't a great name, but having two names for
> everything is yet another bar to reading kernel source.
>
[...]
>
> D: This removes list_t, which is a gratuitous typedef for a "struct
> D: list_head". Unless there is good reason, the kernel doesn't usually
> D: typedef, as typedefs cannot be predeclared unlike structs.
>

Good, I see it was actually a *good* thing that I've done a
's/struct list_head/list_t' in list.h, back when I was adding list_move_*().

Otherwise, we wouldn't have noticed much the appearance of list_t, and it
might have spread throughout the kernel by the time we reach 2.6.0.

task_t, anyone?

--
Dan Aloni
[email protected]

2002-09-06 14:30:56

by Robert Love

[permalink] [raw]

Subject: Re: [TRIVIAL PATCH] Remove list_t infection.

On Fri, 2002-09-06 at 05:28, Dan Aloni wrote:

> task_t, anyone?

I actually like task_t, and it is my lone typedef exception, but maybe I
am the exception...

My real complaint against typedefs (and list_t in particular) is their
inconsistent use. I think we have done a good job universally using
task_t vs struct task_struct, and thus its not an issue to keep it...
On the other hand, I would not scream too loudly over its removal.

Anyhow, I think any change should be ack'ed by Ingo because its his code
and he deals with it a disappropriately large amount of the time.

Robert Love

2002-09-09 05:54:33