Re: [dpdk-dev] [PATCH v2] eal: abstract away the auxiliary vector

2018-04-24 Thread Thomas Monjalon
11/04/2018 23:34, Thomas Monjalon:
> Anyone to review, please?
> 
> 02/04/2018 20:24, Aaron Conole:
> > Rather than attempting to load the contents of the auxv directly,
> > prefer to use an exposed API - and if that doesn't exist then attempt
> > to load the vector.  This is because on some systems, when a user
> > is downgraded, the /proc/self/auxv file retains the old ownership
> > and permissions.  The original method of /proc/self/auxv is retained.
> > 
> > This also removes a potential abort() in the code when compiled with
> > NDEBUG.  A quick parse of the code shows that many (if not all) of
> > the CPU flag parsing isn't used internally, so it should be okay.
> > 
> > Signed-off-by: Aaron Conole 
> > Signed-off-by: Timothy Redaelli 

3 weeks without a single comment.
Applied with below fix, thanks

fix applied:
-#if RTE_ARCH_64
+#ifdef RTE_ARCH_64





Re: [dpdk-dev] [PATCH v2] eal: abstract away the auxiliary vector

2018-04-11 Thread Thomas Monjalon
Anyone to review, please?

02/04/2018 20:24, Aaron Conole:
> Rather than attempting to load the contents of the auxv directly,
> prefer to use an exposed API - and if that doesn't exist then attempt
> to load the vector.  This is because on some systems, when a user
> is downgraded, the /proc/self/auxv file retains the old ownership
> and permissions.  The original method of /proc/self/auxv is retained.
> 
> This also removes a potential abort() in the code when compiled with
> NDEBUG.  A quick parse of the code shows that many (if not all) of
> the CPU flag parsing isn't used internally, so it should be okay.
> 
> Signed-off-by: Aaron Conole 
> Signed-off-by: Timothy Redaelli