Messages in this thread | | | Date | Thu, 17 Sep 1998 00:55:17 -0500 | From | Mitchell Blank Jr <> | Subject | Re: STREAMS: interface versus implementation |
| |
Jamie Lokier wrote: > Albert, I see your point of view except I disagree with "severe". From > a technical viewpoint, let me explain why the overhead is negligible: [...] > if (!strcmp (name, "/dev/tcp")) [...] > if (fd < 0 || fd >= __streams_fd_table_size > || !__streams_fd_table [fd])
My personal feeling is that this would be gross. First it gives special meaning to the string "/dev/tcp"... what about "/dev//tcp" or "../../../dev/tcp" or a symlink pointing to "/dev/tcp". True, it's unlikely that you'll encounter a program screwed up enough to want to do that, but it's possible. The ioctl hack has a similar properties - the file descriptor now has a "magical" property that isn't preserved across a dup, exec, or being passed through a socket (although the dup case could be worked around using yet-more syscall kludging). Maybe this doesn't matter but I think its a hack.
I think what's being proposed here (a couple basic devices whose only function is a simple ioctl) is laughably trivial in the kernel. It's about as complicated as /dev/null. We have the framework (drivers/char/misc.c). They could even be a module (although I think they would waste most of their 1 page of memory) Having it in the kernel would at least make the device behave somewhat rationally.
> I'm not advocating any approach here,
Me neither. I'm not sure this whole STREAMS business is worth doing. There's a couple things that I like about STREAMS but they almost all would require a full-blown implementation (which is almost certainly a BAD idea)
-Mitch
- 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/
| |