Quotes of the week

I came to realize that if one wants his work (software) to be used globally, making it in-tree is not the goal but an important first step. Making software in-tree is technical, but affecting distributors decision should involve non-technical issues, I guess.

So, if your display switch button now just makes the letter "P" appear, say thanks to Microsoft. There's a range of ways we can fix this, although none of them are straightforward and those of you who currently use left-Windows-p as a keyboard shortcut are going to be sad. I would say that I feel your pain, but my current plan is to spend the immediate future getting drunk enough that I stop caring.

One of the things that we sometimes have to tell people who are trying to navigate the maze of upstream submission is that sometimes you need to know who to ignore, and that sometimes rules are guidelines (despite pedants who will NACK based on rules like, "/proc, eeeeewwww", or "/debugfs must only strictly be for debug information").

Telling embedded developers who only want to submit their driver that they must create a whole new pseudo-filesystem just to export a single file that in older, simpler times, would have just been thrown into /proc is really not fair, and is precisely the sort of thing that may cause them to say, "f*ck it, these is one too many flaming hoops to jump through". If we throw up too many barriers, in the long run it's not actually doing Linux a service.

Good heavens, what is EILSEQ? ... Why on earth are driver writers using this in the kernel??? Imagine the confusion which ensues when this error code propagates all the way back to some poor user's console. They'll be scrabbling around with language encodings not even suspecting that their hardware is busted.

People do this *a lot*. They go grubbing through errno.h and grab something which looks vaguely appropriate. But it's wrong. If your hardware is busted then return -EIO and emit a printk to tell the operator what broke.