Linux-kernel mailing list archive 2000-29,: Re: [RFC] solution for the inet_ntoa problem, buffer allocator

# Re: [RFC] solution for the inet_ntoa problem, buffer allocator

Olaf Titz (olaf@bigred.inka.de)
Tue, 18 Jul 2000 12:05:20 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: P.Basker: "problem with d_count."
- Previous message: Ruth Ivimey-Cook: "Re: 2.4.0-test4 niggles"

> But now it's a brand new lock contention point! That's not much of an
> improvement. It took me all of 20 minutes to replace all the instances of
> inet_ntoa with inet_ntoa2, why all the effort to make the inherently
> troubled inet_ntoa work?

Because the purpose of a library function is (IMHO) to save the user
as much work as possible, and for this reason I want to explore the
possibilities to make this self-contained.

I agree that passing a buffer is not too bad a solution too,
preferably with suitable definitions on buffer types in the header (I
still want to integrate IPv6 addresses).

Olaf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: P.Basker: "problem with d_count."
- Previous message: Ruth Ivimey-Cook: "Re: 2.4.0-test4 niggles"