From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7dcb175c4b441d42d3050f09e0eb74a0@collyer.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] porting from vs. porting to Plan 9 From: Geoff Collyer In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Sat, 18 Oct 2003 04:09:18 -0700 Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 722fcf6e-eacc-11e9-9e20-41e7f4b1d025 There are obvious driver interface mismatches between Linux and Plan 9. Linux has ioctl, mmap and select entry points; Plan 9 drivers present a file system interface. I think we can ignore mmap and select, and probably some sort of class drivers can provide the glue between a file system interface and the Linux drivers, including turning I/O on ctl files into calls on the ioctl entry points, though I don't know if they are sufficiently standardised across drivers for that to work with tweaks for each Linux driver. My impression is that Linux has more drivers because it has more contributors. Here are some numbers from systems I have access to. RedHat 7.3: ; pwd=20 /usr/src/linux-2.4/drivers ; du -sk 98820 . ; du -a | wc -l 4149 OpenBSD 3.3: ; pwd /usr/src/sys ; du -sk scsi arch/i386/isa arch/i386/eisa arch/i386/pci | addup 1 946 ; du -a scsi arch/i386/isa arch/i386/eisa arch/i386/pci | wc -l 106=20 The Linux numbers look incredible (and they exclude object files), but they've got busy little typists working for them: -rw-r--r-- 1 root root 632394 Sep 7 2001 qlogicfc_asm.c -rw-r--r-- 1 root root 741668 Aug 18 11:33 advansys.c I drew up a list of obvious drivers that one could write: Adaptec PCI SCSI; various gigabit Ethernet cards; USB, Bluetooth and Firewire generic (protocol), device class and controller drivers; flash memory widgets; random sound chipsets; random VGA chipsets; and perhaps serial ATA. I must admit that I'm not currently in need of any of these, though that could change if I bought a laptop. Some of these may just be checklist items that would make people feel warm and fuzzy, but also probably some people could make use of others (notably VGA and ether). As for C++, X and configure, my sense is that implementing X (even from scratch) will add a lot of bulk to the system and I wonder how much use it would get other than web browsing (about which, see below). C++ is another source of bulk. Is there a cfront-like C++-to-C translator extant for the current version of C++? I've been pretty happy with vnc to Unix machines that also run u9fs for web browsing (I use a private 100Gb/s Ethernet for this). Likewise, when I need to use some GNUware, it's much simpler to just install it on a Unix system and access it remotely. I think trying to make GNUware runnable out of the box will contort the system until it looks like a GNUish lunix system (e.g. Linux). I installed the latest Bochs emulator last night; this is the size of its configure script: ; wc bochs/configure 23851 84792 701647 bochs/configure The sheer size of configure scripts is bad enough, but they are stuffed full of bad AI and knowledge of lunix path names and other intimate details. Some examples: if your C compiler is named pcc, configure won't find it and will quit; if your C compiler generates .8 files instead of .o files, configure will quit; if your include files aren't in /usr/include, configure won't find them. configure does all this sniffing and probing to determine things that are largely irrelevant to its real job, which seems to be converting prototype makefiles into usable makefiles and guessing at the local OS configuration, but if any of a long list of tests fail, it just quits and leaves you unable to even try to run make. For simple programs, "cc -I. *.c" usually works, but sometimes the authors have provided complicated trees of include files that have to be searched in a particular order. (Speaking of which, here are numbers from RedHat 7.3: : new; cd /usr/include : new; du -sk 81396 . : new; du -a | wc -l 9672 And these include files are full of #if, #ifdef and games with #define.) The problem that I believe configure was designed to solve (divergence of Unices during the Unix Wars) is going away and all the Unix vendors are making their systems compliant with POSIX and SUS and the like, so configure's raison d'etre is vanishing, yet configure scripts are getting bigger and more ludicrous. Maybe it's getting bad enough that lots of people need to start telling the GNU project to just aim for POSIX/SUS/whatever and get rid of configure and its associated religious machinery (autoconf, automake, etc.). The alternative, for us, seems to be to make Plan 9 look enough like Linux that =C2=BEMB configure scripts can poke, prod, sniff and make false deductions based on bogus assumptions, and yet happily build GNUware. And once started down that road, it just gets worse. More and more GNUware now wants perl just to build, never mind run. And you may need GNU's special make too, and on and on.