[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [PATCH] guess_fstype applet
From:       James B <jamesbond3142 () gmail ! com>
Date:       2013-08-23 4:20:22
Message-ID: CA+wkPBTQrNACWQt9W7nOYr+-oBGnyaAGfj2zCV0YpsLfuSic2Q () mail ! gmail ! com
[Download RAW message or body]

If the interface can be simplifed to detect filesystem only (instead
of also looking for labels and UUID) I think I think it would get an
order of magnitude speed-up (taking the cues from Puppy Linux's
original guess_fstype which basically does just that). I'm not so sure
about code-size reduction, though.

It is called guess_fstype for historical reason (because that's how it
was used and called in Puppy Linux), I'm happy to change it to
"fstype" if that helps everybody else :)

cheers!





On Thu, Aug 22, 2013 at 7:40 PM, Sven-Göran Bergh
<svengbergh-busybox@yahoo.com> wrote:
> 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@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@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);
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]