> According to Jeremy Fitzhardinge:
> > On 26-Apr-99 Stefan Monnier wrote:
> > > open("/proc/meminfo", O_RDONLY) = 3
> > > fstat(3, {st_mode=0, st_size=0, ...}) = 0
> > > mmap(0, 0, PROT_READ, MAP_PRIVATE, 3, 0) = 0
> >
> > This is the problem. It stats the file, mmaps 0 bytes from it and finishes
> > with no action. Presumeably if the mmap failed or stat said the file isn't a
> > regular file it would use normal read.
>
> Hm. Would it be a Bad Thing for mmap to fail on /proc files that
> don't report true sizes?
> --
I don't know. And I don't know how to make it fail. I understand that
the reason why most sizes are not reported are that sizes are dynamic,
i.e., /proc/interrupts is bigger each time a value increase over 10. Since
the /proc file-system does know when a directory access is made, it
might be a good idea to actually calculate the length (but only at
directory access time, not when data are being accumumated which would
be a large overhead that is wasted because /proc is seldom read.
It is also possible to just return a size of, maybe, 1024 bytes for
each of the files that are normally 0 size. I don't think a premature
EOF would affect most Unix tools. This would have zero overhead and
might make life easier.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/