Milan Jurik wrote: > Hi, > > Darren J Moffat p??e v st 02. 09. 2009 v 13:58 +0100: >> Is it safe to assume that this case will update all of the ON and other >> Solaris consolidations that have code that uses lbolt/lbolt64 ? >> >> In the ZFS kernel module alone there are over 30 references to >> lbolt/lblot64. >> >> Was any consideration given to providing something like this: >> >> #define lbolt ddi_get_lbolt() >> #define lbolt64 ddi_get_lbolt64() >> >> The main reason for suggesting is based on a quick glance of where ZFS >> uses lbolt and lbolt64 today those new function calls are going to cause >> some ugly cstyle issues in a few places. >> > > Is it good idea to use macro just to make C-style test happy? Isn't it
That is the question I'm asking. The main reason I'm asking is because lbolt/lbolt64 is so so ingrained in existing code. A quick check with cscope suggests somewhere in the region of 500+ references in ON. Is it really a good use of engineering time to fix the cstyle issue that will be created in replacing lbolt with ddi_get_lbolt() as a result ? Personally I don't think so. It is quite a different thing to ask though if use of lbolt is still the appropriate thing to look at post this case and that is valuable use of engineering time. This is mostly below the ARC review line, except for the fact that lbolt/loblt64 are ancient symbols and they are now going away. For what its worth I think it is less of a hack than the nonsense that has to be done sometimes to make lint happy. -- Darren J Moffat
