On Wed, 10 Jun 2020 09:33:04 +0100
Luca Boccassi wrote:
> > It seems there is a communication issue in this thread.
> > Some maintainers look to be against the solution,
> > and you seem frustrated because of a blocked usage issue.
> >
> > Please could you explain what is the initial user proble
On Wed, 2020-06-10 at 10:15 +0200, Thomas Monjalon wrote:
> 09/06/2020 17:37, Dan Gora:
> > On Tue, Jun 2, 2020 at 2:10 AM Dan Gora wrote:
> > > Can these patches be considered again for 20.08?
> > >
> > > I thought that I addressed all of the issues or at least provided
> > > reasonable response
09/06/2020 17:37, Dan Gora:
> On Tue, Jun 2, 2020 at 2:10 AM Dan Gora wrote:
> >
> > Can these patches be considered again for 20.08?
> >
> > I thought that I addressed all of the issues or at least provided
> > reasonable responses to all of the concerns.
>
> So I guess I'll take that as a "no".
04/05/2020 16:13, Dan Gora:
> On Mon, May 4, 2020 at 5:04 AM Mattias Rönnblom
> wrote:
> > The make build is going away completely.
>
> Well it's not going away for at least a year or two
It will be removed in 20.11.
> and that has
> nothing to do with the issues at hand here. And I sure hope
On Tue, Jun 2, 2020 at 2:10 AM Dan Gora wrote:
>
> Can these patches be considered again for 20.08?
>
> I thought that I addressed all of the issues or at least provided
> reasonable responses to all of the concerns.
So I guess I'll take that as a "no"...
I have to admit that I just laughed when
Can these patches be considered again for 20.08?
I thought that I addressed all of the issues or at least provided
reasonable responses to all of the concerns.
thanks
dan
On Mon, May 4, 2020 at 11:19 AM Dan Gora wrote:
>
> On Mon, May 4, 2020 at 11:13 AM Dan Gora wrote:
> >
> > On Mon, May 4,
On Mon, May 4, 2020 at 11:13 AM Dan Gora wrote:
>
> On Mon, May 4, 2020 at 5:04 AM Mattias Rönnblom
> wrote:
>
> > >> so what you are effectively asking is to
> > >> double the size of the support matrix, and for the project to ensure
> > >> that every single dependency can always be built agains
On Mon, May 4, 2020 at 5:04 AM Mattias Rönnblom
wrote:
> >> so what you are effectively asking is to
> >> double the size of the support matrix, and for the project to ensure
> >> that every single dependency can always be built against a new version
> >> and used against an older one.
> > No, th
On 2020-05-01 23:05, Dan Gora wrote:
> On Fri, May 1, 2020 at 1:29 PM Luca Boccassi wrote:
>>> Well, no, because rdseed is used first if available and /dev/urandom
>>> is used next..
>>>
>>> And this is not a corner case at all.. There are lots of linux
>>> distributions which DPDK claims to suppo
On Fri, May 1, 2020 at 1:29 PM Luca Boccassi wrote:
> >
> > Well, no, because rdseed is used first if available and /dev/urandom
> > is used next..
> >
> > And this is not a corner case at all.. There are lots of linux
> > distributions which DPDK claims to support which do not support
> > getentr
On Thu, 2020-04-30 at 17:43 -0300, Dan Gora wrote:
> On Thu, Apr 30, 2020 at 5:29 PM Luca Boccassi wrote:
>
> > > > Adding a new dependecy happens only when building with the new version
> > > > of the library. If it's not available, then there's no new dependency.
> > >
> > > But you also do no
On Thu, Apr 30, 2020 at 5:29 PM Luca Boccassi wrote:
> > > Adding a new dependecy happens only when building with the new version
> > > of the library. If it's not available, then there's no new dependency.
> >
> > But you also do not get to use the new getentropy() if you happen to
> > compile o
On Mon, 2020-04-27 at 13:57 -0300, Dan Gora wrote:
> On Mon, Apr 27, 2020 at 1:19 PM Luca Boccassi wrote:
> > On Thu, 2020-04-23 at 14:38 -0300, Dan Gora wrote:
> > > On Thu, Apr 23, 2020 at 12:59 PM Luca Boccassi wrote:
> > > > > > /dev/urandom is basically only a different interface to the same
On Mon, Apr 27, 2020 at 1:19 PM Luca Boccassi wrote:
>
> On Thu, 2020-04-23 at 14:38 -0300, Dan Gora wrote:
> > On Thu, Apr 23, 2020 at 12:59 PM Luca Boccassi wrote:
> > > > > /dev/urandom is basically only a different interface to the same
> > > > > underlying mechanism.
> > >
> > > This is not
On Thu, 2020-04-23 at 14:38 -0300, Dan Gora wrote:
> On Thu, Apr 23, 2020 at 12:59 PM Luca Boccassi wrote:
> > > > /dev/urandom is basically only a different interface to the same
> > > > underlying mechanism.
> >
> > This is not the whole story though - while the end result when all
> > works is
On Thu, Apr 23, 2020 at 12:59 PM Luca Boccassi wrote:
> > >
> > > /dev/urandom is basically only a different interface to the same
> > > underlying mechanism.
>
> This is not the whole story though - while the end result when all
> works is the same, there are important differences in getting ther
On Thu, Apr 23, 2020 at 9:36 AM Mattias Rönnblom
wrote:
> >>
> >> /dev/urandom is basically only a different interface to the same
> >> underlying mechanism.
> >>
> >> Such an alternative would look something like:
> >>
> >> static int
> >> getentropy(void *buffer, size_t length)
> >> {
> >>
On 2020-04-22 22:35, Dan Gora wrote:
> On Wed, Apr 22, 2020 at 5:14 PM Mattias Rönnblom
> wrote:
>> On 2020-04-22 19:44, Dan Gora wrote:
>>> On Wed, Apr 22, 2020 at 5:28 AM Mattias Rönnblom
>>> wrote:
On 2020-04-21 21:54, Dan Gora wrote:
> The getentropy() function was introduced into gl
On Wed, 2020-04-22 at 17:35 -0300, Dan Gora wrote:
> On Wed, Apr 22, 2020 at 5:14 PM Mattias Rönnblom
> wrote:
> > On 2020-04-22 19:44, Dan Gora wrote:
> > > On Wed, Apr 22, 2020 at 5:28 AM Mattias Rönnblom
> > > wrote:
> > > > On 2020-04-21 21:54, Dan Gora wrote:
> > > > > The getentropy() funct
On Wed, Apr 22, 2020 at 5:14 PM Mattias Rönnblom
wrote:
>
> On 2020-04-22 19:44, Dan Gora wrote:
> > On Wed, Apr 22, 2020 at 5:28 AM Mattias Rönnblom
> > wrote:
> >> On 2020-04-21 21:54, Dan Gora wrote:
> >>> The getentropy() function was introduced into glibc v2.25 and so is
> >>> not available
On 2020-04-22 19:44, Dan Gora wrote:
> On Wed, Apr 22, 2020 at 5:28 AM Mattias Rönnblom
> wrote:
>> On 2020-04-21 21:54, Dan Gora wrote:
>>> The getentropy() function was introduced into glibc v2.25 and so is
>>> not available on all supported platforms. Previously, if DPDK was
>>> compiled (usin
On Wed, Apr 22, 2020 at 5:28 AM Mattias Rönnblom
wrote:
>
> On 2020-04-21 21:54, Dan Gora wrote:
> > The getentropy() function was introduced into glibc v2.25 and so is
> > not available on all supported platforms. Previously, if DPDK was
> > compiled (using meson) on a system which has getentrop
On 2020-04-21 21:54, Dan Gora wrote:
> The getentropy() function was introduced into glibc v2.25 and so is
> not available on all supported platforms. Previously, if DPDK was
> compiled (using meson) on a system which has getentropy(), it would
> introduce a dependency on glibc v2.25 which would p
On Tue, Apr 21, 2020 at 6:03 PM Stephen Hemminger
wrote:
>
> On Tue, 21 Apr 2020 16:54:45 -0300
> Dan Gora wrote:
>
> > The getentropy() function was introduced into glibc v2.25 and so is
> > not available on all supported platforms. Previously, if DPDK was
> > compiled (using meson) on a system
On Tue, 21 Apr 2020 16:54:45 -0300
Dan Gora wrote:
> The getentropy() function was introduced into glibc v2.25 and so is
> not available on all supported platforms. Previously, if DPDK was
> compiled (using meson) on a system which has getentropy(), it would
> introduce a dependency on glibc v2.
The getentropy() function was introduced into glibc v2.25 and so is
not available on all supported platforms. Previously, if DPDK was
compiled (using meson) on a system which has getentropy(), it would
introduce a dependency on glibc v2.25 which would prevent that binary
from running on a system w
26 matches
Mail list logo
