Re: [PATCH 1/3] iwlwifi: adding channels to sysfs

[Michael Buesch <mb@bu3sch.de>]

On Friday 13 June 2008 14:11:36 Tomas Winkler wrote:
> On Fri, Jun 13, 2008 at 11:35 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> >
> >> >>  drivers/net/wireless/iwlwifi/iwl4965-base.c |   58 ++++++++++++++++++++++++++-
> >> >>  1 files changed, 56 insertions(+), 2 deletions(-)
> >> >>
> >> >> diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
> >> >> index 81a1c22..c179b21 100644
> >> >> --- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
> >> >> +++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
> >> >> @@ -4122,8 +4122,62 @@ static DEVICE_ATTR(power_level, S_IWUSR | S_IRUSR, show_power_level,
> >> >>  static ssize_t show_channels(struct device *d,
> >> >>                            struct device_attribute *attr, char *buf)
> >> >>  {
> >> >> -     /* all this shit doesn't belong into sysfs anyway */
> >> >> -     return 0;
> >> >
> >> > Hehe. Do you really have to? You can query this information with
> >> > nl80211. I don't know why you need all that sysfs stuff anyway.
> >>
> >> I'm not sure why Yi has cut off the log message but original was
> >>
> >> 'This patch returns channel list to sysfs. This is requirement
> >> for validation purposes'
> >>
> >> Our automation is build around sysfs and wext and I'm not going to
> >> rewrite it now.
> >
> > If you managed to get along without this for so long, why is it needed
> > in upstream now?
> 
> We didn't run without it, We  were developing HW 5000 on older kernel
> now I just merging it upstream. See my announcement  Try to imagine
> that there is world on totally different planet with different
> gravitation constant,
> 
> > Remember, sysfs is API. You don't get to change it gratuitously, so
> > neither should you add to it gratuitously. And we already _have_ API for
> > this particular thing which is not dependent on a particular
> > hardware/driver to boot!
> Agree. We've just returned what was there before
> I think you understand what legacy means after your try to replace
> wext. It will take time
> till we switch to new API. Unfortunately cannot fix everything in one day.


IMO a compromise could be to put this API under a default-off kconfig option
with a big fat warning that the API is supposed to be deleted and replaced
by cfg80211 soon. So this would only be temporary API for special purposes
that nobody should actually use. But if somebody needs to, he can do so and
has no loss of functionality for the time until the correct API is established.

-- 
Greetings Michael.