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 as
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
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 @@
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
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
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 stu
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 instruct
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 instruct
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
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 "SP
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 freebsd-c
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 =
> > > +
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 s
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
> g
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 commen
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 tech
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
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:
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
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 wo
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: bin
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
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) {
>
:...
:}
:
: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 w
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
actua
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 unle
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 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 brac
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, an
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
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
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) {
mum
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 pr
* 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 fir
:
: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
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
* 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 mo
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
: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
:ha
:
:> 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 gen
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 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
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.
> :>
> :>
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 ef
: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
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
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 th
Poul-Henning Kamp wrote:
> 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
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
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. Hopeful
50 matches
Mail list logo
