Hi Enrico, On 6/28/21 7:47 PM, Enrico Weigelt, metux IT consult wrote: > On 28.06.21 17:12, Hans de Goede wrote: > > Hi, > >> I'm not in favor of internal reviews, esp. not when new userspace >> API is involved. I would greatly prefer for the discussions surrounding >> this to be kept public. > > ACK. Please do that in open public. There're still lots of things to > discuss that should be discussed in wide public, instead of comittee > behind closed doors. > >> I agree that ideally we should have some generic userspace API for this, >> but I'm afraid that ATM that simply is not possible. > > Why not ? Lets collect the actual requirements and talk about some > viable solutions (I've already got a few ideas ...) Because we don't know the actual requirements yet. This is a very young technology and still evolving fast. Also whether we like it or not, we don't get to dictate what the involved firmware and hardware interfaces get to look like. So any API which we come up with must be capable of working with the existing fw and hw interfaces as shipped in actual devices. >> This whole notion of maximum tx power being controlled based on various sensors because of SAR reasons is pretty new (at least in the PC/laptop space) and I know of a couple of vendors who are slapping some adhoc firmware >> interface on the sensor readings for some modem related userspace >> process to consume. > > We should bring them here onboard, public discussion. And at the same > time we should make it crystally clear to them that weird adhoc hacks > won't be accepted and just give them very bad reputation and > shitstorming. Seriously, I believe we should go that route, in order > to prevent even more damage by insane firmware interfaces. <sigh> we are in no place to make demands here "standard" (non chrome-os / android) Linux laptop-os usage is a tiny fraction of the market. So new features like this are primarily developed on other OS-es and typically we either take the firmware interfaces as is, or we don't support the feature. You seem to believe in an utopia where we fully control all the layers and can design and implement everything to be just perfect, but the reality is quite different from this. You also seem to forget that perfect is the enemy of good. This case is an excellent example of a case where we cannot design anything close to the "perfect" API in one go because we don't have the necessary problem-domain information / experience yet. > Such stuff really doesn't belong into firmware, at least not the way its > done now. Instead there just should be a clear description of the actual > hardware. Yes you've made your opinion on this abundantly clear and I must say that the whole tone of your emails in this thread and the "I know better then everyone else" attitude in this thread seriously rubs me the wrong way. Don't be surprised if I do not answer any further emails from you in this thread. That won't be because I don't read them, but that will be because I deliberately choose to not answer them because IMHO your strong opinion on how everyone must bow to your vision of how exactly this all must be implemented adds very little of value to this thread. Regards, Hans
