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.

I may add that my concerns are more or less specific for mid- to high-speed local area networking.

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.

All the best
Peter




Reply via email to