[CUWiN-Dev] Re: want to help: cuwin on wrt54g/embedded mips

[David Young]

On Sun, Mar 26, 2006 at 10:56:40AM -0500, Rob Janes wrote:
> David, thanks for the pointers.  This paragraph from the 
> "summer-of-code" doc/local file seems apropo:
> 
> >Ports
> >
> >        Mac OS X
> >
> >                It's BSD, so it might not be *too* difficult to
> >                port net80211 and the *BSD wireless drivers.  Then
> >                we can run hslsd/etx "in the usual way." Lots of
> >                work.  Apple should support this development, since
> >                it makes *so* much sense.  Sick Sascha on 'em?
> 
> 
> Hmmm, so a port to another flavour of BSD is not deemed "piece of cake" 
> but "not *too* difficult".

That paragraph is talking about porting the 802.11 framework and 802.11
device drivers from NetBSD to Mac OS X.  If that was a piece of cake,
it would be done already.

> Is there any other information about the obsticals to porting?  What 
> unique features of bsd were used in hslsd/etx?  What was the rational 
> for choosing netbsd in the first place (as opposed to linux, macosx, 
> freebsd, etc, etc).

The software is written with portability in mind.  The best way to find
the obstacles is to give it a shot, but I anticipate some Linux/BSD
differences in the socket library.

> David Young wrote:
> 
> >On Sat, Mar 25, 2006 at 03:12:37AM -0500, Rob Janes wrote:
> > 
> >
> >>It's hard to distinguish the mesh components from the others.  
> >>Interdependencies are not documented.  The bsd makefiles are not there.
> >>   
> >>
> >
> >You will have to make do.  The BSD make macros are documented in
> >/usr/share/mk/bsd.README, which is installed on all NetBSD machines.
> > 
> >
> It would be helpful if you could count off the strictly cuwin mesh 
> components from other things.  Ie, a list of things that need to be 
> ported from things that already are ported.
> 
> For example, I would assume that quagga, thttpd, jpeg, libpng, gd, 
> boot-image are components that are either unnecessary or are already 
> ported to linux.

Correct.

> However it's not clear whether or not ans, athtools, clearsilver, flock, 
> hclient, heap, hitime, howl, ipschema, iswlan, netwdog, nodeconfig, 
> nsbridge, nsd, pathstate, pool, radix, test and viz would be part of a 
> porting effort.

Of the above, only the 'heap' module needs to be ported.  It is used in
the routing daemon.

> If you or somebody could fill in the blanks here it would be helpful:

The 'stubs' do so-called 'reachover' builds of third-party sources.
I cannot think of any 3rd-party sources we use that do not compile and
run on Linux.

> boot-image - creates cuwin boot image?

This builds the NetBSD boot image on Linux/Mac OS X/*BSD, using the
NetBSD cross-build tools.  You don't need to port that.

> ans - dyonge: some utility belt tool?
> athtools - stub directory, only a makefile
> clearsilver - stub directories
> electricfence - stub, memory leak checker
> flock - cuwin: shell tool for locking on a file
> gd - stub directory
> howl - stub directories - porchdog?  service advertising?
> ipschema - shell tools for fiddling with ip numbers
> iswlan - shell tool
> jpeg - stub
> libpng - stub
> netwdog - shell script watchdog, reboot triggered by lack of default route
> nodeconfig - cuwin: clearsilver plugin, cgi+static for configuring your AP
> nsbridge - works with howl?  what's it do?
> nsd - stub, what's it do?
> pathstate - what's it do?
> pool - cuwin: memory/pool management
> radix - no licence: what's it do?
> thttpd - stub
> viz - cuwin: cgi route visualizer

Pay those no attention.

> quagga - stub

Essential, but known to compile and run on Linux.

> test - tests arithmetic, howl, misc, pack, pathstate, radix, rib, ssrv

The tests are not essential, but they will be helpful....  No need for
howl, pathstate, or radix tests, though (see above).

> arithmetic - cuwin: some crc thing?
> cxn - cuwin: manages state (of what?) ?
> etx - cuwin: beacon?
> evwrap - cuwin: wrapper for bsd event library
> hclient - cuwin: uses misc, ssrv, hsls, looks like a testing tool for 
> pinging
> heap - cuwin: heap, guts in header, .c just a test
> hitime - timer with event handler code
> hsls - cuwin: routing daemon
> libhsls - cuwin: routing daemon
> log - cuwin: logging
> misc - cuwin: misc functions
> pack - cuwin: has a README! for packing data
> rib - cuwin: routing information block handlers?
> ssrv - cuwin: library.  what's it do?
> zrib - cuwin: library.  what's it do?

All of those are important to port.  Some of them are trivially ported.

> But, what are event and util?  are they stock bsd libraries?

libevent is Niels Provos' event library, which is portable to Linux.
See event(3).

libutil provides pidfile(3).  See util(3).  You will also need daemon(3)
which is in libc rather than libutil.  I recommend lifting the source
for those from NetBSD, since it is known to work.

> electricfence doesn't sound like something you've written.  It would be 
> helpful to identify from this list which you've written and would need 
> porting vs which you've imported and already likely has a port.

If it's in the 3rd-party sources, cuw-trunk/extern-src/, CUWiN did not
write it.  If it's in the "first party" sources, cuw-trunk/src/, CUWiN
did write it, with exceptions duly attributed---e.g., sockaddr_snprintf
by Christos Zoulas.

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933