From mboxrd@z Thu Jan 1 00:00:00 1970 From: ppokorny@penguincomputing.com (Philip Pokorny) Date: Thu, 19 May 2005 06:24:01 +0000 Subject: mkpatch works Message-Id: <3EF7510D.9050001@penguincomputing.com> List-Id: References: <3EF5B5CE.6050103@paradyne.com> In-Reply-To: <3EF5B5CE.6050103@paradyne.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lm-sensors@vger.kernel.org When we make a patch, why not generate the sensors.h and then put the result in the patch for installation in include/linux/sensors.h or similar. If you're going to compile user space code against your patched kernel, you're going to need that header file and I would expect that the user-space command line would need to specify: -I/lib/modules/$(uname -r)/build/include or it's equivalent... :v) Mark D. Studebaker wrote: > I think that sensors.h (which is autogenerated now) is now userspace-only > (it isn't included by any chip driver). So I'll remove it from FILES and > INCLUDES. > > Mark M. Hoffman wrote: > >> * Mark M. Hoffman [2003-06-22 11:17:05 -0400]: >> >>> * Mark D. Studebaker [2003-06-22 09:57:34 -0400]: >>> >>>> I got mkpatch working on both i2c and sensors, >>>> both configuring as modules and compiling-in. >>>> Please test. >>>> >>>> A few hints: >>>> >>>> - Follow steps in order: generate and apply i2c patch; then generate >>>> and apply sensors patch. >>> >>> >>> I2C mkpatch works and applies cleanly to 2.4.9. >>> >>> Then lm_sensors mkpatch says this: >>> >>> Can't open './kernel/include/sensors.h' at mkpatch/mkpatch.pl line 1432. >>> >>> Is that file generated on the fly now? >> >> >> >> Hmmm, it's in there... but 'make clean' deleted it. Is that the right >> thing >> for 'make clean' to do? >> >> Regards, >> > -- Philip Pokorny, Director of Engineering Tel: 415-358-2635 Fax: 415-358-2646 Toll Free: 888-PENGUIN PENGUIN COMPUTING, INC. www.penguincomputing.com