Newsgroups: comp.arch Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: virtual I/O Message-ID: <1988May12.164906.17159@utzoo.uucp> Organization: U of Toronto Zoology References: <1605@pt.cs.cmu.edu> <28200142@urbsdc>, <3033@encore.UUCP> Date: Thu, 12 May 88 16:49:06 GMT >Which brings up the question, why don't we do IO with virtual addresses? >We have living proof that it can be done. Why isn't it catching on? Depends on what you mean by "catching on". All Suns do IO with virtual addresses -- there is no way to bypass the Sun MMU. (Actually, I should hedge that: I know this applies to the Sun 3, but I might be wrong about the others.) > ... For a device that can potentially > support concurrent traffic for more than one process, you need an MMU for > each thread of control, and suddenly you have an allocation problem. No, you just give the IO its own address space, and map pieces of the user spaces into it. I agree it's a bit less elegant than just handing the IO device the whole user space. > The other thing that consistently gets in the way is that IO has this tendency > to require deterministic delays so various buffers don't overrun and the like. > MMUs dont lend themselves well to that. Some MMUs don't. Some do. Some of the ones that don't can be made to give deterministic delays if the software makes a real effort. > IO also doesn't know what to do with a fault. So you have to make sure it doesn't get any. Again, a nuisance for the software, but not a disaster. -- NASA is to spaceflight as | Henry Spencer @ U of Toronto Zoology the Post Office is to mail. | {ihnp4,decvax,uunet!mnetor}!utzoo!henry