On Mon, 2008-11-17 at 19:34 +0200, Tomas Winkler wrote:
> There actually complains about slow reconnection,
Ok I guess then I haven't seen them for some reason.
Either way, here's a quick summary:
* locking issues with the callback are fixed by removing it
* callback is incorrect when you're only suspended for a very short
time
* callback is incorrect when you're in non-STA modes
* suspend/resume cannot be implemented well through this callback, at
least not the way it is written now and needs to do a whole lot more
* there's no "slow" issue when you actually resume in a different
location where the AP is not around any more
* there should be no "slow" issue when the AP properly deauthenticates
when receiving data frames
This was an RFC. I'm convinced it should go in, but I don't make those
decisions anyway. I've outlined my reasons for it.
> Second we used the
> same mechanism to
> recover from rfkill which wasn't submitted. rfkill needs also mac80211
> treatment.
Sure does, and I've even described how I'd do it in some email. Seems
nobody actually cares enough though to invest the day or two it would
take to write it. And I don't care about killswitches at all,
fortunately, so I don't need to touch that mess.
johannes
On Mon, Nov 17, 2008 at 06:59:59PM +0100, Johannes Berg wrote:
> On Mon, 2008-11-17 at 19:34 +0200, Tomas Winkler wrote:
>
> > There actually complains about slow reconnection,
>
> Ok I guess then I haven't seen them for some reason.
>
> Either way, here's a quick summary:
> * locking issues with the callback are fixed by removing it
> * callback is incorrect when you're only suspended for a very short
> time
> * callback is incorrect when you're in non-STA modes
> * suspend/resume cannot be implemented well through this callback, at
> least not the way it is written now and needs to do a whole lot more
> * there's no "slow" issue when you actually resume in a different
> location where the AP is not around any more
> * there should be no "slow" issue when the AP properly deauthenticates
> when receiving data frames
>
> This was an RFC. I'm convinced it should go in, but I don't make those
> decisions anyway. I've outlined my reasons for it.
I agree that it seems to solve problems, and there is little benefit
tokeeping the callback in question. I'm going to send this upstream.
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Mon, 2008-11-17 at 20:12 +0200, Tomas Winkler wrote:
> I've posted something based on plugging into notification chain. It
> worked but wasn't accepted I hoped that who rejected will supply
> alternative solution...
Sorry, that's not how it works... Those who want the functionality are
generally expected to do the work, and if the design phase happens
behind closed doors they don't get to complain...
johannes
On Mon, Nov 17, 2008 at 7:59 PM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2008-11-17 at 19:34 +0200, Tomas Winkler wrote:
>
>> There actually complains about slow reconnection,
>
> Ok I guess then I haven't seen them for some reason.
>
> Either way, here's a quick summary:
> * locking issues with the callback are fixed by removing it
> * callback is incorrect when you're only suspended for a very short
> time
> * callback is incorrect when you're in non-STA modes
> * suspend/resume cannot be implemented well through this callback, at
> least not the way it is written now and needs to do a whole lot more
> * there's no "slow" issue when you actually resume in a different
> location where the AP is not around any more
> * there should be no "slow" issue when the AP properly deauthenticates
> when receiving data frames
>
> This was an RFC. I'm convinced it should go in, but I don't make those
> decisions anyway. I've outlined my reasons for it.
My concern is what is immediate impact of this. Whether we fix mac
notify for short term
and we'll remove it when resume/suspend is available or we have
suspend/resume worked out in 2h.
>
>> Second we used the
>> same mechanism to
>> recover from rfkill which wasn't submitted. rfkill needs also mac80211
>> treatment.
>
> Sure does, and I've even described how I'd do it in some email. Seems
> nobody actually cares enough though to invest the day or two it would
> take to write it. And I don't care about killswitches at all,
> fortunately, so I don't need to touch that mess.
I've posted something based on plugging into notification chain. It
worked but wasn't accepted I hoped that who rejected will supply
alternative solution...
Tomas
> johannes
>
On Mon, Nov 17, 2008 at 9:46 PM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2008-11-17 at 20:12 +0200, Tomas Winkler wrote:
>
>> I've posted something based on plugging into notification chain. It
>> worked but wasn't accepted I hoped that who rejected will supply
>> alternative solution...
>
> Sorry, that's not how it works... Those who want the functionality are
> generally expected to do the work,
I didn't get the feeling I'm the only one who wants it there were
alternative design which shell be backed up by some code.
and if the design phase happens
> behind closed doors they don't get to complain...
RFC patch is a valid design presentation. This is not valid complain of yours.
Tomas
On Tue, Nov 18, 2008 at 9:46 PM, John W. Linville
<[email protected]> wrote:
> On Mon, Nov 17, 2008 at 06:59:59PM +0100, Johannes Berg wrote:
>> On Mon, 2008-11-17 at 19:34 +0200, Tomas Winkler wrote:
>>
>> > There actually complains about slow reconnection,
>>
>> Ok I guess then I haven't seen them for some reason.
>>
>> Either way, here's a quick summary:
>> * locking issues with the callback are fixed by removing it
>> * callback is incorrect when you're only suspended for a very short
>> time
>> * callback is incorrect when you're in non-STA modes
>> * suspend/resume cannot be implemented well through this callback, at
>> least not the way it is written now and needs to do a whole lot more
>> * there's no "slow" issue when you actually resume in a different
>> location where the AP is not around any more
>> * there should be no "slow" issue when the AP properly deauthenticates
>> when receiving data frames
>>
>> This was an RFC. I'm convinced it should go in, but I don't make those
>> decisions anyway. I've outlined my reasons for it.
>
> I agree that it seems to solve problems, and there is little benefit
> tokeeping the callback in question. I'm going to send this upstream.
>
I suggest to run this code before going upstream
Tomas
some bugs related to coming from resume is filed caused by removing
this callback function, any body looking into alternatives to share
how to fix this problem.
On Tue, Nov 18, 2008 at 3:08 PM, Tomas Winkler <[email protected]> wrote:
> On Tue, Nov 18, 2008 at 9:46 PM, John W. Linville
> <[email protected]> wrote:
>> On Mon, Nov 17, 2008 at 06:59:59PM +0100, Johannes Berg wrote:
>>> On Mon, 2008-11-17 at 19:34 +0200, Tomas Winkler wrote:
>>>
>>> > There actually complains about slow reconnection,
>>>
>>> Ok I guess then I haven't seen them for some reason.
>>>
>>> Either way, here's a quick summary:
>>> * locking issues with the callback are fixed by removing it
>>> * callback is incorrect when you're only suspended for a very short
>>> time
>>> * callback is incorrect when you're in non-STA modes
>>> * suspend/resume cannot be implemented well through this callback, at
>>> least not the way it is written now and needs to do a whole lot more
>>> * there's no "slow" issue when you actually resume in a different
>>> location where the AP is not around any more
>>> * there should be no "slow" issue when the AP properly deauthenticates
>>> when receiving data frames
>>>
>>> This was an RFC. I'm convinced it should go in, but I don't make those
>>> decisions anyway. I've outlined my reasons for it.
>>
>> I agree that it seems to solve problems, and there is little benefit
>> tokeeping the callback in question. I'm going to send this upstream.
>>
> I suggest to run this code before going upstream
> Tomas
> --
> 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
>
On Fri, Dec 05, 2008 at 03:53:18PM -0800, mohamed salim abbas wrote:
> some bugs related to coming from resume is filed caused by removing
> this callback function, any body looking into alternatives to share
> how to fix this problem.
Perhaps you could give us a link to the reported bugs?
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Fri, 2008-12-05 at 15:53 -0800, mohamed salim abbas wrote:
> some bugs related to coming from resume is filed caused by removing
> this callback function, any body looking into alternatives to share
> how to fix this problem.
Yes, in fact, somebody _is_ looking into implementing _proper_
suspend/resume support. You'll either have to wait or help out.
johannes