[lkml]   [1999]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: Rio filesystem

On 22-Oct-99 Jeremy Fitzhardinge <> 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
>device, and isn't layered on the buffer cache. If you want to use the
>cache, then you can map the Rio blocks into cache pages in any way you

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?
>depends on what sort of accuracy you need, and what kinds of delays. If
>just a few microseconds here and there you can use udelay; if you need to
>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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:54    [W:0.069 / U:7.368 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site