From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9bf232817e79377293a7e9aa834f320c@gmx.de> To: lucio@proxima.alt.za, 9fans@9fans.net Date: Thu, 2 Apr 2009 14:50:18 +0200 From: cinap_lenrek@gmx.de In-Reply-To: <6c529a9785a1131ce815f5fa79593321@proxima.alt.za> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-qlekhjpjgbidcpjqfvmnyzbfus" Subject: Re: [9fans] segfree() - more details? Topicbox-Message-UUID: d0a93744-ead4-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-qlekhjpjgbidcpjqfvmnyzbfus Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think russ has added this functionality to his kernel. The sourcecode of his linuxemu had commented out lines that used special segname with a filename to map elf-files into memory. /n/sources/contrib/rsc/linuxemu/linuxemu.c: /* * mmap, if it were handled by the kernel * void* _mmap(char *name) { void *v; Dir *d; char *buf; vlong len; if((d = dirstat(name)) == nil || d->length == 0){ free(d); return nil; } len = d->length; free(d); buf = malloc(strlen(name)+10); if(buf == nil) return nil; sprint(buf, "file!%s", name); v = (void*)segattach(0, buf, nil, len); print("v=%lx file=%s len=%ld\n", v, name, len); free(buf); if(v == (void*)-1) return nil; return v; } void* _mmapfd(int fd) { void *v; Dir d; char buf[30]; if(dirfstat(fd, &d) < 0 || d.length == 0) return nil; snprint(buf, sizeof buf, "file!/fd/%d", fd); v = (void*)segattach(0, buf, nil, 4096); if(v == (void*)-1) return nil; return v; } */ But you cant use it without increasing the maximum segment count per process to work with dynamicly linked linux programs. /* * process memory segments - NSEG always last ! */ enum { SSEG, TSEG, DSEG, BSEG, ESEG, LSEG, SEG1, SEG2, SEG3, SEG4, NSEG }; SSEG, TSEG, DSEG and BSEG are used already. That gets you at maximum 6 more slots. Also, having a look at a typical linux memory map, data and mmaped files are not separate continously mapped but alternating. term% acid -l linuxemu.acid 264 /proc/264/text:386 plan 9 executable /sys/lib/acid/port /sys/lib/acid/386 acid: umem(Current()) 1 0x08048000-0x080dc000 0x00000000@/bin/bash 1 0x080dc000-0x080e2000 0x00093000@/bin/bash 1 0x080e2000-0x080e6000 *ANON* 1 0x080e6000-0x080fc000 0x00000000@/lib/ld-2.3.2.so 1 0x080fc000-0x080fd000 0x00015000@/lib/ld-2.3.2.so 1 0x080fd000-0x080fe000 *ANON* 1 0x08103000-0x08139000 0x00000000@/lib/libncurses.so.5.4 1 0x08139000-0x08142000 0x00035000@/lib/libncurses.so.5.4 1 0x08142000-0x08144000 0x00000000@/lib/libdl-2.3.2.so 1 0x08144000-0x08145000 0x00002000@/lib/libdl-2.3.2.so 1 0x08145000-0x0826d000 0x00000000@/lib/libc-2.3.2.so 1 0x0826d000-0x08275000 0x00127000@/lib/libc-2.3.2.so 1 0x08275000-0x08278000 *ANON* 1 0x08278000-0x0827d000 *ANON* 1 0x0827d000-0x08284000 0x00000000@/lib/libnss_compat-2.3.2.so 1 0x08284000-0x08285000 0x00006000@/lib/libnss_compat-2.3.2.so 1 0x08285000-0x08297000 0x00000000@/lib/libnsl-2.3.2.so 1 0x08297000-0x08298000 0x00011000@/lib/libnsl-2.3.2.so 1 0x08298000-0x0829a000 *ANON* 1 0x0829a000-0x082a2000 0x00000000@/lib/libnss_nis-2.3.2.so 1 0x082a2000-0x082a3000 0x00007000@/lib/libnss_nis-2.3.2.so 1 0x082a3000-0x082ab000 0x00000000@/lib/libnss_files-2.3.2.so 1 0x082ab000-0x082ac000 0x00008000@/lib/libnss_files-2.3.2.so 1 0x082ac000-0x082c1000 *ANON* 2 0xdefed000-0xdeffe000 *ANON* So you would need separate memory segments in between too. Linuxemu uses a fixed count of segments to emulate the linux address space and just reads in mapped files at the right location. term% cat /proc/264/segment Stack defff000 dffff000 1 Text R 00001000 00020000 2 Shared 00020000 00029000 2 Shared 00029000 00054000 2 Bss ceffe000 deffe000 1 Bss 08048000 082c1000 1 Shared 06000000 06001000 1 This works because here is just one fixed address mapping for the first binary (that is where i create the segment) and all further fixed mapping are relative to some other dynamic mapping so i just expand the segment carefully. The area where glibc maps stacks is fixed size and works because plan9 overcommits memory for segments. (you cant grow segments down) -- cinap --upas-qlekhjpjgbidcpjqfvmnyzbfus Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-bounces+cinap_lenrek=gmx.de@9fans.net> X-Flags: 0000 Delivered-To: GMX delivery to cinap_lenrek@gmx.de Received: (qmail invoked by alias); 02 Apr 2009 09:21:37 -0000 Received: from gouda.swtch.com (EHLO gouda.swtch.com) [67.207.142.3] by mx0.gmx.net (mx007) with SMTP; 02 Apr 2009 11:21:37 +0200 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from <9fans-bounces@9fans.net>) id 1LpJ22-0002B9-0d; Thu, 02 Apr 2009 09:16:18 +0000 Received: from [192.96.32.140] (helo=mutter.proxima.alt.za) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from ) id 1LpJ1y-0002B4-5y for 9fans@9fans.net; Thu, 02 Apr 2009 09:16:15 +0000 Received: from plan9.phyrql.alt.za (gprs01.rb.mtnns.net [41.208.50.160] (may be forged)) (authenticated bits=0) by mutter.proxima.alt.za (8.14.3/8.14.3) with ESMTP id n329DQjN017111 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <9fans@9fans.net>; Thu, 2 Apr 2009 11:13:44 +0200 (SAST) Message-ID: <6c529a9785a1131ce815f5fa79593321@proxima.alt.za> To: 9fans@9fans.net Organization: Proxima Research & Development Date: Thu, 2 Apr 2009 11:13:18 +0200 From: lucio@proxima.alt.za MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] segfree() - more details? X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lucio@proxima.alt.za, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+cinap_lenrek=gmx.de@9fans.net X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Mail was not recognized as spam) X-GMX-UID: lrvhfREzRkkeD4s90GRqj2BmdWkvKBPX The rather tantalising: Segfree tells the system that it may free any physical mem- ory within the span [va, va+len), but leaves that portion of the process's address space valid. The system will not free any memory outside that span, and may not free all or even any of the specified memory. If free'd memory is later ref- erenced, it will be initialized as appropriate for the seg- ment type. For example data and text segments will be read from the executable file, and bss segments will be filled with zero bytes. in segattach(2) suggests that there is some mechanism to associate disk file portions with memory segments (that being what Unix's MMAP does, roughly), but falls short of explaining how this association is established. I presume there is documentation for this elsewhere that ought to be mentioned in the above. Also, I'm too dense to grasp the exact intent of segfree(2) as implied in the above description, but I'm sure once I understand it I'll be able to make use of it in my efforts to make Plan 9 understand ELF directly. So if anyone can point me to the right place, I'd greatly appreciate it. I have Nemo's "commentary" that has proved invaluable to my understanding of the Plan 9 kernel, but I always have to find it by inspection because its filename is not very self-explanatory. I guess I ought to change that, but I'm the conservative type: does anyone remember its name? ++L --upas-qlekhjpjgbidcpjqfvmnyzbfus--