On 02/29, Al Viro wrote: > On Sun, Feb 28, 2016 at 03:39:08PM -0800, Amber Thrall wrote: > > Apologies for the confusing name, struggled to find an appropriate name > > while staying consistent with the naming schemes of > > simple_read/write_to_buffer() functions, as it based off of them. I'd > > love to hear alternative names. > > > > I saw possible uses for this proposed function being an easy way to > > interact with debugfs, via their write file operation. For > > example in the function xenvif_write_io_ring() the string "kick" is > > checked for against a user space buffer. > > TBH, that caller leaves an impression of rather... poor API - "any write > of no more than 32 bytes that starts with 'k' 'i' 'c' 'k' is OK (and > everything beyond first 4 characters is ignored), anything else is > rejected, in some cases with whining into syslog, in some - quietly". > I don't know if encouraging stuff like that is a good idea... > > In any case, you've ended up open-coding kmemdup_user() + strncmp() + kfree(); > the problem with combining those into a single helper is that calling > conventions will be very error-prone - you have zero/positive/negative for > passing strncmp() result *and* you need to report errors somehow. The conflicts between strncmp() and error values hadn't crossed my mind. The function could return the value from strncmp() via pointer, but it wouldn't match up with strncmp's formatting making the function confusing to use. Thanks for the input, I'm still new to working with the kernel and have a lot to learn. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
