Path: sparky!uunet!math.fu-berlin.de!news.tu-chemnitz.de!hrz.tu-chemnitz.de!jpo
From: j...@kappa.informatik.tu-chemnitz.de (Joerg Pommnitz)
Newsgroups: comp.os.linux
Subject: Re: ANNOUNCE: linux-0.99 patchlevel 3
Date: 14 Jan 1993 08:58:22 +0100
Organization: University of Technology Chemnitz, FRG
Lines: 9
Message-ID: <jpo.726998071@hrz.tu-chemnitz.de>
References: <1993Jan13.220545.6910@klaava.Helsinki.FI>
NNTP-Posting-Host: kappa.informatik.tu-chemnitz.de
Keywords: kernel, new patchlevel, minor bugfixes
Some days ago Peter MacDonald wrote, that he had included
the ipcbeta patches to the SLS release.
Isn't it time to make this beast part of the standard kernel ?
It will become harder and harder to apply these patches,
if the kernel changes more and more.
I think, having shared memory, message queues and semaphores
isn't such a bad idea.
Joerg
Newsgroups: comp.os.linux
Path: sparky!uunet!mcsun!news.funet.fi!funic!nntp.hut.fi!nntp!jem
From: j...@vipunen.hut.fi (Johan Myreen)
Subject: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
In-Reply-To: jpo@kappa.informatik.tu-chemnitz.de's message of 14
Jan 1993 08:58:22 +0100
Message-ID: <JEM.93Jan14151001@vipunen.hut.fi>
Sender: use...@nntp.hut.fi (Usenet pseudouser id)
Nntp-Posting-Host: vipunen.hut.fi
Organization: Helsinki University of Technology, Finland
References: <1993Jan13.220545.6910@klaava.Helsinki.FI>
<jpo.726998071@hrz.tu-chemnitz.de>
Date: 14 Jan 93 15:10:01
Lines: 25
In article <jpo.726998...@hrz.tu-chemnitz.de>
j...@kappa.informatik.tu-chemnitz.de (Joerg Pommnitz) writes:
>Some days ago Peter MacDonald wrote, that he had included
>the ipcbeta patches to the SLS release.
>Isn't it time to make this beast part of the standard kernel ?
>It will become harder and harder to apply these patches,
>if the kernel changes more and more.
>I think, having shared memory, message queues and semaphores
>isn't such a bad idea.
Linus is of course the definite authority on this, but I'd like to add
my two cents. I think there should be some limit to what gets added to
Linux; does it really need everything? If I remember correctly, one of
the goals Linus had was to keep Linux a small and simple, but Posix
compatible kernel.
We don't want Linux to become a new AIX, do we?
If Peter MacDonald distributes a kernel different from the "standard"
kernel (Linus' version), then I think it is questionable if that
kernel is Linux at all.
--
Johan Myreen
j...@cs.hut.fi
Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!
cbnewse!cbnewsd!att-out!oucsboss!oucsace!sadkins
From: sadk...@bigbird.cs.ohiou.edu (Scott W. Adkins)
Newsgroups: comp.os.linux
Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
Message-ID: <1993Jan14.154308.2640@oucsace.cs.ohiou.edu>
Date: 14 Jan 93 15:43:08 GMT
References: <1993Jan13.220545.6910@klaava.Helsinki.FI>
<jpo.726998071@hrz.tu-chemnitz.de> <JEM.93Jan14151001@vipunen.hut.fi>
Sender: use...@oucsace.cs.ohiou.edu (Network News Poster)
Organization: Ohio University CS Dept., Athens
Lines: 52
In article <JEM.93Jan14151...@vipunen.hut.fi>
j...@vipunen.hut.fi (Johan Myreen) writes:
>In article <jpo.726998...@hrz.tu-chemnitz.de>
j...@kappa.informatik.tu-chemnitz.de (Joerg Pommnitz) writes:
>
>>Some days ago Peter MacDonald wrote, that he had included
>>the ipcbeta patches to the SLS release.
>>Isn't it time to make this beast part of the standard kernel ?
>
>Linus is of course the definite authority on this, but I'd like to add
>my two cents. I think there should be some limit to what gets added to
>Linux; does it really need everything? If I remember correctly, one of
>the goals Linus had was to keep Linux a small and simple, but Posix
>compatible kernel.
I disagree with you here... a lot of systems can be POSIX compliant and
still have extensions to the kernel. I do not recall POSIX saying that
you *can't* have this or that... (somebody correct me if I am wrong).
I think that shared memory, ipc's, semaphores, etc. should be included
since it makes the communication bewtween processes and programs just
a bit easier. I think a lot of Unix systems are moving in this direction
anyway (specifically with shared memory), and Linux should attempt to
stay on the leading of edge of ... (what? popularity? technology? well,
just the leading edge...) :-)
>We don't want Linux to become a new AIX, do we?
I think this is a little out of the ball park... Could Linux ever get
as bad as AIX? It isn't because AIX had shared memory and IPC's that
made it so bad... there was a lot of other things that made it bad from
the start (like the design for instance...) (You can flame me for this,
since I am admitting right now that I don't know *that* much about the
way AIX does things...)
>If Peter MacDonald distributes a kernel different from the "standard"
>kernel (Linus' version), then I think it is questionable if that
>kernel is Linux at all.
I completely disagree here... Linux is linux... If it is supported by
the Linux community (and of course Linus himself), then why shouldn't it
still be called Linux? Kernels all over the world for all types of Unix
systems are modified to include new stuff or non-standard stuff... but
this does not make it a new type of Unix. I can imaging what would happen
with Minix, with students/profs/etc modifying the kernel every day! :-)
Don't be too harsh on me for voicing my opinion here... Of course, Johan
was voicing his opinion too... :-) I thought I would just add a little
extra traffic to the c.o.l's highway!
Scott.
--
Scott W. Adkins Internet: sadk...@ohiou.edu
~~~~~~~~~~~~~~~ ak...@cleveland.freenet.edu
Ohio University of Athens Bitnet: adk...@ouaccvma.bitnet
Newsgroups: comp.os.linux
Path: sparky!uunet!pipex!warwick!sunserver1.aston.ac.uk!uhura!evansmp
From: evan...@uhura.aston.ac.uk (Mark Evans)
Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
Message-ID: <1993Jan14.172817.7750@aston.ac.uk>
Sender: use...@aston.ac.uk (Usenet administrator)
Nntp-Posting-Host: uhura
Organization: Aston University
X-Newsreader: TIN [version 1.1 PL241235]
References: <1993Jan14.154308.2640@oucsace.cs.ohiou.edu>
Date: Thu, 14 Jan 1993 17:28:17 GMT
Lines: 25
Scott W. Adkins (sadk...@bigbird.cs.ohiou.edu) wrote:
:
: I disagree with you here... a lot of systems can be POSIX compliant and
: still have extensions to the kernel. I do not recall POSIX saying that
: you *can't* have this or that... (somebody correct me if I am wrong).
: I think that shared memory, ipc's, semaphores, etc. should be included
: since it makes the communication bewtween processes and programs just
: a bit easier. I think a lot of Unix systems are moving in this direction
: anyway (specifically with shared memory), and Linux should attempt to
: stay on the leading of edge of ... (what? popularity? technology? well,
: just the leading edge...) :-)
There are also (at least) 2 different ways of doing shared memory,
one is by having the sysv method of createing a shared memory, which
can be attached to any process. The other way is to mark pages as shareable
the fork. (or selectively disable copy on write, which does the same thing)
In the former case the shared area exists until explicitly destroyed,
in the latter it ceases to exist when the last process of the tree exists.
--
-------------------------------------------------------------------------
Mark Evans |evan...@uhura.aston.ac.uk
+(44) 21 429 9199 (Home) |evan...@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office) |
Newsgroups: comp.os.linux
Path: sparky!uunet!munnari.oz.au!metro!basser.cs.su.oz.au!swift!jeremy
From: jer...@sw.oz.au (Jeremy Fitzhardinge)
Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
Organization: Softway Pty Ltd
Date: 20 Jan 93 07:24:04 GMT
Message-ID: <jeremy.727514644@chao>
References: <1993Jan14.154308.2640@oucsace.cs.ohiou.edu>
<1993Jan14.172817.7750@aston.ac.uk>
Sender: n...@softway.sw.oz.au (Usenet)
Lines: 43
In <1993Jan14.172817.7...@aston.ac.uk> evan...@uhura.aston.ac.uk (Mark Evans)
writes:
>Scott W. Adkins (sadk...@bigbird.cs.ohiou.edu) wrote:
>There are also (at least) 2 different ways of doing shared memory,
>one is by having the sysv method of createing a shared memory, which
>can be attached to any process. The other way is to mark pages as shareable
>the fork. (or selectively disable copy on write, which does the same thing)
>
>In the former case the shared area exists until explicitly destroyed,
>in the latter it ceases to exist when the last process of the tree exists.
I have no objection to things being added to Linux if they are useful,
but System V-type IPC are not the way to go - they are BAD. The main
problem is that they use a completely different set of access methods
and name space to everything else in the unix kernel. Because they
have very little common overlap with existing code, there is a higher
chance of bugs, and a disproportionate amount of extra code for the
extra functionality.
I would suggest that mmap() type shared memory should be implemented.
This is where a file gets mapped into a process's address space.
All the processes mapping the same file get the same memory pages in
their address spaces. The mappings can be set up so modifications to
the mapped pages can either be shared or private.
Not only do you get shared memory backed by files (preserving the
everything is a file and is used through a file descriptor paradigm),
but it is useful for implementing all the memory management of the
kernel, particularly executable images, shared code and dynamic
linking. All of the shmop() type functions can be simulated with
mmap()/mprotect()/munmap().
After looking at some older kernel sources, it seems that Linus is
planning to use a SVR4-style memory object system where processes can
have a number of memory segments in their address spaces with different
properites. This should allow an easy implementation of mapped files
type VM system.
Semaphores can be done in shared memory, and message queues can be done
with named pipes.
shmop() - just say no.
J
From: evansmp@uhura.aston.ac.uk (Mark Evans)
Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
Date: 20 Jan 93 15:09:36 GMT
Jeremy Fitzhardinge (jeremy@sw.oz.au) wrote:
:
: I would suggest that mmap() type shared memory should be implemented.
: This is where a file gets mapped into a process's address space.
: All the processes mapping the same file get the same memory pages in
: their address spaces. The mappings can be set up so modifications to
: the mapped pages can either be shared or private.
You can do without the mmap (though loose the back up file, frequently
what is done is call open immediatly followed by unlink anyway)
By altering the page tables, so as to explicitally share the page.
(partially switching off the copy on write which normally takes place)
:
: Not only do you get shared memory backed by files (preserving the
: everything is a file and is used through a file descriptor paradigm),
: but it is useful for implementing all the memory management of the
: kernel, particularly executable images, shared code and dynamic
: linking. All of the shmop() type functions can be simulated with
: mmap()/mprotect()/munmap().
Which is exectly how the Dynix operating system.
The tricky bit is where you want to be able to handle growing private
and shared heap areas arbitarly.
This should be solvable.
--
=========================================================================
Mark Evans |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199 (Home) |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office) |
From: janl@ifi.uio.no (Jan Nicolai Langfeldt)
Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
Date: 20 Jan 93 13:27:38 GMT
In article <jeremy.727514644@chao>, jeremy@sw.oz.au (Jeremy Fitzhardinge) writes:
> In <1993Jan14.172817.7750@aston.ac.uk> evansmp@uhura.aston.ac.uk (Mark Evans) writes:
> I would suggest that mmap() type shared memory should be implemented.
> This is where a file gets mapped into a process's address space.
> All the processes mapping the same file get the same memory pages in
> their address spaces. The mappings can be set up so modifications to
> the mapped pages can either be shared or private.
>
> Not only do you get shared memory backed by files (preserving the
> everything is a file and is used through a file descriptor paradigm),
> but it is useful for implementing all the memory management of the
> kernel, particularly executable images, shared code and dynamic
> linking. All of the shmop() type functions can be simulated with
> mmap()/mprotect()/munmap().
(I don't know much about how things work inside linux but... :-)
My mind is spinning. The next logical step is to make the data segment
a memory mapped file too, then the system can be taken down by
stopping the processes and writing the memory to the files. On boot
the system can be started exactly where it left. This would be esp.
handy for portables (other mahcines are kept up all the time...) This
becomes the virtual memory mechanism too of course.
How is that for creeping featurism? (I think I may have read about
this somewhere it came to me all too easily :-)
Nicolai, all around non-wizard
--
Nicolai Langfeldt, "Bugs made while you wait"
Internet: janl@ifi.uio.no
From: evansmp@uhura.aston.ac.uk (Mark Evans)
Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
Date: Wed, 20 Jan 1993 15:15:45 GMT
Jan Nicolai Langfeldt (janl@ifi.uio.no) wrote:
:
: My mind is spinning. The next logical step is to make the data segment
: a memory mapped file too, then the system can be taken down by
: stopping the processes and writing the memory to the files. On boot
: the system can be started exactly where it left. This would be esp.
: handy for portables (other mahcines are kept up all the time...) This
: becomes the virtual memory mechanism too of course.
Part of this can be done by a small alteration to malloc (well not on linux
yet, since mmap dosn't do it at the moment)
However as well as the heap you also need to store the stack (can also be
mmaped to a file)
And the rigisters lots of extra instructions (in the binary to do this)
Or were you thinking of dumping the apropriate data to disk on a shutdown
explicitly.
--
=========================================================================
Mark Evans |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199 (Home) |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office) |
Path: sparky!uunet!spool.mu.edu!agate!doc.ic.ac.uk!warwick!uknet!
edcastle!dcs.ed.ac.uk!sct
From: s...@dcs.ed.ac.uk (Stephen Tweedie)
Newsgroups: comp.os.linux
Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
Message-ID: <SCT.93Jan21162633@carna.dcs.ed.ac.uk>
Date: 21 Jan 93 16:26:33 GMT
References: <1993Jan14.154308.2640@oucsace.cs.ohiou.edu>
<1993Jan14.172817.7750@aston.ac.uk> <jeremy.727514644@chao>
Sender: cn...@dcs.ed.ac.uk (UseNet News Admin)
Organization: University of Edinburgh Dept. of Computer Science, Scotland
Lines: 37
In-Reply-To: jeremy@sw.oz.au's message of 20 Jan 93 07:24:04 GMT
In article <jeremy.727514644@chao>, jer...@sw.oz.au (Jeremy Fitzhardinge) writes:
> I have no objection to things being added to Linux if they are useful,
> but System V-type IPC are not the way to go - they are BAD. The main
> problem is that they use a completely different set of access methods
> and name space to everything else in the unix kernel. Because they
> have very little common overlap with existing code, there is a higher
> chance of bugs, and a disproportionate amount of extra code for the
> extra functionality.
> I would suggest that mmap() type shared memory should be implemented.
> This is where a file gets mapped into a process's address space.
> All the processes mapping the same file get the same memory pages in
> their address spaces. The mappings can be set up so modifications to
> the mapped pages can either be shared or private.
I agree with you from the "operating systems philosophy" point of
view. Unfortunately, compatibility and performance are also issues.
We currently DO have SYSV-IPC as a kernel option; there is too much
software out there using these facilities to give them up.
IF we can implement SYSV-IPC in an efficient and totally
user-transparent way by building library calls on top of shared
memory, then that will be a reasonable way to go. If not, then I
don't think we should strip the existing code from the kernel; it is
too useful, even if ugly. We can always make it a kernel
configuration option.
However, that does not mean that mmap() for normal files is not worth
while. It would be a clean and useful extension to the kernel. I
just don't think we should throw away compatibility for the sake of
aesthetics.
Cheers,
Stephen Tweedie.
---
Stephen Tweedie <s...@uk.ac.ed.dcs> (Internet: <s...@dcs.ed.ac.uk>)
Department of Computer Science, Edinburgh University, Scotland
From: jem@snakemail.hut.fi (Johan Myreen)
Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
Date: 22 Jan 93 18:23:15 GMT
In article <SCT.93Jan21162633@carna.dcs.ed.ac.uk>
sct@dcs.ed.ac.uk (Stephen Tweedie) writes:
>In article <jeremy.727514644@chao>, jeremy@sw.oz.au (Jeremy Fitzhardinge) writes:
>> I have no objection to things being added to Linux if they are useful,
>> but System V-type IPC are not the way to go - they are BAD. The main
...
>> I would suggest that mmap() type shared memory should be implemented.
>I agree with you from the "operating systems philosophy" point of
>view. Unfortunately, compatibility and performance are also issues.
>We currently DO have SYSV-IPC as a kernel option; there is too much
>software out there using these facilities to give them up.
I'm curious: how much software is there really that uses SYSV IPC,
without any alternate way to go? As we are talking about Linux here,
only free software counts. Could you give some examples of software
like this? (This should not be taken as a flame, I really want to
know.)
Somebody else said that keeping the linux kernel small can be done
with conditional compilation and let the user decide what goes in and
what doesn't. That's not what I meant by keeping the kernel small, to
try to keep the kernel image file as small as possible. Perhaps
'non-hairy' is a better word. A known Linux hacker once said: "If I
were to choose between a feature filled kludged kernel and a piece of
art, I'd take the piece of art." Compile time configuration could make
things even worse, filling the code with #ifdef this and #ifndef
that... (I'm not particularly a friend of the C preprocessor.
Somtimes I feel like writing an article called "The C Preprocessor
Considered Harmful".)
In another article somebody asked something like "if we want to keep
the kernel simple, why do we have soundcard support etc..." I haven't
looked at the soundcard code, but I think there's a difference between,
for instance, adding drivers for various pieces of hardware and adding
features which have a significant impact on the whole kernel, cutting
deep into the foundations of the design. This is especially true when
the features to be added start to overlap with other features of the
kernel.
Note that what I've said above does not neccessarily apply to the SYSV
IPC patches, they just happened to provoke me to post the article that
started this thread. But I still think bloating the kernel with
feature after feature isn't a good idea.
As usual, these are just my thoughts on the issue.
--
Johan Myreen
jem@cs.hut.fi
Path: sparky!uunet!decwrl!spool.mu.edu!yale.edu!ira.uka.de!
rz.uni-karlsruhe.de!ma2s2!haible
From: hai...@ma2s2.uucp (Bruno Haible)
Newsgroups: comp.os.linux
Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
Date: 31 Jan 1993 14:30:20 GMT
Organization: University of Karlsruhe, Germany
Lines: 19
Sender: <hai...@ma2s2.mathematik.uni-karlsruhe.de>
Message-ID: <1kgnps$g29@nz12.rz.uni-karlsruhe.de>
References: <jeremy.727514644@chao> <SCT.93Jan21162633@carna.dcs.ed.ac.uk>
<JEM.93Jan22202315@lk-hp-6.hut.fi>
NNTP-Posting-Host: ma2s2.mathematik.uni-karlsruhe.de
Summary: CLISP uses shared memory
Keywords: shared memory, kernel, clisp
j...@snakemail.hut.fi (Johan Myreen) writes:
> I'm curious: how much software is there really that uses SYSV IPC,
> without any alternate way to go? As we are talking about Linux here,
> only free software counts. Could you give some examples of software
> like this?
Take CLISP as an example. It is free software. When it uses the Linux SYSV IPC
this results in a speedup of about 6%. Not much, I agree, but it's worth it.
> adding features which have a significant impact on the whole kernel, cutting
> deep into the foundations of the design.
The current Linux SYSV IPC has no impact on the kernel unless used. Look at the
code.
Bruno Haible
hai...@ma2s2.mathematik.uni-karlsruhe.de