Le Wednesday 19 March 2014 à 15:53 +0100, Michal Marek a écrit :
> Dne 18.3.2014 22:42, Jean Delvare napsal(a):
> > Hi Michal et al,
> >
> > When running sequence-patches.sh --vanilla I would expect the vanilla
> > config file to be copied to the generated source tree, not the default
> > config file. That's not the case though, except when only the vanilla
> > config file is available. What about the following change to address
> > that?
>
> Good idea.
Patch applied.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi,
I stumbled on bnc#858840, and wondering whether we can use %posttrans
for triggering mkinitrd (or whatever) instead of %post. This will
reduce the time when many relevant packages are updated at once.
Or am I missing anything obvious...?
thanks,
Takashi
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi Michal et al,
When running sequence-patches.sh --vanilla I would expect the vanilla
config file to be copied to the generated source tree, not the default
config file. That's not the case though, except when only the vanilla
config file is available. What about the following change to address
that?
---
scripts/sequence-patch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/scripts/sequence-patch.sh
+++ b/scripts/sequence-patch.sh
@@ -304,7 +304,7 @@ if [ $# -ge 1 ]; then
fi
if test -z "$CONFIG"; then
- if test "$VANILLA_ONLY" = 1; then
+ if test "$VANILLA_ONLY" = 1 || $VANILLA; then
CONFIG=$(uname -m)-vanilla
else
CONFIG=$(uname -m)-default
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi,
Xen is broken on all ARM configs on master branch.
On ARM, when you enable xen (CONFIG_PARAVIRT_XEN=y), this lead to a compilation problem:
********************************************************************************
[ 3509s] CC arch/arm/kernel/asm-offsets.s
[ 3510s] In file included from /home/abuild/rpmbuild/BUILD/kernel-default-3.14.rc6/linux-3.14-rc6/arch/arm/include/asm/io.h:31:0,
[ 3510s] from /home/abuild/rpmbuild/BUILD/kernel-default-3.14.rc6/linux-3.14-rc6/include/linux/scatterlist.h:10,
[ 3510s] from /home/abuild/rpmbuild/BUILD/kernel-default-3.14.rc6/linux-3.14-rc6/include/linux/dma-mapping.h:9,
[ 3510s] from /home/abuild/rpmbuild/BUILD/kernel-default-3.14.rc6/linux-3.14-rc6/arch/arm/kernel/asm-offsets.c:15:
[ 3510s] /home/abuild/rpmbuild/BUILD/kernel-default-3.14.rc6/linux-3.14-rc6/arch/arm/include/asm/dma-mapping.h: In function 'get_dma_ops':
[ 3510s] /home/abuild/rpmbuild/BUILD/kernel-default-3.14.rc6/linux-3.14-rc6/include/xen/xen.h:29:38: error: dereferencing pointer to incomplete type
[ 3510s] xen_start_info && xen_start_info->flags & SIF_INITDOMAIN)
********************************************************************************
Maybe because of this patch: http://lists.xen.org/archives/html/xen-devel/2013-07/msg01833.html
Then, in "include/xen/interface/xen.h" file, "struct start_info" is not defined since XEN_HAVE_PV_GUEST_ENTRY is only defined for x86.
I tried vanilla 3.14-rc6 and there is no problem. So, the problem is in openSUSE xen patches.
Note that in arch/arm/{Kconfig,Makefile}, vanilla kernel uses CONFIG_XEN whereas openSUSE has CONFIG_PARAVIRT_XEN instead.
I will send a patch to disable Xen on ARM for now until this problem is solved.
Guillaume
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi,
please find in attachment a patch to re-enable ARM configs and update them to 3.14-rc6.
Signed-off-by: Guillaume GARDET <guillaume.gardet(a)opensuse.org>
Regards,
Guillaume
Hi all,
Having worked on built-in drivers which could be modularized, I am now
looking for modular drivers which could be built-in. Our policy is that
drivers which are not hardware-specific and are needed on a majority of
systems should be built into the kernel directly.
So I checked which modules were loaded on my 4 systems. After filtering
out hardware-specific modules, I am left with the following list:
ACPI and thermal drivers:
* button
* processor
* thermal_sys
Block device drivers
* cdrom
* scsi_dh
* scsi_dh_alua
* scsi_dh_emc
* scsi_dh_hp_sw
* scsi_dh_rdac
* sg
* sr_mod
Graphics helper drivers
* drm
* drm_kms_helper
* i2c_algo_bit
Filesystem drivers:
* fuse
* lockd
* sunrpc
CPU drivers:
* microcode
Sound drivers:
* pcspkr
* snd
* snd_page_alloc
* snd_pcm
* snd_seq
* snd_seq_device
* snd_timer
* soundcore
If anyone has an opinion on whether these should be built into the
kernel or left as modules, this is the right time to discuss it. My
personal thoughts, with mostly x86 in mind:
* The ACPI button and processor drivers could be built-in. Most x86
systems use ACPI and they supposedly all have at least one processor and
one power button ;) And thermal_sys is selected by processor.
* While all my systems have an optical drive, I know they have
disappeared from many systems, both very small and very large ones, so
leaving cdrom and sr_mod as modules seems fine.
* I have no idea why/how sg is being loaded, it has no modalias and no
other module depend on it. But /dev/sd* nodes are created so it is
certainly useful. Hannes?
* No idea what the scsi_dh* modules are about either, no modalias and no
dependencies either. Hannes?
* With DRM/KMS being the norm now, I believe drm and drm_kms_helper
could be built-in, even though the former is quite large. drm selects
i2c-algo-bit, most (all?) DRM/KMS drivers use it. Even servers have
graphics chips.
* I suppose fuse is only used on desktop machines by default, for gvfs,
so having it as a module seems OK.
* lockd and sunrpc are dependencies of nfs and nfsd. I suppose there are
many users out there who don't serve nor mount NFS shares so modules
make sense.
* I think microcode could be unloaded after use, maybe for security
reasons it might even be preferable, or just because there is simply no
point in keeping it in memory. Thomas? Either way we should keep it
modular.
* For sound drivers, Takashi should know better than me. I suppose that
the rationale for having these modular is that servers have no sound
chip?
--
Jean Delvare
Suse L3
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi,
please find in attachment an ARMv7 exynos config update to enhance arndale board.
* Add sound support
* Add I2C/SPI support
This patch is against master branch.
Signed-off-by: Guillaume GARDET <guillaume.gardet(a)opensuse.org>
Regards,
Guillaume
Hi,
please find in attachment an ARMv7 exynos config update to enhance/fix arndale board.
* Add USB support (and Ethernet connected on USB)
* Add sound support
* Add devices (accelerometer, etc.)
This patch is against 13.1 branch. Another patch against master branch will follow.
Signed-off-by: Guillaume GARDET <guillaume.gardet(a)opensuse.org>
Regards,
Guillaume
Hello,
did I miss something or is this [1][2] still unpatched in openSUSE 12.3
and 13.1 kernels?
After:
zypper in linux-sources
and:
grep -r -e "if (get_compat_timespec(&ktspec, timeout))" /usr/src/*
there was the expected output for the _unpatched_ kernel.
Much worse, the "CONFIG_X86_X32=y" (for openSUSE 13.1) and
"CONFIG_X86_32=y" (for openSUSE 12.3) seems to be available in *every*
kernel configuration. Is there a chance to use any kernel parameters for
deactivating this problem? I didn't find any solution.
Manually patching the kernel is no option for me. In the case of
patching myself and the assumption that it will not be fixed in the
repositories I will probably end up repairing this after every kernel
update.
Kind regards,
Stefan
References:
[1] http://www.openwall.com/lists/oss-security/2014/01/31/2
[2]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=…
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org