Re: small fix to netatalk

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, but it sounds like we've  
maintained it much more aggressively.

>> 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 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.

>> ... 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. :-)

>> 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.

Robert