Re: [PATCH net-next] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)
Hi all!
On 07/04/2021 23:59, Dexuan Cui wrote:
[...]
> FWIW, {0} and { 0 } are still widely used, but it looks like
> {} is indeed more preferred:
>
> $ grep "= {};" drivers/net/ -nr | wc -l
> 829
$ egrep -nr "=[[:space:]]*{[[:space:]]*};" drivers/net/ | wc -l
872
> $ grep "= {0};" drivers/net/ -nr | wc -l
> 708
$ egrep -nr "=[[:space:]]*{[[:space:]]*0[[:space:]]*};" drivers/net/ |
wc -l
1078
> $ grep "= {};" kernel/ -nr | wc -l
> 29
$ egrep -nr "=[[:space:]]*{[[:space:]]*};" kernel/ | wc -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
Hi all!
On 02/03/2021 18:42, Joe Perches wrote:
[...]
> - For instance: (head -10 of the git grep for file statics)
>
> drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 16,
> 8, 4, 2, 1 };
> drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[] = {
> drivers/accessibility/speakup/main.c:2059:static spkup_hand spkup_handler[] =
> {
> drivers/accessibility/speakup/speakup_acntpc.c:35:static unsigned int
> synth_portlist[] = { 0x2a8, 0 };
> drivers/accessibility/speakup/speakup_decpc.c:133:static int synth_portlist[]
> = { 0x340, 0x350, 0x240, 0x250, 0 };
> drivers/accessibility/speakup/speakup_dectlk.c:110:static int ap_defaults[] =
> {122, 89, 155, 110, 208, 240, 200, 106, 306};
> drivers/accessibility/speakup/speakup_dectlk.c:111:static int g5_defaults[] =
> {86, 81, 86, 84, 81, 80, 83, 83, 73};
> drivers/accessibility/speakup/speakup_dtlk.c:34:static unsigned int
> synth_portlist[] = {
> drivers/accessibility/speakup/speakup_keypc.c:34:static unsigned int
> synth_portlist[] = { 0x2a8, 0 };
> drivers/acpi/ac.c:137:static enum power_supply_property ac_props[] = {
>
> 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
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
There is NO CLOUD, just other people's computers. - FSFE
LUGA : http://www.luga.at
Re: Old platforms: bring out your dead
On Wed, 2021-01-13 at 14:21 +0200, Andy Shevchenko wrote:
[...]
> WRT x86 I run the search
> https://pc104.org/product-search-results/?kw=x86_tag=_typeFilter+by+Member+Company
> seems like all of them are based on Vortex86DX.
There are some real/true PC104 boards left -
still in production - 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 Petrovitsch Email : be...@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
LUGA : http://www.luga.at
Re: Toolchain-dependent config options
Hi all! On Thu, 2021-01-14 at 13:56 +0900, Masahiro Yamada wrote: > On Thu, Jan 14, 2021 at 7:21 AM Josh Poimboeuf wrote: [...] > > If I copy a config with CONFIG_GCC_PLUGINS to another system which > > doesn't have the gcc-plugin-devel package, it gets silently disabled by > > "make olddefconfig". > > > > I've seen multiple cases lately where this is causing confusion. I > > suspect the problem is getting worse with recent added support for a > > variety of toolchains and toolchain-dependent features. > > > > Would it be possible to have an error (or at least a warning) in this > > case? > > > > For example, a "depends-error" which triggers an error if its failure > > would disable a feature? [...] > We disable any feature that is unsupported by the compiler in use. > > Conventionally, we did that in the top Makefile > by using $(call cc-option, ) macro or by running some scripts. > > Recently, we are moving such compiler tests to the Kconfig stage. > > Anyway, we disable unsupported features so any combination > of CONFIG options builds successfully. > This will ease randconfg and allmodconfig tests. For options of $CC, that makes sense since there are different compilers and lots of versions of them out there. > A lot of people and CI systems are running allmodconfig tests > for various architectures and toolchains. Isn't some kind of defying (or more killing) the usefulness of regression compile runs if one does `make allmodconfig` and some (lots?) of stuff gets automatically configured out just because some -dev(|el) package is missing? Aren't there some kernel-build meta packages for various distributions out there 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
Hi all! On Tue, 2021-01-05 at 18:03 -0600, Eric W. Biederman wrote: [...] > Maybe I am wrong and there are interesting users of x32. All I remember > is that last time this was discussed someone found a distro that > actually shipped an x32 build to users. Which was just enough users 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. > > > > Perhaps I'm not the only one who has /sbin and /usr/sbin in the > > $PATH of normal accounts too (and idk what's the default > > behaviour of distributions is - my .bashrc "fixes" the > > $PATH). > > I was thinking more towards maxim/dictum: > "Never break userspace!" or "It worked before but now it is not." But if userspace changed (and that could be a change by the distribution which the user isn't aware) than ... > Think of automated kernel build and test setups based on Debian. > > Debian/testing AMD64 has... OK. > [ /etc/login.defs ] > > # *REQUIRED* The default PATH settings, for superuser and normal users. > # > # (they are minimal, add the rest in the shell startup files) > ENV_SUPATH > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > ENV_PATHPATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games Well, "minimal" and /usr/local/games:/usr/games ... /usr/local/* is the next ... Yes, it's hard for the distribution to "guess" the local admins habits and policies > IMHO users should not need to fix their environment. > ( The discussion is a bit obsolete as we now have a fix. ) FWIW, I have no (and don't see any) problems simply appending /sbin:/usr/sbin to the $PATH in/for the kernel's scripts. 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 10:13 +0100, Sedat Dilek wrote:
[...]
> To be honest I wondered why there were no more reports on this.
Perhaps I'm not the only one who has /sbin and /usr/sbin in the
$PATH of normal accounts too (and idk what's the default
behaviour of distributions is - my .bashrc "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
Hi all! On Sat, 2020-12-26 at 14:30 -0800, Theodore Dubois wrote: [...] > thing on macOS (please don't question my sanity :), and I've run > into various issues stemming from macOS having a case-insensitive > filesystem. Case-insensitive filesystems are broken by design. Kind 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
Hi all! On 29/10/2020 14:10, Michael J. Baars wrote: [...] > According to manual page socket(7), SO_REUSEADDR allows for local addresses > to be reused for binding. I've tested this socket option with the WAN > address, it > appears the problem is solved for both local and non-local connections. Yup. > I also found the the SO_LINGER socket option to be useful in some way. By > default, SO_LINGER is set to 0, so you would think that lingering connections > were out > of the question. However, an enabled linger with a l_onoff = 1 and a l_linger > = 0 seems to work a lot better than a disabled linger with a l_onoff = 0 and a > l_linger = 0. > > Which option would you use? I never used SO_LINGER before. >From the description in `man 7 socket`, active SO_LINGER just makes shutdown() to block if not all data has been transmitted (and ACKed?). 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.at There is no cloud, just other people computers. - FSFE LUGA : http://www.luga.at
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 closes it's > sockets before the server closes it's sockets, to prevent linger, but trying > did Which were exactly? English/original text pls ... And The close() (and shutdown() syscalls, respectively) don't avoid the FIN_WAIT2 timeout on a closed socket. Just set the SO_REUSEADDR socket option on the listening socket. > not help. Now I think I found the problem. Then solve it. > Please do have a look at the code. It looks like the SIGHUP is sent to the > server not on close or exit, but on the connect instead. Too lazy to save and uncompress the file ... MfG, Bernd -- There is no cloud, just other people computers. -- https://static.fsf.org/nosvn/stickers/thereisnocloud.svg pEpkey.asc Description: application/pgp-keys
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 >>> script from the repository. >>> >>> Link: >>> https://lore.kernel.org/lkml/20200830174409.c24c3f67addcce0cea9a9...@linux-foundation.org/ >>> Link: https://lore.kernel.org/lkml/202008271102.FEB906C88@keescook/ >>> >>> Suggested-by: Andrew Morton >>> Suggested-by: Kees Cook >>> Suggested-by: Lukas Bulwahn >>> Signed-off-by: Ujjwal Kumar >>> --- >>> Makefile | 4 ++-- >>> arch/arm64/kernel/vdso/Makefile | 2 +- >>> arch/arm64/kernel/vdso32/Makefile | 2 +- >>> arch/ia64/Makefile| 4 ++-- >>> arch/nds32/kernel/vdso/Makefile | 2 +- >>> scripts/Makefile.build| 2 +- >>> scripts/Makefile.package | 4 ++-- >>> 7 files changed, 10 insertions(+), 10 deletions(-) >>> >>> diff --git a/Makefile b/Makefile >>> index 0af7945caa61..df20e71dd7c8 100644 >>> --- a/Makefile >>> +++ b/Makefile >>> @@ -1256,7 +1256,7 @@ include/generated/utsrelease.h: >>> include/config/kernel.release FORCE >>> PHONY += headerdep >>> headerdep: >>> $(Q)find $(srctree)/include/ -name '*.h' | xargs --max-args 1 \ >>> - $(srctree)/scripts/headerdep.pl -I$(srctree)/include >>> + $(PERL) $(srctree)/scripts/headerdep.pl -I$(srctree)/include >>> >>> # >>> --- >>> # Kernel headers >>> @@ -1312,7 +1312,7 @@ PHONY += kselftest-merge >>> kselftest-merge: >>> $(if $(wildcard $(objtree)/.config),, $(error No .config exists, config >>> your kernel first!)) >>> $(Q)find $(srctree)/tools/testing/selftests -name config | \ >>> - xargs $(srctree)/scripts/kconfig/merge_config.sh -m >>> $(objtree)/.config >>> + xargs $(CONFIG_SHELL) >>> $(srctree)/scripts/kconfig/merge_config.sh -m $(objtree)/.config >>> $(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig >>> >>> # >>> --- >>> diff --git a/arch/arm64/kernel/vdso/Makefile >>> b/arch/arm64/kernel/vdso/Makefile >>> index edccdb77c53e..fb07804b7fc1 100644 >>> --- a/arch/arm64/kernel/vdso/Makefile >>> +++ b/arch/arm64/kernel/vdso/Makefile >>> @@ -65,7 +65,7 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE >>> # Generate VDSO offsets using helper script >>> gen-vdsosym := $(srctree)/$(src)/gen_vdso_offsets.sh >>> quiet_cmd_vdsosym = VDSOSYM $@ >>> - cmd_vdsosym = $(NM) $< | $(gen-vdsosym) | LC_ALL=C sort > $@ >>> + cmd_vdsosym = $(NM) $< | $(CONFIG_SHELL) $(gen-vdsosym) | LC_ALL=C >>> sort > $@ >>> >>> include/generated/vdso-offsets.h: $(obj)/vdso.so.dbg FORCE >>> $(call if_changed,vdsosym) >>> diff --git a/arch/arm64/kernel/vdso32/Makefile >>> b/arch/arm64/kernel/vdso32/Makefile >>> index 7f96a1a9f68c..617c9ac58156 100644 >>> --- a/arch/arm64/kernel/vdso32/Makefile >>> +++ b/arch/arm64/kernel/vdso32/Makefile >>> @@ -205,7 +205,7 @@ quiet_cmd_vdsomunge = MUNGE $@ >>> gen-vdsosym := $(srctree)/$(src)/../vdso/gen_vdso_offsets.sh >>> quiet_cmd_vdsosym = VDSOSYM $@ >>> # The AArch64 nm should be able to read an AArch32 binary >>> - cmd_vdsosym = $(NM) $< | $(gen-vdsosym) | LC_ALL=C sort > $@ >>> + cmd_vdsosym = $(NM) $< | $(CONFIG_SHELL) $(gen-vdsosym) | LC_ALL=C >>> sort > $@ >>> >>> # Install commands for the unstripped file >>> quiet_cmd_vdso_install = INSTALL32 $@ >>> diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile >>> index 703b1c4f6d12..86d42a2d09cb 100644 >>> --- a/arch/ia64/Makefile >>> +++ b/arch/ia64/Makefile >>> @@ -27,8 +27,8 @@ cflags-y := -pipe $(EXTRA) -ffixed-r13 >>> -mfixed-range=f12-f15,f32-f127 \ >>>-falign-functions=32 -frename-registers >>> -fno-optimize-sibling-calls >>> KBUILD_CFLAGS_KERNEL := -mconstant-gp >>> >>> -GAS_STATUS = $(shell $(srctree)/arch/ia64/scripts/check-gas "$(CC)" >>> "$(OBJDUMP)") >>> -KBUILD_CPPFLAGS += $(shell $(srctree)/arch/ia64/scripts/toolchain-flags >>> "$(CC)" "$(OBJDUMP)" "$(READELF)") >>> +GAS_STATUS = $(shell $(CONFIG_SHELL) >>> $(srctree)/arch/ia64/scripts/check-gas "$(CC)" "$(OBJDUMP)") >>> +KBUILD_CPPFLAGS += $(shell $(CONFIG_SHELL) >>> $(srctree)/arch/ia64/scripts/toolchain-flags "$(CC)" "$(OBJDUMP)" >>> "$(READELF)") >> >> Here is an instance of what Masahiro-san pointed out being wrong. >> >> Ujjwal, will you send a v3? > > Following is the quoted text from the reply mail from Masahiro > >>> -GAS_STATUS = $(shell $(srctree)/arch/ia64/scripts/check-gas "$(CC)" >>> "$(OBJDUMP)") >>> -KBUILD_CPPFLAGS += $(shell $(srctree)/arch/ia64/scripts/toolchain-flags >>> "$(CC)" "$(OBJDUMP)" "$(READELF)") >>> +GAS_STATUS = $($(CONFIG_SHELL) $(srctree)/arch/ia64/scripts/check-gas >>> "$(CC)" "$(OBJDUMP)") >>> +KBUILD_CPPFLAGS += $($(CONFIG_SHELL) >>>
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 can be done to narrow down the root cause? > Any example of reference could be helpful to understand. I haven't checked the date of the older kernel but Spectre+ Meltdown mitigation costs a lot (20%-30% speed IIRC, out of the top of my head). MfG, Bernd -- There is no cloud, just other people computers. -- https://static.fsf.org/nosvn/stickers/thereisnocloud.svg pEpkey.asc Description: application/pgp-keys
Re: [PATCH] Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang
On 11/08/2019 05:17, Nathan Chancellor wrote: > On Sat, Aug 10, 2019 at 08:06:05PM -0700, Joe Perches wrote: >> On Sat, 2019-08-10 at 19:04 -0700, Nathan Chancellor wrote: >>> On a tangential note, how are you planning on doing the fallthrough >>> comment to attribute conversion? The reason I ask is clang does not >>> support the comment annotations, meaning that when Nathan Huckleberry's >>> patch is applied to clang (which has been accepted [1]), we are going >>> to get slammed by the warnings. I just ran an x86 defconfig build at >>> 296d05cb0d3c with his patch applied and I see 27673 instances of this >>> warning... (mostly coming from some header files so nothing crazy but it >>> will be super noisy). >>> >>> If you have something to share like a script or patch, I'd be happy to >>> test it locally. >>> >>> [1]: https://reviews.llvm.org/D64838 >> >> Something like this patch: >> >> https://lore.kernel.org/patchwork/patch/1108577/ >> >> Maybe use: >> >> #define fallthrough [[fallthrough]] >> >> 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 attribute macro, was that going to be done with > Coccinelle or something else? clang has not problem with the comment - it's just a comment;-) The #define above works BTW. MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
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 then (in unpredictable ways) too. MfG, Bernd-- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds pEpkey.asc Description: application/pgp-keys
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
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
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 is important here, the use of 'cat', 'xargs' and >>> 'basename' may be substituted with that of 'sed' to initialise >>> same_name_modules: >>> sed 's!.*/!!' modules.order modules.builtin | sort | uniq -d >> >> 's!' is TTBOMK also a GNU-extension: >> sed 's/.*\///' modules.order modules.builtin | sort | uniq -d > > It isn't. > Here's an excerpt from the POSIX manpage for 'sed', > http://pubs.opengroup.org/onlinepubs/009695399/utilities/sed.html: > [2addr]s/BRE/replacement/flags > ... Any character other than backslash or can be used > instead of a slash to delimit the BRE and the replacement Oops, yup, sorry for the noise. Don't know anymore where I encountered problems with that in the past MfG, Bernd-- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds pEpkey.asc Description: application/pgp-keys
Re: [PATCH v2] kbuild: check uniqueness of module names
On 17/05/2019 10:16, Alexander Kapshuk wrote:
[...]
> The 'xargs' '-r' flag is a GNU extension.
> If POSIX compliance is important here, the use of 'cat', 'xargs' and
> 'basename' may be substituted with that of 'sed' to initialise
> same_name_modules:
> sed 's!.*/!!' modules.order modules.builtin | sort | uniq -d
's!' is TTBOMK also a GNU-extension:
sed 's/.*\///' modules.order modules.builtin | sort | uniq -d
> 'Sed' may also be used on its own in the 'for' loop instead of as part
> of a pipeline along with 'grep' to generate the desired output:
> sed '/\/'$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 pointless > though. Obviously;-) Sorry for being unclear above: If I want my application to avoid suffering from page faults, I use simply mlock() (and/or friends) to nail the relevant pages into physical RAM and not "look if they are out, if yes, get them in" which has also the risk that these important pages are too soon evicted again. But perhaps I'm missing some very special use cases MfG, Brend -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On 05/01/2019 20:38, Vlastimil Babka wrote: [...] > I was thinking about "return true" here, assuming that userspace generally > wants > to ensure itself there won't be page faults when it starts doing something > critical, and if it sees a "false" it will try 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? MfG, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: Why is no one discussing this anymore?
On 27/12/2018 21:30, vsnsdua...@memeware.net wrote: Real name pls, if want to be taken somewhat serious? Thank you. > Why is no one discussing this anymore. You don't discuss anything in the first place: You just spam mails with claims without any reproducible proof. And since we are here on a techie-list, said proofs should be techie-understandable - it's not that techies adjust to non-techies if it goes in the other direction. > It's like you just accepted the "NU UH U WRONG" proclamation from "Proof by claim"? I don't think so > Are you idiots [...] > > 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's only spam after all ... -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
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" // for time_t
>> # define PRI_nsec_t "lld" // for tv_nsec in struct timespec
>> # else // x86_64
>> # define PRI_time_t "ld"// for time_t
>> # define PRI_nsec_t "ld"// for tv_nsec in struct timespec
>> # endif
>> #else// i[3-6]68
>> # define PRI_time_t "ld"// for time_t
>> # define PRI_nsec_t "ld"// for tv_nsec in struct timespec
>> #endif
>> snip
>> in my userspace code for printf() and friends - I don't know how libc's
>> react to such a patch (and I don't care for the name of the macros as
>> long it's obviously clear for which type they are).
>> I assume/fear we won't get additional modifiers into the relevant
>> standards for libc types (as they are far more like pid_t, uid_t etc.).
>> And casting to u/intmaxptr_t to get a defined printf()-modifier doesn't
>> look appealing to me to "solve" such issues.
>
> This is all useless (and wrong since tv_nsec is required to have type
> long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
Thanks. OK, I didn't know that - and 32bit is enough to represent 1E9
(as a second won't have more nanosecs).
Hmm, can we fix that in the x32 world?
Sry, I'm not the expert on glibc vs ABI va syscall interface vs breakage
there though.
> in glibc's x32). Just do:
>
> printf("%jd", (intmax_t)t);
>
> Saving 2 or 3 insns (for sign or zero extension) around a call to
> printf is not going to make any measurable difference to performance
Until someone comes up with hardware with ASIC support for 1k bit int's
and (ab)uses intmax_t for that. SCNR
> or any significant difference to size, and it's immeasurably more
> readable than the awful PRI* macros and the
> adjacent-string-concatenation they rely on.
One gets used to the PRI_* macros over time (and there no calculated
format strings in my world) - and type casts are not better in my eyes ...
MfG,
Bernd
--
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds
pEpkey.asc
Description: application/pgp-keys
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 causing issues. For example, application code usually >> expects things like time_t to be 32-bit on a 32-bit system. However, this IMHO this just historically grown (as in "it has been forever that way" - it sounds way better in Viennese dialect though;-). >> isn't the case for x32 which is why code fails to build. > > I don't see any basis for this claim about expecting time_t to be > 32-bit. I've encountered some programs that "implicitly assume" this > by virtue of assuming they can cast time_t to long to print it, or > similar. IIRC this was an issue in busybox at one point; I'm not sure > if it's been fixed. But any software that runs on non-Linux unices has > long been corrected. If not, 2038 is sufficiently close that catching > and correcting any such remaining bugs is more useful than covering > them up and making the broken code work as expected. Yup, unconditionally providing 64bit time_t/timespec/timeval/...-equivalents with libc and syscall support also for 32bit architectures (and deprecating all 32bit versions) should be the way to go. FWIW I have snip #if defined __x86_64__ # if defined __ILP32__ // x32 # define PRI_time_t"lld" // for time_t # define PRI_nsec_t"lld" // for tv_nsec in struct timespec # else // x86_64 # define PRI_time_t"ld"// for time_t # define PRI_nsec_t"ld"// for tv_nsec in struct timespec # endif #else // i[3-6]68 # define PRI_time_t "ld"// for time_t # define PRI_nsec_t "ld"// for tv_nsec in struct timespec #endif snip in my userspace code for printf() and friends - I don't know how libc's react to such a patch (and I don't care for the name of the macros as long it's obviously clear for which type they are). I assume/fear we won't get additional modifiers into the relevant standards for libc types (as they are far more like pid_t, uid_t etc.). And casting to u/intmaxptr_t to get a defined printf()-modifier doesn't look appealing to me to "solve" such issues. MfG, Bernd -- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds pEpkey.asc Description: application/pgp-keys
Re: Cleaning up numbering for new x86 syscalls?
On 20/11/2018 08:33, Ingo Molnar wrote:
[...]
> 6. Is x32 even used in practice? I still think it was a mistake to add it
>and some significant distributions like Fedora are not enabling it.
x32 works as far as gcc/gas/ld is concerned (at least for compiling
non-trivial programs).
Finding a distribution that actually *delivers* x32 libraries is another
thing (and said non-trivial software uses ATM e.g. libxml2) - at least I
can't find an "x32-Ubuntu".
And no, I don't see a compelling reason to (try to) build the n+1.
architecture for the major distributions.
And yes, lots of stuff will not compile out of the box (especially if
one uses a somewhat sane set of gcc options - not only -Wall -Wextra
-Werror) but if one gets software to compile for i386 and x86_64,
getting it to compile for x32 is a Friday afternoon job (more or less).
And yes, there is enough hardware/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?
On 20/11/2018 08:33, Ingo Molnar wrote:
[...]
> 6. Is x32 even used in practice? I still think it was a mistake to add it
>and some significant distributions like Fedora are not enabling it.
x32 works as far as gcc/gas/ld is concerned (at least for compiling
non-trivial programs).
Finding a distribution that actually *delivers* x32 libraries is another
thing (and said non-trivial software uses ATM e.g. libxml2) - at least I
can't find an "x32-Ubuntu".
And no, I don't see a compelling reason to (try to) build the n+1.
architecture for the major distributions.
And yes, lots of stuff will not compile out of the box (especially if
one uses a somewhat sane set of gcc options - not only -Wall -Wextra
-Werror) but if one gets software to compile for i386 and x86_64,
getting it to compile for x32 is a Friday afternoon job (more or less).
And yes, there is enough hardware/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.
On 25/09/2018 19:14, \0xDynamite wrote: [...] >>> So, is code a *published* item? Most of the public can't read it. >> >> I cannot read (or understand) neither Russian nor Chinese nor almost any >> natural (let alone dead) languages of the world. I'm pretty sure that >> I'm not the only one;-) >> Does that make Russian literature non-public? I don't think so ... > > You confuse the issue. My definition included "intended for the > public". But it isn't clear that open source code is intended for the Well, then I have to repeat myself: Signed-off source code (in form of patches) in a well-known programming language for a (nowadays) well-known GPLv2 licensed project mailed on "everyone can subscribe" mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed mailinglist archives, if accepted to be 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.
On 25/09/2018 19:14, \0xDynamite wrote: [...] >>> So, is code a *published* item? Most of the public can't read it. >> >> I cannot read (or understand) neither Russian nor Chinese nor almost any >> natural (let alone dead) languages of the world. I'm pretty sure that >> I'm not the only one;-) >> Does that make Russian literature non-public? I don't think so ... > > You confuse the issue. My definition included "intended for the > public". But it isn't clear that open source code is intended for the Well, then I have to repeat myself: Signed-off source code (in form of patches) in a well-known programming language for a (nowadays) well-known GPLv2 licensed project mailed on "everyone can subscribe" mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed mailinglist archives, if accepted to be 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.
On 24/09/2018 20:59, \0xDynamite wrote: >>> * Publishing others’ private information, such as a physical or >>> electronic >>> address, without explicit permission >> >> I need an (explicit) permission to "publish" an already published email >> address which is already world-wide known because it can be found by the >> simplest and worst search engine as the email address is in public >> mailing list archives and git repos? >> >> Sounds pretty absurd as the people themselves already published their >> email address. >> >> IMHO you cannot "publish" already published stuff. > > The notion of being "published" means at least these two things: 1) Where exactly - URL? - is that notion defined? Especially the intention is IMHO not necessary - just the fact if it happened (and I don't think we want to discuss legal stuff about "X broke into my home, stole and published my work" - the patent world has the same problem). > you INTEND it to be PUBLIC, 2) you made it available to the PUBLIC > A semi-private email list is a boundary area of being public. Just Define "semi-private" - URL?: Any company/club/family/...-internal ML is - should be;-) - obviously private as the subscription policy is usually pretty selective (read: not public, not debatable, ...) and the archives - if any - are not public by design. So everyone there should know that. Of course, anyone getting all mails can put an $SEARCH_MACHINE indexed archive publicly online but that's another (law) question. On the otherhand, if the mailinglist is public, the (future) subscribers should know the beforehand. > like a memo distributed within a university department. Participants > in the latter have some reasonable expectation that the material is > not being published in the larger public sphere beyond actions of the > trusted participants involved (which might share it in a limited > fashion as a personal note). ACK but what has that to do with LKML etc? You try to change - manipulate - the issues of the discussion. Are you only a troll? > So, is code a *published* item? Most of the public can't read it. I cannot read (or understand) neither Russian nor Chinese nor almost any natural (let alone dead) languages of the world. I'm pretty sure that I'm not the only one;-) Does that make Russian literature non-public? I don't think so ... You really don't want to go down that road - neither with law people and even less with techies. So how can be (source) code (at least in any publicly known/defined language) posted on a "everyone can subscribe" mailinglist, archived in several $SEARCH_ENGINE indexed mailinglist archives and replicated in a myriad of public accessible git-repos with the only intention of inclusion in the Kernel not be *obviously* and *clearly* public? > It is often not intended for the public, per se, only a specialized Maybe but doesn't change any fact of publication - you may also want to check with patent folks and "unintended or unwanted publication" (yes, some talk in a "maybe publicly accessible space" might count there as "publication") - they have more or less the same situation. > COMMUNITY. Because once published, it belongs to copyright and fair> use > (THAT sticky little wicket). In the law area, the Copyright (TTBOMK) and the much more advanced Central European Authors rights start to exist with existence of the "work" (and not a µs later) independent of any status or situation of publication. Where does the "fair use" come from? Reads: where is that defined? If you want me to define "fair use of source code publicized in the LKML and similar under the GPLv2": You also cease the right to efeectively revoke it (though that is in some jurisdictions not possible but that "revoke-right" was made for completely different situations - long before GPL or CC was even thinkable). "effectively revoke it" is meant that you cannot say "I wrote parts of it/I'm the initial contributor/I have a significant patch accepted and I'm fed up with the kernel so remove all my contributions". BTW you cannot do that at your workplace either because in all sane software development companies you cease all (transferable) rights of your written to the company paying 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 with "not intended for the public" or "semi-public" or any other off-topic stuff which is clearly not the case here. Or - even better - shut up, unsubscribe and go away, thank you. MfG, Bernd, NAL but I talked to a lot of them;-) PS: Sorry for troll feeding:-( -- 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.
On 24/09/2018 20:59, \0xDynamite wrote: >>> * Publishing others’ private information, such as a physical or >>> electronic >>> address, without explicit permission >> >> I need an (explicit) permission to "publish" an already published email >> address which is already world-wide known because it can be found by the >> simplest and worst search engine as the email address is in public >> mailing list archives and git repos? >> >> Sounds pretty absurd as the people themselves already published their >> email address. >> >> IMHO you cannot "publish" already published stuff. > > The notion of being "published" means at least these two things: 1) Where exactly - URL? - is that notion defined? Especially the intention is IMHO not necessary - just the fact if it happened (and I don't think we want to discuss legal stuff about "X broke into my home, stole and published my work" - the patent world has the same problem). > you INTEND it to be PUBLIC, 2) you made it available to the PUBLIC > A semi-private email list is a boundary area of being public. Just Define "semi-private" - URL?: Any company/club/family/...-internal ML is - should be;-) - obviously private as the subscription policy is usually pretty selective (read: not public, not debatable, ...) and the archives - if any - are not public by design. So everyone there should know that. Of course, anyone getting all mails can put an $SEARCH_MACHINE indexed archive publicly online but that's another (law) question. On the otherhand, if the mailinglist is public, the (future) subscribers should know the beforehand. > like a memo distributed within a university department. Participants > in the latter have some reasonable expectation that the material is > not being published in the larger public sphere beyond actions of the > trusted participants involved (which might share it in a limited > fashion as a personal note). ACK but what has that to do with LKML etc? You try to change - manipulate - the issues of the discussion. Are you only a troll? > So, is code a *published* item? Most of the public can't read it. I cannot read (or understand) neither Russian nor Chinese nor almost any natural (let alone dead) languages of the world. I'm pretty sure that I'm not the only one;-) Does that make Russian literature non-public? I don't think so ... You really don't want to go down that road - neither with law people and even less with techies. So how can be (source) code (at least in any publicly known/defined language) posted on a "everyone can subscribe" mailinglist, archived in several $SEARCH_ENGINE indexed mailinglist archives and replicated in a myriad of public accessible git-repos with the only intention of inclusion in the Kernel not be *obviously* and *clearly* public? > It is often not intended for the public, per se, only a specialized Maybe but doesn't change any fact of publication - you may also want to check with patent folks and "unintended or unwanted publication" (yes, some talk in a "maybe publicly accessible space" might count there as "publication") - they have more or less the same situation. > COMMUNITY. Because once published, it belongs to copyright and fair> use > (THAT sticky little wicket). In the law area, the Copyright (TTBOMK) and the much more advanced Central European Authors rights start to exist with existence of the "work" (and not a µs later) independent of any status or situation of publication. Where does the "fair use" come from? Reads: where is that defined? If you want me to define "fair use of source code publicized in the LKML and similar under the GPLv2": You also cease the right to efeectively revoke it (though that is in some jurisdictions not possible but that "revoke-right" was made for completely different situations - long before GPL or CC was even thinkable). "effectively revoke it" is meant that you cannot say "I wrote parts of it/I'm the initial contributor/I have a significant patch accepted and I'm fed up with the kernel so remove all my contributions". BTW you cannot do that at your workplace either because in all sane software development companies you cease all (transferable) rights of your written to the company paying 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 with "not intended for the public" or "semi-public" or any other off-topic stuff which is clearly not the case here. Or - even better - shut up, unsubscribe and go away, thank you. MfG, Bernd, NAL but I talked to a lot of them;-) PS: Sorry for troll feeding:-( -- 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.
On 22/09/2018 01:31, jonsm...@gmail.com wrote: [...] > How does this part apply to email addresses used to commit code? > > * Publishing others’ private information, such as a physical or electronic > address, without explicit permission I need an (explicit) permission to "publish" an already published email address which is already world-wide known because it can be found by the simplest and worst search engine as the email address is in public mailing list archives and git repos? Sounds pretty absurd as the people themselves already published their email address. 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.
On 22/09/2018 01:31, jonsm...@gmail.com wrote: [...] > How does this part apply to email addresses used to commit code? > > * Publishing others’ private information, such as a physical or electronic > address, without explicit permission I need an (explicit) permission to "publish" an already published email address which is already world-wide known because it can be found by the simplest and worst search engine as the email address is in public mailing list archives and git repos? Sounds pretty absurd as the people themselves already published their email address. 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?
Hi all! On Thu, 2018-08-23 at 10:43 -0700, Paul E. McKenney wrote: > [...] > Does anyone do kernel-only deployments, for example, setting up an > embedded device having a Linux kernel and absolutely no userspace > whatsoever? [...] > You see, rcutorture runs entirely out of initrd, never mounting a real > root partition. The user has been required to supply the initrd, but IMHO running programs from the initrd is in user-space, but anyways: Ages ago at some former employer, we built an embedded Linux device on an MPC-860 board (but that shouldn't make a significant difference to other architectures) based on the (at that time) brand new 2.4 kernel which ran completely out of the initrd (which obviously contained the whole root filesystem). [...] > by throwing out everything not absolutely needed by the dash and sleep > binaries, which got me down to about 2.5MB, 1.8MB of which was libc. We had a working glibc binary (which as the largest binary on the filesystem) and just used it (and never got time and/or necessity to use something else like ulibc, newlibc or build glibc ourselves to leave all unneeded stuff out). We basically built the filesystem - the distribution as such;-) - from scratch (only self-crafted `configure` calls around[0]) and - thus - used busybox and ash (IIRC) - so throw dash, core-utils etc. away and just use busybox (or something similar) for further space savings. The whole startup and daemon management was done with busybox' "init" via a simple /etc/inittab (that were the good old times;-) and it was enough as one can start one-time programs at boot time (e.g. to load kernel modules (and remove the file in the filesystem from the filesystem[0]) or configure stuff via sysctl) and restart daemons. We didn't need run-levels ... > This situation of course prompted me to create an initrd containing > a statically linked binary named "init" and absolutely nothing else > (not even /dev or /tmp directories), which weighs in at not quite 800KB. That is probably the smallest solution - if it's enough. If it's all GPL, just link it statically against dietlibc We had all of the usual directories and a somewhat filled /dev (completely static in the initrd IIRC, no udev or similar dynamic stuff was needed) as we had dropbear as ssh-server, a small webserver+CGI- script for a 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?
Hi all! On Thu, 2018-08-23 at 10:43 -0700, Paul E. McKenney wrote: > [...] > Does anyone do kernel-only deployments, for example, setting up an > embedded device having a Linux kernel and absolutely no userspace > whatsoever? [...] > You see, rcutorture runs entirely out of initrd, never mounting a real > root partition. The user has been required to supply the initrd, but IMHO running programs from the initrd is in user-space, but anyways: Ages ago at some former employer, we built an embedded Linux device on an MPC-860 board (but that shouldn't make a significant difference to other architectures) based on the (at that time) brand new 2.4 kernel which ran completely out of the initrd (which obviously contained the whole root filesystem). [...] > by throwing out everything not absolutely needed by the dash and sleep > binaries, which got me down to about 2.5MB, 1.8MB of which was libc. We had a working glibc binary (which as the largest binary on the filesystem) and just used it (and never got time and/or necessity to use something else like ulibc, newlibc or build glibc ourselves to leave all unneeded stuff out). We basically built the filesystem - the distribution as such;-) - from scratch (only self-crafted `configure` calls around[0]) and - thus - used busybox and ash (IIRC) - so throw dash, core-utils etc. away and just use busybox (or something similar) for further space savings. The whole startup and daemon management was done with busybox' "init" via a simple /etc/inittab (that were the good old times;-) and it was enough as one can start one-time programs at boot time (e.g. to load kernel modules (and remove the file in the filesystem from the filesystem[0]) or configure stuff via sysctl) and restart daemons. We didn't need run-levels ... > This situation of course prompted me to create an initrd containing > a statically linked binary named "init" and absolutely nothing else > (not even /dev or /tmp directories), which weighs in at not quite 800KB. That is probably the smallest solution - if it's enough. If it's all GPL, just link it statically against dietlibc We had all of the usual directories and a somewhat filled /dev (completely static in the initrd IIRC, no udev or similar dynamic stuff was needed) as we had dropbear as ssh-server, a small webserver+CGI- script for a 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
On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote: > On 07-06-18, 15:46, Du, Changbin wrote: > > I think if the destination is not a null terminated string (If I understand > > your > > description below), memcpy can be used to get rid of such warning. The > > 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 copying it. Kind regards, Bernd -- 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
On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote: > On 07-06-18, 15:46, Du, Changbin wrote: > > I think if the destination is not a null terminated string (If I understand > > your > > description below), memcpy can be used to get rid of such warning. The > > 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 copying it. Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: Suggested new user link command
Hi all! Top-quoting is evil BTW. On Wed, 2018-05-02 at 00:17 +1200, Tony Wallace wrote: > Two issues here: > 1) Use case (which I have) > 2) Permissions > > 1) Use case > > I am trying to build a backup system. To avoid duplication of files > over multiple backups I take an Md5 check sum of file contents. Files > with the same sum are hardlinked together. Files are linked in to a > standard directory structure a new link for each backup that the file is > part of. When all backups pointing to a file are deleted the reference > count drops to zero and the file is deleted. We can keep a database of > checksums and there related inode numbers for linking purposes. So why a) You can store one of the filenames instead of the inode number. b) You can keep an extra directory with a hardlink named as the inode number (and delete the entries there if the link count drops to 1). > not have some reference copy to link against it would take no extra > space. Well it doesn't, but it keeps at least one copy of the file on You have a (disk) space problems on an backup system? I don't think so, Tim;-) > disk forever and the reference count never drops to zero. Using one of > the backup copies to link to (as stored as the reference copy in the > database) will not work as it could be deleted at any time. > > I have seen on stack overflow others wanting to do this also. "Do. Or do not. There is no try." - Yoda SCNR . > 2) Permissions > > To maintain security there are two requirements: > 2.1) The effective user must have rights to the inode, that is they must > either own it or be root > 2.2) The effective user must have rights file creation rights to the > directory where it is being linked Obviously (und useful). And on a backup system, there is no problem about that (because the backup software probably runs as root anyways because otherwise 2.1) below will limit the deduplication severely). But for a (to be mainlined/accepted) new syscall, one should think about all situations/use cases and not just one. Additionally to the 2 items above, one needs also x-permissions on *all* directories from / to one existing hardlink in the traditional case and such a syscall bypasses that. Think about it: Everyone can write a progrm to try link all inodes from 0 to ~0 to a directory entry and gets all files with restrictions 2.1) and 2.2) from below. ATM it is enough to `chmod o= ~` to keep all others from all files in my $HOME. Afterwards it's no longer that easy. > If you say no, that is fine, but I do think this idea has merit and can > be done without compromising the system. I'm no one to say no (or yes;-) here to anything;-) I'm just thinking about the implications. And you can always implement a patch and if it's ignored/not accepted, you can use it locally anyways - no one can stop that:-) One more - more constructive - thing: Perhaps 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
Hi all! Top-quoting is evil BTW. On Wed, 2018-05-02 at 00:17 +1200, Tony Wallace wrote: > Two issues here: > 1) Use case (which I have) > 2) Permissions > > 1) Use case > > I am trying to build a backup system. To avoid duplication of files > over multiple backups I take an Md5 check sum of file contents. Files > with the same sum are hardlinked together. Files are linked in to a > standard directory structure a new link for each backup that the file is > part of. When all backups pointing to a file are deleted the reference > count drops to zero and the file is deleted. We can keep a database of > checksums and there related inode numbers for linking purposes. So why a) You can store one of the filenames instead of the inode number. b) You can keep an extra directory with a hardlink named as the inode number (and delete the entries there if the link count drops to 1). > not have some reference copy to link against it would take no extra > space. Well it doesn't, but it keeps at least one copy of the file on You have a (disk) space problems on an backup system? I don't think so, Tim;-) > disk forever and the reference count never drops to zero. Using one of > the backup copies to link to (as stored as the reference copy in the > database) will not work as it could be deleted at any time. > > I have seen on stack overflow others wanting to do this also. "Do. Or do not. There is no try." - Yoda SCNR . > 2) Permissions > > To maintain security there are two requirements: > 2.1) The effective user must have rights to the inode, that is they must > either own it or be root > 2.2) The effective user must have rights file creation rights to the > directory where it is being linked Obviously (und useful). And on a backup system, there is no problem about that (because the backup software probably runs as root anyways because otherwise 2.1) below will limit the deduplication severely). But for a (to be mainlined/accepted) new syscall, one should think about all situations/use cases and not just one. Additionally to the 2 items above, one needs also x-permissions on *all* directories from / to one existing hardlink in the traditional case and such a syscall bypasses that. Think about it: Everyone can write a progrm to try link all inodes from 0 to ~0 to a directory entry and gets all files with restrictions 2.1) and 2.2) from below. ATM it is enough to `chmod o= ~` to keep all others from all files in my $HOME. Afterwards it's no longer that easy. > If you say no, that is fine, but I do think this idea has merit and can > be done without compromising the system. I'm no one to say no (or yes;-) here to anything;-) I'm just thinking about the implications. And you can always implement a patch and if it's ignored/not accepted, you can use it locally anyways - no one can stop that:-) One more - more constructive - thing: Perhaps 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
Hi
On Tue, 2018-05-01 at 20:03 +1200, Tony Wallace wrote:
> I am suggesting a new command for linking files. Currently there is
> no
> easy way to link a file with a known inode number to its correct
> position in the directory tree.
>
>
> int ilink(const int inode, const char *newpath)
... avoiding any permission checks on all paths to the existing names.
> The current alternative to this command is to find the file path
> associated with an inode using the find command and then once found
> using a standard link command. Obviously this is very inefficient.
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
Hi
On Tue, 2018-05-01 at 20:03 +1200, Tony Wallace wrote:
> I am suggesting a new command for linking files. Currently there is
> no
> easy way to link a file with a known inode number to its correct
> position in the directory tree.
>
>
> int ilink(const int inode, const char *newpath)
... avoiding any permission checks on all paths to the existing names.
> The current alternative to this command is to find the file path
> associated with an inode using the find command and then once found
> using a standard link command. Obviously this is very inefficient.
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)
On Wed, 2018-01-17 at 18:16 +0100, Dmitry Vyukov wrote: [...] > Agree, but as far as I understand it is specifically restricted. You > can see docs here: > https://cloud.google.com/appengine/docs/standard/php/mail/mail-with-headers-attachments ROTFL - as if almost no one at Google know that there are source files of any kind. > It also does not allow sending .exe, .com, .bat, etc at all. > The support for log/patch/c will at least solve all problems for syzbot. Yup, but they should better also add .h, .hpp., .cpp and a lot more from the source code world too. I'm 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...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: LKML admins (syzbot emails are not delivered)
On Wed, 2018-01-17 at 18:16 +0100, Dmitry Vyukov wrote: [...] > Agree, but as far as I understand it is specifically restricted. You > can see docs here: > https://cloud.google.com/appengine/docs/standard/php/mail/mail-with-headers-attachments ROTFL - as if almost no one at Google know that there are source files of any kind. > It also does not allow sending .exe, .com, .bat, etc at all. > The support for log/patch/c will at least solve all problems for syzbot. Yup, but they should better also add .h, .hpp., .cpp and a lot more from the source code world too. I'm 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...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: [PATCH 2/2] staging: media: atomisp2: Replace kfree()/vfree() with kvfree()
On Fri, 2017-07-07 at 20:41 -0400, Amitoj Kaur Chawla wrote:
[...]
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> @@ -117,11 +117,7 @@ void *atomisp_kernel_zalloc(size_t bytes, bool
> zero_mem)
> */
> void atomisp_kernel_free(void *ptr)
> {
> - /* Verify if buffer was allocated by vmalloc() or kmalloc()
> */
> - if (is_vmalloc_addr(ptr))
> - vfree(ptr);
> - else
> - kfree(ptr);
> + kvfree(ptr);
> }
>
> /*
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()
On Fri, 2017-07-07 at 20:41 -0400, Amitoj Kaur Chawla wrote:
[...]
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> @@ -117,11 +117,7 @@ void *atomisp_kernel_zalloc(size_t bytes, bool
> zero_mem)
> */
> void atomisp_kernel_free(void *ptr)
> {
> - /* Verify if buffer was allocated by vmalloc() or kmalloc()
> */
> - if (is_vmalloc_addr(ptr))
> - vfree(ptr);
> - else
> - kfree(ptr);
> + kvfree(ptr);
> }
>
> /*
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
Hi all! On Sun, 2017-06-25 at 15:47 -0700, Randy Dunlap wrote: > On 06/25/2017 02:18 PM, Enrico Weigelt, metux IT consult wrote: > > On 25.06.2017 22:10, Joe Perches wrote: > > > > > > Yeah, that's still an open problem. Actually, I still haven't found out, > > > > how it's done w/ all the other kernel-internal conversions. That is hard-coded in gcc ATM TTBOMK (AFAIK BSDs ship patched gcc's for their in-kernel extensions of format strings). > > > Everything else uses "%p", > > > > hmm, but errno's aren't pointers. Isn't %p checked for pointer > > values ? Yup, and gcc will also generate a format string warning/error. > > > > Already was about to do so. Shall I call it strerror() ? > > > > > > I presume kstrerror > > > > > > So use something like > > > "%d: (%s)", errno, kstrerror(errno) > > > > Okay, sounds good. > > but why not just do that in userspace. Sure, you can keep that as your > internal kernel patch, but there's not really much need for it to be in the > mainline kernel. So when 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
Hi all! On Sun, 2017-06-25 at 15:47 -0700, Randy Dunlap wrote: > On 06/25/2017 02:18 PM, Enrico Weigelt, metux IT consult wrote: > > On 25.06.2017 22:10, Joe Perches wrote: > > > > > > Yeah, that's still an open problem. Actually, I still haven't found out, > > > > how it's done w/ all the other kernel-internal conversions. That is hard-coded in gcc ATM TTBOMK (AFAIK BSDs ship patched gcc's for their in-kernel extensions of format strings). > > > Everything else uses "%p", > > > > hmm, but errno's aren't pointers. Isn't %p checked for pointer > > values ? Yup, and gcc will also generate a format string warning/error. > > > > Already was about to do so. Shall I call it strerror() ? > > > > > > I presume kstrerror > > > > > > So use something like > > > "%d: (%s)", errno, kstrerror(errno) > > > > Okay, sounds good. > > but why not just do that in userspace. Sure, you can keep that as your > internal kernel patch, but there's not really much need for it to be in the > mainline kernel. So when 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
On Tue, 2017-06-13 at 10:40 -0700, Darren Hart wrote:
[...]
> There are plenty of other examples of things you can do to screw up the
> state of your system if you have the right permissions for which the
> answer is "don't do that". Consider MEM(4), SETPCI(8), ... /dev/sda ...
> for example.
So what is the problem?!
And that pretty much answers it for the Unix world IMHO (FWIW) ...
And there is *a lot* more of that if you are root.
WTF - that actually is the job definition of root/administrator/
supervisor/... to be able to fix (almost) everything and that implies
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
On Tue, 2017-06-13 at 10:40 -0700, Darren Hart wrote:
[...]
> There are plenty of other examples of things you can do to screw up the
> state of your system if you have the right permissions for which the
> answer is "don't do that". Consider MEM(4), SETPCI(8), ... /dev/sda ...
> for example.
So what is the problem?!
And that pretty much answers it for the Unix world IMHO (FWIW) ...
And there is *a lot* more of that if you are root.
WTF - that actually is the job definition of root/administrator/
supervisor/... to be able to fix (almost) everything and that implies
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
On Thu, 2017-05-25 at 03:35 -0700, Joe Perches wrote: > On Wed, 2017-05-24 at 13:18 +0300, Alexey Dobriyan wrote: > > Proper fix is to introduce typed allocation macros with the following > > signatures: > > > > T* lmalloc(T, gfp); Ack (FWIW). [...] > > struct foo *x; > > x = lmalloc(struct foo, GFP_KERNEL); > > Then code would be written > > x = lmalloc(typeof(*x), GFP_KERNEL); At least it is correct and changes automagically if x changes the type which struct bar *x; x = kmalloc(sizeof(struct foo), 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
On Thu, 2017-05-25 at 03:35 -0700, Joe Perches wrote: > On Wed, 2017-05-24 at 13:18 +0300, Alexey Dobriyan wrote: > > Proper fix is to introduce typed allocation macros with the following > > signatures: > > > > T* lmalloc(T, gfp); Ack (FWIW). [...] > > struct foo *x; > > x = lmalloc(struct foo, GFP_KERNEL); > > Then code would be written > > x = lmalloc(typeof(*x), GFP_KERNEL); At least it is correct and changes automagically if x changes the type which struct bar *x; x = kmalloc(sizeof(struct foo), 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
On Mon, 2017-01-23 at 10:48 +0100, SF Markus Elfring wrote: [...] > > The others are useless churn or they make the result uselessly > > different from the rest of KVM code. > > I got an other view about potential benefits around the suggested > movements for error 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 : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: KVM: Fine-tuning for several function implementations
On Mon, 2017-01-23 at 10:48 +0100, SF Markus Elfring wrote: [...] > > The others are useless churn or they make the result uselessly > > different from the rest of KVM code. > > I got an other view about potential benefits around the suggested > movements for error 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 : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: MD-RAID: Use seq_putc() in three status functions?
On Mon, 2016-10-17 at 13:10 +0200, SF Markus Elfring wrote: [...] > > (Which up to now I thought was basic programming knowledge...) > > By the way: > Run time environments still exist where the size of a pointer can > be also just one byte, don't they? In the context of the Linux kernel: No. [ Side note: there might be some DSP out there with a running Linux kernel which cannot really address a "byte" (meaning 8bits) but only in register sized quantities (and also aligned for that). But no one cares here really deeply as that is a so fundamental difference that the C- compiler must cope with that anyways in the first place. ] [...] > > See above. At the moment _any_ test result from your side would do. > > I imagine that another single result might not be representative. Publish not only results but also everything (complete!) so that 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?
On Mon, 2016-10-17 at 13:10 +0200, SF Markus Elfring wrote: [...] > > (Which up to now I thought was basic programming knowledge...) > > By the way: > Run time environments still exist where the size of a pointer can > be also just one byte, don't they? In the context of the Linux kernel: No. [ Side note: there might be some DSP out there with a running Linux kernel which cannot really address a "byte" (meaning 8bits) but only in register sized quantities (and also aligned for that). But no one cares here really deeply as that is a so fundamental difference that the C- compiler must cope with that anyways in the first place. ] [...] > > See above. At the moment _any_ test result from your side would do. > > I imagine that another single result might not be representative. Publish not only results but also everything (complete!) so that 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()
Hi all! On Thu, 2016-10-06 at 19:49 +0200, SF Markus Elfring wrote: > > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c > > > > [] > > > > > > > > > > @@ -7044,7 +7044,7 @@ static void raid5_status(struct > > > > > seq_file *seq, struct mddev *mddev) > > > > > rdev && test_bit(In_sync, > > > > > >flags) ? "U" : "_"); > > > > > } > > > > > rcu_read_unlock(); > > > > > - seq_printf (seq, "]"); > > > > > + seq_puts(seq, "]"); > > > > seq_putc > > > How do you think about the possibility that the script > > > "checkpatch.pl" can also point > > > such a source code transformation out directly? > > > > 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"? The above is BTW a pretty simple thing and thus good for a learning experience for regular expressions and copy-pasting a few lines in that perl-script and editing them. MfG, Bernd PS: Sry for the noise - it's somewhat OT here -- 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()
Hi all! On Thu, 2016-10-06 at 19:49 +0200, SF Markus Elfring wrote: > > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c > > > > [] > > > > > > > > > > @@ -7044,7 +7044,7 @@ static void raid5_status(struct > > > > > seq_file *seq, struct mddev *mddev) > > > > > rdev && test_bit(In_sync, > > > > > >flags) ? "U" : "_"); > > > > > } > > > > > rcu_read_unlock(); > > > > > - seq_printf (seq, "]"); > > > > > + seq_puts(seq, "]"); > > > > seq_putc > > > How do you think about the possibility that the script > > > "checkpatch.pl" can also point > > > such a source code transformation out directly? > > > > 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"? The above is BTW a pretty simple thing and thus good for a learning experience for regular expressions and copy-pasting a few lines in that perl-script and editing them. MfG, Bernd PS: Sry for the noise - it's somewhat OT here -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
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 that case but personally, I use that style to explicit list all enum/#define values so that it is obvious that none was forgotten. For the compiler output, it shouldn't matter anyways ... MfG, Bernd -- mobile: +43 664 4416156 http://www.sysprog.at/ Linux Software Development, Consulting and Services
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 that case but personally, I use that style to explicit list all enum/#define values so that it is obvious that none was forgotten. For the compiler output, it shouldn't matter anyways ... MfG, Bernd -- mobile: +43 664 4416156 http://www.sysprog.at/ Linux Software Development, Consulting and Services
Re: script relative shebang
Hi all!
On Wed, 2016-06-01 at 09:00 +0100, Boris wrote:
[...]
> Yes, I think this is too ugly:
>
> #!/usr/bin/gawk {exit system("/bin/sh -c 'exec \"$(dirname
> \"$0\")\"/subdir/catself \"$0\"' " FILENAME);}
The simplest solution for an application today is to provide a wrapper
script/program (to be placed in /usr/bin or /usr/local/bin) which knows
where to search for the applications executables - if adding some
directories to $PATH is not enough.
> Imagine you have that feature in your kernel would you rather use:
>
> #!{dirname}/subdir/catself
And what if "{dirname}" (or any other character sequence) happens to be
a valid pathname?
> You second advice involves changing root fs which is not desirable in
> copy-deployment apps (bring all the dependencies)
>
> This more about making kernel "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
Hi all!
On Wed, 2016-06-01 at 09:00 +0100, Boris wrote:
[...]
> Yes, I think this is too ugly:
>
> #!/usr/bin/gawk {exit system("/bin/sh -c 'exec \"$(dirname
> \"$0\")\"/subdir/catself \"$0\"' " FILENAME);}
The simplest solution for an application today is to provide a wrapper
script/program (to be placed in /usr/bin or /usr/local/bin) which knows
where to search for the applications executables - if adding some
directories to $PATH is not enough.
> Imagine you have that feature in your kernel would you rather use:
>
> #!{dirname}/subdir/catself
And what if "{dirname}" (or any other character sequence) happens to be
a valid pathname?
> You second advice involves changing root fs which is not desirable in
> copy-deployment apps (bring all the dependencies)
>
> This more about making kernel "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 usual solution is to have a preprocessor symbol to allow people with lots of time and/or "valgrind" and similar tools to clean up cleanly and the speed gang can compile that code out. Kind regards, Bernd -- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 solution is to have a preprocessor symbol to allow people with lots of time and/or valgrind and similar tools to clean up cleanly and the speed gang can compile that code out. Kind regards, Bernd -- I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong. - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 in the past. [...] Does it make sense(Is it enough to filter the changes to only include changes from the last 6 months or so (if there are newer changes;-)? People probably don't care if they didn't touch it for ages anyway. Or ignore changes which touch only a few lines completely (to not include typo fixes or trivial fixups)? Kind regards, Bernd -- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 in the past. [...] Does it make sense(Is it enough to filter the changes to only include changes from the last 6 months or so (if there are newer changes;-)? People probably don't care if they didn't touch it for ages anyway. Or ignore changes which touch only a few lines completely (to not include typo fixes or trivial fixups)? Kind regards, Bernd -- I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong. - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 or use something else or whatever). Usually this makes > app developers a little cranky because something that was going to be > easy in their mind just got harder. Perhaps these developers should rethink the design and protocols of their apps - or pay the price for a stupid design which relies on heavy IPC traffic (and usually - sooner or later - heavy network traffic). Or - at least - deliver a (technical!) proof why this isn't feasible. The case of "patching the kernel to lie about the kernel's command line" just because some ill-designed user-space daemon misused it" was bad enough and the above smells quite similarly. Kind regards, Bernd -- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 or use something else or whatever). Usually this makes app developers a little cranky because something that was going to be easy in their mind just got harder. Perhaps these developers should rethink the design and protocols of their apps - or pay the price for a stupid design which relies on heavy IPC traffic (and usually - sooner or later - heavy network traffic). Or - at least - deliver a (technical!) proof why this isn't feasible. The case of patching the kernel to lie about the kernel's command line just because some ill-designed user-space daemon misused it was bad enough and the above smells quite similarly. Kind regards, Bernd -- I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong. - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 unprooved
number of cases.
> I would challenge that assumption, *especially* in the context of kernel
> programming. Let's not waste time on that crap.
Even if the assumption is correct (which I'm not implying - quite the
opposite), than these programmers are not well educated enough and -
thus;-) - write buggy code. They also fail to strive for mot possible
robustness.
BTW POSIX' strcmp() description on
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strcmp.html
als states "> 0, == 0 or < 0" (and ISO-C seem to also see it that way).
Kind regards,
Bernd
--
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 unprooved
number of cases.
I would challenge that assumption, *especially* in the context of kernel
programming. Let's not waste time on that crap.
Even if the assumption is correct (which I'm not implying - quite the
opposite), than these programmers are not well educated enough and -
thus;-) - write buggy code. They also fail to strive for mot possible
robustness.
BTW POSIX' strcmp() description on
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strcmp.html
als states 0, == 0 or 0 (and ISO-C seem to also see it that way).
Kind regards,
Bernd
--
I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong.
- Linus Torvalds
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong.
- Linus Torvalds
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 divides Use `bc -l`;-) snip 2^32 / 1000 / 86400 49.71026962962962962962 snip Bernd -- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 divides Use `bc -l`;-) snip 2^32 / 1000 / 86400 49.71026962962962962962 snip Bernd -- I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong. - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 periodically require entropy. Now I run out of descriptors. I > > > can't establish new connections. but I should > > > now halt all the other ones that require entropy? I should raise > > > SIGKILL on my process serving these thousands > > > of connetions? I don't think so. > > > > If that long-running daemon periodically needs something from a device, > > one would better keep the fd for that open the whole time. Saves some > > CPU cycles and latency too BTW. > > Agreed. > > On the other hand, keeping a fd open is quite tricky for a > library. But better solution might be to make that easier. Yes, in a (full-fledged, standalone) library seems at least tricky (also referring to some off-list mails here: think about fork() - which could be inside system() or popen() or similar). But as part of the *application* (where one has control over fork() etc.), this should be somewhat less risky. Yes, that doesn't really help libssl;-) Hehe, we (Unix!) have (had) gettimeofday(), time() and similar sys-calls since ages and no one proposed to make devices for them and get rid of the system-calls. > open( , O_IM_A_LIBRARY_GIVE_ME_ONE_OF_THREE_RESERVED_FDS) might be one > solution. Actually, one reserved fd should be enough. Well, this can also be DoSed and the proposal aims to make that impossible (and where does this reserved count against? process-limits, kernel-wide limit?). Bernd -- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 periodically require entropy. Now I run out of descriptors. I can't establish new connections. but I should now halt all the other ones that require entropy? I should raise SIGKILL on my process serving these thousands of connetions? I don't think so. If that long-running daemon periodically needs something from a device, one would better keep the fd for that open the whole time. Saves some CPU cycles and latency too BTW. Agreed. On the other hand, keeping a fd open is quite tricky for a library. But better solution might be to make that easier. Yes, in a (full-fledged, standalone) library seems at least tricky (also referring to some off-list mails here: think about fork() - which could be inside system() or popen() or similar). But as part of the *application* (where one has control over fork() etc.), this should be somewhat less risky. Yes, that doesn't really help libssl;-) Hehe, we (Unix!) have (had) gettimeofday(), time() and similar sys-calls since ages and no one proposed to make devices for them and get rid of the system-calls. open( , O_IM_A_LIBRARY_GIVE_ME_ONE_OF_THREE_RESERVED_FDS) might be one solution. Actually, one reserved fd should be enough. Well, this can also be DoSed and the proposal aims to make that impossible (and where does this reserved count against? process-limits, kernel-wide limit?). Bernd -- I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong. - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 the other ones that require entropy? I should raise > SIGKILL on my process serving these thousands > of connetions? I don't think so. If that long-running daemon periodically needs something from a device, one would better keep the fd for that open the whole time. Saves some CPU cycles and latency too BTW. Bernd -- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 the other ones that require entropy? I should raise SIGKILL on my process serving these thousands of connetions? I don't think so. If that long-running daemon periodically needs something from a device, one would better keep the fd for that open the whole time. Saves some CPU cycles and latency too BTW. Bernd -- I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong. - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - otherwise there is no way to
address 32bit ("short int" is usually 16 bit).
Bernd
--
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 - otherwise there is no way to address 32bit (short int is usually 16 bit). Bernd -- I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong. - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 keeps the last mails from the thread around and they also can be founds in public archives. Bernd -- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 keeps the last mails from the thread around and they also can be founds in public archives. Bernd -- I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong. - Linus Torvalds -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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, struct
> task_struct *p)
> {
> s64 delta = p->dl.dl_runtime - p->dl.runtime;
This line can be removed as well (an then we have a one-line
function ).
> - if (delta > 1)
> - hrtick_start(rq, p->dl.runtime);
> + hrtick_start(rq, p->dl.runtime);
> }
> #endif
Bernd
--
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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, struct
task_struct *p)
{
s64 delta = p-dl.dl_runtime - p-dl.runtime;
This line can be removed as well (an then we have a one-line
function ).
- if (delta 1)
- hrtick_start(rq, p-dl.runtime);
+ hrtick_start(rq, p-dl.runtime);
}
#endif
Bernd
--
I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong.
- Linus Torvalds
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 > >> for opportunities to replace a call to memcpy by a struct assignment. > >> This patch removes memcpy-assign.cocci as it is not clear that this > >> convention has an impact on the generated code. > > > > Using struct assignment keeps the type check and is just for this reason > > always preferable over memcpy(). > What about the assignment hiding that a potentially large memcpy is > happening instead of just a pointer assignment? It makes no difference if you copy 2KB with a struct assignment or with a memcpy(). IMHO most probably each and every C compiler produces the same code for both cases. And - more important - I assume that people which actually read the code (to understand the code) also know if the variables there are pointers/ints or a (somewhat large) struct (if only one see an field access in the struct, it should be pretty clear). I don't think it makes actually much sense trying to read source without that 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Coccicheck: Remove memcpy to struct assignment test
On Die, 2014-03-18 at 22:11 +0100, Peter Senna Tschudin wrote:
> The Coccinelle script scripts/coccinelle/misc/memcpy-assign.cocci look
> for opportunities to replace a call to memcpy by a struct assignment.
> This patch removes memcpy-assign.cocci as it is not clear that this
> convention 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://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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Coccicheck: Remove memcpy to struct assignment test
On Die, 2014-03-18 at 22:11 +0100, Peter Senna Tschudin wrote: The Coccinelle script scripts/coccinelle/misc/memcpy-assign.cocci look for opportunities to replace a call to memcpy by a struct assignment. This patch removes memcpy-assign.cocci as it is not clear that this convention 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://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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 for opportunities to replace a call to memcpy by a struct assignment. This patch removes memcpy-assign.cocci as it is not clear that this convention has an impact on the generated code. Using struct assignment keeps the type check and is just for this reason always preferable over memcpy(). What about the assignment hiding that a potentially large memcpy is happening instead of just a pointer assignment? It makes no difference if you copy 2KB with a struct assignment or with a memcpy(). IMHO most probably each and every C compiler produces the same code for both cases. And - more important - I assume that people which actually read the code (to understand the code) also know if the variables there are pointers/ints or a (somewhat large) struct (if only one see an field access in the struct, it should be pretty clear). I don't think it makes actually much sense trying to read source without that 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] tpm/tpm_ppi: Do not compare strcmp(a,b) == -1
Hi all! On Mit, 2013-10-30 at 12:41 -0700, Joe Perches wrote: [...] > The arch/... assembly versions don't always > return -1, 0, 1 so I don't think it's worth > it to change all of those. FWIW user-space strcmp() - e.g. as in http://pubs.opengroup.org/onlinepubs/009695399/functions/strcmp.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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] tpm/tpm_ppi: Do not compare strcmp(a,b) == -1
Hi all! On Mit, 2013-10-30 at 12:41 -0700, Joe Perches wrote: [...] The arch/... assembly versions don't always return -1, 0, 1 so I don't think it's worth it to change all of those. FWIW user-space strcmp() - e.g. as in http://pubs.opengroup.org/onlinepubs/009695399/functions/strcmp.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-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: checkpatch.pl "uninitialized value"
Hi! On Mon, 2013-01-14 at 14:42 +0100, Schrober wrote: [...] > it seems the current version of checkpatch.pl in linux-next ist broken. I get > a lot of > > Use of uninitialized value $ms_size in pattern match (m//) at > ./scripts/checkpatch.pl line 3383. > Use of uninitialized value $ms_size in pattern match (m//) at > ./scripts/checkpatch.pl line 3386. > Use of uninitialized value $ms_size in pattern match (m//) at > ./scripts/checkpatch.pl line 3383. > Use of uninitialized value $ms_size in pattern match (m//) at > ./scripts/checkpatch.pl line 3386. > Use of uninitialized value $ms_size in pattern match (m//) at > ./scripts/checkpatch.pl line 3383. > Use of uninitialized value $ms_size in pattern match (m//) at > ./scripts/checkpatch.pl line 3386. on which file? If you would have added the command line to trivially reproduce 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" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: checkpatch.pl uninitialized value
Hi! On Mon, 2013-01-14 at 14:42 +0100, Schrober wrote: [...] it seems the current version of checkpatch.pl in linux-next ist broken. I get a lot of Use of uninitialized value $ms_size in pattern match (m//) at ./scripts/checkpatch.pl line 3383. Use of uninitialized value $ms_size in pattern match (m//) at ./scripts/checkpatch.pl line 3386. Use of uninitialized value $ms_size in pattern match (m//) at ./scripts/checkpatch.pl line 3383. Use of uninitialized value $ms_size in pattern match (m//) at ./scripts/checkpatch.pl line 3386. Use of uninitialized value $ms_size in pattern match (m//) at ./scripts/checkpatch.pl line 3383. Use of uninitialized value $ms_size in pattern match (m//) at ./scripts/checkpatch.pl line 3386. on which file? If you would have added the command line to trivially reproduce 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 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC GIT PULL] "Nuke 386-DX/SX support" changes for v3.8
On Mit, 2012-12-12 at 11:00 -0800, H. Peter Anvin wrote: [...] > There were a *bunch* of embedded 486 clones made, some still in > production as far as I know, and I wouldn't be surprised if some of them > lacked FPU. I guess we'll see. And there is an x86 emulator written in Javascript 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 the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC GIT PULL] Nuke 386-DX/SX support changes for v3.8
On Mit, 2012-12-12 at 11:00 -0800, H. Peter Anvin wrote: [...] There were a *bunch* of embedded 486 clones made, some still in production as far as I know, and I wouldn't be surprised if some of them lacked FPU. I guess we'll see. And there is an x86 emulator written in Javascript 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 the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer
On Fre, 2012-09-14 at 16:25 +0200, Jan Engelhardt wrote: > On Friday 2012-09-14 15:46, Jim Rees wrote: > >Jan Engelhardt wrote: > > >A pure K version would use a string: > > >#define base10len(i) > > "\0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14"[sizeof(i)] > > >(if I converted them properly into hexadecimal) > > The syntax is \x01\x03\x05... > > > >K doesn't have the \x escape, only \0 (octal). We cuold use octal too. > People recommend K only for the introductory reading, not for its > actuality. And I 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 them properly into hexadecimal) and that gives a "char"
> which is happily promoted to whatever one needs in that place.
>
> 1. That may give you a signed char on some architectures, which is not what
> you want (although it doesn't matter since the values are all < 128)
And it depends on compiler options BTW.
But we can easily cast it:
#define base10len(i) ((unsigned char)"\x1\x3\x5\x8\xA\xD\xF\x11\x14"[sizeof(i)])
> 2. If you put this in a .h, you'll get multiple copies of the array
That depends on the compiler.
> 3. No bounds checking (but in ninja K style you never check bounds)
Well, I assumed that we don't use VLAs as parameter for the sizeof() so
the value is compile time known and the better C compilers can check it.
And then, there is no reason to store the string as such too.
[]
> Pure K:
We can (and should) make it "const" too.
> base10.h:
> extern unsigned char base10len_vals[];
extern const unsigned char base10len_vals[];
> #define base10len(i) (base10len_vals[sizeof(i)])
>
> base10.c:
> unsigned char base10len_vals[] = {1,3,5,8,10,13,15,17,20};
const unsigned char base10len_vals[] = {1,3,5,8,10,13,15,17,20};
> But I still like my way better.
The 8 wasted bytes probably do not matter
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer
On Mon, 2012-09-10 at 08:19 +0200, Jan Engelhardt wrote:
> On Tuesday 2012-08-21 23:29, J. Bruce Fields wrote:
[...]
> >+/*
> >+ * length of the decimal representation of an unsigned integer. Just an
> >+ * approximation, but it's right for types of size 1 to 36 bytes:
> >+ */
> >+#define base10len(i) (sizeof(i) * 24 / 10 + 1)
>
> gcc provides... "interesting" features at times.
>
> /* for unsigned "i"s */
> #define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[i])
Shouldn't that have been
snip
#define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[sizeof(i)])
snip
?
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 them properly into hexadecimal) and that gives 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 "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer
On Mon, 2012-09-10 at 08:19 +0200, Jan Engelhardt wrote:
On Tuesday 2012-08-21 23:29, J. Bruce Fields wrote:
[...]
+/*
+ * length of the decimal representation of an unsigned integer. Just an
+ * approximation, but it's right for types of size 1 to 36 bytes:
+ */
+#define base10len(i) (sizeof(i) * 24 / 10 + 1)
gcc provides... interesting features at times.
/* for unsigned is */
#define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[i])
Shouldn't that have been
snip
#define base10len(i) ((const int[]){1,3,5,8,10,13,15,17,20}[sizeof(i)])
snip
?
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) and that gives 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 unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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) and that gives a char
which is happily promoted to whatever one needs in that place.
1. That may give you a signed char on some architectures, which is not what
you want (although it doesn't matter since the values are all 128)
And it depends on compiler options BTW.
But we can easily cast it:
#define base10len(i) ((unsigned char)\x1\x3\x5\x8\xA\xD\xF\x11\x14[sizeof(i)])
2. If you put this in a .h, you'll get multiple copies of the array
That depends on the compiler.
3. No bounds checking (but in ninja KR style you never check bounds)
Well, I assumed that we don't use VLAs as parameter for the sizeof() so
the value is compile time known and the better C compilers can check it.
And then, there is no reason to store the string as such too.
[]
Pure KR:
We can (and should) make it const too.
base10.h:
extern unsigned char base10len_vals[];
extern const unsigned char base10len_vals[];
#define base10len(i) (base10len_vals[sizeof(i)])
base10.c:
unsigned char base10len_vals[] = {1,3,5,8,10,13,15,17,20};
const unsigned char base10len_vals[] = {1,3,5,8,10,13,15,17,20};
But I still like my way better.
The 8 wasted bytes probably do not matter
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] strings: helper for maximum decimal encoding of an unsigned integer
On Fre, 2012-09-14 at 16:25 +0200, Jan Engelhardt wrote: On Friday 2012-09-14 15:46, Jim Rees wrote: Jan Engelhardt wrote: A pure KR-C version would use a string: #define base10len(i) \0x1\0x3\0x5\0x8\0x0A\0x0D\0x0F\0x11\0x14[sizeof(i)] (if I converted them properly into hexadecimal) The syntax is \x01\x03\x05... KR doesn't have the \x escape, only \0 (octal). We cuold use octal too. People recommend KR only for the introductory reading, not for its actuality. And I 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-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why exported const value modified by another driver not updated in original driver
Hi! On Die, 2012-09-04 at 15:00 +0530, Manavendra Nath Manav wrote: [] > I have declared a static const int variable in one driver and exported > that variable symbol. Exporting a "static" variable makes conceptually no sense whatsoever - either you want it exported (so you should remove the "static") or you want it not exported - which is precisely the definition of "static". > retains the original value. When both virtual and physical addresses > of the variable as seen by both drivers are same, how is this even > possible. Is it a kernel bug? It's a bug in your drivers. The C compiler sees an initialized "static const" variable. So the C compiler knows that it is not accessible from other compilation units (because it is "static") and the variable isn't changing within the current compilation unit (because the variable as such is "const" and their is no non-const pointer to it or similar). Since this is the only compilation unit, it knows that no one will/can change it's value. So the C compiler happily replaces all references to the variable with it's value - just as if you would have #define'd that value. Obviously, later on it is exported and the variable actually exists and you can change it in the other file. But since the value has been replaced literally by "123" at compile (more precise: optimizer time), you don't see a change in the printk()s. > Interestingly, when i change the declaration of variable to "volatile" > in driver.c as "static const volatile int" then the driver.ko prints > modified value "987" during rmmod and the original value "123" is > lost. What is the difference between this and previous declaration? "volatile" tells the C compiler that a variable may change it's value without explicit code. A typical use case are hardware registers which are changed by the underlying hardware. In user space, variables may be modified by signal handlers (which can occur at any time in a program - unless specifcally blocked). So the optimizer must not accesses to "volatile" variables because they may change their value at any time. > Please forgive if you find this question silly? That all is actually pure (K)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 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why exported const value modified by another driver not updated in original driver
Hi! On Die, 2012-09-04 at 15:00 +0530, Manavendra Nath Manav wrote: [] I have declared a static const int variable in one driver and exported that variable symbol. Exporting a static variable makes conceptually no sense whatsoever - either you want it exported (so you should remove the static) or you want it not exported - which is precisely the definition of static. retains the original value. When both virtual and physical addresses of the variable as seen by both drivers are same, how is this even possible. Is it a kernel bug? It's a bug in your drivers. The C compiler sees an initialized static const variable. So the C compiler knows that it is not accessible from other compilation units (because it is static) and the variable isn't changing within the current compilation unit (because the variable as such is const and their is no non-const pointer to it or similar). Since this is the only compilation unit, it knows that no one will/can change it's value. So the C compiler happily replaces all references to the variable with it's value - just as if you would have #define'd that value. Obviously, later on it is exported and the variable actually exists and you can change it in the other file. But since the value has been replaced literally by 123 at compile (more precise: optimizer time), you don't see a change in the printk()s. Interestingly, when i change the declaration of variable to volatile in driver.c as static const volatile int then the driver.ko prints modified value 987 during rmmod and the original value 123 is lost. What is the difference between this and previous declaration? volatile tells the C compiler that a variable may change it's value without explicit code. A typical use case are hardware registers which are changed by the underlying hardware. In user space, variables may be modified by signal handlers (which can occur at any time in a program - unless specifcally blocked). So the optimizer must not accesses to volatile variables because they may change their value at any time. Please forgive if you find 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 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Drop support for x86-32
On Sam, 2012-08-25 at 19:38 +0200, wbrana wrote: [] > You can temporary unsubscribe from LKML and read archives [] > People care because they replied to my e-mails. You obviously didn't read these mails, didn't understand it, purposely misread or purposely ignored them (and answer with a lot of unrelated questions) - for whatever reason. And yes, people care that anyone might listen to the unfounded stuff you are writing. You delivered only some stories about the future and not one argument (let alone a convincing one). And you are promising a lot of service in a few years 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: 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Drop support for x86-32
On Sam, 2012-08-25 at 19:38 +0200, wbrana wrote: [] You can temporary unsubscribe from LKML and read archives [] People care because they replied to my e-mails. You obviously didn't read these mails, didn't understand it, purposely misread or purposely ignored them (and answer with a lot of unrelated questions) - for whatever reason. And yes, people care that anyone might listen to the unfounded stuff you are writing. You delivered only some stories about the future and not one argument (let alone a convincing one). And you are promising a lot of service in a few years 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: 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
