Linux-Development-Sys Digest #827, Volume #6 Sun, 13 Jun 99 13:14:06 EDT
Contents:
Multiple anonymous mmaps sharing memory --- how? ([EMAIL PROTECTED])
Re: TAOs: Much to do about nothing? (Technolord)
Re: the ultimate OS (Frank Sweetser)
/usr/include/linux/proc_fs.h, how to use it? ("Huang Kai")
Re: power off after shutdown --> no more in 2.2.x ? (Stefan Opperskalski)
glibc2: undefined references (Tobias Deiminger)
About /proc/meminfo ?? ("lming")
Re: 64 bit File I/O (Andreas Jaeger)
Re: glibc2: undefined references (Andreas Jaeger)
Re: power off after shutdown --> no more in 2.2.x ? (Moritz Franosch)
Re: SIGALRM and serial i/o (James Youngman)
Re: /usr/include/linux/proc_fs.h, how to use it? (James Youngman)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Multiple anonymous mmaps sharing memory --- how?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 12 Jun 1999 15:02:30 GMT
Here is something I want to do, and really can't figure out how to do
properly:
I have a program which has to go through 3 steps.
1) Allocate several chunks of memory using an anonymous mmap().
This is on an Alpha, so the address space of these chunks is
>4GB (i.e. the upper 32 bits are non-zero).
2) Do some arithmetic, calculating addresses in the first 4GB
3) Map the chunks of memory allocated in (1) at the addresses calculated
in (2), using MAP_FIXED.
The problem is that there is no file associated with anonymous mmap()s, and
that thus I cannot simply call mmap() on the same files again in (3).
At the moment, I am simply using some (large) files and map them shared,
but that really can't be the solution (among other things, it means that
exiting the program takes forever when the dummy files get updated).
I tried using /dev/zero as the file, but it seems one cannot map that
in a shared way.
I have also tried opening /proc/self/mem in step (3) and mapping at
the offsets that were returned in (1), but mmap won't have it.
As far as I can see, there is nothing that would technically make it
impossible to do what I want. mremap() seems to almost do the right thing,
only that it can't be told where to move things to, and that it also
deletes the old mapping.
It seems to me like this would be a pretty common thing to do, so I expect
UNIX to provide a mechanism to do it. But I can't for the life of me
figure out how....
Any ideas?
Bernie
--
============================================================================
"It's a magical world, Hobbes ol' buddy...
...let's go exploring"
Calvin's final words, on December 31st, 1995
------------------------------
From: Technolord <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAOs: Much to do about nothing?
Date: Sat, 12 Jun 1999 18:19:44 +0200
Reply-To: Technolord <[EMAIL PROTECTED]>
On Fri, 11 Jun 1999, Christopher B. Browne wrote:
> >Also, the text is pretty chaotic in its contents (should be re-arranged
> >in a better way) but what I wanted to do was to explain better the
> >situation.
> I think it is quite successful at doing this, such as it is.
Succesful at being chaotic, I guess? :))
> It nicely maintains the too-abstract-to-do-anything-about approach
> of providing design constraints that do not have clear definitions.
Yep, indeed! I think I should ask for forgiveness since I had pretty no
time to write down something more clearer, maybe some day I will find
enough time.
> The problem with this whole discussion has been that the claims of
> "what should be" do not provide a specific model of what should be,
> but merely touch at the edges to say vague things about what should
> be.
[big snip]
Uhm, I'm not asking for any $50,000 chunk of marble as for now. As for
previous work, I guess noone of you will ever see them as I (meanly) lost
them all in a couple of HDD crashes (backups too, of course), so you'll
have to believe my good faith. Of course, I'm not intending to sell smoke,
and I'm doing the best I can to build something over time.
> "Here's a big piece of marble; my plan is to chip away everything that
> doesn't look like a beautiful woman."
Did I say this? ;)
> Instead of hearing what abstractions are actually supposed to be
> provided in the various areas of functionality, we see things like:
> "Thinking to the poor and bethrayed programmer, the programming
> interface will be studied to be as more powerful and abstract as
> possible..."
> That's not design; that's mere platitudes; wishful thinking. "We'll chip
> away everything that isn't powerful and abstract."
Uhm, I'd suggest to read it as "we have a (vague, ok) idea of what we
shold achieve, try to keep it in mind while the research continues". Don't
try to tell me semaphores under Linux are easy to use, I won't drink it!
> How about instead writing an outline that parallels books that have
> been written about OS designs?
Eventually when I'll have time to do it I will. The only book I have right
here under my hands is "Operating Systems, 5th ed", Silbershatz-Galvin.
> Two that leap immediately to mind are The Design and Implementation of
> the 4.4 BSD UNIX Operating System, which documents the BSD architecture,
> and the Be Developer's Guide, Book 1. I suspect that The QNX 4 Real-Time
> Operating System would also represent a good reference in the same vein,
> though I have not seen it.
I'll try to put my paws on them, when I'll have time to dedicate to them.
But it would be appreciated if someone who actually read them share the
knowledge.
> Major "kernel areas" that would need to be outlined for an OS that would
> include a graphical component include:
[...]
> An operating system is composed of these sorts of things, and in order
> to have any sort of picture of what the OS is supposed to look like,
> they need to be outlined, or, preferably, detailed.
Yep, no doubt.
> Descriptions of each of these dozen or so major areas of functionality
> would represent a "design," at least to a trivial level of detail.
Well, what you say in this post is pretty much the truth, and I cannot say
I disagree (instead, you're right on about everythiong). But let me say
something on my own truth. I'll keep the architect example which sounds
good to me.
The architect (or someone which we're not interested in) say "I want to
build an house". Then the architect starts outlining what he requires,
eventually focusing on the details back and forth, I mean at first "I want
a bathroom here" is allowable. Then, as time passes by and the project
evolves, more details are studied: how to place the pipes, the windows,
lights, plugs and single components. Eventually he studies the new
solutions to the instance (new type of pipes, for example) and makes the
project better. Eventually he will find the bathroom is neat and will go
even more in-depth by actually examining which lights to put in, which WC
or sink to place and so forth. Wether he studied many things is of little
relevance, knowledge of about building a skyscraper is of little or no use
to build a standalone house. He just requires to know what can and cannot
be done (placing a bed in a 1.5mx1.5m room isn't possible) and then
study what he needs to know better. Or, he can ask others who already have
the knowledge for an opinion/help, and get the work done meybe better (the
little difference between a fresh architect and a veteran who did similar
projects for years ;)
The project actually is at the "I want an house, and there should be a
chicken, a bathroom, 2 bedrooms and so forth" point, and each point is
being examined to find whichever solution fits best the problem we're to
solve with the guidelines written in the text (and also those not
written). If I want the bathroom far from the bedroom, and a solution
implie the bathroom to be part of the bedroom, this solution isn't
acceptable even if it would greatly reduce costs, just because it goes
against my requirements (where my could be a customer, a programmer or
whatever). I see no crime in it. The fact that we're researching and
discussing to get further detail and we're asking for veterans to help us
(but also non-veterans can help) doesn't go against any rule.
But, if what you want to see is something like "memory management will be
done with Linux's buddy algo or MacOs' enhanced second chance algo" well,
I invite you to re-read my post. Else, start giving suggestions on which
functions (interface?) should the "entities" have. UDI is one of those
we'll use, if you wanted to hear something like this. If we're in the
"research" part of the project you can't come out by saying "hey, you
haven't written the details!" since it's what we're trying to achieve!
Ooops that's late... gotta go! Bye bye! (nice talk to ya)
[=-----------------------Technolord-the-Hellraiser----------------------=]
To those who can see the truth to those who can still have feelings
to those who still have the courage to live in this evil world.
.no.regrets.
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: the ultimate OS
Date: 13 Jun 1999 00:13:36 -0400
<sigh...>
okay, look at things this way. many of the people here are professional
coders, who do or have worked for large software companies. in these
companies, they often get assignments from clueless PHB's. ones such as
"perform a study determining which color database has the most memory" to
"write a program that can find all of the bugs in our other programs" to
"make sure you fully utilize the synergy of the object oriented paradigms
while empowering yourself with our action plans." in short, these people
are not impressed by words. in particular, ones which identify some of the
shortcomings of current ideas, and suggest replacing them completely with
half-understood buzzwords. until you produce some code, and start to
establish a reputation that you know what you're doing, and not just how to
make fancy papers, there is **nothing** to distinguish yourself from
another pseudo-programmer trying to replace the entire field of computer
science by actioning yet another buzzword-compliant paradigm.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
"Mommy, mommy, the evil person won't let me take advantage of him".
Whine whine whine.
- Linus, responding to someone complaining about
Linux being GPL'd
------------------------------
From: "Huang Kai" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development
Subject: /usr/include/linux/proc_fs.h, how to use it?
Date: Sun, 13 Jun 1999 12:06:33 +0800
hi,
I try to include linux/proc_fs.h, like the following code:
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/proc_fs.h>
int test()
{
return 0;
}
the compiler's message:
In file included from proc.c:4:
/usr/include/linux/proc_fs.h:275: parse error before `filldir_t'
/usr/include/linux/proc_fs.h:275: warning: `struct file' declared inside
paramet
er list
/usr/include/linux/proc_fs.h:275: warning: its scope is only this definition
or
declaration,
/usr/include/linux/proc_fs.h:275: warning: which is probably not what you
want.
proc.c:6: parse error before `filldir_t'
proc.c:6: warning: `struct file' declared inside parameter list
Where can I find document for proc_fs.h?
How to use it?
BR
kevin
------------------------------
From: Stefan Opperskalski <[EMAIL PROTECTED]>
Subject: Re: power off after shutdown --> no more in 2.2.x ?
Date: Sun, 13 Jun 1999 09:28:55 +0200
Reply-To:
Igor Zlatkovic wrote:
>
> Stefan Opperskalski wrote:
>
> > Hi,
>
> There are two things to consider:
> 1. Kernel 2.2.x needs a newer /sbin/shutdown than 2.0.36.
> 2. All this will not work on a multiprocessor machine. The apm driver
> disables any power management as soon it detects more than one processor.
> APM is not SMP safe.
>
> --
> Igor Zlatkovic mailto:[EMAIL PROTECTED]
> University of Applied Sciences, Frankfurt, Germany, EU
> "If at first you don't succeed, redefine success."
> -- /usr/bin/fortune, 12.5.1999.
Hmmm, I compiled 2.0.36 (I think it was Suse 5.3) with SMP and shutdown
did its job very well.
OK, you may say, the SMP-support was not perfet in that kernel. Accepted
then.
What, if the kernel supported SMP well and shutdown worked?
But I see. I try "halt -p" and I look inside the code to find, how
powering off is done.
CU,
Stefan
------------------------------
Date: Sun, 13 Jun 1999 12:02:13 +0200
From: Tobias Deiminger <[EMAIL PROTECTED]>
Subject: glibc2: undefined references
After installing glibc2.1.1pre3 on my suse5.3 (libc; egcs1.1) to
/usr/local I sometimes get errors during linking:
/usr/local/lib/libc.so.6: undefined reference to
`_dl_unload_cache@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to
`_dl_initial_searchlist@@GLIBC_2.1'
...
What's wrong?
Please retry by e-mail.
------------------------------
From: "lming" <[EMAIL PROTECTED]>
Subject: About /proc/meminfo ??
Date: Sun, 13 Jun 1999 19:02:38 +0800
When I cat /proc/meminfo , I find the shared, buffers, and cached memory.
But what's meaning about that ??
Thanks.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: 64 bit File I/O
Date: 13 Jun 1999 15:00:08 +0200
>>>>> Matthew Carl Schumaker writes:
> I'm currently in the process of porting some windows servers to linux but
> I've run into the problem of 64 bit files. The servers make use of 64bit
> file I/O calls and I know that there are equivalent calls for unix ie
> fopen64, fseek64, ..
> I found these in the stdio.h but I'm not sure as to how to get gcc to use
> them. I've found little documentation of them(basically just saying that
> they exist) but nothing telling me how to use them.
> Thought looking at stdio.h I've noticed a bunch of #ifdefs, I'm not sure
> how to use these and have no way of really testing the calls(baring from
> making a file greater than 2GB and seeing what happens)
> Any help would be greatly appreciated
Have a look at <features.h> (I'm assuming you're running glibc 2.1.x):
_LARGEFILE_SOURCE Some more functions for correct standard I/O.
_LARGEFILE64_SOURCE Additional functionality from LFS for large files.
You can compile with -D_LARGEFILE64_SOURCE to get the interfaces - or
define it before the inclusion of any libc headers.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: glibc2: undefined references
Date: 13 Jun 1999 14:57:30 +0200
>>>>> Tobias Deiminger writes:
Tobias> After installing glibc2.1.1pre3 on my suse5.3 (libc; egcs1.1) to
Tobias> /usr/local I sometimes get errors during linking:
Tobias> /usr/local/lib/libc.so.6: undefined reference to
Tobias> `_dl_unload_cache@@GLIBC_2.1'
Tobias> /usr/local/lib/libc.so.6: undefined reference to
Tobias> `_dl_initial_searchlist@@GLIBC_2.1'
Tobias> ...
Tobias> What's wrong?
Read the glibc FAQ first that comes with glibc 2.1.1.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: Moritz Franosch <[EMAIL PROTECTED]>
Subject: Re: power off after shutdown --> no more in 2.2.x ?
Date: 13 Jun 1999 16:17:35 +0200
Igor Zlatkovic <[EMAIL PROTECTED]> writes:
> Stefan Opperskalski wrote:
> > Since 2.2.x, the power-off function with my asus-boards doesn=B4t wor=
k any
> > more.
>
> 2. All this will not work on a multiprocessor machine. The apm driver
> disables any power management as soon it detects more than one processo=
r.
> APM is not SMP safe.
This also has been reported, but I have not tried it:
You could, however, try adding "apm=3Dsmp-power-off" to your kernel-cmdli=
ne.
Moritz
------------------------------
From: James Youngman <[EMAIL PROTECTED]>
Subject: Re: SIGALRM and serial i/o
Date: 13 Jun 1999 09:55:18 +0100
<[EMAIL PROTECTED]> writes:
> Hi everyone,
>
> I'm trying to synchronize the start of reading from a serial port
> using the sleep() call. But this seems to disable/wipeout the serial
> port settings i.e. a blocking read() call never returns.
>
> All is fine if I exclude the sleep() before reading. Strangely, the simple
> thing of having the sleep() call in the code disables serial read ??!
>
> I'm compiling with gcc 2.7.2.3, glibc 2.0.7 and kernel 2.2.9.
>
> Here's the compile options:
>
> CFLAGS = -Wall -O2 -pedantic-errors -ansi
>
> Here are the include files:
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <ctype.h>
> #include <termios.h>
> #include <unistd.h>
> #include <sys/signal.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> #include <fcntl.h>
> #include <time.h>
> #include <sys/time.h>
>
> I initialize the serial port with:
>
> else{ /* non async mode */
> fd = open(devname, O_RDWR | O_NOCTTY );
> if( fd < 0 ){ perror("open"); return -1;}
> }
>
> and set the termios structure etc.
>
> All works well until I uncomment sleep() before the main loop.
>
> sleep(obstime->tm_sec < 50 ? 50-obstime->tm_sec : 60-obstime->tm_sec+50);
>
> while( !stop ){
> ret = read(fd, buf, MESLEN);
> ...
> }
Are you expecting the read() call to return because it has read MESLEN
bytes, or because it has read a newline, or what? I'm not sure you've
posted a complete anough example to demonstrate the problem. Try
condensing the demonstration into the smallest possible (readable)
program, and post that.
--
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+actually
------------------------------
From: James Youngman <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development
Subject: Re: /usr/include/linux/proc_fs.h, how to use it?
Date: 13 Jun 1999 09:59:34 +0100
"Huang Kai" <[EMAIL PROTECTED]> writes:
> hi,
> I try to include linux/proc_fs.h, like the following code:
>
> #include <linux/kernel.h>
> #include <linux/module.h>
>
> #include <linux/proc_fs.h>
>
> int test()
> {
> return 0;
> }
Is this piece of code intended to go into the kernel, or a user-space
program? If the latter, just use the files under /proc.
linux/proc_fs.h is just a property of the implementation, user-space
programs do not (need to) use it.
--
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+actually
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
