On Tue, May 8, 2012 at 10:50 AM, KOSAKI Motohiro kosaki.motohiro@gmail.com wrote:
- sample_period is brain damaged idea. If people ONLY need to
sampling stastics, they only need to read /proc/vmstat periodically. just remove it and implement push notification. _IF_ someone need unfrequent level trigger, just use "usleep(timeout); read(vmevent_fd)" on userland code.
That comes from a real-world requirement. See Leonid's email on the topic:
I know, many embedded guys prefer such timer interval. I also have an experience similar logic when I was TV box developer. but I must disagree. Someone hope timer housekeeping complexity into kernel. but I haven't seen any justification.
Leonid?
- Also vmevent_event must hide from userland.
Why? That's part of the ABI.
Ahhh, if so, I missed something. as far as I look, vmevent_fd() only depend on vmevent_config. which syscall depend on vmevent_evennt?
read(2). See tools/testing/vmevent/vmevent-test.c for an example how the ABI is used.
- vmevent_config::size must be removed. In 20th century, M$ API
prefer to use this technique. But They dropped the way because a lot of application don't initialize size member and they can't use it for keeping upper compitibility.
It's there to support forward/backward ABI compatibility like perf does. I'm going to keep it for now but I'm open to dropping it when the ABI is more mature.
perf api is not intended to use from generic applications. then, I don't think it will make abi issue. tool/perf is sane, isn't it? but vmevent_fd() is generic api and we can't trust all userland guy have sane, unfortunately.
The perf ABI is being used by other projects as well. We don't _depend_ on ->size being sane as much as use it to detect new features in the future.
But anyway, we can consider dropping once the ABI is more stable.
Hm. If you want vmevent makes depend on CONFIG_EMBEDDED, I have no reason to complain this feature. At that world, almost all applications _know_ their system configuration. then I don't think api misuse issue is big matter.
No, I don't want to do that. I was just commeting on why existing solutions are the way they are.