memory overhead and embedded Samba

[Christopher R. Hertel]

On Thu, Jan 27, 2005 at 10:26:09AM +1100, Luke Mewburn wrote:
> On Sun, Jan 23, 2005 at 09:10:20PM -0600, Christopher R. Hertel wrote:
>   | On Mon, Jan 24, 2005 at 01:52:03PM +1100, Andrew Tridgell wrote:
>   | > I've been thinking about possible new applications of Samba4 beyond
>   | > where Samba3 has already been deployed. One possible application is
>   | > for Samba4 to support very low memory configurations, so you can
>   | > create a functional micro-server.
> 
> There's another resource constraint issue for embedded systems:
> operating system/application disk space constraints.

Valid concern.  The unit I will be testing has, I think, 8MB.  If this
hits me in the face then clearly I'll need to talk to the folks coding
Samba4.

Right now, Samba4 makes a lot of use of auto-generated code.  There might
be some space savings there (I need to try things out to see)  or it might
be that there's a lot of code generated.  Dunno.  I'm sure someone else 
will have a comment here...  :)

> Many embedded appliances have a limited amount of storage for the
> OS image (which Samba is part of) -- e.g., 4 - 32 MB flash -- even
> if they have terabytes of space for end-user storage.

The term "OS" is a little stretched here but your point is perfectly 
valid.

> Samba 3 is a disk space pig.  I spent some work fixing this in a build
> that's part of an embedded software build.  The comparative sizes were:
> 	20+ MB	out of the box build
> 	16 MB	build tweaked to use a static library for common code
> 	3.5 MB	build tweaked to use a shared library for common code

I'm fairly sure we can do better.

> I haven't looked at Samba 4 in detail, but the principle I used
> should apply to allow the on-disk space to be smaller.

Yep.

> Side note: I find it interesting that Samba 3 uses an "automatic"
> method to keep prototypes in sync, yet uses manually maintained
> object dependency lists.  This is wrong-sided IMHO; I prefer to
> maintain prototypes manually (easier to detect API/ABI changes),
> and let the linker do its job in maintaining object dependencies...
> I've had this rant before with various samba developers :-)

My own style is probably more in line with this.  I have not had time to 
look at the Samba4 code much at all, so I really can't comment further.  
Input and collaboration is certainly welcome.  :)

> The NLSU2 uses the IXP420 CPU, which has an MMU.

I've heard.  Thanks.  I've got one ordered...

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org