mkpatch works

mkpatch works

[Mark D. Studebaker]

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.

- As a compile test you can compile-in all drivers. But actually running that kernel takes
forever to load (bus scanning) and you hit all the driver quantity limits
(see the top of i2c.h). For easiest testing of compiled-in drivers only compile-in a few at a time.

- Don't enable bttv or other non-compatible i2c stuff in kernel.

mkpatch works

[Mark M. Hoffman]

* Mark D. Studebaker <mds@paradyne.com> [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?

> - As a compile test you can compile-in all drivers. But actually running 
> that kernel takes
> forever to load (bus scanning) and you hit all the driver quantity limits
> (see the top of i2c.h). For easiest testing of compiled-in drivers only 
> compile-in a few at a time.
> 
> - Don't enable bttv or other non-compatible i2c stuff in kernel.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

mkpatch works

[Mark M. Hoffman]

* Mark M. Hoffman <mhoffman@lightlink.com> [2003-06-22 11:17:05 -0400]:
> * Mark D. Studebaker <mds@paradyne.com> [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,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

mkpatch works

[Mark D. Studebaker]

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 <mhoffman@lightlink.com> [2003-06-22 11:17:05 -0400]:
> 
>>* Mark D. Studebaker <mds@paradyne.com> [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,
> 

mkpatch works

[Mark M. Hoffman]

* Mark D. Studebaker <mds@paradyne.com> [2003-06-22 12:18:32 -0400]:
> 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.

OK, I can patch and apply cleanly from i2c and lm_sensors2 to 2.4.9 now.
But, CONFIG_SENSORS never shows up in 'make xconfig'.  All the drivers
are there in ./drivers/sensors.

My kernel config is attached.  I'll have more time tomorrow to play with
this.

> 
> Mark M. Hoffman wrote:
> >* Mark M. Hoffman <mhoffman@lightlink.com> [2003-06-22 11:17:05 -0400]:
> >
> >>* Mark D. Studebaker <mds@paradyne.com> [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,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

-------------- next part --------------
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PM=y
# CONFIG_ACPI is not set
# CONFIG_APM is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play configuration
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set

#
#  
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set

#
# IDE chipset support/bugfixes
#
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y

#
# SCSI support
#
# CONFIG_SCSI is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_ARM_AM79C961A is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
CONFIG_VORTEX=y
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_CS89x0 is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_DGRS is not set
# CONFIG_DM9102 is not set
CONFIG_EEPRO100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Input core support
#
# CONFIG_INPUT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
# CONFIG_SERIAL_CONSOLE is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT%6
# CONFIG_PRINTER is not set
# CONFIG_PPDEV is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_PHILIPSPAR=y
CONFIG_I2C_ELV=y
CONFIG_I2C_VELLEMAN=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ELEKTOR=y
CONFIG_I2C_MAINBOARD=y
CONFIG_I2C_ALI1535=y
CONFIG_I2C_ALI15X3=y
CONFIG_I2C_HYDRA=y
CONFIG_I2C_AMD756=y
CONFIG_I2C_AMD8111=y
CONFIG_I2C_I801=y
CONFIG_I2C_I810=y
CONFIG_I2C_PIIX4=y
CONFIG_I2C_SIS5595=y
CONFIG_I2C_SIS630=y
CONFIG_I2C_SIS645=y
CONFIG_I2C_SAVAGE4=y
CONFIG_I2C_VIA=y
CONFIG_I2C_VIAPRO=y
CONFIG_I2C_VOODOO3=y
CONFIG_I2C_ISA=y
CONFIG_I2C_CHARDEV=y

#
# Mice
#
# CONFIG_BUSMOUSE is not set
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set

#
# Joysticks
#

#
# Game port support
#

#
# Gameport joysticks
#

#
# Serial port support
#

#
# Serial port joysticks
#

#
# Parallel port joysticks
#
# CONFIG_QIC02_TAPE is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_INTEL_RNG is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_I810=y
CONFIG_AGP_VIA=y
CONFIG_AGP_AMD=y
CONFIG_AGP_SIS=y
CONFIG_AGP_ALI=y
# CONFIG_AGP_SWORKS is not set
CONFIG_DRM=y
CONFIG_DRM_TDFX=y
# CONFIG_DRM_GAMMA is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=y
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_MGA is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
# CONFIG_REISERFS_FS is not set
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_FAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
CONFIG_TMPFS=y
# CONFIG_RAMFS is not set
CONFIG_ISO9660_FS=y
# CONFIG_JOLIET is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_SMB_NLS is not set
# CONFIG_NLS is not set

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set
# CONFIG_MDA_CONSOLE is not set

#
# Frame-buffer support
#
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
# CONFIG_USB is not set

#
# Bluetooth support
#
# CONFIG_BLUEZ is not set

#
# Kernel hacking
#
# CONFIG_MAGIC_SYSRQ is not set

mkpatch works

[Philip Pokorny]

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 <mhoffman@lightlink.com> [2003-06-22 11:17:05 -0400]:
>>
>>> * Mark D. Studebaker <mds@paradyne.com> [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

mkpatch works

[Mark Studebaker]

Shouldn't sensors.h (and the sensors userspace version of i2c-dev.h) 
just get installed in /usr/local/include/linux
when you do a 'make install'?

Philip Pokorny wrote:
> 
> 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 <mhoffman@lightlink.com> [2003-06-22 11:17:05 -0400]:
> >>
> >>> * Mark D. Studebaker <mds@paradyne.com> [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

mkpatch works

[Philip Pokorny]

I guess that depends on what the expected use of the mkpatch script is.

Is the idea to inject a specific version of lm_sensors into a kernel 
tree for development and tweaking.  Perhaps someone is playing with 
config file options, or other kernel patches and wants i2c/sensors 
available as modules in all the development work they do?  (Alan Cox's 
-ac kernel trees, OS distro developers...)

Or is it meant for people compiling a monolithic kernel and therefore 
need the i2c/sensors files to be in the kernel tree for linking into the 
monolithic kernel?

In the first case, you're not going to run "make install" so you're 
going to have to provide the files in a different manner.

In the second case, you're right.  "make install" or something similar 
could just install in $(PREFIX)/include/linux...

:v)

Mark Studebaker wrote:
> Shouldn't sensors.h (and the sensors userspace version of i2c-dev.h) 
> just get installed in /usr/local/include/linux
> when you do a 'make install'?
> 
> Philip Pokorny wrote:
> 
>>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 <mhoffman@lightlink.com> [2003-06-22 11:17:05 -0400]:
>>>>
>>>>
>>>>>* Mark D. Studebaker <mds@paradyne.com> [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
> 
> 



-- 
Philip Pokorny, Director of Engineering
Tel: 415-358-2635   Fax: 415-358-2646   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com

mkpatch works

[Mark M. Hoffman]

* Mark M. Hoffman <mhoffman@lightlink.com> [2003-06-22 13:46:43 -0400]:
(making a habit of replying to himself...)

> * Mark D. Studebaker <mds@paradyne.com> [2003-06-22 12:18:32 -0400]:
> > 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.
> 
> OK, I can patch and apply cleanly from i2c and lm_sensors2 to 2.4.9 now.
> But, CONFIG_SENSORS never shows up in 'make xconfig'.  All the drivers
> are there in ./drivers/sensors.
> 
> My kernel config is attached.  I'll have more time tomorrow to play with
> this.

The line which specifies CONFIG_I2C_PROC in i2c/mkpatch/Config.in is missing
from the kernel file: drivers/i2c/Config.in.  Of course CONFIG_SENSORS
depends on CONFIG_I2C_PROC so that's why I never saw it.  I'm not familiar
w/ the guts of mkpatch - but I'll try to look at it unless someone else
gets there first (hopefully... took a quick peek but I'm no Perl guru.)

;)

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

mkpatch works

[Jean Delvare]

> The line which specifies CONFIG_I2C_PROC in i2c/mkpatch/Config.in is
> missing from the kernel file: drivers/i2c/Config.in.  Of course
> CONFIG_SENSORS depends on CONFIG_I2C_PROC so that's why I never saw
> it.  I'm not familiar w/ the guts of mkpatch - but I'll try to look at
> it unless someone else gets there first (hopefully... took a quick
> peek but I'm no Perl guru.)

Oh, I didn't know mkpatch was written in Perl. Maybe I can help?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

mkpatch works

[Mark D. Studebaker]

I guess more the second.
I'm going to add some make targets to do the userspace stuff only.

Philip Pokorny wrote:
> I guess that depends on what the expected use of the mkpatch script is.
> 
> Is the idea to inject a specific version of lm_sensors into a kernel 
> tree for development and tweaking.  Perhaps someone is playing with 
> config file options, or other kernel patches and wants i2c/sensors 
> available as modules in all the development work they do?  (Alan Cox's 
> -ac kernel trees, OS distro developers...)
> 
> Or is it meant for people compiling a monolithic kernel and therefore 
> need the i2c/sensors files to be in the kernel tree for linking into the 
> monolithic kernel?
> 
> In the first case, you're not going to run "make install" so you're 
> going to have to provide the files in a different manner.
> 
> In the second case, you're right.  "make install" or something similar 
> could just install in $(PREFIX)/include/linux...
> 
> :v)
> 
> Mark Studebaker wrote:
> 
>> Shouldn't sensors.h (and the sensors userspace version of i2c-dev.h) 
>> just get installed in /usr/local/include/linux
>> when you do a 'make install'?
>>
>> Philip Pokorny wrote:
>>
>>> 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 <mhoffman@lightlink.com> [2003-06-22 11:17:05 
>>>>> -0400]:
>>>>>
>>>>>
>>>>>> * Mark D. Studebaker <mds@paradyne.com> [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
>>
>>
>>
> 
> 
> 

mkpatch works

[Mark M. Hoffman]

* Jean Delvare <khali@linux-fr.org> [2003-06-26 15:28:31 +0200]:
> 
> > The line which specifies CONFIG_I2C_PROC in i2c/mkpatch/Config.in is
> > missing from the kernel file: drivers/i2c/Config.in.  Of course
> > CONFIG_SENSORS depends on CONFIG_I2C_PROC so that's why I never saw
> > it.  I'm not familiar w/ the guts of mkpatch - but I'll try to look at
> > it unless someone else gets there first (hopefully... took a quick
> > peek but I'm no Perl guru.)
> 
> Oh, I didn't know mkpatch was written in Perl. Maybe I can help?
> 

Recap: I tested mkpatch against linux 2.4.9 and found that CONFIG_I2C_PROC
and therefore CONFIG_SENSORS (and all dependents) were missing from
"make config".

Looks like CONFIG_I2C_PROC used to be patched into drivers/char/Config.in
by i2c mkpatch, but that's commented out now.  Meanwhile, linux 2.4.13
adds CONFIG_I2C_PROC to drivers/i2c/Config.in instead.

I think i2c mkpatch needs to be able to patch drivers/i2c/Config.in
if we want to support linux 2.4.9.  I guess that the contents of
i2c/mkpatch/Config.in would be suitable for this, except that it's
missing some adapters that are present in later kernels. (1)

Or, declare minimum supported kernel >= 2.4.13 and this particular
problem goes away.  I mean, 2.4.9 is almost *two years* old.  Probably
if I didn't test this nobody would have ever noticed. ;)

Also, I'm soon on vacation... whatever is decided (if I'm to work on it)
will wait until mid-July at least.

(1) That's actually a whole seperate problem: linux 2.4.21 has i2c code
that we don't have in CVS - e.g. "NatSemi SCx200 I2C using GPIO pins".
Should we bring that into CVS before the next release?  Otherwise
mkpatch will "unsupport" it.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

mkpatch works

[Mark D. Studebaker]

Thanks for testing.
Let's fix this the simplest way possible.
We'll continue to claim support for 2.4.9 but say that
if you are using mkpatch the minimum kernel is 2.4.13.

As far as SCx200, since mkpatch will render it unusable anyway
(due to struct changes) it's probably a good thing that
it get "unsupported" by mkpatch.

I'll update the docs.

Mark M. Hoffman wrote:
> * Jean Delvare <khali@linux-fr.org> [2003-06-26 15:28:31 +0200]:
> 
>>>The line which specifies CONFIG_I2C_PROC in i2c/mkpatch/Config.in is
>>>missing from the kernel file: drivers/i2c/Config.in.  Of course
>>>CONFIG_SENSORS depends on CONFIG_I2C_PROC so that's why I never saw
>>>it.  I'm not familiar w/ the guts of mkpatch - but I'll try to look at
>>>it unless someone else gets there first (hopefully... took a quick
>>>peek but I'm no Perl guru.)
>>
>>Oh, I didn't know mkpatch was written in Perl. Maybe I can help?
>>
> 
> 
> Recap: I tested mkpatch against linux 2.4.9 and found that CONFIG_I2C_PROC
> and therefore CONFIG_SENSORS (and all dependents) were missing from
> "make config".
> 
> Looks like CONFIG_I2C_PROC used to be patched into drivers/char/Config.in
> by i2c mkpatch, but that's commented out now.  Meanwhile, linux 2.4.13
> adds CONFIG_I2C_PROC to drivers/i2c/Config.in instead.
> 
> I think i2c mkpatch needs to be able to patch drivers/i2c/Config.in
> if we want to support linux 2.4.9.  I guess that the contents of
> i2c/mkpatch/Config.in would be suitable for this, except that it's
> missing some adapters that are present in later kernels. (1)
> 
> Or, declare minimum supported kernel >= 2.4.13 and this particular
> problem goes away.  I mean, 2.4.9 is almost *two years* old.  Probably
> if I didn't test this nobody would have ever noticed. ;)
> 
> Also, I'm soon on vacation... whatever is decided (if I'm to work on it)
> will wait until mid-July at least.
> 
> (1) That's actually a whole seperate problem: linux 2.4.21 has i2c code
> that we don't have in CVS - e.g. "NatSemi SCx200 I2C using GPIO pins".
> Should we bring that into CVS before the next release?  Otherwise
> mkpatch will "unsupport" it.
> 
> Regards,
>