[uClinux-dev] in.h and Ethernet
tom at cyberiansoftware.com
Thu Nov 22 21:52:04 EST 2001
"Kendrick G. Hamilton" wrote:
> On Thu, 22 Nov 2001, Bruce Paterson wrote:
> > "Kendrick G. Hamilton" wrote:
> > >
> > > Bruce,
> > > we are using busybox for ifconfig under linux 2.0.38
> > Thanks for that. Yes that would appear to compile fine. I had a bit of a
> > mismash of stuff between
> > busybox and others and I have rationalised my app list a bit (it's only
> > when you get
> > to the busybox part of the new makefile system you realise you should
> > have said No to a lot
> > of the earlier questions). Actually its easier editing the config file
> > by hand.
> > You mentioned in another list email about some small mods needed to the
> > ethernet driver to get it
> > working with 2.4.x (as distinct from 2.0.38). What were they ?
> > I have the mleslie 2.0.38 version working fine, but I'm hoping the 68k
> > memory leak problems with
> > 2.4.x may be found soon (who knows I might even find one).
> We would run free then another program then free again. Free was reporting
> less and less free memory. Our system only has 2Meg of RAM so we would
> eventually run out of RAM.
> As for getting 68EN360 ethernet support working under 2.4.x kernel, see
> Rubini and Corbet, Linux Device Drivers, 2nd Edition. The CVS release of
> the 2.4.x kernel included the 2.0.38 code(I think) but did not try
> compiling or linking it with the kernel.
I am not aware of any memory leaks in the 2.4 kernel, you can get a
problem of fracturing the memory by alloc/free too many times. There is
a tendancy for the memory to become broken into smaller fragments and it
not being viewed by the o/s as being contigous. I believe that this
tends to happen normally (if you really insist on many alloc/free cycles
in your application code. This may also tend to happen if you have a
daemon and a lot of forking is occuring, then when you attempt to do
something like alloc a 400K block, it may fail.
There is more indepth information in the archives about this:
http://uClinux.home.at, check there.. This is one of the drawbacks of
not having an MMU, the uClibc library does have two memory allocators:
simple and complex. The uClibc is normally running in the simple
malloc/free mode (default), This tends to fragment more, but is faster
than the more complex allocator.
DavidM, correct me if I am wrong here..
Tom Walsh - WN3L - Embedded Systems Consultant
"Windows? No thanks, I have work to do..."
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
More information about the uClinux-dev