On Oct 16, 2013, at 10:24 AM, Robert Mustacchi <***@joyent.com> wrote:
> On 10/16/13 9:59 , Saso Kiselkov wrote:
>> On 10/16/13 5:43 PM, George Wilson wrote:
>>> On 10/16/13 10:02 AM, Saso Kiselkov wrote:
>>>> On 10/16/13 2:41 PM, ***@gmail.com wrote:
>>>>> Given that this is a private interface that seems reasonable. I
>>>>> don't think there is that much harm in leaving the old behind for a
>>>>> while, but given we don't have "releases" as such, its unclear how we
>>>>> we would ever decide that it was time to finally nuke the old one.
>>>>>
>>>>> I'm ambivalent either way. Ditching the old interface entirely
>>>>> is more consistent with Linux practices than Solaris practices
>>>>> though. :-)
>>>> Agree that it is un-Solarisy to break APIs, but since both you and me
>>>> are ambivalent here and George and Matt are opposed, I've gone ahead and
>>>> created a new webrev with a modified call signature and bumped library
>>>> version:
>>>> http://cr.illumos.org/~webrev/skiselkov/4012_new_api/
>>>>
>>>> Let's get a clear-cut decision on this. Frankly, if we can't make any
>>>> headway on a change this small I worry about our ability to keep up with
>>>> larger changes that are in the queue.
>>>>
>>>> Cheers,
>>> First the main code change look good to me (minus the library revision):
>>>
>>> On the question of breaking APIs, we have to remember that illumos is a
>>> source repo and not a release. Should we be required to rev the library
>>> in the source repo if it's a private interface? In Nevada we made
>>> changes to private APIs all the time without a library rev. So what is
>>> the model here?
>>
>> Good question. I'm not sure. I think simply stating that "we're a source
>> repo!" doesn't really absolve us of playing nice with downstream users.
>> We *do* include a build system that is used to prepare packages and
>> control versions, so we are at least partly responsible for making sure
>> things don't explode haphazardly.
>
> Part of playing nice involves telling people what we consider stable and
> what we don't and folks who use the things that we say aren't stable
> being willing to accept the fact that they might get broken. It also
> underscores the importance of providing useful stable interfaces. Yes
> the illumos-gate packages deliver header files and compilation symlinks
> to unstable libraries. I think it's worthwhile that we do so folks can
> opt to consume an unstable interface with the risk of breakage.
>
> In illumos today, any library that is marked stable, eg. uses versioned
> symbols, has manual pages the functionality and stability, etc. will
> cause at least folks in illumos to bend over backwards not to break
> API/ABI even when it really sucks (see 32-bit libc and FILE *). It
> doesn't matter that there isn't a 'release' of illumos for that.
> Conversely when something isn't marked stable we do have the right to
> break it. Obviously, the costs have to be weighed appropriately, you
> don't want to break users arbitrarily. libzfs has no manual pages, only
> uses SUNWprivate symbols, and hey, at least it doesn't call exit anymore
> for you (I think).
>
> Really this just further underscores the importance of getting to a
> stable zfs library interface, which libzfs was never intended to be.
> I've certainly been at the receiving end of libzfs breakage and it's
> annoying, but really it sounds like we should really be working to get
> libzfs_core.so into a state where we can declare it to be stable.
Agree on all counts. The problem is how badly do we burn people who are having to live with the lack of a public API? (And its not just APIs but ABIs that count too, btw.) I'm ok with the idea that this was a private API and we're going to break some folks -- but I also do think that if it was easy to avoid breaking them, there might be merit in doing so. Along with a great big warning "this legacy PRIVATE interface WILL be removed SOON." What I don't know is how many people will be busted by this change… I suspect its not very many, and that those who will be know how to cope.
I do want to be careful about setting precedents here. We need to be careful about breaking public interfaces, and we need to also move various critical interfaces from being private-only to being public. There are lots of candidates here -- not just libzfs. At DEY we wound up needing to access a bunch of private interfaces in order to get any real work done, unless we just wanted to fork/exec various programs.
Oracle/Sun was always very cautious about raising commitment for interfaces. Too cautious IMO. The situation with libzfs is a good example of that. People needed these interfaces, and since they couldn't get the committed interface, they just pushed on ahead.
We need to be more proactive in providing reasonable public/documented interfaces for those important parts of the system -- data links, networking, zone management, and of course ZFS.
We also need a release management system to tie interface change to, but that's another topic… :-)
- Garrett
>
> Robert
>
>
> -------------------------------------------
> illumos-zfs
> Archives: https://www.listbox.com/member/archive/182191/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182191/22035932-85c5d227
> Modify Your Subscription: https://www.listbox.com/member/?&
> Powered by Listbox: http://www.listbox.com