Juergen Hennerich wrote:

I did that a few times, but most of the work went always into the kernel and uClinux-dist build system. Also (maybe this has changed) there are a few places in the kernel (and the build system, but this could be fixed now) that relay on case sensitive file systems (netfilter?).

Also compiling on cygwin is much slower than on coLinux. Additionally you can't use two cygwin installations at the same time and when you want to install new software (with setup.exe), you may end with an installation that is incompatible with your embedded toolchain.
  
    But after persuasion and argument has failed,  what is left is what the client wants.

    Unfortunately this client is brilliant - and understands nothing is impossible, stuborn - they want Linux on their embedded systems, but they want to work from windows, and a close friend so
    blowing him off is not an option. But atleast I get to tell him he is an idiot, before trying to give him what he wants.


    I personally dislike cygwin - with respect to the people who put enormous effort into it. It is a horrible bag on the side of windows attempting to fix the unfixable.

    colinux is  a much more elegant solution to the same problem - as well as many others.


This is not exactly correct.  smbfs can be run without a working network
(at least in the physical sense).  Just setup the coLinux side for samba,
install the virtual network interface on the windows side, and then map
the coLinux from Windows.  You could also enable filesharing on the
windows side and access your coLinux build which resides on the NTFS by
mounting the windows shared folder in the coLinux build directory.

    
Exporting the build tree via SMBFS to Windows over tun/tap works quite good. This way the case problems could also be fixed.
  
    I started playing with colinux about 2 years ago. I never got TUN/TAP working. I have not used slirp, but I have had good luck with bridging - but I do nto have the time to fix the install system to get all the bridge parameters
    right automatically. We decided to drop networking colinux - it is really nice to have, but not critical to operations.


    Also I do not think CIFS/SMB resolves the filename case problems. I am fairly certain that in non-colinux environments I have had really evil things happen accross Samba connections based on the difference between
    the client and host OS's case rules. I think this even effects cofs with colinux. I think a cofs mount uses windows filename case rules even though it is on the Linux side.


AFAIK these tools have all the same problem, as they don't/can't support case sensitive file access under Windows. They have therefore the same problems as cygwin.
  
    We (my client and I looked thoroughly at the filename case issues - and they are solvable. It is possible to force casesensitive operations under Win32 - I am not sure why cofs and cygwin don't but it can be done.
    We were preparing to try to patch cygwin when we hit a few other problems:

             Most w32 api's are limited to approximately 240 character path's. There may be work arrounds - but they are going to be ugly.
             legal linux filename characters are  superset of legal windows filename chacters.


You can download an (rather old) example installer for such a setup (exports the directory containing the uClinux-dist with SAMBA) from  http://blackfin.uclinux.org/projects/bfin-colinux. 
Also since the coLinux system can connection with a Windows X-Server can function like a normal Linux box, it could support quite a number of additional applications which could be very interesting for a developer in the embedded area.
  
    My problem is my client is trying to get the colinux install (root file system particularly) as small as possible.
       I am down to 225Mb with a minimal compressed Debian system with a complete patched linux source and build environment and crosstools.

    I tried building a smaller image starting with Arch - but by the time I had everything I needed to compile Linux I was at probably 80% of the size of a minimal Debian image anyway, and I have probably a decade of Debian experience.

   I am not trying to create my own - or even the clients development environment. I have a fairly sophisticated coLinux install, multiple network connections, ssh, X, ....
   I am trying to create something my client can put on their web site for their clients to download. My client - http://www.picocomputing.com. sells very small and expensive embedded systems. They happen to run GreenHills and Linux, but primarily they are used for immage procession, or cryptography, or other things were their clients develop special hardware APU's in the FPGA. Anyway their clients are mostly firmware engineers doing everything under windows.

    Now I would personally like to see cofs evolve to the point of reducing my personal need for a large disk image, and since there is some significant synergy between some aspects of colinux and the embedded systems I am working on I might get time to do some work on cofs - basically I want to piggyback on colinux for the Pico Hosted development environment. I want to tunnel the cofs, conet, .. colinux<->windows link between the windows X86 host and my ppc405 linux target.


   
      
   
-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein