From: "Ihar \"Philips\" Filipau" <filia@softhome.net>
To: linux-kernel@vger.kernel.org
Cc: luciano@lsd.di.uminho.pt, root@chaos.analogic.com
Subject: Re: SVR4 STREAMS (for example LiS)
Date: Tue, 22 Jul 2003 09:24:38 +0200 [thread overview]
Message-ID: <3F1CE6B6.4020909@softhome.net> (raw)
In-Reply-To: <bKj0.2yr.3@gated-at.bofh.it>
Luciano Miguel Ferreira Rocha wrote:
> On Mon, Jul 21, 2003 at 10:38:38AM -0400, Richard B. Johnson wrote:
>>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() and writes() 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.
>
> 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... ;-)
next parent reply other threads:[~2003-07-22 7:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bJGh.25l.15@gated-at.bofh.it>
[not found] ` <bJZH.2jj.29@gated-at.bofh.it>
[not found] ` <bKj0.2yr.3@gated-at.bofh.it>
2003-07-22 7:24 ` Ihar "Philips" Filipau [this message]
2003-07-22 8:29 ` SVR4 STREAMS (for example LiS) Bernd Eckenfels
[not found] <bZLc.6Xx.19@gated-at.bofh.it>
[not found] ` <bZLc.6Xx.21@gated-at.bofh.it>
[not found] ` <bZLc.6Xx.23@gated-at.bofh.it>
[not found] ` <bZLc.6Xx.17@gated-at.bofh.it>
2003-07-22 12:44 ` Ihar "Philips" Filipau
2003-07-21 14:13 Ihar "Philips" Filipau
2003-07-21 14:38 ` Richard B. Johnson
2003-07-21 14:50 ` Luciano Miguel Ferreira Rocha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F1CE6B6.4020909@softhome.net \
--to=filia@softhome.net \
--cc=linux-kernel@vger.kernel.org \
--cc=luciano@lsd.di.uminho.pt \
--cc=root@chaos.analogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).