Frank Schaefer schrieb:
> Matthew Dharm schrieb:
>
>> On Sat, Oct 17, 2009 at 11:34:07AM -0400, Alan Stern wrote:
>>
>>
>>> On Sat, 17 Oct 2009, Oliver Neukum wrote:
>>>
>>>
>>>
>>>> Am Samstag, 17. Oktober 2009 15:14:28 schrieb Frank Schaefer:
>>>>
>>>>
>>>>> I can think of multiple solutions for this, my first questions are:
>>>>> Is there already a common solution for these devices in the kernel ?
>>>>> How widespread is this bad habit of device-design ? So far, the only
>>>>> devices I know are
>>>>>
>>>>>
>>>> This is usually handled by the modeswitch tool outside the kernel.
>>>>
>>>>
>>> Alternatively, you may be able to force the device to switch modes by
>>> running the "eject" program on it.
>>>
>>> There is mode-switching code in the kernel for a few devices. The
>>> current trend is to move this out of the kernel and let user programs
>>> be responsible for it.
>>>
>>>
>> If you go with the current trend, then you probably will want to write some
>> UDEV rules to recognize these devices and issue the mode-changing command
>> (either modeswitch or eject).
>>
>> Matt
>>
>>
> Thanks for your replies, I really didn't know that there are so many
> devices showing this behavior.
>
> On Windows, AVM does the fast-eject for its devices with a small
> filter-driver avmeject.sys.
> I will try to find out the "magic sequence" needed for the mode-switch
> with a USB-logger.
>
> Regards,
> Frank
>
I finally found the "magic" sequence.
In the meantime I've been thinking a lot (too much ?) about HOW and
WHERE to do the mode-switching.
The mailing-list-archieves were really inspiring, maybe you remember the
discussion about Tejun Heos' patches in april 2008.
The conclusion was that there is no clearly preferable way to do this
and that compromises are inevitable.
The attached patch adds the mode-switching-procedure to the WLAN-driver
(ar9170usb) and disables the storage device in the usb-storage-driver.
I really think the mode-switching should be done in the kernel and not
in user-space for reasons of usability.
Doing it in the driver means putting the code for these device together
in a single place.
It also doesn't "pollute" the driver with much code (adds a single
usb_bulk_msg()).
Another benfit is that it binds the mode-switching to the driver. If the
driver is blacklisted/not used, there will be no mode-switching.
If there would be a way to keep the usb-storage-driver enabled as
"fallback-driver" it would be an almost perfect solution...
Regards,
Frank
Christian Lamparter schrieb:
> On Sunday 01 November 2009 21:24:28 Frank Schaefer wrote:
>
>> Matthew Dharm schrieb:
>>
>>> On Sun, Nov 01, 2009 at 07:29:20PM +0100, Josua Dietze wrote:
>>>
>>>> Frank Schaefer schrieb:
>>>>
>>>>> I really think the mode-switching should be done in the kernel and not
>>>>> in user-space for reasons of usability.
>>>>>
>>>> What is wrong with an udev rule entry? By the way, did the "eject"
>>>> command line tool work as well?
>>>>
>>> And I think it should be done in userspace for issues of maintainability
>>> and useability. It is much easier for users to upgrade their udev then
>>> their kernel.
>>>
>> Maintainability for whom ? The kernel-devs or the distro-people and the
>> users ? ;)
>>
>> Please think about the users. They don't know that they have to create
>> udev-rules or have to install additional packages like usb_modeswitch
>> (which is nevertheless a great tool !).
>> And even if they know, they don't want to do that. So it's up to the
>> distros to do this automatically, which will in reality never come true
>> for all devices and distros.
>>
> yes, please think about the users!
>
> All not-so-trival-changes have to go through wireless-testing / wireless-next,
> net-next, linux-next until it hits finally the mainline... And then only users
> which are able to update their kernels will benefit, *everyone else* has
> to wait until their distros to pick up the new kernel... this could be easily more
> than a year before the device will work right out of the box for *everyone else*.
>
Which potential not-so-trivial-changes do you think of in this case ?
And userspace-software + packages have a quality-assurance-procedure,
too, right ? ;)
> Therefore udev should be the way to go...
Maybe it should be, but it's a solution which will never work
satisfyingly. At least as long as the needed udev-rules are not shipped
with the kernel...
> and as a bonus: a userspace/udev solution
> does work with older kernels right away!
>
> Regards,
> Chr
Frank
On Wed, 2009-11-04 at 11:16 -0500, Alan Stern wrote:
> Here's my first attempt at considering all the pros and cons. Has
> anything important been left out?
[snip]
I think you forgot to consider the case where both the driver and the
mode switch code need an update to handle a new device. This is relevant
in the case where a new device shows up that needs mode-switching, but
even after switching has an ID that the current driver doesn't know
about.
It's not clear to me which case typically happens though. I suppose that
often enough it'd be possible to have a device that shows up with a
special driver USB ID, and then after you eject it comes up again with a
regular USB ID that other devices use too.
Input from people who have such switching devices could be helpful.
johannes
Johannes Berg schrieb:
> On Sun, 2009-11-01 at 19:00 +0100, Frank Schaefer wrote:
>
>
>> The attached patch adds the mode-switching-procedure to the WLAN-driver
>> (ar9170usb) and disables the storage device in the usb-storage-driver.
>>
>
> This patch looks weird. Have you looked at zd1211rw, which also does
> this? I think it just adds something to usb-storage for the device IDs?
>
> johannes
>
Well, AFAICS, the zd1211rw does exactly what I suggest with my patch ?!
It calls a function eject_installer(...) for these devices in the
modules' probe-function which sends a single usb_bulk_msg.
Frank
Josua Dietze schrieb:
> Frank Schaefer schrieb:
>
>> I really think the mode-switching should be done in the kernel and not
>> in user-space for reasons of usability.
>
> What is wrong with an udev rule entry? By the way, did the "eject"
> command line tool work as well?
It returns an error but the device is ejected.
But do you really want the users to open a terminal window and call
"eject" each time they plug their device in ;) ?
>> It also doesn't "pollute" the driver with much code (adds a single
>> usb_bulk_msg()).
>
> That may be true for a single device but there are around 30+ others
> which are switched outside the kernel, some inside usb-storage, and
> this would add even more places where mode switching happened.
Of course I like the idea of having all mode-switches at the same place,
but we learnt from discussions in the past that there will likely never
be a unified solution for all devices.
Devices are to different. Some disconnect and change their IDs and
others only change their interface-setup.
In addition to that it depends on the purpose/type of the two devices.
In this case, the only purpose of the storage device is to provide
windows-drivers for installation. When the driver is installed, the
storage-device should not appear any more.
>> Another benfit is that it binds the mode-switching to the driver. If the
>> driver is blacklisted/not used, there will be no mode-switching.
>
> But how would you access the storage part of the device then?
>
> Josua
Never, that's the compromise we have to make. But we can really make it,
simply because we will never need it.
Please let me know if there is a possibility to "keep" the
usb-mass-storage-driver as "fallback-driver".
Frank
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
On Mon, Nov 02, 2009 at 01:10:01PM -0800, Matthew Dharm wrote:
> 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.
Search the archives for "Toshiba G450" if you want to find that discussion.
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed
suction darts!
-- Salesperson to Greg
User Friendly, 12/30/1997
Oliver Neukum schrieb:
> I am afraid this will spread beyond modems. For now I'd like
> those devices which are affected by resets to get a quirk that
> marks them as not resettable for purposes of error handling. But
> I fear we may have to face this system in the future on a regular
> basis.
I had similar thoughts when I first encountered a device with
drivers "on board". But so far (around three years now) only
wireless communication devices have shown up.
My guess is that these things are basically working with cell phone
chipsets most of which have the "dual device" built in; many
cellphones can USB-connect as "modem" or "storage".
So it's just a case of using what's there already and would probably
lie around unnoticed otherwise.
Josua Dietze
--
Man is the only creature on earth enabled to take a
warm meal while flying! Loriot
Matthew Dharm schrieb:
> On Sun, Nov 01, 2009 at 07:29:20PM +0100, Josua Dietze wrote:
>
>> Frank Schaefer schrieb:
>>
>>
>>> I really think the mode-switching should be done in the kernel and not
>>> in user-space for reasons of usability.
>>>
>> What is wrong with an udev rule entry? By the way, did the "eject"
>> command line tool work as well?
>>
>
> And I think it should be done in userspace for issues of maintainability
> and useability. It is much easier for users to upgrade their udev then
> their kernel.
>
Maintainability for whom ? The kernel-devs or the distro-people and the
users ? ;)
Please think about the users. They don't know that they have to create
udev-rules or have to install additional packages like usb_modeswitch
(which is nevertheless a great tool !).
And even if they know, they don't want to do that. So it's up to the
distros to do this automatically, which will in reality never come true
for all devices and distros.
Do you know the microdia-webcam-driver which recently got into the
kernel as sn9c20x-gspcav-sub-driver ?
It's a great and functional driver which supports lots of webcams, but
in fact its useless for most users (at least the ones who don't know
LD_PRELOAD-hack)...
Please don't understand me wrong: I agree that we should keep the kernel
slim and do as much as possible in userspace and I can see the benefits
of the userspace-approach.
But we have to make compromises and I think a kernel-space-apporach
would be the best compromise in this case. Just my two cents.
>>> Another benfit is that it binds the mode-switching to the driver. If the
>>> driver is blacklisted/not used, there will be no mode-switching.
>>>
>> But how would you access the storage part of the device then?
>>
>
> And doing the switch in userspace would solve this problem also.
>
> Finally, if we do this in userspace, device vendors might actually get a
> clue and start providing a small linux app or script to do the mode switch
> on their virtual storage device, just like they do for windows.
>
> Matt
>
As I said in reply to Josua, this depends on device-type. For
windows-driver-storage-devices we don't need such a tool.
Frank
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.
> 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?
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 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
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
Okay, this isn't funny anymore! Let me down! I'll tell Bill on you!!
-- Microsoft Salesman
User Friendly, 4/1/1998
On Wed, 4 Nov 2009, Oliver Neukum wrote:
> > If power is turned off, there's nothing we can do about it. Once that
> > happens, it doesn't make much difference whether the mode switch occurs
> > in usb-storage or from a userspace program. The old device instance
> > will go away and a new one will appear.
>
> That is what happens and what must happen if we switch mode in user space.
> In kernel space, the kernel could repeat the mode switch.
How? Doesn't the mode switch cause a change in the configuration,
interface, or endpoint descriptors? The end result would be the same
-- the old device instance would go away and a new one would appear.
Alan Stern
Dan Williams schrieb:
> ...
> Maybe there's a better way as I said a bit lower in the thread; could we
> put the logic for ejection into the driver (and not usb_modeswitch or
> whatever) but put the decision into userspace in udev?
>
> Right now the kernel drivers know what hardware they support, and that's
> a great place to also put how to eject the fake driver CD. So the
> mechanism could live in the kernel still (instead of in usb_modeswitch
> in userspace) while the actual decision still gets made in userspace
> with udev rules. The rules would say something like "if this USB
> storage device has an 'fakecd' attribute, then touch the 'ejectmeharder'
> attribute" instead of complex rules to run usb_modeswitch that duplicate
> all the device IDs in userspace. If you need to rummage around on the
> driver CD for whatever reason, you disable the udev rule. Maybe?
> ...
That would make system-configuration much easier and would also reduce
the work for the distros.
Mode-switch-tools would be much easier to maintain, too.
How do you want to implement this policy-hint ?
Frank
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
On Mon, Nov 02, 2009 at 12:18:35PM -0800, Dan Williams wrote:
> Devices with fake driver CDs and how they are handled currently:
>
> Zydas WLAN - kernel
> Huawei 3G - kernel (unusual_devs entry)
> Sierra 3G - kernel (drivers/usb/serial/sierra.c)
> Option 3G - udev rules, 'rezero', or usb_modeswitch
> ZTE 3G - udev rules, simple 'eject'
It's worth noting that for some of these which are handled in-kernel, it
had to be done that way because their storage-emulation was so poor that
the normal 'eject' WOULD NOT work properly.
Any device which can be handled in userspace SHOULD be handled there.
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
But where are the THEMES?! How do you expect me to use an OS without
themes?!
-- Stef
User Friendly, 10/9/1998
Am Montag, 2. November 2009 22:42:04 schrieb Dan Williams:
> The kernel drivers know which devices are supported and how to drive
> them. ?But because the eject code isn't in kernelspace, all that device
> selection logic has to be duplicated in userspace with usb_modeswitch.
> Pretty dumb.
No, the kernel doesn't have to know which devices need a mode switch.
Nor does user space need to know which driver a device needs to switch its
mode.
Regards
Oliver
Dan Williams schrieb:
> On Mon, 2009-11-02 at 21:10 +0100, Frank Schaefer wrote:
>
>> Matthew Dharm schrieb:
>>
>>> On Sun, Nov 01, 2009 at 09:11:49PM +0100, Frank Schaefer wrote:
>>>
>>>> Josua Dietze schrieb:
>>>>
>>>>> Frank Schaefer schrieb:
>>>>>
>>>>>
>>>>>> I really think the mode-switching should be done in the kernel and not
>>>>>> in user-space for reasons of usability.
>>>>>>
>>>>> What is wrong with an udev rule entry? By the way, did the "eject"
>>>>> command line tool work as well?
>>>>>
>>>> It returns an error but the device is ejected.
>>>> But do you really want the users to open a terminal window and call
>>>> "eject" each time they plug their device in ;) ?
>>>>
>>> If 'eject' worked, then why not use a simple udev entry? That way nobody
>>> has to call anything by hand...
>>>
>>> Matt
>>>
>> And who will create this udev-entry ;) ? How can you make sure that this
>> is done on all systems ?
>>
>
> You can't. The distros have to make sure it works.
Right, and here the trouble begins.
The driver and the mode-switch needed to use it must come from the same
source.
Otherwise we will always have inconsistencies.
> Personally, I think
> these should all be in the kernel, but the kernel doesn't contain
> policy. And unfortunately, for some devices (3G modems specifically)
> ejecting the driver CD thing *is* policy.
Hmm, policy...
Talking about the large group of devices with a driver-disk-mode only:
Isn't an installed driver for the device the policy itself, because it
makes the driver-disk obsolete !?
> Option for example protested
> mightily when I sent a patch to auto-eject their driver CD, because they
> apparently do use the driver CD thing to send Linux drivers and software
> to a few clients. But by and large, the driver CD is completely
> useless.
>
> Devices with fake driver CDs and how they are handled currently:
>
> Zydas WLAN - kernel
> Huawei 3G - kernel (unusual_devs entry)
> Sierra 3G - kernel (drivers/usb/serial/sierra.c)
> Option 3G - udev rules, 'rezero', or usb_modeswitch
> ZTE 3G - udev rules, simple 'eject'
>
> Dan
>
I can't see any real problems having device-(group-)specific policies
and switching-solutions.
Of course, it would be nice to have a common solution for all, but the
devices are too different.
Therefore the compromises we have to make should be individual (to a
certain degree).
Frank
On Sun, Nov 01, 2009 at 09:11:49PM +0100, Frank Schaefer wrote:
> Josua Dietze schrieb:
> > Frank Schaefer schrieb:
> >
> >> I really think the mode-switching should be done in the kernel and not
> >> in user-space for reasons of usability.
> >
> > What is wrong with an udev rule entry? By the way, did the "eject"
> > command line tool work as well?
> It returns an error but the device is ejected.
> But do you really want the users to open a terminal window and call
> "eject" each time they plug their device in ;) ?
If 'eject' worked, then why not use a simple udev entry? That way nobody
has to call anything by hand...
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
Why am I talking to a toilet brush?
-- CEO
User Friendly, 4/30/1998
On Sun, Nov 01, 2009 at 09:24:28PM +0100, Frank Schaefer wrote:
> Matthew Dharm schrieb:
> > On Sun, Nov 01, 2009 at 07:29:20PM +0100, Josua Dietze wrote:
> >
> >> Frank Schaefer schrieb:
> >>
> >>
> >>> I really think the mode-switching should be done in the kernel and not
> >>> in user-space for reasons of usability.
> >>>
> >> What is wrong with an udev rule entry? By the way, did the "eject"
> >> command line tool work as well?
> >>
> >
> > And I think it should be done in userspace for issues of maintainability
> > and useability. It is much easier for users to upgrade their udev then
> > their kernel.
> >
> Maintainability for whom ? The kernel-devs or the distro-people and the
> users ? ;)
Both.
> Please think about the users. They don't know that they have to create
> udev-rules or have to install additional packages like usb_modeswitch
> (which is nevertheless a great tool !).
> And even if they know, they don't want to do that. So it's up to the
> distros to do this automatically, which will in reality never come true
> for all devices and distros.
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?
Updates in userspace are universally easier; on users, on kernel deves, and
on distro devs.
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
Hey Chief. We've figured out how to save the technical department. We
need to be committed.
-- The Techs
User Friendly, 1/22/1998
On Monday 02 November 2009 22:45:59 Dan Williams wrote:
> On Mon, 2009-11-02 at 21:05 +0000, Alan Cox wrote:
> > > apparently do use the driver CD thing to send Linux drivers and software
> > > to a few clients. But by and large, the driver CD is completely
> > > useless.
> >
> > And then every so often you need to rummage around the driver CD image to
> > extract the APN or other data you need to make your modem work. At which
> > point you end up having to recompile the kernel to get it. Very annoying
> > given it could be trivially done properly in user space.
>
> Maybe there's a better way as I said a bit lower in the thread; could we
> put the logic for ejection into the driver (and not usb_modeswitch or
> whatever) but put the decision into userspace in udev?
>
> Right now the kernel drivers know what hardware they support, and that's
> a great place to also put how to eject the fake driver CD. So the
> mechanism could live in the kernel still (instead of in usb_modeswitch
> in userspace) while the actual decision still gets made in userspace
> with udev rules. The rules would say something like "if this USB
> storage device has an 'fakecd' attribute, then touch the 'ejectmeharder'
> attribute" instead of complex rules to run usb_modeswitch that duplicate
> all the device IDs in userspace. If you need to rummage around on the
> driver CD for whatever reason, you disable the udev rule. Maybe?
>
> I simply hate the duplication of all the device IDs with one set in the
> kernel and one set in userspace because it's pretty pointless and makes
> twice the work when new hardware comes out.
>
well, there's more to Alan's theory here.
AVM provides a beta firmware [1] which allows the user to but the stick into
the mass storage mode again and stream the data over WLAN connection.
(of course, you'll need a special AP which supports this)
[1]: (german only, they haven't bothered to do a translation)
http://www.avm.de/de/Service/Service-Portale/Service-Portal/Labor/7270_streaming_stick/labor_start_streaming_stick.php
Of course, I haven't tested, or even seen such setup yet.
But it appears to be working (based on google).
Therefore, it might be a good idea to start a new user app,
which does this 3-way usb-mode switching for these devices.
Regards,
Chr
On Mon, 2009-11-02 at 13:11 -0800, Matthew Dharm wrote:
> On Mon, Nov 02, 2009 at 12:18:35PM -0800, Dan Williams wrote:
> > Devices with fake driver CDs and how they are handled currently:
> >
> > Zydas WLAN - kernel
> > Huawei 3G - kernel (unusual_devs entry)
> > Sierra 3G - kernel (drivers/usb/serial/sierra.c)
> > Option 3G - udev rules, 'rezero', or usb_modeswitch
> > ZTE 3G - udev rules, simple 'eject'
>
> It's worth noting that for some of these which are handled in-kernel, it
> had to be done that way because their storage-emulation was so poor that
> the normal 'eject' WOULD NOT work properly.
Half of them don't use eject at all, because of course on Windows the
vendor driver owns the device and can do whatever it wants. Huawei uses
a custom sequence, Option uses a custom sequence, and so does Sierra.
ZTE is the only one that I've seen that you can actually just "eject"
and make it work.
In userspace, usb_modeswitch is the place to put all this logic. Then
you tie it together with udev rules using some bubble-gum and duct-tape,
and maybe it works. Of course, there's massive duplication of data
between usb_modeswitch and the kernel drivers, because the there's
simply no communication between the two.
The kernel drivers know which devices are supported and how to drive
them. But because the eject code isn't in kernelspace, all that device
selection logic has to be duplicated in userspace with usb_modeswitch.
Pretty dumb.
Maybe we can get the kernel drivers to expose the information we need
(maybe even an 'eject' attribute in sysfs or something) and then we just
have to write udev rules instead of having a whole bunch of libusb junk
in userspace? Would that preserve the policy-always-in-userspace
requirement yet keep the code to drive the hardware in kernel space
where it really belongs?
Dan
Alan Stern schrieb:
> On Mon, 2 Nov 2009, Dan Williams wrote
>> In userspace, usb_modeswitch is the place to put all this logic. Then
>> you tie it together with udev rules using some bubble-gum and duct-tape,
>> and maybe it works. Of course, there's massive duplication of data
>> between usb_modeswitch and the kernel drivers, because the there's
>> simply no communication between the two.
>>
> The only reason for this "massive" duplication is that nobody has
> bothered to remove from the kernel the parts that usb_modeswitch can
> handle. Adding yet more switching code into the kernel, thereby
> _increasing_ the amount of duplication, seems like a bad idea.
>
Or the other way around ;) .
Of course, we all don't want any duplicate code. We need a kernelspace
OR a userspace-solution.
But we should make pragmatic and device-(group-)specific decisions.
The hardware itself and the context in which it is used (=>
switch-policy) are too different.
...
> ... Jobs that can be handled
> in userspace _should_ be handled there.
>
> Alan Stern
>
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.
Frank
On Mon, 2009-11-02 at 22:39 +0000, Alan Cox wrote:
> > Maybe we can get the kernel drivers to expose the information we need
> > (maybe even an 'eject' attribute in sysfs or something) and then we just
> > have to write udev rules instead of having a whole bunch of libusb junk
> > in userspace? Would that preserve the policy-always-in-userspace
> > requirement yet keep the code to drive the hardware in kernel space
> > where it really belongs?
>
> Or put the magic strings in the kernel with a translation hook for the
> eject request ? That would keep policy and method in the right places.
> You ask the kernel to eject, it hides the magic weirdness.
Yes, that would be awesome.
Dan
On Sun, 2009-11-01 at 19:00 +0100, Frank Schaefer wrote:
> The attached patch adds the mode-switching-procedure to the WLAN-driver
> (ar9170usb) and disables the storage device in the usb-storage-driver.
This patch looks weird. Have you looked at zd1211rw, which also does
this? I think it just adds something to usb-storage for the device IDs?
johannes
On Sunday 01 November 2009 21:24:28 Frank Schaefer wrote:
> Matthew Dharm schrieb:
> > On Sun, Nov 01, 2009 at 07:29:20PM +0100, Josua Dietze wrote:
> >
> >> Frank Schaefer schrieb:
> >>
> >>
> >>> I really think the mode-switching should be done in the kernel and not
> >>> in user-space for reasons of usability.
> >>>
> >> What is wrong with an udev rule entry? By the way, did the "eject"
> >> command line tool work as well?
> >>
> >
> > And I think it should be done in userspace for issues of maintainability
> > and useability. It is much easier for users to upgrade their udev then
> > their kernel.
> >
> Maintainability for whom ? The kernel-devs or the distro-people and the
> users ? ;)
>
> Please think about the users. They don't know that they have to create
> udev-rules or have to install additional packages like usb_modeswitch
> (which is nevertheless a great tool !).
> And even if they know, they don't want to do that. So it's up to the
> distros to do this automatically, which will in reality never come true
> for all devices and distros.
yes, please think about the users!
All not-so-trival-changes have to go through wireless-testing / wireless-next,
net-next, linux-next until it hits finally the mainline... And then only users
which are able to update their kernels will benefit, *everyone else* has
to wait until their distros to pick up the new kernel... this could be easily more
than a year before the device will work right out of the box for *everyone else*.
Therefore udev should be the way to go... and as a bonus: a userspace/udev solution
does work with older kernels right away!
Regards,
Chr
> Maybe we can get the kernel drivers to expose the information we need
> (maybe even an 'eject' attribute in sysfs or something) and then we just
> have to write udev rules instead of having a whole bunch of libusb junk
> in userspace? Would that preserve the policy-always-in-userspace
> requirement yet keep the code to drive the hardware in kernel space
> where it really belongs?
Or put the magic strings in the kernel with a translation hook for the
eject request ? That would keep policy and method in the right places.
You ask the kernel to eject, it hides the magic weirdness.
Am Dienstag, 3. November 2009 16:16:12 schrieb Alan Stern:
> This sounds as if you are trying very hard to get the _worst_ of both
> worlds! ?You would force users to upgrade their kernels before they can
> use new devices (because the kernel is where the mode-switch code will
> be), and you also would force them to upgrade their userspace settings
> (so that the new mode-switch code will be called).
Yes.
> I'm with Matt Dharm and Josua Dietze on this. ?Jobs that can be handled
> in userspace _should_ be handled there.
There is the inconvenient problem of hibernation. And, if more systems
start cutting power to USB in STR, the problem of STR. I am inclined
to declare that hibernation is a problem of those pesky misdesigns.
But dare we say that also about STR?
Regards
Oliver
On Sun, Nov 01, 2009 at 07:29:20PM +0100, Josua Dietze wrote:
> Frank Schaefer schrieb:
>
> >I really think the mode-switching should be done in the kernel and not
> >in user-space for reasons of usability.
>
> What is wrong with an udev rule entry? By the way, did the "eject"
> command line tool work as well?
And I think it should be done in userspace for issues of maintainability
and useability. It is much easier for users to upgrade their udev then
their kernel.
> >Another benfit is that it binds the mode-switching to the driver. If the
> >driver is blacklisted/not used, there will be no mode-switching.
>
>
> But how would you access the storage part of the device then?
And doing the switch in userspace would solve this problem also.
Finally, if we do this in userspace, device vendors might actually get a
clue and start providing a small linux app or script to do the mode switch
on their virtual storage device, just like they do for windows.
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
C: They kicked your ass, didn't they?
S: They were cheating!
-- The Chief and Stef
User Friendly, 11/19/1997
On Wed, 4 Nov 2009, Johannes Berg wrote:
> On Wed, 2009-11-04 at 11:16 -0500, Alan Stern wrote:
>
> > Here's my first attempt at considering all the pros and cons. Has
> > anything important been left out?
>
> [snip]
>
> I think you forgot to consider the case where both the driver and the
> mode switch code need an update to handle a new device. This is relevant
> in the case where a new device shows up that needs mode-switching, but
> even after switching has an ID that the current driver doesn't know
> about.
This could be handled by programs like usb_modeswitch. The USB serial
drivers allow IDs to be added dynamically.
Of course, if something more than that is required then the situation
would be different. However I think this is pretty rare.
Alan Stern
Matthew Dharm schrieb:
> On Sun, Nov 01, 2009 at 09:11:49PM +0100, Frank Schaefer wrote:
>
>> Josua Dietze schrieb:
>>
>>> Frank Schaefer schrieb:
>>>
>>>> I really think the mode-switching should be done in the kernel and not
>>>> in user-space for reasons of usability.
>>>>
>>> What is wrong with an udev rule entry? By the way, did the "eject"
>>> command line tool work as well?
>>>
>> It returns an error but the device is ejected.
>> But do you really want the users to open a terminal window and call
>> "eject" each time they plug their device in ;) ?
>>
>
> If 'eject' worked, then why not use a simple udev entry? That way nobody
> has to call anything by hand...
>
> Matt
>
And who will create this udev-entry ;) ? How can you make sure that this
is done on all systems ?
Frank
Frank Schaefer schrieb:
> I really think the mode-switching should be done in the kernel and not
> in user-space for reasons of usability.
What is wrong with an udev rule entry? By the way, did the "eject"
command line tool work as well?
> It also doesn't "pollute" the driver with much code (adds a single
> usb_bulk_msg()).
That may be true for a single device but there are around 30+ others
which are switched outside the kernel, some inside usb-storage, and
this would add even more places where mode switching happened.
> Another benfit is that it binds the mode-switching to the driver. If the
> driver is blacklisted/not used, there will be no mode-switching.
But how would you access the storage part of the device then?
Josua
--
Man is the only creature on earth enabled to take a
warm meal while flying! Loriot
On Mon, 2 Nov 2009, Dan Williams wrote:
> In userspace, usb_modeswitch is the place to put all this logic. Then
> you tie it together with udev rules using some bubble-gum and duct-tape,
> and maybe it works. Of course, there's massive duplication of data
> between usb_modeswitch and the kernel drivers, because the there's
> simply no communication between the two.
The only reason for this "massive" duplication is that nobody has
bothered to remove from the kernel the parts that usb_modeswitch can
handle. Adding yet more switching code into the kernel, thereby
_increasing_ the amount of duplication, seems like a bad idea.
> The kernel drivers know which devices are supported and how to drive
> them.
No. The kernel drivers (usb-storage is where most if not all of the
kernel-side mode-switching code has ended up) only know about the
particular devices _they_ support. They don't know about the other
devices supported by usb_modeswitch.
> But because the eject code isn't in kernelspace, all that device
> selection logic has to be duplicated in userspace with usb_modeswitch.
> Pretty dumb.
What are you talking about? Of course usb-storage contains
mode-switching code for the devices it switches. And for the devices
it doesn't switch, it does not contain device-selection logic.
> Maybe we can get the kernel drivers to expose the information we need
> (maybe even an 'eject' attribute in sysfs or something) and then we just
> have to write udev rules instead of having a whole bunch of libusb junk
> in userspace? Would that preserve the policy-always-in-userspace
> requirement yet keep the code to drive the hardware in kernel space
> where it really belongs?
This sounds as if you are trying very hard to get the _worst_ of both
worlds! You would force users to upgrade their kernels before they can
use new devices (because the kernel is where the mode-switch code will
be), and you also would force them to upgrade their userspace settings
(so that the new mode-switch code will be called).
I'm with Matt Dharm and Josua Dietze on this. Jobs that can be handled
in userspace _should_ be handled there.
Alan Stern
Matthew Dharm schrieb:
> On Sun, Nov 01, 2009 at 09:24:28PM +0100, Frank Schaefer wrote:
>
>> Matthew Dharm schrieb:
>>
>>> On Sun, Nov 01, 2009 at 07:29:20PM +0100, Josua Dietze wrote:
>>>
>>>> Frank Schaefer schrieb:
>>>>> I really think the mode-switching should be done in the kernel and not
>>>>> in user-space for reasons of usability.
>>>>>
>>>> What is wrong with an udev rule entry? By the way, did the "eject"
>>>> command line tool work as well?
>>>>
>>> And I think it should be done in userspace for issues of maintainability
>>> and useability. It is much easier for users to upgrade their udev then
>>> their kernel.
>>>
>> Maintainability for whom ? The kernel-devs or the distro-people and the
>> users ? ;)
>>
>
> Both.
>
>> Please think about the users. They don't know that they have to create
>> udev-rules or have to install additional packages like usb_modeswitch
>> (which is nevertheless a great tool !).
>> And even if they know, they don't want to do that. So it's up to the
>> distros to do this automatically, which will in reality never come true
>> for all devices and distros.
>
> 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.
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.
And in this case, it would be really easy.
> Updates in userspace are universally easier; on users, on kernel deves, and
> on distro devs.
>
> Matt
>
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.
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 !
Frank
Alan Stern schrieb:
> On Wed, 4 Nov 2009, Johannes Berg wrote:
>
>> I think you forgot to consider the case where both the driver and the
>> mode switch code need an update to handle a new device. This is relevant
>> in the case where a new device shows up that needs mode-switching, but
>> even after switching has an ID that the current driver doesn't know
>> about.
>
> This could be handled by programs like usb_modeswitch. The USB serial
> drivers allow IDs to be added dynamically.
>
> Of course, if something more than that is required then the situation
> would be different. However I think this is pretty rare.
So far, mostly cdc_acm and high speed serial devices are known.
There is the special case of the HSO interface for "Option" modems
which resembles a network device IIRC. But switching them is pretty
straightforward and driver support by the manufacturer seems to be OK.
I don't know of any "switching" devices which are completely
unsupported by the recent kernels.
usb_modeswitch now has a wrapper which loads the "option" module by
default if the "new" device will not be claimed by "cdc_acm", "hso"
or "option". Using the "new_id" feature *any* ID can be used with it
right away.
Josua Dietze
--
Man is the only creature on earth enabled to take a
warm meal while flying! Loriot
On Tue, 3 Nov 2009, Oliver Neukum wrote:
> > I'm with Matt Dharm and Josua Dietze on this. ?Jobs that can be handled
> > in userspace _should_ be handled there.
>
> There is the inconvenient problem of hibernation. And, if more systems
> start cutting power to USB in STR, the problem of STR. I am inclined
> to declare that hibernation is a problem of those pesky misdesigns.
> But dare we say that also about STR?
If power is turned off, there's nothing we can do about it. Once that
happens, it doesn't make much difference whether the mode switch occurs
in usb-storage or from a userspace program. The old device instance
will go away and a new one will appear.
Alan Stern
On Mon, 2009-11-02 at 21:05 +0000, Alan Cox wrote:
> > apparently do use the driver CD thing to send Linux drivers and software
> > to a few clients. But by and large, the driver CD is completely
> > useless.
>
> And then every so often you need to rummage around the driver CD image to
> extract the APN or other data you need to make your modem work. At which
> point you end up having to recompile the kernel to get it. Very annoying
> given it could be trivially done properly in user space.
Maybe there's a better way as I said a bit lower in the thread; could we
put the logic for ejection into the driver (and not usb_modeswitch or
whatever) but put the decision into userspace in udev?
Right now the kernel drivers know what hardware they support, and that's
a great place to also put how to eject the fake driver CD. So the
mechanism could live in the kernel still (instead of in usb_modeswitch
in userspace) while the actual decision still gets made in userspace
with udev rules. The rules would say something like "if this USB
storage device has an 'fakecd' attribute, then touch the 'ejectmeharder'
attribute" instead of complex rules to run usb_modeswitch that duplicate
all the device IDs in userspace. If you need to rummage around on the
driver CD for whatever reason, you disable the udev rule. Maybe?
I simply hate the duplication of all the device IDs with one set in the
kernel and one set in userspace because it's pretty pointless and makes
twice the work when new hardware comes out.
Dan
Am Montag, 2. November 2009 22:11:23 schrieb Matthew Dharm:
> It's worth noting that for some of these which are handled in-kernel, it
> had to be done that way because their storage-emulation was so poor that
> the normal 'eject' WOULD NOT work properly.
>
> Any device which can be handled in userspace SHOULD be handled there.
Do these devices survive a reset and stay in the correct mode?
Has that been tested?
Regards
Oliver
On Tuesday 03 November 2009 11:57:22 Oliver Neukum wrote:
> Am Montag, 2. November 2009 22:11:23 schrieb Matthew Dharm:
> > It's worth noting that for some of these which are handled in-kernel, it
> > had to be done that way because their storage-emulation was so poor that
> > the normal 'eject' WOULD NOT work properly.
> >
> > Any device which can be handled in userspace SHOULD be handled there.
>
> Do these devices survive a reset and stay in the correct mode?
> Has that been tested?
ar9170usb does an usb reset right before it uploads the WLAN firmware.
The device stays in the correct mode, else it wouldn't be possible
to continue because usb-storage mode has a different PID.
Regards,
Chr
Am Dienstag, 3. November 2009 23:47:55 schrieb Alan Stern:
> On Tue, 3 Nov 2009, Oliver Neukum wrote:
> > > I'm with Matt Dharm and Josua Dietze on this. ?Jobs that can be handled
> > > in userspace _should_ be handled there.
> >
> > There is the inconvenient problem of hibernation. And, if more systems
> > start cutting power to USB in STR, the problem of STR. I am inclined
> > to declare that hibernation is a problem of those pesky misdesigns.
> > But dare we say that also about STR?
>
> If power is turned off, there's nothing we can do about it. Once that
> happens, it doesn't make much difference whether the mode switch occurs
> in usb-storage or from a userspace program. The old device instance
> will go away and a new one will appear.
That is what happens and what must happen if we switch mode in user space.
In kernel space, the kernel could repeat the mode switch.
Regards
Oliver
On Mon, 2009-11-02 at 21:10 +0100, Frank Schaefer wrote:
> Matthew Dharm schrieb:
> > On Sun, Nov 01, 2009 at 09:11:49PM +0100, Frank Schaefer wrote:
> >
> >> Josua Dietze schrieb:
> >>
> >>> Frank Schaefer schrieb:
> >>>
> >>>> I really think the mode-switching should be done in the kernel and not
> >>>> in user-space for reasons of usability.
> >>>>
> >>> What is wrong with an udev rule entry? By the way, did the "eject"
> >>> command line tool work as well?
> >>>
> >> It returns an error but the device is ejected.
> >> But do you really want the users to open a terminal window and call
> >> "eject" each time they plug their device in ;) ?
> >>
> >
> > If 'eject' worked, then why not use a simple udev entry? That way nobody
> > has to call anything by hand...
> >
> > Matt
> >
> And who will create this udev-entry ;) ? How can you make sure that this
> is done on all systems ?
You can't. The distros have to make sure it works. Personally, I think
these should all be in the kernel, but the kernel doesn't contain
policy. And unfortunately, for some devices (3G modems specifically)
ejecting the driver CD thing *is* policy. Option for example protested
mightily when I sent a patch to auto-eject their driver CD, because they
apparently do use the driver CD thing to send Linux drivers and software
to a few clients. But by and large, the driver CD is completely
useless.
Devices with fake driver CDs and how they are handled currently:
Zydas WLAN - kernel
Huawei 3G - kernel (unusual_devs entry)
Sierra 3G - kernel (drivers/usb/serial/sierra.c)
Option 3G - udev rules, 'rezero', or usb_modeswitch
ZTE 3G - udev rules, simple 'eject'
Dan
Am Mittwoch, 4. November 2009 17:16:18 schrieb Alan Stern:
> 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
Oh yes.
> 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.
I am afraid this will spread beyond modems.
For now I'd like those devices which are affected by resets to get
a quirk that marks them as not resettable for purposes of error handling.
But I fear we may have to face this system in the future on a regular
basis.
Regards
Oliver
Am Mittwoch, 4. November 2009 04:57:59 schrieb Alan Stern:
> On Wed, 4 Nov 2009, Oliver Neukum wrote:
> > > If power is turned off, there's nothing we can do about it. Once that
> > > happens, it doesn't make much difference whether the mode switch occurs
> > > in usb-storage or from a userspace program. The old device instance
> > > will go away and a new one will appear.
> >
> > That is what happens and what must happen if we switch mode in user
> > space. In kernel space, the kernel could repeat the mode switch.
>
> How? Doesn't the mode switch cause a change in the configuration,
> interface, or endpoint descriptors? The end result would be the same
> -- the old device instance would go away and a new one would appear.
But it switches to a known state which we could use to trigger a switch
and recompare after the switch.
Regards
Oliver
> apparently do use the driver CD thing to send Linux drivers and software
> to a few clients. But by and large, the driver CD is completely
> useless.
And then every so often you need to rummage around the driver CD image to
extract the APN or other data you need to make your modem work. At which
point you end up having to recompile the kernel to get it. Very annoying
given it could be trivially done properly in user space.
HAL probably needs the database of these devices *not* the kernel.
On Mon, 2009-11-02 at 21:05 +0000, Alan Cox wrote:
> > apparently do use the driver CD thing to send Linux drivers and software
> > to a few clients. But by and large, the driver CD is completely
> > useless.
>
> And then every so often you need to rummage around the driver CD image to
> extract the APN or other data you need to make your modem work. At which
> point you end up having to recompile the kernel to get it. Very annoying
> given it could be trivially done properly in user space.
>
> HAL probably needs the database of these devices *not* the kernel.
It's udev these days; HAL is going away since it and udev pretty much
can do the same thing anyway. The tool you're looking for is called
usb_modeswitch, but it needs a bit of work to Just Work in a stock
distro install with the user having to edit a config file.
Dan