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 majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
>
-
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/
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 majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
>
-
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/