From: Oleg Nesterov <oleg@tv-sign.ru>
To: Daniel Walker <dwalker@mvista.com>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Subject: Re: [PATCH rc5-rt2 3/3] plist: convert the code to newimplementation
Date: Mon, 19 Dec 2005 22:19:43 +0300 [thread overview]
Message-ID: <43A707CF.F27868E6@tv-sign.ru> (raw)
In-Reply-To: <1135012399.30466.13.camel@localhost.localdomain>
Daniel Walker wrote:
>
> I think firstly, if you want to have success with this patch you'll need
> to clean it up a bit. I'm not an authority on clean code , but below
> isn't clean to my eyes.
Cleanups are always good, I am open to any suggestions.
> However, this is cleaner than your last
> attempt .
Thanks, but it was NOT changed from my last attempt. Just rediff.
> Hard coding MAX_PRIO isn't really acceptable.
I don't do that? Could you clarify?
> If your going to make it
> more similar to list_head , why not name it plist_head instead of
> pl_head that way it's easy to switch between them.
I don't mind to rename, probably plist_head is better. I'd like to know
Ingo's opinion first.
> Like you
> remove a lot of the API which makes it less similar to a regular list .
For example?
> Also, making any changes to the internals of the plist structure outside
> of plist.c (or similar) isn't acceptable. For instance you set the node
> priority in several places, that should be hidden inside another
> function or macro. That makes it easier for people to change the
> internal structure without treading though tons of code.
Agreed, I already thought it makes sense to add plist_add_prio() helper.
Note that ->prio is set directly mostly right before plist_add() call.
> Changing plist_empty() doesn't make any sense to me.
plist_empty(head) means this list empty. plist_unhashed(node) means
this node is not on list.
> Also changing
> dp_node to prio_list doesn't make much sense either.
Again, this patch is unchanged. I don't mind to rename, but recall
that it was sent before the current implementation become functional.
And honestly I don't like 'sp_node', this name is misleading, and
reflects first buggy implementation. It should be called 'all_nodes'
or something like this.
Oleg.
prev parent reply other threads:[~2005-12-19 18:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-18 18:17 [PATCH rc5-rt2 3/3] plist: convert the code to new implementation Oleg Nesterov
2005-12-19 17:13 ` Daniel Walker
2005-12-19 19:19 ` Oleg Nesterov [this message]
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=43A707CF.F27868E6@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=dwalker@mvista.com \
--cc=inaky.perez-gonzalez@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
/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
all inboxes | Powered by JetHome®