Messages in this thread | | | Date | Tue, 15 Dec 1998 20:17:03 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: PATCH: Raw device IO for 2.1.131 |
| |
On Mon, 14 Dec 1998, Stephen C. Tweedie wrote: > > The advantage of a read/write() O_DIRECT API is that it works > immediately, even if we go through the page cache (assuming only that we > can write through the page cache, and that is really not hard to do).
The disadvantage I see, though, is fairly basic: - it's generic as hell
Generic code is good. However, if we're talking performance (and we are), then generic _interfaces_ are bad. They are also bad if we're talking about maintaining them forever, because the very concept of "generic" means that it works on everything. Which means that whenever somebody does something new, it has to support the generic interface.
The issue of shared pages has already been discussed. It comes up every time anybody looks into using page mapping or other "direct" access to the data as opposed to just copying it into a private buffer. The other issue that tends to come up (depending on what people want to do) is alignment.
This is kind of the same issue as "splice()", which Larry McVoy brings up every once in a while, for good reason. "splice()" is this generic IO thing, and it's cool. It's just that when I actually thought about how to implement it well and efficiently, my head started hurting, and my private areas started to itch (*).
As opposed to something very _specific_ like sendfile() which took me half a day to write and basically just worked.
So basically, unless you can show that you _need_ the generality, I'd much much more prefer to have a more limited and specific interface. The advantage is that a limited interface can always be implemented on top of the generic one if it later turns out to be necessary - while the reverse is not true.
Linus
(*) The latter could be unrelated. But I'm blaming Larry.
- 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/
| |