user-mode-linux-user

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. F T <che...@gm...>]

On 07/04/2013 10:29 AM, Steven Rostedt wrote:
> On Thu, 2013-07-04 at 10:10 +0800, Chen Gang F T wrote:
> 
>> > Select "COMPILE_TEST=y" with allmodconfig, but can not pass compiling in
>> > many architectures, one of the most reasons is "HW does not support".
>> > 
>> > 'asm-generic' is really existent for a long time, and make an important
>> > role for both architectures and modules.
>> > 
> The purpose of asm-generic is to add a standard infrastructure that some
> archs may be able to optimize. It's not so that all archs can compile
> all modules.
> 

Yes, I can understand.

But at present, it seems only 'asm-generic' can play the unlucky role
for current issues (at least, it is neither architectures issue nor
modules issue).

Hmm..., I think maybe also has another way: get rid of 'COMPILE_TEST'
(regress the related patch, which is only existent in next-* tree).

Or could you provide your suggestions or completions about it ?

Thanks.

> I'm still confused by what you are trying to accomplish.

Currently, I am trying to compile all architectures with allmodconfig in
next-* tree (which will have "COMPILE_TEST=y").

So I can find and solve the related issues (I am one of contributors).

One of main issues is about it.


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Steven R. <ro...@go...>]

On Thu, 2013-07-04 at 10:10 +0800, Chen Gang F T wrote:

> Select "COMPILE_TEST=y" with allmodconfig, but can not pass compiling in
> many architectures, one of the most reasons is "HW does not support".
> 
> 'asm-generic' is really existent for a long time, and make an important
> role for both architectures and modules.
> 

The purpose of asm-generic is to add a standard infrastructure that some
archs may be able to optimize. It's not so that all archs can compile
all modules.

I'm still confused by what you are trying to accomplish.

-- Steve

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. F T <che...@gm...>]

On 07/04/2013 09:23 AM, Steven Rostedt wrote:
> On Wed, 2013-07-03 at 18:12 -0700, Greg KH wrote:
> 
>> > confused,
> Good. I thought I was the only one. Confusion loves company, that way we
> can follow each other around in endless circles.

If you think, this mail has already make noises to many other members,
please reply mail next, which only contents the related members. And I
will follow with the address which you provide.

Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. F T <che...@gm...>]

On 07/04/2013 10:03 AM, Steven Rostedt wrote:
> On Thu, 2013-07-04 at 09:49 +0800, Chen Gang wrote:
> 
>> > Hmm... at least, it is neither architectures issue nor modules issue.
>> > 
>> > So we have to look for who have duty for it, since it is a 'generic'
>> > issue for many architectures and modules, we have to find it in
>> > 'generic' area (e.g. "./include/*").
>> > 
>> > At least now, it seems only "asm-generic/*" can play the unlucky role !!
>> > 
>> > Or, do you think it is still the modules issue themselves ?
> What problem are you trying to solve? asm-generic has been around for a
> long time, and so has allmodconfig. I'm unaware of any issues with
> either of them.
> 

Select "COMPILE_TEST=y" with allmodconfig, but can not pass compiling in
many architectures, one of the most reasons is "HW does not support".

'asm-generic' is really existent for a long time, and make an important
role for both architectures and modules.

> But as my last email got blocked because your ISP thinks my ISP is a
> spambot (it's road runner, which I'm sure there are spammers), you wont
> get this anyway.

Oh, sorry for not reply the original mail, and did not see in my backup
mail, now, I can use my backup mail to continue.


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Steven R. <ro...@go...>]

On Thu, 2013-07-04 at 09:49 +0800, Chen Gang wrote:

> Hmm... at least, it is neither architectures issue nor modules issue.
> 
> So we have to look for who have duty for it, since it is a 'generic'
> issue for many architectures and modules, we have to find it in
> 'generic' area (e.g. "./include/*").
> 
> At least now, it seems only "asm-generic/*" can play the unlucky role !!
> 
> Or, do you think it is still the modules issue themselves ?

What problem are you trying to solve? asm-generic has been around for a
long time, and so has allmodconfig. I'm unaware of any issues with
either of them.

But as my last email got blocked because your ISP thinks my ISP is a
spambot (it's road runner, which I'm sure there are spammers), you wont
get this anyway.

-- Steve

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

On 07/04/2013 09:12 AM, Greg KH wrote:
> On Thu, Jul 04, 2013 at 08:57:34AM +0800, Chen Gang wrote:
>> > 'COMPILE_TEST=y' will let 'asm-generic' provide self checking sevices to
>> > both modules and architectures (especially with allmodconfig and
>> > "EXTRA_CFLAGS=-W")
> No it doesn't.
> 

"If add 'COMPILE_TEST=y' to 'asm-generic', it will provide self checking
services to both modules and architectures"

Is it correct ?

>> > For modules (especially which will run under the specific architecture
>> > soon), the developer can find more compiling issues before they really
>> > support it.
> Huh?
> 

For developers, they may has hobby to let their code pass compiling as
much as possible in the integrating environments, although the modules
may not really load/run.


>> > For architectures, can let modules compile as much as possible (if
>> > "COMPILE_TEST=y"), it will give a better check for the architectures.
>> > 
>> > At present, most of architectures (include various machine/cpu in an
>> > architecture) can not pass compiling with 'allmodconfig'. One of the
>> > main reasons is the HW of the specific architecture does not support.
>> > 
>> > It is neither architectures issue nor modules issue, the root cause is:
>> > "now, 'asm-generic' doesn't provide the related necessary public
>> > services for it".
> That's not what asm-generic is for at all.

Hmm... at least, it is neither architectures issue nor modules issue.

So we have to look for who have duty for it, since it is a 'generic'
issue for many architectures and modules, we have to find it in
'generic' area (e.g. "./include/*").

At least now, it seems only "asm-generic/*" can play the unlucky role !!

Or, do you think it is still the modules issue themselves ?


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Steven R. <ro...@go...>]

On Wed, 2013-07-03 at 18:12 -0700, Greg KH wrote:

> confused,

Good. I thought I was the only one. Confusion loves company, that way we
can follow each other around in endless circles.

-- Steve

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Greg KH <gr...@li...>]

On Thu, Jul 04, 2013 at 08:57:34AM +0800, Chen Gang wrote:
> 'asm-generic' neither belongs to architectures nor belongs to modules,
> it provides public services to both modules and architectures.

That sentence does not make any sense to me.

> 'COMPILE_TEST=y' will let 'asm-generic' provide self checking sevices to
> both modules and architectures (especially with allmodconfig and
> "EXTRA_CFLAGS=-W")

No it doesn't.

> For modules (especially which will run under the specific architecture
> soon), the developer can find more compiling issues before they really
> support it.

Huh?

> For architectures, can let modules compile as much as possible (if
> "COMPILE_TEST=y"), it will give a better check for the architectures.
> 
> At present, most of architectures (include various machine/cpu in an
> architecture) can not pass compiling with 'allmodconfig'. One of the
> main reasons is the HW of the specific architecture does not support.
> 
> It is neither architectures issue nor modules issue, the root cause is:
> "now, 'asm-generic' doesn't provide the related necessary public
> services for it".

That's not what asm-generic is for at all.

confused,

greg k-h

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

'asm-generic' neither belongs to architectures nor belongs to modules,
it provides public services to both modules and architectures.


'COMPILE_TEST=y' will let 'asm-generic' provide self checking sevices to
both modules and architectures (especially with allmodconfig and
"EXTRA_CFLAGS=-W")

For modules (especially which will run under the specific architecture
soon), the developer can find more compiling issues before they really
support it.

For architectures, can let modules compile as much as possible (if
"COMPILE_TEST=y"), it will give a better check for the architectures.


At present, most of architectures (include various machine/cpu in an
architecture) can not pass compiling with 'allmodconfig'. One of the
main reasons is the HW of the specific architecture does not support.

It is neither architectures issue nor modules issue, the root cause is:
"now, 'asm-generic' doesn't provide the related necessary public
services for it".


Thanks.

On 07/03/2013 04:43 PM, Chen Gang wrote:
> On 07/03/2013 04:14 PM, Arnd Bergmann wrote:
>> On Wednesday 03 July 2013, Chen Gang wrote:
>>>> On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote:
>>>>>> On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote:
>>>>>>>>>> On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
>>>>>>>>>>>>>> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote:
>>>>>> I mean that COMPILE_TEST should exist in Kconfig files only.
>>>>>> It's only meant to have more compile coverage, not to "fix" (through #ifdef)
>>>>>> more code to make it compile.
>>>>
>>>> If so, can we allow the module to 'COMPILE_TEST' under one platform
>>>> which not support the related HW ?
>>>>
>>>>   e.g. "...Despite they cannot be loaded there (or even when they load
>>>> they cannot be used due to missing HW support)...".
>> There is a reason why ioremap and the associated functions make no
>> sense on UML, and it remains important to not provide them here
>> so we can find drivers that accidentally use them and are missing
>> a dependency on HAS_IOMEM.
>>  
> 
> Yeah, it is necessary for "asm-generic" to provide the configuration
> checking features (e.g. check HAS_IOMEM, HAS_IOMAP, ...).
> 
> And it really make no sense on UML.
> 
>>>> 'asm-generic' need provide generic layer to users (both architecture
>>>> guys and module guys).
>> No. It's a set of examples for the architectures to look at and
>> include if they want to.
>>
> 
> If really just like what you said, I recommend to use "asm-default"
> instead of "asm-generic".
> 
> And for module guys, they have to use another 'generic' files instead
> of current 'asm-generic', they really need some 'generic' things to
> prevent the various definitions/implementations spread into anywhere.
> 
>>>> So for 'default', it can depend on some conditions (e.g. HW support);
>>>> but for 'generic', it need try to be independent from any conditions.
>>>>
>>>> And it is also necessary for 'generic' to provide the configuration
>>>> checking features, but this checking must be no negative effect (or
>>>> consistent) with its 'generic' services.
>>>>
>>>> So it is necessary to check 'NOMMU', 'CONFIG_HAS_IOMEM' ..., but it
>>>> also necessary to consider about 'COMPILE_TEST' to be consistent with
>>>> its 'generic' services.
>> The important distinction is between drivers we want to enable in
>> COMPILE_TEST because they are written in a portable way but are just
>> useless if you don't have the hardware, and other drivers that rely
>> on an interface and that should not be built when that interface
>> is not available.
> 
> For user/distributor, they are just like what you said above, but for
> some of developers ...
> 
> The comments of 'COMPILE_TEST' in init/Kconfig:
> 
> config COMPILE_TEST
>        bool "Compile also drivers which will not load"
>        default n
>        help
>          Some drivers can be compiled on a different platform than they are
>          intended to be run on. Despite they cannot be loaded there (or even
>          when they load they cannot be used due to missing HW support),
>          developers still, opposing to distributors, might want to build such
>          drivers to compile-test them.
> 
>          If you are a developer and want to build everything available, say Y
>          here. If you are a user/distributor, say N here to exclude useless
>          drivers to be distributed.
> 
> 
> Thanks.
> 


-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

On 07/03/2013 04:14 PM, Arnd Bergmann wrote:
> On Wednesday 03 July 2013, Chen Gang wrote:
>> > On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote:
>>> > > On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote:
>>>>> > >> > On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
>>>>>>> > >>> >> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote:
>>> > > I mean that COMPILE_TEST should exist in Kconfig files only.
>>> > > It's only meant to have more compile coverage, not to "fix" (through #ifdef)
>>> > > more code to make it compile.
>> > 
>> > If so, can we allow the module to 'COMPILE_TEST' under one platform
>> > which not support the related HW ?
>> > 
>> >   e.g. "...Despite they cannot be loaded there (or even when they load
>> > they cannot be used due to missing HW support)...".
> There is a reason why ioremap and the associated functions make no
> sense on UML, and it remains important to not provide them here
> so we can find drivers that accidentally use them and are missing
> a dependency on HAS_IOMEM.
>  

Yeah, it is necessary for "asm-generic" to provide the configuration
checking features (e.g. check HAS_IOMEM, HAS_IOMAP, ...).

And it really make no sense on UML.

>> > 'asm-generic' need provide generic layer to users (both architecture
>> > guys and module guys).
> No. It's a set of examples for the architectures to look at and
> include if they want to.
> 

If really just like what you said, I recommend to use "asm-default"
instead of "asm-generic".

And for module guys, they have to use another 'generic' files instead
of current 'asm-generic', they really need some 'generic' things to
prevent the various definitions/implementations spread into anywhere.

>> > So for 'default', it can depend on some conditions (e.g. HW support);
>> > but for 'generic', it need try to be independent from any conditions.
>> > 
>> > And it is also necessary for 'generic' to provide the configuration
>> > checking features, but this checking must be no negative effect (or
>> > consistent) with its 'generic' services.
>> > 
>> > So it is necessary to check 'NOMMU', 'CONFIG_HAS_IOMEM' ..., but it
>> > also necessary to consider about 'COMPILE_TEST' to be consistent with
>> > its 'generic' services.
> The important distinction is between drivers we want to enable in
> COMPILE_TEST because they are written in a portable way but are just
> useless if you don't have the hardware, and other drivers that rely
> on an interface and that should not be built when that interface
> is not available.

For user/distributor, they are just like what you said above, but for
some of developers ...

The comments of 'COMPILE_TEST' in init/Kconfig:

config COMPILE_TEST
       bool "Compile also drivers which will not load"
       default n
       help
         Some drivers can be compiled on a different platform than they are
         intended to be run on. Despite they cannot be loaded there (or even
         when they load they cannot be used due to missing HW support),
         developers still, opposing to distributors, might want to build such
         drivers to compile-test them.

         If you are a developer and want to build everything available, say Y
         here. If you are a user/distributor, say N here to exclude useless
         drivers to be distributed.


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Arnd B. <ar...@ar...>]

On Wednesday 03 July 2013, Chen Gang wrote:
> On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote:
> > On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote:
> >> > On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
> >>> >> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote:
> > I mean that COMPILE_TEST should exist in Kconfig files only.
> > It's only meant to have more compile coverage, not to "fix" (through #ifdef)
> > more code to make it compile.
> 
> If so, can we allow the module to 'COMPILE_TEST' under one platform
> which not support the related HW ?
> 
>   e.g. "...Despite they cannot be loaded there (or even when they load
> they cannot be used due to missing HW support)...".

There is a reason why ioremap and the associated functions make no
sense on UML, and it remains important to not provide them here
so we can find drivers that accidentally use them and are missing
a dependency on HAS_IOMEM.
 
> 'asm-generic' need provide generic layer to users (both architecture
> guys and module guys).

No. It's a set of examples for the architectures to look at and
include if they want to.

> So for 'default', it can depend on some conditions (e.g. HW support);
> but for 'generic', it need try to be independent from any conditions.
> 
> And it is also necessary for 'generic' to provide the configuration
> checking features, but this checking must be no negative effect (or
> consistent) with its 'generic' services.
> 
> So it is necessary to check 'NOMMU', 'CONFIG_HAS_IOMEM' ..., but it
> also necessary to consider about 'COMPILE_TEST' to be consistent with
> its 'generic' services.

The important distinction is between drivers we want to enable in
COMPILE_TEST because they are written in a portable way but are just
useless if you don't have the hardware, and other drivers that rely
on an interface and that should not be built when that interface
is not available.

	Arnd

Re: [uml-user] Configuring GRE tunnel between Ubuntu and UML

[madhusudan r <mad...@ya...>]

I found the answer to this, posting it for others' benefit. The configuration is as follows, but the parameters vary depending on the mode in which the GRE needs to work on UML/Ubuntu:

1. Boot-up UML with GRE enabled
./vmlinux ubd0=guest3,uml-ext2-img con0=null con=fd:0,fd:1 umid=guest3 mem=32m eth0=tapng,,tap1 eth1=gre,,10.0.0.1,10.0.0.2,0x0,0x0,0x9 cgroup_disable=memory init=/etc/preinit

2. Configure a 'Ethernet over GRE' tunnel on Ubuntu
#sudo ip link add gt0 type gretap remote <IP> local <IP> [csum] [seq]
#sudo ip addr add 10.20.30.70/24 dev gt0
#sudo ip link set gt0 up


With everything in between them working, the systems will now be able to talk over GRE.



________________________________
 From: madhusudan r <mad...@ya...>
To: "use...@li..." <use...@li...> 
Sent: Friday, 28 June 2013 12:12 PM
Subject: [uml-user] Configuring GRE tunnel between Ubuntu and UML
 


Hi,

I'm trying to setup a GRE tunnel between an Ubuntu system and a UML (running on a different system). This is how the systems were configured:

1. UML

Boot arguments: ./vmlinux ubd0=guest3,uml-ext2-img con0=null con=fd:0,fd:1 umid=guest3 mem=32m eth0=tapng,,tap1 eth1=gre,,10.0.0.1,10.0.0.2,9 cgroup_disable=memory init=/etc/preinit


root@OpenWrt:/# ifconfig
eth0      Link encap:Ethernet  HWaddr 5A:86:C4:0D:19:F5
          UP BROADCAST RUNNING MULTICAST  MTU:1500 
 Metric:1
          RX packets:43 errors:0 dropped:22 overruns:0 frame:0
          TX packets:777 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2321 (2.2 KiB)  TX bytes:312354 (305.0 KiB)
          Interrupt:5

eth1      Link encap:Ethernet  HWaddr 76:5A:7B:B7:D9:F6
          inet addr:192.168.252.1  Bcast:192.168.252.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:611 errors:0 dropped:611 overruns:0
 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:42518 (41.5 KiB)  TX bytes:402 (402.0 B)
          Interrupt:5

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0
 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

2. Ubuntu

This is the entry I added to /etc/network/interfaces:

auto gre1
iface gre1 inet static
        address
 192.168.252.110
        netmask 255.255.255.252
        pre-up iptunnel add gre1 mode gre local 10.0.0.1 remote 10.0.0.2 ttl 255
        up ifconfig gre1 multicast
        pointtopoint 192.168.252.1
        post-down iptunnel del gre1


ubuntu# ifconfig

eth0      Link encap:Ethernet  HWaddr 78:e7:d1:c6:23:71
          inet addr:10.0.0.1  Bcast:10.78.49.255 
 Mask:255.255.255.0
          inet6 addr: fe80::7ae7:d1ff:fec6:2371/64 Scope:Link
          inet6 addr: 2001:220:abcd::20/64 Scope:Global
          inet6 addr: 2001:220:abcd:70::26/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3331 errors:0 dropped:284 overruns:0 frame:0
          TX packets:543 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1200307 (1.2 MB)  TX bytes:114051 (114.0 KB)
         
 Interrupt:17

gre1      Link encap:UNSPEC  HWaddr 0A-4E-31-4B-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.252.110  P-t-P:192.168.252.110  Mask:255.255.255.252
          inet6 addr: fe80::5efe:a4e:314b/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:168 (168.0 B)


The ubuntu box is able to ping the IP 192.168.252.1, but strangely I don't see packets going out to 10.0.0.2. Also, the UML is not able to ping 192.168.252.110.

Is this configuration correct or is there something missing?

Thanks!

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
User-mode-linux-user mailing list
Use...@li...
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

On 07/03/2013 08:51 AM, Chen Gang wrote:
> On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote:
>> On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote:
>>>> On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
>>>>>> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote:
>>>>>>>>>> 'asm-generic' need provide necessary configuration checking, if can't
>>>>>>>>>> pass checking, 'asm-generic' shouldn't implement it.
>>>>>>>>>>
>>>>>>>>>> For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
>>>>>>>>>> let it pass configuration checking, and provide related dummy contents
>>>>>>>>>> for it.
>>>>>>>>>>
>>>>>>>>>> Part of 'COMPLE_TEST' help contents in "init/Kconfig":
>>>>>>>>>>
>>>>>>>>>>   "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Chen Gang <gan...@as...>
>>>>>> NAKed-by: Geert Uytterhoeven <ge...@li...>
>>>>>>
>>>>>> Please don't clutter the code with checks for CONFIG_COMPILE_TEST.
>>>>
>>>> Do you mean: 'asm-generic' should not support 'COMPILE_TEST' (the
>>>> platform should not support 'COMPILE_TEST") ?
>>>>
>>>> Or you mean: 'COMPILE_TEST' should not exist in kernel ?
>> I mean that COMPILE_TEST should exist in Kconfig files only.
>> It's only meant to have more compile coverage, not to "fix" (through #ifdef)
>> more code to make it compile.
> 
> If so, can we allow the module to 'COMPILE_TEST' under one platform
> which not support the related HW ?
> 
>   e.g. "...Despite they cannot be loaded there (or even when they load
> they cannot be used due to missing HW support)...".
> 
> 
> 'asm-generic' need provide generic layer to users (both architecture
> guys and module guys).
> 
> So for 'default', it can depend on some conditions (e.g. HW support);
> but for 'generic', it need try to be independent from any conditions.
> 
> And it is also necessary for 'generic' to provide the configuration
> checking features, but this checking must be no negative effect (or
> consistent) with its 'generic' services.
> 
> So it is necessary to check 'NOMMU', 'CONFIG_HAS_IOMEM' ..., but it
> also necessary to consider about 'COMPILE_TEST' to be consistent with
> its 'generic' services.
> 
> 
> BTW: 20% code are for 80% features, but the left 20% features, need 80%
> code, if we have to make it complete, we have to face this 'rule'.
> 
> 

It is necessary to let the 'COMPILE_TEST' related members to know about
it (better to provide their own opinions), it may be helpful for our
discussion, so I list the details below.

-------------------------------commit begin----------------------------------

commit 4bb1667255a86360721291fe59991d033bbc2f2a
Author: Jiri Slaby <js...@su...>
Date:   Wed May 22 10:56:24 2013 +0200

    build some drivers only when compile-testing
    
    Some drivers can be built on more platforms than they run on. This is
    a burden for users and distributors who package a kernel. They have to
    manually deselect some (for them useless) drivers when updating their
    configs via oldconfig. And yet, sometimes it is even impossible to
    disable the drivers without patching the kernel.
    
    Introduce a new config option COMPILE_TEST and make all those drivers
    to depend on the platform they run on, or on the COMPILE_TEST option.
    Now, when users/distributors choose COMPILE_TEST=n they will not have
    the drivers in their allmodconfig setups, but developers still can
    compile-test them with COMPILE_TEST=y.
    
    Now the drivers where we use this new option:
    * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
      processors so it should depend on x86.
    * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
    * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
      systems -- which do not actually support the hardware via that
      method.
    * INTEL_MID_PTI: It is specific to the Penwell type of Intel Atom
      device.
    
    [v2]
    * remove EXPERT dependency
    
    [gregkh - remove chipidea portion, as it's incorrect, and also doesn't
     apply to my driver-core tree]
    
     Signed-off-by: Jiri Slaby <js...@su...>
    Cc: Andrew Morton <ak...@li...>
    Cc: Linus Torvalds <tor...@li...>
    Cc: Jeff Mahoney <je...@su...>
    Cc: Alexander Shishkin <ale...@li...>
    Cc: lin...@vg...
    Cc: Florian Tobias Schandinat <Flo...@gm...>
    Cc: lin...@li...
    Cc: lin...@vg...
    Cc: Richard Cochran <ric...@gm...>
    Cc: ne...@vg...
    Cc: Ben Hutchings <be...@de...>
    Cc: "Keller, Jacob E" <jac...@in...>
    Signed-off-by: Greg Kroah-Hartman <gr...@li...>

diff --git a/init/Kconfig b/init/Kconfig
index 55ccdf6..1e825c2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -53,6 +53,20 @@ config CROSS_COMPILE
          need to set this unless you want the configured kernel build
          directory to select the cross-compiler automatically.
 
+config COMPILE_TEST
+       bool "Compile also drivers which will not load"
+       default n
+       help
+         Some drivers can be compiled on a different platform than they are
+         intended to be run on. Despite they cannot be loaded there (or even
+         when they load they cannot be used due to missing HW support),
+         developers still, opposing to distributors, might want to build such
+         drivers to compile-test them.
+
+         If you are a developer and want to build everything available, say Y
+         here. If you are a user/distributor, say N here to exclude useless
+         drivers to be distributed.
+

-------------------------------commit end------------------------------------

Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote:
> On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote:
>> > On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
>>> >> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote:
>>>>> >>> > 'asm-generic' need provide necessary configuration checking, if can't
>>>>> >>> > pass checking, 'asm-generic' shouldn't implement it.
>>>>> >>> >
>>>>> >>> > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
>>>>> >>> > let it pass configuration checking, and provide related dummy contents
>>>>> >>> > for it.
>>>>> >>> >
>>>>> >>> > Part of 'COMPLE_TEST' help contents in "init/Kconfig":
>>>>> >>> >
>>>>> >>> >   "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > Signed-off-by: Chen Gang <gan...@as...>
>>> >> NAKed-by: Geert Uytterhoeven <ge...@li...>
>>> >>
>>> >> Please don't clutter the code with checks for CONFIG_COMPILE_TEST.
>> >
>> > Do you mean: 'asm-generic' should not support 'COMPILE_TEST' (the
>> > platform should not support 'COMPILE_TEST") ?
>> >
>> > Or you mean: 'COMPILE_TEST' should not exist in kernel ?
> I mean that COMPILE_TEST should exist in Kconfig files only.
> It's only meant to have more compile coverage, not to "fix" (through #ifdef)
> more code to make it compile.

If so, can we allow the module to 'COMPILE_TEST' under one platform
which not support the related HW ?

  e.g. "...Despite they cannot be loaded there (or even when they load
they cannot be used due to missing HW support)...".


'asm-generic' need provide generic layer to users (both architecture
guys and module guys).

So for 'default', it can depend on some conditions (e.g. HW support);
but for 'generic', it need try to be independent from any conditions.

And it is also necessary for 'generic' to provide the configuration
checking features, but this checking must be no negative effect (or
consistent) with its 'generic' services.

So it is necessary to check 'NOMMU', 'CONFIG_HAS_IOMEM' ..., but it
also necessary to consider about 'COMPILE_TEST' to be consistent with
its 'generic' services.


BTW: 20% code are for 80% features, but the left 20% features, need 80%
code, if we have to make it complete, we have to face this 'rule'.


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Geert U. <ge...@li...>]

On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote:
> On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
>> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote:
>>> > 'asm-generic' need provide necessary configuration checking, if can't
>>> > pass checking, 'asm-generic' shouldn't implement it.
>>> >
>>> > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
>>> > let it pass configuration checking, and provide related dummy contents
>>> > for it.
>>> >
>>> > Part of 'COMPLE_TEST' help contents in "init/Kconfig":
>>> >
>>> >   "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."
>>> >
>>> >
>>> > Signed-off-by: Chen Gang <gan...@as...>
>> NAKed-by: Geert Uytterhoeven <ge...@li...>
>>
>> Please don't clutter the code with checks for CONFIG_COMPILE_TEST.
>
> Do you mean: 'asm-generic' should not support 'COMPILE_TEST' (the
> platform should not support 'COMPILE_TEST") ?
>
> Or you mean: 'COMPILE_TEST' should not exist in kernel ?

I mean that COMPILE_TEST should exist in Kconfig files only.
It's only meant to have more compile coverage, not to "fix" (through #ifdef)
more code to make it compile.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote:
>> > 'asm-generic' need provide necessary configuration checking, if can't
>> > pass checking, 'asm-generic' shouldn't implement it.
>> >
>> > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
>> > let it pass configuration checking, and provide related dummy contents
>> > for it.
>> >
>> > Part of 'COMPLE_TEST' help contents in "init/Kconfig":
>> >
>> >   "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."
>> >
>> >
>> > Signed-off-by: Chen Gang <gan...@as...>
> NAKed-by: Geert Uytterhoeven <ge...@li...>
> 
> Please don't clutter the code with checks for CONFIG_COMPILE_TEST.

Do you mean: 'asm-generic' should not support 'COMPILE_TEST' (the
platform should not support 'COMPILE_TEST") ?

Or you mean: 'COMPILE_TEST' should not exist in kernel ?

Can we use 'asm-default' instead of 'asm-generic', since "if HW support,
it will provide default value, or it will provide nothing" ?


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Geert U. <ge...@li...>]

On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote:
> 'asm-generic' need provide necessary configuration checking, if can't
> pass checking, 'asm-generic' shouldn't implement it.
>
> For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
> let it pass configuration checking, and provide related dummy contents
> for it.
>
> Part of 'COMPLE_TEST' help contents in "init/Kconfig":
>
>   "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."
>
>
> Signed-off-by: Chen Gang <gan...@as...>

NAKed-by: Geert Uytterhoeven <ge...@li...>

Please don't clutter the code with checks for CONFIG_COMPILE_TEST.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

'asm-generic' need provide necessary configuration checking, if can't
pass checking, 'asm-generic' shouldn't implement it.

For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
let it pass configuration checking, and provide related dummy contents
for it.

Part of 'COMPLE_TEST' help contents in "init/Kconfig":

  "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."


Signed-off-by: Chen Gang <gan...@as...>
---
 include/asm-generic/io.h |   22 ++++++++++++++++++----
 1 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index d5afe96..301ce80 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -303,13 +303,18 @@ static inline void *phys_to_virt(unsigned long address)
 /*
  * Change "struct page" to physical address.
  *
- * This implementation is for the no-MMU case only... if you have an MMU
- * you'll need to provide your own definitions.
+ * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
+ * if you have an MMU and IOMEM, you'll need to provide your own definitions.
  */
-#ifndef CONFIG_MMU
+#if !defined(CONFIG_MMU) || \
+	(!defined(CONFIG_HAS_IOMEM) && defined(CONFIG_COMPILE_TEST))
 static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
 {
+#if !defined(CONFIG_MMU)
 	return (void __iomem*) (unsigned long)offset;
+#else
+	return NULL;
+#endif
 }
 
 #define __ioremap(offset, size, flags)	ioremap(offset, size)
@@ -325,7 +330,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
 static inline void iounmap(void __iomem *addr)
 {
 }
-#endif /* CONFIG_MMU */
+#endif /* !CONFIG_MMU || (!CONFIG_HAS_IOMEM && CONFIG_COMPILE_TEST) */
 
 #ifdef CONFIG_HAS_IOPORT
 #ifndef CONFIG_GENERIC_IOMAP
@@ -341,6 +346,15 @@ static inline void ioport_unmap(void __iomem *p)
 extern void __iomem *ioport_map(unsigned long port, unsigned int nr);
 extern void ioport_unmap(void __iomem *p);
 #endif /* CONFIG_GENERIC_IOMAP */
+#elif defined(CONFIG_COMPILE_TEST) /* CONFIG_HAS_IOPORT */
+static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
+{
+	return NULL;
+}
+
+static inline void ioport_unmap(void __iomem *p)
+{
+}
 #endif /* CONFIG_HAS_IOPORT */
 
 #ifndef xlate_dev_kmem_ptr
-- 
1.7.7.6

Re: [uml-user] [PATCH] include/asm-generic/io.h: add 'UML' case just like 'no-MMU'

[Chen G. <gan...@as...>]

On 07/01/2013 09:40 AM, Chen Gang wrote:
> On 06/26/2013 06:22 PM, Chen Gang wrote:
>> > On 06/26/2013 06:17 PM, Richard Weinberger wrote:
>>> >> Am 26.06.2013 12:01, schrieb Chen Gang:
>>>>> >>>> On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote:
>>>>>>> >>>>>> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote:
>>>>>>>>>>>>>>> >>>>>>>>>>>>>> Since the API itself already contents the meaning: "return NULL means
>>>>>>>>>>>>>>> >>>>>>>>>>>>>> the arch has no related io memory",
>>>>>>> >>>>>> No, NULL means it could not map the I/O memory.
>>>>>>> >>>>>>
>>>>> >>>>
>>>>> >>>> "it could not map the I/O memory" includes "has no related io memory".
>>>>> >>>> So it is enough for our case.
>>>>> >>>>
>>>>>>>>>>>>>>> >>>>>>>>>>>>>> Why not define a generic dummy one in "include/asm-generic/io.h" instead
>>>>>>>>>>>>>>> >>>>>>>>>>>>>> of "HAS_IOMEM" (which has already spread many various places, and also,
>>>>>>>>>>>>>>> >>>>>>>>>>>>>> most of new drivers have to know about it).
>>>>>>>>>>>>>>> >>>>>>>>>>>>>>
>>>>>>>>>>>>>>> >>>>>>>>>>>>>> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a
>>>>>>>>>>>>>>> >>>>>>>>>>>>>> dummy ioremap() which return NULL ... (also need consider more details).
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>> Because we don't even want to build these drivers and not make them fail while
>>>>>>>>>>> >>>>>>>>>> executing io memory related functions.
>>>>>>> >>>>>> Indeed, it doesn't make sense to build drivers that cannot work.
>>>>>>> >>>>>> And they may fail in a very bad way.
>>>>> >>>>
>>>>> >>>> That is our 'platform' guys feeling, not the 'module' guys, as
>>>>> >>>> 'platform' guys, it is better to provide the choice to 'module' guys,
>>>>> >>>> and let them decide by themselves, not forced by us.
>>> >> FYI, this is my last reply to this thread.
>>> >>
>>> >> As Geert and I said, drivers which need io memory have to depend on HAS_IOMEM=y.
>>> >> If an arch does not have io memory these drivers cannot work and therefore we don't
>>> >> want them built.
>> > 
> Hmm, if the modules select 'COMPILE_TEST', it is better to let asm-generic
> support this features (at least, not forbid it)
> 
> So how about the diff below ?  ;-)
> 
> ---------------------------diff begin-----------------------------------
> 
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index d5afe96..ede3775 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -303,13 +303,17 @@ static inline void *phys_to_virt(unsigned long address)
>  /*
>   * Change "struct page" to physical address.
>   *
> - * This implementation is for the no-MMU case only... if you have an MMU
> - * you'll need to provide your own definitions.
> + * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
> + * if you have an MMU and IOMEM, you'll need to provide your own definitions.
>   */
> -#ifndef CONFIG_MMU
> +#if !defined(CONFIG_MMU) || \
> +	(!defined(CONFIG_HAS_IOMEM) && defined(COMPILE_TEST))

Need use 'CONFIG_COMPILE_TEST' instead of 'COMPILE_TEST'.

>  static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
>  {
> +#if !defined(CONFIG_MMU)
>  	return (void __iomem*) (unsigned long)offset;
> +#else
> +	return NULL;
>  }
>  
>  #define __ioremap(offset, size, flags)	ioremap(offset, size)
> @@ -325,7 +329,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
>  static inline void iounmap(void __iomem *addr)
>  {
>  }
> -#endif /* CONFIG_MMU */
> +#endif /* !MMU || (!HAS_IOMEM && COMPILE_TEST) */
>  
>  #ifdef CONFIG_HAS_IOPORT
>  #ifndef CONFIG_GENERIC_IOMAP
> 
> ---------------------------diff end-------------------------------------
> 
>> > It is really the time for stopping discussion, and thank you all for
>> > spending your time resources on this discussion.
>> > 
>> > Next, I will send related patch for it (also cc to you all).
>> > 
>> > 
>> > Thanks.
>> > 
> 
> -- Chen Gang
> 


-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add 'UML' case just like 'no-MMU'

[Chen G. <gan...@as...>]

On 06/26/2013 06:22 PM, Chen Gang wrote:
> On 06/26/2013 06:17 PM, Richard Weinberger wrote:
>> Am 26.06.2013 12:01, schrieb Chen Gang:
>>>> On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote:
>>>>>> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote:
>>>>>>>>>>>>>> Since the API itself already contents the meaning: "return NULL means
>>>>>>>>>>>>>> the arch has no related io memory",
>>>>>> No, NULL means it could not map the I/O memory.
>>>>>>
>>>>
>>>> "it could not map the I/O memory" includes "has no related io memory".
>>>> So it is enough for our case.
>>>>
>>>>>>>>>>>>>> Why not define a generic dummy one in "include/asm-generic/io.h" instead
>>>>>>>>>>>>>> of "HAS_IOMEM" (which has already spread many various places, and also,
>>>>>>>>>>>>>> most of new drivers have to know about it).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a
>>>>>>>>>>>>>> dummy ioremap() which return NULL ... (also need consider more details).
>>>>>>>>>>
>>>>>>>>>> Because we don't even want to build these drivers and not make them fail while
>>>>>>>>>> executing io memory related functions.
>>>>>> Indeed, it doesn't make sense to build drivers that cannot work.
>>>>>> And they may fail in a very bad way.
>>>>
>>>> That is our 'platform' guys feeling, not the 'module' guys, as
>>>> 'platform' guys, it is better to provide the choice to 'module' guys,
>>>> and let them decide by themselves, not forced by us.
>> FYI, this is my last reply to this thread.
>>
>> As Geert and I said, drivers which need io memory have to depend on HAS_IOMEM=y.
>> If an arch does not have io memory these drivers cannot work and therefore we don't
>> want them built.
> 

Hmm, if the modules select 'COMPILE_TEST', it is better to let asm-generic
support this features (at least, not forbid it)

So how about the diff below ?  ;-)

---------------------------diff begin-----------------------------------

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index d5afe96..ede3775 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -303,13 +303,17 @@ static inline void *phys_to_virt(unsigned long address)
 /*
  * Change "struct page" to physical address.
  *
- * This implementation is for the no-MMU case only... if you have an MMU
- * you'll need to provide your own definitions.
+ * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
+ * if you have an MMU and IOMEM, you'll need to provide your own definitions.
  */
-#ifndef CONFIG_MMU
+#if !defined(CONFIG_MMU) || \
+	(!defined(CONFIG_HAS_IOMEM) && defined(COMPILE_TEST))
 static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
 {
+#if !defined(CONFIG_MMU)
 	return (void __iomem*) (unsigned long)offset;
+#else
+	return NULL;
 }
 
 #define __ioremap(offset, size, flags)	ioremap(offset, size)
@@ -325,7 +329,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
 static inline void iounmap(void __iomem *addr)
 {
 }
-#endif /* CONFIG_MMU */
+#endif /* !MMU || (!HAS_IOMEM && COMPILE_TEST) */
 
 #ifdef CONFIG_HAS_IOPORT
 #ifndef CONFIG_GENERIC_IOMAP

---------------------------diff end-------------------------------------

> It is really the time for stopping discussion, and thank you all for
> spending your time resources on this discussion.
> 
> Next, I will send related patch for it (also cc to you all).
> 
> 
> Thanks.
> 


-- 
Chen Gang

[uml-user] Configuring GRE tunnel between Ubuntu and UML

[madhusudan r <mad...@ya...>]

Hi,

I'm trying to setup a GRE tunnel between an Ubuntu system and a UML (running on a different system). This is how the systems were configured:

1. UML

Boot arguments: ./vmlinux ubd0=guest3,uml-ext2-img con0=null con=fd:0,fd:1 umid=guest3 mem=32m eth0=tapng,,tap1 eth1=gre,,10.0.0.1,10.0.0.2,9 cgroup_disable=memory init=/etc/preinit


root@OpenWrt:/# ifconfig
eth0      Link encap:Ethernet  HWaddr 5A:86:C4:0D:19:F5
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:43 errors:0 dropped:22 overruns:0 frame:0
          TX packets:777 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2321 (2.2 KiB)  TX bytes:312354 (305.0 KiB)
          Interrupt:5

eth1      Link encap:Ethernet  HWaddr 76:5A:7B:B7:D9:F6
          inet addr:192.168.252.1  Bcast:192.168.252.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:611 errors:0 dropped:611 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:42518 (41.5 KiB)  TX bytes:402 (402.0 B)
          Interrupt:5

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

2. Ubuntu

This is the entry I added to /etc/network/interfaces:

auto gre1
iface gre1 inet static
        address 192.168.252.110
        netmask 255.255.255.252
        pre-up iptunnel add gre1 mode gre local 10.0.0.1 remote 10.0.0.2 ttl 255
        up ifconfig gre1 multicast
        pointtopoint 192.168.252.1
        post-down iptunnel del gre1


ubuntu# ifconfig

eth0      Link encap:Ethernet  HWaddr 78:e7:d1:c6:23:71
          inet addr:10.0.0.1  Bcast:10.78.49.255  Mask:255.255.255.0
          inet6 addr: fe80::7ae7:d1ff:fec6:2371/64 Scope:Link
          inet6 addr: 2001:220:abcd::20/64 Scope:Global
          inet6 addr: 2001:220:abcd:70::26/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3331 errors:0 dropped:284 overruns:0 frame:0
          TX packets:543 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1200307 (1.2 MB)  TX bytes:114051 (114.0 KB)
          Interrupt:17

gre1      Link encap:UNSPEC  HWaddr 0A-4E-31-4B-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.252.110  P-t-P:192.168.252.110  Mask:255.255.255.252
          inet6 addr: fe80::5efe:a4e:314b/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:168 (168.0 B)


The ubuntu box is able to ping the IP 192.168.252.1, but strangely I don't see packets going out to 10.0.0.2. Also, the UML is not able to ping 192.168.252.110.

Is this configuration correct or is there something missing?

Thanks!

Re: [uml-user] Configure UML to work in IPv6 mode

[madhusudan r <mad...@ya...>]

I tried this with an image from a fresh build and the interfaces come up alright. 


Thanks for your answers/comments.



________________________________
 From: Michael Richardson <mc...@sa...>
To: madhusudan r <mad...@ya...> 
Cc: "use...@li..." <use...@li...> 
Sent: Tuesday, 25 June 2013 11:35 PM
Subject: Re: [uml-user] Configure UML to work in IPv6 mode
 


madhusudan r <mad...@ya...> wrote:

    > You're right about 'ifconfig' belonging to busybox. But things work fine for
    > IPv4 with exactly the same procedure.

Right... so busybox ifconfig doesn't speak enough IPv6, perhaps.

    > Also, in IPv6, eth1 comes up with link-local address; it just doesn't get
    > assigned the specified address. Assigning the v6 address from the command-line
    > works fine though.

Please say this more clearly.
You said that ifconfig failed.
Are you now saying that ifconfig works?
Or did you do ip?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]    mc...@sa...  http://www.sandelman.ca/        |   ruby on rails    [

Re: [uml-user] [PATCH] include/asm-generic/io.h: add 'UML' case just like 'no-MMU'

[Chen G. <gan...@as...>]

On 06/26/2013 06:17 PM, Richard Weinberger wrote:
> Am 26.06.2013 12:01, schrieb Chen Gang:
>> > On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote:
>>> >> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote:
>>>>>>> >>>>>> Since the API itself already contents the meaning: "return NULL means
>>>>>>> >>>>>> the arch has no related io memory",
>>> >> No, NULL means it could not map the I/O memory.
>>> >>
>> > 
>> > "it could not map the I/O memory" includes "has no related io memory".
>> > So it is enough for our case.
>> > 
>>>>>>> >>>>>> Why not define a generic dummy one in "include/asm-generic/io.h" instead
>>>>>>> >>>>>> of "HAS_IOMEM" (which has already spread many various places, and also,
>>>>>>> >>>>>> most of new drivers have to know about it).
>>>>>>> >>>>>>
>>>>>>> >>>>>> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a
>>>>>>> >>>>>> dummy ioremap() which return NULL ... (also need consider more details).
>>>>> >>>>
>>>>> >>>> Because we don't even want to build these drivers and not make them fail while
>>>>> >>>> executing io memory related functions.
>>> >> Indeed, it doesn't make sense to build drivers that cannot work.
>>> >> And they may fail in a very bad way.
>> > 
>> > That is our 'platform' guys feeling, not the 'module' guys, as
>> > 'platform' guys, it is better to provide the choice to 'module' guys,
>> > and let them decide by themselves, not forced by us.
> FYI, this is my last reply to this thread.
> 
> As Geert and I said, drivers which need io memory have to depend on HAS_IOMEM=y.
> If an arch does not have io memory these drivers cannot work and therefore we don't
> want them built.

It is really the time for stopping discussion, and thank you all for
spending your time resources on this discussion.

Next, I will send related patch for it (also cc to you all).


Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [uml-user] [PATCH] include/asm-generic/io.h: add 'UML' case just like 'no-MMU'

[Richard W. <ri...@no...>]

Am 26.06.2013 12:01, schrieb Chen Gang:
> On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote:
>> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote:
>>>>>> Since the API itself already contents the meaning: "return NULL means
>>>>>> the arch has no related io memory",
>> No, NULL means it could not map the I/O memory.
>>
> 
> "it could not map the I/O memory" includes "has no related io memory".
> So it is enough for our case.
> 
>>>>>> Why not define a generic dummy one in "include/asm-generic/io.h" instead
>>>>>> of "HAS_IOMEM" (which has already spread many various places, and also,
>>>>>> most of new drivers have to know about it).
>>>>>>
>>>>>> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a
>>>>>> dummy ioremap() which return NULL ... (also need consider more details).
>>>>
>>>> Because we don't even want to build these drivers and not make them fail while
>>>> executing io memory related functions.
>> Indeed, it doesn't make sense to build drivers that cannot work.
>> And they may fail in a very bad way.
> 
> That is our 'platform' guys feeling, not the 'module' guys, as
> 'platform' guys, it is better to provide the choice to 'module' guys,
> and let them decide by themselves, not forced by us.

FYI, this is my last reply to this thread.

As Geert and I said, drivers which need io memory have to depend on HAS_IOMEM=y.
If an arch does not have io memory these drivers cannot work and therefore we don't
want them built.

Over and out,
//richard

Re: [uml-user] [PATCH] include/asm-generic/io.h: add 'UML' case just like 'no-MMU'

[Chen G. <gan...@as...>]

On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote:
> On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger <ri...@no...> wrote:
>>> >> Since the API itself already contents the meaning: "return NULL means
>>> >> the arch has no related io memory",
> No, NULL means it could not map the I/O memory.
> 

"it could not map the I/O memory" includes "has no related io memory".
So it is enough for our case.

>>> >> Why not define a generic dummy one in "include/asm-generic/io.h" instead
>>> >> of "HAS_IOMEM" (which has already spread many various places, and also,
>>> >> most of new drivers have to know about it).
>>> >>
>>> >> e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a
>>> >> dummy ioremap() which return NULL ... (also need consider more details).
>> >
>> > Because we don't even want to build these drivers and not make them fail while
>> > executing io memory related functions.
> Indeed, it doesn't make sense to build drivers that cannot work.
> And they may fail in a very bad way.

That is our 'platform' guys feeling, not the 'module' guys, as
'platform' guys, it is better to provide the choice to 'module' guys,
and let them decide by themselves, not forced by us.


Thanks.
-- 
Chen Gang

Asianux Corporation