> > > Looking at it again, it seems that sock_gettstamp() should > > > actually deal with this gracefully: it will return a -EINVAL > > > error condition if the timestamp remains at the > > > SK_DEFAULT_STAMP initial value, which is probably > > > just as appropriate (or better) as the current -ENOTTY > > > default, and if we are actually recording timestamps, we > > > might just as well report them. > > > > Yes, that's a nice solution. There is always some risk in changing > > error codes. But ioctl callers should be able to support newly > > implemented functionality. Even if partially implemented and > > returning ENOENT instead of ENOIOCTLCMD. > > Ok, so do you think we should stay with the current version > for now, and change the two points later, or should I rework > it to integrate the locking and removing the callback? > > I suppose the series actually gets nicer without the > callback, since I can simply add the generic timestamping > implementation first, and then remove the dead ioctl > handlers. Agreed. I would add the locks in a separate patch, if only on the off-chance that lockdep discovers something and it will be easier to bisect and revise independently. I can also follow up with that patch outside this set, of course.
