How to move storage OEMs to Samba 4.0 ?

[Alexander Bokovoy]

On Sat, Jun 23, 2012 at 10:34 PM, simo <idra at samba.org> wrote:
> On Sat, 2012-06-23 at 11:46 +0300, Alexander Bokovoy wrote:
>> On Sat, Jun 23, 2012 at 10:22 AM, Andrew Bartlett <abartlet at samba.org> wrote:
>> > On Sat, 2012-06-23 at 09:23 +0300, Alexander Bokovoy wrote:
>> >> On Sat, Jun 23, 2012 at 1:40 AM, Andrew Bartlett <abartlet at samba.org> wrote:
>> >> > On Fri, 2012-06-22 at 08:35 -0700, Jeremy Allison wrote:
>> >> >> On Thu, Jun 21, 2012 at 10:10:16PM -0400, simo wrote:
>> >> >> >
>> >> >> > I would say also that the actual vfs ABI should not change, that doesn't
>> >> >> > mean the rest of samba internal are untouchable, but why penalize people
>> >> >> > that use exclusively the VFS interface as published ?
>> >> >> >
>> >> >> > I generally agree with all, although I would prefer if we made an effort
>> >> >> > not to change the VFS ABI in a minor release. I am not to ask to be
>> >> >> > strict about that, the vfs is large enough that we may not hold to the
>> >> >> > promise, but I would like to avoid seeing deliberate ABI change without
>> >> >> > a good reason .. "because we can"
>> >> >>
>> >> >> I agree. I wouldn't break the ABI without good cause also, but
>> >> >> we only promise API compatibility, just like the Linux kernel
>> >> >> and for the same reason.
>> >> >
>> >> > What is the VFS API?
>> >> >
>> >> > Does it include all the other Samba functions that a VFS module could
>> >> > potentially call?
>> >> >
>> >> > (As an example of what I mean, a passdb module AB wrote recently started
>> >> > calling become_root()/unbecome_root())
>> >> The module does not call become_root()/unbecome_root(). Instead, the
>> >> callback for smbldap SASL bind operation is called under
>> >> become_root()/unbecome_root() from within smbldap code. All passdb use
>> >> is actually done with become_root()/unbecome_root() already.
>> >
>> > Ahh, thanks.  But my memory is you did have a module that did this, and
>> > it worked?
>> Yes, it worked, but then we discussed on IRC with you and came to
>> conclusion it is better to move the wrapping where the call happens.
>>
>> > Putting aside this example, my point is just that the functions in the
>> > Samba VFS API could potentially be quite broad.  For example, we
>> > maintained for ages some lp_ helpers, and I presume some modules call
>> > DEBUG().
>> Yes. An issue with 4.0 is that headers are not installed which would
>> allowed to build VFS modules for smbd at all. We'll need to get smbd
>> source3/include headers back into WAF build. For example,
>> source3/include/proto.h is not installed, making hard to build any VFS
>> module that uses lp_parm_const_string() or vfs_file_id_from_sbuf(). Or
>> vfs.h/vfs_macros.h.
>
> We should never install proto.h
>
> We need to come up with a header we are comfortable making public and
> stick there as much of the API we think we can try to support as stable
> public API.
>
> If other people wnat to use internal symbols for convenience, they will
> have to declare them themselves and be on their own when/if we decide to
> change them.
I agree with the idea in principle. What I was trying to point is that
we don't install any of smbd-related headers that would allow building
VFS modules out of tree *at all*.
This is something that needs to be fixed, via refactoring of headers
or otherwise.

-- 
/ Alexander Bokovoy