On Tue, Mar 07, 2006 at 07:11:27PM -0800, Simon Barber wrote:
> Overloading configuration parameters with extra meanings like this makes
> it harder to configure the system - I think it's useful to keep an
> on/off function separate from the power setting.
>
> Simon
The main issue I have with adding another separate setting is
that I'm trying to fight the sprawling wireless API. Every time we add
a new command in the API, we have to implement it in a dozen driver
and support it more or less forever (deprecating things is hard).
Many people already complain that Wireless Extension is too
bloated (while simultaneously complaining that their pet feature is
not available).
I'm personally pragmatic, not dogmatic. So, I'm asking myself
these two questions :
1) Why is this setting useful to the user ?
If a user want to disable/power-off its network interface, the
official and supported way to do that is 'ifconfig ethX down'. Most
driver do support that, and it leaves the network stack in a
consistent state (interface is down, routing will use an alternate
interface).
Moreover, Linux power management and ACPI will probably define
ways to suspend the device, if not done already.
So, why do we need yet another way to acheive the same thing ?
2) in practical terms, for the average user, what is the
difference between shutting down the Tx power and shutting down the
whole MAC ? If you shut down Tx power, you can't remain associated,
you can't scan, and can't do anything useful in general, so there is
little point in keeping the rest of the MAC active.
Also, I disagree that it make things harder for the user. By
default, this parameter has the right value (on), so the user doesn't
have to touch it, and it's only if he touches it that he may run into
troubles. There are plenty of driver setting available (standard or
private) that the user will never touch.
To me, it's clear that we don't need to waste our collective
time supporting this feature.
And if a driver author insist on exporting such feature, he
can use 'txpower on'. It's not perfect, but a pretty good match. If
the author doesn't like that, there is plenty of driver specific APIs
available (iwpriv, /proc, sysfs...).
Have fun...
Jean
-
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
