Date: Mon, 29 Dec 2008 00:33:59 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Kip Macy <kmacy@freebsd.org> Cc: Qing Li <qingli@freebsd.org>, freebsd-net@freebsd.org Subject: Re: arp-v2 (void *)-1 "hack" Message-ID: <20081229003106.G28465@maildrop.int.zabbadoz.net> In-Reply-To: <20081228234501.F28465@maildrop.int.zabbadoz.net> References: <20081228225956.G28465@maildrop.int.zabbadoz.net> <3c1674c90812281530l52b83404k9822cf6818329f01@mail.gmail.com> <20081228234501.F28465@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 Dec 2008, Bjoern A. Zeeb wrote: Hi, > On Sun, 28 Dec 2008, Kip Macy wrote: > > Hi, > >>> What do you think wrt to adding the (possibly optional) int *error and >>> returning the errno rather than a (void *)-1? If you'd be ok, I'd can >>> prepare the patch. I'd rather break the API now than in a few months. >> >> I would greatly prefer having a dedicated new function that calls in >> to it. There are a lot of calls to lla_lookup that would have to be >> changed needlessly. In other words: > > Right, there are 14 or so of them and at least 2 will need to be > touched. > >> 1) lla_lookup_internal - a static function which takes all 3 args >> 2) lla_delete - which returns an errno >> 3) lla_lookup - which maintains the current interface > > I wonder if it's worth adding two more functions for about a dozen calls > from basically 2 files; especially considering that we will need to modify > the internal API (llt_lookup function pointer in struct lltable and > in_lltable_lookup()/in6_lltable_lookup()) anyway. > > That's why I thought adding the int *error now consistently would be > easier and cleaner. > > Most of the callers, currently not caring could just pass in NULL, if > they don't care and we keep the argument optional. Just as a follow-up. I talked to Qing and the summary is: * we agree that this should be changed - one way or the other. * we'll wait a bit for things to settle more and possibly (though hopefully not) collect another few cases and fix them all at once should they show up. /bz -- Bjoern A. Zeeb The greatest risk is not taking one.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081229003106.G28465>