Thanks for looking at it
This is not offtopic..
the answer is:
No, the code is correct..
here is the logic..
If there are N processors, then there are at most N KSEs (kernel
schedulable entities) working to process threads that belong to this
KSEGOUP. (kg). If there are N or more threads
Thank you very much.
After I sent previous question to you, I was still thinking the mail.
and last night when I went to bed, I suddenly found that I was wrong,
choosethread() selects a highest priority thread from queue, if it is
the lastest assigned thread, there is of course no more thread
Sorry for this OT, I found a point in kern_switch.c, when choosethread() runs,
you reset kg_last_assigned to NULL, I suspect it is incorrect, should it be:
--- kern_switch.c.orig Sun Jun 2 14:52:24 2002
+++ kern_switch.c Sun Jun 2 14:53:28 2002
@@ -67,7 +67,9 @@
Jake Burkholder wrote:
The system call stubs in libc are leaf functions; basically just a
trap instruction followed by a return. They do not touch the stack
at all, or change the stack pointer. One of the first few instructions
on entry to the kernel is a save, which rotates the register
Julian Elischer wrote:
interesting but not exactly brief.. :-)
Does brevity really matter?
You asked why. I gave a reference in the general class;
Jake gave a specific reference for the upcall issues he think
the code will face.
I think you have enough justification for Jake's position to
On Thu, 30 May 2002, Peter Wemm wrote:
Julian Elischer wrote:
On Thu, 30 May 2002, Jake Burkholder wrote:
[..]
It is much more difficult to ensure that all the register values
end up the same on each return from the system call on sparc64, due
to the way that register stack works.
Peter Wemm [EMAIL PROTECTED] writes:
If you want final commit approval/objections, you really need to either
include or go to developers@ instead since they're the ones dealing with
actual commit process.
s/developers/arch/
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe:
Dag-Erling Smorgrav wrote:
Peter Wemm [EMAIL PROTECTED] writes:
If you want final commit approval/objections, you really need to either
include or go to developers@ instead since they're the ones dealing with
actual commit process.
s/developers/arch/
I wasn't clear with this comment.
Peter Wemm [EMAIL PROTECTED] writes:
But he said he was asking for permission to commit it (Seeking OK to
commit KSE MIII-again), so he should be talking with other committers.
I guess I just don't see why he needs our permission, as long as he's
given us a chance to comment on the technical
On Thu, May 30, 2002 at 09:14:33PM +0200, Bernd Walter wrote:
On Thu, May 30, 2002 at 09:20:57AM -0700, Julian Elischer wrote:
ok, but does anyone other than john (who has commented) have any comments
about the logic and work in the change?
I'm working on his comments but comments by
On Fri, 31 May 2002, Bernd Walter wrote:
On Thu, May 30, 2002 at 09:14:33PM +0200, Bernd Walter wrote:
There are problems with the patchset:
fixed
This is code that translates the new states to old states for single
threaded processes so that 'ps' and friends can continue
to report a
Apparently, On Thu, May 30, 2002 at 06:56:30PM -0700,
Julian Elischer said words to the effect of;
+ /* Note: use of M_WAITOK means it won't fail. */
+ newkse-ke_pcb =
+ (((struct md_store *)(newkse-ke_mdstorage))-mds_pcb);
+ newkse-ke_frame =
+ (((struct md_store
Dag-Erling Smorgrav wrote:
Peter Wemm [EMAIL PROTECTED] writes:
But he said he was asking for permission to commit it (Seeking OK to
commit KSE MIII-again), so he should be talking with other committers.
I guess I just don't see why he needs our permission, as long as he's
given us a
On Fri, 31 May 2002, Jake Burkholder wrote:
[aweful stuff]
(always did dislike sparc)
jake..
can you show me the sequecne of operations performed on the stack
in a syscall before and after the jump to kernel space?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
Apparently, On Fri, May 31, 2002 at 01:45:50PM -0700,
Julian Elischer said words to the effect of;
On Fri, 31 May 2002, Jake Burkholder wrote:
[aweful stuff]
(always did dislike sparc)
Whatever. It's the most fun architecture I've found to program for.
jake..
can you show
interesting but not exactly brief.. :-)
On Fri, 31 May 2002, Jake Burkholder wrote:
The system call stubs in libc are leaf functions; basically just a
trap instruction followed by a return. They do not touch the stack
at all, or change the stack pointer. One of the first few
Apparently, On Fri, May 31, 2002 at 05:49:59PM -0700,
Julian Elischer said words to the effect of;
interesting but not exactly brief.. :-)
On Fri, 31 May 2002, Jake Burkholder wrote:
The system call stubs in libc are leaf functions; basically just a
trap instruction
On Fri, 31 May 2002, Jake Burkholder wrote:
Apparently, On Fri, May 31, 2002 at 05:49:59PM -0700,
Julian Elischer said words to the effect of;
interesting but not exactly brief.. :-)
On Fri, 31 May 2002, Jake Burkholder wrote:
The system call stubs in libc are
Matthew Dillon wrote:
But that is not what is going on here. Not by a long shot. We have
people on this list that complain over the smallest 'infraction' of the
rules, and then jump up the alleged significance of the event by
foretelling gloom and doom and the end of all
On Thu, May 30, 2002 at 12:43:22AM -0700, Terry Lambert wrote:
Hi,
Rules are what seperate us from the apes.
And even with them, some computer users still resemble them ;-)ยบ
Apes with Internet access, degrees in CS, a working knowledge of
CVS, an ability to code, mailing list access, and
On 29-May-2002 Matthew Dillon wrote:
:having said that,
:In this case the braces in question in ithread_schedule are:
:- } else
:+ } else {
:curthread-td_kse-ke_flags |= KEF_NEEDRESCHED;
:+ }
:
:I tend to always put braces on the
On Thu, May 30, 2002 at 09:20:57AM -0700, Julian Elischer wrote:
ok, but does anyone other than john (who has commented) have any comments
about the logic and work in the change?
I'm working on his comments but comments by others would sure be
appreciated..
especially if they actually
On Thu, 30 May 2002, Bernd Walter wrote:
Largely these need to be written by someone who is intimately aquainted
with the register set of the machine in question and knows
what registers need to be saved to restore a user context correctly.
I can do the alpha part tomorrow unless
Julian Elischer wrote:
ok, but does anyone other than john (who has commented) have any comments
about the logic and work in the change?
If you want final commit approval/objections, you really need to either
include or go to developers@ instead since they're the ones dealing with
actual
:...
:}
:
:Instead of:
:
:if (foo)
:{
:...
:}
:
:However, the real pain here is that basically people go and modify code
:they aren't even touching. If you are modifying the condition of an if()
:but not the body then the extra braces are just gratuitous. You did this
:when you
John Baldwin wrote:
This is your opinion not gospel truth. The reason I and others leave out
braces except when they are needed is to minimize the number of wasted
vertical space so that more code can fit on a screen at a time. This is
the same reason for using
if (foo) {
...
}
apparently, On Thu, May 30, 2002 at 09:20:57AM -0700,
Julian Elischer said words to the effect of;
ok, but does anyone other than john (who has commented) have any comments
about the logic and work in the change?
I'm working on his comments but comments by others would sure be
On Thu, 30 May 2002, Jake Burkholder wrote:
apparently, On Thu, May 30, 2002 at 09:20:57AM -0700,
Julian Elischer said words to the effect of;
Index: bin/ksetest/Makefile
===
Index:
Julian Elischer wrote:
On Thu, 30 May 2002, Jake Burkholder wrote:
[..]
It is much more difficult to ensure that all the register values
end up the same on each return from the system call on sparc64, due
to the way that register stack works. The current test program
will not work at
On 28-May-2002 Julian Elischer wrote:
Now things are moving again.
Jonathon Mini and I have cleaned up the patches a bit
and fixed the more obvious problems..
from teh point of view of non KSE processes
(that would be all of them at the moment) it shuold act the
same as now. Hopefully,
In message [EMAIL PROTECTED], John Baldwin writes:
+ frame = td-td_frame;
+ frame-tf_eax = retval; /* Child returns zero */
+ frame-tf_edx = aux;/* I dunno */
You could always ask about that instead of having a I dunno comment. :)
I think that we no longer
On Wed, 29 May 2002, John Baldwin wrote:
On 28-May-2002 Julian Elischer wrote:
Now things are moving again.
Jonathon Mini and I have cleaned up the patches a bit
and fixed the more obvious problems..
from teh point of view of non KSE processes
(that would be all of them at the
On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote:
9) More gratuitous braces as well as gratuituos ()'s and white space
changes in ithread_schedule() obfuscate the functional diffs.
I guess so though it made it a hell of a lot more readable to me.
That isn't the issue.
:On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote:
:
: 9) More gratuitous braces as well as gratuituos ()'s and white space
: changes in ithread_schedule() obfuscate the functional diffs.
:
: I guess so though it made it a hell of a lot more readable to me.
:
:That isn't
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
I agree that as a general rule of thumb it makes sense to commit
whitespace/paren/brace changes separately, but that is ALL it is.
A rule of thumb. It should not be followed blindly, on principle,
if it has an adverse effect
On Wed, May 29, 2002 at 01:07:01PM -0700, Matthew Dillon wrote:
:On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote:
:
: 9) More gratuitous braces as well as gratuituos ()'s and white space
: changes in ithread_schedule() obfuscate the functional diffs.
:
: I guess so
On Wed, 29 May 2002, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
I agree that as a general rule of thumb it makes sense to commit
whitespace/paren/brace changes separately, but that is ALL it is.
A rule of thumb. It should not be followed
On Wed, 29 May 2002, Matthew Dillon wrote:
I agree that as a general rule of thumb it makes sense to commit
whitespace/paren/brace changes separately, but that is ALL it is.
A rule of thumb. It should not be followed blindly, on principle,
if it has an adverse effect on
:
: Furthermore, it is an extreme and inappropriate imposition on Julian
: to require that he extract all the alleged 'gratuitous braces and
: ()'s)' into a separate commit.
:
:Uh, no it isn't. That is the rules we operate under. This type of
:request comes up _daily_, and is
:having said that,
:In this case the braces in question in ithread_schedule are:
:- } else
:+ } else {
:curthread-td_kse-ke_flags |= KEF_NEEDRESCHED;
:+ }
:
:I tend to always put braces on the else clause if the 'then' clause
:has
Ok I just committed that one on it's own
now back to the real points that jhb raised..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
* From Matthew Dillon [EMAIL PROTECTED]
No hold on a minute. Some of us believe that adding those extra
braces and parenthesis makes the code a whole lot more readable. they
are NOT gratuitous in the least, certainly not from my point of view!
When you make the code more
On Wed, 29 May 2002, Julian Elischer wrote:
On Wed, 29 May 2002, John Baldwin wrote:
4) It would be nice if you didn't mix in gratuitous style changes with
actual content changes such as extra braces in else clause of
PROCFS_CTRL_WAIT case in procfs_ctl.c
I
:
:When you make the code more readable, you introduce further diffs, and you
:leave no reference against the original code of where the functional changes
:are. Either make the base code cleaned up by committing non-functional
:changes first, or commit against the base code your functional
* From Matthew Dillon [EMAIL PROTECTED]
:
:When you make the code more readable, you introduce further diffs, and you
:leave no reference against the original code of where the functional changes
:are. Either make the base code cleaned up by committing non-functional
:changes first, or
Julian Elischer wrote:
On Wed, 29 May 2002, Julian Elischer wrote:
On Wed, 29 May 2002, John Baldwin wrote:
4) It would be nice if you didn't mix in gratuitous style changes with
actual content changes such as extra braces in else clause of
PROCFS_CTRL_WAIT case in procfs_ctl.c
On Wed, 29 May 2002, Peter Wemm wrote:
ie: it is ok to change this:
if (foo) {
fumble();
futz();
} else
bah;
into
} else {
bah;
}
In this case it's moot because I already did it as a separate commit
but it was changing:
if (foo) {
mumble();
When it comes right down to it, I am getting wholely sick and tired
of people acting like rulez-police and complaining about the most
minor, most insignificant syntactical changes imagineable. The
rest of us developers have better things to do with their time then
to spend it
48 matches
Mail list logo
