* set_super_anon in fs/super.c
@ 2012-10-23 13:03 Abhijit Chandrakant Pawar
2012-10-23 13:17 ` Rohan Puri
0 siblings, 1 reply; 6+ messages in thread
From: Abhijit Chandrakant Pawar @ 2012-10-23 13:03 UTC (permalink / raw)
To: kernelnewbies
I am working on the layered file systems. I came across a function
called set_super_anon.
This is a callback to the sget function to compare the superblock . This
function accepts two parameters. first is superblock * and second is
void *. If you look at the definition of this function, the void* is
never used.
Many filesystem uses this function when they are mounting the
superblock. Some pass NULL and some pass actual data.I have looked till
2.6.31 but there isnt any trace of the usage of second parameter.
If it is never used then why its added to the function param list? Is
there any historical reason during the older kernel days?
Regards,
Abhijit Pawar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121023/26860a3f/attachment.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* set_super_anon in fs/super.c
2012-10-23 13:03 set_super_anon in fs/super.c Abhijit Chandrakant Pawar
@ 2012-10-23 13:17 ` Rohan Puri
2012-10-23 14:00 ` Abhijit Chandrakant Pawar
0 siblings, 1 reply; 6+ messages in thread
From: Rohan Puri @ 2012-10-23 13:17 UTC (permalink / raw)
To: kernelnewbies
On Tue, Oct 23, 2012 at 6:33 PM, Abhijit Chandrakant Pawar <
abhi.c.pawar@gmail.com> wrote:
> **
> I am working on the layered file systems. I came across a function called
> set_super_anon.
> This is a callback to the sget function to compare the superblock . This
> function accepts two parameters. first is superblock * and second is void
> *. If you look at the definition of this function, the void* is never
> used.
> Many filesystem uses this function when they are mounting the superblock.
> Some pass NULL and some pass actual data.I have looked till 2.6.31 but
> there isnt any trace of the usage of second parameter.
>
> If it is never used then why its added to the function param list? Is
> there any historical reason during the older kernel days?
>
> Regards,
> Abhijit Pawar
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
Hi Abhijit,
See the issue is this function is passed as an argument to sget(), now
their are many other file-systems that defined their own set_super function
& for that they need data argument where they usually pass mount-related
data
For eg. see the definition and usage of function nfs_set_super().
So, the prototype of the sget() should contain function ptr (set_super())
and this function ptr should have data argument also. Now one usage can
imply NO USE of the data parameter, which is set_super_anon, but other
file-systems may require, so the sget() prototype should be generic to
support, both the cases.
- Rohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121023/f5a87449/attachment-0001.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* set_super_anon in fs/super.c
2012-10-23 13:17 ` Rohan Puri
@ 2012-10-23 14:00 ` Abhijit Chandrakant Pawar
2012-10-24 8:20 ` Rohan Puri
0 siblings, 1 reply; 6+ messages in thread
From: Abhijit Chandrakant Pawar @ 2012-10-23 14:00 UTC (permalink / raw)
To: kernelnewbies
Hi Rohan,
On Tue, 2012-10-23 at 18:47 +0530, Rohan Puri wrote:
>
>
> On Tue, Oct 23, 2012 at 6:33 PM, Abhijit Chandrakant Pawar
> <abhi.c.pawar@gmail.com> wrote:
>
> I am working on the layered file systems. I came across a
> function called set_super_anon.
> This is a callback to the sget function to compare the
> superblock . This function accepts two parameters. first is
> superblock * and second is void *. If you look at the
> definition of this function, the void* is never used.
> Many filesystem uses this function when they are mounting the
> superblock. Some pass NULL and some pass actual data.I have
> looked till 2.6.31 but there isnt any trace of the usage of
> second parameter.
>
> If it is never used then why its added to the function param
> list? Is there any historical reason during the older kernel
> days?
>
> Regards,
> Abhijit Pawar
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> Hi Abhijit,
>
> See the issue is this function is passed as an argument to sget(), now
> their are many other file-systems that defined their own set_super
> function & for that they need data argument where they usually pass
> mount-related data
>
> For eg. see the definition and usage of function nfs_set_super().
>
> So, the prototype of the sget() should contain function ptr
> (set_super()) and this function ptr should have data argument also.
> Now one usage can imply NO USE of the data parameter, which is
> set_super_anon, but other file-systems may require, so the sget()
> prototype should be generic to support, both the cases.
>
Yes... thats what I thought. many are passing data un-necessarily to
this function wherein they already have captured the required
information for their purpose in their own defined function.
Wouldnt that cause stack to store the value un-necessarily? It would be
good if everybody passes NULL as second param.
> - Rohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121023/e410b56f/attachment.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* set_super_anon in fs/super.c
2012-10-23 14:00 ` Abhijit Chandrakant Pawar
@ 2012-10-24 8:20 ` Rohan Puri
2012-10-25 4:10 ` Abhijit Pawar
0 siblings, 1 reply; 6+ messages in thread
From: Rohan Puri @ 2012-10-24 8:20 UTC (permalink / raw)
To: kernelnewbies
Look inline for comments.
On Tue, Oct 23, 2012 at 7:30 PM, Abhijit Chandrakant Pawar <
abhi.c.pawar@gmail.com> wrote:
> **
> Hi Rohan,
>
>
> On Tue, 2012-10-23 at 18:47 +0530, Rohan Puri wrote:
>
>
>
> On Tue, Oct 23, 2012 at 6:33 PM, Abhijit Chandrakant Pawar <
> abhi.c.pawar at gmail.com> wrote:
>
> I am working on the layered file systems. I came across a function called
> set_super_anon.
> This is a callback to the sget function to compare the superblock . This
> function accepts two parameters. first is superblock * and second is void
> *. If you look at the definition of this function, the void* is never
> used.
> Many filesystem uses this function when they are mounting the superblock.
> Some pass NULL and some pass actual data.I have looked till 2.6.31 but
> there isnt any trace of the usage of second parameter.
>
> If it is never used then why its added to the function param list? Is
> there any historical reason during the older kernel days?
>
> Regards,
> Abhijit Pawar
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> Hi Abhijit,
>
> See the issue is this function is passed as an argument to sget(), now
> their are many other file-systems that defined their own set_super function
> & for that they need data argument where they usually pass mount-related
> data
>
> For eg. see the definition and usage of function nfs_set_super().
>
> So, the prototype of the sget() should contain function ptr (set_super())
> and this function ptr should have data argument also. Now one usage can
> imply NO USE of the data parameter, which is set_super_anon, but other
> file-systems may require, so the sget() prototype should be generic to
> support, both the cases.
>
> Yes... thats what I thought. many are passing data un-necessarily to
> this function wherein they already have captured the required information
> for their purpose in their own defined function.
>
Do you mean to say, each fs's own set_super function makes a call to
set_anon_super() with data parameter as their specific data, but
set_anon_super makes no use of it?
>
> Wouldnt that cause stack to store the value un-necessarily? It would be
> good if everybody passes NULL as second param.
>
> Yes, each fs's set_super, if makes a call to anon_super() should pass NULL
as the second parameter(void *data) since anon_super doesnt make use of
this parameter, need for this parameter just arises to match the prototype
of sget()'s function ptr agrument. Also do remember the pointer to this
data is passed, so only a word-size of extra stack is utilized when a call
to this function is made.
> - Rohan
>
>
- Rohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121024/56a620d0/attachment.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* set_super_anon in fs/super.c
2012-10-24 8:20 ` Rohan Puri
@ 2012-10-25 4:10 ` Abhijit Pawar
2012-10-25 5:05 ` Rohan Puri
0 siblings, 1 reply; 6+ messages in thread
From: Abhijit Pawar @ 2012-10-25 4:10 UTC (permalink / raw)
To: kernelnewbies
On 10/24/2012 01:50 PM, Rohan Puri wrote:
> Look inline for comments.
>
> On Tue, Oct 23, 2012 at 7:30 PM, Abhijit Chandrakant Pawar
> <abhi.c.pawar at gmail.com <mailto:abhi.c.pawar@gmail.com>> wrote:
>
> Hi Rohan,
>
>
> On Tue, 2012-10-23 at 18:47 +0530, Rohan Puri wrote:
>>
>>
>> On Tue, Oct 23, 2012 at 6:33 PM, Abhijit Chandrakant Pawar
>> <abhi.c.pawar at gmail.com <mailto:abhi.c.pawar@gmail.com>> wrote:
>>
>> I am working on the layered file systems. I came across a
>> function called set_super_anon.
>> This is a callback to the sget function to compare the
>> superblock . This function accepts two parameters. first is
>> superblock * and second is void *. If you look at the
>> definition of this function, the void* is never used.
>> Many filesystem uses this function when they are mounting the
>> superblock. Some pass NULL and some pass actual data.I have
>> looked till 2.6.31 but there isnt any trace of the usage of
>> second parameter.
>>
>> If it is never used then why its added to the function param
>> list? Is there any historical reason during the older kernel
>> days?
>>
>> Regards,
>> Abhijit Pawar
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> <mailto:Kernelnewbies@kernelnewbies.org>
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>> Hi Abhijit,
>>
>> See the issue is this function is passed as an argument to
>> sget(), now their are many other file-systems that defined their
>> own set_super function & for that they need data argument where
>> they usually pass mount-related data
>>
>> For eg. see the definition and usage of function nfs_set_super().
>>
>> So, the prototype of the sget() should contain function ptr
>> (set_super()) and this function ptr should have data argument
>> also. Now one usage can imply NO USE of the data parameter, which
>> is set_super_anon, but other file-systems may require, so the
>> sget() prototype should be generic to support, both the cases.
>>
> Yes... thats what I thought. many are passing data
> un-necessarily to this function wherein they already have captured
> the required information for their purpose in their own defined
> function.
>
> Do you mean to say, each fs's own set_super function makes a call to
> set_anon_super() with data parameter as their specific data, but
> set_anon_super makes no use of it?
>
>
> Wouldnt that cause stack to store the value un-necessarily? It
> would be good if everybody passes NULL as second param.
>
> Yes, each fs's set_super, if makes a call to anon_super() should pass
> NULL as the second parameter(void *data) since anon_super doesnt make
> use of this parameter, need for this parameter just arises to match
> the prototype of sget()'s function ptr agrument. Also do remember the
> pointer to this data is passed, so only a word-size of extra stack is
> utilized when a call to this function is made.
I have made a patch for those filesystems and submitted to the kernel list.
>> - Rohan
>
>
> - Rohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121025/fc0df94d/attachment.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* set_super_anon in fs/super.c
2012-10-25 4:10 ` Abhijit Pawar
@ 2012-10-25 5:05 ` Rohan Puri
0 siblings, 0 replies; 6+ messages in thread
From: Rohan Puri @ 2012-10-25 5:05 UTC (permalink / raw)
To: kernelnewbies
On Thu, Oct 25, 2012 at 9:40 AM, Abhijit Pawar <abhi.c.pawar@gmail.com>wrote:
> On 10/24/2012 01:50 PM, Rohan Puri wrote:
>
> Look inline for comments.
>
> On Tue, Oct 23, 2012 at 7:30 PM, Abhijit Chandrakant Pawar <
> abhi.c.pawar at gmail.com> wrote:
>
>> Hi Rohan,
>>
>>
>> On Tue, 2012-10-23 at 18:47 +0530, Rohan Puri wrote:
>>
>>
>>
>> On Tue, Oct 23, 2012 at 6:33 PM, Abhijit Chandrakant Pawar <
>> abhi.c.pawar at gmail.com> wrote:
>>
>> I am working on the layered file systems. I came across a function called
>> set_super_anon.
>> This is a callback to the sget function to compare the superblock . This
>> function accepts two parameters. first is superblock * and second is void
>> *. If you look at the definition of this function, the void* is never
>> used.
>> Many filesystem uses this function when they are mounting the superblock.
>> Some pass NULL and some pass actual data.I have looked till 2.6.31 but
>> there isnt any trace of the usage of second parameter.
>>
>> If it is never used then why its added to the function param list? Is
>> there any historical reason during the older kernel days?
>>
>> Regards,
>> Abhijit Pawar
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>> Hi Abhijit,
>>
>> See the issue is this function is passed as an argument to sget(), now
>> their are many other file-systems that defined their own set_super function
>> & for that they need data argument where they usually pass mount-related
>> data
>>
>> For eg. see the definition and usage of function nfs_set_super().
>>
>> So, the prototype of the sget() should contain function ptr (set_super())
>> and this function ptr should have data argument also. Now one usage can
>> imply NO USE of the data parameter, which is set_super_anon, but other
>> file-systems may require, so the sget() prototype should be generic to
>> support, both the cases.
>>
>> Yes... thats what I thought. many are passing data un-necessarily to
>> this function wherein they already have captured the required information
>> for their purpose in their own defined function.
>>
> Do you mean to say, each fs's own set_super function makes a call to
> set_anon_super() with data parameter as their specific data, but
> set_anon_super makes no use of it?
>
>>
>> Wouldnt that cause stack to store the value un-necessarily? It would be
>> good if everybody passes NULL as second param.
>>
>> Yes, each fs's set_super, if makes a call to anon_super() should pass
> NULL as the second parameter(void *data) since anon_super doesnt make use
> of this parameter, need for this parameter just arises to match the
> prototype of sget()'s function ptr agrument. Also do remember the pointer
> to this data is passed, so only a word-size of extra stack is utilized when
> a call to this function is made.
>
> I have made a patch for those filesystems and submitted to the kernel
> list.
>
> - Rohan
>>
>>
> - Rohan
>
>
> Cool :)
- Rohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121025/ee1ffa9a/attachment.html
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-10-25 5:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-23 13:03 set_super_anon in fs/super.c Abhijit Chandrakant Pawar
2012-10-23 13:17 ` Rohan Puri
2012-10-23 14:00 ` Abhijit Chandrakant Pawar
2012-10-24 8:20 ` Rohan Puri
2012-10-25 4:10 ` Abhijit Pawar
2012-10-25 5:05 ` Rohan Puri
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).