Linux-Development-Sys Digest #560, Volume #8 Mon, 12 Mar 01 10:13:13 EST
Contents:
Re: Can linux be trusted? (pete)
Re: Can linux be trusted? (Richard Heathfield)
Re: why is mmap() unhappy?? (Alexander Viro)
Re: why is mmap() unhappy?? (Dragan Cvetkovic)
Re: why is mmap() unhappy?? ([EMAIL PROTECTED])
Re: why is mmap() unhappy?? ([EMAIL PROTECTED])
Re: why is mmap() unhappy?? (Kasper Dupont)
Re: How to use C++ to develope kernel module? (Kasper Dupont)
Re: why is mmap() unhappy?? (Dragan Cvetkovic)
Re: why is mmap() unhappy?? (Basile STARYNKEVITCH)
Re: Can linux be trusted? (Kasper Dupont)
Re: Can linux be trusted? (Peter da Silva)
Re: why is mmap() unhappy?? (Dragan Cvetkovic)
Re: Can linux be trusted? (Gergo Barany)
----------------------------------------------------------------------------
From: pete <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.c,comp.os.linux.development.apps,comp.sys.be.programmer,comp.sys.mac.programmer.misc,comp.unix.bsd.freebsd.misc,comp.unix.bsd.misc,gnu.gcc
Subject: Re: Can linux be trusted?
Date: Mon, 12 Mar 2001 08:14:53 -0500
Reply-To: [EMAIL PROTECTED]
Erik Max Francis wrote:
>
> pete wrote:
>
> > I felt funny about that too.
> > What do you think about it this way?
>
> If the called function allocate its own storage buffer that it
> manages, it should free it, not the caller.
>
> Either have it return the null pointer in the freeing case, or simply
> don't store the buffer locally and have the caller pass it in. The
> latter solution also would make your code reentrant.
Thanks for your thoughts.
I've been considering a function called strdup().
One of my compilers just told me it was ANSI compatible,
but the other says that it isn't and I can't find it in K&R2,
so I think it isn't. Both compilers are familiar with it though,
so I think it's just a common extension, like kbhit().
Both compilers say that stdrup() uses a call to malloc(), internally.
I used the same syntax for calling and freeing,
as was shown by one of my compilers usage examples.
/* BEGIN, bytebits.c */
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
unsigned char *Bits(void const *p, size_t bytes);
int main(void)
{
float a;
char *s = "(float)%f = %s\n", *t;
printf("\n");
for(a = -2.0; a < 2.5; a += 0.5){
t = Bits(&a, sizeof a);
printf(s, a, t);
free(t);
}
a += 0.1;
t = Bits(&a, sizeof a);
printf(s, a, t);
free(t);
return 0;
}
unsigned char *Bits(void const *p, size_t bytes)
{
unsigned char *a, *b, mask;
a = b = malloc(CHAR_BIT * bytes + 1);
if(!a)
printf("malloc() failure in Bits()\n"), exit(EXIT_FAILURE);
while(bytes--)
for(mask = 1 << CHAR_BIT - 1; mask; mask >>= 1)
*a++ = ((char*)p)[bytes] & mask? '1': '0';
*a = '\0';
return b;
}
/* END, bytebits.c */
--
pete
------------------------------
Date: Mon, 12 Mar 2001 13:30:53 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.c,comp.os.linux.development.apps,comp.sys.be.programmer,comp.sys.mac.programmer.misc,comp.unix.bsd.freebsd.misc,comp.unix.bsd.misc
Subject: Re: Can linux be trusted?
pete wrote:
>
<snip>
> I've been considering a function called strdup().
> One of my compilers just told me it was ANSI compatible,
It isn't.
> but the other says that it isn't and I can't find it in K&R2,
> so I think it isn't.
Although your method of arriving at it was based on non-normative
sources, your conclusion is nevertheless correct. :-)
> Both compilers are familiar with it though,
> so I think it's just a common extension, like kbhit().
Unlike kbhit(), strdup() is trivial to implement yourself. Here's a
minimalist implementation which trusts that the caller passes in a valid
string.
#include <string.h>
#include <stdlib.h>
char *dupstr(const char *s)
{
char *p = malloc(strlen(s) + 1);
if(p)
strcpy(p, s);
return p;
}
Note the name change. str[a-z]* names are reserved (for external
identifiers, at least). The name str_dup would be okay, if you prefer
it.
> Both compilers say that stdrup() uses a call to malloc(), internally.
Then it probably does, for those compilers.
<snip>
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: why is mmap() unhappy??
Date: 12 Mar 2001 08:51:06 -0500
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>virtual memory goes to any backing store other than swap space. Further,
>most systems allow swap space to be scattered among multiple partitions
>very easily. Doing so for /tmp is difficult and rarely done.
I said tmpfs. Not /tmp. It _is_ swap-backed - that's what tmpfs is
about.
>From Solaris mount_tmpfs(1M):
Maintenance Commands mount_tmpfs(1M)
NAME
mount_tmpfs - mount tmpfs file systems
SYNOPSIS
mount [ -F tmpfs ] [ -o size= sz ] [ -O ] special
mount_point
DESCRIPTION
tmpfs is a memory based file system which uses kernel
resources relating to the VM system and page cache as a file
system.
[snip]
Such beast is often mounted on /tmp (for obvious reasons) but there's
nothing to prohibit mounting it anywhere else. And yes, files on such
fs exist only in RAM+swap and they are mmap()able.
Similar animal is available for *BSD and for Linux (right now you need
-ac to get the full-blown variant, though). I've no idea about AIDX and
HP/UX, though - the latter is pretty backwards and the former... <shudder>
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Subject: Re: why is mmap() unhappy??
From: Dragan Cvetkovic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: 12 Mar 2001 09:03:38 -0500
[EMAIL PROTECTED] writes:
> While not every place does this very normal practice, I do not want to be
> the one to impose "something strange" onto them by distributing a library
> which then causes programs to start eating up tons of /tmp space when all
> their swap space goes unused.
Well, at least Solaris' mmap(2) has a MAP_NORESERVE option telling
operating system not to reserve swap space for the mapped pages. I am not
sure about the others though.
Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: why is mmap() unhappy??
Date: Mon, 12 Mar 2001 14:38:20 -0000
On 12 Mar 2001 08:51:06 -0500 Alexander Viro <[EMAIL PROTECTED]> wrote:
| In article <[EMAIL PROTECTED]>,
| <[EMAIL PROTECTED]> wrote:
|>virtual memory goes to any backing store other than swap space. Further,
|>most systems allow swap space to be scattered among multiple partitions
|>very easily. Doing so for /tmp is difficult and rarely done.
|
| I said tmpfs. Not /tmp. It _is_ swap-backed - that's what tmpfs is
| about.
|
| From Solaris mount_tmpfs(1M):
Please quote the relevant POSIX document.
My point still stands. Things don't work on arbitrary systems, even
if you limit it to BSD, Linux and Solaris, because it still takes a
specific system administration policy decision to configure this.
At the library coding level, this is not an option. But using SysV
shared memory does not require any such decision; it can simply be
used when the system adminstrator has taken no particular action
(such as patching the kernel to remove SysV shared memory).
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: why is mmap() unhappy??
Date: Mon, 12 Mar 2001 14:42:39 -0000
On 12 Mar 2001 09:03:38 -0500 Dragan Cvetkovic <[EMAIL PROTECTED]> wrote:
| [EMAIL PROTECTED] writes:
|> While not every place does this very normal practice, I do not want to be
|> the one to impose "something strange" onto them by distributing a library
|> which then causes programs to start eating up tons of /tmp space when all
|> their swap space goes unused.
|
| Well, at least Solaris' mmap(2) has a MAP_NORESERVE option telling
| operating system not to reserve swap space for the mapped pages. I am not
| sure about the others though.
That's the opposite of what I want. I want program virtual memory to be
backed to swap space by default (I can make it be backed to somewhere else
by option in the program and/or environment easily enough). And I want it
to function without particular actions by the system administrator who
could very well just install a stock system of any BSD flavor, any Linux
distribution, or any commercial vendor UNIX.
SysV shared memory accomplishes this.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: why is mmap() unhappy??
Date: Mon, 12 Mar 2001 14:43:37 +0000
[EMAIL PROTECTED] wrote:
>
> On Mon, 12 Mar 2001 11:49:07 +0000 Kasper Dupont <[EMAIL PROTECTED]> wrote:
> | Alexander Viro wrote:
> ...
> |> That's how shared memory should've been implemented in the first place,
> |> instead of wanking with additional syscalls.
> |
> | I never claimed that SysV shared memory was well
> | designed. But until someone comes up with something
> | better, I will have to live with it.
>
> If it had been specified this way at the beginning:
>
> Open file "/dev/zero" and mmap() calls against the same open instance,
> e.g. that same file descriptor, shall refer to the very same object of
> memory, while mmap() calls against a different open instance in the same
> or a different process, shall refer to a separate memory object. This
> means that if a parent opens "/dev/zero" and then forks a child, and
> then both processes do mmap() to the same relative offset on the same
> open instance (the same file descriptor the child inherited, even if
> its numeric value is changed by dup() or dup2() in either the parent
> or the child) then they each have memory with data shared between
> them. If the relative offsets and size result in partial overlap
> of that virtual memory object, then that part overlapping is shared.
>
> then I think it might have worked quite well to get it into swap space.
> Needs for totally disjoint space can always be easily done by another
> open instance. My big question would be, how hard would it be to do
> this? And would it break anything that expects a different behaviour?
>
Currently you cannot mmap /dev/zero with the MAP_SHARED
flag, it would be nice if that was used to get the
behaviour you suggest. That way we are also sure that
it does not break existing programs.
In my first posting in this thread I already said that
would be a nice feature.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: How to use C++ to develope kernel module?
Date: Mon, 12 Mar 2001 14:51:52 +0000
[EMAIL PROTECTED] wrote:
>
> A non-OO language like C can still be done in an object oriented way,
And there really are lots of object oriented code in
the Linux kernel.
The struct file is actually an object, which among
others have a method named read.
It is called in fs/read_write.c, with all consistency
checks removed the method invocation is done with
this piece of code:
ret = file->f_op->read
(file, buf, count, &file->f_pos);
--
Kasper Dupont
------------------------------
Subject: Re: why is mmap() unhappy??
From: Dragan Cvetkovic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: 12 Mar 2001 09:55:00 -0500
[EMAIL PROTECTED] writes:
> On 12 Mar 2001 09:03:38 -0500 Dragan Cvetkovic <[EMAIL PROTECTED]> wrote:
> | Well, at least Solaris' mmap(2) has a MAP_NORESERVE option telling
> | operating system not to reserve swap space for the mapped pages. I am not
> | sure about the others though.
>
> That's the opposite of what I want. I want program virtual memory to be
> backed to swap space by default (I can make it be backed to somewhere else
> by option in the program and/or environment easily enough). And I want it
> to function without particular actions by the system administrator who
> could very well just install a stock system of any BSD flavor, any Linux
> distribution, or any commercial vendor UNIX.
Oops my bad. But what are you asking for _is_ the default with mmap(). Here
is the rest of the text from Solaris mmap(3C) man page about MAP_NORESERVE:
The MAP_NORESERVE option specifies that no swap space be
reserved for a mapping. Without this flag, the creation of a
writable MAP_PRIVATE mapping reserves swap space equal to
the size of the mapping; when the mapping is written into,
the reserved space is employed to hold private copies of
the data. A write into a MAP_NORESERVE mapping produces
results which depend on the current availability of swap
space in the system. If space is available, the write
succeeds and a private copy of the written page is created;
if space is not available, the write fails and a SIGBUS or
SIGSEGV signal is delivered to the writing process.
Again, I am not sure about the other systems.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
------------------------------
From: Basile STARYNKEVITCH <[EMAIL PROTECTED]>
Subject: Re: why is mmap() unhappy??
Date: 12 Mar 2001 15:22:36 +0100
>>>>> "Dragan" == Dragan Cvetkovic <[EMAIL PROTECTED]> writes:
Dragan> Well, at least Solaris' mmap(2) has a MAP_NORESERVE option
Dragan> telling operating system not to reserve swap space for the
Dragan> mapped pages. I am not sure about the others though.
This is also true of Linux (at least 2.2 and 2.4
kernels). MAP_NORESERVE (defined in <asm/mman.h> and <bits/mman.h>
included by <sys/mman.h>) option is handled in kernel files
/usr/src/linux/mm/mmap.c and /usr/src/linux/mm/mremap.c
If I recall correctly, CMUCL (An opensourced CommonLisp implementation
available on Linux/x86) actually uses MAP_NORESERVE mapping (to
reserve a fixed address space range without using it).
N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.
=====================================================================
Basile STARYNKEVITCH ---- Commissariat � l Energie Atomique * France
DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX
phone: 1,69.08.60.55; fax: 1.69.08.83.95 home: 1,46.65.45.53
email: Basile point Starynkevitch at cea point fr
web perso: http://perso.wanadoo.fr/starynkevitch/basile/
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.c,comp.os.linux.development.apps,comp.sys.be.programmer,comp.sys.mac.programmer.misc,comp.unix.bsd.freebsd.misc,comp.unix.bsd.misc
Subject: Re: Can linux be trusted?
Date: Mon, 12 Mar 2001 15:00:06 +0000
Richard Heathfield wrote:
>
> Unlike kbhit(), strdup() is trivial to implement yourself. Here's a
> minimalist implementation which trusts that the caller passes in a valid
> string.
>
> #include <string.h>
> #include <stdlib.h>
>
> char *dupstr(const char *s)
> {
> char *p = malloc(strlen(s) + 1);
> if(p)
> strcpy(p, s);
> return p;
> }
>
The strdup() function in the standard library also
trusts that it is passed a valid string, though it
does check that malloc did not return NULL.
This is the standard library implementation of
strdup().
char * __strdup (const char *s)
{
size_t len = strlen (s) + 1;
void *new = malloc (len);
if (new == NULL) return NULL;
return (char *) memcpy (new, s, len);
}
--
Kasper Dupont
------------------------------
From: [EMAIL PROTECTED] (Peter da Silva)
Crossposted-To:
comp.lang.c,comp.os.linux.development.apps,comp.sys.be.programmer,comp.sys.mac.programmer.misc,comp.unix.bsd.freebsd.misc,comp.unix.bsd.misc,gnu.gcc
Subject: Re: Can linux be trusted?
Date: 12 Mar 2001 14:32:50 GMT
pete <[EMAIL PROTECTED]>: your email is bouncing. Could you
please mail me with a working email address?
--
`-_-' In hoc signo hack, Peter da Silva.
'U` "A well-rounded geek should be able to geek about anything."
-- [EMAIL PROTECTED]
Disclaimer: WWFD?
------------------------------
Subject: Re: why is mmap() unhappy??
From: Dragan Cvetkovic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: 12 Mar 2001 10:05:12 -0500
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> Dragan> Well, at least Solaris' mmap(2) has a MAP_NORESERVE option
> Dragan> telling operating system not to reserve swap space for the
> Dragan> mapped pages. I am not sure about the others though.
>
>
> This is also true of Linux (at least 2.2 and 2.4
> kernels). MAP_NORESERVE (defined in <asm/mman.h> and <bits/mman.h>
> included by <sys/mman.h>) option is handled in kernel files
> /usr/src/linux/mm/mmap.c and /usr/src/linux/mm/mremap.c
Great, I didn't know that. Thanks. It seems I need to get updated man
pages (the one I have had Linux 1.3.86 from 12 April 1996 in its header).
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
------------------------------
From: [EMAIL PROTECTED] (Gergo Barany)
Crossposted-To:
comp.lang.c,comp.os.linux.development.apps,comp.sys.be.programmer,comp.sys.mac.programmer.misc,comp.unix.bsd.freebsd.misc,comp.unix.bsd.misc
Subject: Re: Can linux be trusted?
Date: 12 Mar 2001 15:07:27 GMT
Kasper Dupont <[EMAIL PROTECTED]> wrote:
> Richard Heathfield wrote:
> > Unlike kbhit(), strdup() is trivial to implement yourself. Here's a
> > minimalist implementation which trusts that the caller passes in a valid
> > string.
> >
> > #include <string.h>
> > #include <stdlib.h>
> >
> > char *dupstr(const char *s)
> > {
> > char *p = malloc(strlen(s) + 1);
> > if(p)
> > strcpy(p, s);
> > return p;
> > }
> >
>
> The strdup() function in the standard library also
What "standard library"? Before you answer, think about the
multitude of groups this is crossposted to.
> trusts that it is passed a valid string, though it
> does check that malloc did not return NULL.
Richard's code does that, too. Read it again.
Gergo
--
Every word is like an unnecessary stain on silence and nothingness.
-- Beckett
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
