Re: [PATCH net-next] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)

-l 45 > $ grep "= {0};" kernel/ -nr | wc -l > 4 $ egrep -nr "=[[:space:]]*{[[:space:]]*0[[:space:]]*};" kernel | wc -l 8 MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at There is NO CLOUD, just other people's computers. - FSFE LUGA : http://www.luga.at

Re: linux-kernel janitorial RFP: Mark static arrays as const

{ > > For drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, > 16, 8, 4, 2, 1 }; Looking at the examples: Just s/^static /static const / in the lines reported by the grep's above and see if it compiles (and save space)? MfG, Bernd --

Re: Old platforms: bring out your dead

roduction - with boards (though they tend to loose features like "memory-mapping over the ISA-bus"). One is a - according to /proc/cpuinfo - a "Intel(R) Atom(TM) CPU E3825 @ 1.33GHz". Sry, I cannot get the product name. MfG, BErnd -- Bernd Petro

Re: Toolchain-dependent config options

ere that pull all necessary in? > Introducing the build breakage is annoying. Yes, update/install the necessary package to fix it. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at There is no cloud, just other people computers. - FSFE LUGA : http://www.luga.at

Re: in_compat_syscall() on x86

to https://wiki.debian.org/X32Port ? [...] MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at There is no cloud, just other people computers. - FSFE LUGA : http://www.luga.at

Re: Linux 5.11-rc1

On Sat, 2021-01-02 at 12:26 +0100, Sedat Dilek wrote: > On Sat, Jan 2, 2021 at 12:05 PM Bernd Petrovitsch > wrote: > > On Sat, 2021-01-02 at 10:13 +0100, Sedat Dilek wrote: > > [...] > > > To be honest I wondered why there were no more reports on this. > > >

Re: Linux 5.11-rc1

ot;fixes" the $PATH). MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at There is no cloud, just other people computers. - FSFE LUGA : http://www.luga.at

Re: linux.git is broken on a case-insensitive filesystem

d regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at There is no cloud, just other people computers. - FSFE LUGA : http://www.luga.at

Re: SIGHUP on connect

d?). close() on a socket calls shutdown() automatically (unless the shutdown() has been already called). The timeout which you're application runs into applies after shutting down/closing the connection. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.

Re: SIGHUP on connect

Hi all! On 25/10/2020 16:11, Michael J. Baars wrote: [...] > I've been writing a simple client and server for cluster computing this > weekend. At first everything appeared to work just fine, but soon enough I > found some > inexplicable bind errors. I've tried to make sure that the client

Re: [PATCH v2 2/2] kbuild: use interpreters to invoke scripts

Hi all! On 12/10/2020 18:42, Ujjwal Kumar wrote: > On 12/10/20 11:50 pm, Lukas Bulwahn wrote: >> >> >> On Mon, 12 Oct 2020, Ujjwal Kumar wrote: >> >>> We cannot rely on execute bits to be set on files in the repository. >>> The build script should use the explicit interpreter when invoking any

Re: Scheduler benchmarks

On 19/08/2020 10:16, Muni Sekhar wrote: > On Tue, Aug 18, 2020 at 11:45 PM peter enderborg > wrote: [...] >> On the 4.4 kernel you dont have >> >> +CONFIG_RETPOLINE=y >> +CONFIG_INTEL_RDT=y > Thanks! That is helpful. Yes, I see 4.4 kernel don't have the above > two config options. > What analysis

Re: [PATCH] Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang

>> if the compiler supports that notation >> > > That patch as it stands will work with D64838, as it is adding support > for the GNU fallthrough attribute. > > However, I assume that all of the /* fall through */ comments will need > to be converted to the attrib

Re: kbuild: Fail if gold linker is detected

Hi all! On 16/07/2019 17:59, Thomas Gleixner wrote: [...] > No. It fails randomly, but also predictable. Enable X32 support on 64bit > and it fails the VDSO build. That's been the case for years. FWIW "GNU gold (GNU Binutils for Ubuntu 2.30) 1.15" segfaults for userspace x32 binaries now and

Re: build error

Hi all! On 28/07/2019 22:08, Matteo Croce wrote: [...] > I get this build error with 5.3-rc2" > > # make > arch/arm64/Makefile:58: gcc not found, check CROSS_COMPILE_COMPAT. Stop. - Install (some) gcc?! - Fix $PATH so that (some) gcc can be found?! MfG, Bernd --

Re: [PATCH v2] kbuild: check uniqueness of module names

On 17/05/2019 11:25, Alexander Kapshuk wrote: > On Fri, May 17, 2019 at 11:58 AM Bernd Petrovitsch > wrote: >> >> On 17/05/2019 10:16, Alexander Kapshuk wrote: >> [...] >>> The 'xargs' '-r' flag is a GNU extension. >>> If POSIX compliance i

Re: [PATCH v2] kbuild: check uniqueness of module names

ed '/\/'$m'/!d;s:^kernel/: :' modules.order modules.builtin sed "/\/${m}/!d;s/^kernel\// /" modules.order modules.builtin MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

On 08/01/2019 12:37, Jiri Kosina wrote: > On Tue, 8 Jan 2019, Bernd Petrovitsch wrote: > >> Shouldn't the application use e.g. mlock()/ to guarantee no page >> faults in the first place? > > Calling mincore() on pages you've just mlock()ed is sort of pointle

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

y to do some kind of prefaulting, > possibly in a loop. There might be somebody trying to make sure something is > out Isn't that racy by design as the pages may get flushed out after the check? Shouldn't the application use e.g. mlock()/ to guarantee no page faults in the first place? Mf

Re: Why is no one discussing this anymore?

...] > > Are you idiots aware that I am a lawyer[...] > > Are you idiots [...] Interesting "qualities" of communication are apparently in order for (alleged) lawyers in your part of the world. MfG, Bernd PS: Sry for feeding the troll- won't happen anymore, it'

Re: Can we drop upstream Linux x32 support?

On 14/12/2018 17:17, Rich Felker wrote: > On Fri, Dec 14, 2018 at 03:13:10PM +0100, Bernd Petrovitsch wrote: [..] >> FWIW I have >> snip >> #if defined __x86_64__ >> # if defined __ILP32__ // x32 >> # define PRI_time_t "lld"

Re: Can we drop upstream Linux x32 support?

On 13/12/2018 17:02, Rich Felker wrote: > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote: >> I can't say anything about the syscall interface. However, what I do know >> is that the weird combination of a 32-bit userland with a 64-bit kernel >> interface is sometimes

Re: Cleaning up numbering for new x86 syscalls?

ware/systems out there that uses 64bit CPUs (for whatever reason - if only that one can't get a 32bit CPU for that board) but will never ever need more than 2-3 GB RAM . MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: Cleaning up numbering for new x86 syscalls?

ware/systems out there that uses 64bit CPUs (for whatever reason - if only that one can't get a 32bit CPU for that board) but will never ever need more than 2-3 GB RAM . MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: Code of Conduct: Let's revamp it.

e found in lots of publicly accessible git repos can be not intended to be published? I wonder what else must happen. > public -- it is intended for those who code or wish to. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at pEpkey.asc Description: application/pgp-keys

Re: Code of Conduct: Let's revamp it.

e found in lots of publicly accessible git repos can be not intended to be published? I wonder what else must happen. > public -- it is intended for those who code or wish to. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at pEpkey.asc Description: application/pgp-keys

Re: Code of Conduct: Let's revamp it.

ying you (and the rest is usually not enough to get anything revoked). I don't see why that should be any different with GPLv2 patches for the Kernel sent to public mailinglists with the intent of inclusion. Please get back to the issue and circumstances at hand and do not try to divert people w

Re: Code of Conduct: Let's revamp it.

ying you (and the rest is usually not enough to get anything revoked). I don't see why that should be any different with GPLv2 patches for the Kernel sent to public mailinglists with the intent of inclusion. Please get back to the issue and circumstances at hand and do not try to divert people w

Re: Code of Conduct: Let's revamp it.

ress. IMHO you cannot "publish" already published stuff. MfG, Bernd, NAL -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at pEpkey.asc Description: application/pgp-keys

Re: Code of Conduct: Let's revamp it.

ress. IMHO you cannot "publish" already published stuff. MfG, Bernd, NAL -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at pEpkey.asc Description: application/pgp-keys

Re: Kernel-only deployments?

web interface and a SNMP agent (hacked net-smtp as we had our own configuration daemon and needed SNMP only as a transport protocol). [...] MfG, Bernd [0]: Every byte counts and size does matter;-) -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: Kernel-only deployments?

web interface and a SNMP agent (hacked net-smtp as we had our own configuration daemon and needed SNMP only as a transport protocol). [...] MfG, Bernd [0]: Every byte counts and size does matter;-) -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

gt; warning > > makes sense in general as explained in mannual. Thanks! > > The destination should be a null terminated string eventually, but we first > need > to make sure src is a null terminated string. Is there strnlen() or memchr() in the kernel? Then check the source before copyi

Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

gt; warning > > makes sense in general as explained in mannual. Thanks! > > The destination should be a null terminated string eventually, but we first > need > to make sure src is a null terminated string. Is there strnlen() or memchr() in the kernel? Then check the source before copyi

Re: Suggested new user link command

aps it is more acceptable/useful if there is a mount option which must be activated on the backup filesystems and that is not activated anywhere else. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: Suggested new user link command

aps it is more acceptable/useful if there is a mount option which must be activated on the backup filesystems and that is not activated anywhere else. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: Suggested new user link command

efficient. That's the price for security as it requires proper permissions. Or is this a root-only syscall? MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: Suggested new user link command

efficient. That's the price for security as it requires proper permissions. Or is this a root-only syscall? MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: LKML admins (syzbot emails are not delivered)

just wondering if it wouldn't be even more safe to use text/plain (instead of application/octet-stream) as the default MIME type if one wants to avoid to be misused to send viruses etc. MfG, Bernd PS: Sry, for somewhat semi-off-topic -- Bernd Petrovitsch Email : be...@petr

Re: LKML admins (syzbot emails are not delivered)

just wondering if it wouldn't be even more safe to use text/plain (instead of application/octet-stream) as the default MIME type if one wants to avoid to be misused to send viruses etc. MfG, Bernd PS: Sry, for somewhat semi-off-topic -- Bernd Petrovitsch Email : be...@petr

Re: [PATCH 2/2] staging: media: atomisp2: Replace kfree()/vfree() with kvfree()

/* Why not get rid of the trivial wrapper function completely? MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: [PATCH 2/2] staging: media: atomisp2: Replace kfree()/vfree() with kvfree()

/* Why not get rid of the trivial wrapper function completely? MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings

en your driver prints "blah: foo bar error 49", > just run a little program that converts 49 to . Userspace can just guess if a given "49" is an errno or not ... MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings

en your driver prints "blah: foo bar error 49", > just run a little program that converts 49 to . Userspace can just guess if a given "49" is an errno or not ... MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: WMI and Kernel:User interface

practically the rights to be able to do everything. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: WMI and Kernel:User interface

practically the rights to be able to do everything. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: [PATCH] CodingStyle: delete "kmalloc(sizeof(*var))" as preferred allocation form

), GFP_KERNEL); doesn't do and the compiler doesn't complain. And the typeof() version could be written that way today but I can't remember seeing it (in the kernel and elsewhere). MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: [PATCH] CodingStyle: delete "kmalloc(sizeof(*var))" as preferred allocation form

), GFP_KERNEL); doesn't do and the compiler doesn't complain. And the typeof() version could be written that way today but I can't remember seeing it (in the kernel and elsewhere). MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: KVM: Fine-tuning for several function implementations

code settings. Which is not explained here. > Would others like to help in approaches for checking corresponding > run time changes a bit more? You propose the patch and others should do the work to get it accepted? Kind regards, Bernd -- Bernd Petrovitsch Email

Re: KVM: Fine-tuning for several function implementations

code settings. Which is not explained here. > Would others like to help in approaches for checking corresponding > run time changes a bit more? You propose the patch and others should do the work to get it accepted? Kind regards, Bernd -- Bernd Petrovitsch Email

Re: MD-RAID: Use seq_putc() in three status functions?

t anyone can *easily* follow it to check and reproduce the results - especially if you want people with knowledge of other architectures to comment (otherwise they probably won't bother). Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: MD-RAID: Use seq_putc() in three status functions?

t anyone can *easily* follow it to check and reproduce the results - especially if you want people with knowledge of other architectures to comment (otherwise they probably won't bother). Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: [PATCH 37/54] md/raid5: Replace a seq_printf() call by seq_puts() in raid5_status()

ctly? > > > > Why don't _you_ try to implement that in checkpatch instead? > > How are the chances that any other software developer would be > quicker (than me) for such > an addition because of more practical knowledge for the programming > language "Perl"

Re: [PATCH 37/54] md/raid5: Replace a seq_printf() call by seq_puts() in raid5_status()

ctly? > > > > Why don't _you_ try to implement that in checkpatch instead? > > How are the chances that any other software developer would be > quicker (than me) for such > an addition because of more practical knowledge for the programming > language "Perl"

Re: [PATCH] mfd: arizona: Remove pointless switch case

Hi all! On Fri, 2016-07-22 at 16:58 +0100, Charles Keepax wrote: [...] >   case IRQF_TRIGGER_RISING: >   case IRQF_TRIGGER_FALLING: >   break; > - > - case IRQ_TYPE_NONE: >   default: Don't know about the kernels coding rule in

Re: [PATCH] mfd: arizona: Remove pointless switch case

Hi all! On Fri, 2016-07-22 at 16:58 +0100, Charles Keepax wrote: [...] >   case IRQF_TRIGGER_RISING: >   case IRQF_TRIGGER_FALLING: >   break; > - > - case IRQ_TYPE_NONE: >   default: Don't know about the kernels coding rule in

Re: script relative shebang

user" friendly. User-friendlyness is not the job of the kernel ... [ Fullquote deleted as it's a bad habit ] MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: script relative shebang

user" friendly. User-friendlyness is not the job of the kernel ... [ Fullquote deleted as it's a bad habit ] MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at

Re: [PATCH v7 2/4] x86/stackvalidate: Compile-time stack validation

On Mon, 2015-07-20 at 12:50 -0500, Josh Poimboeuf wrote: [...] > It's perhaps distasteful, but it improves performance. And I'm a > pragmatist at heart ;-) And you measured the time gain guaranteeing that it actually saves that much time. Usually that isn't actually measurable And the

Re: [PATCH v7 2/4] x86/stackvalidate: Compile-time stack validation

On Mon, 2015-07-20 at 12:50 -0500, Josh Poimboeuf wrote: [...] It's perhaps distasteful, but it improves performance. And I'm a pragmatist at heart ;-) And you measured the time gain guaranteeing that it actually saves that much time. Usually that isn't actually measurable And the usual

Re: get_maintainers.pl is rude, was Re: [PATCH 05/19] USB: inode.c: move assignment out of if () block

On Don, 2015-04-30 at 14:54 +0200, Christoph Hellwig wrote: > On Thu, Apr 30, 2015 at 02:40:04PM +0200, Greg Kroah-Hartman wrote: > > scripts/get_maintainer.pl is bringing up your name for this file as you > > have modified it in the past: > > I've probably modified a large part of files in the

Re: get_maintainers.pl is rude, was Re: [PATCH 05/19] USB: inode.c: move assignment out of if () block

On Don, 2015-04-30 at 14:54 +0200, Christoph Hellwig wrote: On Thu, Apr 30, 2015 at 02:40:04PM +0200, Greg Kroah-Hartman wrote: scripts/get_maintainer.pl is bringing up your name for this file as you have modified it in the past: I've probably modified a large part of files in the kernel

Re: [GIT PULL] kdbus for 4.1-rc1

Hi all! On Die, 2015-04-21 at 09:37 -0400, Havoc Pennington wrote: [...] > This has long been sort of the 'party line' and I've told many people > this on the dbus mailing list over the years (almost exactly what you > just said - that for performance-critical cases they should open a > direct

Re: [GIT PULL] kdbus for 4.1-rc1

Hi all! On Die, 2015-04-21 at 09:37 -0400, Havoc Pennington wrote: [...] This has long been sort of the 'party line' and I've told many people this on the dbus mailing list over the years (almost exactly what you just said - that for performance-critical cases they should open a direct socket

Re: [PATCH] x86,boot: standardize strcmp()

On Don, 2015-03-19 at 10:34 -0700, H. Peter Anvin wrote: > On 03/17/2015 07:13 AM, Arjun Sreedharan wrote: > > On a related note, IMO strcmp() should return {-1,0,1} since many > > programmers just expect this behavior. just my opinion. One doesn't change an API just for a claimed expection for

Re: [PATCH] x86,boot: standardize strcmp()

On Don, 2015-03-19 at 10:34 -0700, H. Peter Anvin wrote: On 03/17/2015 07:13 AM, Arjun Sreedharan wrote: On a related note, IMO strcmp() should return {-1,0,1} since many programmers just expect this behavior. just my opinion. One doesn't change an API just for a claimed expection for an

Re: [PATCH] x86,boot: standardize strcmp()

On Die, 2015-03-17 at 19:43 +0530, Arjun Sreedharan wrote: [...] > On a related note, IMO strcmp() should return {-1,0,1} since many > programmers just expect this behavior. just my opinion. -ENOPATCH. MfG, Bernd -- "I dislike type abstraction if it has no real reason. And saving on

Re: [PATCH] x86,boot: standardize strcmp()

On Die, 2015-03-17 at 19:43 +0530, Arjun Sreedharan wrote: [...] On a related note, IMO strcmp() should return {-1,0,1} since many programmers just expect this behavior. just my opinion. -ENOPATCH. MfG, Bernd -- I dislike type abstraction if it has no real reason. And saving on typing

Re: Why do we still have 32 bit counters? Interrupt counters overflow within 50 days

On Fre, 2014-10-03 at 07:23 -0500, Christoph Lameter wrote: > On Fri, 3 Oct 2014, Paul Bolle wrote: > > > dc -e "1 k 2 32 ^ 1000 / 86400 / p" > > 49.7 > > > > (That was the number I remembered from stories about a ancient Windows > > lockup.) > > Well yes, I used bc which discards the remainder

Re: Why do we still have 32 bit counters? Interrupt counters overflow within 50 days

On Fre, 2014-10-03 at 07:23 -0500, Christoph Lameter wrote: On Fri, 3 Oct 2014, Paul Bolle wrote: dc -e 1 k 2 32 ^ 1000 / 86400 / p 49.7 (That was the number I remembered from stories about a ancient Windows lockup.) Well yes, I used bc which discards the remainder on integer

Re: [PATCH -v4] random: introduce getrandom(2) system call

On Don, 2014-07-31 at 00:18 +0200, Pavel Machek wrote: > On Wed 2014-07-30 16:40:52, Bernd Petrovitsch wrote: > > On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote: > > > Pavel. I have bit 'ol enterprise daemon running with established file > > > descriptors servi

Re: [PATCH -v4] random: introduce getrandom(2) system call

On Don, 2014-07-31 at 00:18 +0200, Pavel Machek wrote: On Wed 2014-07-30 16:40:52, Bernd Petrovitsch wrote: On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote: Pavel. I have bit 'ol enterprise daemon running with established file descriptors serving thousands of connections which

Re: [PATCH -v4] random: introduce getrandom(2) system call

On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote: > Pavel. I have bit 'ol enterprise daemon running with established file > descriptors serving thousands of connections > which periodically require entropy. Now I run out of descriptors. I > can't establish new connections. but I should > now

Re: [PATCH -v4] random: introduce getrandom(2) system call

On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote: Pavel. I have bit 'ol enterprise daemon running with established file descriptors serving thousands of connections which periodically require entropy. Now I run out of descriptors. I can't establish new connections. but I should now halt all

Re: [PATCH] drivers/staging/comedi/drivers/ni_atmio16d.c: remove pointless condition

Hi! On Fre, 2014-07-11 at 15:30 +0300, Andrey Utkin wrote: [...] > Could you please substantiate this? I see that convert_arg has type > "unsigned int" which may be 8 bytes on 64-bit platform. I haven't At least in the x86_64 world, "unsigned int" has 32bit. TTBOMK, it is similar on all other

Re: [PATCH] drivers/staging/comedi/drivers/ni_atmio16d.c: remove pointless condition

Hi! On Fre, 2014-07-11 at 15:30 +0300, Andrey Utkin wrote: [...] Could you please substantiate this? I see that convert_arg has type unsigned int which may be 8 bytes on 64-bit platform. I haven't At least in the x86_64 world, unsigned int has 32bit. TTBOMK, it is similar on all other 64bit -

Re: Fwd: linux-next: Tree for Jul 9

Hi! On Mit, 2014-07-09 at 16:54 -0400, Nick Krause wrote: [... useless quotes deleted ...] > Thanks for the help. Hope this message is better makes sense to me. And always quoting everything is bad mail style too - just quote just the relevant parts for the answer, not more, not less. Everyone

Re: Fwd: linux-next: Tree for Jul 9

Hi! On Mit, 2014-07-09 at 16:54 -0400, Nick Krause wrote: [... useless quotes deleted ...] Thanks for the help. Hope this message is better makes sense to me. And always quoting everything is bad mail style too - just quote just the relevant parts for the answer, not more, not less. Everyone

Re: [PATCH] sched/deadline: overrun could happen in start_hrtick_dl

On Die, 2014-07-08 at 11:33 +0200, Peter Zijlstra wrote: [...] > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index fc4f98b1258f..e1e24eea8061 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -999,8 +999,7 @@ static void start_hrtick_dl(struct rq *rq,

Re: [PATCH] sched/deadline: overrun could happen in start_hrtick_dl

On Die, 2014-07-08 at 11:33 +0200, Peter Zijlstra wrote: [...] diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index fc4f98b1258f..e1e24eea8061 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -999,8 +999,7 @@ static void start_hrtick_dl(struct rq *rq,

Re: [PATCH] Coccicheck: Remove memcpy to struct assignment test

Hi! On Mit, 2014-03-19 at 14:39 +0100, Peter Senna Tschudin wrote: > On Wed, Mar 19, 2014 at 1:02 PM, Bernd Petrovitsch > wrote: > > On Die, 2014-03-18 at 22:11 +0100, Peter Senna Tschudin wrote: > >> The Coccinelle script scripts/coccinelle/misc/memcpy-assign.cocci look &

Re: [PATCH] Coccicheck: Remove memcpy to struct assignment test

nvention has an impact on the generated code. Using struct assignment keeps the type check and is just for this reason always preferable over memcpy(). Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http:/

Re: [PATCH] Coccicheck: Remove memcpy to struct assignment test

an impact on the generated code. Using struct assignment keeps the type check and is just for this reason always preferable over memcpy(). Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe

Re: [PATCH] Coccicheck: Remove memcpy to struct assignment test

Hi! On Mit, 2014-03-19 at 14:39 +0100, Peter Senna Tschudin wrote: On Wed, Mar 19, 2014 at 1:02 PM, Bernd Petrovitsch be...@petrovitsch.priv.at wrote: On Die, 2014-03-18 at 22:11 +0100, Peter Senna Tschudin wrote: The Coccinelle script scripts/coccinelle/misc/memcpy-assign.cocci look

Re: [PATCH 1/2] tpm/tpm_ppi: Do not compare strcmp(a,b) == -1

rcmp.html but also (glibcs) manual page- doesn't guarantee -1 or +1 either, MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send the line "unsubscribe linux-kerne

Re: [PATCH 1/2] tpm/tpm_ppi: Do not compare strcmp(a,b) == -1

but also (glibcs) manual page- doesn't guarantee -1 or +1 either, MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: checkpatch.pl "uninitialized value"

that (or whatever you did to get it), people are more likely to look into it. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: checkpatch.pl uninitialized value

to look into it. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info

Re: [RFC GIT PULL] "Nuke 386-DX/SX support" changes for v3.8

avascript at http://www.bellard.org/jslinux/. http://www.bellard.org/jslinux/tech.html says that it (also) lacks an FPU. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send

Re: [RFC GIT PULL] Nuke 386-DX/SX support changes for v3.8

://www.bellard.org/jslinux/. http://www.bellard.org/jslinux/tech.html says that it (also) lacks an FPU. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer

actually used it to show that no gcc-isms are necessary. ANSI-C is fine too for that case. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send the line "unsubscribe linux-

Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer

On Fre, 2012-09-14 at 08:30 -0400, Jim Rees wrote: > Bernd Petrovitsch wrote: [...] > A pure K version would use a string: > snip > #define base10len(i) "\0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14"[sizeof(i)] > snip > (if I converted th

Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer

a "char" which is happily promoted to whatever one needs in that place. Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send the line "unsubs

Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer

, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer

On Fre, 2012-09-14 at 08:30 -0400, Jim Rees wrote: Bernd Petrovitsch wrote: [...] A pure KR-C version would use a string: snip #define base10len(i) \0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14[sizeof(i)] snip (if I converted them properly into hexadecimal

Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer

. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: Why exported const value modified by another driver not updated in original driver

int value = 123; [...] > EXPORT_SYMBOL(value); I wonder if we can modify EXPORT_SYMBOL() so that it compile-time-fails for "static" variables. And if we actually want that. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at

Re: Why exported const value modified by another driver not updated in original driver

this question silly? That all is actually pure (KR-)C and has nothing to do with the kernel. static const int value = 123; [...] EXPORT_SYMBOL(value); I wonder if we can modify EXPORT_SYMBOL() so that it compile-time-fails for static variables. And if we actually want that. Bernd -- Bernd

Re: Drop support for x86-32

and I do not believe that you will keep to it (and I seriously doubt that anyone believes that). Go troll somewhere else. Thank you. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list

Re: Drop support for x86-32

not believe that you will keep to it (and I seriously doubt that anyone believes that). Go troll somewhere else. Thank you. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at -- To unsubscribe from this list: send

  1   2   3   4   >