netdev - Re: [2.6 patch] drivers/net/loopback.c: convert to module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20061212.171756.85408589.davem@davemloft.net>
Date:	Tue, 12 Dec 2006 17:17:56 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	bunk@...sta.de
Cc:	jgarzik@...ox.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [2.6 patch] drivers/net/loopback.c: convert to module_init()

From: Adrian Bunk <bunk@...sta.de>
Date: Tue, 12 Dec 2006 17:24:35 +0100

> This patch converts drivers/net/loopback.c to using module_init().
> 
> Signed-off-by: Adrian Bunk <bunk@...sta.de>

I'm not %100 sure of this one, let's look at the comment you
are deleting:

> -/*
> - *	The loopback device is global so it can be directly referenced
> - *	by the network code. Also, it must be first on device list.
> - */
> -extern int loopback_init(void);
> -

in particular notice the part that says "it must be first on the
device list".

I'm not sure whether that is important any longer.  It probably isn't,
but we should verify it before applying such a patch.

Since module_init() effectively == device_initcall() for statically
built objects, which loopback always is, the Makefile ordering does
not seem to indicate to me that there is anything guarenteeing
this "first on the list" invariant.  At least not via object
file ordering.

So this gives some support to the idea that loopback_dev's position
on the device list no longer matters.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html