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

Powered by blists - more mailing lists