Re: [Libcdio-devel] Re: private udf information

[Rocky Bernstein]

On Tue, Oct 19, 2010 at 12:01 AM, Shaya Potter <address@hidden> wrote:

> On 10/18/2010 11:51 PM, Rocky Bernstein wrote:
>
>> On Mon, Oct 18, 2010 at 6:28 PM, Shaya Potter<address@hidden>  wrote:
>>
>>  as a followup to my previous information, this function I added to my own
>>> private copy lets me do what I need
>>>
>>> uint32_t udf_get_start_block(const udf_dirent_t *p_udf_dirent)
>>> {
>>>  udf_t *p_udf = p_udf_dirent->p_udf;
>>>  uint32_t i_max_size;
>>>  lba_t i_start = offset_to_lba(p_udf_dirent, p_udf->i_position,&i_start,
>>>                                &i_max_size);
>>>  return i_start;
>>> }
>>>
>>> a better solution might be a stat() type call that returns a lot of
>>> information in a struct.
>>>
>>
>>
>> Suppose both struct udf_dirent_s and the udf_get_start_block() prototype
>> were put in udf.h. In other words suppose these were both made public.
>>
>> Would that suffice?
>>
>> A comment about udf_get_start_block is that it looks like at some point
>> one
>> might want to do the same thing for i_max_size (as you indicated in the
>> original post); The code to get this would look almost identical as above.
>> So, as you suggest, perhaps a function returns both values in one shot
>> would
>> be good.
>>
>
> the Q is, what parts of udf_dirent_s really need non exported functionality
> to understand.


I don't see any reason right now to hide anything in udf_dirent_s, so the
simplest thing is to expose all of it. If you are imagining other things in
struct stat that aren't in udf_dirent_s, well, they aren't readily available
as the start block and length are.


For instance, I couldn't write udf_get_start_block() easily outside of
> libudf, because I needed offset_to_lba().
>

Yes, so that would be made public too.


>
> As mentioned, part of me thinks a well thought out udf_stat() function is
> what's needed.
>

Ok. Suggest something. Or better, implement it.