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: <20061107115857.GB13028@2ka.mipt.ru>
Date:	Tue, 7 Nov 2006 14:58:57 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	David Miller <davem@...emloft.net>,
	Ulrich Drepper <drepper@...hat.com>,
	Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>
Subject: Re: [take21 0/4] kevent: Generic event handling mechanism.

On Tue, Nov 07, 2006 at 06:46:58AM -0500, Jeff Garzik (jeff@...zik.org) wrote:
> At an aside...  This may be useful.  Or not.
> 
> Al Viro had an interesting idea about kernel<->userspace data passing 
> interfaces.  He had suggested creating a task-specific filesystem 
> derived from ramfs.  Through the normal VFS/VM codepaths, the user can 
> easily create [subject to resource/priv checks] a buffer that is locked 
> into the pagecache.  Using mmap, read, write, whatever they prefer. 
> Derive from tmpfs, and the buffers are swappable.

It looks like Al likes filesystems more than any other part of kernel
tree...
Existing ring buffer is created in process' memory, so it is swappable
too (which is probably the most significant part of this ring buffer 
version), but in theory kevent file descriptor can be obtained not from
the char device, but from special filesystem (well, it was done in that
way in first releases but then I was asked to remove such
functionality).

> Then it would be a simple matter to associate a file stored in 
> "keventfs" with a ring buffer guaranteed to be pagecache-friendly.
> 
> Heck, that might make zero-copy easier in some cases, too.  And using a 
> filesystem would mean that you could do all this without adding 
> syscalls, by using special (poll-able!) files in the filesystem for 
> control and notification purposes.

There are too many ideas about networking zero-copy both sending and
receiving, and some of them are even implemented on different layers
(starting from special allocator down to splice() with additional
single allocation/copy).

> 	Jeff

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