[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060822123932.GA27181@2ka.mipt.ru>
Date: Tue, 22 Aug 2006 16:39:32 +0400
From: Evgeniy Polyakov <johnpol@....mipt.ru>
To: Christoph Hellwig <hch@...radead.org>
Cc: lkml <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Ulrich Drepper <drepper@...hat.com>,
Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
Zach Brown <zach.brown@...cle.com>
Subject: Re: [PATCH] kevent_user: remove non-chardev interface
On Tue, Aug 22, 2006 at 01:27:31PM +0100, Christoph Hellwig (hch@...radead.org) wrote:
> On Tue, Aug 22, 2006 at 04:17:10PM +0400, Evgeniy Polyakov wrote:
> > I personally do not have objections against it, but it introduces
> > additional complexies - one needs to open /dev/kevent and then perform
> > syscalls on top of returuned file descriptor.
>
> it disalllows
>
> int fd = sys_kevent_ctl(<random>, KEVENT_CTL_INIT, <random>, <random>);
>
> in favour of only
>
> int fd = open("/dev/kevent", O_SOMETHING);
>
> which doesn't seem like a problem, especially as I really badly hope
> no one will use the syscalls but some library instead.
Yep, exactly about above open/kevent_ctl I'm talking.
I still have a system which has ioctl() based kevent setup, and it
works - I really do not want to rise another flamewar about which
approach is better. If no one will complain until tomorrow I will commit
it.
> In addition to that I'm researching whether there's a better way to
> implement the other functionality instead of the two syscalls. But I'd
> rather let code speak, so wait for some patches from me on that.
There were implementation with pure ioctl() and with one syscall for all
oprations (and control block embedded in it), all were rejected in
favour of two syscalls, so I'm waiting for your patches.
--
Evgeniy Polyakov
-
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/
Powered by blists - more mailing lists