On Wed, Aug 28, 2024 at 12:06 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Wed, Aug 28, 2024 at 12:00 PM Han-Wen Nienhuys <hanwenn@xxxxxxxxx> wrote: > > > > On Tue, Aug 27, 2024 at 3:48 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > > BTW, since you are one of the first (publicly announced) users of > > > FUSE passthrough, it would be helpful to get feedback about API, > > > which could change down the road and about your wish list. > > > > I guess it is too late to change now, but I noticed that > > fuse_backing_map takes the file descriptors and backing IDs as signed > > int32. Why int32 and not uint32 ? open(2) is documented as never > > returning negative integers. > > > > It seemed safer this way and allows to extend the API with special > return codes later. > Why? what is to gain from uint32 in this API? Consistency. Almost all fields in the FUSE API are uint64 or uint32. Having it be different suggests that something special is going on, and that negative numbers have a valid use case. If they're always non-negative, that could be documented. Similarly, it looks like the first backing ID is usually 1. Is it guaranteed that 0 is never a valid backing ID? I am not sure, and it would certainly help implementation on my side. -- Han-Wen Nienhuys - hanwenn@xxxxxxxxx - http://www.xs4all.nl/~hanwen
