Re: small fix to netatalk

2009/8/3 Robert N. M. Watson <rwatson_at_freebsd.org>:
>
> On 3 Aug 2009, at 14:06, Frank Lahm wrote:
>
>>> This is a patch against the kernel netatalk code in FreeBSD,
>>> specifically,
>>> against address configuration for phase I addresses. Forgive a lack of
>>> knowledge of the netatalk project itself, but I had assumed we basically
>>> owned the kernel bits and were supposed to make sure they kept working,
>>> and
>>> you guys owned the userspace bits.
>>
>> Yes, of course.
>> I'm sorry to say, but apparently I was too lazy to check the relation
>> between "our" sys/netatalk/*.[c|h] [1] stuff and the FreeBSD stuff.
>> As it turns out we have some very old and very unmaintained code in
>> our repo which was imported way back then when Netatalk was brought to
>> SF.net in the first place. Since then nobody every really has worked
>> on it. Current Netatalk development focuses on userspace stuff. Afaik none
>> of
>> us doing active development has any decent knowledge of the AppleTalk
>> protocol implementations of BSD or Solaris.
>
> This is simplifying from many perspectives --

??

> I should probably check your
> repo history to see if there were any earlier bug fixes that would be useful
> to pick up for FreeBSD, ...

As said:
>> As it turns out we have some very old and very unmaintained code in
>> our repo which was imported way back then when Netatalk was brought to
>> SF.net in the first place. Since then nobody every really has worked
>> on it.

> ...but it sounds like we've maintained it much more aggressively.

Indeed. You have maintained it, we haven't.

>>> We should probably talk regardless as one of the big things we appear to
>>> be
>>> missing for the kernel netatalk code is a decent regression suite -- I
>>> have
>>> some casual local tests, but over the years we've picked up several
>>> reports
>>> of regressions (8 appears to have regressed with respect to multiple
>>> network
>>> interfaces being available, for example), and I know very little about
>>> the
>>> wire protocol. If you guys have any unit tests ...
>>
>> No, we don't. Only for the userlevel AFP protocol.
>
> However, that is useful to know: if I can create a VM with a
> netatalk-enabled ...

Again: please in order to prevent confusion imo we should follow the
naming scheme in use at every other place. The AppleTalk kernel module
is called just that. Calling it the netatalk kernel module will cause
confusion. Really, it confuses myself while we're talkink about it.
I'm not trying to nitpick here, I'm sorry if you got that impression.

> ... FreeBSD kernel and netatalk source package from you, with
> minimal configuration, can I simply say "make test" or something along those
> lines and get test results of value? If so that can help us significantly in
> keeping netatalk working on the platform.

As said: we have this for testing Netatalk's afpd against the AFP
(over IP) specs [1]. Having a test suit for testing the AppleTalk
stack on a platform would be nice, but as said none of the current
Netatalk developers has time or interest in doing this as we're
focusing on other stuff.

>>> ... for kernel netatalk services, ...
>>
>> Fwiw:
>> the usage of the term netatalk for the kernel implementation of the
>> link-layer AppleTalk protocoll is confusing. I guess the naming rules
>> in FreeBSD CVS joined net with atalk to form netatalk, but that's only
>> the name of the directory containg the atalk implementation.
>
> I think there's a bit more history to it than that. In the original BSD
> network stack (home of the sockets API, etc), the various directory names
> were net and net$proto, such as netinet. This naming convention has been
> continued in the FreeBSD stack - netipx, netinet6, net80211, etc. You can
> even find the impact of this historic BSD naming convention on systems like
> Solaris and Linux, where the portable header file names are things like
> "netinet/in.h". My guess is that the userspace components in today's
> netatalk project derived their name from this structure, rather than it
> being a convergence of names. :-)

Probably. ;o)

>>> that would be excellent, but if not, perhaps you can provide some
>>> guidance
>>> on what sorts of units tests would be appropriate.
>>
>> From our (or at least my) perspective, we're focusing on the AFP
>> protocol and our ressources are sparse. Also note that Mac OS X 10.6
>> will ship withouh AppleTalk. The words of dropping AppleTalk support
>> and the userlevel daemons atalkd and papd who use it have already been
>> heared twice on netatalk-dev_at_sf.net. Few are still using it, fewer
>> know it, nobody maintains it.
>> A year or two back in time I would have been tempted to step up and
>> pick up AT development and would then have asked you for some advice
>> on how to get to know developping networking stuff in the FreeBSD
>> kernel. But that was then.
>
> Right. The future of AppleTalk as a protocol is grim, but the reality is
> that there are moderate number of folks still using it. Or, at least, I
> usually get a handful of bug reports whenever I break it when sliding
> support forward to new kernel infrastructure changes, including this most
> recent one that was fallout from SMP work. :-)
>
> We'd like to keep our kernel protocol stack supporting it until our users
> stop using it. I don't see us doing much in the way of enhancement (although
> our netatalk code probably will grow support for network stack
> virtualization in the future, as that's a general infrastructural change
> appearing throughout the network stack). So in as much as we can rely on,
> for example, unit testing in the userspace netatalk package telling us when
> we introduce regressions in the kernel code, that's very helpful.

I highly appreciate your and anybody elses work on the AppleTalk
kernel module in FreeBSD. As it stands the recommended platform for
Netatalk for folks still using AT is FreeBSD, as Linux AppleTalk
kernel module is broken (e.g. it generates broken RTMP packets) and
the Solaris one (which lives in the Netatalk repo) is loadable but
unmaintained.

Regards
-Frank

[1]
<http://netatalk.cvs.sourceforge.net/viewvc/netatalk/test-suite/test/>