Re: kernel headers ethtool.h and mii.h

2006-01-05 Thread Robert Love
On Thu, 2006-01-05 at 10:19 -0800, Stephen Hemminger wrote:

> Is there something that needs to be exported in net/if.h or is it just
> application stupidity?

Nah, I think they both export the right stuff.

But I would not say the problem is "application stupidity" -- we have
two official headers that both define the same stuff.  While we may
expect an individual application to be smart enough to not include both,
what do we expect if an application uses various other libraries and
headers, that include the two files, plus does networking of its own?

This is what we see in NM: NM wants to get at this data, but so does
iwlib and mii.  We can have NM use whatever header we want, but iwlib
uses  and mii uses .

For SUSE, at least, I patched wireless-tools to use .  It
does not fix the underlying problem, but at least we can build.

Robert Love


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: kernel headers ethtool.h and mii.h

2006-01-05 Thread Stephen Hemminger
On Wed, 04 Jan 2006 11:12:16 -0500
Robert Love <[EMAIL PROTECTED]> wrote:

> On Wed, 2006-01-04 at 10:57 -0500, Dan Williams wrote:
> 
> > Yes, it appears that we do.
> 
> Alright.  I'll look into patching our glibc, too.  In the meantime, the
> previous patch works.
> 
> > We have to do this for wpa.c too since somebody decided it was cool to
> > use kernel types in wpa_supplicant.  Whatever.
> 
> Ugh.
> 
> On a similar vein -- I am seeing a problem (reported weeks ago by
> someone else) with more recent wireless-tools.  It seems some things use
>  and others .  Unfortunately, they define much the
> same stuff (ifmap, ifreq, and ifconf structures being the troublemakers)
> and thus break compilation.
> 
> Not sure an easy solution for that, although a quick-hack would be to
> patch iwlib.h to always use  instead of .  [ The
> problem in NM's case is that we include iwlib.h and kernel headers, such
> as mii.h that use , in the same file. ]
> 
>   Robert Love

Is there something that needs to be exported in net/if.h or is it just
application stupidity?

-- 
Stephen Hemminger <[EMAIL PROTECTED]>
OSDL http://developer.osdl.org/~shemminger
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: kernel headers ethtool.h and mii.h

2006-01-04 Thread Robert Love
On Wed, 2006-01-04 at 10:57 -0500, Dan Williams wrote:

> Yes, it appears that we do.

Alright.  I'll look into patching our glibc, too.  In the meantime, the
previous patch works.

> We have to do this for wpa.c too since somebody decided it was cool to
> use kernel types in wpa_supplicant.  Whatever.

Ugh.

On a similar vein -- I am seeing a problem (reported weeks ago by
someone else) with more recent wireless-tools.  It seems some things use
 and others .  Unfortunately, they define much the
same stuff (ifmap, ifreq, and ifconf structures being the troublemakers)
and thus break compilation.

Not sure an easy solution for that, although a quick-hack would be to
patch iwlib.h to always use  instead of .  [ The
problem in NM's case is that we include iwlib.h and kernel headers, such
as mii.h that use , in the same file. ]

Robert Love


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: kernel headers ethtool.h and mii.h

2006-01-04 Thread Dan Williams
On Wed, 2006-01-04 at 10:28 -0500, Robert Love wrote:
> ethtool.h and mii.h (included in the new nm-device-802-3-ethernet.c)
> define a bunch of structures with the kernel-internal u16, u32, etc.
> types.
> 
> This basically means they don't work without defining these types.
> 
> Kernel headers are not supposed to leak these types to user-space,
> polluting the name space, but instead use __u16, __u32, etc.
> 
> Dan, does Red Hat patch these files?  If  has __u32
> instead of u32, then you do.

Yes, it appears that we do.

> Patching these files is the right solution.  I sent the attached two
> patches upstream and they should go in the next kernel release.  Then,
> once glibc repopulates its headers from the kernel, everyone will be all
> right.  In the interim, distros can add these patches to their glibc
> packages, if they are not doing so already.

Yeah, saw those already on lkml.  Sounds good.

> As a temp hack, the attached patch against NM makes everything work by
> defining the new types.  Hacky, but it builds.

We have to do this for wpa.c too since somebody decided it was cool to
use kernel types in wpa_supplicant.  Whatever.

Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


kernel headers ethtool.h and mii.h

2006-01-04 Thread Robert Love

ethtool.h and mii.h (included in the new nm-device-802-3-ethernet.c)
define a bunch of structures with the kernel-internal u16, u32, etc.
types.

This basically means they don't work without defining these types.

Kernel headers are not supposed to leak these types to user-space,
polluting the name space, but instead use __u16, __u32, etc.

Dan, does Red Hat patch these files?  If  has __u32
instead of u32, then you do.

Patching these files is the right solution.  I sent the attached two
patches upstream and they should go in the next kernel release.  Then,
once glibc repopulates its headers from the kernel, everyone will be all
right.  In the interim, distros can add these patches to their glibc
packages, if they are not doing so already.

As a temp hack, the attached patch against NM makes everything work by
defining the new types.  Hacky, but it builds.

Just an FYI.

Robert Love

Index: src/nm-device-802-3-ethernet.h
===
RCS file: /cvs/gnome/NetworkManager/src/nm-device-802-3-ethernet.h,v
retrieving revision 1.1
diff -u -r1.1 nm-device-802-3-ethernet.h
--- src/nm-device-802-3-ethernet.h	31 Dec 2005 08:21:23 -	1.1
+++ src/nm-device-802-3-ethernet.h	4 Jan 2006 15:24:59 -
@@ -29,6 +29,12 @@
 
 #include "nm-device.h"
 
+/* define the kernel types until mii.h and ethtool.h are fixed */
+#define u64	__u64
+#define u32	__u32
+#define u16	__u16
+#define u8	__u8
+
 G_BEGIN_DECLS
 
 #define NM_TYPE_DEVICE_802_3_ETHERNET			(nm_device_802_3_ethernet_get_type ())
don't leak the kernel uX types to user-space, use __uX in lieu

 include/linux/ethtool.h |  228 
 1 files changed, 114 insertions(+), 114 deletions(-)

diff -urN linux-2.6.15/include/linux/ethtool.h linux/include/linux/ethtool.h
--- linux-2.6.15/include/linux/ethtool.h	2006-01-02 22:21:10.0 -0500
+++ linux/include/linux/ethtool.h	2006-01-03 15:46:38.0 -0500
@@ -15,24 +15,24 @@
 
 /* This should work for both 32 and 64 bit userland. */
 struct ethtool_cmd {
-	u32	cmd;
-	u32	supported;	/* Features this interface supports */
-	u32	advertising;	/* Features this interface advertises */
-	u16	speed;		/* The forced speed, 10Mb, 100Mb, gigabit */
-	u8	duplex;		/* Duplex, half or full */
-	u8	port;		/* Which connector port */
-	u8	phy_address;
-	u8	transceiver;	/* Which transceiver to use */
-	u8	autoneg;	/* Enable or disable autonegotiation */
-	u32	maxtxpkt;	/* Tx pkts before generating tx int */
-	u32	maxrxpkt;	/* Rx pkts before generating rx int */
-	u32	reserved[4];
+	__u32	cmd;
+	__u32	supported;	/* Features this interface supports */
+	__u32	advertising;	/* Features this interface advertises */
+	__u16	speed;		/* The forced speed, 10Mb, 100Mb, gigabit */
+	__u8	duplex;		/* Duplex, half or full */
+	__u8	port;		/* Which connector port */
+	__u8	phy_address;
+	__u8	transceiver;	/* Which transceiver to use */
+	__u8	autoneg;	/* Enable or disable autonegotiation */
+	__u32	maxtxpkt;	/* Tx pkts before generating tx int */
+	__u32	maxrxpkt;	/* Rx pkts before generating rx int */
+	__u32	reserved[4];
 };
 
 #define ETHTOOL_BUSINFO_LEN	32
 /* these strings are set to whatever the driver author decides... */
 struct ethtool_drvinfo {
-	u32	cmd;
+	__u32	cmd;
 	char	driver[32];	/* driver short name, "tulip", "eepro100" */
 	char	version[32];	/* driver version string */
 	char	fw_version[32];	/* firmware version string, if applicable */
@@ -40,53 +40,53 @@
 /* For PCI devices, use pci_name(pci_dev). */
 	char	reserved1[32];
 	char	reserved2[16];
-	u32	n_stats;	/* number of u64's from ETHTOOL_GSTATS */
-	u32	testinfo_len;
-	u32	eedump_len;	/* Size of data from ETHTOOL_GEEPROM (bytes) */
-	u32	regdump_len;	/* Size of data from ETHTOOL_GREGS (bytes) */
+	__u32	n_stats;	/* number of __u64's from ETHTOOL_GSTATS */
+	__u32	testinfo_len;
+	__u32	eedump_len;	/* Size of data from ETHTOOL_GEEPROM (bytes) */
+	__u32	regdump_len;	/* Size of data from ETHTOOL_GREGS (bytes) */
 };
 
 #define SOPASS_MAX	6
 /* wake-on-lan settings */
 struct ethtool_wolinfo {
-	u32	cmd;
-	u32	supported;
-	u32	wolopts;
-	u8	sopass[SOPASS_MAX]; /* SecureOn(tm) password */
+	__u32	cmd;
+	__u32	supported;
+	__u32	wolopts;
+	__u8	sopass[SOPASS_MAX]; /* SecureOn(tm) password */
 };
 
 /* for passing single values */
 struct ethtool_value {
-	u32	cmd;
-	u32	data;
+	__u32	cmd;
+	__u32	data;
 };
 
 /* for passing big chunks of data */
 struct ethtool_regs {
-	u32	cmd;
-	u32	version; /* driver-specific, indicates different chips/revs */
-	u32	len; /* bytes */
-	u8	data[0];
+	__u32	cmd;
+	__u32	version; /* driver-specific, indicates different chips/revs */
+	__u32	len; /* bytes */
+	__u8	data[0];
 };
 
 /* for passing EEPROM chunks */
 struct ethtool_eeprom {
-	u32	cmd;
-	u32	magic;
-	u32	offset; /* in bytes */
-	u32	len; /* in bytes */
-	u8	data[0];
+	__u32	cmd;
+	__u32	magic;
+	__u32	offset; /* in bytes */
+	__u32	len; /* in bytes */
+	__u8	data[0];
 };
 
 /* for