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
--
---
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
i...@metux.net -- +49-151-27565287
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
