[PATCH] uefirttime: add fwts tests for the UEFI get/set time runtime services

IvanHu ivan.hu at canonical.com
Wed Oct 17 10:43:28 UTC 2012


Thanks Colin, Keng-yu for your comments.

I will modify and resend the patch.

Ivan


On 10/17/2012 05:41 PM, Keng-Yu Lin wrote:
> On Tue, Oct 16, 2012 at 7:09 PM, Colin Ian King
> <colin.king at canonical.com> wrote:
>> Thanks Ivan,
>>
>> The bulk of this is essentially OK, but I have a few notes so to improve
>> this a little more.  Thanks for the work on this initial version.
>>
>>
>>
>> On 16/10/12 09:37, Ivan Hu wrote:

>>> +               return false;
>>> +
>>> +       if (!(Time->TimeZone == FWTS_UEFI_UNSPECIFIED_TIMEZONE ||
>>> +               (Time->TimeZone >= -1440 && Time->TimeZone <= 1440)))
>>> +               return false;
>>
>>
>> What is the significance of -1440 to 1440? is there a specification (url +
>> page) I can refer to to check this out?
>>
>>

The value of the timezone is followed by the UEFI spec 2.3.1 errata C, 
page 233,234. you could download from:
http://www.uefi.org/specs/


>>> +
>>> +static int uefirttime_init(fwts_framework *fw)
>>> +{
>>> +       if (fwts_firmware_detect() != FWTS_FIRMWARE_UEFI) {
>>> +               fwts_log_info(fw, "Cannot detect any UEFI firmware.
>>> Aborted.");
>>> +               return FWTS_ABORTED;
>>> +       }
>>> +
>>> +       fd = open("/dev/efi_runtime", O_RDONLY);
>>> +       if (fd == -1) {
>>> +               fwts_log_info(fw, "Cannot open efi_runtime driver.
>>> Aborted.");
>>> +               return FWTS_ABORTED;
>>> +       }
>>
>>
>> I'm a little confused about the mechanism that installs the efi_runtime
>> driver.  I realise dkms is used to build the driver, but how does it get
>> installed at run time?  Is that something that fwts should try to load?
>>
>
> This is what is missing now.
> We have a separate debian package to install the driver source and
> dkms builds and installs the binary in the postinst step.
> But at the moment there is no code in fwts to modprobe/insmod the driver binary.
>
>> Perhaps we should first check if /dev/efi_runtime exists, if not, then try
>> to force load the driver. If it still does not exist, we should then bail
>> out and report that the driver is probably not loaded.  Then we should do
>> the open, and if that fails we have some form of driver error.  As it
>> stands, just reporting that /dev/efi_runtime couldn't be opened does not
>> really help a user who sees a test fail because of some mechanism that they
>> don't need to know about.
>>
>
> A system()-like to call the modprobe command along with the checking
> the existence of /dev/efi_runtime could be the most simple way.
>

It seems that we can not force load the efi_runtime driver if the driver 
doesn't exist, but I will add the checking nonresistance code first and 
then do the open driver.

>>> +
>>> +       return FWTS_OK;
>>> +}
>>
>>




More information about the fwts-devel mailing list