[PATCH#2][2nd REVIEW?] fake data io module for samba

[Peter Somogyi]

Wait a bit. Andrew, the pread API looks this:

  static ssize_t vfswrap_pread(vfs_handle_struct *handle, files_struct 
*fsp, void *data,
                           size_t n, off_t offset)

All what I can do is a memset / memcpy on that given *data content.
Or is there a safe and agreed hack to replace that pointer in the call 
chain?

BTW I'd be fine with a simple memset as well, just to avoid concerns and 
confusion.

--
Peter Somogyi
IBM Magyarországi Kft.
1117 Budapest
Infopark, Neumann János u. 1.
Hungary
Phone: +36 1 382 5469



Peter Somogyi/Hungary/IBM at IBMHU 
Sent by: samba-technical-bounces at lists.samba.org
11/04/2014 10:08 AM

To
Jeremy Allison <jra at samba.org>, Andrew Bartlett <abartlet at samba.org>, 
cc
samba-technical at samba.org
Subject
Re: [PATCH#2][2nd REVIEW?] fake data io module for samba






Andrew/Jeremy,

Thank you very much for pointing this out, I'm modifying the code using 
the static calloc buffer then!

--
Peter Somogyi
IBM Magyarországi Kft.
1117 Budapest
Infopark, Neumann János u. 1.
Hungary
Phone: +36 1 382 5469



Jeremy Allison <jra at samba.org> 
11/03/2014 10:39 PM
Please respond to
Jeremy Allison <jra at samba.org>


To
Andrew Bartlett <abartlet at samba.org>, 
cc
Jeremy Allison <jra at samba.org>, Peter Somogyi/Hungary/IBM at IBMHU, 
samba-technical at samba.org
Subject
Re: [PATCH#2][2nd REVIEW?] fake data io module for samba






On Tue, Nov 04, 2014 at 10:12:47AM +1300, Andrew Bartlett wrote:
> 
> I'm really quite uncomfortable with having this, even with an option
> set.  I would rather see it send zero or fixed data. 
> 
> What is the largest pread call we should have to return?  Even 16MB of
> zeros allocated as static const in the module would not be an
> unreasonable overhead for a testing module such as this. 

That is a *really* good idea, and I should have
thought of it :-) :-). Thanks Andrew !

Peter, in the "connect" VFS call, calloc a
buffer to use to return for all read calls,
and stash away a pointer to it.

That removes the problem entirely.

Thanks a *lot* Andrew (boy do I feel dumb now :-).

Cheers,

                 Jeremy.