From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ronald G Minnich To: <9fans@cse.psu.edu> In-Reply-To: <20011206072931.90885199E8@mail.cse.psu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [9fans] My "plan9" stuff for Linux (last reference, I promise) Date: Thu, 6 Dec 2001 09:12:24 -0700 Topicbox-Message-UUID: 303ad7d6-eaca-11e9-9e20-41e7f4b1d025 v9fs.sourceforge.net, source and docs. Now builds on redhat and the demo works (i.e. you can run /bin/cat and it will read the file from the "9p" server). More details on the web page. VFS work for 2.4 in progress (you can't do exec unless you have a VFS). There was major dry rot from 2.5 years of storage and the upgrade from redhat 5 to redhat 7 is still not quite done. mail list: majordomo@lanl.gov, subscribe v9fs Amusement time, I learned just how much shared libraries suck. So nice that Plan 9 did not fall down that rathole. Masataka Ohta, where are you now? You were right all along. Here's a simple example: /bin/cat /bin/cat /etc/hosts: opens 18 files (if no error); 323 symbol fixups. many of the symbol fixups are for identical function (e.g. open, open64, __open, __libc_open, etc). Some fraction of gcc lib is 64-bit-ized, some is not. There are > 5 different symbol versions supported: 2.0, 2.1, 2.1.3, 2.2, 2.2.something. This is in one library. So the version number 2.2.2 on the file for libc-2.2.2.so is not really at all useful, except maybe as a ceiling on version number. Library-specific optimization: there is now a /lib/i686, and a /lib/i386. Libraries are compiled different ways, and then you link to the right one for your cpu. It's getting to the point where you no longer can make the case that shared libraries save lots of space (unless you have a badly designed windowing system or something). Yikes, my brain hurts. ron