Re: [RFC][PATCHv2] Fixing POSIX wait queue to insert in task priority order for real-time, including normal tasks

[Jonathan Haws <jhaws@sdl.usu.edu>]

> OK, when I said to Cc the kernel mailing list, I should have said
> that you
> also need to still Cc everyone you want to read it. LKML gets over
> 600+ emails
> a day. Nobody reads it all. Some people filter it, but others (like
> myself)
> stopped reading it because I can barely keep up with just the emails
> I'm Cc'd
> on.
> 
> The only reason I found this email is because I was going through my
> older
> email, noticed that I haven't seen another patch from you, and
> realized that
> you may have misunderstood what I meant by Ccing LKML. My fault for
> not being
> clear. Sorry about that.

Thanks for the update.  I was wondering if I messed something up when I
submitted this.  I realize this is a high-volume list and I have always
been curious how people stay on top of it.  It just makes sense to
direct specifics to the actual maintainers.

> To know who to Cc, use "scripts/get_maintainer.pl" on your patch. But
> since
> this is a RT issue, it is good to include the RT maintainers as well.

I didn't realize that script was there.  I'll make use of it!  As far
as RT maintainers go, I take it that is Thomas, Sebastian, and
yourself?


> Next, the subject should have a topic in it. If you look at other
> changes in
> the file you changed, you can usually figure it out. For example,
> looking at
> other changes in ipc/mqueue.c, I see "ipc: mqueue:" which you can add
> to you
> subject. That's because we want to know what commits are for what,
> when doing
> git logs, especially one liner log output.
> 
> The subject should be a bit shorter. It should try to stay under 76
> characters
> (subtracting the "[RFC][PATCH*]"). 

Just to make sure I'm following - you're looking for something along
the lines of:

[RFC][PATCH] ipc: mqueue: wq_add priority change to dynamic priority

> 
> Your subject is a little confusing. And you have zero change log. The
> subject
> can be what you are doing, but write a change log to describe why you
> are
> doing it. Don't be afraid to put in how you came about what you
> discovered. A
> year from now, when someone is looking at this code, and does a git
> blame to
> see why things are the way they are, it's good to know what the
> developer was
> thinking for why they made the change. That way, the code can be
> modified if
> circumstances change for why the code is the way it is. But without
> knowing
> why changes were done, new updates may not be made out of fear for
> breaking
> something they don't understand.
> 

Right - I'll shorten the subject as well and add a detailed change log.

Thanks for the tips!  You'll see PATCHv3 soon.



> On Tue, Dec 05, 2017 at 06:15:32PM -0700, Jonathan Haws wrote:
> > 
> > Signed-off-by: Jonathan Haws <jhaws@sdl.usu.edu>
> > ---
> >  ipc/mqueue.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> > index 9649ecd..cb96db9 100644
> > --- a/ipc/mqueue.c
> > +++ b/ipc/mqueue.c
> > @@ -546,7 +546,7 @@ static void wq_add(struct mqueue_inode_info
> > *info, int sr,
> >  	ewp->task = current;
> >  
> >  	list_for_each_entry(walk, &info->e_wait_q[sr].list, list)
> > {
> > -		if (walk->task->static_prio <= current-
> > >static_prio) {
> > +		if (walk->task->prio <= current->prio) {
> >  			list_add_tail(&ewp->list, &walk->list);
> >  			return;
> >  		}