> > It's not useless, and it's the same as essentially every other > > device file in the system. > > Then perhaps they convey the wrong information. > Note the "essentially every other". Not "every other". > > That means you can't take a devices mtime to be kerndate, which means > making *some* of them have kerndate presents duplicate data that is also > untrustworthy and therefore meaningless and arbitrary.
I hedged because I wasn't 100% sure and didn't want to look through all the drivers. But now I have. It's really "every other". There are no kernel-provided devices that fiddle with mtime. Not one. > If we are assigning arbitrary pieces of data as the mtime then why not > the start time of when the process was created and therefore the > creation date of /proc/pid > > IMHO the creation time of /proc should be the boot time of the kernel. > Kerndate should be somewhere but it is it really relevant to the current > running state of the system ? Maybe in someone else's humble opinion the modification time (there is no creation time in Plan 9) of /proc should be the time of the last call to fork or exits, i.e. the last time the directory actually changed. There isn't an obvious value here. There are lots of good arguments that various information relevant to the system should be available (when did the system boot? when was the kernel built? what kernel is running? where did it get loaded from? etc.). Overloading mtime for all these purposes is misguided, as none of them are actually modification times. An arbitrary value got chosen for the mtime on kernel devices. It's reasonable enough and I don't see an argument to change it. If the value was something else, I'd feel the same way: I wouldn't go changing it to kerndate. Same reason I didn't change NBROKEN. If it were 8 already, I wouldn't be arguing that it should be 4. But given that it there isn't one right answer and that the current definitions have sufficed for the last 15+ years, I don't see why we should change it today. Enough already. Russ
