Alan Stern schrieb:
> On Tue, 3 Nov 2009, Frank Schaefer wrote
>> Basically, I have no problem to agree here.
>> But what's the price we pay for this solution(s) in this case (and most
>> other devices with windows-driver-disc-mode) ?
>> You should not ignore the problems coming-up with the discussed
>> userspace-solutions.
>> This is not ONLY about technical aspects. We already discussed usability
>> and maintanance. Think about the whole product, not only the kernel-part.
>> Then, please, make a list of ALL pros and cons a make a pragmatic decision.
>>
>
> Here's my first attempt at considering all the pros and cons. Has
> anything important been left out?
>
> First, let's consider the case where the relevant drivers/programs are
> already present when a switchable device is plugged in. Then
> presumably it all works correctly and there's no problem. :-)
>
> So second, let's consider the case where the drivers/programs are not
> already present. The device does not get switched automatically. In
> order to do anything with it, the user must upgrade his system.
>
> 1. If the mode-switch code is in the kernel: The user must install
> a new kernel. This might mean downloading a new version from
> the distro or it might mean installing a patch and rebuilding
> manually.
>
> 2. If the mode-switch code is in userspace: The user must update
> the mode-switch program. This might mean adding a line to a
> udev script file, installing a new binary package, or
> downloading new source code to usb_modeswitch and rebuilding
> manually.
>
> 3. If the policy is handled by a userspace program while the
> mechanism is handled by the kernel: The user will have to carry
> out 1 or 2 or possibly both. Hence this case reduces to the
> earlier cases (plus the fact that the user somehow has to
> determine which steps are necessary).
>
> Either way, once the upgrade has been done the device will work. So
> the only question is which is easier for everybody, 1 or 2?
>
> Clearly 1 puts more of a burden on the kernel/distro developers while 2
> puts more of a burden on the userspace support teams. But they
> comprise a relatively small number of people compared to the total user
> population. For users, then, which is easier?
>
> Downloading a new kernel package is roughly equivalent to downloading a
> new usb_modeswitch binary package. It takes longer and there might be
> administrative issues (updating the kernel has more repercussions than
> updating a single program), but overall they are similar.
>
> Clearly editing a udev script is very easy. Downloading patches or
> source code and rebuilding by hand requires a certain amount of skill,
> and it is not something most people would care to do -- although if
> they had to, building a program is much easier than building a kernel.
>
> Thus, in terms of the amount of work required of the user, I'd say that
> 1 is worse than 2. But there's more to consider. How long does it
> take for new-device support to get disseminated?
>
> User programs like usb_modeswitch can be updated very rapidly. It's
> merely a question of writing the new code and making it publicly
> available in the appropriate repository. Typically this might involve
> a delay of a few days. By contrast, new kernels appear roughly every
> three months. It's possible that new mode-switch code would be allowed
> in a stable release (although this is far from certain). If so, then
> the delay could drop as low as a few weeks.
>
> Thus, in terms of the delay time for new support, I'd say again that 1
> is worse than 2. Finally, let's consider adding support for a new
> device to an old system.
>
> An old system is not readily upgradable. But _some_ sort of upgrade is
> needed to support new devices.
>
> If all that is needed is a modification to a udev script,
> there is no problem.
>
> Installing a new version of a program might be difficult
> because of library dependencies that aren't up to date.
>
> Installing a new version of the kernel might be difficult
> because of incompatibilities with old userspace components.
>
> Comparing the last two directly is hard; either could be a
> show-stopper. The ideal solution would be to provide a way to upgrade
> a mode-switching program by modifying a text configuration or script
> file rather than by changing the code. For example, if usb_modeswitch
> could parse a text file containing device IDs to match and packet
> contents to send, then upgrades would be very easy.
>
> In short, for users I don't see any advantage to putting the
> mode-switching stuff in the kernel, whereas there may be considerable
> advantages to putting it in userspace.
>
> The only exception would be the case that Oliver is worried about,
> where a device loses its mode setting during a reset or system sleep.
> In principle the kernel could put it back in the correct mode while
> keeping the device's identity intact (although the code to do this
> would be extremely ugly, and convincing people to allow it would be
> hard). Even then, I don't see how existing serial/phone connections
> could be maintained across a reset, so there might not be any point.
>
> Alan Stern
>
First of all: flexibility of changes (that's what you're talking about
here) is not the only aspect to consider.
I can follow you, but you assume that the changes are coming from the
userspace side.
But isn't it the other way around for these sysconfig-topics ?
Usually:
=> a new driver / support for a specific hardware is added to the kernel.
=> the distros should notice that and try to provide a
sysconfig+tools+... to make it as easy as possible for users to use the
device
In theory, the distro-people watch the kernel-changes and process them
all accurately.
They check if they are relevant for any part of their userspace-config
and do the necessary changes.
But, of course, that's an illusion. It's a tough job for them to put the
puzzle together and they highly depend on user-feedback (bug reports).
Please don't understand me wrong: the distros are giving their best and
they are doing a really great job !
But they will *ALWAYS* lag behind.
So how can we avoid this situation and make life easier for the distros
AND the users ?
The answer is: we should not unnecessarily split things which belong
together (no difference here between kernelspace and userspace).
In this case (Windows-driver-discs), the modeswitch and the driver
clearly belong together.
Please note: we are not talking about an "extra-feature" or an
"extension". The modeswitch is an essential prerequisite for making the
device *AVAILABLE*, for making it *USABLE*.
Because we ship the driver with the kernel, we should ship the
mode-witch, too.
So let's simply put these single usb_bulk_message into the drivers, the
place which is dedicated to make these devices work and where it can be
maintained by people who really know them and usually own these devices.
I think that's worth the compromise of loosing access to the
storage-device, at least in cases like this where the device contains
nothing else then an (usually outdated) windows-driver-installer.
Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
