Date: Sun, 9 Jan 2005 06:07:40 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Joe Marcus Clarke <marcus@FreeBSD.org> Cc: ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/net/netatalk Makefile distinfo pkg-plist Message-ID: <Pine.NEB.3.96L.1050109055434.43829O-100000@fledge.watson.org> In-Reply-To: <1105249472.872.4.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 9 Jan 2005, Joe Marcus Clarke wrote: > > > > Modified files: > > > > net/netatalk Makefile distinfo pkg-plist > > > > Log: > > > > Update to 2.0.2. > > > > > > Is PR kern/4184 still an issue with this version update? > > > > Good question. The aarp.c patch is no longer needed, but it looks like > > the ddp_output.c patch applies. I have never had a report of netatalk > > working or not working on an Alpha, so I'm not sure if this patch really > > fixes anything or not. > > > > I'm adding rwatson to the Cc since he was the last to touch the netatalk > > code, and could probably give a more informed opinion. I currently don't have an AppleTalk network up and available for testing other than in fairly trivial ways, so don't have too informed an opinion, especially for the AppleTalk phase issue. The first patch in the PR appears already to have been applied. The second patch sounds like a a reaosnable problem diagnosis; the mbuf handling in this part of the netatalk is pretty sloppy and should be rewritten. In particular, there are a number of assumptions about headers fitting into available mbuf space without run-time or compile-time checking (for example, that struct elaphdr fits in an mbuf). However, I'm not quite sure I agree with the solution presented in the PR: presumably the problem is that some piece of code receives this mbuf and makes poor assumptions about its layout in mbufs, and fails to perform a necessary m_pullup()? Seeing m_pull() with MHLEN/m.pkthdr.len suggests that the requirements for alignment and layout aren't fully known, such that this is a workaround rather than a solution. It's a pity the PR doesn't indicate what piece of code it is that stumbles over the mbuf later. I think I'm not in a position to take immediate action on this one -- it would be interesting to know if we could find someone with an active and complex AppleTalk network who could give this code a spin on a system where alignment is more of an issue and let us know what happens. Otherwise I'd be tempted to suspend the PR as "not currently in a position to do something about this". Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050109055434.43829O-100000>