Re: [PATCH] Linux: Add getdents64 system call

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 28/05/2019 16:55, Carlos O'Donell wrote:
> On 5/28/19 3:26 AM, Florian Weimer wrote:
>> * Carlos O'Donell:
>>
>>> On 5/15/19 11:10 AM, Florian Weimer wrote:
>>>> No 32-bit system call wrapper is added because the interface
>>>> is problematic because it cannot deal with 32-bit inode numbers
>>
>> (should say 64-bit inode numbers)
> 
> I figured that.
> 
>>>> and 64-bit directory hashes.
>>>
>>> Are you saying we do not want to ever add a getdents syscall wrapper
>>> because it would have problems that users couldn't fix, or problems
>>> the user could fix if they were careful?
>>
>> The whole thing would be confusing.  The position of d_type is different
>> on 64-bit architectures, and future 32-bit architectures may not even
>> have it.
> 
> Right, I noticed that d_type moved when comparing the two arches.
> 
> Is there any reason we don't define getdents defaulting to getdents64?
> 
> Is it because of the established precedent set for all the other fs-related
> 32-bit and 64-bit syscalls, whose default selection for a non-specific name
> like getdents, is predicated on large-file support being turned on?

I would prefer that if we eventually make a switch to make default fs-related
function to route to LFS variants to do as a whole instead of a symbol base.
Otherwise there is potential case of using wrong type, in this case it would
require to explicit use dirent64 type when calling getdents for 32-bit archs.  

> 
>>>> A future commit will deprecate the undocumented getdirentries
>>>> and getdirentries64 functions.
>>>
>>> Why are getdirentries and getdirentries64 considered deprecated?
>>> Is it because getdents and getdents64 superseded them?
>>
>> They perform a useless lseek call.
> 
> So if I understand correctly:
> 
> * The have poorer performance.
> 
> * We can confuse developers when presenting two similar interfaces for
>   effectively the same operations.
> 
> The downside is that there may be BSD software that we make harder to
> port because you have to rewrite getdirentries into getdents64.
> 
> Unless there is a stronger reason for deprecation I would simply leave
> getdirentries.
> 
> Are the above reasons the full list? Do you consider these reasons enough
> for deprecation of getdirenties?
> 
> I know I'm getting ahead of myself here, but while we're at it we might
> as well have a precursor conversation to the future patch.

My understanding is lseek from getdirentries is not really useless, but
exactly the semantic it aims to provide. Linux getdents does not have
the concept of offset, different than BSDs one which is usually 
syscall (FreeBSD for instance).

I am not sure, however, who usefull this is in reality. On FreeBSD repo
(not including ports), I see few uses: sdiff tool is the only binary and
opendir seems call it internally.

Now that glibc is providing a LFS variant, I think it would be better
served by a wrapper library instead (like libbsd).