A new API for mounting filesystems [LWN.net]

A new API for mounting filesystems

Posted Apr 3, 2017 4:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: A new API for mounting filesystems by simcop2387
Parent article: A new API for mounting filesystems

Yeah, I meant NUL bytes. They're a PITA in many languages, including good old C.

to post comments

A new API for mounting filesystems

Posted Apr 3, 2017 6:30 UTC (Mon) by Homer512 (subscriber, #85295) [Link] (11 responses)

When you want to be able to handle all POSIX-compatible file names, e.g. for loop mounting, you pretty much have to use \0 terminators or come up with escape characters. Given this alternative, I think \0 terminators are preferable, especially for C.

A new API for mounting filesystems

Posted Apr 3, 2017 6:34 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

If you want to stay with pure text then you can do length-tagged pairs, something like:

12\n
INSTRUCTION1\n
23\n
/a/23/character/file/name\n

It's not terribly difficult to parse in pure C either.

A new API for mounting filesystems

Posted Apr 3, 2017 7:57 UTC (Mon) by dany (guest, #18902) [Link] (1 responses)

this works unless there is "\n" in filename, which is valid character

A new API for mounting filesystems

Posted Apr 3, 2017 7:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

The \n is not a separator - it's just a decoration to avoid long strings. The length of the key/value is specified explicitly.

A new API for mounting filesystems

Posted Apr 3, 2017 14:29 UTC (Mon) by sorokin (guest, #88478) [Link] (6 responses)

~~Shouldn't we stop reinventing the wheel and go directly for XML? (trolling)~~

You mentioned that having '\0' have some downsides, but you did not specify which ones exactly. On the other hand I see a (in my optinion) significant downside of your encoding. With known lengths of the values it is very easy to calculate the required buffer size with zero terminated strings. In your case calculating the buffer size in advance is complicated.

You can appeal that we don't care about the performance of the mount system call. I would say that later the same format can be used in other places too. Making a format difficult to generate and to parse should not be based on the fact it will be rarely used.

A new API for mounting filesystems

Posted Apr 3, 2017 17:00 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

XML is way too complex (namespaces, entities, ...) but JSON (or one of its binary counterparts like BSON) would indeed be a welcome addition.

> You mentioned that having '\0' have some downsides, but you did not specify which ones exactly.
Several languages make it difficult to work with \0-containing strings, like good old bash or C.

> On the other hand I see a (in my optinion) significant downside of your encoding. With known lengths of the values it is very easy to calculate the required buffer size with zero terminated strings. In your case calculating the buffer size in advance is complicated.
I don't follow. In a case of \0-terminated array of dynamically-sized strings calculating the total length would require traversal of the whole array with parsing along the way.

A new API for mounting filesystems

Posted Apr 3, 2017 17:33 UTC (Mon) by Homer512 (subscriber, #85295) [Link] (3 responses)

>> On the other hand I see a (in my optinion) significant downside of your encoding. With known lengths of the values it is very easy to calculate the required buffer size with zero terminated strings. In your case calculating the buffer size in advance is complicated.
> I don't follow. In a case of \0-terminated array of dynamically-sized strings calculating the total length would require traversal of the whole array with parsing along the way.

I think the point is that with \0-terminated strings, you can precalculate the buffer size by summing strlen() of the parts. With a prefixed string, you have to add ceil(log10(strlen())) + 1 or something like that to account for the length.
The simplest workaround in plain old C is to use snprintf(NULL, 0, format, …) and use the return value to allocate the actual buffer.

A new API for mounting filesystems

Posted Apr 3, 2017 17:34 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

With my scheme there are no \0 symbols in the mix. So just get strlen() of the whole thing.

A new API for mounting filesystems

Posted Apr 3, 2017 20:58 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

It's impossible to call strlen till you allocate butter and put all the data into it. And calculating size of buffer is not trivial

A new API for mounting filesystems

Posted Apr 3, 2017 21:02 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

And how is that different from a bag of \0-terminated key-value pairs?

A new API for mounting filesystems

Posted Apr 4, 2017 5:01 UTC (Tue) by jhoblitt (subscriber, #77733) [Link]

msgpack is probably the most consistent and performant binary encoded equivalent of JSON. It would certainly be a great thing to start using a standardized data interchange format rather that using a hand rolled format for anything that isn't performance critical (i.e., called 1000+ per second). However, I wouldn't hold my breath, the kernel community is still holding on to C90.

A new API for mounting filesystems

Posted May 1, 2017 3:11 UTC (Mon) by spigot (subscriber, #50709) [Link]

Sounds similar to djb's netstrings proposal.