How to move storage OEMs to Samba 4.0 ?

[simo]

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.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>