On Wed, Apr 04, 2007 at 03:18:41PM +0400, Nikita Danilov wrote: > This pushes binary data to the user space. Wasn't /proc supposed to be > ascii-based to avoid compatibility problems (e.g., size of unsigned long > changing, endianness, etc.)?
Most of what's in /proc is ASCII, true. But there are notable exceptions - kcore, auxv, mem. This is just another window into memory like kcore and mem. It's also a fairly big window. To examine a 1G mapping, you need to read 1M of data. ASCII would be rather ugly here. It's important that the interface be seekable so that you can skip over wide ranges of data with no maps. So all the elements would have to be nice fixed sizes. That'd mean 16 hex digits plus a space/newline. So to figure out what's at b7f81000, I'd have to divide by 4096 (I already have to know the page size), then multiply by 17, getting c37791. And then I'd have to copy more than 2x the data in byte-wide chunks due to alignment concerns. With the extra translation on both ends, the expanded data size, and the alignment issues, this probably just got 10x-20x slower. Which means taking a snapshot of a typical system and doing any sort of live display just got a hell of a lot more impractical. Now I could adjust these to only export u64s in some preferred endianness. But given I already need details like the page size to make any sense of it, it seems unnecessary. Also, the PFNs are fairly opaque unless you're attempting to correlate them with /proc/kpagemap. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
