Messages in this thread | | | Subject | RE: Rio filesystem | From | Steven_Hazel@trilogy ... | Date | Fri, 22 Oct 1999 14:56:04 -0500 |
| |
On 22-Oct-99 Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>The block device layer certainly likes to talk to devices with 2^n blocks >sizes, but you shouldn't need to worry about that. If you're writing a >filesystem interface for the Rio, then it should be an NFS-like filesystem >rather than a ext2-like filesystem; that is, it isn't associated with a block >device, and isn't layered on the buffer cache. If you want to use the page >cache, then you can map the Rio blocks into cache pages in any way you like.
So you're saying the best way to handle this is to just do direct hardware access from within the filesystem code? My biggest practical problem with this is that it would require a version of mount which knows how to pass it the appropriate parallel port info.
>What sort of stuff? Do you mean fiddling with printer port control bits? It >depends on what sort of accuracy you need, and what kinds of delays. If its >just a few microseconds here and there you can use udelay; if you need to do >things like "wait at least 2ms" then you can use a blocking sleep.
Yeah, I need to just pause for a few milliseconds between parallel port control operations. I've been (ab)using udelay, which has the disadvantages that my delay times vary unacceptably much from system to system and that it locks the system for frequent milliseconds-in-length intervals during file transfers, which isn't acceptable. Blocking sleep definitely sounds like the right way to go -- any idea where I can find info on linux's provisions for doing this?
-S
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |