Re: Seeking OK to commit KSE MIII

2002-06-03 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII

2002-06-03 Thread David Xu
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

Re: Seeking OK to commit KSE MIII

2002-06-02 Thread David Xu
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 @@

Re: Seeking OK to commit KSE MIII-again

2002-06-01 Thread Terry Lambert
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

Re: Seeking OK to commit KSE MIII-again

2002-06-01 Thread Terry Lambert
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

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Julian Elischer
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.

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Dag-Erling Smorgrav
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:

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Peter Wemm
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.

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Dag-Erling Smorgrav
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

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Bernd Walter
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

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Jake Burkholder
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

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Peter Wemm
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

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Terry Lambert
Julian Elischer wrote: 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? It's not that awful. Read the paper SPARC

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Jake Burkholder
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

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Jake Burkholder
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

Re: Seeking OK to commit KSE MIII-again

2002-05-31 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII

2002-05-30 Thread Terry Lambert
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

Re: Seeking OK to commit KSE MIII

2002-05-30 Thread Miguel Mendez
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

Re: Seeking OK to commit KSE MIII

2002-05-30 Thread John Baldwin
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

Re: Seeking OK to commit KSE MIII-again

2002-05-30 Thread Bernd Walter
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

Re: Seeking OK to commit KSE MIII-again

2002-05-30 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII-again

2002-05-30 Thread Peter Wemm
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

Re: Seeking OK to commit KSE MIII

2002-05-30 Thread Matthew Dillon
:... :} : :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

Re: Seeking OK to commit KSE MIII

2002-05-30 Thread Terry Lambert
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) { ... }

Re: Seeking OK to commit KSE MIII-again

2002-05-30 Thread Jake Burkholder
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

Re: Seeking OK to commit KSE MIII-again

2002-05-30 Thread Julian Elischer
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:

Re: Seeking OK to commit KSE MIII-again

2002-05-30 Thread Peter Wemm
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

RE: Seeking OK to commit KSE MIII

2002-05-29 Thread John Baldwin
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,

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Poul-Henning Kamp
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

RE: Seeking OK to commit KSE MIII

2002-05-29 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread David O'Brien
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.

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Matthew Dillon
: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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Poul-Henning Kamp
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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread David O'Brien
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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Matthew Dillon
: : 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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Matthew Dillon
: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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread J. Mallett
* 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

RE: Seeking OK to commit KSE MIII

2002-05-29 Thread Julian Elischer
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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Matthew Dillon
: :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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread J. Mallett
* 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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Peter Wemm
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

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Julian Elischer
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();

Re: Seeking OK to commit KSE MIII

2002-05-29 Thread Matthew Dillon
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