public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox