Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Dec 2016 14:36:21 +0100
From: Peter Zijlstra <>
To: Kees Cook <>
Cc: David Windsor <>,
	"Reshetova, Elena" <>,
	"" <>,
	Greg KH <>,
	"" <>,
	Boqun Feng <>,
	Hans Liljestrand <>,
	"" <>,
	"" <>
Subject: Re: Conversion from atomic_t to refcount_t: summary of issues

On Thu, Dec 01, 2016 at 03:20:29PM -0800, Kees Cook wrote:

> There doesn't seem to be a good reason NOT to have stats_t, beyond the
> work needed to create it and audit the places it should be used.

API proliferation is a negative. Esp. if you have APIs that provide
overlapping / redundant functionality.

Its why I currently detest kref, and why I never used it (and actively
moved people away from it for code that I work on). Its daft wrappery
(and I know Greg disagrees).

Sure, you can add atomic_stats_t or whatever name gets decided upon (I
think Boqun had a good point in that there's plenty stats that are
!atomic -- also, I don't see you proposing to split "int" into separate
types per use-case), but don't expect me to use it for the code that I

refcount_t makes sense in that it has clearly defined semantics that are
not elsewhere provided and doesn't provide operations that defeat those
semantics or the use-case.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.