| 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
| ||
|
Date: Sat, 16 Aug 2008 17:13:36 +1000 From: Rusty Russell <rusty@...tcorp.com.au> To: Fernando Luis Vázquez Cao <fernando@....ntt.co.jp> Cc: Jens Axboe <jens.axboe@...cle.com>, linux-kernel@...r.kernel.org, 吉川 拓哉 <yoshikawa.takuya@....ntt.co.jp>, dpshah@...gle.com Subject: Re: request->ioprio On Friday 15 August 2008 15:51:02 Fernando Luis Vázquez Cao wrote: > On Thu, 2008-08-14 at 12:16 +1000, Rusty Russell wrote: > > On Wednesday 13 August 2008 17:06:03 Fernando Luis Vázquez Cao wrote: > > > Besides, I guess that accessing the io context information (such as > > > ioprio) of a request through elevator-specific private structures is > > > not something we want virtio_blk (or future users) to do. > > > > The only semantic I assumed was "higher is better". The server (ie. > > host) can really only use the information to schedule between I/Os for > > that particular guest anyway. > > Does that mean you are not going to incorporate the prio class system > that is used in Linux? Actually, since it's unused at the moment, we can define it however we want. But note that this is an ABI; while the kernel-internal definitions are fluid, this semantic must stay the same (even if the actual values differ). So we should probably put an explicit mapping function there anyway. Thanks, Rusty. -- 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