From: Tadeusz Struk <tadeusz.struk@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: flihp@twobit.us, jgg@ziepe.ca, linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] tpm: add ptr to the tpm_space struct to file_priv
Date: Fri, 10 Aug 2018 11:05:17 -0700 [thread overview]
Message-ID: <2bacb3d8-3897-e147-252f-c49de9e7806b@intel.com> (raw)
In-Reply-To: <20180810172700.GU4692@linux.intel.com>
On 08/10/2018 10:27 AM, Jarkko Sakkinen wrote:
> On Tue, Aug 07, 2018 at 01:27:44PM -0700, Tadeusz Struk wrote:
>> Add a ptr to struct tpm_space to the file_priv to have an easy
>> access to it in the async job without the need to allocate memory.
>> This also allows to consolidate of the write operations for
>> the two interfaces.
>
> I think the 2nd premise should be the priority and the first premise should
> be removed as it is not needed in any possible way to justify the
> change.
Jarkko,
The main reason why the pointer to tpm_space struct was added to the
file_priv was to have access to space in the async job when it is enqueued
via the /dev/tpm<N> interface. Currently it is only available in tpmrm_priv.
Otherwise I would need to introduce yet another struct what would consist of
a ptr file_priv and a ptr to tpm_space and allocate it on every enqueue.
Much easier was to to it this way. The consolidation was only a side effect
of this so I think the description is correct.
Thanks,
--
Tadeusz
WARNING: multiple messages have this Message-ID (diff)
From: tadeusz.struk@intel.com (Tadeusz Struk)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v4 1/2] tpm: add ptr to the tpm_space struct to file_priv
Date: Fri, 10 Aug 2018 11:05:17 -0700 [thread overview]
Message-ID: <2bacb3d8-3897-e147-252f-c49de9e7806b@intel.com> (raw)
In-Reply-To: <20180810172700.GU4692@linux.intel.com>
On 08/10/2018 10:27 AM, Jarkko Sakkinen wrote:
> On Tue, Aug 07, 2018 at 01:27:44PM -0700, Tadeusz Struk wrote:
>> Add a ptr to struct tpm_space to the file_priv to have an easy
>> access to it in the async job without the need to allocate memory.
>> This also allows to consolidate of the write operations for
>> the two interfaces.
>
> I think the 2nd premise should be the priority and the first premise should
> be removed as it is not needed in any possible way to justify the
> change.
Jarkko,
The main reason why the pointer to tpm_space struct was added to the
file_priv was to have access to space in the async job when it is enqueued
via the /dev/tpm<N> interface. Currently it is only available in tpmrm_priv.
Otherwise I would need to introduce yet another struct what would consist of
a ptr file_priv and a ptr to tpm_space and allocate it on every enqueue.
Much easier was to to it this way. The consolidation was only a side effect
of this so I think the description is correct.
Thanks,
--
Tadeusz
next prev parent reply other threads:[~2018-08-10 20:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-07 20:27 [PATCH v4 0/2] tpm: add support for nonblocking operation Tadeusz Struk
2018-08-07 20:27 ` Tadeusz Struk
2018-08-07 20:27 ` [PATCH v4 1/2] tpm: add ptr to the tpm_space struct to file_priv Tadeusz Struk
2018-08-07 20:27 ` Tadeusz Struk
2018-08-10 17:27 ` Jarkko Sakkinen
2018-08-10 17:27 ` Jarkko Sakkinen
2018-08-10 18:05 ` Tadeusz Struk [this message]
2018-08-10 18:05 ` Tadeusz Struk
2018-08-10 18:43 ` Jarkko Sakkinen
2018-08-10 18:43 ` Jarkko Sakkinen
2018-08-07 20:27 ` [PATCH v4 2/2] tpm: add support for nonblocking operation Tadeusz Struk
2018-08-07 20:27 ` Tadeusz Struk
2018-08-10 17:43 ` Jarkko Sakkinen
2018-08-10 17:43 ` Jarkko Sakkinen
2018-08-10 18:21 ` Tadeusz Struk
2018-08-10 18:21 ` Tadeusz Struk
2018-08-10 18:48 ` James Bottomley
2018-08-10 18:48 ` James Bottomley
2018-08-10 18:56 ` Tadeusz Struk
2018-08-10 18:56 ` Tadeusz Struk
2018-08-10 19:00 ` James Bottomley
2018-08-10 19:00 ` James Bottomley
2018-08-10 19:14 ` Tadeusz Struk
2018-08-10 19:14 ` Tadeusz Struk
2018-08-12 10:39 ` Jarkko Sakkinen
2018-08-12 10:39 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2bacb3d8-3897-e147-252f-c49de9e7806b@intel.com \
--to=tadeusz.struk@intel.com \
--cc=flihp@twobit.us \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.