Alexander Viro wrote:
>
> On Thu, 1 Aug 2002, Peter Chubb wrote:
>
>
>>Maybe we need to roll our own? I suggest something like:
>> struct linux_volume_header {
>> char volname[16];
>> __u32 nparts;
>> __u32 blocksize;
>> struct linux_partition {
>> char partname[16]
>> __u64 start;
>> __u64 len;
>> __u32 usage;
>> __u32 flags;
>> } parts[]
>> }
>
>
> Oh, ferchrissake! WHY??? People, we'd seen a lot of demonstrations
> of the reasons why binary structures are *bad* for such stuff.
>
> What the bleedin' hell is wrong with <name> <start> <len>\n - all in ASCII?
> Terminated by \0. No need for flags, no need for endianness crap, no
> need to worry about field becoming too narrow...
>
> What, parsing that would be too slow? Right. Sure. How many times do
> we parse partition table? How many times do we end up reading it from
> disk? How does IO time compare to the "overhead" of trivial sscanf loop?
>
> Furrfu... "ASCII is tough, let's go shopping"...
Whats wrong with ASCII processing? Easy to tell:
1. Look at bagtraq. (www.securityfocus.com)
2. It's making data *not agnostic* against i18n issues. This is
something most people forgett about. /proc is LANG=en_US. ISO8859-1 - I
do not like this language.
3. For some as of jet undiscovered reason actual application programmers
hate processing it.
4. Answer 1. should be actually sufficient.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:15 EST