SVR4 STREAMS (for example LiS)
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 17 lines · Luciano Miguel Ferreira Rocha
Quoted 4 lines · Richard B. Johnson
Streams are an extension of buffered I/O implimented by the 'C' runtime library. Streams really have nothing to do with the internal workings of kernel I/O. As far as kernel I/O goes, one
reads()andwrites()from user-space.Actually, SysV Streams do.
An ex, for openning a pty, on svr4:
fds =open(pts_name, O_RDWR)ioctl(fds, I_PUSH, "ptem")ioctl(fds, I_PUSH, "ldterm")ioctl(fds, I_PUSH, "ttcompat")Where ptem, ldterm, ttcompat work as independent modules converting the stream, resulting in a pseudo-terminal implementation.
Quoted 9 lines
New programs should just use openpty directly, and let libc take care of the actual implementation.
Also, BSD sockets were implemented using streams also, thus the compatibility libraries.
Anyway, I see no point in caring wether streams are used or not in normal programs.
Not every one has normal programmes and normal needs [1]. Use of STREAMS allows you easily build up your own network protocol
stack for example.
Sun's autopush(1M) looks really cool.
http://docs.sun.com/db/doc/805-3173/6j31cplrg?a=view
Configure special device and just feed it your programme. Not more - not less.
As of me I see not that much uses of STREAMS somewhere outside of
terminal conversions and network stack manipulations. And some rare (but
nasty indeed) occasions of stupid binary programmes, which happend to
be used and happend to need something special.
On behalf of conclusion I would summarize: STREAMS are Ok, but
potentially slow and hard to configure (I can easily imagine situation when app trying to manipulate already prepared by admin stream /something like this).
[1] <blatant rant on>I absolutely do not need to use 64GB of memory - but kernel includes HIGH_MEM support. Is it normal for 32bit PC to have that much memory? *No*. Do you run any normal programme which does need 64GB of memory? I bet *No*.<blatant rant off> There are a lot of examples of _not_ normal features - read "bloat" - in kernel. And I'm not talking about user-land... ;-)
Quoted 2 lines · In article <[email protected]> you wrote:
[1] <blatant rant on>I absolutely do not need to use 64GB of memory - but kernel includes
HIGH_MEMsupport.
of course if you do not enable HIGH_MEM support your 2.4 kernel will only allow 960MB of main memory, so I dont think this is bloat and unneeded.
Greetings
Bernd
Signature · 2 lines
eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/