From: m...@rola.ch (Furter Martin)
Subject: getmsg & putmsg
Date: 1998/05/13
Message-ID: <Pine.LNX.3.96.980513124126.632D-100000@gateway.rola.ch>#1/1
X-Deja-AN: 352841782
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
I'm porting our software to Linux. We are useing the functions getpmsg and
putpmsg on the SINIX system. We need the bands for priority messages.
Is there a way to do the same on Linux ?
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: a...@bfr.co.il (Alexander L. Belikoff)
Subject: Re: getmsg & putmsg
Date: 1998/05/13
Message-ID: <m31ztyo1t8.fsf@vermis.bfr.co.il>#1/1
X-Deja-AN: 352851738
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980513124126.632D-100000@gateway.rola.ch>
Newsgroups: muc.lists.linux-kernel
Furter Martin <m...@rola.ch> writes:
>
>
> I'm porting our software to Linux. We are useing the functions getpmsg and
> putpmsg on the SINIX system. We need the bands for priority messages.
> Is there a way to do the same on Linux ?
>
Get-/putmsg() come from STREAMS interface. There is no STREAMS in the
official Linux kernel. Still, there are following options available:
1. If you need "full" STREAMS framework, not just those functions for
some special task, you may go to http://www.gcom.com and get LiS
(Linux STREAMS), which is a Linux STREAMS implementation. You will
have to patch a kernel however.
2. Or, if you just need {get,put}msg() to do some very specific task,
you may be much better off finding a way to achieve the same effect
you need by Linux-specific means. For example, I was involved once
in porting an application from SVR4-based systems to Linux. The
application called STREAMS ioctl()'s to remove all modules from a
serial port. This was done to squeeze maximum performance on data
transfer. So, I just replaced that code in the Linux version to use
POSIX termio to set a non-canonical input and that was it.
BTW, although I fully recognize all STREAMS' drawbacks, I still cannot
understand why it is such a big deal to incorporate LiS into the
kernel and provide it as a configuration option. While most of people
would just disable it, those who really need SVR4 compatibility would
be able to get it. This would give Linux *much* more acceptance in
corporate world.
The question above is not intended to start yet another holy "Linux vs
STREAMS" war. Instead, if you think you have a reasonable answer, you
may just mail it to me.
Regards,
--
Alexander L. Belikoff
Bloomberg LP / BFM Financial Research Ltd.
a...@bfr.co.il
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: da...@dm.cobaltmicro.com (David S. Miller)
Subject: Re: getmsg & putmsg
Date: 1998/05/13
Message-ID: <199805131134.EAA03163@dm.cobaltmicro.com>#1/1
X-Deja-AN: 352851737
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m31ztyo1t8.fsf@vermis.bfr.co.il>
Newsgroups: muc.lists.linux-kernel
From: a...@bfr.co.il (Alexander L. Belikoff)
Date: 13 May 1998 14:19:47 +0300
BTW, although I fully recognize all STREAMS' drawbacks, I still
cannot understand why it is such a big deal to incorporate LiS into
the kernel and provide it as a configuration option. While most of
people would just disable it, those who really need SVR4
compatibility would be able to get it. This would give Linux *much*
more acceptance in corporate world.
The question above is not intended to start yet another holy "Linux
vs STREAMS" war. Instead, if you think you have a reasonable
answer, you may just mail it to me.
The problem is that everyone would "just config out streams" until
some major vendor wrote a major application which depended upon it.
Then people would start to compile it in by default, and this is a
landslide effect. Then people would start asking why the default
configuration of the kernel is so slow, and we'd start trying to make
our streams implementation more efficient, ad nauseum...
STREAMS isn't going to help us as much as you think as far as
corporate acceptance is concerned. And things will be a lot better
off if people started to use things other than streams in their
applications, adding support for them in Linux is not going to
encourage that to happen.
Also if something like streams would go into the main distribution, it
would become like a fungus and begin to "creap" into other parts of
the generic code.
It's just a problem waiting to happen and none of us are going to let
it begin.
Later,
David S. Miller
da...@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: groud...@club-internet.fr (Gerard Roudier)
Subject: Re: getmsg & putmsg
Date: 1998/05/13
Message-ID: <Pine.LNX.3.95.980513165906.588A-100000@localhost>#1/1
X-Deja-AN: 352946232
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199805131134.EAA03163@dm.cobaltmicro.com>
Newsgroups: muc.lists.linux-kernel
On Wed, 13 May 1998, David S. Miller wrote:
> From: a...@bfr.co.il (Alexander L. Belikoff)
> Date: 13 May 1998 14:19:47 +0300
>
> BTW, although I fully recognize all STREAMS' drawbacks, I still
> cannot understand why it is such a big deal to incorporate LiS into
> the kernel and provide it as a configuration option. While most of
> people would just disable it, those who really need SVR4
> compatibility would be able to get it. This would give Linux *much*
> more acceptance in corporate world.
>
> The question above is not intended to start yet another holy "Linux
> vs STREAMS" war. Instead, if you think you have a reasonable
> answer, you may just mail it to me.
>
> The problem is that everyone would "just config out streams" until
> some major vendor wrote a major application which depended upon it.
> Then people would start to compile it in by default, and this is a
> landslide effect. Then people would start asking why the default
> configuration of the kernel is so slow, and we'd start trying to make
> our streams implementation more efficient, ad nauseum...
Nothing but paranoia, IMNSHO.
I did think that an O/S is a thing that run application programs. If
applications want STREAMS, then we must provide them STREAMS.
Providing both STREAMS and BSDish methods would allow application
programs supplier to use the method that they consider better regarding
their own trends.
You like free software, but you donnot want application to freely use
methods they prefer. This looks like dictatotship and nothing else.
Why are you worrying about an application program supplier who prefer
his application to run slower when a faster method is available.
It is not your concern at all and speed in not always the more
important thing for application programs.
> STREAMS isn't going to help us as much as you think as far as
> corporate acceptance is concerned. And things will be a lot better
> off if people started to use things other than streams in their
> applications, adding support for them in Linux is not going to
> encourage that to happen.
Bill Gates want applications to use Win32 and MFC. It is a question of
$$$$$$$ and could be understandable. The war against STREAMS by
BSDish dynosaurs is not understandable to me.
> Also if something like streams would go into the main distribution, it
> would become like a fungus and begin to "creap" into other parts of
> the generic code.
Blah blah blah. This depends on how the thing is designed and implemented.
It is often the speed paranoia that leads to ugly implementation compromise.
> It's just a problem waiting to happen and none of us are going to let
> it begin.
Donnot make me laugth since my lips are chapped. ;-)
You will do what users will want you to do or will give up, IMO.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: mc...@ibm.net (Larry McVoy)
Subject: Re: getmsg & putmsg
Date: 1998/05/13
Message-ID: <199805132216.WAA102502@out1.ibm.net>#1/1
X-Deja-AN: 353044662
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
: Nothing but paranoia, IMNSHO.
: I did think that an O/S is a thing that run application programs. If
: applications want STREAMS, then we must provide them STREAMS.
If people want to do stupid things, nobody stops them.
If those stupid things negatively effect other people, then they get stopped.
: You like free software, but you donnot want application to freely use
: methods they prefer. This looks like dictatotship and nothing else.
Yup, it's a dictatorship and thank God for that. Otherwise every bad idea
that comes down the pike would be added to the kernel.
: > Also if something like streams would go into the main distribution, it
: > would become like a fungus and begin to "creap" into other parts of
: > the generic code.
:
: Blah blah blah. This depends on how the thing is designed and implemented.
: It is often the speed paranoia that leads to ugly implementation compromise.
Um, I put all of the networking code in SCO Unix. It was STREAMS based.
I also put that code into a supercomputer Unix and I worked on Sun's
STREAMS, both the Lachman derived crap and the rewrite after we tossed
Lachman's stuff.
It was then, and remains today, a bad idea. It's a performance lose and
the code gets incredibly ugly when you try and make it go fast. You
essentially have to rewrite the I/O paths so STREAMS becomes nothing more
than a fancy framework for ioctls.
Look, if you love STREAMS so much, then go make it work in the kernel.
Come back with a system that is less lines of code, works faster (both
bandwidth and latency), and is easier to use. Until you can do that,
nobody will take your seriously. I sure don't.
: > It's just a problem waiting to happen and none of us are going to let
: > it begin.
:
: Donnot make me laugth since my lips are chapped. ;-)
: You will do what users will want you to do or will give up, IMO.
And you are the person that didn't want to start another flamefest about
STREAMS? Right. Good. Thanks for being so reserved and uninflammatory.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: groud...@club-internet.fr (Gerard Roudier)
Subject: Re: getmsg & putmsg
Date: 1998/05/14
Message-ID: <Pine.LNX.3.95.980514205511.679A-100000@localhost>#1/1
X-Deja-AN: 353544086
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199805132216.WAA102502@out1.ibm.net>
Newsgroups: muc.lists.linux-kernel
On Wed, 13 May 1998, Larry McVoy wrote:
> Look, if you love STREAMS so much, then go make it work in the kernel.
> Come back with a system that is less lines of code, works faster (both
> bandwidth and latency), and is easier to use. Until you can do that,
> nobody will take your seriously. I sure don't.
I donnot love STREAMS at all and I just shit on them.
I did write all kind of sockets and STREAMS based application programs
and resusable softwares that are actually incorporated into several
product at the Company I work, and not only for UNIX systems.
I do know the silliness of STREAMS, but have to use them when the only
other solution are sockets crappily emulated on STREAMS, or when the
only available interface is STREAMS.
I always use _native_ services instead of shitty emulations.
If the subject had been to claim that raw devices or any other really
used facility asked by users will never be incorporated in Linux,
I would have complained the same way.
> : > It's just a problem waiting to happen and none of us are going to let
> : > it begin.
> :
> : Donnot make me laugth since my lips are chapped. ;-)
> : You will do what users will want you to do or will give up, IMO.
>
> And you are the person that didn't want to start another flamefest about
I am not this person at all.
> STREAMS? Right. Good. Thanks for being so reserved and uninflammatory.
I just wrote what Companies have to do if they want to stay in busyness.
Why should it be different for Free Softwares and especially for Linux ?
(BTW, the previous phase was a joke, translated from French)
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: a...@muc.de (Andi Kleen)
Subject: Re: getmsg & putmsg
Date: 1998/05/17
Message-ID: <k290o1ei1v.fsf@zero.aec.at>#1/1
X-Deja-AN: 353948156
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980514205511.679A-100000@localhost>
Newsgroups: muc.lists.linux-kernel
Gerard Roudier <groud...@club-internet.fr> writes:
> On Wed, 13 May 1998, Larry McVoy wrote:
>
> > Look, if you love STREAMS so much, then go make it work in the kernel.
> > Come back with a system that is less lines of code, works faster (both
> > bandwidth and latency), and is easier to use. Until you can do that,
> > nobody will take your seriously. I sure don't.
>
> I donnot love STREAMS at all and I just shit on them.
> I did write all kind of sockets and STREAMS based application programs
> and resusable softwares that are actually incorporated into several
> product at the Company I work, and not only for UNIX systems.
> I do know the silliness of STREAMS, but have to use them when the only
> other solution are sockets crappily emulated on STREAMS, or when the
> only available interface is STREAMS.
> I always use _native_ services instead of shitty emulations.
>
> If the subject had been to claim that raw devices or any other really
> used facility asked by users will never be incorporated in Linux,
> I would have complained the same way.
iBCS has happily lived for years as a separately distributed subsystem.
PCMCIA has too. So why can't LiS too?
I know that the current distribution of LiS is a bit unfortunate. It is
distributed as a gigant patch set that adds lots of new files, but has
actually only a few changes to existing files. I think it would be nice
to add the necessary hooks into the standard kernel so that LiS can be
compiled separately and insmod'ed without any kernel patches.
Then those who want STREAMS can dowload and use it, and the other people
don't have to worry about it. The only core patch that seems to be needed
for 2.2 are syscall slot reservations for getmsg/putmsg [the poll
implementation from 2.0 LiS is not needed because 2.1 already has poll]
Linus, would you accept a patch to reserve getpmsg()/putpmsg() syscall
slots? (similar like the AFS syscall). Then LiS could be plug into 2.2
easily by those who want it, and others don't have to worry.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
|