qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V2 4/9] Add tpm_tis driver to build process


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH V2 4/9] Add tpm_tis driver to build process
Date: Tue, 5 Apr 2011 21:55:51 +0300

On Tue, Apr 5, 2011 at 9:33 PM, Stefan Berger
<address@hidden> wrote:
> On 04/05/2011 01:45 PM, Blue Swirl wrote:
>>
>> On Tue, Apr 5, 2011 at 5:08 AM, Stefan Berger
>> <address@hidden>  wrote:
>>>
>>> On 04/03/2011 05:20 AM, Blue Swirl wrote:
>>>>
>>>> On Fri, Apr 1, 2011 at 10:57 PM, Stefan Berger
>>>> <address@hidden>    wrote:
>>>>>
>>>>> On 04/01/2011 02:14 PM, Blue Swirl wrote:
>>>>>
>>>>> At this point there is no compile test needed since all code is
>>>>> 'there'.
>>>>> It's merely adding the front-end,i.e., the TPM TIS emulation to be
>>>>> compiled.
>>>>
>>>> If the basic device (without the tpms-devel library) can be built on
>>>> any OS, the flag should go to default-configs/*86*-softmmu.mak.
>>>>
>>> It can be built on any OS, but it is of no use since the backend
>>> (libtpms)
>>> is only available on Linux and we don't support it on another OS. Unless
>>> someone else wants to port it to other OSes, I'd say that the test for
>>> Linux
>>> is useful.
>>> I'd actually also only compile the TIS if libtpms could be found, and
>>> terminate with an error message otherwise. I would add this restriction
>>> only
>>> in the last patch, so that in patch 4 at least for now the TIS can be
>>> built.
>>> Does that sound reasonable?
>>
>> It should be possible to emulate the device (to some degree) without
>> relying on backend. See for example the recently committed smart card
>> device.
>>
> In case of a TPM, the specs are huge and translate into multiple 10k lines
> of code. If there was to be a dummy backend, all it could send back would be
> error messages...

Then how about emulating the library instead so that all calls return failure?

If a device is built only in special circumstances, it will be more
prone to bit rot. We have a few such devices though, so it's not so
big deal.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]