> One idea: how about covering new system calls? We have the thread calls
> Ingo did, the sched_[set|get]affinity calls, AIO, etc.
I've toyed with this idea, but wondered if perhaps a seperate
document would be a better idea. Ie, keep this one as a
end-users guide, and have a seperate programmers guide
covering things like API changes and the likes.
The latter would likely be more time consuming than the former,
we'll see how things go..
> > - Note, there are still cases where preemption must be temporarily disabled
> > where we do not. If you get "xxx exited with preempt count=n" messages
> > in syslog, don't panic, these are non fatal, but are somewhat unclean.
> I just want to clarify that, in the second point, the "xxx exited with
> preempt_count=n" message and not disabling preemption are two different
> issues.
Good point, that was confusing. Cleaned up.
> Not disabling preemption where needed is like an SMP race condition.
> There may be a some per-CPU data left that needs explicit protection but
> hopefully not much.
Wasn't there also some issue in various drivers ? I believe Alan cited
the 8390 net driver as one example.
> Just a note that the tree Rik and I are hacking on is the original and
> not a fork. It is the same tree mkj created and is in the official Red
> Hat CVS repository. It just has not had much activity lately and now it
> has new blood :)
>
> Albert's tree is a fork.
*sigh* politics. I changed that text after Albert mailed me complaining
about the original. Something tells me I'm not going to be able to
please both of you. I'll mangle it again, and see which one of you
complains next time 8-)
All other suggestions added/changed/etc.
Thanks for the feedback
Dave
-- | Dave Jones. http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/