I welcome an fstype applet. Was using the klibc binary before bb blkid got that capability. So +1 from me.
However, I have been looking on the volumeid framework and it has its pros and cons. I would like to revamp parts of it but currently lack the time. All the probe functions in volumeid probe for 3 things: filesystem, (GU)ID and label. The easiestone that needs to be performed first in any case is the filesystem detection. Today, the support functions do a full probe for all three (fs, GUID + label). In many cases one would like a more flexible api. In this case we only want fs detection and do not care about the rest. Here should be potential for better performance and smaller size. Sorry, that was just a personal reflection of topic... As I said, I like the fstype applet and I sure will use it. BTW: Why not just call it fstype as its klibc sibling? Brgds /S-G 2013-08-21 18:25, James B <[email protected]>: > >Because it was originally built as an independent static binary which >used busybox's volume_id code. >But you're right, now that it is an applet there is no reason to avoid printf. > >Updated patch attached with Ralf's modification. >I didn't check to see which one is shorter, though, but the code is sure >neater. > >cheers! > >On Wed, Aug 21, 2013 at 5:26 PM, Ralf Friedl <[email protected]> wrote: >> Why not use printf? It's already used in busybox, so it wont be included >> just for this applet. I'm sure it would also make the code shorter. (I do >> hope that the compiler can optimize out the calls to strlen for the constant >> strings.) >> >> How about this: >> char const *type; >> if ((!volume_id_probe_all (id, 0)) && id->type) >> type = id->type; >> else { >> type = "unknown"; >> retcode = 1; >> } >> if (argc > 2) >> printf ("%s: ", argv[0]); >> printf ("%s\n", type); _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
