This adds a few things needed by the pmap command.
They show up in /proc/*/pmap files.
Signed-off-by: Albert Cahalan <[email protected]>
---
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);
>
> This applies to -git4, grabbed Saturday night.
with this much wrapping... no it doesn't ;-)
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.
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
>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
--
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)
On 1/22/06, Arjan van de Ven <[email protected]> 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.
On Sun, 2006-01-22 at 14:17 -0500, Albert Cahalan wrote:
> On 1/22/06, Arjan van de Ven <[email protected]> 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...
Arjan van de Ven <[email protected]> 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.
On 1/22/06, Jan Engelhardt <[email protected]> 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,[email protected]/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<[email protected]+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
On 1/22/06, Andrew Morton <[email protected]> wrote:
> Arjan van de Ven <[email protected]> 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.