First, a note about versions...

Does the kernel you use really say "NetBSD 1.2A"?  or "NetBSD
1.2_ALPHA"?  Please don't confuse them...  1.2A is "-current after
1.2 (i.e. the trunk)," and 1.2_ALPHA is "-current before 1.2 (i.e.
1.2 revision control branch."

You might actually have a kernel that says 1.2A, because of a slight
screw-up in the way the transition to the 1.2 branch was done.  If you
do, i strongly suggest you update your sources again, so you're on
1.2_ALPHA...  There are some extensive and mostly-untested changes in
1.2A at this time.


> After compiling the latest kernel I ended up with a file being about
> 300kb smaller then the previous ones, also I have enabled some more
> options.
> 
> Has the latest code undergone some major surgery with a lot of stuff
> being cut out (properbly debugging code etc.) or is the new code just
> that much more efficient?

Well, i turned on optimization in the kernel makefiles...  That could
make a difference, but on my systems it made the kernels i run
_larger_...

Nothing big has been cut that I can think of.  (That's not to say that
things haven't gotten more efficient; i can think of several that
have...  but none should seriously impact code size.)


> Also, how difficult is it to port some of the more common isa/pci
> devices to NetBSD/alpha? I was thinking of multiserial cards,
> sound cards etc... 

Depends on what you're talking about, right now.

General rules, for now:
	ISA + DMA:	"don't even bother."
	ISA - DMA:	"probably not too hard."
	PCI, EISA:	"probably not too hard."

When i say 'probably not too hard,' what i mean is:
	(1) convert the drivers to use the 'bus' macros for memory
	    and I/O mapping and access, and
	(2) if they use bus mastering DMA, hack them to do the
	    right thing for the alpha instead of vtophys().  (There's
	    a routine to help.  take a look in the ncr, de drivers for
	    examples.) 

ISA boards using DMA and boards using the motherboard DMA controllers
for programmed DMA are basically out of the question at this point,
because of the way the ISA address space is managed (in hardware).  I
hope to address this some time after 1.2 is released.


BTW: proof that drivers can be ported w/o _too_ much trouble: Matt
Thomas now has his 'pdq' (DEC FDDI) driver running on the Alpha with
PCI, EISA, and TurboChannel busses (i.e. all of the busses that he
could support 8-).  (Actually, the driver as it is in the source tree
should do that, but there are some fixes that need to be checked in
before the EISA version can work on the AlphaStation 600, and i
wouldn't suggest using it as an example for the DMA vtophys() hack
mentioned above in any case. 8-) 


> Also, has someone managed to get INN (InterNetNews) and
> Arena(WebBrowser) to work? Would be very interested to hearing from
> you!!! 

A couple of months i tried to build Arena.

It took a long time and a fair bit of work to get a binary to build,
and that binary would core if asked to do anything interesting.
Looking at the code, it's not a big surprise...  I wasn't particularly
impressed, to be quite honest.

I've never tried INN, but since people have undoubtedly made it work
on NetBSD/i386 (or similar systems like BSD/OS), and people have
undoubtedly made it work on the Alpha, it couldn't be too hard to make
it go.  8-)



chris