Date: Mon, 21 Jul 1997 10:44:11 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Mikael Karpberg <karpen@ocean.campus.luth.se> Cc: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies), current@FreeBSD.ORG Subject: Re: I am contemplating the following change... Message-ID: <28734.869507051@time.cdrom.com> In-Reply-To: Your message of "Mon, 21 Jul 1997 16:41:09 %2B0200." <199707211441.QAA09641@ocean.campus.luth.se>
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok... This just might seem like a silly question, but Jordan wanted to take > away the double devices. Why? > > ed0 == 300 / 10 > ed1 == 280 / 5 > > This seems to be a really great solution, since it satisfies both sides with > a good default. It will make installing easier for everyone. Now what could > possibly be good about removing the double entry? Because I think the basic idea we're trying to push with the whole userconfig thing (and its associated docs) are that you should always edit ed0 to match your card, whatever that might be, and if it falls to ed1 then something is _wrong_ and you should go back and edit the entry for ed0 again. Also, with the settings as they currently stand today, you rarely get fall back behavior which actually helps the user - far from it. What happens instead is that ed1's port value matches but the IRQ value is still wrong, and while the user sees a "probe" for ed1 and an entry in all the relevant selection menus (further leading them to feel that things are fine), things hang up later when they actually go out and try to use the card. Timeouts, hangs, very confused users. If, on the other hand, you didn't even show them an ethernet card as an option, nor did they see a probe message for it at boot time, it's be a strong indication to them that they need to go fix this problem first. When the ed1: timeout problems happen, by contrast, they typically write to us since it's not a failure they understand. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28734.869507051>