| 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, 28 May 2010 09:43:20 +0200 From: Henrik Rydberg <rydberg@...omail.se> To: stefani@...bold.net CC: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org, andi@...stfloor.org, gregkh@...e.de, alan@...rguk.ukuu.org.uk, tytso@....edu, iws@...o.caltech.edu Subject: Re: really generic, type save and type definable. stefani@...bold.net wrote: [...] > The main goal was to provide an API which is very intuitive, save and easy > to use. So linux will get now a powerful fifo API which provides all what > a developer needs. This will save in the future a lot of kernel space, since > there is no need to write an own implementation. Most of the device driver > developers need a fifo, and also deep kernel development will gain benefit > from this API. The meaning of the term "multiple readers" referred to in the header is somewhat ambiguous. It could in principle refer to concurrent reading of the same position, or concurrent reading from different positions. Imaginably, those cases also have different locking behavior. What happens if two fifos are initialized with the same memory buffer? What about one-to-many and many-to-one cases? The input system and the logging facilities could serve as examples where such buffers would be useful. Henrik -- 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