All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Tinguely <tinguely@sgi.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Eric Sandeen <sandeen@redhat.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: Is jdm_delete_filehandle part of a public API?
Date: Tue, 29 Jul 2014 15:54:03 -0500	[thread overview]
Message-ID: <53D809EB.80207@sgi.com> (raw)
In-Reply-To: <53D801B1.5000300@sandeen.net>

On 07/29/14 15:18, Eric Sandeen wrote:
> On 7/29/14, 3:04 PM, Mark Tinguely wrote:
>> On 07/29/14 13:18, Mark Tinguely wrote:
>>> On 07/29/14 12:31, Eric Sandeen wrote:
>>>> I was cleaning up xfsprogs to plug some leaks, and wanted to use
>>>> jdm_delete_filehandle(). I noticed that it has an "hlen" argument which
>>>> is unused.
>>>>
>>>> Can we remove that, or is this part of a public API? It's not in any
>>>> manpage (or even called anywhere in xfsprogs/xfstests/xfsdump/dmapi)
>>>> but it is in a public header...
>>>>
>>>> anyone know?
>>>>
>>>> If needed I guess I can just call it with hlen==0, but that seems odd.
>>>>
>>>> Thanks,
>>>> -Eric
>>>
>>> The first thing that comes to mind is maybe they trying to distinguish
>>> between a fshandle or handle. Or they we trying to be consistent with
>>> the allocation calls.
>>>
>>> The libhandle free_handle has the same calling parameters. It also does
>>> nothing with the length. That we cannot change without breaking existing
>>> code.
>>>
>>> I will look/ask around.
>>>
>>> --Mark.
>>
>> Looks like the code is pretty sloppy with freeing the handles.
>
> yeah, that's what I was going to fix :)
>
>> Best guess is jdm_delete_filehandle() and free_handle are trying to
>> keep the API similar to DMAPI. The DMAPI handle free routine,
>> dm_handle_free(), also has a second length parameter that is not used
>> in the library.
>>
>> The code example that I saw are similar to the use in xfsdump, where
>> the length used in the free comes from the handle creation/conversion
>> routine.
>
> yup but I don't think jdm_getfshandle has anything similar does it?

nope. Do you know why there is a jdm and a libhandle libs?

>
>> Since the xfsprogs do not open handles with calls that provide a
>> length. How about FSHANDLE_SZ and FILEHANDLE_SZ depending on if it is
>> a xfs_fshandle or xfs_handle?
>
> *shrug* it's not used anyway - I'm not sure why we'd need to invent a
> macro to pass in only to have it ignored.  Is there any advantage to that?

never mind... handles are opaque and we should not be defining a size.

I did the grep and saw that the sizes were defined and thought they were 
better than nothing. I did not not realize that the defines are are in 
jdm.c and not a header file. In that case, nothing is better than adding 
a define for an opaque item.

> -Eric

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2014-07-29 20:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29 17:31 Is jdm_delete_filehandle part of a public API? Eric Sandeen
2014-07-29 18:18 ` Mark Tinguely
2014-07-29 20:04   ` Mark Tinguely
2014-07-29 20:18     ` Eric Sandeen
2014-07-29 20:54       ` Mark Tinguely [this message]
2014-07-29 23:46 ` Dave Chinner
2014-08-01 13:53 ` Christoph Hellwig
2014-08-04  2:20   ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D809EB.80207@sgi.com \
    --to=tinguely@sgi.com \
    --cc=sandeen@redhat.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.