On Mon, Aug 31, 2009 at 12:15 PM, Hin-Tak Leung<[email protected]> wrote:
> On Mon, Aug 31, 2009 at 7:54 PM, Luis R. Rodriguez<[email protected]> wrote:
>> On Mon, Aug 31, 2009 at 11:43 AM, Hin-Tak Leung<[email protected]> wrote:
>>> On Thu, Aug 27, 2009 at 10:43 AM, Hin-Tak Leung<[email protected]> wrote:
>>>> On Thu, Aug 27, 2009 at 8:14 AM, Johannes Berg<[email protected]> wrote:
>>>>> On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote:
>>>>>
>>>>>> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
>>>>>
>>>>> Yes, but I never understood why that matters. If you've got
>>>>> compat-wireless "rfkill" loaded then the original rfkill can't be loaded
>>>>> anyway. And their symbols would probably clash anyway if the original is
>>>>> built in, in which case you can't use compat.
>>>>>
>>>>> You haven't renamed cfg80211's sysfs either, so why rfkill?
>>>>>
>>>>> johannes
>>>>>
>>>>
>>>> There are a couple of wimax drivers which depends on rfkill... or
>>>> bluetooth drivers? I think one likely reason is that there are valid
>>>> situations or hardware combinations which requires having both of them
>>>> loaded. (but that's a whole can of worms )
>>>
>>> Argh, I just have a stacktrace after reboot - toshiba_acpi.ko (on a
>>> toshiba laptop) requires the stock-kernel rfkill-* symbols, and rfkill
>>> won't load because of my modified compat-wireless rfkill_backport.ko
>>> which takes up /sys/class/rfkill rather than
>>> /sys/class/rfkill_backport . There's your reason from sysfs renaming.
>>> I wonder why/how I could unload rfkill.ko earlier, since the *_acpi.ko
>>> needs it - maybe I had acpi unloaded as a side-effect also.
>>>
>>> I guess we'll need hal to treat /sys/class/rfkill_backport like
>>> /sys/class/rfkill then - will file a bug somewhere on freedesktop,
>>> although I hear hal is on its way out....
>>
>> How many modules depend on rfkill, as with ssb maybe we should just
>> add them all ? I'm not volunteering though, but just pointing out that
>> if its not that many as with ssb perhaps its best to just add the
>> other drivers.
>>
>> Luis
>>
>
> for fedora 11's stock, (which probably have all the modules of any use)
> #depmod -v | grep rfkill_register shows, besides drivers/net/wireless/* ,
>
> kernel/drivers/net/usb/hso.ko
> kernel/drivers/platform/x86/dell-laptop.ko
> kernel/drivers/platform/x86/acer-wmi.ko
> kernel/drivers/platform/x86/hp-wmi.ko
> kernel/drivers/platform/x86/sony-laptop.ko
> kernel/drivers/platform/x86/thinkpad_acpi.ko
> kernel/drivers/platform/x86/toshiba_acpi.ko
> kernel/net/wireless/cfg80211.ko
OK not so bad except for:
> kernel/net/wimax/wimax.ko
That's touching another subsystem but we could technically merge wimax
into compat-wireless if Inaky thinks that's a good idea. the point
here is to unify anything that uses rfkill for backport usage.
> If everything that depends on rkill is bundled with
> compat-wireless, there is probablt no need for the symbol and sysfs
> renaming hacks.
Right which is why I think this may be reasonable to do. Any thoughts Inaky?
Luis
Hi Luis,
> > OK not so bad except for:
> >
> > > kernel/net/wimax/wimax.ko
> >
> > That's touching another subsystem but we could technically merge wimax
> > into compat-wireless if Inaky thinks that's a good idea. the point
> > here is to unify anything that uses rfkill for backport usage.
>
> Oh boy, can of worms
>
> I have my own compat-wimax already, which already handles things for
> backwards compat (many #ifdef hacks to simplify life) and which is
> heavily used internally.
>
> I don't really know how much worth it might be and I know I don't have
> resources to support both.
for the wireless-compat tree, I would just remove the RFKILL support for
WiMAX. It is really not worth to support it.
Regards
Marcel
On Mon, 2009-08-31 at 13:25 -0600, Luis R. Rodriguez wrote:
> OK not so bad except for:
>
> > kernel/net/wimax/wimax.ko
>
> That's touching another subsystem but we could technically merge wimax
> into compat-wireless if Inaky thinks that's a good idea. the point
> here is to unify anything that uses rfkill for backport usage.
Oh boy, can of worms
I have my own compat-wimax already, which already handles things for
backwards compat (many #ifdef hacks to simplify life) and which is
heavily used internally.
I don't really know how much worth it might be and I know I don't have
resources to support both.
> > If everything that depends on rkill is bundled with
> > compat-wireless, there is probablt no need for the symbol and sysfs
> > renaming hacks.
>
> Right which is why I think this may be reasonable to do. Any thoughts Inaky?
> Luis
--
-- Inaky
On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<[email protected]> wrote:
> Hi Luis,
>
>> > OK not so bad except for:
>> >
>> > > kernel/net/wimax/wimax.ko
>> >
>> > That's touching another subsystem but we could technically merge wimax
>> > into compat-wireless if Inaky thinks that's a good idea. the point
>> > here is to unify anything that uses rfkill for backport usage.
>>
>> Oh boy, can of worms
>>
>> I have my own compat-wimax already, which already handles things for
>> backwards compat (many #ifdef hacks to simplify life) and which is
>> heavily used internally.
>>
>> I don't really know how much worth it might be and I know I don't have
>> resources to support both.
>
> for the wireless-compat tree, I would just remove the RFKILL support for
> WiMAX. It is really not worth to support it.
Works for me, we then still need to address (if we really care) the
platform stuff. If someone is interested feel free to send patches to
add those, I figure as long we get down to the latest supported stable
kernel it should be good. The latest supported stable kernel is always
on display on kernel,org, today being 2.6.27.
Luis
On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<[email protected]> wrote:
> On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<[email protected]> wrote:
>> Hi Luis,
>>
>>> > OK not so bad except for:
>>> >
>>> > > kernel/net/wimax/wimax.ko
>>> >
>>> > That's touching another subsystem but we could technically merge wimax
>>> > into compat-wireless if Inaky thinks that's a good idea. the point
>>> > here is to unify anything that uses rfkill for backport usage.
>>>
>>> Oh boy, can of worms
>>>
>>> I have my own compat-wimax already, which already handles things for
>>> backwards compat (many #ifdef hacks to simplify life) and which is
>>> heavily used internally.
>>>
>>> I don't really know how much worth it might be and I know I don't have
>>> resources to support both.
>>
>> for the wireless-compat tree, I would just remove the RFKILL support for
>> WiMAX. It is really not worth to support it.
>
> Works for me, we then still need to address (if we really care) the
> platform stuff. If someone is interested feel free to send patches to
> add those, I figure as long we get down to the latest supported stable
> kernel it should be good. The latest supported stable kernel is always
> on display on kernel,org, today being 2.6.27.
BTW inaky -- this is actually up to you, are you wiling to live with
no rfkill for compat?
Luis
On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<[email protected]> wrote:
> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<[email protected]> wrote:
> >> Hi Luis,
> >>
> >>> > OK not so bad except for:
> >>> >
> >>> > > kernel/net/wimax/wimax.ko
> >>> >
> >>> > That's touching another subsystem but we could technically merge wimax
> >>> > into compat-wireless if Inaky thinks that's a good idea. the point
> >>> > here is to unify anything that uses rfkill for backport usage.
> >>>
> >>> Oh boy, can of worms
> >>>
> >>> I have my own compat-wimax already, which already handles things for
> >>> backwards compat (many #ifdef hacks to simplify life) and which is
> >>> heavily used internally.
> >>>
> >>> I don't really know how much worth it might be and I know I don't have
> >>> resources to support both.
> >>
> >> for the wireless-compat tree, I would just remove the RFKILL support for
> >> WiMAX. It is really not worth to support it.
> >
> > Works for me, we then still need to address (if we really care) the
> > platform stuff. If someone is interested feel free to send patches to
> > add those, I figure as long we get down to the latest supported stable
> > kernel it should be good. The latest supported stable kernel is always
> > on display on kernel,org, today being 2.6.27.
>
> BTW inaky -- this is actually up to you, are you wiling to live with
> no rfkill for compat?
I don't really mind -- but it could be a problem for anyone trying to
use it. Not that I recommend not being able to switch the radio off :)
however, the WiMAX stack has APIs for it too, so at least there is a
workaround.
But remember, I won't be able to support it at all.
--
-- Inaky