[PATCH] [TRIVIAL] Remove last traces of ikconfig.h
The build system stopped generating ikconfig.h in v2.6.8. Remove an entry for it in dontdiff. There's also a reference to it in a small comment. Remove that comment too, as it is of little help in any case. Signed-off-by: Paul Bolle <pebo...@tiscali.nl> --- Documentation/dontdiff | 1 - kernel/Makefile| 2 -- 2 files changed, 3 deletions(-) diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 5385cba941d2..a23edccd2059 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -139,7 +139,6 @@ hpet_example hugepage-mmap hugepage-shm ihex2fw -ikconfig.h* inat-tables.c initramfs_list int16.c diff --git a/kernel/Makefile b/kernel/Makefile index eb26e12c6c2a..eaee9de224bd 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -115,8 +115,6 @@ obj-$(CONFIG_HAS_IOMEM) += memremap.o $(obj)/configs.o: $(obj)/config_data.h -# config_data.h contains the same information as ikconfig.h but gzipped. -# Info from config_data can be extracted from /proc/config* targets += config_data.gz $(obj)/config_data.gz: $(KCONFIG_CONFIG) FORCE $(call if_changed,gzip) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] CodingStyle: Expand IS_ENABLED() documentation
On Tue, 2016-09-27 at 14:08 -0500, Bjorn Helgaas wrote: > --- a/Documentation/CodingStyle > +++ b/Documentation/CodingStyle > +Because the compiler processes the block, you have to use an #ifdef instead > +of IS_ENABLED() when code inside the block references symbols that will not > +exist if the condition is not met. Different CONFIG_FOO autoconf.h symbols > +are generated for modular Kconfig options than for builtin ones, so you > +need "#if defined(CONFIG_FOO) || defined(CONFIG_FOO_MODULE)" Isn't that equivalent to "#if IS_ENABLED(CONFIG_FOO)"? > if FOO can be > +a module: > + > + .config include/generated/autoconf.h > + > + CONFIG_FOO=y#define CONFIG_FOO 1 > + CONFIG_FOO=m#define CONFIG_FOO_MODULE 1 Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Prefer kASLR over Hibernation
On wo, 2016-04-06 at 15:16 -0700, Kees Cook wrote: > And it seems like Fedora either doesn't either, or has a lot of people > for whom it doesn't work: > https://bugzilla.redhat.com/show_bug.cgi?id=1206936 > https://bugzilla.redhat.com/show_bug.cgi?id=1224151 > http://blog.kriptonium.com/2015/12/fedora-23-hibernate.html Which are all variations on a theme: add "resume=$SWAP" to your kernel commandline, aren't they? (No idea why that's needed since Fedora 22, but it cost me quite a bit of head scratching to find out.) Once that parameter was set hibernate functioned again on the few laptops I, well, manage that run Fedora 22. Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
Hi Karsten, On do, 2016-03-10 at 11:53 +0100, i...@linux-pingi.de wrote: > mISDN with CAPI support works just fine with pppd and pppdcapiplugin > and the CAPI works for all mISDN HW. In the mainline tree the mISDN and CAPI stacks are effectively separate. Do you perhaps refer to a mISDN + Asterisk + chan-capi setup? (That's the closest to mISDN with CAPI support that I could find. Did I miss something?) Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
On za, 2016-03-05 at 14:08 +0100, Tilman Schmidt wrote: > As a consequence, owners of HiSAX type adapters are in fact stuck with > the old hisax driver if they want to continue using i4l userspace > tools. Do you know whether or not mISDN tools offer functionality comparable to i4l tools? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
On vr, 2016-03-04 at 17:32 +0100, Arnd Bergmann wrote: > A third patch moves the capidrv source from drivers/isdn/capi/ > into the i4l directory. I see. Why exactly? Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
[Added Tilman and Christoph.]
On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote:
> I actually did more patches that I ended up not submitting:
>
> * move hisax to staging
> * remove i4l support from gigaset
For the record: I have no reason to object a patch that does that. (I'm
not aware anyone complained when gigaset switched its default from i4l
to capi. By now all relevant distributions should use our capi driver.)
> * move i4l core to staging
On a local tree I have two (draft) patches that do some related
preliminary work:
- isdnhdlc: move into separate directory
- mISDN: NETJet: stop selecting ISDN_I4L
These trivial patches untangle mISDN and i4l. Perhaps you did something
similar in your "move i4l core to staging".
> while I initially thought that i4l as a whole is not just unmaintained
> but also more or less unused, patch 19cebbcb04c8 ("isdn: Partially
> revert debug format string usage clean up") came in that indicated
> that
> there are still users that even send patches for hisax, and that
> made me doubt whether we could consider it obsolete enough.
See also commit 3460baa62068 ("PCI: Fix minimum allocation address
overwrite").
> Any thoughts on this? If you like, I can send those too.
For my part I'm surprised that anyone is still using it. But apparently
the hardware that required commit 19cebbcb04c8 and 3460baa62068 (which
I'm unfamiliar with) is still operational. And since there never has
been, as far as I know, a global i4l to capi migration nor a global i4l
(and capi) to mISDN migration it might be that some people are stuck on
i4l drivers for their hardware. Perhaps that explains Cristoph's
commits.
> My main motivation was to not have to fix up the ippp implementation
> when I move the compat ioctl handler from fs/compat_ioctl.c
> into drivers/net/ppp/ppp_generic.c, but I guess I can do that
> anyway as it seems that i4l never worked properly in compat mode.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
