linux-kernel - Re: [RFC, PATCH] Extensible AIO interface

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:	Thu, 4 Oct 2012 06:58:06 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Kent Overstreet <koverstreet@...gle.com>
Cc:	Zach Brown <zab@...bo.net>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, tytso@...gle.com,
	Dave Kleikamp <dave.kleikamp@...cle.com>,
	Dmitry Monakhov <dmonakhov@...nvz.org>,
	"Maxim V. Patlasov" <mpatlasov@...allels.com>,
	michael.mesnier@...el.com, jeffrey.d.skirvin@...el.com,
	Martin Petersen <martin.petersen@...cle.com>
Subject: Re: [RFC, PATCH] Extensible AIO interface

Hello, Kent.

On Tue, Oct 02, 2012 at 08:00:20PM -0700, Kent Overstreet wrote:
> > However, I don't think it's a good idea to try to implement something
> > which is a neutral transport of opaque data between userland and lower
> > layers.  Things like that sound attractive with unlimited
> > possibilities but reality seems to have the tendancy to make a big
> > mess out of setups like that.
> 
> I don't see how the "neutral transport of opaque data" itself is a bad
> thing. We want something simple and sane to build actual interfaces on
> top of - once we've got that, we can either build clean generic well
> defined interfaces or we can make a mess like with ioctls :P
> 
> It's like any other mechanism. There's good syscalls and bad syscalls...

Depending on what a feature aims for, the design and implementation
vary greatly.  If you go for completely generic extensible stuff which
can be used to warp space-time continuum, it's easy to end up with a
monstrosity with generic and programmable parser, verifier, accessor
and so on.

> Say we implement an attr to control a block layer cache. That attr could
> be parsed/validated in high level code (if there's any to do) - that I
> don't object to. But the high level code isn't going to /know/ whether
> there was any block cache in the stack that handled the attr. If the
> attr is passed down to the block cache, that block cache can return that
> it was handled.

My point is that if it doesn't fit the generic abstract model as in
fadvise(2), it probably isn't worth supporting in any generic manner.

> > It's okay to allow some side channel thing for specific hacky uses but
> > I really hope the general design were focused around properly
> > abstracted attributes which can be understood and handled by the upper
> > layer.
> 
> Completely agreed. I want to leave that side channel open for
> experimentation, and so we have a way of implementing one off hacky
> stuff when we need to - but normal mainline stuff should be sane and
> well designed.

So, I think we can aim for something simple and modest (the only thing
I can think of at the moment is task association) and provide simple
framework which can be used for specific custom usages.  Let's please
not go overboard with generic parser / verifier which supports pointer
indirection or whatnot.

Thanks.

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