On 19.03.21 13:59, Leon Romanovsky wrote:
I really doubt we can influence that by any technical decision here in
the kernel.
There are subsystems that succeeded to do it, for example netdev, RDMA e.t.c.
I'd guess either hi-end / server or embedded products - already
mentioned that these are different fields. I've been talking about the
average consumer products.
OTOH, there're also very expensive vendors that are exceptionally bad,
eg. National instruments (who even are capable of breaking rpm so badly
with their proprietary packages that they open up 0day holes - i once
filed a report @FD on such a case).
IMHO, the expensive ones don't care either.
Does eg. Dell publish board schematics ? Do they even publish exact part
lists (exact chipsets) along with their brochures, so customers can
check wether their HW is supported, before buying and trying out ?
They do it because they are allowed to do it and not because they
explicitly want to annoyance their customers.
Yes, they're just ignorant. They can still do that, because buy their
pretty expensive cheap-hardware. And that's mostly driven by purchase
people inside the customer organisations, who just don't care how much
damage they do to their own employers, by dictating purchase of
expensive broken-by-design hardware. ... but that's nothing we here have
any influence on - except for dissuasion and purchase boycott ...
In any case, I still fail to see why giving operators an debug knob
should make anything worse.
[ And often, even a combination of them isn't enough. Did you know that
even Google doesn't get all specs necessary to replace away the ugly
FSP blob ? (it's the same w/ AMD, but meanwhile I'm pissed enought to
reverse engineer their AGESA blob). ]
I don't know about this specific Google case, but from my previous experience.
The reasons why vendor says no to Google are usually due to licensing and legal
issues and not open source vs. proprietary.
In short words: Google did (still does?) build their own mainboards and
FW (IIRC that's where LinuxBoot came from), but even with their HUGE
quantities (they buy cpus in quantities of truck loads) they still did
not manage to get any specs for writing their own early init w/o the
proprietary FSP.
The licensing / legal issues can either be:
a) we, the mightly Intel Corp., have been so extremly stupid for
licensing some vital IP stuff (what exactly could that be, in exactly
the prime domain of Intel ?) and signing such insane crontracts, that
we're not allowed to tell anybody how to actually use our own
products (yes: initializing the CPU and built-in interfaces belongs
exactly into that category)
b) we, the mighty Intel Corp., couldn't build something on our own, but
just stolen IP (in our primary domain) and are scared that anybody
could find out from just reading some early setup code.
c) we, the mighty Intel Corp., rule the world and we give a phrack on
what some tiny Customers like Google want from us.
d) we, the mightly Intel Corp., did do what our name tells: INTEL,
and we don't want anybody raise unpleasant questions.
choose your poison :P
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287
