[yast-devel] Re: Mockups pre kdump
Hi Bernhard, I had discussion with my colleagues about UI and about usability. The result is some widgets are not clear for understanding their main goals. I would like to change some of them. ,---- Enable/Disable Kdump ---------------------------------, | | | (o) Enable kdump | | ( ) Disable kdump | | ( ) Disable kdump (Remove the Kernel Parameter) | | | ............................................................. The frame "Enable/Disable Kdump" looks good but... The better is split removing kernel parameter and enable/disable kdump service. ,---- Enable/Disable Kdump ---------------------------------, | | | (o) Enable kdump | | ( ) Disable kdump | | | ............................................................. ,---- Boot Option (crashkernel) for Kdump ------------------, | | | (o) Add Boot Option | | ( ) Remove Boot Option | | | ............................................................. What is your opinion? I interested in option "Enable kdump" from the frame "Enable/Disable Kdump". I am not sure if it is good idea enable kdump service without booting with kernel parameter for kdump. Could you write me something about dependencies between "kdump service" and "kernel parameter" for kdump? What happen if machine boots without crashkernel parameter and user enable/disable kdump service etc.? Next there is the frame for switching between options KDUMP_COMMANDLINE and KDUMP_COMMANDLINE_APPEND. ,---- Command Line -----------------------------------------, | | | Kdump Command Line ( ) Append | | [_____________________] (O) Replace | | | | | ............................................................. Radiobuttons Append and Replace are good solution but radiobutton Replace has wrong name. It is not clear what the radiobutton Replace means. Probably better name for radiobutton will be "Normal". Maybe longer description for radiobuttons will be better too. (Append kdump Commandline / Normal kdump Commandline) I prefer solution with 1 checkbox: ,---- Command Line -----------------------------------------, | | | Kdump Command Line | | [_______________________] ( ) Append kdump Commandline | | | | | ............................................................. If user select checkbox "Append kdump Commandline" the frame "Command Line" is changed: ,---- Command Line -----------------------------------------, | | | Kdump Command Line Append | | [_______________________] (X) Append kdump Commandline | | | | | ............................................................. My final question is about KDUMP_KEEP_OLD_DUMPS. Could you write me the maximum value for this options from /etc/sysconfig/kdump? ------------------------------------------------------------- I accept that name of push buttons will be "[Browse]". Using tabs or left-handed-tree: I am sure that final version of UI will has 4 dialogs maybe 5. (There are still some open points) It is not problem transfer left-hand-tree to the tabs. If final version has 4 dialogs I transfer UI to the tabs. I will continue with left-hand-tree. After clearing all options and settings for kdump we can start discussion about using tabs or left-hand-tree. I will delete unclear options from module. It doesn't mean that the deleted parts are lost. :) I only temporary delete parts which are not clear now. You will find new mock-ups on the wiki soon. (http://en.opensuse.org/YaST/yast-kdump) Finally thank you all for their hints, comments and suggestions. best regards jozef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi Jozef, * Jozef Uhliarik <juhliarik@suse.cz> [2007-04-25 18:16]:
The result is some widgets are not clear for understanding their main goals. I would like to change some of them.
,---- Enable/Disable Kdump ---------------------------------, | | | (o) Enable kdump | | ( ) Disable kdump | | ( ) Disable kdump (Remove the Kernel Parameter) | | | .............................................................
The frame "Enable/Disable Kdump" looks good but... The better is split removing kernel parameter and enable/disable kdump service.
,---- Enable/Disable Kdump ---------------------------------, | | | (o) Enable kdump | | ( ) Disable kdump | | | .............................................................
,---- Boot Option (crashkernel) for Kdump ------------------, | | | (o) Add Boot Option | | ( ) Remove Boot Option | | | .............................................................
What is your opinion? I interested in option "Enable kdump" from the frame "Enable/Disable Kdump". I am not sure if it is good idea enable kdump service without booting with kernel parameter for kdump.
Right. :) You have to take care that this option is not selectable, e.g. by graying out stuff.
Could you write me something about dependencies between "kdump service" and "kernel parameter" for kdump? What happen if machine boots without crashkernel parameter and user enable/disable kdump service etc.?
You can disable the service without removing the command line (but IMO it doesn't make much sense, you waste memory with no benefit). But you *cannot* enable the service without the command line. The service script will simply fail and output an error message.
Next there is the frame for switching between options KDUMP_COMMANDLINE and KDUMP_COMMANDLINE_APPEND.
,---- Command Line -----------------------------------------, | | | Kdump Command Line ( ) Append | | [_____________________] (O) Replace | | | | | .............................................................
Radiobuttons Append and Replace are good solution but radiobutton Replace has wrong name. It is not clear what the radiobutton Replace means. Probably better name for radiobutton will be "Normal". Maybe longer description for radiobuttons will be better too. (Append kdump Commandline / Normal kdump Commandline)
I prefer solution with 1 checkbox:
,---- Command Line -----------------------------------------, | | | Kdump Command Line | | [_______________________] ( ) Append kdump Commandline | | | | | .............................................................
If user select checkbox "Append kdump Commandline" the frame "Command Line" is changed:
,---- Command Line -----------------------------------------, | | | Kdump Command Line Append | | [_______________________] (X) Append kdump Commandline | | | | | .............................................................
That sounds good.
My final question is about KDUMP_KEEP_OLD_DUMPS. Could you write me the maximum value for this options from /etc/sysconfig/kdump?
It depends on disk space and the maximum arithmetics the shell can handle. ;-) So, there's no "real" maximum. Maybe one checkbox to disable delection (i.e. to 'enable' it) and a maximum spin box between 1 and 50 with a default of 5.
-------------------------------------------------------------
I accept that name of push buttons will be "[Browse]".
Of course. We need to change this if we support SSH/NFS/... in the future anyway. ;-) Thanks, Bernhard -- SUSE LINUX Products GmbH Tel. +49 (911) 74053-0 Maxfeldstr. 5 GF: Markus Rex 90409 Nürnberg, Germany HRB 16746 (AG Nürnberg) OpenPGP DDAF6454: F61F 34CC 09CA FB82 C9F6 BA4B 8865 3696 DDAF 6454 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi, I did update of UI. You can find new mock-ups on the http://en.opensuse.org/YaST/yast-kdump We have following frames: ,---- Enable/Disable Kdump ---------------------------------, | | | (o) Enable kdump | | ( ) Disable kdump | | | ............................................................. ,---- Boot Option (crashkernel) for Kdump ------------------, | | | (o) Add Boot Option | | ( ) Remove Boot Option | | | ............................................................. The frame "Boot Option (crashkernel) for Kdump" is clear it only adds or removes boot parameter "crashkernel". The change this option apply after reboot. I interested in the frame Enable/Disable Kdump and logic for this frame. I would like only clarify from you logic for this frames and what is necessary to allow users. 1. user boots with crashkernel parameter: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - frame has selected "(o) Enable kdump" - user can disable kdump service via selecting "( ) Disable kdump" Is it possible to disable kdump? Is it necessary to allow this operation users? - kdump service is disabled "(o) Disable kdump" - user can enable kdump service via selecting "( ) Enable kdump" Is it possible enable/start kdump in this case? Is it necessary to allow this operation users? My opinion is only operation "(o) Disable kdump" and "(o) Remove Boot Option" has logic (necessary reboot) but this is question for you. :) You are expert for debugging kernel and kdump. 2. user boots WITHOUT crashkernel parameter: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ All changes in the frames "Boot Option (crashkernel) for Kdump" and "Enable/Disable Kdump" will be possible. I prefer following operations: i. "(o) Add Boot Option" and "(o) Enable kdump" (necessary reboot) ii. "(o) Remove Boot Option" and "(o) Disable kdump" (without reboot because kernel was sterted without "crashkernel" - present status) Another combinations will be permitted. If you want to add another combinations write me them please. Mock-ups don't include unclear widgets. If you finish, clarify or add new functionality for kdump you can write me about it and I add it into UI. Best regards Jozef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thu, Apr 26, 2007 at 01:16:39PM +0200, Jozef Uhliarik wrote:
Hi, I did update of UI. You can find new mock-ups on the http://en.opensuse.org/YaST/yast-kdump
We have following frames:
,---- Enable/Disable Kdump ---------------------------------, | | | (o) Enable kdump | | ( ) Disable kdump | | | .............................................................
,---- Boot Option (crashkernel) for Kdump ------------------, | | | (o) Add Boot Option | | ( ) Remove Boot Option | | | .............................................................
The frame "Boot Option (crashkernel) for Kdump" is clear it only adds or removes boot parameter "crashkernel". The change this option apply after reboot.
I interested in the frame Enable/Disable Kdump and logic for this frame. I would like only clarify from you logic for this frames and what is necessary to allow users.
1. user boots with crashkernel parameter: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - frame has selected "(o) Enable kdump" - user can disable kdump service via selecting "( ) Disable kdump"
Is it possible to disable kdump? Is it necessary to allow this operation users?
- kdump service is disabled "(o) Disable kdump" - user can enable kdump service via selecting "( ) Enable kdump"
Is it possible enable/start kdump in this case? Is it necessary to allow this operation users?
My opinion is only operation "(o) Disable kdump" and "(o) Remove Boot Option" has logic (necessary reboot) but this is question for you. :) You are expert for debugging kernel and kdump.
2. user boots WITHOUT crashkernel parameter: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ All changes in the frames "Boot Option (crashkernel) for Kdump" and "Enable/Disable Kdump" will be possible.
I prefer following operations:
i. "(o) Add Boot Option" and "(o) Enable kdump" (necessary reboot) ii. "(o) Remove Boot Option" and "(o) Disable kdump" (without reboot because kernel was sterted without "crashkernel" - present status)
Another combinations will be permitted.
If you want to add another combinations write me them please.
Hi Jozef, Looks like it is confusing for us the developers themselves. What if we just have "(o) Enable (o) Disable" option only. If the user selects "Enable" the tool can _display a message box_ conveying the user that the change will be in effect after a reboot. The config tool then puts the "crashkernel=" parameter in the kernel command line as per the memory reservation settings. And the kdump service is run while the OS is coming up through init script. I the user selects "Disable" The kdump service will be stopped and not run by defalt from the next oot onwards. Also, the next boot will not have he "crashkernel=" parameter.
Mock-ups don't include unclear widgets. If you finish, clarify or add new functionality for kdump you can write me about it and I add it into UI.
Provided some comments in the other thread. Thanks Maneesh -- Maneesh Soni Linux Technology Center, IBM India Systems and Technology Lab, Bangalore, India -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Maneesh Soni wrote:
2. user boots WITHOUT crashkernel parameter: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ All changes in the frames "Boot Option (crashkernel) for Kdump" and "Enable/Disable Kdump" will be possible.
I prefer following operations:
i. "(o) Add Boot Option" and "(o) Enable kdump" (necessary reboot) ii. "(o) Remove Boot Option" and "(o) Disable kdump" (without reboot because kernel was sterted without "crashkernel" - present status)
Another combinations will be permitted.
If you want to add another combinations write me them please.
Hi Jozef,
Looks like it is confusing for us the developers themselves. What if we just have "(o) Enable (o) Disable" option only. If the user selects "Enable" the tool can _display a message box_ conveying the user that the change will be in effect after a reboot. The config tool then puts the "crashkernel=" parameter in the kernel command line as per the memory reservation settings. And the kdump service is run while the OS is coming up through init script.
I the user selects "Disable" The kdump service will be stopped and not run by defalt from the next oot onwards. Also, the next boot will not have he "crashkernel=" parameter.
Yes, this would be even better. Less fantasy, more reality :) User doesn't need to tune everything, some features might be a bit complicated inside the logic layer but UI should be simple as possible. Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
participants (4)
-
Bernhard Walle -
Jozef Uhliarik -
Lukas Ocilka -
Maneesh Soni