From: "Steve Schmidtke" <steve_schmidtke@hotmail.com>
To: jdike@addtoit.com
Cc: User-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] filemap feature 2.4.22-5um
Date: Tue, 14 Oct 2003 22:58:34 +0000 [thread overview]
Message-ID: <BAY7-F10EP60A1ozvkh00011910@hotmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]
Jeff Dike wrote:
>Why so pessimistic? I like filemap - IIRC, i suggested it.
Yeah, but finding the right interface to express it is tough. I don't even
want to go in the whole *in* OS_ layer/*above* os_* layer argument again. :)
I am also thinking that the filemap database should be generalized so that
any translation can be supported - like an "xlate" table that can map Unix
filenames to DOS filenames...
>I'd also like people to use this to see what's missing, if anything, and to
>get any improvements on the command line syntax.
Just so SKAS users don't feel left out, I've attached a small patch that
adds a "mm" table to filemap for chrooted SKAS mode operation. Just apply
it after the first patch.
The following example shows how to use this patch to set up a chrooted SKAS
UML with 20 available process slots:
chroot /home/uml /linux mem=32M filemap=mm,30-49 \
30>/proc/mm 31>/proc/mm 32>/proc/mm 33>/proc/mm 34>/proc/mm \
35>/proc/mm 36>/proc/mm 37>/proc/mm 38>/proc/mm 39>/proc/mm \
40>/proc/mm 41>/proc/mm 42>/proc/mm 43>/proc/mm 44>/proc/mm \
45>/proc/mm 46>/proc/mm 47>/proc/mm 48>/proc/mm 49>/proc/mm \
filemap=file,25,/proc/mm 25>/proc/mm \
filemap=vm,20 20<>/dev/shm/vm-$$.0 con=null con0=fd:0,fd:1
Note the dummy "file" table entry for /proc/mm. This is needed so the boot
test for /proc/mm succeeds.
ISSUE: The UML will panic if it runs out of /proc/mm fds.
ISSUE: What side effects does re-using an address space have?
TODO: Make the filemap lookup routine re-entrant safe.
Comments? Concerns?
Steve Schmidtke
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
[-- Attachment #2: filemap5-02.diff --]
[-- Type: application/octet-stream, Size: 2149 bytes --]
--- linux-2.4.22-5um.fm/arch/um/kernel/filemap.c Tue Oct 14 10:44:50 2003
+++ linux-2.4.22-5um.new/arch/um/kernel/filemap.c Tue Oct 14 13:56:37 2003
@@ -502,6 +502,11 @@
.entries = NULL,
.ops = &fm_ops_pool,
},
+ {
+ .name = "mm",
+ .entries = NULL,
+ .ops = &fm_ops_pool,
+ },
};
static struct filemap_table* filemap_get_table(const char* table_name)
--- linux-2.4.22-5um.fm/arch/um/kernel/skas/process.c Tue Oct 14 10:44:31 2003
+++ linux-2.4.22-5um.new/arch/um/kernel/skas/process.c Tue Oct 14 14:28:39 2003
@@ -27,6 +27,8 @@
#include "skas_ptrace.h"
#include "chan_user.h"
+#include "filemap.h"
+
int is_skas_winch(int pid, int fd, void *data)
{
if(pid != getpid())
@@ -340,12 +342,27 @@
int new_mm(int from)
{
struct proc_mm_op copy;
- int n, fd = os_open_file("/proc/mm",
+ int n, fd;
+
+ /* use the raw access since /proc/mm opens a new file every time */
+ fd = filemap_access("mm", "/proc/mm");
+ if(fd >= 0) {
+ printk("filemap aquire: fd=%d, file=%s\n", fd, "/proc/mm");
+ goto handle_fd;
+ }
+
+ /* if /proc/mm exists, the same fd would be returned over and over */
+ if(filemap_access("file", "/proc/mm") >= 0) {
+ return(-1);
+ }
+
+ fd = os_open_file("/proc/mm",
of_cloexec(of_write(OPENFLAGS())), 0);
if(fd < 0)
return(fd);
+handle_fd:
if(from != -1){
copy = ((struct proc_mm_op) { .op = MM_COPY_SEGMENTS,
.u =
--- linux-2.4.22-5um.fm/arch/um/kernel/skas/mmu.c Tue Oct 14 10:44:31 2003
+++ linux-2.4.22-5um.new/arch/um/kernel/skas/mmu.c Tue Oct 14 16:48:36 2003
@@ -21,14 +21,23 @@
mm->context.skas.mm_fd = new_mm(from);
if(mm->context.skas.mm_fd < 0)
+#if 1
panic("init_new_context_skas - new_mm failed, errno = %d\n",
mm->context.skas.mm_fd);
+#else /* DON'T PANIC */
+ return(mm->context.skas.mm_fd);
+#endif
return(0);
}
void destroy_context_skas(struct mm_struct *mm)
{
+ /* filemapped files will return something other than -ENOENT */
+ if(filemap_release("mm", mm->context.skas.mm_fd) != -ENOENT) {
+ return;
+ }
+
os_close_file(mm->context.skas.mm_fd);
}
next reply other threads:[~2003-10-14 22:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-14 22:58 Steve Schmidtke [this message]
2003-10-15 8:43 ` [uml-devel] filemap feature 2.4.22-5um azu
2003-10-15 20:13 ` Jeff Dike
-- strict thread matches above, loose matches on Subject: below --
2003-10-18 17:15 Steve Schmidtke
2003-10-18 16:34 BlaisorBlade
2003-10-18 1:31 Steve Schmidtke
2003-10-18 12:37 ` Henrik Nordstrom
2003-10-18 21:57 ` Goetz Bock
2003-10-18 22:29 ` Henrik Nordstrom
2003-10-18 14:27 ` Adam Heath
2003-10-14 14:08 Steve Schmidtke
2003-10-14 3:54 Steve Schmidtke
2003-10-13 5:15 ` Jeff Dike
2003-10-14 6:19 ` Doug Dumitru
2003-10-17 17:14 ` Adam Heath
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=BAY7-F10EP60A1ozvkh00011910@hotmail.com \
--to=steve_schmidtke@hotmail.com \
--cc=User-mode-linux-devel@lists.sourceforge.net \
--cc=jdike@addtoit.com \
/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