On Fri, Mar 09, 2007 at 03:33:01PM -0800, Mark Fasheh wrote: > ->kernel_write() as opposed to genericizing ->perform_write() would be fine > with me. Just so long as we get rid of ->prepare_write and ->commit_write in > that other kernel code doesn't call them directly. That interface just > doesn't work for Ocfs2.
It doesn't work for any filesystem that needs slightly fancy locking. That and the reason that's an interface that doesn't fit into our layering is why I want to get rid of it. Note that fops->kernel_write might in fact use ->perform_write with an actor as Nick suggested. I'm not quite sure how it'll look like - I'd rather take care of the buffered write path first and then handle this issue once the first changes have stabilized. > Right now I've got Ocfs2 implementing it's own lowest-level buffered write > code - think generic_file_buffered_write() replacement for Ocfs2. With some > duplicated code above that layer. What's nice is that I can abstract away > the "copy data into some target pages" bits such that the majority of that > code is re-usable for ocfs2's splice write operation. I'm not sure we could > have that low a level of abstraction for anyhing above individual the file > system though which also has to deal with non-kernel writes though. That's > where a ->kernel_write() might come in handy. Why do you need your own low level buffered write functionality? As in past times when filesystems want to come up I'd like to have a very good exaplanation on why you think it's needed and whether we shouldn't improve the generic buffered write code instead. This codepath is so nasty that any duplication will be a maintaince horror. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
