lkml.org 
[lkml]   [1998]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: STREAMS: interface versus implementation
Date
>>> Just overload the ioctl symbol
>>
>> That stinks. While nobody expects STREAMS to be really fast,
>> they shouldn't add severe overhead to libc. That includes the
>> non-STREAMS part of an application that uses STREAMS.
>
> Tragedy.
>
> 1. Anyone who needed that performance wouldnt be using streams they'd
> be rewriting.

That's surely a great way to encourage Linux ports. Let's tell
all the app vendors that they must rewrite to get tolerable
performance on Linux.

> 2. It only affects anything linked with said streams library.

Yes, but it affects the whole application including normal file access.
If the overhead was really so low then we'd just change the normal
open() wrapper in libc.

> 3. The "severe overhead argument" is complete shit. You are
> adding
>
> if(*(u32 *)pathname='/dev')
>
> to most opens. 2 clocks at most with branch prediction in

I see an alignment trap too, but anyway...

The kernel version is free. We already have to handle device
operations and ioctls in the kernel. Libc would need an extra check,
while the kernel would not.

Lots of things don't _need_ to be in the kernel. We could get rid
of getcwd() and sendfile() without trouble, but we have them for
performance reasons. The device file and ioctls that were requested
would help STREAMS apps without messing up the network stack.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:2.696 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site