Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-06 Thread Johannes Berg
On Mon, 2007-03-05 at 17:56 -0800, Greg KH wrote:

 Theory F:  It broke because you are using NetworkManager for your
 network devices and the patches that fix this have not made it into a
 real release?
 
 I'm just guessing, but does anyone who is having this problem, NOT using
 NetworkManager?
 
 I'm running an old version of HAL just fine, but I'm not using
 NetworkManager here.

Greg, HAL itself isn't the problem. The problem is that older versions
of HAL ignore all network devices when this option is not set and thus
network manager can't pick them up.

johannes


signature.asc
Description: This is a digitally signed message part


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-06 Thread Dan Williams
On Mon, 2007-03-05 at 17:56 -0800, Greg KH wrote:
 On Mon, Mar 05, 2007 at 07:30:21PM -0600, Matt Mackall wrote:
  On Mon, Mar 05, 2007 at 04:07:22PM -0800, Greg KH wrote:
   On Tue, Mar 06, 2007 at 12:40:52AM +0100, Adrian Bunk wrote:
On Mon, Mar 05, 2007 at 10:58:13AM -0800, Greg KH wrote:
 
 Ok, how about the following patch.  Is it acceptable to everyone?
 
 thanks,
 
 greg k-h
 
 ---
  init/Kconfig |   13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)
 
 --- gregkh-2.6.orig/init/Kconfig
 +++ gregkh-2.6/init/Kconfig
 @@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
 that belong to a class, back into the /sys/class heirachy, in
 order to support older versions of udev.
  
 -   If you are using a distro that was released in 2006 or later,
 -   it should be safe to say N here.
 +   If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
 +   release from 2007 or later, it should be safe to say N here.
 +
 +   If you are using Debian or other distros that are slow to
 +   update HAL, please say Y here.
...

The sane solution seems to be to enable SYSFS_DEPRECATED 
unconditionally 
for all users, and schedule it's removal for mid-2008 (or later).

12 months after the first _release_ of a HAL that can live without 
seems 
to be the first time when we can consider getting rid of it, since all 
distributions with at least one release a year should ship it by then.

Currently, SYSFS_DEPRECATED is only a trap for users.
   
   Huh?
   
   No, again, I've been using this just fine for about 6 months now.
   
   And what about all of the servers not using HAL/NetworkManager?
   And what about all of the embedded systems not using either?
   
   So to not allow this to be turned off by people who might want to (we
   want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will
   other distros released this year), is pretty heavy-handed.
   
   It also will work in OpenSuSE 10.2 which is already released, and I
   think Fedora 6, but I've only limited experience with these.
   
   Oh, and Gentoo works just fine, and has been for the past 6 months.
  
   I would just prefer to come up with an acceptable set of wording that
   will work to properly warn people.
   
   I proposed one such wording which some people took as a slam against
   Debian, which it really was not at all.
   
   Does someone else want to propose some other wording instead?
  
  Back up a bit. Let's review:
  
  Problem: NetworkManager stopped working with my ipw2200 on Debian/unstable
  
  Theory A: It broke because I'm not running an as-yet-unreleased HAL.
  
   Then we should revert the patch pronto because it's an unqualified
   regression.
  
  Theory B: It broke because I'm not running relatively recent HAL.
  
   By all accounts I'm running the latest and greatest HAL and Network
   Manager, more than recent enough to work.
  
  Theory C: It broke because I've got some goofy config.
  
   My setup passes no arguments to either. The HAL config file is
   completely bare-bones and there's no sign of any configuration files
   for Network Manager.
  
  Theory D: It broke for some nebulous Debian-related reason.
  
   That's a bunch of unhelpful crap.
  
 
  Can we come up with an actual theory for what's wrong with my setup, please?
  Like, perhaps:
  
  Theory E: There's some undiagnosed new breakage that this introduces
  that no else hit until it went into mainline.
 
 Theory F:  It broke because you are using NetworkManager for your
 network devices and the patches that fix this have not made it into a
 real release?

The problem is _NOT_ NetworkManager.  NM just asks HAL for network
devices, NM does not muck with /sys at all.  If HAL can't see it,
NetworkManager can't see it, because NM uses HAL.

The problem is that sysfs is fundamentally a kernel API.  Whenever it
changes, HAL must change or HAL will break.  Same story with anything
that ever reads from sysfs.

Dan

 I'm just guessing, but does anyone who is having this problem, NOT using
 NetworkManager?
 
 I'm running an old version of HAL just fine, but I'm not using
 NetworkManager here.
 
 I am using NetworkManager on a OpenSuSE 10.3 release, but suse's version
 of NetworkManager is well known to not be anywhere near what is released
 as a tarball :(
 
 thanks,
 
 greg k-h
 -
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-06 Thread Greg KH
On Tue, Mar 06, 2007 at 12:10:09AM -0600, Matt Mackall wrote:
 On Mon, Mar 05, 2007 at 08:03:50PM -0800, Greg KH wrote:
  On Mon, Mar 05, 2007 at 09:39:47PM -0600, Matt Mackall wrote:
   On Mon, Mar 05, 2007 at 06:48:50PM -0800, Greg KH wrote:
If so, can you disable the option and strace it to see what program is
trying to access what?  That will put the
HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty
quickly :)
   
   Ok, I've got straces of both good and bad (5M each). Filtered out
   random pointer values and the like, diffed, and filtered for /sys/,
   and the result's still 1.5M. What should I be looking for?
  
  Failures when trying to read from /sys/class/net/
  
  Or opening the directory and iterating over the subdirs in there.  Or
  something like that.
  
  But the /sys/class/net/ stuff should hopefully help narrow it down.
 
 Works:
 
 6857  open(/sys/class/net,
 O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13
 6857  fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
 6857  fcntl64(13, F_SETFD, FD_CLOEXEC)  = 0
 6857  getdents64(13, /* 5 entries */, 4096) = 120
 6857  readlink(/sys/class/net/eth1, 0x80a2450, 256) = -1 EINVAL
 (Invalid argument)
 6857  readlink(/sys/class/net/eth1/device,
 ../../../devices/pci:00/:00:1e.0/:02:02.0, 256) = 53
 6857  readlink(/sys/class/net/lo, 0x80a2450, 256) = -1 EINVAL
 (Invalid argument)
 6857  readlink(/sys/class/net/lo/device, 0x80a2450, 256) = -1 ENOENT
 (No such
 file or directory)
 6857  readlink(/sys/class/net/eth0, 0x80a2450, 256) = -1 EINVAL
 (Invalid argument)
 6857  readlink(/sys/class/net/eth0/device,
 ../../../devices/pci:00/:00:1e.0/:02:01.0, 256) = 53
 6857  getdents64(13, /* 0 entries */, 4096) = 0
 6857  close(13) = 0
 
 Breaks:
 
 3620  open(/sys/class/net,
 O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13
 3620  fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
 3620  fcntl64(13, F_SETFD, FD_CLOEXEC)  = 0
 3620  getdents64(13, /* 5 entries */, 4096) = 120
 3620  readlink(/sys/class/net/eth1,
 ../../devices/pci:00/:00:1e.0/00\00:02:02.0/eth1, 256) = 55
 3620
 readlink(/sys/devices/pci:00/:00:1e.0/:02:02.0/eth1/device,
 0x809e910, 256) = -1 ENOENT (No such file or directory)
 3620  readlink(/sys/class/net/lo, ../../devices/virtual/net/lo,
 256) = 28
 3620  readlink(/sys/devices/virtual/net/lo/device, 0x809e960, 256) =
 -1 ENOEN\T (No such file or directory)
 3620  readlink(/sys/class/net/eth0,
 ../../devices/pci:00/:00:1e.0/00\00:02:01.0/eth0, 256) = 55
 3620
 readlink(/sys/devices/pci:00/:00:1e.0/:02:01.0/eth0/device,
 0x809e960, 256) = -1 ENOENT (No such file or directory)
 3620  getdents64(13, /* 0 entries */, 4096) = 0
 3620  close(13) = 0

Ah, that should be simple to fix in the kernel, give me an hour or so...

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-06 Thread Greg KH
On Tue, Mar 06, 2007 at 12:10:09AM -0600, Matt Mackall wrote:
 On Mon, Mar 05, 2007 at 08:03:50PM -0800, Greg KH wrote:
  On Mon, Mar 05, 2007 at 09:39:47PM -0600, Matt Mackall wrote:
   On Mon, Mar 05, 2007 at 06:48:50PM -0800, Greg KH wrote:
If so, can you disable the option and strace it to see what program is
trying to access what?  That will put the
HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty
quickly :)
   
   Ok, I've got straces of both good and bad (5M each). Filtered out
   random pointer values and the like, diffed, and filtered for /sys/,
   and the result's still 1.5M. What should I be looking for?
  
  Failures when trying to read from /sys/class/net/
  
  Or opening the directory and iterating over the subdirs in there.  Or
  something like that.
  
  But the /sys/class/net/ stuff should hopefully help narrow it down.
 
 Works:
 
 6857  open(/sys/class/net,
 O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13
 6857  fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
 6857  fcntl64(13, F_SETFD, FD_CLOEXEC)  = 0
 6857  getdents64(13, /* 5 entries */, 4096) = 120
 6857  readlink(/sys/class/net/eth1, 0x80a2450, 256) = -1 EINVAL
 (Invalid argument)
 6857  readlink(/sys/class/net/eth1/device,
 ../../../devices/pci:00/:00:1e.0/:02:02.0, 256) = 53
 6857  readlink(/sys/class/net/lo, 0x80a2450, 256) = -1 EINVAL
 (Invalid argument)
 6857  readlink(/sys/class/net/lo/device, 0x80a2450, 256) = -1 ENOENT
 (No such
 file or directory)
 6857  readlink(/sys/class/net/eth0, 0x80a2450, 256) = -1 EINVAL
 (Invalid argument)
 6857  readlink(/sys/class/net/eth0/device,
 ../../../devices/pci:00/:00:1e.0/:02:01.0, 256) = 53
 6857  getdents64(13, /* 0 entries */, 4096) = 0
 6857  close(13) = 0
 
 Breaks:
 
 3620  open(/sys/class/net,
 O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13
 3620  fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
 3620  fcntl64(13, F_SETFD, FD_CLOEXEC)  = 0
 3620  getdents64(13, /* 5 entries */, 4096) = 120
 3620  readlink(/sys/class/net/eth1,
 ../../devices/pci:00/:00:1e.0/00\00:02:02.0/eth1, 256) = 55
 3620
 readlink(/sys/devices/pci:00/:00:1e.0/:02:02.0/eth1/device,
 0x809e910, 256) = -1 ENOENT (No such file or directory)
 3620  readlink(/sys/class/net/lo, ../../devices/virtual/net/lo,
 256) = 28
 3620  readlink(/sys/devices/virtual/net/lo/device, 0x809e960, 256) =
 -1 ENOEN\T (No such file or directory)
 3620  readlink(/sys/class/net/eth0,
 ../../devices/pci:00/:00:1e.0/00\00:02:01.0/eth0, 256) = 55
 3620
 readlink(/sys/devices/pci:00/:00:1e.0/:02:01.0/eth0/device,
 0x809e960, 256) = -1 ENOENT (No such file or directory)
 3620  getdents64(13, /* 0 entries */, 4096) = 0
 3620  close(13) = 0

Can you try the patch below?  And enable CONFIG_SYSFS_DEPRECATED.  It
should cause HAL to see the network devices again, as the symlink is now
back (it shouldn't have gone away, that was my fault...)

I tried this with HAL 0.5.7, which is pretty old, and hal-device-manager
shows my network devices properly.

thanks for your patience,

greg k-h


---
 drivers/base/core.c |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

--- gregkh-2.6.orig/drivers/base/core.c
+++ gregkh-2.6/drivers/base/core.c
@@ -584,17 +584,17 @@ int device_add(struct device *dev)
if (dev-kobj.parent != dev-class-subsys.kset.kobj)
sysfs_create_link(dev-class-subsys.kset.kobj,
  dev-kobj, dev-bus_id);
-#ifdef CONFIG_SYSFS_DEPRECATED
if (parent) {
sysfs_create_link(dev-kobj, dev-parent-kobj,
device);
+#ifdef CONFIG_SYSFS_DEPRECATED
class_name = make_class_name(dev-class-name,
dev-kobj);
if (class_name)
sysfs_create_link(dev-parent-kobj,
  dev-kobj, class_name);
-   }
 #endif
+   }
}
 
if ((error = device_add_attrs(dev)))
@@ -651,17 +651,17 @@ int device_add(struct device *dev)
if (dev-kobj.parent != dev-class-subsys.kset.kobj)
sysfs_remove_link(dev-class-subsys.kset.kobj,
  dev-bus_id);
-#ifdef CONFIG_SYSFS_DEPRECATED
if (parent) {
+#ifdef CONFIG_SYSFS_DEPRECATED
char *class_name = make_class_name(dev-class-name,
   dev-kobj);
if (class_name)
sysfs_remove_link(dev-parent-kobj,
  class_name);
kfree(class_name);
+#endif

Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-05 Thread Greg KH
On Tue, Mar 06, 2007 at 12:40:52AM +0100, Adrian Bunk wrote:
 On Mon, Mar 05, 2007 at 10:58:13AM -0800, Greg KH wrote:
  
  Ok, how about the following patch.  Is it acceptable to everyone?
  
  thanks,
  
  greg k-h
  
  ---
   init/Kconfig |   13 +++--
   1 file changed, 11 insertions(+), 2 deletions(-)
  
  --- gregkh-2.6.orig/init/Kconfig
  +++ gregkh-2.6/init/Kconfig
  @@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
that belong to a class, back into the /sys/class heirachy, in
order to support older versions of udev.
   
  - If you are using a distro that was released in 2006 or later,
  - it should be safe to say N here.
  + If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
  + release from 2007 or later, it should be safe to say N here.
  +
  + If you are using Debian or other distros that are slow to
  + update HAL, please say Y here.
 ...
 
 The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally 
 for all users, and schedule it's removal for mid-2008 (or later).
 
 12 months after the first _release_ of a HAL that can live without seems 
 to be the first time when we can consider getting rid of it, since all 
 distributions with at least one release a year should ship it by then.
 
 Currently, SYSFS_DEPRECATED is only a trap for users.

Huh?

No, again, I've been using this just fine for about 6 months now.

And what about all of the servers not using HAL/NetworkManager?
And what about all of the embedded systems not using either?

So to not allow this to be turned off by people who might want to (we
want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will
other distros released this year), is pretty heavy-handed.

It also will work in OpenSuSE 10.2 which is already released, and I
think Fedora 6, but I've only limited experience with these.

Oh, and Gentoo works just fine, and has been for the past 6 months.

I would just prefer to come up with an acceptable set of wording that
will work to properly warn people.

I proposed one such wording which some people took as a slam against
Debian, which it really was not at all.

Does someone else want to propose some other wording instead?

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-05 Thread Adrian Bunk
On Mon, Mar 05, 2007 at 04:07:22PM -0800, Greg KH wrote:
 On Tue, Mar 06, 2007 at 12:40:52AM +0100, Adrian Bunk wrote:
  On Mon, Mar 05, 2007 at 10:58:13AM -0800, Greg KH wrote:
   
   Ok, how about the following patch.  Is it acceptable to everyone?
   
   thanks,
   
   greg k-h
   
   ---
init/Kconfig |   13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
   
   --- gregkh-2.6.orig/init/Kconfig
   +++ gregkh-2.6/init/Kconfig
   @@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
   that belong to a class, back into the /sys/class heirachy, in
   order to support older versions of udev.

   -   If you are using a distro that was released in 2006 or later,
   -   it should be safe to say N here.
   +   If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
   +   release from 2007 or later, it should be safe to say N here.
   +
   +   If you are using Debian or other distros that are slow to
   +   update HAL, please say Y here.
  ...
  
  The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally 
  for all users, and schedule it's removal for mid-2008 (or later).
  
  12 months after the first _release_ of a HAL that can live without seems 
  to be the first time when we can consider getting rid of it, since all 
  distributions with at least one release a year should ship it by then.
  
  Currently, SYSFS_DEPRECATED is only a trap for users.
 
 Huh?
 
 No, again, I've been using this just fine for about 6 months now.
 
 And what about all of the servers not using HAL/NetworkManager?

On a server, it shouldn't harm.

 And what about all of the embedded systems not using either?

If it was much code, I would have sent a patch that allowed disabling it 
if EMBEDDED=y.

 So to not allow this to be turned off by people who might want to (we
 want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will
 other distros released this year), is pretty heavy-handed.
 
 It also will work in OpenSuSE 10.2 which is already released, and I
 think Fedora 6, but I've only limited experience with these.
 
 Oh, and Gentoo works just fine, and has been for the past 6 months.

For most people, it simply doesn't matter whether SYSFS_DEPRECATED is 
on or off.

But accidentally disabling SYSFS_DEPRECATED has proven to be a trap 
people sometimes fall into - and tracking them down to 
SYSFS_DEPRECATED=n sometimes takes some time.

 I would just prefer to come up with an acceptable set of wording that
 will work to properly warn people.
 
 I proposed one such wording which some people took as a slam against
 Debian, which it really was not at all.
 
 Does someone else want to propose some other wording instead?
 
 thanks,
 
 greg k-h

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-05 Thread Greg KH
On Tue, Mar 06, 2007 at 01:35:41AM +0100, Adrian Bunk wrote:
 On Mon, Mar 05, 2007 at 04:07:22PM -0800, Greg KH wrote:
  On Tue, Mar 06, 2007 at 12:40:52AM +0100, Adrian Bunk wrote:
   On Mon, Mar 05, 2007 at 10:58:13AM -0800, Greg KH wrote:

Ok, how about the following patch.  Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

--- gregkh-2.6.orig/init/Kconfig
+++ gregkh-2.6/init/Kconfig
@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
  that belong to a class, back into the /sys/class heirachy, in
  order to support older versions of udev.
 
- If you are using a distro that was released in 2006 or later,
- it should be safe to say N here.
+ If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+ release from 2007 or later, it should be safe to say N here.
+
+ If you are using Debian or other distros that are slow to
+ update HAL, please say Y here.
   ...
   
   The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally 
   for all users, and schedule it's removal for mid-2008 (or later).
   
   12 months after the first _release_ of a HAL that can live without seems 
   to be the first time when we can consider getting rid of it, since all 
   distributions with at least one release a year should ship it by then.
   
   Currently, SYSFS_DEPRECATED is only a trap for users.
  
  Huh?
  
  No, again, I've been using this just fine for about 6 months now.
  
  And what about all of the servers not using HAL/NetworkManager?
 
 On a server, it shouldn't harm.

But if they wanted that option enabled?

  And what about all of the embedded systems not using either?
 
 If it was much code, I would have sent a patch that allowed disabling it 
 if EMBEDDED=y.

It's not a code size issue.  In fact, if the option is enabled, like you
have done, it builds more code into the kernel than before.

  So to not allow this to be turned off by people who might want to (we
  want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will
  other distros released this year), is pretty heavy-handed.
  
  It also will work in OpenSuSE 10.2 which is already released, and I
  think Fedora 6, but I've only limited experience with these.
  
  Oh, and Gentoo works just fine, and has been for the past 6 months.
 
 For most people, it simply doesn't matter whether SYSFS_DEPRECATED is 
 on or off.

Exactly.

 But accidentally disabling SYSFS_DEPRECATED has proven to be a trap 
 people sometimes fall into - and tracking them down to 
 SYSFS_DEPRECATED=n sometimes takes some time.

So how do I put up the warning flag any larger than I have?

I do not want this always enabled, that option is not acceptable to me,
or to the zillions of people who are running a distro that this option
works just fine on (see above list...)

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-05 Thread Matt Mackall
On Mon, Mar 05, 2007 at 04:07:22PM -0800, Greg KH wrote:
 On Tue, Mar 06, 2007 at 12:40:52AM +0100, Adrian Bunk wrote:
  On Mon, Mar 05, 2007 at 10:58:13AM -0800, Greg KH wrote:
   
   Ok, how about the following patch.  Is it acceptable to everyone?
   
   thanks,
   
   greg k-h
   
   ---
init/Kconfig |   13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
   
   --- gregkh-2.6.orig/init/Kconfig
   +++ gregkh-2.6/init/Kconfig
   @@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
   that belong to a class, back into the /sys/class heirachy, in
   order to support older versions of udev.

   -   If you are using a distro that was released in 2006 or later,
   -   it should be safe to say N here.
   +   If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
   +   release from 2007 or later, it should be safe to say N here.
   +
   +   If you are using Debian or other distros that are slow to
   +   update HAL, please say Y here.
  ...
  
  The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally 
  for all users, and schedule it's removal for mid-2008 (or later).
  
  12 months after the first _release_ of a HAL that can live without seems 
  to be the first time when we can consider getting rid of it, since all 
  distributions with at least one release a year should ship it by then.
  
  Currently, SYSFS_DEPRECATED is only a trap for users.
 
 Huh?
 
 No, again, I've been using this just fine for about 6 months now.
 
 And what about all of the servers not using HAL/NetworkManager?
 And what about all of the embedded systems not using either?
 
 So to not allow this to be turned off by people who might want to (we
 want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will
 other distros released this year), is pretty heavy-handed.
 
 It also will work in OpenSuSE 10.2 which is already released, and I
 think Fedora 6, but I've only limited experience with these.
 
 Oh, and Gentoo works just fine, and has been for the past 6 months.

 I would just prefer to come up with an acceptable set of wording that
 will work to properly warn people.
 
 I proposed one such wording which some people took as a slam against
 Debian, which it really was not at all.
 
 Does someone else want to propose some other wording instead?

Back up a bit. Let's review:

Problem: NetworkManager stopped working with my ipw2200 on Debian/unstable

Theory A: It broke because I'm not running an as-yet-unreleased HAL.

 Then we should revert the patch pronto because it's an unqualified
 regression.

Theory B: It broke because I'm not running relatively recent HAL.

 By all accounts I'm running the latest and greatest HAL and Network
 Manager, more than recent enough to work.

Theory C: It broke because I've got some goofy config.

 My setup passes no arguments to either. The HAL config file is
 completely bare-bones and there's no sign of any configuration files
 for Network Manager.

Theory D: It broke for some nebulous Debian-related reason.

 That's a bunch of unhelpful crap.

Can we come up with an actual theory for what's wrong with my setup, please?
Like, perhaps:

Theory E: There's some undiagnosed new breakage that this introduces
that no else hit until it went into mainline.

 Hmmm, this one sounds more promising.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-05 Thread Greg KH
On Mon, Mar 05, 2007 at 07:30:21PM -0600, Matt Mackall wrote:
 On Mon, Mar 05, 2007 at 04:07:22PM -0800, Greg KH wrote:
  On Tue, Mar 06, 2007 at 12:40:52AM +0100, Adrian Bunk wrote:
   On Mon, Mar 05, 2007 at 10:58:13AM -0800, Greg KH wrote:

Ok, how about the following patch.  Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

--- gregkh-2.6.orig/init/Kconfig
+++ gregkh-2.6/init/Kconfig
@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
  that belong to a class, back into the /sys/class heirachy, in
  order to support older versions of udev.
 
- If you are using a distro that was released in 2006 or later,
- it should be safe to say N here.
+ If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+ release from 2007 or later, it should be safe to say N here.
+
+ If you are using Debian or other distros that are slow to
+ update HAL, please say Y here.
   ...
   
   The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally 
   for all users, and schedule it's removal for mid-2008 (or later).
   
   12 months after the first _release_ of a HAL that can live without seems 
   to be the first time when we can consider getting rid of it, since all 
   distributions with at least one release a year should ship it by then.
   
   Currently, SYSFS_DEPRECATED is only a trap for users.
  
  Huh?
  
  No, again, I've been using this just fine for about 6 months now.
  
  And what about all of the servers not using HAL/NetworkManager?
  And what about all of the embedded systems not using either?
  
  So to not allow this to be turned off by people who might want to (we
  want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will
  other distros released this year), is pretty heavy-handed.
  
  It also will work in OpenSuSE 10.2 which is already released, and I
  think Fedora 6, but I've only limited experience with these.
  
  Oh, and Gentoo works just fine, and has been for the past 6 months.
 
  I would just prefer to come up with an acceptable set of wording that
  will work to properly warn people.
  
  I proposed one such wording which some people took as a slam against
  Debian, which it really was not at all.
  
  Does someone else want to propose some other wording instead?
 
 Back up a bit. Let's review:
 
 Problem: NetworkManager stopped working with my ipw2200 on Debian/unstable
 
 Theory A: It broke because I'm not running an as-yet-unreleased HAL.
 
  Then we should revert the patch pronto because it's an unqualified
  regression.
 
 Theory B: It broke because I'm not running relatively recent HAL.
 
  By all accounts I'm running the latest and greatest HAL and Network
  Manager, more than recent enough to work.
 
 Theory C: It broke because I've got some goofy config.
 
  My setup passes no arguments to either. The HAL config file is
  completely bare-bones and there's no sign of any configuration files
  for Network Manager.
 
 Theory D: It broke for some nebulous Debian-related reason.
 
  That's a bunch of unhelpful crap.
 

 Can we come up with an actual theory for what's wrong with my setup, please?
 Like, perhaps:
 
 Theory E: There's some undiagnosed new breakage that this introduces
 that no else hit until it went into mainline.

Theory F:  It broke because you are using NetworkManager for your
network devices and the patches that fix this have not made it into a
real release?

I'm just guessing, but does anyone who is having this problem, NOT using
NetworkManager?

I'm running an old version of HAL just fine, but I'm not using
NetworkManager here.

I am using NetworkManager on a OpenSuSE 10.3 release, but suse's version
of NetworkManager is well known to not be anywhere near what is released
as a tarball :(

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-05 Thread Greg KH
On Mon, Mar 05, 2007 at 07:30:21PM -0600, Matt Mackall wrote:
 On Mon, Mar 05, 2007 at 04:07:22PM -0800, Greg KH wrote:
  On Tue, Mar 06, 2007 at 12:40:52AM +0100, Adrian Bunk wrote:
   On Mon, Mar 05, 2007 at 10:58:13AM -0800, Greg KH wrote:

Ok, how about the following patch.  Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

--- gregkh-2.6.orig/init/Kconfig
+++ gregkh-2.6/init/Kconfig
@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
  that belong to a class, back into the /sys/class heirachy, in
  order to support older versions of udev.
 
- If you are using a distro that was released in 2006 or later,
- it should be safe to say N here.
+ If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+ release from 2007 or later, it should be safe to say N here.
+
+ If you are using Debian or other distros that are slow to
+ update HAL, please say Y here.
   ...
   
   The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally 
   for all users, and schedule it's removal for mid-2008 (or later).
   
   12 months after the first _release_ of a HAL that can live without seems 
   to be the first time when we can consider getting rid of it, since all 
   distributions with at least one release a year should ship it by then.
   
   Currently, SYSFS_DEPRECATED is only a trap for users.
  
  Huh?
  
  No, again, I've been using this just fine for about 6 months now.
  
  And what about all of the servers not using HAL/NetworkManager?
  And what about all of the embedded systems not using either?
  
  So to not allow this to be turned off by people who might want to (we
  want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will
  other distros released this year), is pretty heavy-handed.
  
  It also will work in OpenSuSE 10.2 which is already released, and I
  think Fedora 6, but I've only limited experience with these.
  
  Oh, and Gentoo works just fine, and has been for the past 6 months.
 
  I would just prefer to come up with an acceptable set of wording that
  will work to properly warn people.
  
  I proposed one such wording which some people took as a slam against
  Debian, which it really was not at all.
  
  Does someone else want to propose some other wording instead?
 
 Back up a bit. Let's review:
 
 Problem: NetworkManager stopped working with my ipw2200 on Debian/unstable

Wait, have confirmed that if you enable this config option,
NetworkManager starts back up again and works properly?

If so, can you disable the option and strace it to see what program is
trying to access what?  That will put the
HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty
quickly :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-05 Thread Matt Mackall
On Mon, Mar 05, 2007 at 06:48:50PM -0800, Greg KH wrote:
 
 Wait, have confirmed that if you enable this config option,
 NetworkManager starts back up again and works properly?

Yep, probably should have mentioned that.

 If so, can you disable the option and strace it to see what program is
 trying to access what?  That will put the
 HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty
 quickly :)

Did that a few hours ago, got a very large dump from both programs. No
smoking guns to my eye, but I'll send you the logs later.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-05 Thread Matt Mackall
On Mon, Mar 05, 2007 at 06:48:50PM -0800, Greg KH wrote:
 If so, can you disable the option and strace it to see what program is
 trying to access what?  That will put the
 HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty
 quickly :)

Ok, I've got straces of both good and bad (5M each). Filtered out
random pointer values and the like, diffed, and filtered for /sys/,
and the result's still 1.5M. What should I be looking for?

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-05 Thread Greg KH
On Mon, Mar 05, 2007 at 09:39:47PM -0600, Matt Mackall wrote:
 On Mon, Mar 05, 2007 at 06:48:50PM -0800, Greg KH wrote:
  If so, can you disable the option and strace it to see what program is
  trying to access what?  That will put the
  HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty
  quickly :)
 
 Ok, I've got straces of both good and bad (5M each). Filtered out
 random pointer values and the like, diffed, and filtered for /sys/,
 and the result's still 1.5M. What should I be looking for?

Failures when trying to read from /sys/class/net/

Or opening the directory and iterating over the subdirs in there.  Or
something like that.

But the /sys/class/net/ stuff should hopefully help narrow it down.

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED

2007-03-05 Thread Matt Mackall
On Mon, Mar 05, 2007 at 08:03:50PM -0800, Greg KH wrote:
 On Mon, Mar 05, 2007 at 09:39:47PM -0600, Matt Mackall wrote:
  On Mon, Mar 05, 2007 at 06:48:50PM -0800, Greg KH wrote:
   If so, can you disable the option and strace it to see what program is
   trying to access what?  That will put the
   HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty
   quickly :)
  
  Ok, I've got straces of both good and bad (5M each). Filtered out
  random pointer values and the like, diffed, and filtered for /sys/,
  and the result's still 1.5M. What should I be looking for?
 
 Failures when trying to read from /sys/class/net/
 
 Or opening the directory and iterating over the subdirs in there.  Or
 something like that.
 
 But the /sys/class/net/ stuff should hopefully help narrow it down.

Works:

6857  open(/sys/class/net,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13
6857  fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
6857  fcntl64(13, F_SETFD, FD_CLOEXEC)  = 0
6857  getdents64(13, /* 5 entries */, 4096) = 120
6857  readlink(/sys/class/net/eth1, 0x80a2450, 256) = -1 EINVAL
(Invalid argument)
6857  readlink(/sys/class/net/eth1/device,
../../../devices/pci:00/:00:1e.0/:02:02.0, 256) = 53
6857  readlink(/sys/class/net/lo, 0x80a2450, 256) = -1 EINVAL
(Invalid argument)
6857  readlink(/sys/class/net/lo/device, 0x80a2450, 256) = -1 ENOENT
(No such
file or directory)
6857  readlink(/sys/class/net/eth0, 0x80a2450, 256) = -1 EINVAL
(Invalid argument)
6857  readlink(/sys/class/net/eth0/device,
../../../devices/pci:00/:00:1e.0/:02:01.0, 256) = 53
6857  getdents64(13, /* 0 entries */, 4096) = 0
6857  close(13) = 0

Breaks:

3620  open(/sys/class/net,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13
3620  fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
3620  fcntl64(13, F_SETFD, FD_CLOEXEC)  = 0
3620  getdents64(13, /* 5 entries */, 4096) = 120
3620  readlink(/sys/class/net/eth1,
../../devices/pci:00/:00:1e.0/00\00:02:02.0/eth1, 256) = 55
3620
readlink(/sys/devices/pci:00/:00:1e.0/:02:02.0/eth1/device,
0x809e910, 256) = -1 ENOENT (No such file or directory)
3620  readlink(/sys/class/net/lo, ../../devices/virtual/net/lo,
256) = 28
3620  readlink(/sys/devices/virtual/net/lo/device, 0x809e960, 256) =
-1 ENOEN\T (No such file or directory)
3620  readlink(/sys/class/net/eth0,
../../devices/pci:00/:00:1e.0/00\00:02:01.0/eth0, 256) = 55
3620
readlink(/sys/devices/pci:00/:00:1e.0/:02:01.0/eth0/device,
0x809e960, 256) = -1 ENOENT (No such file or directory)
3620  getdents64(13, /* 0 entries */, 4096) = 0
3620  close(13) = 0

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html