Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That
will not happen for several reasons. The opposition to the idea
is widespread and deeply held, and there are good arguments to
support that opposition. Furthermore, the economic conditions
necessary for the creation of such a HAL do not exist in the ARM
world, nor indeed in the Linux world in general. (The necessary
condition is the ability for one company to impose a substantial
change by fiat - essentially a monopoly position.)
Shall we agree, then, that any further discussion of the HAL
issue is "just for fun", and that nobody needs to feel threatened
that it would actually happen?
I've recently worked with vendor versions of U-Boot for advanced
ARM SoCs. There is already *huge* chunk of HAL code in those
versions. And if there would be possibility to have callbacks into
the firmware these chunks would only grow, IMHO.
How can there be HAL code in U-Boot unless there is already the
possibility to have callbacks into the firmware?
Currently it aims to abstract hardware from U-Boot and reuse the
same HW access code across operating systems and bootloaders. If
this code would have callbacks I afraid the things would became worse.
The only way I can understand what you said is if I assume that by
"callback", you mean the following sequence:
a) U-boot loads and executes the OS, providing to the OS the address
of some HW access routines that it can use
b) The OS calls one of those HW access routines
c) During the execution of that HW access routine, that routine calls
"back" into the OS, before returning. So a call into the OS is
nested inside a call into U-boot resident code.
If that is what you are worried about, it is not what we were
discussing. We were discussing - and many people were against - step
(b).
Are you saying that step (b) - the OS calling into routines provided
by U-Boot - is already the status quo?
I'm also objecting the step (b) and, fortunately, it's not yet the
status quo.
Current U-Boot/kernel implementations I've encountered still do not
have OS calls to resident HW access routines. But if such calls would
be allowed, my impression is that SoC vendors would make extensive use
of them.
One could argue that a feature that vendors would use extensively is one
that is sorely needed from their point of view.
One counterargument, of course, is that "there is a better way". But it
is only "better" under a cost function that values things differently
than the vendors value them. Were that not so, the vendors would gladly
use the "better" way and not be tempted to use the objectionable
feature. (Unless, of course, the vendors are just ignorant or unskilled
- but I generally find that different cost functions cause more
disconnects than lack of ability.)
It's hardly arguable that Linux community and decision makers at chip
vendor companies use different cost functions. But it's not that obvious
that vendors cost functions based on well established _technical_ analysis.
Many vendors try to use the same code base for several operating
systems. From the high level perspective it sounds logical: use the same
core functionality and thin adaptation layers to fit the core
functionality into several OSes. But in reality, developing the OS
abstraction layer and "thin" adaptation layers may become more expensive
than developing each OS support from scratch. Besides, such code becomes
a real mess after a while, and it's maintainability is very questionable.
Which of course raises the question: How does the Linux community view
such SoC vendors? Are they embraced and eagerly supported, or (either
openly or secretly) viewed as a nuisance? How does the widespread
objection to something that such vendors "would make extensive use of"
mesh with that view?
I cannot tell for the entire Linux community, but from what I know, such
vendors are not much welcomed in the community.
It is not HAL if it can't be called.
The potential for "vendors breaking out of the debugging use case
and turning it into a HAL" is miniscule, because
a) The callback is disabled by default
b) The technical challenges of the callback interface limit its
applicability to specific "wizard user" scenarios
c) OFW is unlikely to achieve sufficient market penetration for
the HAL thing to be worth doing
_______________________________________________
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Sincerely yours,
Mike.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
