When I do 'ls -l /proc/*/*' I see that all files have 0-length. And non-empty content can be seen for most of them, for example for /proc/curproc/cmdline.
Responsible Changed From-To: freebsd-bugs->imp Hi WArner, you touched procfs a couple of times (from the ident strings on the procfs files) can you have a look please?
Responsible Changed From-To: imp->freebsd-fs OK Warner wasn't the right person to redirect to, forward over to the FS group
State Changed From-To: open->closed After a bit of discussion, this is not something which we are going to fix. It is not worth the hassle. If you think this should be different, we do welcome patches. Thanks fo rusing FreeBSD!
On Wed, 20 Feb 2008, remko@FreeBSD.org wrote: > After a bit of discussion, this is not something which we are going to fix. > It is not worth the hassle. If you think this should be different, we do > welcome patches. Thanks fo rusing FreeBSD! Just as two data points here: Solaris attempts to provide coherent file sizes in /proc (at least to the extent that tried a few for objects where it is remotely possible), and the Linux 2.6.12 kernel I have on a box locally basically doesn't. My view is that it's a synthetic file system with data that varies dynamically at runtime, and that while it wouldn't hurt to produce file size information that's correct, it's quite a bit of work to do so and that I wouldn't prioritize it above other, more critical things that need to happen. We should certainly evaluate any patches that come in for possible inclusion, assuming they don't muck up the internals of procfs too much; it's not clear to me if they necessarily do so or not. Robert N M Watson Computer Laboratory University of Cambridge
Robert Watson <rwatson@FreeBSD.org> writes: > Just as two data points here: Solaris attempts to provide coherent > file sizes in /proc (at least to the extent that tried a few for > objects where it is remotely possible), and the Linux 2.6.12 kernel I > have on a box locally basically doesn't. Correct; neither to more recent Linux kernels. 2.6.12 is ancient! :) > My view is that it's a synthetic file system with data that varies > dynamically at runtime, and that while it wouldn't hurt to produce > file size information that's correct, it's quite a bit of work to do > so and that I wouldn't prioritize it above other, more critical things > that need to happen. Most of the time, it can't be done. Some of the files in /proc have a fixed size (/proc/$$/{,db,fp}regs for instance), but others have highly variable content, and there is no other way to figure out how large it is than to generate it. Even then, it may change between the stat(2) call and the read(2) call. A good example is /proc/$$/status, which among other things contains a textual representation of the process's user and system time in seconds and microseconds. A process reading its own /proc/$$/status will get inconsistent results. As for /proc/$$/map, the simple act of malloc()ing a buffer for it may change its contents if jemalloc needs to mmap() a new chunk. Some files actually *don't* have any size, such as /proc/$$/ctl, which is write-only. > We should certainly evaluate any patches that come in for possible > inclusion, assuming they don't muck up the internals of procfs too > much; it's not clear to me if they necessarily do so or not. I'll be glad to review and commit patches, but procfs doesn't have any internals to speak of, all it does is provide content for pseudofs. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
On Wed, 20 Feb 2008, Robert Watson wrote: > On Wed, 20 Feb 2008, remko@FreeBSD.org wrote: > >> After a bit of discussion, this is not something which we are going to fix. >> It is not worth the hassle. If you think this should be different, we do >> welcome patches. Thanks fo rusing FreeBSD! > > Just as two data points here: Solaris attempts to provide coherent file sizes > in /proc (at least to the extent that tried a few for objects where it is > remotely possible), and the Linux 2.6.12 kernel I have on a box locally > basically doesn't. > > My view is that it's a synthetic file system with data that varies > dynamically at runtime, and that while it wouldn't hurt to produce file size > information that's correct, it's quite a bit of work to do so and that I > wouldn't prioritize it above other, more critical things that need to happen. > We should certainly evaluate any patches that come in for possible inclusion, > assuming they don't muck up the internals of procfs too much; it's not clear > to me if they necessarily do so or not. The bug is mainly that stat() claims that the files are regular when they highly irregular (they are more like fifos). This confuses naive applications into thinking that normal access methods for regular files actually work. Bruce
On Thu, 21 Feb 2008, Bruce Evans wrote: > On Wed, 20 Feb 2008, Robert Watson wrote: > >> On Wed, 20 Feb 2008, remko@FreeBSD.org wrote: >> >>> After a bit of discussion, this is not something which we are going to >>> fix. It is not worth the hassle. If you think this should be different, we >>> do welcome patches. Thanks fo rusing FreeBSD! >> >> Just as two data points here: Solaris attempts to provide coherent file >> sizes in /proc (at least to the extent that tried a few for objects where >> it is remotely possible), and the Linux 2.6.12 kernel I have on a box >> locally basically doesn't. >> >> My view is that it's a synthetic file system with data that varies >> dynamically at runtime, and that while it wouldn't hurt to produce file >> size information that's correct, it's quite a bit of work to do so and that >> I wouldn't prioritize it above other, more critical things that need to >> happen. We should certainly evaluate any patches that come in for possible >> inclusion, assuming they don't muck up the internals of procfs too much; >> it's not clear to me if they necessarily do so or not. > > The bug is mainly that stat() claims that the files are regular when they > highly irregular (they are more like fifos). This confuses naive > applications into thinking that normal access methods for regular files > actually work. I feel this way more generally about synthetic file systems with objects in them that don't correspond with any of the standard file system objects that applications known how to deal with. Robert N M Watson Computer Laboratory University of Cambridge
On Thu, 21 Feb 2008, Robert Watson wrote: > On Thu, 21 Feb 2008, Bruce Evans wrote: >>> [about files in procfs] >> The bug is mainly that stat() claims that the files are regular when they >> highly irregular (they are more like fifos). This confuses naive >> applications into thinking that normal access methods for regular files >> actually work. > > I feel this way more generally about synthetic file systems with objects in > them that don't correspond with any of the standard file system objects that > applications known how to deal with. Enough to break compatibility/portabiility by adding a new file type? :-) S_IFMT has 4 bits, so it could encode 16 file types, but it currently only encodes 8. It looks like it once had only 3 bits but was expanded for fifos. It was last changed in ~1993 in 4.4BSD to add whiteouts. Bruce
On Thu, 21 Feb 2008, Bruce Evans wrote: > On Thu, 21 Feb 2008, Robert Watson wrote: > >> On Thu, 21 Feb 2008, Bruce Evans wrote: >>>> [about files in procfs] >>> The bug is mainly that stat() claims that the files are regular when they >>> highly irregular (they are more like fifos). This confuses naive >>> applications into thinking that normal access methods for regular files >>> actually work. >> >> I feel this way more generally about synthetic file systems with objects in >> them that don't correspond with any of the standard file system objects >> that applications known how to deal with. > > Enough to break compatibility/portabiility by adding a new file type? :-) > S_IFMT has 4 bits, so it could encode 16 file types, but it currently only > encodes 8. It looks like it once had only 3 bits but was expanded for > fifos. It was last changed in ~1993 in 4.4BSD to add whiteouts. Not that much :-). If someone hadn't been working to fix unionfs recently, I'd suggest GCing the whiteout flag so that we did, in fact, have a spare bit. That said, work to reduce dependence on procfs seems to be gradually getting done. There are a few things left, such as ps -e and gcore that could use some attention. Once nice thing about /proc/$pid/mem is that you can use it asynchronously with respect to the process and in a way that is non-interfering with its debugging and signal delivery. We almost want a ptrace attachment mode that specifies in advance that no execution flow interference will occur, just allowing memory access, register snapshots, etc, rather than an attachment necessarily getting in the signal delivery path (etc). Robert N M Watson Computer Laboratory University of Cambridge