Re: 2.5.28 and partitions

From: Marcin Dalecki (
Date: Thu Aug 01 2002 - 05:08:20 EST

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. (

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
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:15 EST