On 09.02.21 20:40, Arthur Heymans wrote:
Hi,
Shell scripts are a very bad way to construct binary data structures.
Maybe a python or perl script ?
Being open source does not require to be public.
How so, exactly ?
If only a few parties have access to the source code, eg. some vendor shares with its business partners, then it's just "shared code".
FWIW we couldn't publish our tool as a binary-only if it was not licenqed as it currently is (BSD-3 clause). I'm not claiming the binary is open source ofc, but we are committed to publish the code ASAP.
If just the binary is published, without source code, then it is NOT open source. Yes, BSD clause permits reclosing of formerly open software - that's why we have other license models like GPL. (GPL code isn't OSS, but Free software - it remains free and can't be closed again w/o breaking the license).
I don't like this very much either, but it looks like it is the best move available.
Move in which direction, exactly ? What exactly can we - the free software community - gain from that ?
The only thing I see right now is one can recompile the whole thing, under certain circumstances, possibly with *some* modifications. Maybe, for some individuals, better than nothing, but conceptionally hasn't much to do w/ FOSS.
Bad side: folks like Intel, can now lay back and say "hey, those FOSS jerks have got a piece of food and can shut up again". For us, mission failed.
Silicon vendors being overprotective over their IP is a recurring issue.
Yes, that's their problem. They've created this mess themselves, and they should't expect us, the public, the FOSS community, cleaning up their mess, even for free (beer).
I don't wanna speculate what's going on in their heads (more precisely the heads of some suit-wearing folks high upstairs - not the tech guys), but the whole idea of "protected IP" for those things (anything that one needs to develop drivers) is completely nonsense. The only practical reason for that is defrauding their silently own paying customers and forcing them into an dishonest dependency. In other words: peventing the *owners* of those products to fully excersise their legal rights from their ownership title. (Apple products are a woderful example for that kind of abuse: you legally *buy* a device, but effectively you've just suscribed a few services).
In your case, the situation very pretty simple: all you need is to create a simple signature of some file and put everything that way, that the SoC designers happend to choose. This is neither an invention nor an piece of art, or something else that's egligably for any kind of legal IP protection. No notable level of creativity. It's just a simple formula.
If we buy into this and accept proprietary implementations of simple formulas, then we're lost and can give up the whole project. If we let that pass, we soon need some proprietary app just for computing the surface area of a circle.
Instead, I'd like to propose a different approach:
You could sign a dozen of images and publish them along with the key pair. So we can find out the formula on our own and type it down in some convenient language. No NDA problems anymore. You didn't tell any "business secret", and they got another lecture that their ridiculous behaviour didn't give them anything but useless costs, and the whole world laughts about them.
The strongest weapon against any kind of oppression is the oppressed just don't play along with their oppressors anymore. Just stop doing what they want. It's that simple.
Developing everything on a private branch and doing a big code dump once the silicon vendor gives a green light is an even bigger disservice to the community.
Of course, you should send cleanly written, easily digestable patches, as usual. If your queue is quite long, then it just takes a while for review and merge. I don't see any problem with that.
OTOH, your quick+dirty proposal is just an ugly hack, that might be usable for some folks, but far away from what I'd consider maintainable.
- The rate at which new silicon and platforms are pushed is staggering.
If one has to wait for the silicon vendor green light before publishing code the platform might already being to old to be very interesting.
The best option of course is not buying those HW, until it is mainlined. Personally, I'm circumventing x86 where ever I can. The more people doing that, the more pressure on Intel and AMD.
We saw this issue in the past where AGESA srubbing took so long that the platforms were not interesting anymore.
Yes, AGESA is a pile of shit. It's the same scenario as above - I don't see any beneign reason of not publishing the necessary specs, so we could implement the *necessary* pieces our own. What do we actually need it for ? At the end, we only need to do a few boring early HW setups, clocks, timings, regulators, etc. Nothing spectacular, once your know the correct values and their order.
Intel also publishes FSP glue code without FSP being published. Relying on things not yet published seems to be a necessary compromise to have upstream development in the master branch for new silicon.
Only for Intel and AMD. I don't recall any similar case ARM world, where we needed any blobs just for SoC bringup. (GPUs etc often still are a big mess, but that's far out of scope here)
One of the things the coreboot project and community does very well at the moment is to develop everything in one master branch, compared to the UEFI world where everything lives in a branch and where there is pretty much 0 community.
UEFI never had community. It's always been design-by-committee. That's why it's such a ridiculous misdesign.
To keep this upstream development model in line with new silicon development it looks like some compromises are necessary.
Depends on how exactly you define "in line". Personally, I don't think that having the newest stuff as quick as possible is an worthy goal at all. (actually, I newer buy any bleeding edge hw - wait until the next generation is out, so there's enough of practical experience with it and prices fall down - applies to all kind of technology).
If we always have to wait for the silicon vendor to be able to upstream, the platform would already be in production and upstreaming is less interesting for both the vendor and the community.
I see that differently: my primary criterion for hw purchase decision (when being just in the user role) is available free software support, or at least open specs. Without that, there gotta be a damn good reason for buying it. A silicon vendor who's not playing with open cards just isn't trustworthy to me.
By the way: we'd also should talk about, how you actually define "upstreaming". Just having it merged into master branch once, isn't enough, IMHO (from my practical experience w/ certain silicon vendors, that's seems one of their primary misunderstandings). It has to fit well into they way, how things are handled in upstream. It has to be actively maintained in order to keep it that ways. And that's the point where such blobs become really ugly.
So yes, in a sense it's urgent and this is how a lot of upstream development is going on anyway at the moment.
Why not just keeping it in a different branch, that's rebased with each new mainline release ?
While it is honorable that you want to work as close to master as
possible,
I do think you should have considered that a lot earlier in this
process,
before getting tangled up in Intel's net of NDA nonsense.
So no upstream Intel support in coreboot anymore? I'll put it on the agenda tomorrow ;-)
Not quite, but without the pseudo help of such corporations.
I wish we had enough leverage as a community to change the silicon vendors way, but that is just not the case.
We can't ever change them, anyways. No matter how many people we're (or how many users we have) - we can only change ourselves. And we can decide whether give them any single penny anymore, and what we suggest to others.
I've decided (for me personally) to leave Intel alone, let'em die lonely. Maybe I change my mind, when they fully open up ME. Until then, remains on the blacklist.
Sorry, x86 sucks.
On a philosophical note, it's always possible to define goals and desires against which everything sucks. It's a cheap trick of the mind. The goal should be to make tomorrow better than today, even if the progress is small ;-)
No, just alone from purely technical perspective, x86 is misdesigned in many ways - including it's spinoffs like ACPI or UEFI. Yes, it gives lots of computing power on a single dice, and you get get it anywhere on the next corner, buts thats it.
--mtx