[PATCH v2 3/5] rust: maple_tree: add MapleTree::lock() and load()

[Daniel Almeida]

Hi Liam,

[…]

>> 
>>> +    ///
>>> +    /// # Examples
>>> +    ///
>>> +    /// Iterate the maple tree.
>>> +    ///
>>> +    /// ```
>>> +    /// use kernel::maple_tree::{MapleTree, InsertErrorKind};
>>> +    /// use kernel::sync::Arc;
>>> +    ///
>>> +    /// let tree = KBox::pin_init(MapleTree::<Arc<i32>>::new(), GFP_KERNEL)?;
>>> +    ///
>>> +    /// let ten = Arc::new(10, GFP_KERNEL)?;
>>> +    /// let twenty = Arc::new(20, GFP_KERNEL)?;
>>> +    /// tree.insert(100, ten, GFP_KERNEL)?;
>>> +    /// tree.insert(200, twenty, GFP_KERNEL)?;
>>> +    ///
>>> +    /// let mut ma_lock = tree.lock();
>>> +    /// let mut iter = ma_lock.ma_state(0, usize::MAX);
>>> +    ///
>>> +    /// assert_eq!(*iter.mas_find(usize::MAX).unwrap(), 10);
>>> +    /// assert_eq!(*iter.mas_find(usize::MAX).unwrap(), 20);
>>> +    /// assert!(iter.mas_find(usize::MAX).is_none());
>>> +    /// # Ok::<_, Error>(())
>>> +    /// ```
>>> +    #[inline]
>>> +    pub fn mas_find(&mut self, max: usize) -> Option<T::BorrowedMut<'_>> {
>> 
>> Should we drop the “mas” prefix here? I think that “find()” is fine.
> 
> The maple tree has two interfaces, the advanced one which starts with
> mas_ and the simple on that uses mt_.  This is probably why the mas_ is
> here?
> 

Yeah but we should probably not expose this nomenclature directly in Rust, or
at least not in the function name itself. Perhaps we can implement the mt_* API
as a separate type, with its own find() function?

— Daniel