Re: [9fans] porting from vs. porting to Plan 9

[Geoff Collyer <geoff@collyer.net>]

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 
	/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 

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 ¾MB
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.