Re: AppleTalk

[Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>]

At 7:06 Uhr +0100 3.2.2018, Maxime Villard wrote:
>I've had a conversation with core@ about the removal of our kernel AppleTalk
>code, and I was asked to send a mail here to give people a chance to comment.

Thanks, that's nice.

>In NetBSD we have a kernel implementation of AppleTalk, in sys/netatalk/. This
>code provides a user API (AF_APPLETALK, sockaddr_at etc.), that userland tools
>can use to create sockets.
>
>Our kernel netatalk has not been maintained in years,

"It just works", I happen to use it almost every day. Also,
s/netatalk/appletalk/

>is grossly not MP-safe
>(global variables), and I already found a bug that could be triggered even
>when no AppleTalk interface was configured [1].
>
>The userland 'netatalk' package, which we do have in pkgsrc, offers the same
>functionalities as our kernel netatalk code.

You are confused.

The kernel NETATALK option compiles in a protocol stack for AppleTalk,
Apple's network protocol supported on Macintoshes from the mid-eighties
until (IIRC) max OS X 10.4.

The net/netatalk* packages install an AppleShare file server. Netatalk
started out  AppleTalk-only, quickly replacing the userland-only CAP
because its kernel support made it more efficient - DDP packets are small,
AppleTalk first appeared on 230 KBit serial lines. Netatalk later grew ASIP
support, and lost AppleTalk support with v3.

> This package is well maintained
>- the last release was less than a year ago -, well documented, and does not
>depend on any kernel netatalk code.

Netatalk 3.x cannot talk to any Mac that relies on Appletalk for service
discovery, PAP printing and AppleShare filesharing.

Netatalk 2.2.6 is the last version to support those machines. It relies on
the kernel AppleTalk stack to do this.

>The other BSDs already removed their netatalk/ several years ago, because it
>is a burden to maintain,

IOW, NetBSD is the last open source OS to provide network support for
pre-OSX Macintoshes. This is a feature in my book.

> and the user package offers the same features without it.

Wrong, see above.

>Therefore, our kernel netatalk code is a good candidate for removal.

I object. Strongly, if it helps.

Cheerio,
hauke


--
"It's never straight up and down"     (DEVO)