From: Martin Maletinsky <maletinsky@scs.ch>
To: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
Cc: kernelnewbies@nl.linux.org, linux-mm@kvack.org
Subject: Re: Changes in vm_operations_struct 2.2.x => 2.4.x
Date: Thu, 09 Aug 2001 09:02:23 +0200 [thread overview]
Message-ID: <3B72357E.1BF85B4B@scs.ch> (raw)
In-Reply-To: <20010809004910.C1200@nightmaster.csn.tu-chemnitz.de>
Hi Ingo,
Thank's for your reply. The details are as follows:
My module allocates a block of memory, and exports that block to user space processes, by registering as a character device and implementing a mmap file operation, so that
user space processes can map that memory block into their virtual address space by calling mmap().
A block of memory may only be mapped through mmap() by one process, subsequent mmap() calls to map that memory block should fail, until the block is no longer mapped into
any processes memory (note, that following fork() calls the block may be mapped into the virtual memory space of several processes simultaneously, but this is OK).
It would have simplified my job, if I could have assumed that a process has either the entire block mapped into it's virtual address space, or that it has none of the block
mapped at all (i.e. there are never fragment's of the block mapped into a process' virtual address space). To ensure that at the time of mapping, I would have checked the
length of the processes memory region (vma->vm_end -vma->vm_start) in the module's mmap() file operation. To prevent partial unmapping of the block, I would have registered
an unmap() vm_area operation with the vm_area_struct in the module's mmap() file operation. The unmap() vm_area operation would have checked the addr and len parameter, to
detect partial unmappings of the memory block by a user process. In case of a partial unmapping of the memory block, unmap() would have simply sent a SIGKILL to the
process.
Regards
Martin
Ingo Oeser wrote:
> On Fri, Aug 03, 2001 at 10:01:22AM +0200, Martin Maletinsky wrote:
> > Does anyone know the reason why the number of operations in
> > vm_operation_struct has been reduced?
>
> Al Viro reduced it, because nobody used them for several years.
> Nobody complained after removing them, also.
>
> Maybe you can explain more, what you try to do in your module and
> people can help you.
>
> Regards
>
> Ingo Oeser
> -
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> IRC Channel: irc.openprojects.net / #kernelnewbies
> Web Page: http://www.kernelnewbies.org/
--
Supercomputing System AG email: maletinsky@scs.ch
Martin Maletinsky phone: +41 (0)1 445 16 05
Technoparkstrasse 1 fax: +41 (0)1 445 16 10
CH-8005 Zurich
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2001-08-09 7:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-03 8:01 Martin Maletinsky
2001-08-08 22:49 ` Ingo Oeser
2001-08-09 7:02 ` Martin Maletinsky [this message]
2001-08-09 12:24 ` Thomas Hofer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B72357E.1BF85B4B@scs.ch \
--to=maletinsky@scs.ch \
--cc=ingo.oeser@informatik.tu-chemnitz.de \
--cc=kernelnewbies@nl.linux.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox