All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rajesh Venkatasubramanian <vrajesh@umich.edu>
To: Werner Almesberger <werner@almesberger.net>
Cc: linux-kernel@vger.kernel.org, kernel@kolivas.org
Subject: Re: [RFC] Generalized prio_tree, revisited
Date: Thu, 16 Dec 2004 10:04:20 -0500	[thread overview]
Message-ID: <41C1A3F4.2090707@umich.edu> (raw)
In-Reply-To: <20041216053118.M1229@almesberger.net>

Werner Almesberger wrote:
> and so on. So it seems to me that we're just at the level of
> abstraction that gives us the most narrow interface and that
> doesn't hide any information we need to implement the other
> cases. And it's just the "engine" that would be used in all
> cases anyway.

Yeah, makes sense. I think we can consider multi_prio_tree_node
later if many future users of prio_tree code need vma->shared.vm_set
like handling.

I am okay with the patch. I haven't tested it myself and I won't
have time to do so for next few days. Below are some small nitpicks.

>  struct prio_tree_node {
>  	struct prio_tree_node	*left;
>  	struct prio_tree_node	*right;
>  	struct prio_tree_node	*parent;
> +	unsigned long		start;
> +	unsigned long		end;
>  };

I wonder whether we should use [start, last] or [first, last] for
index names because "end" normally means last + 1, e.g., vm_end.
In prio_tree we store closed intervals of form [first, last] and
I think the name "last" makes it more explicit. Did I tell you
nitpicking ?

> +
> +struct prio_tree_node *prio_tree_replace(struct prio_tree_root *root, 
> +                struct prio_tree_node *old, struct prio_tree_node *node);

prio_tree_replace should be static in prio_tree.c.

> +struct prio_tree_node *prio_tree_first(struct prio_tree_iter *iter);

Should we go with prio_tree_iter_init and remove prio_tree_first
(similar to vma_prio_tree_next) ? I am not very particular about it,
though.

> +static void get_index(const struct prio_tree_root *root,

Should be "inline" ?

Thanks,
Rajesh

  parent reply	other threads:[~2004-12-16 15:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-16  8:31 [RFC] Generalized prio_tree, revisited Werner Almesberger
2004-12-16  9:02 ` Con Kolivas
2004-12-16  9:15   ` Werner Almesberger
2004-12-16  9:33     ` Con Kolivas
2004-12-16 13:23       ` Werner Almesberger
2004-12-16 11:12 ` Rajesh Venkatasubramanian
2004-12-16 13:57   ` Werner Almesberger
2004-12-16 15:04 ` Rajesh Venkatasubramanian [this message]
2004-12-16 19:38   ` Werner Almesberger
2004-12-16 20:01     ` Rajesh Venkatasubramanian
2004-12-17  4:44   ` Werner Almesberger

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=41C1A3F4.2090707@umich.edu \
    --to=vrajesh@umich.edu \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=werner@almesberger.net \
    /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.