Re: SVR4 STREAMS (for example LiS)

Re: SVR4 STREAMS (for example LiS)

[Ihar "Philips" Filipau]

Ihar "Philips" Filipau wrote:
> 
>    On behalf of conclusion I would summarize:

     Bad me.
     Found thru Google quite interesting paper on LiS site:

     http://www.gcom.com/home/products/why_streams.html

     Little bit of history with final emphasis on networking.

     Just to finally close the topic.

Re: SVR4 STREAMS (for example LiS)

[Bernd Eckenfels]

In article <3F1CE6B6.4020909@softhome.net> you wrote:
> [1] <blatant rant on>I absolutely do not need to use 64GB of memory - 
> but kernel includes HIGH_MEM support.

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
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: SVR4 STREAMS (for example LiS)

[Ihar "Philips" Filipau]

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... ;-)

Re: SVR4 STREAMS (for example LiS)

[Luciano Miguel Ferreira Rocha]

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.

Regards,
Luciano Rocha

Re: SVR4 STREAMS (for example LiS)

[Richard B. Johnson]

On Mon, 21 Jul 2003, Ihar "Philips" Filipau wrote:

> Hello All!
>
>     I have little bit theoretical question. As usual ;-)
>
>     From what ever piece of doc I see says that STREAMS are good.
>     They are part of SUS (at least v3 has them).
>     Sun's docs reffering only cases when one may want to use them.
>     This was the first pointer to problems: docs are missing the
>        "dark side" of STREAMS.
>
>     Can anyone give any pointers to information why STREAMS are _not_
>        part of Linux kernel yet?
>     (Besides that no-one needs/merged it in kernel ;-)
>     What kind of problems this implementation of I/O has?
>     (Low performance and high latencies I expect - but what's else?)
>
>     Any sort of RTFM will be very appreciated.
>
>     Thanks in advance.
>

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.

That said, the kernel provides getpmsg and putpmsg functions
to support streams. You really can't do much more for streams
inside the kernel and be efficient.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

SVR4 STREAMS (for example LiS)

[Ihar "Philips" Filipau]

Hello All!

    I have little bit theoretical question. As usual ;-)

    From what ever piece of doc I see says that STREAMS are good.
    They are part of SUS (at least v3 has them).
    Sun's docs reffering only cases when one may want to use them.
    This was the first pointer to problems: docs are missing the
       "dark side" of STREAMS.

    Can anyone give any pointers to information why STREAMS are _not_
       part of Linux kernel yet?
    (Besides that no-one needs/merged it in kernel ;-)
    What kind of problems this implementation of I/O has?
    (Low performance and high latencies I expect - but what's else?)

    Any sort of RTFM will be very appreciated.

    Thanks in advance.