Get best of the week

To the question of Linux (L)

We proceed from the fact that you get a full-fledged operating system, immediately completely paying for everything. (Bill Gates in response to a question about competition with L.)


The more I learn about Linux, the less I hate B.G.


Well, actually, I never felt such strong feelings for him, I’m just starting to better understand why the company that produces Windows takes money. And it becomes clearer why consumers prefer to pay Bill (there are, of course, options here, you understand), instead of using the free (“that is, free”) alternative. But let's start in order, and consider two episodes of interaction with L.

Recently, L has been functioning on the devices I develop (in one or another of its forms, well, you understand ...), in the framework of which special-purpose software is executed. And so, in the process of interacting with external devices (specialized keyboards), interesting artifacts of OS behavior were discovered, which led to the thoughts stated in the epigraph.

Episode one - during the correction of the USB keyboard program, a “accidentally, unintentionally” defect was introduced, which led to the failure of the device’s string descriptor. For those who are not very connected with USB, the necessary explanation - a string descriptor - is an optional part of the device description, which is intended solely for visualizing the type of device and the manufacturer of system utilities. Nevertheless, this is not an excuse for programmers and such errors should not be made, but everything happens in life. How can a host running a sane OS react if such an incorrect device is connected to it?

Personally, I see 3 possible strategies:

  1. Ignore the error and work with the device further, especially since there are no obstacles for this - this is what Windows do, at least starting from 7, and this is a wonderful solution;
  2. marking the device as malfunctioning, issuing the appropriate system message and then ignoring this device is also a completely normal and meaningful reaction;
  3. to repeat the request of the string descriptor and, until it is received, not to start working with this device itself is also an acceptable solution, although it is somewhat worse than the previous ones, since it takes up a certain part of the processor and USB bus resources (and they are not unlimited at all).

PNP: It should be noted that the standard for the interface only provides for the need (Figure 8.31 on page 222), while waiting for the input message, to control the time and process the timeout, as one of the possible errors - repeat the request 3 times, and then give a signal about the transaction failure. Further host actions are determined by the implementation. Well, at least, I did not find such information in the standard, although this is not final.

So, the developers of L did not limit themselves to the solutions that lay on the surface and went deeper, having come up with an unusually interesting and, we will not be afraid of this word, idiotic very creative way:

4. repeat the request a certain number of times, after the exhaustion of which to mark the device as faulty and then turn it off .

So far, nothing criminal, if not for one small detail (“and everything else is nuances”) - while the L host repeats the above request, it monopolizes access via the bus (most likely the timeout in the hardware does not start or the interrupt from it is not processed) and all (!!!) other USB devices are idle. This process takes about a dozen seconds, during which all devices are unavailable - already not bad. And here’s the cherry on the cake - after exhausting attempts to read the string descriptor from the wrong keyboard, packets generally stop coming to it, after 2 minutes, it understands “something went wrong” and tries to present itself to the host again by reconnecting, causing the process to repeat. The results are understandable - working with the bus is simply not possible if you are not ready to use the hiccup mode.An unusually original solution, but this (originality) is its only advantage.

My Linux acquaintances, after demonstrating this phenomenon, first tried to explain it in the style of “this is not a bug, it’s such a feature” (or rather, at first they, as they accepted, suggested rebuilding the kernel with the latest patches, this is generally a universal response to any message in the L community about a possible error), and then they said that, yes, the behavior is incorrect, but, probably, somewhere in the configuration files of the assembly there is a flag, resetting or setting which, you can disable this system behavior. If this is true, then the only name for the flag that I can offer is (in Russian): "I really want to_OS_be_being_being_something_failing_string_descriptor_as_hysterichka", in the style "Until this bitch tells me her name, I won’t ask anyone to talk to you," sorry for my french. Well, even if this is the case and such a flag is,Is by default the OS should not be collected in normal, not perverted, mode? For some reason, Windows do just that. Of course, you should look at the source text of host L (most likely, a specific USB driver) and determine if there is such a flag and how to achieve similar system behavior, but for the reasons listed below, this was not done, so we restrict ourselves to stating the fact .

The second feature (much more like an error, because in the first case the device was incorrect, which I immediately emphasized) was detected after the device program error was fixed and we started working further.

The fact is that on the designed device there were two controllers that each implemented the joystick and keyboard functions, while one processed the left side of the keyboard, and the second processed the right. But one button on the front panel was connected to both controllers, because it had the marking “FIRE” on it and the results of a failure of one controller would be very unpleasant. When you clicked on this button, both controllers produced a “space” symbol and everything was fine until we noticed that sometimes (~ 10% of cases) after releasing the A button, it continues to be considered pressed and the application goes into continuous fire mode. At the same time, pressing and lowering the button again returned the system to normal mode.

It has been suggested that closely spaced (in time) events from the keyboard may be skipped, in this case a message about releasing a button.

Further, various steps were taken to determine the cause of the malfunction, but their description goes beyond the scope and subject matter for this post and will (I hope) be described separately. But the process of finding out the causes of such a simple (at first glance) error in itself required such efforts that any desire to understand the reason for the first bug described in the post was lost.
Returning to the epigraph, I must say that on Windows 7 this defect was not observed for at least 100 clicks, which indicates the stability of this OS on this factor. Again, I did not see the source code, but the behavior of the program speaks for itself.

It is unlikely that the qualifications of Windows developers would significantly exceed that for the open source community and the question, apparently, is only as testing, which is unambiguously conducted in a larger volume (and with higher quality), when people who receive money for their work are engaged in it ( besides moral satisfaction).

I have to admit that the behavior of A, at least in the situations described, is best defined by the phrase "it works," which cannot be considered acceptable for an OS that claims to be reliable and widespread, which is why my attitude to B.G. As a result of this episode, it improved, since he is definitely not to blame for what is happening (although there may be different opinions).

More articles:


All Articles