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: <20110830155438.bc31ab99.akpm@linux-foundation.org>
Date:	Tue, 30 Aug 2011 15:54:38 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Daniel Ehrenberg <dehrenberg@...gle.com>
Cc:	Jens Axboe <axboe@...nel.dk>, Jeff Moyer <jmoyer@...hat.com>,
	linux-kernel@...r.kernel.org, linux-aio@...ck.org
Subject: Re: Approaches to making io_submit not block

On Tue, 30 Aug 2011 15:45:35 -0700
Daniel Ehrenberg <dehrenberg@...gle.com> wrote:

> >> Not quite sure, and after working on them and fixing thing up, I don't
> >> even think they are that complex or intrusive (which I think otherwise
> >> would've been the main objection). Andrew may know/remember.
> >
> > Boy, that was a long time ago. __I was always unhappy with the patches
> > because of the amount of additional code/complexity they added.
> >
> > Then the great syslets/threadlets design session happened and it was
> > expected that such a facility would make special async handling for AIO
> > unnecessary. __Then syslets/threadlets didn't happen.
> 
> Do you think we could accomplish the goals with less additional
> code/complexity? It looks like the latest version of the patch set
> wasn't so invasive.
> 
> If syslets/threadlets aren't happening, should these patches be
> reconsidered for inclusion in the kernel?

I haven't seen any demand at all for the feature in many years.  That
doesn't mean that there _isn't_ any demand - perhaps everyone got
exhausted.

If there is demand then that should be described and circulated, see
how much interest there is in resurrecting the effort.

And, of course, the patches should be dragged out and looked at - it's
been a number of years now.

Also, glibc has userspace for POSIX AIO.  A successful kernel-based
implementation would result in glibc migrating away from its current
implementation.  So we should work with the glibc developers on ensuring
that the migration can happen.

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