putting HESIOD, Appletalk and IPX on notice

[Tim Robbins]

Robert Watson wrote:

> On Fri, 5 Aug 2005, Poul-Henning Kamp wrote:
>
>> I think it is time we deorbit HESIOD in toto.
>>
>> At the same time, making Appletalk and IPX "opt in" facilities by 
>> putting them under
>>     YES_IPX
>> and
>>     YES_APPLETALK
>> boolean build options seems a sensible move.
>>
>> Comments ?
>>
>> The first RELENG_7 release would happen in 2006 or 2007, there is no 
>> way they will need any of those three protocols.
>
>
> Right now IPX and netatalk are already opt-in for the kernel, as the 
> options are already non-default.  I'm not sure we gain anything by 
> doing that in user space, other than making it harder to turn them on 
> (since presumably we're not talking more than a few hundred k in 
> support code). I've found NETIPX and NETATALK both quite useful during 
> the netperf work, as they help keep the protocol and socket type 
> abstractions in the stack real, as well as explain why things are the 
> way they are.
>
> My leaning would be to leave them as-is until early 2006, then take an 
> executive decision then.  Since there's not much point in talking 
> solely about the user space parts, I think the decision should be 
> about each protocol as a whole (kernel and userspace).  At last today, 
> I know that NETIPX is fairly widely used, because we received lots of 
> bug reports when 5.3 shipped with it broken (as a result of a compiler 
> change, it turns out).  As a result, we now have a basic set of IPX 
> and AppleTalk regression tests.
>
> I have no opinion on HESIOD, other than that I've always through it 
> somewhat fun -- does MIT still deploy it?  If not, then they may have 
> been the last major site to do so.  Probably, it would be useful to 
> stuff HESIOD in ports since we now support NSS.  I'd like to see us 
> import LDAP support into the base system at some point so that we can 
> support cAtive Directory integration better.

HESIOD should be moved out of libc and into a separate NSS/PAM module 
even if we do decide to keep it in the base system. With HESIOD out of 
libc, we could then split the DNS code out into a separate libresolv.

The same could be done with NIS/YP, which would allow us to slim down 
libc by moving xdr & rpc into a separate librpc, and yp into a separate 
libyp.

Tim