linux-kernel - Re: XArray documentation

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 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:   Fri, 24 Nov 2017 23:02:41 +0100
From:   Martin Steigerwald <martin@...htvoll.de>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Matthew Wilcox <mawilcox@...rosoft.com>
Subject: Re: XArray documentation

Matthew Wilcox - 24.11.17, 22:18:
> On Fri, Nov 24, 2017 at 07:01:31PM +0100, Martin Steigerwald wrote:
> > > The XArray is an abstract data type which behaves like an infinitely
> > > large array of pointers.  The index into the array is an unsigned long.
> > > A freshly-initialised XArray contains a NULL pointer at every index.
> > 
> > Yes, I think this is clearer already.
> > 
> > Maybe with a few sentences on "Why does the kernel provide this?", "Where
> > is it used?" (if already known), "What use case is it suitable for – if I
> > want to implement something into the kernel (or in user space?) ?" and
> > probably "How does it differ from user data structures the kernel
> > provides?"
> 
> OK, I think this is getting more useful.  Here's what I currently have:
> 
> Overview
> ========
> 
> The XArray is an abstract data type which behaves like a very large array
> of pointers.  It meets many of the same needs as a hash or a conventional
> resizable array.  Unlike a hash, it allows you to sensibly go to the
> next or previous entry in a cache-efficient manner.  In contrast to
> a resizable array, there is no need for copying data or changing MMU
> mappings in order to grow the array.  It is more memory-efficient,
> parallelisable and cache friendly than a doubly-linked list.  It takes
> advantage of RCU to perform lookups without locking.

I like this.

I bet I may not be able help much further with it other than to possibly 
proofread it tomorrow.

Thank you for considering my suggestion.

-- 
Martin