linux-kernel - Re: [patch 13/13] signal/timer/event fds v9

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0704011315480.26550@alien.or.mcafeemobile.com>
Date:	Sun, 1 Apr 2007 13:20:23 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Avi Kivity <avi@...o.co.il>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Zach Brown <zach.brown@...cle.com>,
	Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: [patch 13/13] signal/timer/event fds v9 - KAIO eventfd support
 example ...

On Sun, 1 Apr 2007, Avi Kivity wrote:

> Davide Libenzi wrote:
> 
>  
> > > I think it's a bit too fine grained, and a new system call (io_bindfd()?)
> > > would be easier to use.  In addition, you would move the eventfd_fget()
> > > out of
> > > the submission path.
> > >     
> > 
> > IMO the cost of the eventfd_fget() (have you seen it?) is not worth adding a
> > new syscall.
> >   
> 
> There's an atomic op there (and another on the way out).  Probably on a busy
> cacheline.  Still it's probably lost in the noise.
> 
> Regardless of that, I think that specifying the fd per submission is wrong.
> It feels like a setup thing that needs to be done once.  We shouldn't skimp on
> syscalls, especially on something as important as unifying the async event
> model.

For userspace that wants to do that (that is, having iocbs signaled to an 
eventfd), do not really matter much. They have their own iocb setup function
and they'd simply set a flag more and set the resfd.
The global setting may be good for some users, with others that may 
complain in having to create another ctx just to set an fd.
Again, IMO is not worth a new API. What do other folks think?




- Davide


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