On Sat, 2007-03-10 at 17:57 -0800, Davide Libenzi wrote: > 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. >
Timers don't need dentry or inode pointers or readahead state, etc., do they? (Beyond the existing VFS expectation, that is.) > > > 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". That wasn't a troll. I was talking about the timerfd()/close() overhead and the corresponding bookkeeping necessary to keep that fd around compared to just passing a struct timespec to poll or a millisecond count to epoll_wait. > > 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 ... Nice. -- Nicholas Miell <[EMAIL PROTECTED]> - 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/