Date: Thu, 21 Feb 2008 11:34:13 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-fs@FreeBSD.org, remko@FreeBSD.org, yuri@tsoft.com, bug-followup@FreeBSD.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty Message-ID: <20080221112718.X64109@fledge.watson.org> In-Reply-To: <20080221210145.C4879@besplex.bde.org> References: <200802201208.m1KC8MHi009288@freefall.freebsd.org> <20080220132030.S14519@fledge.watson.org> <20080221202027.B29307@delplex.bde.org> <20080221093203.Y52922@fledge.watson.org> <20080221210145.C4879@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080221112718.X64109>