On Mon, Mar 05, 2007 at 04:37:15PM -0800, Greg KH wrote:
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.
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.
- Ted
-
