[Tipc-discussion] Cross-compiling TIPC for UML and MIPs

[<hek...@ya...>]

Hello,

It seems TIPC-1.3.08 can only be compiled for i386 architecture.

The attached patch to linux 2.4's Makefile will make TIPC compilable for
linux 2.4.x on architectures including UML (user-mode-linux) and MIPs.

After applying the attached patch I tried compiling TIPC for 
UML 2.4.22 kernel and MIPs 2.4.18 kernel as the following. 
Both build OK (compilation for i386 is the same as before)

1. UML:
cd source/unstable/net/tipc/linux-2.4
make ARCH=um KINCLUDE=/home/hek/src/solos/src/kernel/uml-2.4.22/include

2. MIPs:
cd source/unstable/net/tipc/linux-2.4
make ARCH=mips KINCLUDE=~/src/kernel/linux-2.4.18-toshiba/include

How does this look like ?

Thanks

Kevin


--- Jon Maloy <jon...@er...> wrote:
>   I sent this mail to cgl_specs and cgl_discussion.
> For those of you who are not at these lists...
> 
> Cheers /jon
> 
> Hi all,
> As there has been some questions about the status of TIPC recently,
> I will give a brief summary here.
> 
> Large parts of the code has been rewritten over the last months, both
> to accommodate the Linux kernel community with regards to code style
> and more, but also to simplify and make it more maintainable in general.
> 
> The major changes are the following:
> 
> 1: Code and directory structure. I now looks much more like what you would
>     expect from linux kernel code. The need for continuous support for 
> 2.4, and
>    realizing that the directory structure at SF does not have to be the 
> same as the
>    the one we use for the code to the kernel tree, made me add a couple of
>    subdirectories, however. We will probably need a script to select the 
> correct files
>    for each targeted kernel tree.
> 
> 2: Basic things such as memory management, lock handling and
>     debug support has been completely rewritten. We now rely entirely on
>     the linux native memory management. We also have a much finer lock
>     granularity than previously, and the debug support has been greatly
>     simplified, still without loosing the good parts of it.
> 
> 3: The total source code volume (14000 lines) and module size (132 kbyte 
> stripped)
>     has been reduced, and there is potential for more.
> 
> 4: The API has been rewritten, and is now as conformant to POSIX as I 
> think it can
>      be. We support SOCK_STREAM, SOCK_SEQ_ACKET, SOCK_RDM,
>     SOCK_DGRAM, and connections can be established in two different, 
> compatible
>     ways: a TCP-style setup scheme and the traditional "non-protocol 
> message" TIPC
>     style. There is also a kernel-internal transport API, availabe for 
> drivers, upon which
>     the socket API is implemented.
> 
> 5: We have modified the protocol header and added the framwork for providing
>     reliable multicast, among other things. We have also added an 
> "unreliable transfer
>     mode" which can be set per socket. This makes it possible tho throw 
> way e.g. tunneled
>     IP-messages during overload (e.g. during DOS-attacks). The 
> functionality for reliable
>     multicast is not complete yet, though. A low-cost socket-to-socket 
> flow control support
>     has also been added.
> 
> 6: We are also working on an (optional) distributed management 
> functionality,
>     making it possible to interrogate and change configuration setting 
> in TIPC via
>     the /proc file system on on one of the cluster nodes.
> 
> Despite all these changes I have taken great care to maintain a high 
> degree of
> code portability, albeit very much on Linux' conditions. Structures and 
> function
> names (spin_lock_bh, sk_buff etc) used are the Linux ones, but they should
> be easily remappable to other OS-es by means of a few simple macros, not
> by changing a lot of  source code files.
> 
> The code is now back to a state where it is working basically on both 
> Linux 2.4 and
> Linux 2.6. But some parts, such as the management functionality and the 
> SOCK_STREAM
> interface have not been tested yet.  This will be done during April.
> 
> I have also spent some time on pushing TIPC within IETF.
> At IETF-59 in Seoul I presented the contents of an  Internet draft
> (http://www.ietf.org/internet-drafts/draft-maloy-tipc-00.txt) where The TIPC
> features, old and new ones, as well as the protocol are described.
> The presentation was received with great interest, but a lot remains to 
> be done
> before IETF will accept it as a standard.
> 
> Finally: I am planning to announce TIPC at the LKML within short.
> I would very much appreciate feedback about functionality, code, protocol
> and anything else that can contribute to make TIPC better.
> 
> Regards /Jon Maloy
> 
>  
> 
> This communication is confidential and intended solely for the addressee(s). Any unauthorized
> review, use, disclosure or distribution is prohibited. If you believe this message has been sent
> to you in error, please notify the sender by replying to this transmission and delete the
> message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, interruption, unauthorized
> amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are
> not liable for any such corruption, interception, amendment, tampering or viruses or any
> consequences thereof.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> TIPC-discussion mailing list
> TIP...@li...
> https://lists.sourceforge.net/lists/listinfo/tipc-discussion