What does the "-DPACKAGE" means?

[Dengke Du]

Hi all

What does the "-DPACKAGE" means?
```
$(OUTPUT)test-libbfd.bin:
    $(BUILD) -DPACKAGE='"perf"' -lbfd -lz -liberty -ldl
```
In this link:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/tree/tools/build/feature/Makefile?id=fb982666e380c1632a74495b68b3c33a66e76430#n189

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Use of enums, why?

[John Whitmore]

I only learning the ropes, and might have missed the memo on the use of enums
so forgive me. I have looked at
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#macros-enums-and-rtl
but that didn't answer my question.

I'm doing a clean up of staging:rtl8192u: clearing out checkpatch errors and
triming out data structures which aren't used in the code. So I came across a
typedef of an enumerated type in the file:

drivers/staging/rtl8192u/r8192U.h

typedef enum rf_optype {
   RF_OP_By_SW_3wire = 0,
   RF_OP_By_FW,
   RF_OP_MAX
} rf_op_type;

A quick grep for this type in drivers/staging/rtl8192u directory shows that
the type is never used outside that header definition. So I can remove it?
Well no you can't because the values defined in the enum are used.

In drivers/staging/rtl8192u/r8192U_core.c for example:
priv->Rf_Mode = RF_OP_By_SW_3wire;

that element priv->Rf_Mode is defined in the structure

typedef struct r8192_priv {
...
u8 Rf_Mode; /* For Firmware RF -R/W switch */
...
}


So now to the question, as I understand it the compiler will use an int type
for the enumerated type. The data structure r8192_priv doesn't use this int type
because the programmer knows that a u8 will do to hold the 3 possible values
defined by the enumerated type.

So you're saving a few bytes in a data structure, which I'm happy about, but
the point of enumerated types is, as I understand it, so that the compiler can
do some checking to ensure a value is not assigned in error. Since the enum
isn't being used, there is no compiler type checking, so why use an enumerated 
type?
Might as well have used three #define values.

The obvious thing to do is leave well enough alone. But I had to ask what is
the correct implementation? Use the enum in the data structure, instead of
u8? Or just #define a few constants?

#define   RF_OP_By_SW_3wire1
#define   RF_OP_By_FW  2
#define   RF_OP_MAX3

Given the space saving of u8 over int I'd probably go with the #define. Guess
it depends on how many of those data structures are being declared.

thanks for any thoughts or clarification

John

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Use of enums, why?

[Greg KH]

On Wed, Jul 11, 2018 at 10:30:28AM +0100, John Whitmore wrote:
> I only learning the ropes, and might have missed the memo on the use of enums
> so forgive me. I have looked at
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html#macros-enums-and-rtl
> but that didn't answer my question.
> 
> I'm doing a clean up of staging:rtl8192u: clearing out checkpatch errors and
> triming out data structures which aren't used in the code. So I came across a
> typedef of an enumerated type in the file:
> 
> drivers/staging/rtl8192u/r8192U.h
> 
> typedef enum rf_optype {
>RF_OP_By_SW_3wire = 0,
>RF_OP_By_FW,
>RF_OP_MAX
> } rf_op_type;

To fix this up for checkpatch, it should just look like:

enum rf_optype {
RF_OP_By_SW_3wire = 0,
RF_OP_By_FW,
RF_OP_MAX
};

> A quick grep for this type in drivers/staging/rtl8192u directory shows that
> the type is never used outside that header definition. So I can remove it?

As you found out, no :)

> Well no you can't because the values defined in the enum are used.
> 
> In drivers/staging/rtl8192u/r8192U_core.c for example:
> priv->Rf_Mode = RF_OP_By_SW_3wire;
> 
> that element priv->Rf_Mode is defined in the structure
> 
> typedef struct r8192_priv {
> ...
>   u8 Rf_Mode; /* For Firmware RF -R/W switch */

Ah, that should be:
enum rf_optype RF_Mode;
right?

> ...
> }
> 
> 
> So now to the question, as I understand it the compiler will use an int type
> for the enumerated type. The data structure r8192_priv doesn't use this int 
> type
> because the programmer knows that a u8 will do to hold the 3 possible values
> defined by the enumerated type.

Or someone messed up and didn't realize that is what was holding those
values :)

> So you're saving a few bytes in a data structure, which I'm happy about, but
> the point of enumerated types is, as I understand it, so that the compiler can
> do some checking to ensure a value is not assigned in error.

You are correct.

> Since the enum isn't being used, there is no compiler type checking,
> so why use an enumerated type?  Might as well have used three #define
> values.

That too would work, but you loose the typechecking.

> The obvious thing to do is leave well enough alone. But I had to ask what is
> the correct implementation? Use the enum in the data structure, instead of
> u8? Or just #define a few constants?
> 
> #define   RF_OP_By_SW_3wire1
> #define   RF_OP_By_FW  2
> #define   RF_OP_MAX3
> 
> Given the space saving of u8 over int I'd probably go with the #define. Guess
> it depends on how many of those data structures are being declared.

I'd stick to the define, UNLESS this structure is coming from/to the
hardware directly.  Then you need to use u8.  So look and see if that is
what is happening here or not.   If it's just a "normal" structure in
memory, then use an enum to keep the type safety.

hope this helps,

greg k-h

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: What does the "-DPACKAGE" means?

[loïc tourlonias]

Hi

On Wed, Jul 11, 2018 at 10:08 AM, Dengke Du  wrote:
>
> Hi all
>
> What does the "-DPACKAGE" means?
> ```
> $(OUTPUT)test-libbfd.bin:
> $(BUILD) -DPACKAGE='"perf"' -lbfd -lz -liberty -ldl
> ```
> In this link:
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/tree/tools/build/feature/Makefile?id=fb982666e380c1632a74495b68b3c33a66e76430#n189

If you look at the manpage of gcc, the -D option is used to define
macro. It creates new #define during build.

HTH
Loïc
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Use of enums, why?

[John Whitmore]

On Wed, Jul 11, 2018 at 11:40:18AM +0200, Greg KH wrote:
> On Wed, Jul 11, 2018 at 10:30:28AM +0100, John Whitmore wrote:
> > I only learning the ropes, and might have missed the memo on the use of 
> > enums
> > so forgive me. I have looked at
> > https://www.kernel.org/doc/html/v4.10/process/coding-style.html#macros-enums-and-rtl
> > but that didn't answer my question.
> > 
> > I'm doing a clean up of staging:rtl8192u: clearing out checkpatch errors and
> > triming out data structures which aren't used in the code. So I came across 
> > a
> > typedef of an enumerated type in the file:
> > 
> > drivers/staging/rtl8192u/r8192U.h
> > 
> > typedef enum rf_optype {
> >RF_OP_By_SW_3wire = 0,
> >RF_OP_By_FW,
> >RF_OP_MAX
> > } rf_op_type;
> 
> To fix this up for checkpatch, it should just look like:
> 
> enum rf_optype {
>   RF_OP_By_SW_3wire = 0,
>   RF_OP_By_FW,
>   RF_OP_MAX
> };
> 
> > A quick grep for this type in drivers/staging/rtl8192u directory shows that
> > the type is never used outside that header definition. So I can remove it?
> 
> As you found out, no :)
> 
> > Well no you can't because the values defined in the enum are used.
> > 
> > In drivers/staging/rtl8192u/r8192U_core.c for example:
> > priv->Rf_Mode = RF_OP_By_SW_3wire;
> > 
> > that element priv->Rf_Mode is defined in the structure
> > 
> > typedef struct r8192_priv {
> > ...
> > u8 Rf_Mode; /* For Firmware RF -R/W switch */
> 
> Ah, that should be:
>   enum rf_optype RF_Mode;
> right?
> 
> > ...
> > }
> > 
> > 
> > So now to the question, as I understand it the compiler will use an int type
> > for the enumerated type. The data structure r8192_priv doesn't use this int 
> > type
> > because the programmer knows that a u8 will do to hold the 3 possible values
> > defined by the enumerated type.
> 
> Or someone messed up and didn't realize that is what was holding those
> values :)
> 
> > So you're saving a few bytes in a data structure, which I'm happy about, but
> > the point of enumerated types is, as I understand it, so that the compiler 
> > can
> > do some checking to ensure a value is not assigned in error.
> 
> You are correct.
> 
> > Since the enum isn't being used, there is no compiler type checking,
> > so why use an enumerated type?  Might as well have used three #define
> > values.
> 
> That too would work, but you loose the typechecking.
> 
> > The obvious thing to do is leave well enough alone. But I had to ask what is
> > the correct implementation? Use the enum in the data structure, instead of
> > u8? Or just #define a few constants?
> > 
> > #define   RF_OP_By_SW_3wire1
> > #define   RF_OP_By_FW  2
> > #define   RF_OP_MAX3
> > 
> > Given the space saving of u8 over int I'd probably go with the #define. 
> > Guess
> > it depends on how many of those data structures are being declared.
> 
> I'd stick to the define, UNLESS this structure is coming from/to the
> hardware directly.  Then you need to use u8.  So look and see if that is
> what is happening here or not.   If it's just a "normal" structure in
> memory, then use an enum to keep the type safety.
> 
> hope this helps,
> 
> greg k-h

Yes that clears that up.

Thanks a million

John

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Regarding Signing Linux kernel with Microsoft secure boot keys for UEFI

[Ewan Marshall]

On 08/07/2018 06:51, inventsekar wrote:

Thx for the reply...
I got it... Its not a youtube video i was refering...
I was asking about this...

https://arstechnica.com/information-technology/2013/02/linus-torvalds-i-will-not-change-linux-to-deep-throat-microsoft/

I read this page few times but I am unable to understand what's Linus's 
idea..Why he disagree ...
whether the Linux kernel should include code that makes it easier to 
boot Linux on Windows PCs. This goes back to Microsoft requiring 
 that 
PCs designed to run Windows 8 use UEFI firmware with the Secure Boot 
feature enabled


On Sun 8 Jul, 2018, 11:16 AM Jeffrey Walton, > wrote:


On Sun, Jul 8, 2018 at 1:17 AM, inventsekar mailto:inventse...@gmail.com>> wrote:
 > ...
 > I am not sure if its a bad question... (i thought for few days
about "can i
 > ask this or not")
 >
 > If its a bad question, please accept la apologizes.. if admins
wishes, this
 > three email can/should be deleted.

My guess is, no one bothered watching the youtube video. But it is
just speculation on my part.

Maybe you can list the items you would like explained.

Jeff


There are major security issues with the trust of the embedded key, if 
the private key part of that key gets compromised, there is no coming 
back. Also, why should Canonical trust Redhat's key, or Novell (SUSE), 
maybe the debian devs. It is a very very bad idea to have a PE binary 
which contains a redhat public key that is microsoft signed. This 
request is suggesting embedding 2 proprietary things into the Linux 
Kernel just so microsoft can control the x86 market.


Ewan


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] vsprintf: fix build warning

[Sergey Senozhatsky]

On (07/10/18 09:42), Tobin C. Harding wrote:
> > I prefer not to do squashes unless absolutely necessary. Yes, it is in
> > next, but even branches pulled into next should try to resist rebasing
> > (I never rebase my next branch unless there is a real bug that will
> > break bisecting).
> 
> Steve if you do not rebase your next branch and the branch ends up
> containing fixes to patches like the above doesn't this mean that when
> you do a pull request to Linus the branch you are asking to be pulled
> will be too 'dirty' i.e. I thought that the pull request should be like
> a patch set and only contain the 'final product' not every change that
> was made during development?

+1

-ss

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: What does the "-DPACKAGE" means?

[Dengke Du]

On 2018年07月11日 19:23, loïc tourlonias wrote:

Hi

On Wed, Jul 11, 2018 at 10:08 AM, Dengke Du  wrote:

Hi all

What does the "-DPACKAGE" means?
```
$(OUTPUT)test-libbfd.bin:
 $(BUILD) -DPACKAGE='"perf"' -lbfd -lz -liberty -ldl
```
In this link:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/tree/tools/build/feature/Makefile?id=fb982666e380c1632a74495b68b3c33a66e76430#n189

If you look at the manpage of gcc, the -D option is used to define
macro. It creates new #define during build.

HTH
Loïc


Thanks, that's what I want.


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Question about memcpy

[bing zhu]

agree! a simple rename would survice.results are the same .kernel is faster
could anyone help fix this ?

2018-07-11 0:03 GMT+08:00 :

> On Tue, 10 Jul 2018 22:51:34 +0800, bing zhu said:
>
> > Thank you ,I use this func for both kernel and user ,result are same.
> > void *memcpy(void *dest, const void *src, size_t n)
> > {
>
> Might want to use 'void *my_memcpy(..)' instead, just in case the build
> environment plays #define games with you and causes a different memcpy()
> to get invoked instead.
>
> [/usr/src/linux-next] egrep -r '#define\s*memcpy\(' include/ arch/*/include
> arch/arm64/include/asm/string.h:#define memcpy(dst, src, len)
> __memcpy(dst, src, len)
> arch/m68k/include/asm/string.h:#define memcpy(d, s, n)
> __builtin_memcpy(d, s, n)
> arch/sparc/include/asm/string.h:#define memcpy(t, f, n)
> __builtin_memcpy(t, f, n)
> arch/x86/include/asm/string_64.h:#define memcpy(dst, src, len)
>   \
> arch/x86/include/asm/string_64.h:#define memcpy(dst, src, len)
> __memcpy(dst, src, len)
> arch/x86/include/asm/string_32.h:#define memcpy(t, f, n)
>   \
> arch/x86/include/asm/string_32.h:#define memcpy(t, f, n)
> __builtin_memcpy(t, f, n)
> arch/x86/include/asm/string_32.h:#define memcpy(t, f, n)
>   \
> arch/xtensa/include/asm/string.h:#define memcpy(dst, src, len)
> __memcpy(dst, src, len)
>
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Question about memcpy

[Greg KH]

On Thu, Jul 12, 2018 at 12:47:12PM +0800, bing zhu wrote:
> agree! a simple rename would survice.results are the same .kernel is faster
> could anyone help fix this ?

Fix what exactly?

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies