3

The POSIX.1-2008 XRAT rationale states that X/Open STREAMS may be removed from future versions of the standard, and that strictly conforming applications shouldn't use them, but it doesn't explain why.

Why were they effectively removed from the standard?

Did they fall outside the scope of POSIX? Are there flaws with implementing device drivers this way? I find STREAMS interesting; I like the idea of implementing device drivers in layers.

sourcejedi
  • 48,311
  • 17
  • 143
  • 296
osvein
  • 199
  • 3
  • 14

2 Answers2

2

Well STREAMS does include an API. Surely they'd be in scope for standardization if the concept was adopted widely, used by portable applications etc.

The lore from the mouths of Linux hackers is that STREAMS was dead by 1994, and only remained in existence for backwards compatibility. (Of the API).

https://lkml.org/lkml/1998/6/28/138

It was originally designed to cover networking as well (cite: Wikipedia). Apparently it was an obstacle to networking performance back in the days of 100M/1G servers... nowadays we have 10G+...

People say Linux networking is still slow (trying to push userspace bypasses like DPDK). So I'm glad we have a network stack that isn't forced into the STREAMS model.

I'm not familiar with STREAMS but the other half of the original design was terminal IO. At least w.r.t. Linux, you could say that's kind of old, we have an interface that does what we need, and coding extra features is just going to cause unnecessary breakages to deal with. You can already switch the intermediate processing with line disciplines, albeit this appears to divert data to another subsystem rather than providing a swappable filter. E.g. one of the disciplines (PPP) creates a network interface - which is completely different from a device node. Even when the result is a device node, it seems pretty clean to announce it as a new device of a given type to the udev hotplug device manager. E.g. applying the serial mouse discipline will create a new input device, which will be picked up by X through the exact same mechanism as plugging a USB mouse.

sourcejedi
  • 48,311
  • 17
  • 143
  • 296
  • What makes STREAMS so slow? (I take it the performance concern is about speed. Or is it about memory too?) – osvein Jul 16 '16 at 21:54
  • Hmm. I get the impression the STREAMS design is about message-passing between processes, as you would use in a micro-kernel. Linux kernel typically can't be described that way. It favors function calls within a single thread... and whatever techniques it takes to address significant performance bottlenecks, human comprehension be damned :). Note, even Solaris ended up smushing together the TCP and IP modules, removing the internal STREAMS for performance reasons. https://blogs.oracle.com/sunay/entry/solaris_networking_the_magic_revealed – sourcejedi Jul 17 '16 at 12:41
  • I can't find much specifics unfortunately. Then what you're left with is a different syscall interface for networking - when BSD sockets got there first - and the System V refactor of terminal IO that you like. I just think there wasn't as much interest / new activity in that area, whereas networking was becoming very exciting commercially. (Another interpretation, but likely from similar sources: http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch07s03.html) – sourcejedi Jul 17 '16 at 12:57
0

STREAMS is a nice api from a userspace programmer's point of view, but it is a horror from the kernel side. It cannot be implemented in any way that is remotely performant.

Systems which have implemented STREAMS have moved away from it years ago for that reason. POSIX just documents the current state of affairs.

Wouter Verhelst
  • 9,171
  • 18
  • 43