On 01/22/2016 11:25 AM, enh wrote: >> I'm promoting three of the commands you _are_ using in pending this >> release cycle. Trying to get ahead on that... > > don't just look at this list: > > toys/pending/dd.c \ > toys/pending/expr.c \ > toys/pending/lsof.c \ > toys/pending/more.c \ > toys/pending/netstat.c \ > toys/pending/route.c \ > toys/pending/tar.c \ > toys/pending/tr.c \ > toys/pending/traceroute.c \ > > make sure you look at what we actually link to. dd and traceroute > still come from BSD and iputils respectively. i may as well stop > building toybox traceroute because i don't think the kernel networking > folks have any interest in moving off iputils.
Understood. My roadmap includes system bootstrapping with a minimum number of packages (ideally kernel, libc, toybox, toolchain). Building a minimal system you can then build more packages under. It's Android decision of the want to use other packages' version of some of those tools, but I still need to provide the complete toolset in that use case. If I'm cross compiling to bootstrap a new target (j-core and hexagon and so on), I need the tools necessary to natively compile the tools on target (under an emulator or on prototype boards) to break the chicken and egg problem of system bootstrapping. Traceroute is in there because it was contributed, and because it's useful on minimal routers and such, and there's a certain amount of pressure towards feature parity with busybox, but it's not central to toybox's goals the way "dd" and "grep" are. Building one natively after a minimal development environment is up isn't a big deal. (That said, once ping is in, traceroute's well over halfway done.) > actually, the "two layers of pending" is more interesting than that... > you don't consider grep pending, for example, but my notes have both > missing features on your side, and C library stuff for me to > investigate on our side: > > grep --- missing -A, -B, -C, color. Yeah, I have that in my todo list here. (As is some backref stuff for parenthetical matching, Izabera on irc was getting me some test cases for that.) Grep got to a good stopping point, but it was incomplete, and turned out to be relying on some glibc extensions that I since ripped out. I'm working as fast as I can but there's so much to do... > compare performance with BSD > grep before switching; BSD grep has work arounds for performance in > the BSD regex implementation. So does gnu grep, according to a post I read it basically mmaps the entire file and runs regex against the whole thing when it can. I can implement something like that, but correct behavior's come before performance so far. (I tried to work out a design using fixed size block reads but no fixed size is guaranteed to hold an entire line, and if a regex match crosses a line boundary how do you know where it would have started? Basically have to back up to the start of the previous line, which may not be in the block...) Oh, and it should work with embedded NUL bytes so you can grep binaries... (Often when I'm not picking at something right now it's because to do it RIGHT is a larger and more elaborate tasks than is immediately obvious. See ps and the ongoing top rewrite...) > but dd and grep are low priorities on our side because we've long had > high-quality implementations of those anyway. Indeed. I hope to eventually offer better versions, but I don't yet. I don't recommend using worse code just because it's toybox. I welcome feedback to help improve toybox, but A) I realize that sort of evaluation is significant work on other peoples' part they're not obligated to give me, B) my todo list is already full of massive piles of stuff I already know I need to do, C) displacing "good enough" is really hard and migrating has its own cost. So I'm just doing the best I can as fast as I can... > ps is the > highest-profile tool that still needs replacement. I'm pretty happy with the current state of ps; the file's still changing because of top and because I'm factoring out common code to move to lib/, but the one in the upcoming release should be worth evaluating. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
