Re: Zero-copy CameraFile transfer?

Hi,

No, this works both ways.

You can download files into a filedescriptor / handler or memory,
or upload.

But both use some buffering. As far as I see libusb with its urb model
is not directly doing filedescriptor passing, so there will always be
a bit of buffers involved.

Ciao, Marcus

On Thu, Mar 10, 2022 at 09:36:09AM -0800, Dave Taylor wrote:
> That would work for transferring a file to the camera, right?  I'm
> more concerned about transferring a file from the camera.
> 
>         =-ddt->
> 
> On Wed, Mar 9, 2022 at 11:32 PM Marcus Meissner <[email protected]> wrote:
> >
> > On Wed, Mar 09, 2022 at 07:02:40PM -0800, Dave Taylor wrote:
> > > Hi, I've been looking through the libgphoto2 API for a way to
> > > implement zero-copy transfers such as through Linux's sendfile(2)
> > > system call, but it seems there isn't currently an exposed way to get
> > > at an open CameraFile's file descriptor to pull this off.
> > >
> > > I do see that the CameraFile object has an fd member in it that
> > > gp_file_slurp() references, but the comments say that gp_file_slurp()
> > > is an internal function and that gp_file_open() is now deprecated.
> > >
> > > Is there a cleaner way to do this?  Or should I not play with matches?  :)
> >
> > If you create a CameraFile from a fd or a handler (gp_file_new_from_fd /
> > gp_file_new_from_handler), it will only use a small local buffer (currently 512kb)
> > to transfer data.
> >
> > gp_file_new() itself would use in-memory storage for the full image.
> >
> > I can take a look to avoid any kind of buffering, not sure if libusb1 allows this.
> >
> > Ciao, Marcus
> 
> 
> _______________________________________________
> Gphoto-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gphoto-user