linux-kernel - Re: [patch 6/9] signalfd/timerfd v1

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.64.0703101752360.3613@alien.or.mcafeemobile.com>
Date:	Sat, 10 Mar 2007 17:57:39 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Nicholas Miell <nmiell@...cast.net>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

On Sat, 10 Mar 2007, Nicholas Miell wrote:

> If that's the goal, somebody should start thinking about reducing the
> contents of struct file to the bare minimum (i.e. not much more than a
> file_operations pointer).

That's already pretty smal, and the single inode (and maybe dentry) will 
make it even smaller. Unless you want to create brazillions of signalfds,
timerfds or asyncfds.



> > And the real point of the whole signalfd() is that there really *are* a 
> > lot of UNIX interfaces that basically only work with file descriptors. Not 
> > just read, but select/poll/epoll.
> 
> It'd be useful if the polling interfaces could return small datums
> beyond just the POLL* flags -- having to do a read on timerfd just to
> get the overrun count has a lot of overhead for just an integer, and I
> imagine other things would like to pass back stuff too.
...

> You still want timeouts, creating/setting/destroying at timer just for
> a single call to select/poll/epoll is probably too heavy weight.

Take a look at what timerfd does and what posix timers has to do to 
implement the interface. You'll prolly stop trolling with things like "a 
lot of overhead" or "too heavy weight".



> timerfd() still leaves out the basic clock selection functionality
> provided by both setitimer() and timer_create().

That is coming as soon as I fixed my send-serie script ...




- 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/