Date: Tue, 29 Apr 2008 21:25:54 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Kevin Oberman <oberman@es.net> Subject: Re: multiple routing tables review patch ready for simple testing. Message-ID: <48178452.4050700@FreeBSD.org> In-Reply-To: <4817743B.6090107@elischer.org> References: <20080429185100.57C2445010@ptavv.es.net> <4817743B.6090107@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: >> >> A general purpose OS is a different beast as it has no physical >> equivalent of the FIB. It may have multiple routing tables, though, to >> I think setrib would be a term less likely to cause confusion then >> setfib even though, in the case of your FreeBSD patches, it's really >> both. > If we need to change the terminology now is the time.. > I asked for comments on terminology before and this is what we > came up with.. but once it gets committed.... it gets set in stone. The kernel forwarding table is not a RIB. In the past some apps have tried to use it as one. They really shouldn't do that. There are implementation constraints on the inter-process communication involved (PRC_ATOMIC, etc) which make it inherently unsuitable as a place for routing daemons to exchange routes, particularly when the system is under load, or running near load limits, as would be the case with a tightly engineered embedded system. I understand folk went down that road in the past, as a means to get something up and running quickly as a working demo, or as a hangover from the days when they were the only tools around, but it isn't the way to build a comms infrastructure. These days general purpose OSes are getting closer to specialised comms equipment in terms of what they can do, but more importantly, so are people's expectations of them -- and thus people's concern about whether or not it works tends to follow. cheers BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48178452.4050700>