[PATCH] guess_fstype applet

Sven-Göran Bergh svengbergh-busybox at yahoo.com
Thu Aug 22 12:40:41 UTC 2013


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 <jamesbond3142 at gmail.com>:
>
>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 <Ralf.Friedl at online.de> 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);


More information about the busybox mailing list