[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