On 02.12.2011 07:05, Vladimir Serbinenko wrote:

>> P.S.  Do you know if there are any plans in the future to implement
>> write operations for filesystems?  (I noticed raw disk writing is
>> currently supported.)  If not, is the reason due to the technical
>> challenges (e.g. NTFS only had read-only access in GNU/Linux for quite
>> a while) or just a general lack of interest?
> Neither. Reliability concerns. Writing to filesystem is potentially
> dangerous and needs to be throughly tested. Since writing is rare for
> bootloader we won't receive enough testing of these code pathes so every
> write will remain a risk. We can't have such risks
I see. Just curious.

>>> Thanks for this. However the coding style isn't according to our
>>> standards. Could you adjust to the standard? I recommend looking at
>>> other code and reading GNU Coding Standard. E.g. we don't use {0}
>>> initialiser, return value of commands, C++ comments or M$-$tyle
>>> variables.
>> Sorry about that.  I've reviewed the standard and perused the source
>> tree, as you suggested, to determine the best style.  Attached is my
>> updated file.
>>
> Much better. There are still few problems like the arbitrary limit (we
> avoid any arbitrary limits, you have one easy to avoid on filename
> length). Also we don't use such ABORT macros as they offer no
> readability advantage. Review in more details when time permits.
Argh. I remember reading about avoiding arbitrary limits too.

I would contend that in this case the macros do improve readability (each
reducing 4-5 lines of code down to 1-2 lines); yet, to be consistent with the
rest of the source base, I've removed them.

Here's the file again.  Maybe the third time's the charm?

Thanks for being a stickler for conformance ( I mean it :) ),
Peter Lustig