On 2012-01-27 16:45, James Carlson wrote:
Robin Axelsson wrote:
On 2012-01-27 15:32, James Carlson wrote:
What NWAM is supposed to do is configure only one usable interface
(guided by user selection criteria) for the system. The fact that you
got multiple interfaces configured is indeed an anomaly, and one I can't
explain. I don't know how you got there in the first place. It
shouldn't have happened.
I don't agree with you on that. Many motherboards come with dual
ethernet ports (i.e. dual NICs, I have counted the chips myself) and it
is not uncommon with laptops with one wired ethernet interface and a
wireless one. So as you said, there is the potential risk of
interference between the two interfaces even though one may not even be
connected.
Don't agree how?
That systems with multiple interfaces are an anomaly, but maybe that's
not what you meant.
NWAM's original mission in life was to make sure that only one interface
was configured at a time, regardless of how many might be available.
I'm pretty darned sure that's true, because I was involved in that project.
That's sort of the whole point. NWAM looks over the available
interfaces, figures out which ones are usable, then applies a set of
policies to determine which one of all of those will be used. It then
disables the others and properly configures the rest of the system to
use that one chosen interface. If conditions change, then it
reevaluates the situation.
The canonical example would be a laptop with wired and wireless
interfaces. The default rule would be to use wired if it's connected
and working, and otherwise use the wireless interface. Not both at any
one time.
Things changed a bit in the next incarnation of NWAM, and I wasn't as in
touch with that one. However, the fundamental design goal of producing
a working configuration -- and avoiding known unworkable configurations
-- wasn't abandoned. So, what you saw was either a bug or a
misconfiguration of some sort, and you'd need to find someone who knows
more about that second NWAM.
That sounds backwards to me. If a buggy driver exists, then the bugs
should be fixed, or the driver should be discarded. There's no reason
on Earth to have some other bit of software "warning" users about
someone else's software design failures, whether real or otherwise. At
best, that other software would just become a repository of uselessly
independent misjudgment -- as new, unknown buggy drivers are written and
old ones are repaired.
True, but what do you do when *all* you've got is a buggy driver that
_may_ work well on your system? Either you use the driver or you go get
a network card that is proven to work well with Solaris/OpenIndana. The
thing is that a substantial part of the development of OI depends on the
charity of willing developers and their spare time, so you have to make
the best out of what you have at your disposal.
I think we have differing viewpoints on system architecture.
To me, it would be a very poor design choice to embed detailed knowledge
of some driver writer's parental marital status into an independent part
of the system.
If all compromised drivers exposed a "I'm potentially garbage" flag,
then, fine, that independent part could read that flag and do whatever
it wants based on it. But merely reading the letters "rge" and deciding
to impugn the connection based on some history or accusations strikes me
as untenable.
The only opinion that I have is that it should work and reliably so. The
rge driver is apparently buggy and that's what people say about it in
mailing lists. It is included with the OI distribution/repository. If I
had the time and knowledge I would try and fix it myself but
unfortunately I don't.
I have told myself to get to learn dtrace someday but I guess that I
will have to get through the "Solaris Internals" to even be able to
understand the output it generates.
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
