lkml.org 
[lkml]   [1996]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: Makefile changes for kernel add-ons

On 17-Apr-96 Robert L Krawitz wrote:
>
> I also added the following patch to the end of Robert Krawitz's
> memcpy patch:
>...
> And likewise to the NcrBsd Driver from Gerard Roudier:
>...
>
>The first obvious problem: the two patches conflict.
>

They will apply. 'patch' has a default fuzz factor.

Patching file linux/Makefile using Plan A...
Hunk #1 succeeded at 5 with fuzz 2 (offset 2 lines).

That from was the +Mem patch with the +Bsd patch already in.
I have tested it with up to 4 different bogus "ADDON" patches.
They all worked.

>The other problem is that these addons only indicate whether the patch
>is installed, not whether it's configured in. I provide a config
>option with my memcpy, and if you disable it it shouldn't be showing
>up in the version string (or anywhere else, for that matter).
>

This is true. I don't leave patches in, whether they include a
config option or not. When I don't want them compiled in I use
'patch -R' to take them out. I also keep a pristine source tree
that doesn't get touched by anything but Linus' patches.

However...

--- linux/Makefile.orig Thu Apr 18 01:30:46 1996
+++ linux/Makefile Thu Apr 18 01:46:22 1996
@@ -127,6 +121,10 @@
drivers/net/net.a
LIBS =$(TOPDIR)/lib/lib.a
SUBDIRS =kernel drivers mm fs net ipc lib
+
+ifdef CONFIG_M586_COPY
+ADDON := $(ADDON)+Mem
+endif

ifeq ($(CONFIG_ISDN),y)
DRIVERS := $(DRIVERS) drivers/isdn/isdn.a
...should do it for you. It puts the test after .config is
included. And yes, more than one patch will still apply
with patch using it's fuzz factor.

Gerard's patch needs no such test. I think all patches that
change $ADDON should do it in the same place in the Makefile
to avoid confusion, whether they need to test for a config
option or not.

>What I think would be more useful would be a /proc/config that would
>contain a list of all options configured in (and perhaps all modules,
>too). Then the burden would be on people writing third party kernel
>software (modules or otherwise) to provide the appropriate
>configuration options.

This proposal has merit, but would require some rather extensive
changes to the kernel modules and the modules package itself.
My patch is short, sweet and gets the job done. With the above
patch we can even determine if a patch was configured in. And
best of all, a three line patch to the Makefile is hardly a
burden to anyone.

My main goal when I did this was to keep sets of incompatible
modules within the same kernel version from clobbering each
other with 'make modules_install' and for kerneld and modprobe
to be able to find the correct modules for the running kernel.
This works and can't affect the kernel in any way.

Rob
(rriggs@tesser.com)


\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.048 / U:1.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site