Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode

[Frank Schaefer <schaefer.frank@gmx.net>]

Matthew Dharm schrieb:
> On Mon, Nov 02, 2009 at 09:07:20PM +0100, Frank Schaefer wrote:
>   
>> Matthew Dharm schrieb:
>>     
>>> I am thinking about the users.  Do you really think someone who has
>>> difficulty installing a new udev rule (probably a line or two of text
>>> copied from a google search) or installing a new version of usb_modeswitch
>>> (probably one or two commands to the distro package manager) will have an
>>> easier time doing a custom kernel-compile and update?
>>>       
>> I think users should not need to do ANY of these things ! That's called
>> usability.
>>     
>
> So, new hardware should "magically" work?  When you can write software to
> support hardware that doesn't exist yet, let me know.
>   
I can make nothing of that.
It really doesn't make sense to discuss about mode-switches for devices
for which we not even have a driver.
>> Which users do you think know how to create udev-rules and how to
>> compile a kernel ?
>> Of course you and me and likely all others on this mailing-list and
>> maybe you think Linux should be for them, only.
>>
>> I think we should do as much as possible to improve Linux-usability for
>> "normal" and even "less experienced" users.
>>     
>
> Okay, let's talk about "less experienced" users.  Suppose you are one of
> these users.  You get a new device, and you want to use it.  You do some
> web searching, and discover either:
>
> (a) you need to download and recompile your kernel
> (b) you need to cut-and-paste some text from a web page into a file
>
> Which do you think is easier?
>   
It's easier to let the driver/kernel do the mode-switch automatically if
it makes sense !
That's perfect Plug'N Play and (a) and (b) are dispensable.

Apart from that, I think that "just cut-and-paste some text from a web
page into a file" is an illusion.
Starts with the right key-words you need for the search and continues
with the quality of the documentation.
It's not that easy to create universal and especially complete manuals
(we all love documentation-work right !? ;) ).
For example: what's udev ? Of course, WE know, but ...
> And, the situation above pre-supposes that the requisite changes (kernel or
> userspace) haven't already been picked up by a distro maintainer.
>
>   
>> And in this case, it would be really easy.
>>     
>>> Updates in userspace are universally easier; on users, on kernel deves, and
>>> on distro devs.
>>>
>>>       
>> Why ? Of course, the benfit for kernel-developers is that the work is
>> done by others...
>> But for the distros it makes life much more difficult in many respects.
>>     
>
> I highly doubt this.  Distros must very carefully test all the kernel
> changes they decide to pull in.  Each and every change in a kernel-layer is
> a high-risk change for them.  Changing userspace packages is much
> lower-risk, and thus consumes correspondingly fewer resources.
>
>   
And they don't have to test userspace-software carefully, too ???
Especially sysconfig-software ?
I can't see a significant difference here.
>> And users are in the somehow insane situation that they have to keep the
>> driver (kernel) AND the "key to be able to use it" up-to-date.
>> That's not only a problem because they both things from different
>> sources/directions !
>>     
>
> I think you may have missed part of an earlier discussion, wherein we
> discussed such devices which would NOT need ANY kernel changes.  The idea
> was that udev could "eject" the fake-USB device, then add the device IDs to
> the serial/cdc_amc/whatever driver dynamically, at runtime.  Thus, no need
> to make any kernel updates at all.
>
> And, that system works *today* with the existing kernel code.
>
> Matt
>   
You didn't understand me right. No problem.
I was talking about inconsistencies we get when driver and the
mode-switch-part come from different sources.
That's one of the main problems in Unix-world, maybe that's the price we
have to pay for thinking more modular (packages) than in products like
in M$-world.
But we shouldn't pay that price needlessly because of splitting things
at the wrong position.

Frank