How to move storage OEMs to Samba 4.0 ?

[simo]

On Sat, 2012-06-23 at 22:38 +0300, Alexander Bokovoy wrote: 
> 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.

Agreed.

Simo.

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