Wolfgang Denk wrote:
Dear Pantelis,
in message 3E9EBB5B.4030609@intracom.gr you wrote:
o Two level access password support.
What do you mean with "two level"?
By two level I mean that when something is deployed normally there are two access levels. One level is the user level, which is allowed to view settings and alter very few parameters. The other level is the administrator level in which it is permitted to do (almost) anything.
I cannot see a way to implement this without dramatically changing the functionality and code of U-Boot. You cannot easily restrict the user from - for example - overwriting certain environment variables without castrating him from the power of defining his own settings.
I feel when you need such a level of authentification then the boot loader is not the right environment for your task - use an OS.
We already use an OS. The problem is that the device's user/person who has physical access to it, is not supposed to be allowed to alter anything in the configuration; especially the network settings, since an error there will render the device unoperable. Think access control on a router or something similar.
True, it's a problem on how to implement it cleanly. We'll see how that will turn out. A first simple step will be to have a single password for entering the command mode.
o Different boot-modes.
Please explain. There already are different boot modes, with a lot of configuration options depending on the specific board.
Sure. Depending on the deployment method for each site the configuration of the devices differ.
For example when you do a trial deployment it is pretty normal to have every device configured individually by the administration. In normal operation the devices operate using DHCP/TFTP for obtaining their settings. In both of these modes password are honoured, and the booting of the kernel is immediate Developers in the other hand are working in a different level and like access to everything including to be able to do a full factory-type resetting of the paramers.
Think of it as simplified run-levels.
OK, but which of this part needs new or modified code? All this can be done with U-Boot as is now.
Almost nothing actually, it's just a method of managing the existing settings by using a master switch.
How good is your German? Can you parse board/lwmon/README.keybd ?
My German is not existant unfortunately, but I'll pass it to a collegue who is fluent.
Thanks. I guess I should provide an Engish version one day, too. But so far, all our customers who used features like that are from Germany, and insisted on German docs.
o Cisco router like command interface with history and command completion.
But please do not try to add readline support - the readline lib is way too big...
No it is not like readline. It is much more light-weight, the current version weighs in at about 12k.
Light-weight? Ummm... that's about 10 times (or more) the size of the existing command line parser.
Oh well, it's pretty light weight for what it does ;)
DNS lookup capability. Yes I know that it is strange but actually some DHCP options can return hostnames so it is needed.
Really? Which one? (Which RFC?)
RFC2132
For example:
Option #66 TFTP Server Name Option #69 SMTP Server Name Option #70 POP3 Server Name etc.
I know, only the first one is actually meaningful for a boot loader.
Wolfgang you are free to veto anything that you deem unacceptable; the best I can do is to present my case for the inclusion of these features.
In general I follow the very simple principle that something which is beneficial to one ore more people without hurting others is good and will be added.
Best regards,
Wolfgang Denk
I know, and I appreciate it.
Regards
Pantelis