> It's certainly simpler and more intellectually satisfying to say that
> all of these issues should be completely handled in an "lower layer',
> but STREAMS made the same argument about networking, as you may recall.
Runtime performance is dependent on STREAMS. If adding in a new STREAMS
packet-filter-module-thing (or whatever you do with streams, I'm not sure)
cost big, but there was no performance probs while it was running, I don't
think anyone would have a problem with STREAMS. I was under the impression
that the drawbacks of STREAMS were the performance costs in everyday
runtime networking?
> Sometimes the most satisfying abstraction boundaries don't result in the
> most efficient and performant implementation.
Sadly, you are quite correct. I'd like to think that, here, though, we can
have the abstraction boundaries we want without sacrificing efficiency
anywhere that efficiency is important.
-Greg Mildenhall
-
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/