> > > (This is the same sort of thing we already have to deal with in > > > certain situations, such as network stat counters on 32 bit > > > platforms.) > > > > But userspace can't deal with the condition accurately, > > Okay, perhaps this is where I'm missing something? If userspace wakes > up once every hour, checks the overrun counter against the previous > (new-old), and goes back to sleep, that'd be good enough, right?
Yes. > > so why > > require userspace to worry about this when we could just use > > a 64-bit value instead? > > <shrug> I don't have strong feelings either way. It just seemed like > something that could already be taken care of with today's interface. > Given that the discussion was about an API change between 2.6.22 and > 2.6.23, I was looking for options to avoid that. In fact I don't have strong feelings on this part of the interface design either. I pointed out the limitation to Davide, and pointed out that the related eventfd interface read()s an 8-byte integer, and Davide then just fired off a patch to Andrew which went into --mm. It's the other problems with the interface that bother me more (inability to retrieve previous setting when changing the timer; inability to retrieve time until next expiration without changing the current setting). Cheers, Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages , read the HOWTOHELP file and grep the source files for 'FIXME'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
