Peter Memishian wrote: > > > One thing I noticed that doesn't seem right in the UV bits is the > > > timestamps on /dev/net nodes. They seem to be at time 0: > > > > > > # ls -l /dev/net > > > total 0 > > > crw-rw-rw- 1 root sys 58, 1 Dec 31 1969 net0 > > > > > > I'd think they should have the time they were created, like > > > the /dev/pts nodes do. I suspect this is just a matter of > > > setting va_atime, va_mtime and va_ctime in devnet_create_rvp(). > > > > > See bug 6616725. > > Thanks. I don't completely follow that bug report, though. In > particular, it states: > > I could change devnet_create_rvp() to fill in the right timestamp in the > second argument. But that makes that every time SDEV_UPDATE is set, it > reset a new timestamp to this node, which is not what I'd expect. > > ... but I don't see any SDEV_UPDATE flag -- are you talking about > SDEV_ATTR_INVALID?
Yes. It is the SDEV_ATTR_INVALID flag. I personally think that only means the dev_t has been changed, but not the timestamp. Further, we set that SDEV_ATTR_INVALID flag once there is no reference on this /dev/net node. The associated device could possibly detach, then attach, with the different or the same dev_t. In the case where SDEV_ATTR_INVALID has been set and > the dev_t has actually changed, it would seem reasonable to have a new > timestamp, though I'm not sure if there is any precedent for it. (Can we > distinguish the case where the dev_t has changed from the one where it > hasn't?) > > Perhaps I should discuss this with the devname team? > I tried to set va_atime, va_mtime and va_ctime in devnet_create_rvp() yesterday. But the result is not what I expected. It seems that the timestamp did not change after I forced the device to detach/reattach. I will need some time to investigate more what has happened there. Thanks - Cathy
