??? 3/1/2003 12:58:02 ??, ?/? Peter Graf <[EMAIL PROTECTED]> ??????:
> >Phoebus wrote: > >><snip> >>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 problem in using jobs for handling hardware devices is that a job can >never react to asynchronous hardware events unless it is polling, i.e. >consuming CPU resources. Not necessary if you assume intelligent (ie with their own CPU) peripherals. In the case of a Network card of course that would mean that a special Qx0 card should be designed and/or that in the case of going to a different IO bus (ie PCI) in the future we would be back to square one. Therefore the ONLY other possibilities I see is to update the main scheduler to allow custom timings or some form of independent hardware buffering for devices (to cater for that loss of control while the scheduler moves execution to a different job). Other possible (and exotic) alternatives would be dual processors (and scheduling) etc... >I may add that my concerns are more or less specific for mid- to high-speed >local area networking. Buffering can still be used in a high-speed LAN but what are the limitations on speed anyway? I doubt it that the ISA bus can do the "theoretical" 100Mbit (like my intel card uses). IIRC in the case of the iNTEL Etherexpress, the card buffers input and output packets and then burst-sends them out/in so no loss of frame sync happens. > >Drivers for (hard) disks drives, printers and such can deal with their >performance challenges by buffering and can be implemented efficient enough >using the given OS facilities. Drivers for duplex serial port connections >are also not much affected, because a medium response time of 10 msec is >still in the same range as the time needed to tranfer a small amount of data. > >Note that the specific thing about (ether)networking is that reading the >data is not triggered from inside the system (like e.g. a software request >for data from harddisk), but absolutely asynchronous and unpredictable from >outside. And that's why IIRC even Windows is polling its devices... and also why they were finally able to use more devices / interrupt (which aren't really used anymore)... and also why "Legacy" devices are always so much more responsive from polled ones. maybe a third type of device driver should be devised... one that can act as block or directory, but which is strictly polled. In any case just one device driver of that type wouldn't put such a load on the system (especially if the code for it is written to take advantage of the 040 and 060 high performance extra instructions Phoebus
