Can you please explain what this patch does and why it is needed?

-- 
Jean Delvare
--

[ message continues ]

It generates the entries needed for the user space module tools to
work with the aliases. For example modprobe/depmod. It is a standard
part of the kernel module system.

-- 
Jon Smirl
jonsmirl@gmail.com
--

[ message continues ]

What entries, where? What can you do after applying your patch that you
couldn't do before?

I'm asking because automatic i2c driver loading works just fine for me
without patching user-space. So I don't get why your want to change
anything.

-- 
Jean Delvare
--

[ message continues ]

-- 
Jon Smirl
jonsmirl@gmail.com
--

[ message continues ]

They do. I'm testing with the lm90 driver, which depends on the hwmon
driver. Both load automatically when the underlying i2c-parport driver
instantiate an "adm1032" i2c device.

-- 
Jean Delvare
--

[ message continues ]

I don't know exactly what those modules tables are used for. I just
copied what the other subsystems do. Maybe they are used when you make
an initrd to know which drivers to copy into the image.

-- 
Jon Smirl
jonsmirl@gmail.com
--

[ message continues ]

Module-init-tools needs those table to create module aliases in the *.ko
files from the MODULE_DEVICE_TABLE(), so udev can load the modules based
on the device IDs when the devices appear in sysfs.

That's the generic part. How this applies to i2c devices on platforms
without Open Firmware device trees is another question. I guess that's
where Jean gets confused (i2c_device_id got _removed_ last year,
because it didn't make sense (at the time?)).

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village 
[ message continues ]

-- 
Jon Smirl
jonsmirl@gmail.com
--

[ message continues ]

Hi Geert,


I thought that the module aliases were generated by
scripts/mod/modpost? As a matter of fact, I did not apply Jon's patch
to module-init-tools, and "modinfo" shows me module aliases properly
for i2c drivers that call MODULE_DEVICE_TABLE():

$ /sbin/modinfo lm90
filename:       /lib/modules/2.6.24-rc7-git4/kernel/drivers/hwmon/lm90.ko
author:         Jean Delvare <khali@linux-fr.org>
description:    LM90/ADM1032 driver
license:        GPL
vermagic:       2.6.24-rc7-git4 mod_unload
depends:        hwmon
alias:          i2c:Nlm90*
alias:          i2c:Nadm1032*
alias:          i2c:Nlm99*
alias:          i2c:Nlm86*
alias:          i2c:Nmax6657*
alias:          i2c:Nadt7461*
alias:          i2c:Nmax6680*
$


The way it was implemented back then did not make sense. As it was not
clear whether we would implement something different or nothing at all,
I decided to plain remove it. Now that it seems that we want to
implement it differently, I'm looking into it again.

-- 
Jean Delvare
--

[ message continues ]

I've just looked it up again (I had to do a similar thing for Zorro bus
support).  Module-init-tools (depmod) also creates the modules.*map files,
which are used to map from device IDs to module names. I think these are used
by udev to load the appropriate module when a device with a specific device ID

Yes, it's also still not 100% clear to me when `i2c:Nadm1032' is used, and when
modules.i2cmap would be used...

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village 
[ message continues ]

Ah, right. I see it now, there's modules.isapnpmap,
modules.ieee1394map, modules.pcimap etc. but no modules.i2cmap.
However, there is modules.alias which contains the i2c aliases for all
device types (including one ieee1394 and many pci aliases) which seems

I am under the impression that modules.*map are the old way to get
automatic driver loading and aliases are the new way to do the same.
But maybe that's just me.

-- 
Jean Delvare
--

[ message continues ]

Right, nothing on recent systems is using the map files. This patch
should not be needed.
The plan is to deprecate the creation of these files in depmod.

Thanks,
Kay
--

[ message continues ]

OK, great. Thanks for the info, Kay!

-- 
Jean Delvare
--

[ message continues ]