On 26.06.13 10:24:08, Borislav Petkov wrote: > On Wed, Jun 26, 2013 at 10:12:23AM +0200, Robert Richter wrote: > > We get a new fd by opening the persistent event with the syscall. > > There would be 2 new ioctls: > > > > ioctl(fd, PERF_EVENT_IOC_DETACH, 0); > > ioctl(fd, PERF_EVENT_IOC_ATTACH, 0); > > > > This would be fine and reuses existing infrastructure. > > Well, how are you going to say that you want to open an already existing > persistent event or your want to create exactly the same persistent > event? Are we even going to allow identical persistent events to > coexist?
Here is the scenario: Creating a persistent event from userspace: * A process opens a system-wide event with the syscall and gets a fd. * The process mmaps the buffer. * The process does an ioctl to detach the process which increases the events and buffers refcount. The event is listed as 'persistent' in sysfs with a unique id. * The process closes the fd. Event and buffer remain in the system since the refcounts are not zero. Opening a persistent event: * A process scans sysfs for persistent events. * To open the event it sets up the event attr according to sysfs. * The persistent event is opened with the syscall, the process gets a new fd of the event. * The process attaches to the event buffer with mmap. Releasing a persistent event: * A process opens a persistent event and gets a fd. * The process does an ioctl to attach the process which decreases the refcounts. The sysfs entry is removed. * The process closes the fd. * After all processes that are tied to the event closed their event's fds, the persistent event and its buffer is released. Sounds like a plan? -Robert -- 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/
