[Toybox] Making new library or adding functions to lib.c?

[Rob Landley]

On 04/08/2013 02:31:58 PM, Kyungwan Han wrote:
> Hello,
> 
> when I make new commands, sometimes I do not add functions to lib.c  
> but
> make new library, because some functions can be categorized according
> to usage such as network or file system, and it makes maintenance  
> easier.

You mean creating different files in lib/ ? Sure.

I broke out lib/args.c, lib/llist.c, and lib/dirtree.c because each of  
those is an obvious group. The lib/lib.c file is a catchall for  
general-purpose stuff, or things that don't have enough code to justify  
their own file. I've been vaguely expecting to start a "lib/net.c" at  
some point, probably when I add a second command that shares code with  
netcat.c. (inetd, telnet, httpd, wget, a 9p server...) I'll move common  
functions from netcat into that.

The build itself just compiles lib/*.c every time it builds toybox, and  
then garbage collects the unused functions at link time with  
--gc-sections. So as far as the toybox build is concerned, there's no  
difference between having a single lib/lib.c and a bunch of lib/*.c  
files. (It's slightly slower to re-parse the headers for each file, but  
not enough to matter.) This means if you make allnoconfig and then  
switch on "true", it still compiles the whole of lib/*.c (and then  
discards most of it).

The getmountlist.c and xregcomp.c files are separate because I was  
pondering teaching the build NOT to build them unless they were needed,  
because you can switch off the things they depend on in uClibc's config  
and at one point bionic didn't have them either. But I never got around  
to doing that, and musl has support for both, so I might just merge  
them back into lib.c.

I need to move lib/bunzip.c into bzcat.c. I was thinking the code would  
be called from tar and such, but really those commands can fork a  
bunzip2 instance and pipe data through it. (Doing so would take  
advantage of SMP, in fact.) It doesn't need to be able to call it as a  
C function on a buffer.

> In my case, I made lib/inetutil.c library for ping, ping6, netstat,
> ifconfig and so on.
> (Now only ifconfig is contributed, but I'm ready to contribute other
> network features.)

I put it in ifconfig because right now nothing else is using that code.  
I prefer to put code in lib/ when there's a second user of it, and keep  
it in the only file that's using it until the second user shows up.  
It's not a big deal to move the code from one file to another once  
there's a reason to, as bunzip.c shows sometimes code stays in lib a  
long time without a second user otherwise.

> But making new library is likely to have an impact on toybox infra or
> structure. so I'd like to know which is better making new library or
> adding functions to lib.c?

I've been expecting to start a lib/net.c for a while now. Having a  
seperate file for network code seems reasonable to me.

Rob