Date: Sun, 16 Jan 2011 21:02:23 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: Pyun YongHyeon <pyunyh@gmail.com>, freebsd-net@freebsd.org, Lev Serebryakov <lev@serebryakov.spb.ru> Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW Message-ID: <20110116200223.GA65732@alchemy.franken.de> In-Reply-To: <20110116174153.Y14966@maildrop.int.zabbadoz.net> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> <20110112225907.GA44318@alchemy.franken.de> <20110113173925.GA49356@alchemy.franken.de> <20110113212713.GC17502@michelle.cdnetworks.com> <20110114012412.GK97101@alchemy.franken.de> <178613186.20110114134109@serebryakov.spb.ru> <20110116144247.GA65399@alchemy.franken.de> <20110116174153.Y14966@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 16, 2011 at 05:55:06PM +0000, Bjoern A. Zeeb wrote:
> On Sun, 16 Jan 2011, Marius Strobl wrote:
>
> Hi,
>
> >On Fri, Jan 14, 2011 at 01:41:09PM +0300, Lev Serebryakov wrote:
> >>Hello, Marius.
> >>You wrote 14 ?????? 2011 ?., 4:24:12:
> >>
> >>>found by ignoring the bits set in the "don't care mask". I've
> >>>updated the patch at the above URL accordingly and based on my
> >>>testing it now should actually work as expected. Sorry for the
> >>>glitch.
> >> Yes, it works for me.
> >
> >Thanks for testing! I've committed the patch to HEAD and will try
> >to get it into 7.4 and 8.2.
> >
> >> Only one note: I think, it is good idea to document this flag in
> >> re(4).
> >>
> >
> >Technically re.4 obviously is the wrong location for documenting it
> >as it's generally the business of the PHY drivers to handle the media.
> >Moreover, rgephy(4) driven PHYs are also commonly used in combination
> >with at least axe(4), nfe(4), nve(4) and sge(4) MACs so we would have
> >to document this special media option in all of the corresponding man
> >pages, which would introduce undesirable redundancy. So instead I've
> >added a rgephy.4 man page and documented it there.
> >Actually, this is a very good example for why we generally should not
> >document media types and options in the man pages of MAC drivers that
> >take advantage of mii(4) but instead add a common ifmedia.4 and just
> >point there and if as in this case it makes sense to man pages of
> >specific PHY drivers.
>
> First of all, thanks a lot for the work! Can you email me the entire
> set of revisions off-list so that I could have a look, especially to
> see if we can still sneak things into the release after the RC2s (or
> send them to re@ fore pre-review and I'll read them there;)
The revision introducing the flag0 media option for rgephy(4) and
fixing some bugs I'd like to avoid shipping the final 7.4 and 8.2
with is just r217415 and has no dependencies. My idea was to MFC
it to stable/{7,8} as planned and then ask re@ for approval to
merge to release/{7.4,8.2}, pointing at the 2-3 threads on net@
about the problem with servers provided by Hetzner as these appear
to be rather popular even outside of .de (not that I'm affiliated
with them in any way, I'm not even one of their customers).
While working on that I noticed that some other PHY drivers share
similar bugs like the ones fixed by r217415 for rgephy(4) so I
fixed these also, which might make you think that other revisions
committed about the same time might be a dependency of the former.
Unlike the problems discovered in rgephy(4), the known MAC-PHY-
(driver-)combinations to the best of my knowledge currently won't
be able to trigger these bugs for one reason or the other so I
don't intend to get the other revisions merged into 7.4 and 8.2.
As for documenting r217415 that unfortunately took me some more
revisions, i.e. r217464, r217468 and r217475. However, my original
plan actually wasn't to get these also into 7.4 and 8.2 anyway as
I think this too big a change. I think for hotfix-like stuff like
this one it actually is tolerable to not have the flag0 media
option documented in the documentation included in the release.
>
> Second, I start to like the idea of <$phy>.4 in addition to <$mac>.4 man
> pages and .Xrs given our discussion lately on the extra alias options.
> The only drawback I see is that the ifconfig.8 -> <$mac>.4 -> <$phy>.4
> man page chain gets longer and ifconfig generally doesn't reference
> any drivers but miibus.4 does.
Well, from the dmesg, the output of devinfo(8) etc it's easily
deducible that f.e the re0 interface also involves miibusX and
rgephyY instances. So I really think we can expect our users to
think of having a look at all of these man pages might be a good
idea if they intend to configure the interface, especially since
as you also point out ifconfig.8 generally doesn't say much about
drivers. Of course this requires <$mac>.4 to not give the
impression they would be authoritative about the media supported,
which they currently unfortunately do.
> Would it make a sense to add a list of
> man pages of the `phys' implementing miibus in addition to the list of
> drivers making use of miibus, rather than just having adding the .Xr
> at the end? The list might grow in the future now that it was
> started?
>
Yes, having such a list in miibus.4 seems like a good idea.
However, I wanted to avoid touching that man pages more than
really necessary at this time as it IMO is in the need for a
general overhaul; several of the information provided there
more or less obviously refers to how things looked like when
Fast Ethernet was the state of the art or otherwise read
rather strange to me. To be honest in this regard I much
prefer the simplicity of the NetBSD mii.4, which the FreeBSD
miibus.4 at least has been inspired by judging the comment at
the top of that man page. The former talks more about how things
work in the OS and what the user is able to do with it rather
than trying to give background information about the technology
involved.
Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110116200223.GA65732>