linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] add /proc/*/pmap files
@ 2006-01-22  9:50 Albert Cahalan
  2006-01-22 10:03 ` Arjan van de Ven
                   ` (3 more replies)
  0 siblings, 4 replies; 11+ messages in thread
From: Albert Cahalan @ 2006-01-22  9:50 UTC (permalink / raw)
  To: linux-kernel, akpm

This adds a few things needed by the pmap command.
They show up in /proc/*/pmap files.

Signed-off-by: Albert Cahalan <acahalan@gmail.com>

---

This applies to -git4, grabbed Saturday night.

History is being made I think, with the first /proc file to have
a solidly documented syntax for future expansion and proper
parsers.

If the patch doesn't make it to the list intact, somebody
please give me a hand. Non-mangling email systems are
getting to be kind of exotic these days.  :-(

diff -Naurd old/Documentation/filesystems/proc/pmap
new/Documentation/filesystems/proc/pmap
--- old/Documentation/filesystems/proc/pmap     1969-12-31
19:00:00.000000000 -0500
+++ new/Documentation/filesystems/proc/pmap     2006-01-22
03:42:59.000000000 -0500
@@ -0,0 +1,50 @@
+general grammar of a /proc/*/pmap file
+======================================
+
+The file consists of one line of text for every memory mapping.
+Each line consists of several parts, delimited internally and
+from each other by the ' ' (SPACE) character except as described
+otherwise. From left to right the parts of a line are:
+
+1. general fields, supplied for every mapping
+2. a type indicator field
+3. type-specific fields
+4. a filename
+
+No general field will exceed 20 characters. No general field
+will contain '_', '\\', '/', or whitespace. When future
+requirements dictate additional general fields, they will be
+added to the end (between the last existing general field and
+the type indicator field).
+
+The type indicator field will start with the '_' character.
+The remainer will be composed of letters and numbers, but
+will not start with a number. The length will not exceed 8,
+including the leading '_'.
+
+Type-specific fields will not contain whitespace, '/', or '\\'.
+Unlike general fields, they may contain '_'. No type-specific
+field will exceed 20 characters. Type-specific fields will
+vary in both meaning and number according to the type indicator.
+There may be zero type-specific fields.
+
+The filename is encoded with '\\' (BACKSLASH) and '\n' (NEWLINE)
+escaped as in the C language notation used here.
+
+The very first field of the line is itself extendable by adding
+characters to the end. This is not allowed to violate the length
+or character limits for a general field. Each position must have
+a unique character associated with it, and must display as that
+character or as the '-' (HYPHEN) character. This allows parsers
+to rely on either position or character value.
+
+It is expected that parsers may:
+
+a. read general fields into an unprotected 20-byte buffer
+b. scan from the beginning for the '_' to determine type
+c. scan from the beginning for the '/' to find the filename
+d. scan from the beginning for the '\n' to find the end
+e. scan from the beginning using strchr() or similar
+f. scan field by field, skipping unknown fields
+g. parse the first field by character position
+h. parse the first field by characters seen
diff -Naurd old/Documentation/filesystems/proc.txt
new/Documentation/filesystems/proc.txt
--- old/Documentation/filesystems/proc.txt      2006-01-21
14:42:13.000000000 -0500
+++ new/Documentation/filesystems/proc.txt      2006-01-22
03:27:05.000000000 -0500
@@ -134,6 +134,7 @@
  status  Process status in human readable form
  wchan   If CONFIG_KALLSYMS is set, a pre-decoded wchan
  smaps  Extension based on maps, presenting the rss size for each mapped file
+ pmap    for pmap command; see Documentation/filesystems/proc/pmap
 ..............................................................................

 For example, to get the status information of a process, all you have to do is
diff -Naurd old/fs/proc/base.c new/fs/proc/base.c
--- old/fs/proc/base.c  2006-01-21 14:42:25.000000000 -0500
+++ new/fs/proc/base.c  2006-01-21 19:45:32.000000000 -0500
@@ -106,6 +106,7 @@
        PROC_TGID_MOUNTS,
        PROC_TGID_WCHAN,
 #ifdef CONFIG_MMU
+       PROC_TGID_PMAP,
        PROC_TGID_SMAPS,
 #endif
 #ifdef CONFIG_SCHEDSTATS
@@ -146,6 +147,7 @@
        PROC_TID_MOUNTS,
        PROC_TID_WCHAN,
 #ifdef CONFIG_MMU
+       PROC_TID_PMAP,
        PROC_TID_SMAPS,
 #endif
 #ifdef CONFIG_SCHEDSTATS
@@ -202,6 +204,7 @@
        E(PROC_TGID_EXE,       "exe",     S_IFLNK|S_IRWXUGO),
        E(PROC_TGID_MOUNTS,    "mounts",  S_IFREG|S_IRUGO),
 #ifdef CONFIG_MMU
+       E(PROC_TGID_PMAP,      "pmap",   S_IFREG|S_IRUGO),
        E(PROC_TGID_SMAPS,     "smaps",   S_IFREG|S_IRUGO),
 #endif
 #ifdef CONFIG_SECURITY
@@ -244,6 +247,7 @@
        E(PROC_TID_EXE,        "exe",     S_IFLNK|S_IRWXUGO),
        E(PROC_TID_MOUNTS,     "mounts",  S_IFREG|S_IRUGO),
 #ifdef CONFIG_MMU
+       E(PROC_TID_PMAP,       "pmap",    S_IFREG|S_IRUGO),
        E(PROC_TID_SMAPS,      "smaps",   S_IFREG|S_IRUGO),
 #endif
 #ifdef CONFIG_SECURITY
@@ -661,6 +665,27 @@
 };
 #endif

+#ifdef CONFIG_MMU
+extern struct seq_operations proc_pid_pmap_op;
+static int pmap_open(struct inode *inode, struct file *file)
+{
+       struct task_struct *task = proc_task(inode);
+       int ret = seq_open(file, &proc_pid_pmap_op);
+       if (!ret) {
+               struct seq_file *m = file->private_data;
+               m->private = task;
+       }
+       return ret;
+}
+
+static struct file_operations proc_pmap_operations = {
+       .open           = pmap_open,
+       .read           = seq_read,
+       .llseek         = seq_lseek,
+       .release        = seq_release,
+};
+#endif
+
 extern struct seq_operations mounts_op;
 struct proc_mounts {
        struct seq_file m;
@@ -1730,6 +1755,12 @@
                        inode->i_fop = &proc_smaps_operations;
                        break;
 #endif
+#ifdef CONFIG_MMU
+               case PROC_TID_PMAP:
+               case PROC_TGID_PMAP:
+                       inode->i_fop = &proc_pmap_operations;
+                       break;
+#endif
 #ifdef CONFIG_SECURITY
                case PROC_TID_ATTR:
                        inode->i_nlink = 2;
diff -Naurd old/fs/proc/task_mmu.c new/fs/proc/task_mmu.c
--- old/fs/proc/task_mmu.c      2006-01-21 14:42:25.000000000 -0500
+++ new/fs/proc/task_mmu.c      2006-01-22 03:16:51.000000000 -0500
@@ -294,6 +294,90 @@
        return show_map_internal(m, v, &mss);
 }

+/* WARNING: unlike other /proc files, this one has a well-defined
+ * grammar to ensure that future changes do not cause parsers to
+ * fail. See the Documentation/filesystems/proc/pmap file for details.
+ */
+static int show_pmap(struct seq_file *m, void *v)
+{
+       struct task_struct *task = m->private;
+       struct vm_area_struct *vma = v;
+       struct mm_struct *mm = vma->vm_mm;
+       struct file *file = vma->vm_file;
+       int flags = vma->vm_flags;
+       unsigned long ino = 0;
+       dev_t dev = 0;
+       struct mem_size_stats mss;
+       char flag_string[7];
+       unsigned shift = PAGE_SHIFT;
+
+       memset(&mss, 0, sizeof mss);
+       if (vma->vm_mm)
+               smaps_pgd_range(vma, vma->vm_start, vma->vm_end, &mss);
+
+       if (file) {
+               struct inode *inode = vma->vm_file->f_dentry->d_inode;
+               dev = inode->i_sb->s_dev;
+               ino = inode->i_ino;
+       }
+
+       flag_string[0] = flags & VM_READ       ? 'r' : '-';
+       flag_string[1] = flags & VM_WRITE      ? 'w' : '-';
+       flag_string[2] = flags & VM_EXEC       ? 'x' : '-';
+       flag_string[3] = flags & VM_MAYSHARE   ? 's' : '-';
+       flag_string[4] = flags & VM_LOCKED     ? 'L' : '-';
+       flag_string[5] = flags & VM_IO         ? 'i' : '-';
+       flag_string[sizeof flag_string - 1] = '\0';
+
+#ifdef HPAGE_SHIFT
+       if(flags & VM_HUGETLB)
+               shift = HPAGE_SHIFT;
+#endif
+
+       seq_printf(
+               m,
+               "%s %lu %lu %lu %u %u %lu %u %lu %lu %lu %lu %lu ",
+               flag_string,
+               vma->vm_start,
+               vma->vm_end,
+               vma->vm_pgoff,
+               MAJOR(dev),
+               MINOR(dev),
+               ino,
+               shift,
+               mss.resident,
+               mss.shared_clean,
+               mss.shared_dirty,
+               mss.private_clean,
+               mss.private_dirty
+       );
+
+       if (file) {
+               seq_puts(m, "_file ");
+               seq_path(m, file->f_vfsmnt, file->f_dentry, "\n");
+       } else {
+               if (mm) {
+                       if (vma->vm_start <= mm->start_brk &&
vma->vm_end >= mm->brk) {
+                               seq_puts(m, "_heap");
+                       } else {
+                               if (vma->vm_start <= mm->start_stack
&& vma->vm_end >= mm->start_stack) {
+                                       seq_puts(m, "_stack");
+                               } else {
+                                       seq_puts(m, "_other");
+                               }
+                       }
+               } else {
+                       seq_puts(m, "_vdso");
+               }
+       }
+
+       seq_putc(m, '\n');
+
+       if (m->count < m->size)  /* vma is copied successfully */
+               m->version = (vma != get_gate_vma(task))? vma->vm_start: 0;
+       return 0;
+}
+
 static void *m_start(struct seq_file *m, loff_t *pos)
 {
        struct task_struct *task = m->private;
@@ -389,6 +473,13 @@
        .show   = show_smap
 };

+struct seq_operations proc_pid_pmap_op = {
+       .start  = m_start,
+       .next   = m_next,
+       .stop   = m_stop,
+       .show   = show_pmap
+};
+
 #ifdef CONFIG_NUMA
 extern int show_numa_map(struct seq_file *m, void *v);

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add /proc/*/pmap files
  2006-01-22  9:50 [PATCH] add /proc/*/pmap files Albert Cahalan
@ 2006-01-22 10:03 ` Arjan van de Ven
  2006-01-22 10:38   ` Kyle Moffett
  2006-01-22 10:39 ` Willy Tarreau
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 11+ messages in thread
From: Arjan van de Ven @ 2006-01-22 10:03 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: linux-kernel, akpm


> 
> This applies to -git4, grabbed Saturday night.

with this much wrapping... no it doesn't ;-)



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add /proc/*/pmap files
  2006-01-22 10:03 ` Arjan van de Ven
@ 2006-01-22 10:38   ` Kyle Moffett
  0 siblings, 0 replies; 11+ messages in thread
From: Kyle Moffett @ 2006-01-22 10:38 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Albert Cahalan, linux-kernel, akpm

On Jan 22, 2006, at 05:03, Arjan van de Ven wrote:
>> This applies to -git4, grabbed Saturday night.
>
> with this much wrapping... no it doesn't ;-)

Err, the patch looks fine to me.  I just checked and I can't find any  
wrapped lines.  Mail client confusion of some sort?

Cheers,
Kyle Moffett

--
Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add /proc/*/pmap files
  2006-01-22  9:50 [PATCH] add /proc/*/pmap files Albert Cahalan
  2006-01-22 10:03 ` Arjan van de Ven
@ 2006-01-22 10:39 ` Willy Tarreau
  2006-01-22 14:32 ` Jan Engelhardt
  2006-01-22 14:36 ` Arjan van de Ven
  3 siblings, 0 replies; 11+ messages in thread
From: Willy Tarreau @ 2006-01-22 10:39 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: linux-kernel, akpm

Hi Albert,

On Sun, Jan 22, 2006 at 04:50:17AM -0500, Albert Cahalan wrote:
(...)
> If the patch doesn't make it to the list intact, somebody
> please give me a hand. Non-mangling email systems are
> getting to be kind of exotic these days.  :-(

It failed :
 
> diff -Naurd old/Documentation/filesystems/proc/pmap
> new/Documentation/filesystems/proc/pmap
> --- old/Documentation/filesystems/proc/pmap     1969-12-31
> 19:00:00.000000000 -0500
> +++ new/Documentation/filesystems/proc/pmap     2006-01-22
> 03:42:59.000000000 -0500

You seem to have used a web interface, you might try to tune its options
to accept very large lines (more than one hundred of chars). Also, you
might try to attach it as text only, with some mailers, the file remains
intact and does not need any decoding on the receiver side.

Regards,
Willy


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add /proc/*/pmap files
  2006-01-22  9:50 [PATCH] add /proc/*/pmap files Albert Cahalan
  2006-01-22 10:03 ` Arjan van de Ven
  2006-01-22 10:39 ` Willy Tarreau
@ 2006-01-22 14:32 ` Jan Engelhardt
  2006-01-22 20:02   ` Albert Cahalan
  2006-01-22 14:36 ` Arjan van de Ven
  3 siblings, 1 reply; 11+ messages in thread
From: Jan Engelhardt @ 2006-01-22 14:32 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: linux-kernel, akpm


>This adds a few things needed by the pmap command.
>They show up in /proc/*/pmap files.

But my pmap command works without the /proc/$$/pmap file?

>If the patch doesn't make it to the list intact, somebody
>please give me a hand. Non-mangling email systems are
>getting to be kind of exotic these days.  :-(

Send it as MIME attachment then :o)



Jan Engelhardt
-- 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add /proc/*/pmap files
  2006-01-22  9:50 [PATCH] add /proc/*/pmap files Albert Cahalan
                   ` (2 preceding siblings ...)
  2006-01-22 14:32 ` Jan Engelhardt
@ 2006-01-22 14:36 ` Arjan van de Ven
  2006-01-22 19:17   ` Albert Cahalan
  3 siblings, 1 reply; 11+ messages in thread
From: Arjan van de Ven @ 2006-01-22 14:36 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: linux-kernel, akpm

On Sun, 2006-01-22 at 04:50 -0500, Albert Cahalan wrote:
> This adds a few things needed by the pmap command.
> They show up in /proc/*/pmap files.


also since this shows filenames and such, could you make the permissions
of the pmap file be 0400 ? (yes I know some others in the same dir
aren't 0400 yet, but I hope that that can be changed in the future,
adding more of these should be avoided for information-leak/exposure
reasons)


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add /proc/*/pmap files
  2006-01-22 14:36 ` Arjan van de Ven
@ 2006-01-22 19:17   ` Albert Cahalan
  2006-01-22 19:44     ` Arjan van de Ven
  0 siblings, 1 reply; 11+ messages in thread
From: Albert Cahalan @ 2006-01-22 19:17 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: linux-kernel, akpm

On 1/22/06, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sun, 2006-01-22 at 04:50 -0500, Albert Cahalan wrote:
> > This adds a few things needed by the pmap command.
> > They show up in /proc/*/pmap files.
>
>
> also since this shows filenames and such, could you make the permissions
> of the pmap file be 0400 ? (yes I know some others in the same dir
> aren't 0400 yet, but I hope that that can be changed in the future,
> adding more of these should be avoided for information-leak/exposure
> reasons)

I thought it was the addresses you'd object to.

I was thinking I'd follow up with a patch to make things
a bit more logical as far as info exposure goes. It makes
no sense to have the /proc/*/exe link fail a readlink()
when one can reliably guess that data from elsewhere.

I notice that Fedora Core 4 shipped with /proc/*/smaps
files that were readable, but /proc/*/maps files that were
not readable. (at least, a recent kernel update did)

As of now, I'm keeping mainstream kernel policy as is.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add /proc/*/pmap files
  2006-01-22 19:17   ` Albert Cahalan
@ 2006-01-22 19:44     ` Arjan van de Ven
  2006-01-22 19:58       ` Andrew Morton
  0 siblings, 1 reply; 11+ messages in thread
From: Arjan van de Ven @ 2006-01-22 19:44 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: linux-kernel, akpm

On Sun, 2006-01-22 at 14:17 -0500, Albert Cahalan wrote:
> On 1/22/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > On Sun, 2006-01-22 at 04:50 -0500, Albert Cahalan wrote:
> > > This adds a few things needed by the pmap command.
> > > They show up in /proc/*/pmap files.
> >
> >
> > also since this shows filenames and such, could you make the permissions
> > of the pmap file be 0400 ? (yes I know some others in the same dir
> > aren't 0400 yet, but I hope that that can be changed in the future,
> > adding more of these should be avoided for information-leak/exposure
> > reasons)
> 
> I thought it was the addresses you'd object to.

well both ;)

knowing that you're listening to Mrs Stefani's music rather than
watching her music clips is something you might not want to spread to
other users of your system. Or in other words, open files already
disclose "private" stuff. 

> I notice that Fedora Core 4 shipped with /proc/*/smaps
> files that were readable, but /proc/*/maps files that were
> not readable. (at least, a recent kernel update did)

that'd be a mistake


> As of now, I'm keeping mainstream kernel policy as is.

you're making a NEW file, so there is no "mainstream policy" yet. Please
do it right the first time so that it doesn't have to change later...



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add /proc/*/pmap files
  2006-01-22 19:44     ` Arjan van de Ven
@ 2006-01-22 19:58       ` Andrew Morton
  2006-01-22 20:40         ` Albert Cahalan
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Morton @ 2006-01-22 19:58 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: acahalan, linux-kernel

Arjan van de Ven <arjan@infradead.org> wrote:
>
>  you're making a NEW file

One which, afaict, contains the same thing as /proc/pid/smaps only in a
different format.  If there's a point to this patch, we weren't told what
it is.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add /proc/*/pmap files
  2006-01-22 14:32 ` Jan Engelhardt
@ 2006-01-22 20:02   ` Albert Cahalan
  0 siblings, 0 replies; 11+ messages in thread
From: Albert Cahalan @ 2006-01-22 20:02 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: linux-kernel, akpm

On 1/22/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
> >This adds a few things needed by the pmap command.
> >They show up in /proc/*/pmap files.
>
> But my pmap command works without the /proc/$$/pmap file?

The -x option doesn't show locked memory, etc.

I'll still be missing a few things, but perhaps they just
don't make sense for Linux today. Solaris has them.

For example, Solaris can report how much swap space
each mapping has reserved and how much it has used.
I don't think we remember per-mapping reservations yet
AFAIK, Linux can't tell which mapping to blame if we run
out of memory.

If mlock() might work on only part of a mapping, then
a mere flag won't do. Adding this later is now easy,
though the flag would need to remain.

> >If the patch doesn't make it to the list intact, somebody
> >please give me a hand. Non-mangling email systems are
> >getting to be kind of exotic these days.  :-(
>
> Send it as MIME attachment then :o)

Doesn't the mailing list trash posts with MIME?
I still remember how to use uuencode though:

begin 644 diff.gz
M'XL("/%&TT,"`V1I9F8`K5GY5^-&$O[9_BLZDY?!Q@>VN0(L9!S&`^QP/0P[
MF;>3YR=++5L/75%+9LCN_._[5;5.8P))EAELJ5557?75V<)R;%MT+HTDLD3@
M6AOO`S/QI!\;L1/X&[;C2O6H8NFIC3`*S(W0,T+ARX?7T-4[G<YK9=;Z>SM[
MG?Z@L]D7_;W]7@__N[WL1W1ZV[U>O=5JO7;OVJ#7V^GT^IW!0/0V][<&^]M[
M3^2]>X>+=D^T^NWMGGCWKMZ:25]&ABMFD>%Y1B0"6QA"2UW7MM-N]=;AJW[J
MK7KK=BZ91YB!KQP5*Y(9^%*X#CYP'<NOL;"#2,B%C!Z%)[V`OHPP=/Q9M]X:
M&>9<$Y<E***&HJ$1Q:HM+.DZGA-+2SA^+"/?<-U'8?A6O65'@2<DR0CBN8S$
M]%'@6ZSA7V-\/3P>-84Y-R+#!)N07TT9QL)0$*C,R)E*2&"^!T?)KOA`PEQI
MQR(.1.3,YC$+8R4T5JRH$<E]LKW?%1F@MB-="XJJ)`Q=!WJ6+-:FUEN#+@3$
MCZ&$$99C&C%(F*_>VNSR@XX*I>G8CIG*J[>VB(?P]0U/TIZ7075/\>"X+AN&
M30>]PEC5%<NT]183`^?8<'RQ-EEKB[4O7^AS`Q]0YV$.D%5HF`#CTUSZPD[B
M),+&D?PM<2))40GP'!.Q"1PLRZ$0I8!:P@&P/6K5IN`&(;0#IH2F]"W1F,KX
M04(^+;B&BF$!7`^8EJQC'Q/1*MR:W2P"5SW5VZL8SL-E/-=Q,5DK(.IJ9I@%
M.!`>J;X`R`L#!8WA<E?&!"8I(OS$F^*Z+:9)G&+I!W%Y"R.EZ0H2#*_-L)@3
MIE[ZL5UO.;[I)A;9RPA(@Z^AG39I12P48C+_%<XJ'$CNA(@[WW7NY6JO>,9C
M.00X3"K!AZ1Z*;*>5;#>6AB(>8B>(J^0[89/AA7H"<,T@TA;KN.AZCOMDTBR
MFO#%[S(*5N9&MUQ]*#N$HQ!;9D"AQLX@+$3CY^'QQ_'Y<'S:9"W6OOA8O!Q]
M.C^['#7K+=0!(P0':H*CP_$8`>G/$F,F"6VNP2*A:""U\ETYM6TG0NAJM*C4
MS=.R!TV<6$G7!GPQXMV8HD"B,E'"4"4HH"PE!<4,,2IV,BI<\*"39N$$+J5;
MG(<4BE94*FM<&Q67'*/J\Z[@\HIHYD057@)]Y\:"<E(DOO-;(DMR#*4"TS'B
M#$`G;C-FS&4Y*G3A$P`5SXVX9`3%':\BO3H`]_3S]>GHLE1W4\O8)$755,%R
MI#5JK$0=AU[2X>*=ZUDQ;V&XB0;^+&8G?T4DD)*D1R:.XH6+LM&%5,-:BGWJ
M&P&,@='H=K'F'_0ZTT<`.TUL6T;UUK0K$`TH>M0&R)RIG#D^!S!AF]4/"+(D
M%//(U12:P.(5G!O,:2/2^;XHZM8KF"EJR]R2ZJ)\GC%1]*GBR)Q'C2;AJ1`D
MK@$K[8R+PW;ZJ"_0NNX=;E2`Z-X/'OR\!\VZ&N14[2+DP5MX*?-=O35_#;U"
MBY=^W?I3XUDWQBSQ\H1$9*\<SHBTF*4PFVW1+-7?_(NS654<CV:#W?W>]LK1
MK+^YU=[!<(:O79K.!'62.%%"7$.45"J[1V&:)QY<1H'-M01QX8G\!YP/`-;'
MY9DMCJ\N/YR=3#X.S\_'GR_&E#%*4B:+,)(=2Z85DAAH2XPGJB9&5*<4I=[4
MX,[GT]R"E@$>!7.S3A615L[O4L\W5%MHO*%YA^=&P3,D?N@Q7Z.70G/K@-PM
M7C-4B^[_]:<.=#Z0KE\-+W31*6,:BO1<E\-+<.I"ST->J.%O4\42CT'"%9/3
M/@":3V+63M4GY+HF1TEU*8_%ZO+3N!ML/QMW?\"ZM[^UO;\Y6!UCO1V.,7SI
M&*M=WUP=3VY/SMY/+J[N+F_'[<K:I^/3X266OG=L2^:Q='%Q5V^5J*XOAM=5
MOC%62-3W*$R.O<P_/CX=O1_?#F_'6JDMK=36;E6I%3J]2J4G&OU9A0:]`2DT
MZ&696!LU"MM&OXS::::]D5_E&WTSGIQ].+_\^%]\WWSZY>[DJME>XDMM83XO
M2#`Y$ROQW8Q.F"_E6F5961`;ERI`.<(:K)!38=(`:"9.\N>XGD%H='QW<W;[
M6>.SQ95J4#@LVZD*S^OQJ<+S-_"IPE/"YP\!JN+S]P':V>D30#L[V^V!1NC;
M0<%8;ZVP@";#R*<6G9@X0\C?)D&(@86JD.(*-`D=:T+FX,%!O47%"L,OYAB1
M+DJ_D7([/FJZ6.>O=B:23^7K](DQ]S^`+%V/#74_2:_7Z48<ZOWHNL$RFMBO
M1CM%J)2'F7)^@X2UQ=ME[32Y+1K?@;XI:*]:R2ZMB`=!=-4Y"B-G@2%S8AFQ
M09PU+U\##6E!J]_P"W%)1&TOQLHWFNY2%$HF/H4M12=;/&2%NF1`K798@->F
M5>JHM$IZTC4ONBZ:U7VVS#<I,0YJ2N;D?(<G\'4K]76K+O[0L3K.V:,9!2NM
MUZ&I>(*<=Z"+YNYFCZOF[O9VNS_0:5BKL;\Z1\[$#D*8JGW#X5S:]H!)IS#P
MO@C+54%9JYDP2512:W]I^:2\OGK_)1>PD[/M6R^DDUC687A[>[-?M16G6Y_"
M=G#P;#/F*/>\9*DA%\M/FG+QZ"\UYE7L/`#V=_:W^RN;\V!/EU5\[?6T0].(
M5_/@84(@9J^[&EY;+)!ZGE+(-O&-BLK&NO@TO+D\NSS9Q\S.!W[]#HP5XN3@
M,S\&0'HA-\<9S1`/TG4Q!.(@0>^^Q'K^*A#C#2;`))+Z6*5?_-"\[L^DHLF'
M7ST8.`GG1ZXX8`FVX;A=,99ZX'_-"U:.:QH1<8X",YWEQ?I&I<8Q`D3<>%I)
M`$7@6&)]\7)A*TK+04&X\"8&@C&G77@&2!<E"L_+'WI4N$#1.0*;YY6(B@);
MHJ#;K'K:KC%3Y6=T3P\3C-HS.$"X`>9JA#6(>O3`DHL)CMIRD2UD^D@HA+%[
M0@BABB@60X<IWH24Q83^[]U?*]+5W+&I?E\/3T:3\>G9A]L#JJ$U2,.)H$'!
MU!:]-@_T&'QU;.E*7AC<Y&K.!26<69.(XH$>MW.S^/U7<8OTS@.UE8KC+E1I
M#.66M01?Y\B>6(B@Z+%S9$V8@BN(AB4O`FK:.5(@9+_5-(CY0URD302?98AZ
MOU(?8L>\%?^ZF-R,AN_3V>$GL1:MB7UZB7&PQ-5?XOJ$4C7*N1Z>X1HL<6%2
M.B[V^OH,U^82U\7P\_AT>#/27.H9KJTEKO.KXX^C]]E>Y\]P;2]QG5WEATIP
M.<]PI?%26A(=P1"M?>FML=?3XGY:A!Y'0J.TU^G=R>CV_&<=7VFDGE9"->^I
MR`-D/Q+9C^T&3PS4CVMO?E#B!S<I?O5_M_A:^GW#;"6]^;X:Q^45"N7R?3@+
M;)M7+H;_O+II(/B:^O;LLGR+Z&OG9O$5T@'C@W(HKO,%A?R5UL3$'.$O+UI.
M%#_FB]G(5"7-!RFBQ>(S"4?0);&B%O)&E]`WG.?ZB1'/Z4F6>`M;>5!15!,1
MG%]\S?5-2$Q$6C3MA`JA;RIU0[\3_P<*,"HPWTRFT;UX^[9<)L21?HXGF8PE
M;><2T[Q6MK+QBYOATWQNNQ)%ONW2OOPPVWAIYR52;KD%J5:5/BM<59Z%I8*4
MY5M>I5(2DTCH?5_)FU#:I`%1_(,:&J5?4PBT?VI<Z.YF$-*?G%1BTFL+.Z$_
MCE$[Y<EZ@4Y-;S8.&2_QW2&]_IC,*&YPWZ`^V6S^5"WF^[KYI,-(+QV^1=J>
M=?--25>V9Q=I@CZV'@:J62\/M2^U:)J*-G_<HZEH:W>SW=_44U&7I@$:NVDH
M4/R6B,Y7-#"\YO24'0%888@II7K7Q[C.2W31UE1!F!(%H5XI[<[OJ'CB7YY@
;+^\NAOGTGX\P?N(9DY?&&++E?XQ&+`*I'@``
`
end

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] add /proc/*/pmap files
  2006-01-22 19:58       ` Andrew Morton
@ 2006-01-22 20:40         ` Albert Cahalan
  0 siblings, 0 replies; 11+ messages in thread
From: Albert Cahalan @ 2006-01-22 20:40 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Arjan van de Ven, linux-kernel

On 1/22/06, Andrew Morton <akpm@osdl.org> wrote:
> Arjan van de Ven <arjan@infradead.org> wrote:
> >
> >  you're making a NEW file
>
> One which, afaict, contains the same thing as /proc/pid/smaps only in a
> different format.  If there's a point to this patch, we weren't told what
> it is.

First of all, it isn't just the same. I need to know if
memory is locked or not. I need to know the page size.

Second of all, smaps is surely a parody of bad file
format design. When I first heard of the patch, I was
certain that it would be rejected for that reason.
At the time I was to sick and busy to even comment
on the matter. It was with shock and horror that I
later found the patch in the kernel.

I can't just fix smaps now, because that would break
a rotten ABI. Patching it out should work OK though,
because it is recent enough that apps will still support
kernels without it. I would have done so with this patch,
but you supposedly don't care for big patches.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2006-01-22 20:47 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-22  9:50 [PATCH] add /proc/*/pmap files Albert Cahalan
2006-01-22 10:03 ` Arjan van de Ven
2006-01-22 10:38   ` Kyle Moffett
2006-01-22 10:39 ` Willy Tarreau
2006-01-22 14:32 ` Jan Engelhardt
2006-01-22 20:02   ` Albert Cahalan
2006-01-22 14:36 ` Arjan van de Ven
2006-01-22 19:17   ` Albert Cahalan
2006-01-22 19:44     ` Arjan van de Ven
2006-01-22 19:58       ` Andrew Morton
2006-01-22 20:40         ` Albert Cahalan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).