Date: Fri, 30 Sep 2016 18:20:06 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Lewis Donzis <lew@perftech.com> Cc: freebsd-arch@freebsd.org, deischen@freebsd.org Subject: Re: mq on kqueue broken after upgrade to FreeBSD 11 Message-ID: <20160930152006.GS38409@kib.kiev.ua> In-Reply-To: <19A6EEAA-C68E-4DAD-B98F-4D904734BD8B@perftech.com> References: <8A6CD0D3-C4D5-40DF-B2AD-4C454CC88AD1@perftech.com> <20160930094544.GP38409@kib.kiev.ua> <19A6EEAA-C68E-4DAD-B98F-4D904734BD8B@perftech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 30, 2016 at 06:52:52AM -0500, Lewis Donzis wrote: > > > On Sep 30, 2016, at 4:45 AM, Konstantin Belousov <kostikbel@gmail.com> wrote: > > Where was a discussion about the function presence being the mistake ? > > I think it was here: https://lists.freebsd.org/pipermail/freebsd-current/2015-November/058706.html > > which was just about a year ago. Perhaps I???m reading it wrong, but it seems like the implication is that removing the symbol from being exported was a "fix", where DE says "Why do the tests in tests/sys/mqueue/ try to use non-public APIs?" and then later, "symbol versioning for librt was broken and leaking symbols that shouldn't have been leaked." > I added Daniel to Cc:. I think that the issue you referenced is somewhat different. The r291439 commit restored symbol versioning, i.e. before it, all symbols were accessible. Right now we are discussing the merits of making one symbol accessible, which was removed from the export table as a side effect of the fix. In other words, if at the time of r291439 the symbol was present in the public export list, your code would not note the fix. > > > In r291439, symbol versioning for librt was fixed, and apparently > > __mq_oshandle() is not present in the global symbols list for librt. > > I suspect that this is an erronous ommission, since the function' > > declaration is present in the mqueue.h header and it is used by some > > mqueue tests. > > > > As such, I believe that exporting it is the intended option there. > > The following patch should fix the problem for you. > > That makes sense, and appreciate the patch, but just to be clear, does your change get committed so that we won???t have to re-apply it after future updates/upgrades? > As I stated, my opinion is that this symbol can be usefully exported. Its name is in implementation-private namespace, and there are uses where access to the mqueue fd (or to the timer id) gives more flexibility and significantly reduces the amount of code. Unless there appear strong objections against the export, I will commit the patch, sure.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160930152006.GS38409>