[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070306011009.GA13267@kroah.com>
Date: Mon, 5 Mar 2007 17:10:09 -0800
From: Greg KH <greg@...ah.com>
To: Theodore Tso <tytso@....edu>, Bron Gondwana <brong@...tmail.fm>,
Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, yi.zhu@...el.com, jketreno@...ux.intel.com,
akpm@...l.org
Subject: Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Mon, Mar 05, 2007 at 07:56:25PM -0500, Theodore Tso wrote:
> On Mon, Mar 05, 2007 at 04:37:15PM -0800, Greg KH wrote:
> > But I AM TRYING TO MAKE IT COMPATIBLE!!!
> >
> > That's what that config option is there for. If you happen to be
> > running a newer userspace, a different distro than what is in Debian
> > right now, or don't use HAL and Networkmanager, then disable that
> > option. Then all of sysfs looks just like it used to, no user visble
> > changes at all. It doesn't get any more compatible than that.
>
> This is great, but I think the real problem isn't the config option,
> but what is changing if the config option isn't enabled. The claim
> which some, including Matt and Bron, seem to be making is that if you
> turn *off* CONFIG_SYSFS_DEPRECATED, you must be using at least hal
> 0.5.9-rc1, released ***yesterday***, or suffer breakages for at least
> some system configurations.
Ok, well that has been proven incorrect. I originally thought it was
HAL that had the problem, but I think that is not true, as I am using
the older version of hal here (0.5.7.1) just fine.
> So the problem with putting a date in Kconfig.txt help file, or in
> Documentation/feature-removal-schedule.txt, is that if there are other
> incompatible changes which are added to sysfs in say, December 2007 or
> January 2008, but which are papered over with CONFIG_SYSFS_DEPRECATED,
> and then come June 2008, CONFIG_SYSFS_DEPRECATED is unceremoniously
> ripped out, then users will get screwed.
>
> So the question really is are we really done making changes to sysfs,
> or maybe what we should do is talk about major version numbers to
> sysfs. Call what we have currently not CONFIG_SYSFS_DEPRECATED, but
> rather CONFIG_SYSFS_LAYOUT_1. At the moment, CONFIG_SYSFS_LAYOUT_2 is
> undergoing changes, but at some point we need to lock down and state
> that Layout version 2 is never going to change, and then people who
> want changes can go work on CONFIG_SYSFS_LAYOUT_3.
>
> The problem with calling CONFIG_SYSFS_DEPRECATED is that people think
> that since it's deprecated, it should be turned off, but if we have
> staged major version numbers, with guarantees of absolute stability
> once a particular major version number is locked down, then it may
> make it a lot easier to talk about what version of hal and udev and
> Network Manager is really needed for different versions.
This is what Documentation/ABI/ has tried to nail down, unfortunatly it
has turned out to be very hard to track down all of the odd userspace
programs that use sysfs and see what they are relying on. We are slowly
fixing things, as is proof in the OpenSuSE and Gentoo releases.
And I'll be the first to admit that the ABI/ directory needs some
flushing out...
And it isn't really a whole different layout, the only problem here is
that a directory has turned into a symlink, so programs that were not
written that well (and I'll be the first to admit that I made the same
mistake in udev many years ago) and can't handle the change.
So numerous programs "just work" fine, but for a limited few, they have
problems, hence the config option so that nothing will break.
And if you look in the ABI/ directory, it describes this usage of the
class devices in sysfs. But again, no one is flushing out the users of
these features, or even reading the stuff that is there...
So, again, a better wording for the CONFIG help text anyone? Or a
better name for the CONFIG value itself?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists