From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1UDUKS-0000T7-5g for mharc-grub-devel@gnu.org; Thu, 07 Mar 2013 01:29:24 -0500 Received: from eggs.gnu.org ([208.118.235.92]:54179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDUKO-0000SR-MN for grub-devel@gnu.org; Thu, 07 Mar 2013 01:29:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDUKM-0001Xs-Uu for grub-devel@gnu.org; Thu, 07 Mar 2013 01:29:20 -0500 Received: from collab.rosalab.ru ([217.199.216.181]:37829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDUKM-0001Xa-AH for grub-devel@gnu.org; Thu, 07 Mar 2013 01:29:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by collab.rosalab.ru (Postfix) with ESMTP id 30CC829C2EE for ; Thu, 7 Mar 2013 10:29:16 +0400 (MSK) X-Virus-Scanned: amavisd-new at rosalab.ru Received: from collab.rosalab.ru ([127.0.0.1]) by localhost (collab.rosalab.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMd9-jwH2kNg for ; Thu, 7 Mar 2013 10:29:15 +0400 (MSK) Received: from icedphoenix.localnet (unknown [10.168.1.56]) by collab.rosalab.ru (Postfix) with ESMTPSA id 6960D29C2EC for ; Thu, 7 Mar 2013 10:29:15 +0400 (MSK) From: Vladimir Testov To: grub-devel@gnu.org Subject: Re: [PATCH] gfxterm: check elements' properties and hadle errors. Date: Thu, 07 Mar 2013 10:29:14 +0400 Message-ID: <9805474.MFZGl5BBPZ@icedphoenix> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart3078256.EAvCV5pCYF" Content-Transfer-Encoding: 7Bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 217.199.216.181 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 06:29:22 -0000 This is a multi-part message in MIME format. --nextPart3078256.EAvCV5pCYF Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" >Again - what problem are you trying to solve? I added unknown option >to theme element and it was loaded and displayed just fine. Why >aborting theme loading in this case is better? There is possibility that we can misprint some option. Or write some wrong value for some existing option. I think it's better to know about it - so we can quickly find the place where we are wrong. >May be you should be less hostile to simple questions? I take it you >are expert in GRUB2 themes. I'm not and I'm trying to learn. OK? Sorry, if I've insulted you. That wasn't my intension. >You conveniently ignored comment about losing original error. The original error will be displayed anyway, because it's called via grub_error function. grub_errno in that case is only an indicator that everything went all right or something went wrong. Returning error state (from component's modules) doesn't change grub_errno until we call grub_error in theme_loader. In current state return value isn't analized. And I think it's not good. (if theme_loaders checks global options and component's names - why shouldn't it also check for component's options) I could think about more complicated hadling of return value. If it is GRUB_ERR_IO then either information message about the error has already been shown (don't see the possibility of the fact right now) or we've faced some non-existing option (or option with a misprint) So I could check for other types of error and hadle them more properly. grub_errno in that case means error code, returned after trying to set a particular value to a particular option. so if return code is GRUB_ERR_IO then there is a problem with option name otherwise there is a problem with a value (e.g. we tried to set integer value to a option, which accepts string value.) If you concerns are about right that - I can slightly remake the patch to show more detailed information about the error. Cheers. -- With best regards, _______________________________ Vladimir Testov, ROSA Laboratory. www.rosalab.ru --nextPart3078256.EAvCV5pCYF Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii" 
>Again - what problem are you trying to solve? I added unknown option
>to theme element and it was loaded and displayed just fine. Why
>aborting theme loading in this case is better?

There is possibility that we can misprint some option. Or write some wrong value for some existing option.
I think it's better to know about it - so we can quickly find the place where we are wrong.

>May be you should be less hostile to simple questions? I take it you
>are expert in GRUB2 themes. I'm not and I'm trying to learn. OK?

Sorry, if I've insulted you. That wasn't my intension.

>You conveniently ignored comment about losing original error.
The original error will be displayed anyway, because it's called via grub_error function.
grub_errno in that case is only an indicator that everything went all right or something went wrong.
Returning error state (from component's modules) doesn't change grub_errno until we call grub_error in theme_loader.
In current state return value isn't analized. And I think it's not good.
(if theme_loaders checks global options and component's names - why shouldn't it also check for component's options)

I could think about more complicated hadling of return value.
If it is GRUB_ERR_IO then either information message about the error has already been shown
(don't see the possibility of the fact right now)
or we've faced some non-existing option (or option with a misprint)
So I could check for other types of error and hadle them more properly.

grub_errno in that case means error code, returned after trying to set a particular value to a particular option.
so if return code is GRUB_ERR_IO then there is a problem with option name
otherwise there is a problem with a value (e.g. we tried to set integer value to a option, which accepts string value.)

If you concerns are about right that - I can slightly remake the patch to show more detailed information about the error.

Cheers.

--

With best regards,

_______________________________

Vladimir Testov, ROSA Laboratory.

www.rosalab.ru

--nextPart3078256.EAvCV5pCYF--