12 Jun 2012 03:58
12 Jun 2012 05:45
Re: liblzf incompatibility
Thor Lancelot Simon <tls <at> panix.com>
2012-06-12 03:45:11 GMT
2012-06-12 03:45:11 GMT
On Tue, Jun 12, 2012 at 01:58:12AM +0000, YAMAMOTO Takashi wrote: > hi, > > is there a near-future plan to use liblzf for any in-tree stuff? > otherwise i'd suggest to disable it because it only causes problems. > see PR/46426. I have code that uses it, both in userspace and the kernel, but I never checked it in because I ran into a build problem with src/common. Let me see what I can do about both issues. -- -- Thor Lancelot Simon tls <at> panix.com "We cannot usually in social life pursue a single value or a single moral aim, untroubled by the need to compromise with others." - H.L.A. Hart
12 Jun 2012 18:12
Re: liblzf incompatibility
Thor Lancelot Simon <tls <at> panix.com>
2012-06-12 16:12:23 GMT
2012-06-12 16:12:23 GMT
On Mon, Jun 11, 2012 at 11:45:11PM -0400, Thor Lancelot Simon wrote: > On Tue, Jun 12, 2012 at 01:58:12AM +0000, YAMAMOTO Takashi wrote: > > hi, > > > > is there a near-future plan to use liblzf for any in-tree stuff? > > otherwise i'd suggest to disable it because it only causes problems. > > see PR/46426. > > I have code that uses it, both in userspace and the kernel, but I never > checked it in because I ran into a build problem with src/common. Let me > see what I can do about both issues. I am looking at the PR, and I don't really think I agree that our liblzf is "incompatible with the upstream version". Unfortunately, the upstream version can be compiled with either of two different APIs. I think the bug is actually in programs whose autoconf logic detects liblzf without detecting which API is in use. I chose the API that was more general, which I do think was the correct decision. Thor
12 Jun 2012 19:51
Re: liblzf incompatibility
YAMAMOTO Takashi <yamt <at> mwd.biglobe.ne.jp>
2012-06-12 17:51:42 GMT
2012-06-12 17:51:42 GMT
hi, > On Mon, Jun 11, 2012 at 11:45:11PM -0400, Thor Lancelot Simon wrote: >> On Tue, Jun 12, 2012 at 01:58:12AM +0000, YAMAMOTO Takashi wrote: >> > hi, >> > >> > is there a near-future plan to use liblzf for any in-tree stuff? >> > otherwise i'd suggest to disable it because it only causes problems. >> > see PR/46426. >> >> I have code that uses it, both in userspace and the kernel, but I never >> checked it in because I ran into a build problem with src/common. Let me >> see what I can do about both issues. > > I am looking at the PR, and I don't really think I agree that our liblzf > is "incompatible with the upstream version". > > Unfortunately, the upstream version can be compiled with either of two > different APIs. I think the bug is actually in programs whose autoconf > logic detects liblzf without detecting which API is in use. as far as i know, there's no reasonable way to detect the compile-time option. so assuming the default is reasonable. > > I chose the API that was more general, which I do think was the correct > decision. i think the option is for users who embed the library into their applications, not for general purpose OSes like us.(Continue reading)
30 Jul 2012 02:14
Re: liblzf incompatibility
YAMAMOTO Takashi <yamt <at> mwd.biglobe.ne.jp>
2012-07-30 00:14:51 GMT
2012-07-30 00:14:51 GMT
hi, > hi, > >> On Mon, Jun 11, 2012 at 11:45:11PM -0400, Thor Lancelot Simon wrote: >>> On Tue, Jun 12, 2012 at 01:58:12AM +0000, YAMAMOTO Takashi wrote: >>> > hi, >>> > >>> > is there a near-future plan to use liblzf for any in-tree stuff? >>> > otherwise i'd suggest to disable it because it only causes problems. >>> > see PR/46426. >>> >>> I have code that uses it, both in userspace and the kernel, but I never >>> checked it in because I ran into a build problem with src/common. Let me >>> see what I can do about both issues. any progress? if you don't want to remove it, how about renaming it? YAMAMOTO Takashi >> >> I am looking at the PR, and I don't really think I agree that our liblzf >> is "incompatible with the upstream version". >> >> Unfortunately, the upstream version can be compiled with either of two >> different APIs. I think the bug is actually in programs whose autoconf >> logic detects liblzf without detecting which API is in use. >(Continue reading)
17 Aug 2012 02:00
Re: liblzf incompatibility
YAMAMOTO Takashi <yamt <at> mwd.biglobe.ne.jp>
2012-08-17 00:00:31 GMT
2012-08-17 00:00:31 GMT
hi, can you reply? YAMAMOTO Takashi > hi, > >> hi, >> >>> On Mon, Jun 11, 2012 at 11:45:11PM -0400, Thor Lancelot Simon wrote: >>>> On Tue, Jun 12, 2012 at 01:58:12AM +0000, YAMAMOTO Takashi wrote: >>>> > hi, >>>> > >>>> > is there a near-future plan to use liblzf for any in-tree stuff? >>>> > otherwise i'd suggest to disable it because it only causes problems. >>>> > see PR/46426. >>>> >>>> I have code that uses it, both in userspace and the kernel, but I never >>>> checked it in because I ran into a build problem with src/common. Let me >>>> see what I can do about both issues. > > any progress? > > if you don't want to remove it, how about renaming it? > > YAMAMOTO Takashi > >>> >>> I am looking at the PR, and I don't really think I agree that our liblzf(Continue reading)
28 Aug 2012 21:40
Re: liblzf incompatibility
Mindaugas Rasiukevicius <rmind <at> netbsd.org>
2012-08-28 19:40:40 GMT
2012-08-28 19:40:40 GMT
yamt <at> mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: > hi, > > > hi, > > > >> On Mon, Jun 11, 2012 at 11:45:11PM -0400, Thor Lancelot Simon wrote: > >>> On Tue, Jun 12, 2012 at 01:58:12AM +0000, YAMAMOTO Takashi wrote: > >>> > hi, > >>> > > >>> > is there a near-future plan to use liblzf for any in-tree stuff? > >>> > otherwise i'd suggest to disable it because it only causes problems. > >>> > see PR/46426. > >>> > >>> I have code that uses it, both in userspace and the kernel, but I > >>> never checked it in because I ran into a build problem with > >>> src/common. Let me see what I can do about both issues. > > any progress? > > if you don't want to remove it, how about renaming it? I think this ought to be removed from netbsd-6 (incompatible and there are no users, nor there is going to be as we are in RC1) and at the very least disabled in -current. > > YAMAMOTO Takashi -- -- Mindaugas(Continue reading)
28 Aug 2012 21:52
Re: liblzf incompatibility
Thor Lancelot Simon <tls <at> panix.com>
2012-08-28 19:52:08 GMT
2012-08-28 19:52:08 GMT
On Tue, Aug 28, 2012 at 08:40:40PM +0100, Mindaugas Rasiukevicius wrote: > > I think this ought to be removed from netbsd-6 (incompatible and there are > no users, nor there is going to be as we are in RC1) and at the very least > disabled in -current. I would prefer to switch the userspce API to the other one and bump the library major version number. I do have kernel code which I am about to check in that uses lzf (an entropy estimator). As I told yamt privately, I will deal with this this week. Sorry for the delay. Thor
29 Aug 2012 09:32
Re: liblzf incompatibility
Christos Zoulas <christos <at> astron.com>
2012-08-29 07:32:02 GMT
2012-08-29 07:32:02 GMT
In article <20120828194151.BB89014A37A <at> mail.netbsd.org>, Mindaugas Rasiukevicius <rmind <at> netbsd.org> wrote: >yamt <at> mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: >> hi, >> >> > hi, >> > >> >> On Mon, Jun 11, 2012 at 11:45:11PM -0400, Thor Lancelot Simon wrote: >> >>> On Tue, Jun 12, 2012 at 01:58:12AM +0000, YAMAMOTO Takashi wrote: >> >>> > hi, >> >>> > >> >>> > is there a near-future plan to use liblzf for any in-tree stuff? >> >>> > otherwise i'd suggest to disable it because it only causes problems. >> >>> > see PR/46426. >> >>> >> >>> I have code that uses it, both in userspace and the kernel, but I >> >>> never checked it in because I ran into a build problem with >> >>> src/common. Let me see what I can do about both issues. >> >> any progress? >> >> if you don't want to remove it, how about renaming it? > >I think this ought to be removed from netbsd-6 (incompatible and there are >no users, nor there is going to be as we are in RC1) and at the very least >disabled in -current. Or just make it compatible and add _s functions that pass the state. Or make it detect NULL state and provide the one on the stack.(Continue reading)
29 Aug 2012 18:30
Re: liblzf incompatibility
Thor Lancelot Simon <tls <at> panix.com>
2012-08-29 16:30:01 GMT
2012-08-29 16:30:01 GMT
On Wed, Aug 29, 2012 at 07:32:02AM +0000, Christos Zoulas wrote: > In article <20120828194151.BB89014A37A <at> mail.netbsd.org>, > Mindaugas Rasiukevicius <rmind <at> netbsd.org> wrote: > >yamt <at> mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: > >> hi, > >> > >> > hi, > >> > > >> >> On Mon, Jun 11, 2012 at 11:45:11PM -0400, Thor Lancelot Simon wrote: > >> >>> On Tue, Jun 12, 2012 at 01:58:12AM +0000, YAMAMOTO Takashi wrote: > >> >>> > hi, > >> >>> > > >> >>> > is there a near-future plan to use liblzf for any in-tree stuff? > >> >>> > otherwise i'd suggest to disable it because it only causes problems. > >> >>> > see PR/46426. > >> >>> > >> >>> I have code that uses it, both in userspace and the kernel, but I > >> >>> never checked it in because I ran into a build problem with > >> >>> src/common. Let me see what I can do about both issues. > >> > >> any progress? > >> > >> if you don't want to remove it, how about renaming it? > > > >I think this ought to be removed from netbsd-6 (incompatible and there are > >no users, nor there is going to be as we are in RC1) and at the very least > >disabled in -current. > > Or just make it compatible and add _s functions that pass the state. Or > make it detect NULL state and provide the one on the stack.(Continue reading)
29 Aug 2012 18:59
Re: liblzf incompatibility
Alan Barrett <apb <at> cequrux.com>
2012-08-29 16:59:46 GMT
2012-08-29 16:59:46 GMT
On Wed, 29 Aug 2012, Christos Zoulas wrote: >>I think this ought to be removed from netbsd-6 (incompatible and there are >>no users, nor there is going to be as we are in RC1) and at the very least >>disabled in -current. > >Or just make it compatible and add _s functions that pass the state. Or >make it detect NULL state and provide the one on the stack. "_r" please, rather than "_s". We already have several _r functions for "reentrant" versions of non-_r functions. The _s suffix has sort of been appropriated by C201x Annex K. --apb (Alan Barrett)
12 Jun 2012 05:54
Re: liblzf incompatibility
Christos Zoulas <christos <at> astron.com>
2012-06-12 03:54:22 GMT
2012-06-12 03:54:22 GMT
In article <20120612015812.348DC14A26D <at> mail.netbsd.org>, YAMAMOTO Takashi <yamt <at> mwd.biglobe.ne.jp> wrote: >hi, > >is there a near-future plan to use liblzf for any in-tree stuff? >otherwise i'd suggest to disable it because it only causes problems. >see PR/46426. > >YAMAMOTO Takashi We could provide a compatible entry point instead... christos
RSS Feed