[lkml]   [1998]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectShould raw I/O be added to the kernel?

    I'm not a kernel hacker, but have been following this discussion with
    some interest. This sounds like a clear philosophical distinction that
    has some merit. Why should raw I/O functionality be added to the kernel
    when device I/O can be better implemented in other functions of the OS?
    Many of us benefit from the fact that Linux is faster and more stable than
    other OS's which employ raw I/O.

    I am reminded of the catch-22 that results from loading products like
    Direct-X to a M$ environment. Enabling direct access to hardware often
    results in instability and system crashes, which anyone who loads the
    above product on a Windows 9x box can testify to after a program in
    userspace brings the whole system down, ad infinitum ad nauseum.

    We don't want to sacrifice the distinctions that make Linux better than
    other OS's for the sake of specific user needs; it makes sense to me that
    certain types of development may take longer [i.e. the development of an
    appropriate high-performance filesystem for Video I/O] but may be more
    successful than they would have been had raw I/O been introduced into the
    mainstream kernel. Then we would have applications crashing the system
    as currently happens with many other OS's.

    On Tue, 15 Dec 1998, Linus Torvalds wrote:

    > On Sat, 12 Dec 1998, Alan Cox wrote:
    > >
    > > Frame capture into a file is uninteresting for serious video people because
    > > a) we have this toy computer 2Gig file limit[1] and b) performance is a colossal
    > > issue. a) is easy to work around [apple worked around it nicely with Qt,
    > > intel forgot] b) is a problem. Video people really don't care about throwing
    > > an 80Gig FCAL array at a video problem. No file system who cares - saves fscking
    > Alan, let me clue you in: we're going to be living in the 21st century in
    > not too long.
    > We're going to have mom-and-pop users who want to capture their
    > grandchildren in HDTV on their computer from their camera. And yes, their
    > computers _are_ going to be able to handle it, and the 2G file limit won't
    > be there.
    > Anybody who seriously thinks that raw device access is worthwhile had
    > better think again. It's not. It's a special case thing that will never be
    > acceptable to any real target audience.
    > Right now you might be able to do it on current hardware only with raw
    > device access, but designing for it is a piece of shit design.
    > > We need memory locking for stuff like video capture DMA. The demonstration
    > > HDTV chipsets want capture to DMA 1600x1200x24bit data to memory targets.
    > > The existing bttv sick 'vmalloc and look the other way' approach isnt as
    > > good as locking pages for this (Disk I/O issues aside)
    > Umm.. That's what I said. You can lock down pages _easily_ in the page
    > cache. You just increment their usage count.
    > And that has absolutely NOTHING to do with raw device access. What you do
    > is you make "sendfile()" work for the "copy to page cache" case too.
    > Linus
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > Please read the FAQ at

    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:46    [W:0.022 / U:3.464 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site