In message 41484664.20509@intracom.gr you wrote:
IMHO it's better to have something now that works adequately than wait for the best solution which may be some years away.
OK. But then let's implement something that at least has a chance of being accepted widely, and that actually solves the problems instead of creating new ones.
What's your opinoin about implementing Mark A. Greer's bi_recs proposal instead?
There's a need and this thing covers it. I'd be more than happy to
No. It causes additional problems that are not easy to solve.
Trying to do the same in the U-Boot environment would blow up the environment and easily overflow it on most systems. Also parsing and decoding the ASCII representation would slow down the Linux boot process too much. Also the output of a "printenv" would become unreadable, etc.
Obviously systems that don't need it, won't enable it.
If your proposal works as intended, it may become the satndard interface to pass information to the kernel, so it should work on all systems. Also, maybe I _need_ this on a system with just a 2 kB EEPROM. What will I do then? In such a situation the environment space is usually tight already now. And remember that the RAM copy of the environment is not bigger than the persistent copy (and this is intentionally, because otherwise you run into trouble when trying to "saveenv").
And I don't think that searching the environment for a couple of variables is going to be a perceptible slowdown.
No matter how much it is, it is wasted effort. There are systems where each millisecond is precious.
I'm open to suggestions.
See above. What about Mark's proposal? And what shall we do with the OCP stuff?
Best regards,
Wolfgang Denk