| 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: Fri, 18 May 2012 16:31:08 +0100 From: James Bottomley <James.Bottomley@...senPartnership.com> To: Matthew Wilcox <willy@...ux.intel.com> Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: NVM Mapping API On Fri, 2012-05-18 at 10:49 -0400, Matthew Wilcox wrote: > You're downplaying the complexity of your own solution while overstating > the complexity of mine. Let's compare, using your suggestion of the > dmesg buffer. I'll give you that one when you tell me how you use your vfs interface simply from within the kernel. Both are always about the same complexity in user space ... To be honest, I'm not hugely concerned whether the key management API is u32 or a string. What bothers me the most is that there will be in-kernel users for whom trying to mmap a file through the vfs will be hugely more complex than a simple give me a pointer to this persistent region. What all this tells me is that the key lookup API has to be exposed both to the kernel and userspace. VFS may make the best sense for user space, but the infrastructure needs to be non-VFS for the in kernel users. So what you want is a base region manager with allocation and key lookup, which you expose to the kernel and on which you can build a filesystem for userspace. Is everyone happy now? James -- 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