<div dir="ltr">Hi Albert,<div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am far from convinced that all of this is sensitive to whether one<br>
keyboard was plugged or unplugged from the system. Why would icons<br>
in the tray be affected by the number of keyboards connected to the<br>
computer, for instance?</blockquote><div><br></div><div>because it's an unwritten expectation in HIGs (Human Interface Guidelines), that tray icons show and react to events happening close to user (physically, theoretically). Hence (un)plugging devices inclusive. Unwanted interruptions are then interpreted as unexpected (un)plugging.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am having a hard time trying to make sense of what you're saying,<br>
which is frustrating, as I've been doing embedded development for more<br>
that 20 years. For instance:<br>
<br>
- I am surprised that all of a sudden, all SW in a computer has to<br>
handle interruptions. In my time (which extends to just about a few<br>
days ago), only drivers did. "Driver" is basically the name we give<br>
to thoses pieces of SW which handle interrupts (and talk to HW and do<br>
DMA requests and...)<br>
<br>
- Nor did any of the systems I worked, and still work on, require that<br>
the full system state be saved and restored on interrupts; in fact,<br>
if they did completely save and restore their state, they interrupts<br>
would have no effect whatsoever, which would be a pity. Granted,<br>
interrupt handlers must save whatever CPU resources they use, and<br>
schedulers must do the same with task states; but that's hardly a<br>
concern outside of these two cases.<br>
<br>
- Finally, the daemons in my time /did/ expect their state to change all<br>
the time. They actually were /intended/ to change state, in carefully<br>
designed ways; a daemon executing in an immutable environment would<br>
have little utility.<br></blockquote><div><br></div><div>It's irrelevant who we are and what we do. The fact is, that in case of unwanted interruptions, the state shall be 100% preserved. Which is currently not implemented in any layer of the common Linux and BSD systems except sometimes for the driver.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I don't know what is the setup on which you encounter these issues; on<br>
mine, I can connect and disconnect keyboards at will, with nothing even<br>
so much as flipping a bit when I do, and my keyboards don't even lose<br>
their French layout :) -- same goes for USB devices which need to get<br>
their firmware uploaded through USB; granted, every time I unplug and<br>
replug them, thy take time to get their firmware /again/, and yes,<br>
trying to use a video capture device won't work if you unplug it right<br>
in the middle of it, but you can hardly expect otherwise, and it's only<br>
logical that plugging it back won't fix the overall problem.<span class="gmail-"><br></span></blockquote><div><br></div><div>The whole thread is about unwanted interruptions, not user-initiated. Refer to the the groups of issues and several specific program names affected by unwanted interruptions as mentioned in my previous email to get an idea what for a mainstream setup it might be.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> An extreme case are security modules (e.g. YubiKey)<br>
> or security SW demanding uninterrupted connection of a certain device<br>
> (due to possible MiM attacks etc.).<br>
<br>
</span>As you say, this is an extreme example. In fact, it is precisely an<br>
example of a setup where continuous connection is laid out a priori as<br>
a /requirement/; no wonder, then, that discontinuity of connection is<br>
not supported.<br></blockquote><div><br></div><div>And therefore we need to make absolutely sure, that all detachable "hubs" will prevent unwanted interruptions.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> Just my 2 cents from real world.<br>
<br>
</span>You should be careful with the way you express yourself: one could be<br>
led to believe that here you are implying I would not know of the real<br>
world whereas you do, and that this implied difference would make my<br>
opinion less worthy than yours. But of course you are not implying<br>
that, since you do no know me at all, right ?<br>
<br>
So let's avoid anyone getting false ideas, and to that effect, let's<br>
stay away from hypothetically real vs hypothetically unreal worlds, and<br>
let's just keep to technical discussion with technical and precise<br>
arguments. Shall we?<br></blockquote><div><br></div><div>Maybe English is really still not the language of the world as the meaning of "real world" is being undeniably confused with "real world without everything Albert ARIBAUD came across".</div><div><br></div><div>Kind regards,</div><div><br></div><div>-- Jan</div></div></div></div>