--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Matt,

On Tue, Sep 19, 2006 at 07:53:30AM -0700, Matt Thomas wrote:
>=20
> kern_synch.c should not have a cpu_idle() implementation since that's
> MD code.  You don't seem to deal with __HAVE_BIGENDIAN_BITOPS.

Mmh, forgive me my blindness, but I don't really see were cpu_idle()
uses MD code. Can you give me a hint what I'm missing?

> I'd rather cpu_idle() do the looping.

Agreed. IIRC, gmcgarry did something similar in his chooseproc()
function. I'll change that.

> Shouldn't cpu_idle() also unset curlwp?  If so, I'm not sure I like
> returning back to the scheduler on a idle stack with no curlwp.

Yes, you are right. cpu_switch() does the same.

> Instead cpu_idle() should I think we should add a member to cpu_info
> which indicates cpu_idle should continue to loop.  When nonzero, it
> represents that there may be a new lwp to be run.
>=20
> void cpu_idle(struct lwp (*getnext)()) __attribute__((__noreturn__));
>=20
> cpu_idle would call back its first argument to get the next lwp to
> run.  When it returns new lwp, it will have already been removed
> from the runqueue.

Sounds reasonable to me.

> cpu_switch should die; either we call cpu_switchto or cpu_idle.

Yes, indeed.

Ok, I'll try to implement your suggestions. Thanks a lot for your
comments.

Regards,
Daniel

--=20
Daniel Sieger  =20
Faculty of Technology
Bielefeld University

--RnlQjJ0d97Da+TV1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (SunOS)

iD8DBQFFEEHCJUKmeYzbnToRAomlAJ9mvUNXGxsKoSCCQOBoPGAfZqmayQCgiSqa
k7ud5wL0F2ziCSr3wUPct1c=
=AF60
-----END PGP SIGNATURE-----

--RnlQjJ0d97Da+TV1--