??? 3/1/2003 9:49:10 ??, ?/? Peter Graf <[EMAIL PROTECTED]> ??????: <snio> >I see only two possible solutions for QDOS/SMS: > >(1) A higher rate for the frame intterrupt (disadvantage: higher system load) >
This would be feasible I think without too much problems for the system. <snip> I always believed that the way I/O is implemented might have been good for extremely slow peripheral devices and with media that wasn't exactly reliable (ie making sure that SuperBasic for example did actually save the changes before you could return control to it) but for today's requirements it is totally obsolete. On the other hand and IIRC IOSS in itself is a different scheduler that could be tuned without resorting to drasting measures (ie overhauling the whole system). Please note that drivers (according to everything I have read) do not *NECESSARILY* have to get into Supervisor mode to go about their business(sic!), it's just "strongly advised" (I quote from Adrian Dickens) that they should do so. >Do you see what I mean? A simple job can cause *immediate* job >re-scheduling. A properly implemented device driver can not (as it seems). See above... A properly implemented device driver can be in fact be a simple job (or have I got it all wrong) if the writer chose to, it's just a lot simpler if you don't implement it that way because after that you have to cater for all sorts of possibilities. The "correct" implementation according to my VERY HUMBLE opinion would be to implement the IOSS as a set of two jobs. One vectrored routine (along the lines of what we have now (which would also ensure compatibility)) which would then start the actual scheduler AND driver. According to the type of driver that would be invoked that would close later if it wasn't needed or -in the case of a say ethernet packet driver- keep on working... something like the DETACH command in OS/2 (remember that one?). You set it and forget it in other words... The separate IO scheduler then (for drivers/jobs that were still in use) could be tuned to our desired response..... (Or something like that in general). In theory we could have two or three or more IOSS's running at the same time, all invoked from the same vectored routine which would only serve as an entry point. (Not many, many more of course as that would introduce other problems...) Maybe I got it all wrong myself.... I don't know we're just brainstorming here :-) Phoebus
