> -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx] > Sent: Thursday, April 23, 2015 10:10 PM > > On Thu, 2015-04-23 at 08:30 +0000, Kweh, Hock Leong wrote: > > > -----Original Message----- > > > From: James Bottomley > [mailto:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx] > > > Sent: Wednesday, April 22, 2015 11:19 PM > > > > > > > > > Yes, I think we've all agreed we can do it ... it's now a question of whether > we > > > can stomach the ick factor of actually initiating a transaction in close ... I'm > still > > > feeling queasy. > > > > The file "close" here can I understand that the file system will call the > "release" > > function at the file_operations struct? > > http://lxr.free-electrons.com/source/include/linux/fs.h#L1538 > > > > So, James you are meaning that we could initiating the update transaction > > inside the f_ops->release() and return the error code if update failed in this > > function? > > Well, that's what I was thinking. However the return value of ->release > doesn't get propagated in sys_close (or indeed anywhere ... no idea why > it returns an int) thanks to the task work additions, so we'd actually > have to use the operation whose value is propagated in sys_close() which > turns out to be flush. > > James > Okay, I think I got you. Just to double check for in case: you are meaning to implement it at f_ops->flush() instead of f_ops->release(). Thanks & Regards, Wilson ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
