On Wed, Aug 28, 2024 at 12:33 PM Han-Wen Nienhuys <hanwenn@xxxxxxxxx> wrote: > > 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. No guarantee. There was some suggestion about special use for value 0, but I don't remember what it was right now. Thanks, Amir.
