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]
Date:	Tue, 16 Jan 2007 10:36:42 -0800
From:	David Brownell <david-b@...bell.net>
To:	"Nate Diller" <nate.diller@...il.com>
Cc:	"Nate Diller" <nate@...mi.com>, "Andrew Morton" <akpm@...l.org>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Trond Myklebust" <trond.myklebust@....uio.no>,
	"Benjamin LaHaise" <bcrl@...ck.org>,
	"Alexander Viro" <viro@...iv.linux.org.uk>,
	"Suparna Bhattacharya" <suparna@...ibm.com>,
	"Kenneth W Chen" <kenneth.w.chen@...el.com>,
	"David Brownell" <dbrownell@...rs.sourceforge.net>,
	"Christoph Hellwig" <hch@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	netdev@...r.kernel.org, ocfs2-devel@....oracle.com,
	linux-aio@...ck.org, xfs-masters@....sgi.com
Subject: Re: [PATCH -mm 9/10][RFC] aio: usb gadget remove aio file ops

On Tuesday 16 January 2007 1:13 am, Nate Diller wrote:
> On 1/15/07, David Brownell <david-b@...bell.net> wrote:
> > What's needed is an async, non-sleeeping, interface ... with I/O
> > overlap.  That's antithetical to using read()/write() calls, so
> > your proposed approach couldn't possibly work.
> 
> haha, wow ok you convinced me :)

Good.  :)


> I got a bit impatient when I was working on this, it took some time
> just to figure out the intention of the code, and I'm trying to hold
> to a bit of a schedule here.  Without any clear (to me) reason, I
> didn't want to spend a lot of effort fixing this up.

Thing is, it's not OK to break other subsystems like that.

 
> There's really no big difference between the usb drivers here and the
> disk I/O scheduler queue, AFAICT,

The disk scheduler queue is more complex, as I understand things,
since it can combine operations.  For USB, "combining" would break
essential semantics relied on by both sides of the transaction.

Maybe the best way to view this is to accept that with USB, all
scheduler operations (e.g. for bandwidth reservation management)
are out of scope of the AIO request model.  AIO requests are no
more (or less) than "append this to the endpoint's I/O queue",
with the (host side) I/O scheduling handled separately.


> so it seems like the solution I want 
> is to do a kmap() on the user buffer and then do the I/O straight out
> of that.  That will eliminate the need for the bounce buffer.  I'll
> post a new version along with the iodesc changes later this week.

Sounds more complex, but it would be nice to have that code become
zero-copy instead of single-copy.  That'd let some platforms work
with high bandwidth ISO from userspace, which previously would not
have had enough CPU bandwidth.  ("High bandwidth" means sustained
8-24 MByte/sec data streaming.  Processing pixels at that rate may
require a companion DSP...)  Testing will be different issue though.

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