Miles Nordin wrote: >>>>>> "s" == Steve <[EMAIL PROTECTED]> writes: >>>>>> > > s> About freedom: I for sure would prefere open source drivers > s> availability, let's account for it! > > There is source for the Intel gigabit cards in the source browser. > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/e1000g/ > > There is source for some Broadcom gigabit cards (bge) > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/bge/ > > but they don't always work well. There is a closed-source bcme driver > for the same cards downloaded from Broadcom that Benjamin Ellison is > using instead. > > I believe this is source an nForce ethernet driver (!): > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/nge/ > > but can't promise this is the driver that actually attaches to your > nForce 570 board. Also there's this: > > http://bugs.opensolaris.org/view_bug.do?bug_id=6728522 > > wikipedia says the forcedeth chips are crap, and always were even with > closed-source windows drivers, but they couldn't be worse than > broadcom. > > I believe this source goes with the Realtek 8169/8110 gigabit MAC: > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/rge/rge_main.c > > On NewEgg many boards say they have Realtek ethernet. If it is 8169 > or 8110, that is an actual MAC chip. usually it's a different number, > and they are talking about the PHY chip which doesn't determine the > driver. >
One of our engineers has also just updated the code to support the Realtek 8111c version chip. That should be in build 95 of Nevada. > This is Theo de Raadt's favorite chip because Realtek is cooperative > with documentation. However I think I've read on this list that chip > is slow and flakey under Solaris. > > > If using the Sil3124 with stable solaris, I guess you need a very new > release: > > http://bugs.opensolaris.org/view_bug.do?bug_id=2157034 > > The other problem is that there are different versions of this chip, > so the lack of bug reports doesn't give you much safety right after a > new chip stepping silently starts oozing into the market, unmarked by > the retailers. > > It looks like the SATA drivers that come with source have their source > here: > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/sata/adapters/ > > The ATI chipset for AMD/AM2+ is ahci (but does not work well. you'll > need an add-on card.) I assume the nForce chipset is nv_sata, which > I'm astonished to find seems to come with source. And, of course, > there is Sil3124! > > The sil3112 driver is somewhere else. I don't think you should use > that one. I think you should use a ``SATA framework'' chip. > > Marvell/thumper and LSI Logic mpt SATA drivers are closed-source, so > if you want a system where most drivers come with source code you > really need to build your own, not buy one of the Sun systems. but > there is what looks like a BSD-licensed LSI Logic driver here: > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/mega_sas/ > > so, I am not sure what is the open/closed status of the LSI board. I > was pretty sure the one in the Ultra 25 is the mpt and attaches to the > SCSI/FC stack, not the SATA stack, and was closed-source. so maybe > this is another case of two drivers for one chip? or maybe I was > wrong? > > I'm not sure the ``SATA framework'' itself is open-source. I believe > at one time it was not, but I don't know where to find a comprehensive > list of the unfree bits in your OpenSolaris 2008.5 CD. > > I'm hoping if enough people rant about this nonsense, we will shift > the situation. For now it seems to be in Sun's best interest to be > vague about what's open source and what's not because people see the > name `Open' in OpenSolaris and impatiently assume the whole thing is > open-source like most Linux CD's. We should have a more defensive > situation where their interest is better-served by being very detailed > and up-front about what's open and what isn't. > > > I haven't figured out an easy way to tell quickly which drivers are > free and which are not, even with great effort. Not only is an > overall method missing, but a stumbling method does not work well > because there are many decoy drivers which don't actually attach > except in circumstances other than yours. I need to find in the > source a few more tables, the PCI ID to kernel module name mapping, > and the kernel module name to build tree mapping. I don't know if > such files exist, or if the only way it's stored is through execution > of spaghetti Makefiles available through numerous scattered ``gates''. > Of course this won't help root out unfree ``frameworks'' either. > > For non-driver pieces of the OS, this is something the package > management tool can do on Linux and BSD, albeit clumsily---you feed > object filenames to tools like rpm and pkg_info, and they slowly > awkwardly lead you back to the source code. > > -----8<----- > zephiris:~$ pkg_info -E `which mutt` > /usr/local/bin/mutt: mutt-1.4.2.3 > mutt-1.4.2.3 tty-based e-mail client > zephiris:~$ pkg_info -P mutt-1.4.2.3 > Information for inst:mutt-1.4.2.3 > > Pkgpath: > mail/mutt/stable > > zephiris:~$ cd /usr/ports/mail/mutt/stable > zephiris:/usr/ports/mail/mutt/stable$ make patch > [...] > zephiris:/usr/ports/mail/mutt/stable$ cd w-* > zephiris:/usr/ports/mail/mutt/stable/w-mutt-1.4.2.3$ ls > bin mutt-1.4.2.3 systrace.policy > zephiris:/usr/ports/mail/mutt/stable/w-mutt-1.4.2.3$ cd mutt-1.4.2.3/ > zephiris:/usr/ports/mail/mutt/stable/w-mutt-1.4.2.3/mutt-1.4.2.3$ ls > ABOUT-NLS config.sub makedoc.c pgppacket.c > BEWARE configure mapping.h pgppacket.h > [...] > config.h.in mailbox.h pgplib.h > config.h.in~ main.c pgpmicalg.c > zephiris:/usr/ports/mail/mutt/stable/w-mutt-1.4.2.3/mutt-1.4.2.3$ > -----8<----- > > That is not actually very awkward, but I sort of imagined an ubertool > that parasitically snoops on 'make's internals and can give you a list > of the actual filenames that a binary object depended on. It would > save lots of time, and OpenBSD ports above falls short of that, but > it's still pretty good when the individual packages aren't too big. > > At least on NetBSD pkgsrc, they can also accept a filename and > immediately tell you the license on that file: > > castrovalva:~$ pkg_info -B -F `which xv` |grep ^LICENSE= > LICENSE=xv-license > > <plug> > and pkgsrc runs on Solaris, too! > </plug> > > Their installer/packager is integrated with their build system, so it > keeps some binding between objects and the source (or at least the > source subtree) used to build them. I like this, but it doesn't seem > like the Solaris installer, the old one nor the OpenSolaris/Indiana > one, embraces this idea of preserving some binding between the > installed system and the build tree. > > s> I would like to choose a botherboard with everything > s> needed onboard. > > The 780G/SB700 is then not possible: > > http://bugs.opensolaris.org/view_bug.do?bug_id=6711742 > > also you have to be careful about what Ethernet they give you since it > isn't built into the ATI chip. > > s> And, if better I'm open also to intel! > > from intel you can possibly get onboard AHCI that works, and the intel > gigabit MAC, and 16GB instead of 8GB RAM on a desktop board. Also the > video may be better-supported. but it's, you know, intel. > > ------------------------------------------------------------------------ > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
