>>>>> "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.
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.
pgptZHBP7OTHo.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
