Am 09.09.2012 14:15, schrieb Peter Hüwe:
> Am Sonntag, 9. September 2012, 13:28:38 schrieb Jean Delvare:
>> Thanks for the info. I thought UML was no longer used with all the
>> virtualization solutions available, but apparently I was wrong.
> I guess it's mainly used for sandboxing, testing and development ;)

It's mostly used where KVM does not work.
For example low end i586 servers in schools.
Using UML you can still run 10+ instances on a P3 with 512MiB ram.

> 
>> My bet is that all I2C bus drivers do use I/O or memory mapped
>> operations directly or indirectly, except i2c-stub. So it would
>> probably make more sense, and be a less intrusive change, to move the
>> HAS_IOMEM dependency to drivers/i2c/busses, and move (logically or for
>> real) i2c-stub out of it.
>>
>> Or are there really other I2C bus drivers which make sense to enable
>> under UML?
> The only other available in UML which doesn't rely on HAS_IOMEM is the 
> PARPORT_LIGHT which relies on direct io access - so I guess this one doesn't 
> make sense either.
> 
> I created a patch for your proposed solution, I moved the stub driver to the 
> end in order to have only one big if HAS_IOMEM.

UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which is
often too coarse grained.
To deal with that I've introduced GENERIC_IO some time ago to support MTD (and nandsim)
on UML.
Maybe some parts of the I2C sub-system can also just depend on GENERIC_IO instead of
HAS_IOMEM.
An arch has GENERIC_IO=y if it supports everything defined in generic-asm/io.h which is
more than enough for most stub drivers.

Please look at this patch series:
https://lkml.org/lkml/2012/2/6/489

I'm sure it will help you in bringing I2C to UML.

Thanks,
//richard