From: Randy Dunlap <randy.dunlap@oracle.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Zach Pfeffer <zpfeffer@codeaurora.org>,
mel@csn.ul.ie, andi@firstfloor.org, dwalker@codeaurora.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Date: Thu, 01 Jul 2010 14:48:29 -0700 [thread overview]
Message-ID: <4C2D0D2D.8090407@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1007011450130.13691@utopia.booyaka.com>
On 07/01/10 13:59, Paul Walmsley wrote:
> Randy,
>
> On Thu, 1 Jul 2010, Randy Dunlap wrote:
>
>>> + * @start_addr The starting address of the VCM region.
>>> + * @len The len of the VCM region. This must be at least
>>> + * vcm_min() bytes.
>>
>> and missing lots of struct members here.
>> If some of them are private, you can use:
>>
>> /* private: */
>> ...
>> /* public: */
>> comments in the struct below and then don't add the private ones to the
>> kernel-doc notation above.
>
> To avoid wasting space in structures, it makes sense to place fields
> smaller than the alignment width together in the structure definition.
> If one were to do this and follow your proposal, some structures may need
> multiple "private" and "public" comments, which seems undesirable. The
> alternative, wasting memory, also seems undesirable. Perhaps you might
> have a proposal for a way to resolve this?
I don't know of a really good way. There are a few structs that have
multiple private/public entries, and that is OK.
Or you can describe all of the entries with kernel-doc notation.
Or you can choose not to use kernel-doc notation on some structs.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Zach Pfeffer <zpfeffer@codeaurora.org>,
mel@csn.ul.ie, andi@firstfloor.org, dwalker@codeaurora.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Date: Thu, 01 Jul 2010 14:48:29 -0700 [thread overview]
Message-ID: <4C2D0D2D.8090407@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1007011450130.13691@utopia.booyaka.com>
On 07/01/10 13:59, Paul Walmsley wrote:
> Randy,
>
> On Thu, 1 Jul 2010, Randy Dunlap wrote:
>
>>> + * @start_addr The starting address of the VCM region.
>>> + * @len The len of the VCM region. This must be at least
>>> + * vcm_min() bytes.
>>
>> and missing lots of struct members here.
>> If some of them are private, you can use:
>>
>> /* private: */
>> ...
>> /* public: */
>> comments in the struct below and then don't add the private ones to the
>> kernel-doc notation above.
>
> To avoid wasting space in structures, it makes sense to place fields
> smaller than the alignment width together in the structure definition.
> If one were to do this and follow your proposal, some structures may need
> multiple "private" and "public" comments, which seems undesirable. The
> alternative, wasting memory, also seems undesirable. Perhaps you might
> have a proposal for a way to resolve this?
I don't know of a really good way. There are a few structs that have
multiple private/public entries, and that is OK.
Or you can describe all of the entries with kernel-doc notation.
Or you can choose not to use kernel-doc notation on some structs.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: randy.dunlap@oracle.com (Randy Dunlap)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Date: Thu, 01 Jul 2010 14:48:29 -0700 [thread overview]
Message-ID: <4C2D0D2D.8090407@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1007011450130.13691@utopia.booyaka.com>
On 07/01/10 13:59, Paul Walmsley wrote:
> Randy,
>
> On Thu, 1 Jul 2010, Randy Dunlap wrote:
>
>>> + * @start_addr The starting address of the VCM region.
>>> + * @len The len of the VCM region. This must be at least
>>> + * vcm_min() bytes.
>>
>> and missing lots of struct members here.
>> If some of them are private, you can use:
>>
>> /* private: */
>> ...
>> /* public: */
>> comments in the struct below and then don't add the private ones to the
>> kernel-doc notation above.
>
> To avoid wasting space in structures, it makes sense to place fields
> smaller than the alignment width together in the structure definition.
> If one were to do this and follow your proposal, some structures may need
> multiple "private" and "public" comments, which seems undesirable. The
> alternative, wasting memory, also seems undesirable. Perhaps you might
> have a proposal for a way to resolve this?
I don't know of a really good way. There are a few structs that have
multiple private/public entries, and that is OK.
Or you can describe all of the entries with kernel-doc notation.
Or you can choose not to use kernel-doc notation on some structs.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
next prev parent reply other threads:[~2010-07-01 21:50 UTC|newest]
Thread overview: 142+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-30 5:55 [RFC 1/3] mm: iommu: An API to unify IOMMU, CPU and device memory management Zach Pfeffer
2010-06-30 5:55 ` Zach Pfeffer
2010-06-30 5:55 ` Zach Pfeffer
2010-06-30 5:55 ` [RFC 2/3] mm: iommu: A physical allocator for the VCMM Zach Pfeffer
2010-06-30 5:55 ` Zach Pfeffer
2010-06-30 5:55 ` Zach Pfeffer
2010-06-30 5:55 ` [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager Zach Pfeffer
2010-06-30 5:55 ` Zach Pfeffer
2010-06-30 5:55 ` Zach Pfeffer
2010-07-01 17:17 ` Randy Dunlap
2010-07-01 17:17 ` Randy Dunlap
2010-07-01 17:17 ` Randy Dunlap
2010-07-01 18:02 ` Andi Kleen
2010-07-01 18:02 ` Andi Kleen
2010-07-01 18:02 ` Andi Kleen
2010-07-01 19:28 ` Daniel Walker
2010-07-01 19:28 ` Daniel Walker
2010-07-01 19:28 ` Daniel Walker
2010-07-01 19:38 ` Andi Kleen
2010-07-01 19:38 ` Andi Kleen
2010-07-01 19:38 ` Andi Kleen
2010-07-01 19:42 ` Daniel Walker
2010-07-01 19:42 ` Daniel Walker
2010-07-01 19:42 ` Daniel Walker
2010-07-01 22:15 ` Hari Kanigeri
2010-07-01 22:15 ` Hari Kanigeri
2010-07-01 22:15 ` Hari Kanigeri
2010-07-02 7:09 ` Zach Pfeffer
2010-07-02 7:09 ` Zach Pfeffer
2010-07-02 7:09 ` Zach Pfeffer
2010-07-10 14:36 ` Joerg Roedel
2010-07-10 14:36 ` Joerg Roedel
2010-07-10 14:36 ` Joerg Roedel
2010-07-13 5:21 ` Zach Pfeffer
2010-07-13 5:21 ` Zach Pfeffer
2010-07-13 5:21 ` Zach Pfeffer
2010-07-14 19:34 ` Joerg Roedel
2010-07-14 19:34 ` Joerg Roedel
2010-07-14 19:34 ` Joerg Roedel
2010-07-15 1:18 ` Zach Pfeffer
2010-07-15 1:18 ` Zach Pfeffer
2010-07-15 1:18 ` Zach Pfeffer
2010-07-01 22:00 ` Zach Pfeffer
2010-07-01 22:00 ` Zach Pfeffer
2010-07-01 22:00 ` Zach Pfeffer
2010-07-01 22:05 ` Daniel Walker
2010-07-01 22:05 ` Daniel Walker
2010-07-01 22:05 ` Daniel Walker
2010-07-02 7:33 ` Zach Pfeffer
2010-07-02 7:33 ` Zach Pfeffer
2010-07-02 7:33 ` Zach Pfeffer
2010-07-10 14:56 ` Joerg Roedel
2010-07-10 14:56 ` Joerg Roedel
2010-07-10 14:56 ` Joerg Roedel
2010-07-13 5:46 ` Zach Pfeffer
2010-07-13 5:46 ` Zach Pfeffer
2010-07-13 5:46 ` Zach Pfeffer
2010-07-13 5:59 ` FUJITA Tomonori
2010-07-13 5:59 ` FUJITA Tomonori
2010-07-13 5:59 ` FUJITA Tomonori
2010-07-13 8:20 ` Alan Cox
2010-07-13 8:20 ` Alan Cox
2010-07-13 8:20 ` Alan Cox
2010-07-13 8:30 ` FUJITA Tomonori
2010-07-13 8:30 ` FUJITA Tomonori
2010-07-13 8:30 ` FUJITA Tomonori
2010-07-13 8:42 ` Alan Cox
2010-07-13 8:42 ` Alan Cox
2010-07-13 8:42 ` Alan Cox
2010-07-13 8:45 ` FUJITA Tomonori
2010-07-13 8:45 ` FUJITA Tomonori
2010-07-13 8:45 ` FUJITA Tomonori
2010-07-13 9:02 ` Russell King - ARM Linux
2010-07-13 9:02 ` Russell King - ARM Linux
2010-07-13 9:02 ` Russell King - ARM Linux
2010-07-14 1:59 ` FUJITA Tomonori
2010-07-14 1:59 ` FUJITA Tomonori
2010-07-14 1:59 ` FUJITA Tomonori
2010-07-22 3:50 ` Zach Pfeffer
2010-07-22 3:50 ` Zach Pfeffer
2010-07-22 3:50 ` Zach Pfeffer
2010-07-22 4:47 ` FUJITA Tomonori
2010-07-22 4:47 ` FUJITA Tomonori
2010-07-22 4:47 ` FUJITA Tomonori
2010-07-22 16:33 ` Zach Pfeffer
2010-07-22 16:33 ` Zach Pfeffer
2010-07-22 16:33 ` Zach Pfeffer
2010-07-22 7:51 ` Russell King - ARM Linux
2010-07-22 7:51 ` Russell King - ARM Linux
2010-07-22 7:51 ` Russell King - ARM Linux
2010-07-22 16:13 ` Zach Pfeffer
2010-07-22 16:13 ` Zach Pfeffer
2010-07-22 16:13 ` Zach Pfeffer
2010-07-13 12:06 ` Zach Pfeffer
2010-07-13 12:06 ` Zach Pfeffer
2010-07-13 12:06 ` Zach Pfeffer
2010-07-01 22:51 ` Hari Kanigeri
2010-07-01 22:51 ` Hari Kanigeri
2010-07-01 22:51 ` Hari Kanigeri
2010-07-02 7:29 ` Zach Pfeffer
2010-07-02 7:29 ` Zach Pfeffer
2010-07-01 23:00 ` Andi Kleen
2010-07-01 23:00 ` Andi Kleen
2010-07-01 23:00 ` Andi Kleen
2010-07-02 6:17 ` Zach Pfeffer
2010-07-02 6:17 ` Zach Pfeffer
2010-07-02 6:17 ` Zach Pfeffer
2010-07-02 8:22 ` Andi Kleen
2010-07-02 8:22 ` Andi Kleen
2010-07-02 8:22 ` Andi Kleen
2010-07-02 18:42 ` Zach Pfeffer
2010-07-02 18:42 ` Zach Pfeffer
2010-07-02 18:42 ` Zach Pfeffer
2010-07-10 15:11 ` Joerg Roedel
2010-07-10 15:11 ` Joerg Roedel
2010-07-10 15:11 ` Joerg Roedel
2010-07-13 5:52 ` Zach Pfeffer
2010-07-13 5:52 ` Zach Pfeffer
2010-07-13 5:52 ` Zach Pfeffer
2010-07-03 6:36 ` Zach Pfeffer
2010-07-03 6:36 ` Zach Pfeffer
2010-07-10 14:54 ` Joerg Roedel
2010-07-10 14:54 ` Joerg Roedel
2010-07-10 14:54 ` Joerg Roedel
2010-07-13 5:27 ` Zach Pfeffer
2010-07-13 5:27 ` Zach Pfeffer
2010-07-13 5:27 ` Zach Pfeffer
2010-07-01 20:59 ` Paul Walmsley
2010-07-01 20:59 ` Paul Walmsley
2010-07-01 20:59 ` Paul Walmsley
2010-07-01 21:48 ` Randy Dunlap [this message]
2010-07-01 21:48 ` Randy Dunlap
2010-07-01 21:48 ` Randy Dunlap
2010-06-30 23:40 ` [RFC 1/3] mm: iommu: An API to unify IOMMU, CPU and device memory management Randy Dunlap
2010-06-30 23:40 ` Randy Dunlap
2010-06-30 23:40 ` Randy Dunlap
2010-07-01 7:16 ` Zach Pfeffer
2010-07-01 7:16 ` Zach Pfeffer
2010-07-01 7:16 ` Zach Pfeffer
2010-07-02 7:00 ` Paul Mundt
2010-07-02 7:00 ` Paul Mundt
2010-07-02 7:00 ` Paul Mundt
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=4C2D0D2D.8090407@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=andi@firstfloor.org \
--cc=dwalker@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-omap@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=paul@pwsan.com \
--cc=zpfeffer@codeaurora.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.