ietf
[Top] [All Lists]

Re: kernelizing the network resolver

2002-11-01 09:22:16
V Guruprasad wrote:

- eliminates sockaddr_t handling in the user space, allowing
 application code to become free of IPv4/IPv6 (or for that matter
 raw Ethernet or ATM) dependencies;

Doesn't using a shared library for the resolver give you the same benefit? It's in user space, but it's not in the app.

- reduces the number of context switches going from application
 to resolver and back;

Do you have data showing these context switches are a problem? To me, it seems like you're optimizing something that doesn't take up that much time anyway--what apps spend that much CPU time on DNS lookups?

- provides robust kernel multitasking for the resolution process,
 avoiding buggy or unsafe multithreading in application-based
 resolvers (like in netscape);

Again, the same thing can be done with a good shared lib. Most current Unices include gethostbyname_r(), which is thread-safe. Netscape just started too early, when threading support in the OS was still pretty uneven.

- reduces the overall code footprint - the filesystem name tree
 cache is reused, sockaddr_t handling code in applications gone.

Again, shared libs also reduce duplicate code (though not data; for that you do need the kernel, or a daemon).

--
/===============================================================\
|John Stracke      |jstracke(_at_)centivinc(_dot_)com                      |
|Principal Engineer|http://www.centivinc.com                    |
|Centiv            |My opinions are my own.                     |
|===============================================================|
|If you're going to walk on thin ice, you might as well *dance*!|
\===============================================================/