expand_number(3) support for tmpfs -o size and -o maxfilesize

[Oliver Fromme]

Alexander Best wrote:
 > Oliver Fromme wrote:
 > > That's expected behaviour ...  The function vfs_scanopt()
 > > is used to parse the size argument using the "%qu" format,
 > > expecting the number in bytes.  So if you write "500m",
 > > it stops at the "m" and simply parses the number as 500
 > > bytes, which is below the minimum size (4 KB), so it falls
 > > back to the default maximum size which is the total amount
 > > of memory available (RAM + swap).
 > 
 > i see. since the "m" gets ignored there's no chance of detecting a value
 > that doesn't comply to the "%qu" format? and maybe issuing a warning that
 > the size value was invalid?

It's possible to do that, but it requires a complete rewrite
of how options are parsed in the vfs code.  Personally I
don't think it's worth the trouble.  Normally a user notices
the problem quickly when he types "df" (as you did).

The problem is that vfs_scanopt() uses vsscanf() which works
similar to the userland function with the same name (though
it's not identical).  vsscanf() only returns the number of
items successfully converted, which is 1 in this case.
The problem is that the *scanf() API is rather stupid.

The simplest solution might be to add a new flag to *scanf()
indicating that unit suffixes (K, M, G, T) are allowed and
parsed appropriately.  But you still won't get a warning if
there's an invalid suffix.

A work-around would be to add %n to the conversion, which
returns the number of characters consumed so far.  If it's
less than the total length of the string, then there is
some trailing garbage, obviously.  Another, possibly simpler
way would be to add %c and check if the result is 2.

Another problem is that the mount code in the kernel cannot
return a warning to the mount(8) utility.  It only returns
success or failure and an errno code.  So, the only thing
you can do is print a kernel message that goes to the dmesg
buffer and to the console (and probably some log file), but
not necessarily to the terminal of the user who is executing
the mount command.

Best regards
   Oliver

PS:  From my signature collection:

"The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired."
        -- Chris Torek

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Perl will consistently give you what you want,
unless what you want is consistency."
        -- Larry Wall