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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060821111335.GA8608@2ka.mipt.ru>
Date:	Mon, 21 Aug 2006 15:13:36 +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: [take9 1/2] kevent: Core files.

On Mon, Aug 21, 2006 at 11:56:37AM +0100, Christoph Hellwig (hch@...radead.org) wrote:
> On Fri, Aug 18, 2006 at 03:23:36PM +0400, Evgeniy Polyakov wrote:
> > > defines make some sense for userspace-visible ABIs because then people
> > > can test for features with ifdef.  It doesn't make any sense for constants
> > > that are used purely in-kernel.  For those enums make more sense because
> > > you can for example looks at the symbolic names with a debugger.
> > 
> > Enums are only usefull when value is increased with each new member by
> > one.
> 
> No, they are not.  Please search the lkml archives, this came up multiple
> times.

Enums when OR'ed and ANDed in theory can produce value out of the enum
set.
And what is the difference between
#define A 1
#define B 2
#define C 4
and
enum {
 A = 1,
 B = 2,
 C = 4,
}
?

> > There will be either several syscalls or multiplexer...
> > I prefer to have one syscall and a lot of multiplexers inside.
> 
> To make life for everyone to detangle the mess hard.  Please at least
> try to follow existing design principles.

I added as less as possible syscalls - control one read ones.
The former can initialize/add/remove/modify kevents, the latter reads
ready events.

> > > > I created a char device in first releases and was forced to not use it
> > > > at all.
> > > 
> > > Do you have a reference to it?  In this case a char devices makes a lot of
> > > sense because you get a filedescriptor and have operations only defined on
> > > it.  In fact given that you have a multiplexer anyway there's really no
> > > point in adding a syscall for that aswell, you could rather use the existing
> > > and debugged ioctl() multiplexer.  Sure, it's still not what we consider
> > > nice, but better than adding even more odd multiplexer syscalls.
> > 
> > Somewhere in february.
> > Here is link to initial anounce which used ioctl and raw char device and
> > enums for all constants.
> > 
> > http://marc.theaimsgroup.com/?l=linux-netdev&m=113949344414464&w=2
> 
> That thread only shows your patch but no comments to it.  Do you have
> an url for the complaint about this design?  And please include the author
> of it in the cc list of your reply so we can settle the arguments.

enum vs. defines were changed after David Miller's suggestion, since the
whole network stack and epoll use defines extensively, and kevent was
built for them in a first time.

I do not remember who suggested not to use char device, but I saw that
inotify specially mention about ioct/syscall issues, old discussion
about event handling mechanism somewhere in this thread:
http://uwsg.iu.edu/hypermail/linux/kernel/0010.3/0002.html

It looks a bit illogical to have epoll/poll syscalls and read data from
char device and it's ioctls for network sockets completeness or timer
notifications.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ