Re: 2.5.28 and partitions

[Marcin Dalecki <dalecki@evision.ag>]

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.