[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.020 / U:24.768 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site