[adding krenel newbies in cc, as there might be others who have better answers]
On Sat, Jun 19, 2010 at 12:49 AM, Anand Pai <anand_pai@xxxxxxxxx> wrote:
>
> Manish:
>
> You are absolutely correct ! I agree with you that once I decide to use the filp, then the inode operations will be used.
>
> But ...your response has caused me to ask a more fundamental question.
>
> This is the scenario> I am trying to initiate a read of LKM read of a file into a kernel buffer.
>
> So .. I do a kernel_read.
>
> This ... does a vfs_read.
>
> vfs_read uses file->f_op and file->f_op->read to decide ... WHICH read it will do:
>
> ************ do_sync_read OR file->f_op->read
>
> Now ... I dont see where file-f_op->read or file->f_op are being initialized.
kernel_read needs a file * as the first argument, What are you passing
there ? How did you get file* there.
Thanks -
Manish
>
> I have shown all the greps etc. Thias has been awhile. Please help me if you can.
>
> Also, another question is ... when IS do_synch_read SUPPOSED to be used (over file->f_op->read) anyway ? What is the philisophy if you will ?
>
> Thanks so much Manish. I do look forward to your response. Regards
>
> -Anand
>
> --- On Wed, 6/16/10, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote:
>
> From: Manish Katiyar <mkatiyar@xxxxxxxxx>
> Subject: Re: Question about do_sync_read()
> To: "Anand Pai" <anand_pai@xxxxxxxxx>
> Date: Wednesday, June 16, 2010, 8:32 AM
>
> If you happened to trace the code enough, you will realise that from the pathname we try to get a file * (filp)... tracing somemore you will find that ultimately __dentry_open(...) will be called which has the below line :-
> static struct file *__dentry_open(struct dentry *dentry, struct vfsmount *mnt,
> struct file *f,
> int (*open)(struct inode *, struct file *),
> const struct cred *cred)
> {
> .................
> ...................
> f->f_mapping = inode->i_mapping;
> f->f_path.dentry = dentry;
> f->f_path.mnt = mnt;
> f->f_pos = 0;
> f->f_op = fops_get(inode->i_fop);
> ..............
>
> Hope that clears your doubt.
>
>
> On Wed, Jun 16, 2010 at 3:48 AM, Anand Pai <anand_pai@xxxxxxxxx> wrote:
>>
>> Hi Manish:
>>
>> Thanks so much for your response. As you can see from the attached screen shots,
>> ext3_file_operations is getting attached to inode->-i_fop.
>>
>> kernel_read (and vfs_read used by it) uses file->f_op, and I cant see where the appropriate
>> plave where any function/ method gets attached to file->f_op.
>>
>> This is noted in the third jpg (File Operations 3.jpg). I just cant find which method of file
>> read is used by vfs_read. Could you please advise ?
>>
>> Thanks, Regards
>>
>> -Anand
>>
>> --- On Sun, 6/13/10, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote:
>>
>> From: Manish Katiyar <mkatiyar@xxxxxxxxx>
>> Subject: Re: Question about do_sync_read()
>> To: "Anand Pai" <anand_pai@xxxxxxxxx>
>> Date: Sunday, June 13, 2010, 7:38 PM
>>
>> For ext3 filesystem, see the structure ext3_file_operations{} in ext3/file.c. Similar thing is done for other filesystems. and trace the function generic_file_aio_read().
>>
>> On Mon, Jun 14, 2010 at 1:58 AM, Anand Pai <anand_pai@xxxxxxxxx> wrote:
>>>
>>> Hi Manish:
>>>
>>> Cane across your question on do_sych_read.... I was wondering if you could
>>> help point me to exactly where the buf is getting written on the read from file....
>>>
>>> I am trying to do a kernel_read of a file from within an LKM, but the buf is not
>>> getting updated after completion of the kernel_read.
>>>
>>> I would appreciate any help at all. Thanks so much
>>>
>>> -Anand
>>>
>>>
>>>
>>
>>
>>
>> --
>> Thanks -
>> Manish
>> ==================================
>> [$\*.^ -- I miss being one of them
>> ==================================
>>
>
>
>
> --
> Thanks -
> Manish
> ==================================
> [$\*.^ -- I miss being one of them
> ==================================
>
--
Thanks -
Manish
==================================
[$\*.^ -- I miss being one of them
==================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
