Richard Zidlicky writes:
> > > > # He can request a re-schedule simply by setting the sys_rshd system
> > > > # variable to $FF. This will then be checked every time an SMSQ trap
is
> > > > # invoked, which should normally happen very often. I think this
should
> > > > # be good enough for his problem.
> > >
> > > this may help, but usually only in situations where it isn't needed
> > > anyway. A similar effect could be achieved on all QDOS variants by
> > > setting sv.pollm, although this has slide sideeffects.
> > >
> > > I looked at js rom and it appears really trivial to fix properly
> > > so why some workaround that doesn't help?
> >
> > Could you please be more specific as to what sort of "fix" you have in
mind?
>
> look at the interrupt handling routine in jsrom (0x352-0x3a0).
> Instead of doing '0003A0 BRA L003B6' test for sys_rshd
> and conditionally branch to 0x936
> Or a lot easier to patch, branch to 0x3a6 and let the EISR
> manipulate sv.pollm.
Im not able to judge how well this would work, as there could be unforseen
consequences. It would require extensive testing to be sure. Since only a
specific effect is required in rather exceptional circumstances, wouldnt it
be better to handle that from the calling code instead? Marcel has refined
his suggestion as follows. I quote:
# By exiting the interrupt handler through the sms.rte function the
# requested re-schedule will be done immediately if possible (i.e. no
# supervisor code was running at that time). Example:
#
# include dev8_smsq_smsq_basekeys
# include dev8_keys_psf
#
# int_handler
# movem.l psf.reg,-(sp)
#
# [blah]
#
# st sys_rshd(a6) ; Request re-schedule
# move.l sms.rte,a5 ; ...now would be convenient
# jmp (a5)
This, I believe, produces the same result, but without any chance of side
effects.
In Qdos(JS) the functional equivalent might be something like
movem.l d7/a5-a6,-(sp)
....
clr.w sv.pollm(a6)
move.l L003a6,a5
jmp (a5)
Suitable code like this will give you all the 'states' you stipulate below.
> sys_rshd is not a bad idea, it might be usefull if it had some
> at least this states:
> - no action
> - run through poll tasks
> - run complete scheduler
>
> That would probably require the complete rewrite of all the 10 lines
> of scheduler in jsrom :)
Then why not go the whole hog and design a scheduler that will allow
time-critial "systems jobs" to run with "hard" priorities (while "user jobs"
get the remaining CPU cycles employing relative priorities, as before)?
Per
