linux-kernel - Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 01 Jul 2010 14:48:29 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Paul Walmsley <paul@...an.com>
CC:	Zach Pfeffer <zpfeffer@...eaurora.org>, mel@....ul.ie,
	andi@...stfloor.org, dwalker@...eaurora.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/