Re: [PATCH 2/2] input: atakbd.c - fix Atari CapsLock behaviour
Hi Michael, On Tue, Sep 18, 2018 at 02:03:29PM +1200, Michael Schmitz wrote: > Thanks Dmitry! > > I had asked Andreas' signoff for his keymap fixes only - the rewrite of the > Atari keyboard driver to the current input framework (and hence the CapsLock > toggle bug) was entirely mine, no blame attaches to Andreas there. It was not about blame, it was about helping me to check the sanity of the patch given I have no idea about the hardware ;) Thanks. -- Dmitry
Attn E-mail Address Owner,
Attn E-mail Address Owner, Website: www.westernunion.com Address: Plot 1261, Adela Hopewell Street CO/B/REP, Republic Of Benin. Email: (westernunionoff...@gmail.com) (+229 66 06 78 33 ) Attention: E-mail Address Owner, Sequel to the meeting held with Federal Bureau of Investigation, The International Monetary Fund (IMF) is compensating all the scam victims and some email users which your name and email address was found on the list. However, we have concluded to effect your own payment through Western Union Money Transfer, $5,000 daily until the total sum of your compensation fund is transferred to you. This is your first payment information: MTCN#: 7307517703 Sender's First Name: Alian Sender's Last Name:Evans Text Question: Code? Answer: ?? Amount Programmed: $5.000 Track your first payment on-line now https://www.westernunion.com/global-service/track-transfer You are advised to get back to the contact person trough the email below for more direction on how to be receiving your payment Contact person: . . SIR. INNOCENT BLESSED Email address: . . (westernunionoff...@gmail.com) Tell phone: . . +229 66 06 78 33 Thanks, SIR.INNOCENT BLESSED Director Western Union Money Transfer, Head Office Benin Republic.
Re: [PATCH 2/4] m68k: Replace NR_syscalls macro from asm/unistd.h
Hi Firoz,
On Tue, Sep 18, 2018 at 9:16 AM Firoz Khan wrote:
> On 9 August 2018 at 13:00, Geert Uytterhoeven wrote:
> > One first comment below...
> >
> > On Thu, Aug 9, 2018 at 7:16 AM Firoz Khan wrote:
> >> NR_syscalls macro holds the number of system call exist in m68k
> >> architecture. This macro is currently the part of asm/unistd.h file.
> >> We have to change the value of NR_syscalls, if we add or delete a
> >> system call.
> >>
> >> One of patch in this patch series has a script which will generate
> >> a uapi header based on syscall.tbl file. The syscall.tbl file
> >> contains the number of system call information. So we have two
> >> option to update NR_syscalls value.
> >>
> >> 1. Update NR_syscalls in asm/unistd.h manually by counting the
> >>no.of system calls. No need to update NR_syscalls untill
> >>we either add a new system call or delete an existing system
> >>call.
> >>
> >> 2. We can keep this feature it above mentioned script, that'll
> >>count the number of syscalls and keep it in a generated file.
> >>In this case we don't need to explicitly update NR_syscalls
> >>in asm/unistd.h file.
> >>
> >> The 2nd option will be the recommended one. For that, I moved the
> >> NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro
> >> name also changed form NR_syscalls to __NR_syscalls for making the
> >> name convention same across all architecture. While __NR_syscalls
> >> isn't strictly part of the uapi, having it as part of the generated
> >> header to simplifies the implementation.
> >
> > It can indeed not be part of the UAPI, as UAPI definitions can never change,
> > while new syscalls will be added in the future, increasing the number ;-)
>
> Thanks for your reply :)
> Sorry for the delayed response :(
>
> I would like to keep __NR_syscalls macro to uapi header in order to simplify
> the system call table generation script. Otherwise the __NR_syscalls
> macro need to update manually. That become a problem.
>
> Please check the below implementation in uapi file make sense?
> It is an easy workaround to leave __NR_syscalls macro in uapi/asm/unistd.h
> and enclose it in #ifdef __KERNEL__
>
> ...
> ...
> #define __NR_pwritev2 378
> #define __NR_statx 379
>
> #ifdef __KERNEL__
> #define __NR_syscalls 380
> #endif
> ...
> ...
#ifdef __KERNEL__ sounds fine to me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/4] m68k: Replace NR_syscalls macro from asm/unistd.h
On 9 August 2018 at 13:00, Geert Uytterhoeven wrote:
> Hi Firoz,
>
> One first comment below...
>
> On Thu, Aug 9, 2018 at 7:16 AM Firoz Khan wrote:
>> NR_syscalls macro holds the number of system call exist in m68k
>> architecture. This macro is currently the part of asm/unistd.h file.
>> We have to change the value of NR_syscalls, if we add or delete a
>> system call.
>>
>> One of patch in this patch series has a script which will generate
>> a uapi header based on syscall.tbl file. The syscall.tbl file
>> contains the number of system call information. So we have two
>> option to update NR_syscalls value.
>>
>> 1. Update NR_syscalls in asm/unistd.h manually by counting the
>>no.of system calls. No need to update NR_syscalls untill
>>we either add a new system call or delete an existing system
>>call.
>>
>> 2. We can keep this feature it above mentioned script, that'll
>>count the number of syscalls and keep it in a generated file.
>>In this case we don't need to explicitly update NR_syscalls
>>in asm/unistd.h file.
>>
>> The 2nd option will be the recommended one. For that, I moved the
>> NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro
>> name also changed form NR_syscalls to __NR_syscalls for making the
>> name convention same across all architecture. While __NR_syscalls
>> isn't strictly part of the uapi, having it as part of the generated
>> header to simplifies the implementation.
>
> It can indeed not be part of the UAPI, as UAPI definitions can never change,
> while new syscalls will be added in the future, increasing the number ;-)
Thanks for your reply :)
Sorry for the delayed response :(
I would like to keep __NR_syscalls macro to uapi header in order to simplify
the system call table generation script. Otherwise the __NR_syscalls
macro need to update manually. That become a problem.
Please check the below implementation in uapi file make sense?
It is an easy workaround to leave __NR_syscalls macro in uapi/asm/unistd.h
and enclose it in #ifdef __KERNEL__
...
...
#define __NR_pwritev2 378
#define __NR_statx 379
#ifdef __KERNEL__
#define __NR_syscalls 380
#endif
...
...
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
