>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/