Date: Mon, 23 Mar 2015 08:40:53 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, Jilles Tjoelker <jilles@stack.nl>, svn-src-all@freebsd.org, Xin LI <delphij@freebsd.org>, Bruce Evans <brde@optusnet.com.au>, svn-src-head@freebsd.org Subject: Re: svn commit: r280308 - head/sys/fs/devfs Message-ID: <20150323081537.U932@besplex.bde.org> In-Reply-To: <20150322162507.GD2379@kib.kiev.ua> References: <201503210114.t2L1ECcB075556@svn.freebsd.org> <20150321200221.K1846@besplex.bde.org> <20150322133709.GA39238@stack.nl> <20150322162507.GD2379@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Mar 2015, Konstantin Belousov wrote: > On Sun, Mar 22, 2015 at 02:37:09PM +0100, Jilles Tjoelker wrote: >> On Sat, Mar 21, 2015 at 08:49:00PM +1100, Bruce Evans wrote: >>> On Sat, 21 Mar 2015, Xin LI wrote: >> >>>> Log: >>>> Disable timestamping on devfs read/write operations by default. >> ... >>> I don't like this. It defaults to non-POSIX-conformant behaviour... >>> ... > Does POSIX ever say anything about special files ? It says indirectly that special files have full support for timestamps although they might not support many other attributes. From an old draft: X 51276 Upon successful completion, where nbyte is greater than 0, write( ) shall mark for update the X 51277 st_ctime and st_mtime fields of the file, and if the file is a regular file, the S_ISUID and S_ISGID X 51278 bits of the file mode may be cleared. Note that it makes a special case for regular files, but not for the file times. > Devfs already has non-POSIX behaviour, e.g. write on one mount is > reflected as mtime/ctime update on all mounts. On reboot, the time > stamps are re-created, i.e. changes are not persistent. POSIX doesn't cover reboots :-). Perhaps it should say something. I don't remember it even saying saying anything about the persistence of file data. Specifying this would be difficult. Obviously, it cannot reasonably specify persistence of file data for longer than is physically possible, and no implementation can guarantee its future behaviour. > I think the deviations may be summarrized as 'devfs mtime is useless for > the usual mtime purposes'. From this PoV, I have no objections to the > patch. Doing extra work with delayed updates of times, which might > be somewhat non-trivial, is a feature with non-obvious gain. I thought that atimes were even more useless, but it is the atime that is used by w(1). I mostly notice devfs times when find(1) finds garbage devfs times -- ones in the future caused by devfs creating files before userland has fixed up the time. Devfs has incomplete code to avoid this problem. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150323081537.U932>