Date: Sun, 07 Aug 2005 16:30:37 +1000 From: Tim Robbins <tjr@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: Poul-Henning Kamp <phk@haven.freebsd.dk>, arch@freebsd.org Subject: Re: putting HESIOD, Appletalk and IPX on notice Message-ID: <42F5AA8D.3060201@freebsd.org> In-Reply-To: <20050805214650.H46767@fledge.watson.org> References: <21744.1123267707@phk.freebsd.dk> <20050805214650.H46767@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42F5AA8D.3060201>