This merge window felt a lot more normal than 5.8, and all the stats
confirm thar it seems to be the usual size.
The only thing that stands out is yet another AMD GPU header file
drop, but by now that almost counts as "usual" too. It does mean that
the diff stats are dominated by those AMD updates, and almost exactly
half of the diff is under drivers/gpu/drm/amd/, but it's the usual big
register definitions (presumably once more generated from the hw
files) and doesn't really matter in the big picture.
If you ignore that, stats look very normal. Even ignoring the AMD GPU
updates, drivers are still about 60% of the patch, and it's all over.
Outside of drivers, it's the usual mix of architecture updates,
documentation, core networking, tooling and filesystem updates.
"Normal size" is still obviously pretty big, so the appended is just
my merge-log as usual. For details, dig down into whichever area
excites you in the git tree...
Linus
---
Al Viro (6):
ptrace regset updates
init and set_fs() cleanups
fdpick coredump update
mount leak fix
misc vfs updates
regset conversion fix
Alex Williamson (1):
VFIO updates
Alexandre Belloni (1):
RTC updates
Andreas Gruenbacher (1):
gfs2 updates
Andrew Morton (3):
misc updates
more updates
even more updates
Andy Shevchenko (1):
x86 platform driver updates
Arnaldo Carvalho de Melo (2):
perf tools updates
more perf tools updates
Arnd Bergmann (5):
ARM defconfig updates
ARM SoC DT updates
ARM SoC updates
ARM SoC driver updates
new ARM SoC support
Benson Leung (1):
chrome platform updates
Bjorn Andersson (3):
rpmsg update
remoteproc updates
hwspinlock updates
Bjorn Helgaas (1):
PCI updates
Casey Schaufler (1):
smack updates
Catalin Marinas (3):
arm64 and cross-arch updates
arm64 fixes
arm64 fix
Christian Brauner (4):
thread updates
fork cleanups
checkpoint-restore updates
close_range() implementation
Christoph Hellwig (2):
uuid update
dma-mapping updates
Chuck Lever (1):
NFS server updates
Corey Minyard (1):
IPMI updates
Damien Le Moal (1):
zonefs update
Daniel Lezcano (1):
thermal updates
Darrick Wong (3):
iomap updates
xfs updates
xfs fixes
Dave Airlie (2):
drm updates
drm fixes
David Miller (2):
networking updates
networking fixes
David Sterba (2):
btrfs updates
more btrfs updates
David Teigland (1):
dlm updates
Dmitry Torokhov (1):
input updates
Dominique Martinet (1):
9p updates
Eric Biederman (1):
execve updates
Eric Biggers (2):
fscrypt updates
fsverity update
Gao Xiang (1):
erofs updates
Geert Uytterhoeven (1):
m68k updates
Greg KH (5):
char/misc driver updates
driver core updates
USB/Thunderbolt updates
staging/IIO driver updates
tty/serial updates
Greg Ungerer (1):
m68knommu updates
Guenter Roeck (1):
hwmon updates
Guo Ren (1):
arch/csky updates
Heiko Carstens (2):
s390 updates
more s390 updates
Helge Deller (2):
parisc updates
more parisc updates
Herbert Xu (2):
crypto updates
crypto fix
Ilya Dryomov (1):
ceph updates
Ingo Molar (1):
x86 cpu updates
Ingo Molnar (26):
irq fixes
debugobjects cleanup
header cleanup
RCU updates
locking updates
objtool updates
perf event updates
scheduler updates
x86/alternatives update
x86 asm updates
x86 boot updates
x86 build updates
x86 cleanups
x86 debug fixlets
x86 FPU selftest
x86 microcode update
x86 MSR filtering
x86 mmm update
x86 platform updates
x86 timer update
x86 RAS updates
sched/fifo updates
locking fixlets
perf fixes
scheduler fixes
x86 fixes
Jaegeuk Kim (1):
f2fs updates
James Bottomley (2):
SCSI updates
more SCSI updates
James Morris (1):
security subsystem updates
Jan Kara (2):
ext2, udf, reiserfs, quota cleanups and minor fixes
fsnotify updates
Jarkko Sakkinen (1):
tpm updates
Jason Gunthorpe (2):
hmm updates
rdma updates
Jassi Brar (1):
mailbox updates
Jeff Layton (1):
file locking fix
Jens Axboe (6):
core block updates
io_uring updates
block driver updates
block stacking updates
block fixes
io_uring fixes
Jessica Yu (1):
module updates
Jiri Kosina (1):
HID updates
Joerg Roedel (1):
iommu updates
Jonathan Corbet (2):
documentation updates
documentation fixes
Juergen Gross (2):
xen updates
more xen updates
Julia Lawall (1):
coccinelle updates
Kees Cook (8):
pstore update
gcc plugin updates
automatic variable initialization updates
tasklets API update
uninitialized_var() macro removal
seccomp updates
seccomp fix
sysfs module section fix
Lee Jones (2):
backlight updates
MFD updates
Linus Walleij (2):
GPIO updates
pin control updates
Mark Brown (3):
regulator updates
spi updates
regmap updates
Masahiro Yamada (2):
Kbuild updates
Kconfig updates
Mauro Carvalho Chehab (1):
media updates
Max Filippov (1):
Xtensa updates
Michael Ellerman (2):
powerpc updates
powerpc fix
Michael Tsirkin (1):
virtio updates
Miguel Ojeda (1):
auxdisplay update
Mike Marshall (1):
orangefs updates
Mike Rapoport (1):
unicore32 removal
Mike Snitzer (1):
device mapper updates
Mimi Zohar (1):
integrity updates
Miquel Raynal (1):
mtd updates
Namjae Jeon (1):
exfat updates
Palmer Dabbelt (2):
RISC-V updates
RISC-V fix
Paolo Bonzini (2):
KVM updates
more KVM updates
Paul Moore (2):
selinux updates
audit updates
Pavel Machek (1):
LED updates
Petr Mladek (2):
printk updates
livepatching updates
Rafael Wysocki (5):
power management updates
ACPI updates
more power management updates
one more power management update
more ACPI updates
Rich Felker (1):
arch/sh updates
Richard Weinberger (2):
mtd fix
JFFS2, UBI and UBIFS updates
Rob Herring (2):
Devicetree updates
devicetree fixes
Russell King (1):
ARM updates
Sebastian Reichel (1):
power supply and reset updates
Shuah Khan (1):
kunit updates
Stafford Horne (1):
OpenRISC updates
Stephen Boyd (2):
clk updates
more clk updates
Steve French (2):
cifs updates
cifs fixes
Steven Rostedt (2):
tracing updates
ktest updates
Takashi Iwai (2):
sound updates
sound fixes
Thierry Reding (1):
pwm updates
Thomas Bogendoerfer (1):
MIPS upates
Thomas Gleixner (9):
irq updates
timer updates
generic kernel entry/exit code
x86 conversion to generic entry code
x86 fsgsbase
locking updates
irq fixes
more timer updates
timekeeping updates
Tony Luck (2):
EDAC updates
edac fix
Trond Myklebust (1):
NFS client updates
Ulf Hansson (1):
MMC updates
Vinod Koul (1):
dmaengine updates
Vishal Verma (1):
libnvdimm updayes
Wei Liu (2):
hyperv updates
hyper-v fixes
Wim Van Sebroeck (1):
watchdog updates
Wolfram Sang (1):
i2c updates
On 13:50 Sun 16 Aug 2020, Linus Torvalds wrote:
>This merge window felt a lot more normal than 5.8, and all the stats
>confirm thar it seems to be the usual size.
>
>The only thing that stands out is yet another AMD GPU header file
>drop, but by now that almost counts as "usual" too. It does mean that
>the diff stats are dominated by those AMD updates, and almost exactly
>half of the diff is under drivers/gpu/drm/amd/, but it's the usual big
>register definitions (presumably once more generated from the hw
>files) and doesn't really matter in the big picture.
>
>If you ignore that, stats look very normal. Even ignoring the AMD GPU
>updates, drivers are still about 60% of the patch, and it's all over.
>Outside of drivers, it's the usual mix of architecture updates,
>documentation, core networking, tooling and filesystem updates.
>
>"Normal size" is still obviously pretty big, so the appended is just
>my merge-log as usual. For details, dig down into whichever area
>excites you in the git tree...
>
> Linus
>
I am scared that I might have missed something very obvious ...am I?? And the build abort...take a peek..
In file included from ./include/linux/scatterlist.h:9,
from ./include/linux/blkdev.h:25,
from ./include/linux/blk-cgroup.h:23,
from ./include/linux/writeback.h:14,
from ./include/linux/memcontrol.h:22,
from ./include/linux/swap.h:9,
from ./include/linux/suspend.h:5,
from arch/x86/kernel/asm-offsets.c:13:
./arch/x86/include/asm/io.h: In function ‘outb_p’:
./arch/x86/include/asm/io.h:292:2: error: implicit declaration of function ‘slow_down_io’ [-Werror=implicit-function-declaration]
slow_down_io(); \
^~~~~~~~~~~~
./arch/x86/include/asm/io.h:334:1: note: in expansion of macro ‘BUILDIO’
BUILDIO(b, b, char)
^~~~~~~
In file included from ./arch/x86/include/asm/suspend_64.h:10,
from ./arch/x86/include/asm/suspend.h:5,
from arch/x86/kernel/asm-offsets.c:19:
./arch/x86/include/asm/desc.h: In function ‘__set_tss_desc’:
./arch/x86/include/asm/desc.h:186:2: error: implicit declaration of function ‘write_gdt_entry’; did you mean ‘find_get_entry’? [-Werror=implicit-function-declaration]
write_gdt_entry(d, entry, &tss, DESC_TSS);
^~~~~~~~~~~~~~~
find_get_entry
./arch/x86/include/asm/desc.h: In function ‘force_reload_TR’:
./arch/x86/include/asm/desc.h:296:2: error: implicit declaration of function ‘load_TR_desc’; did you mean ‘local_dec’? [-Werror=implicit-function-declaration]
load_TR_desc();
^~~~~~~~~~~~
local_dec
./arch/x86/include/asm/desc.h: In function ‘clear_LDT’:
./arch/x86/include/asm/desc.h:358:2: error: implicit declaration of function ‘set_ldt’; did you mean ‘set_bit’? [-Werror=implicit-function-declaration]
set_ldt(NULL, 0);
^~~~~~~
set_bit
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:117: arch/x86/kernel/asm-offsets.s] Error 1
~Bhaskar
>---
>
>Al Viro (6):
> ptrace regset updates
> init and set_fs() cleanups
> fdpick coredump update
> mount leak fix
> misc vfs updates
> regset conversion fix
>
>Alex Williamson (1):
> VFIO updates
>
>Alexandre Belloni (1):
> RTC updates
>
>Andreas Gruenbacher (1):
> gfs2 updates
>
>Andrew Morton (3):
> misc updates
> more updates
> even more updates
>
>Andy Shevchenko (1):
> x86 platform driver updates
>
>Arnaldo Carvalho de Melo (2):
> perf tools updates
> more perf tools updates
>
>Arnd Bergmann (5):
> ARM defconfig updates
> ARM SoC DT updates
> ARM SoC updates
> ARM SoC driver updates
> new ARM SoC support
>
>Benson Leung (1):
> chrome platform updates
>
>Bjorn Andersson (3):
> rpmsg update
> remoteproc updates
> hwspinlock updates
>
>Bjorn Helgaas (1):
> PCI updates
>
>Casey Schaufler (1):
> smack updates
>
>Catalin Marinas (3):
> arm64 and cross-arch updates
> arm64 fixes
> arm64 fix
>
>Christian Brauner (4):
> thread updates
> fork cleanups
> checkpoint-restore updates
> close_range() implementation
>
>Christoph Hellwig (2):
> uuid update
> dma-mapping updates
>
>Chuck Lever (1):
> NFS server updates
>
>Corey Minyard (1):
> IPMI updates
>
>Damien Le Moal (1):
> zonefs update
>
>Daniel Lezcano (1):
> thermal updates
>
>Darrick Wong (3):
> iomap updates
> xfs updates
> xfs fixes
>
>Dave Airlie (2):
> drm updates
> drm fixes
>
>David Miller (2):
> networking updates
> networking fixes
>
>David Sterba (2):
> btrfs updates
> more btrfs updates
>
>David Teigland (1):
> dlm updates
>
>Dmitry Torokhov (1):
> input updates
>
>Dominique Martinet (1):
> 9p updates
>
>Eric Biederman (1):
> execve updates
>
>Eric Biggers (2):
> fscrypt updates
> fsverity update
>
>Gao Xiang (1):
> erofs updates
>
>Geert Uytterhoeven (1):
> m68k updates
>
>Greg KH (5):
> char/misc driver updates
> driver core updates
> USB/Thunderbolt updates
> staging/IIO driver updates
> tty/serial updates
>
>Greg Ungerer (1):
> m68knommu updates
>
>Guenter Roeck (1):
> hwmon updates
>
>Guo Ren (1):
> arch/csky updates
>
>Heiko Carstens (2):
> s390 updates
> more s390 updates
>
>Helge Deller (2):
> parisc updates
> more parisc updates
>
>Herbert Xu (2):
> crypto updates
> crypto fix
>
>Ilya Dryomov (1):
> ceph updates
>
>Ingo Molar (1):
> x86 cpu updates
>
>Ingo Molnar (26):
> irq fixes
> debugobjects cleanup
> header cleanup
> RCU updates
> locking updates
> objtool updates
> perf event updates
> scheduler updates
> x86/alternatives update
> x86 asm updates
> x86 boot updates
> x86 build updates
> x86 cleanups
> x86 debug fixlets
> x86 FPU selftest
> x86 microcode update
> x86 MSR filtering
> x86 mmm update
> x86 platform updates
> x86 timer update
> x86 RAS updates
> sched/fifo updates
> locking fixlets
> perf fixes
> scheduler fixes
> x86 fixes
>
>Jaegeuk Kim (1):
> f2fs updates
>
>James Bottomley (2):
> SCSI updates
> more SCSI updates
>
>James Morris (1):
> security subsystem updates
>
>Jan Kara (2):
> ext2, udf, reiserfs, quota cleanups and minor fixes
> fsnotify updates
>
>Jarkko Sakkinen (1):
> tpm updates
>
>Jason Gunthorpe (2):
> hmm updates
> rdma updates
>
>Jassi Brar (1):
> mailbox updates
>
>Jeff Layton (1):
> file locking fix
>
>Jens Axboe (6):
> core block updates
> io_uring updates
> block driver updates
> block stacking updates
> block fixes
> io_uring fixes
>
>Jessica Yu (1):
> module updates
>
>Jiri Kosina (1):
> HID updates
>
>Joerg Roedel (1):
> iommu updates
>
>Jonathan Corbet (2):
> documentation updates
> documentation fixes
>
>Juergen Gross (2):
> xen updates
> more xen updates
>
>Julia Lawall (1):
> coccinelle updates
>
>Kees Cook (8):
> pstore update
> gcc plugin updates
> automatic variable initialization updates
> tasklets API update
> uninitialized_var() macro removal
> seccomp updates
> seccomp fix
> sysfs module section fix
>
>Lee Jones (2):
> backlight updates
> MFD updates
>
>Linus Walleij (2):
> GPIO updates
> pin control updates
>
>Mark Brown (3):
> regulator updates
> spi updates
> regmap updates
>
>Masahiro Yamada (2):
> Kbuild updates
> Kconfig updates
>
>Mauro Carvalho Chehab (1):
> media updates
>
>Max Filippov (1):
> Xtensa updates
>
>Michael Ellerman (2):
> powerpc updates
> powerpc fix
>
>Michael Tsirkin (1):
> virtio updates
>
>Miguel Ojeda (1):
> auxdisplay update
>
>Mike Marshall (1):
> orangefs updates
>
>Mike Rapoport (1):
> unicore32 removal
>
>Mike Snitzer (1):
> device mapper updates
>
>Mimi Zohar (1):
> integrity updates
>
>Miquel Raynal (1):
> mtd updates
>
>Namjae Jeon (1):
> exfat updates
>
>Palmer Dabbelt (2):
> RISC-V updates
> RISC-V fix
>
>Paolo Bonzini (2):
> KVM updates
> more KVM updates
>
>Paul Moore (2):
> selinux updates
> audit updates
>
>Pavel Machek (1):
> LED updates
>
>Petr Mladek (2):
> printk updates
> livepatching updates
>
>Rafael Wysocki (5):
> power management updates
> ACPI updates
> more power management updates
> one more power management update
> more ACPI updates
>
>Rich Felker (1):
> arch/sh updates
>
>Richard Weinberger (2):
> mtd fix
> JFFS2, UBI and UBIFS updates
>
>Rob Herring (2):
> Devicetree updates
> devicetree fixes
>
>Russell King (1):
> ARM updates
>
>Sebastian Reichel (1):
> power supply and reset updates
>
>Shuah Khan (1):
> kunit updates
>
>Stafford Horne (1):
> OpenRISC updates
>
>Stephen Boyd (2):
> clk updates
> more clk updates
>
>Steve French (2):
> cifs updates
> cifs fixes
>
>Steven Rostedt (2):
> tracing updates
> ktest updates
>
>Takashi Iwai (2):
> sound updates
> sound fixes
>
>Thierry Reding (1):
> pwm updates
>
>Thomas Bogendoerfer (1):
> MIPS upates
>
>Thomas Gleixner (9):
> irq updates
> timer updates
> generic kernel entry/exit code
> x86 conversion to generic entry code
> x86 fsgsbase
> locking updates
> irq fixes
> more timer updates
> timekeeping updates
>
>Tony Luck (2):
> EDAC updates
> edac fix
>
>Trond Myklebust (1):
> NFS client updates
>
>Ulf Hansson (1):
> MMC updates
>
>Vinod Koul (1):
> dmaengine updates
>
>Vishal Verma (1):
> libnvdimm updayes
>
>Wei Liu (2):
> hyperv updates
> hyper-v fixes
>
>Wim Van Sebroeck (1):
> watchdog updates
>
>Wolfram Sang (1):
> i2c updates
On 8/16/20 1:50 PM, Linus Torvalds wrote:
> This merge window felt a lot more normal than 5.8, and all the stats
> confirm thar it seems to be the usual size.
>
on x86_64, allmodconfig:
$ gcc --version
gcc (SUSE Linux) 7.5.0
$ sparse --version
0.6.2
I seem to be having some problems with kernel/time/timekeeping.c,
including a segfault.
a. Is it sparse that segfaults?
b. what prints this message?
make[3]: *** Deleting file 'kernel/time/timekeeping.o'
c. I would prefer to be able to tell the source of warning/error messages,
i.e., gcc or sparse. Especially when they are intermixed.
So one solution IMO would be to be able to do a full sparse check _only_,
without the gcc build. That way the messages would obviously be from sparse.
Another reason to do that is that I often do gcc builds and then would like
to follow that up with a sparse check build, but currently that means that
I have to do the full gcc + sparse build, which is really time consuming
since I have a wimpy laptop.
CC kernel/time/timekeeping.o
CHECK ../kernel/time/timekeeping.c
../kernel/time/timekeeping.c:461:23: warning: trying to copy expression type 31
../kernel/time/timekeeping.c:470:18: warning: trying to copy expression type 31
../include/linux/seqlock.h:214:1: warning: unreplaced symbol 's'
../include/linux/seqlock.h:214:1: warning: unreplaced symbol 'return'
../kernel/time/timekeeping.c:461:23: warning: unreplaced symbol 's'
../kernel/time/timekeeping.c:461:23: warning: unreplaced symbol 'return'
../include/linux/seqlock.h:214:1: warning: unreplaced symbol 's'
../include/linux/seqlock.h:214:1: warning: unreplaced symbol 'return'
../kernel/time/timekeeping.c:470:18: warning: unreplaced symbol 's'
../kernel/time/timekeeping.c:470:18: warning: unreplaced symbol 'return'
/bin/sh: line 1: 15126 Segmentation fault (core dumped) sparse -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ -Wbitwise -Wno-return-void -Wno-unknown-attribute -D__x86_64__ --arch=x86_64 -mlittle-endian -m64 -Wp,-MMD,kernel/time/.timekeeping.o.d -nostdinc -isystem /usr/lib64/gcc/x86_64-suse-linux/7/include -I../arch/x86/include -I./arch/x86/include/generated -I../include -I./include -I../arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I../include/uapi -I./include/generated/uapi -include ../include/linux/kconfig.h -include ../include/linux/compiler_types.h -D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -DCONFIG_X86_X32_ABI -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -O2 --param=allow-store-data-races=0 -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fno-var-tracking-assignments -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -fno-inline-functions-called-once -flive-patching=inline-clone -falign-functions=32 -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fsanitize-coverage=trace-pc -I ../kernel/time -I ./kernel/time -DKBUILD_MODFILE='"kernel/time/timekeeping"' -DKBUILD_BASENAME='"timekeeping"' -DKBUILD_MODNAME='"timekeeping"' ../kernel/time/timekeeping.c
make[3]: *** [../scripts/Makefile.build:283: kernel/time/timekeeping.o] Error 139
make[3]: *** Deleting file 'kernel/time/timekeeping.o'
make[3]: *** Waiting for unfinished jobs....
thanks.
--
~Randy
On Sun, Aug 16, 2020 at 06:35:26PM -0700, Randy Dunlap wrote:
>
> on x86_64, allmodconfig:
>
> $ gcc --version
> gcc (SUSE Linux) 7.5.0
>
> $ sparse --version
> 0.6.2
>
>
> I seem to be having some problems with kernel/time/timekeeping.c,
> including a segfault.
>
> a. Is it sparse that segfaults?
It's most probably the one fixed in:
eb6779f6f621 ("generic: fix missing inlining of generic expression")
On the main tree there is a branch with a few fixes since the last release:
git://git.kernel.org/pub/scm/devel/sparse/sparse.git maint-v0.6.2
> b. what prints this message?
> make[3]: *** Deleting file 'kernel/time/timekeeping.o'
It seems like a typical message from make when a command fails.
> c. I would prefer to be able to tell the source of warning/error messages,
> i.e., gcc or sparse. Especially when they are intermixed.
You can use the option -fdiagnostic-prefix[=PREFIX] for this. It will
just prefix all messages from from sparse with the given PREFIX or
'sparse: ' if none is given. You can pass this option via 'make CF=...'.
It may be a good idea to directly add it to CHECKFLAGS.
Best regards,
-- Luc
On 8/16/20 7:15 PM, Luc Van Oostenryck wrote:
> On Sun, Aug 16, 2020 at 06:35:26PM -0700, Randy Dunlap wrote:
>>
>> on x86_64, allmodconfig:
>>
>> $ gcc --version
>> gcc (SUSE Linux) 7.5.0
>>
>> $ sparse --version
>> 0.6.2
>>
>>
>> I seem to be having some problems with kernel/time/timekeeping.c,
>> including a segfault.
>>
>> a. Is it sparse that segfaults?
>
> It's most probably the one fixed in:
> eb6779f6f621 ("generic: fix missing inlining of generic expression")
>
> On the main tree there is a branch with a few fixes since the last release:
> git://git.kernel.org/pub/scm/devel/sparse/sparse.git maint-v0.6.2
>
>> b. what prints this message?
>> make[3]: *** Deleting file 'kernel/time/timekeeping.o'
>
> It seems like a typical message from make when a command fails.
>
>> c. I would prefer to be able to tell the source of warning/error messages,
>> i.e., gcc or sparse. Especially when they are intermixed.
>
> You can use the option -fdiagnostic-prefix[=PREFIX] for this. It will
> just prefix all messages from from sparse with the given PREFIX or
> 'sparse: ' if none is given. You can pass this option via 'make CF=...'.
>
> It may be a good idea to directly add it to CHECKFLAGS.
>
> Best regards,
> -- Luc
Thank you, Luc. I'll get the latest and also use PREFIX.
--
~Randy
On Sun, Aug 16, 2020 at 3:58 PM Bhaskar Chowdhury <[email protected]> wrote:
>
> I am scared that I might have missed something very obvious ...am I?? And the build abort...take a peek..
>
> ./arch/x86/include/asm/io.h:292:2: error: implicit declaration of function ‘slow_down_io’ [-Werror=implicit-function-declaration]
I'm not seeing how that would happen with a pristine codebase, but
send me your config just in case.
slow_down_io() is declared not that much further up in that file (or
in paravirt.h that gets included before for the CONFIG_PARAVIRT case).
Linus
On 09:44 Mon 17 Aug 2020, Linus Torvalds wrote:
>On Sun, Aug 16, 2020 at 3:58 PM Bhaskar Chowdhury <[email protected]> wrote:
>>
>> I am scared that I might have missed something very obvious ...am I?? And the build abort...take a peek..
>>
>> ./arch/x86/include/asm/io.h:292:2: error: implicit declaration of function ‘slow_down_io’ [-Werror=implicit-function-declaration]
>
>I'm not seeing how that would happen with a pristine codebase, but
>send me your config just in case.
>
>slow_down_io() is declared not that much further up in that file (or
>in paravirt.h that gets included before for the CONFIG_PARAVIRT case).
>
> Linus
Thanks, Linus ...I have attached the .config file with this mail for your
perusal.
~Bhaskar
On 8/17/20 2:25 PM, Bhaskar Chowdhury wrote:
> On 09:44 Mon 17 Aug 2020, Linus Torvalds wrote:
>> On Sun, Aug 16, 2020 at 3:58 PM Bhaskar Chowdhury <[email protected]> wrote:
>>>
>>> I am scared that I might have missed something very obvious ...am I?? And the build abort...take a peek..
>>>
>>> ./arch/x86/include/asm/io.h:292:2: error: implicit declaration of function ?slow_down_io? [-Werror=implicit-function-declaration]
>>
>> I'm not seeing how that would happen with a pristine codebase, but
>> send me your config just in case.
>>
>> slow_down_io() is declared not that much further up in that file (or
>> in paravirt.h that gets included before for the CONFIG_PARAVIRT case).
>>
>> ??????????? Linus
>
> Thanks, Linus ...I have attached the .config file with this mail for your
> perusal.
Hi--
I don't see any build errors with your config file.
--
~Randy
On Mon, Aug 17, 2020 at 2:25 PM Bhaskar Chowdhury <[email protected]> wrote:
>
> Thanks, Linus ...I have attached the .config file with this mail for your
> perusal.
There's something wrong with your setup - like Randy, I cannot
recreate the problem.
I wonder if you perhaps have some buggy version of ccache installed,
or something like that, which could mess up the build subtly?
Corrupted ccache files can result in some really hard-to-debug stuff,
because what the compiler sees isn't actually what you see when you
look at the source files...
Linus
On 16:32 Mon 17 Aug 2020, Linus Torvalds wrote:
>On Mon, Aug 17, 2020 at 2:25 PM Bhaskar Chowdhury <[email protected]> wrote:
>>
>> Thanks, Linus ...I have attached the .config file with this mail for your
>> perusal.
>
>There's something wrong with your setup - like Randy, I cannot
>recreate the problem.
>
>I wonder if you perhaps have some buggy version of ccache installed,
>or something like that, which could mess up the build subtly?
>Corrupted ccache files can result in some really hard-to-debug stuff,
>because what the compiler sees isn't actually what you see when you
>look at the source files...
>
> Linus
I take your and Randy's word as it seems plausible. Let me bisect my
setup and see what bad introduced and importantly how it introduced.
Thanks a bunch to both of you!!
~Bhaskar