Marius, good day. First, thanks for committing the fix. Wed, Jun 03, 2009 at 09:44:53PM +0200, Marius Strobl wrote: > On Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. > > Just now we won't be able to reach this with the current definition > > for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can > > become negative and that's bad. > > If it actually becomes negative the build should break again, > which IMO is sufficient protection. Yes, "protection" is here. But it will break the build again and that's a bit uncomfortable. > > The attached patch should fix this (although I have no sun4v to test > > on, so take it with a grain of salt). > > I think this is overengineered, especially if not also > adjusting the padding for other macros which may change the > size of both MD and MI parts of struct pcpu. Hmm, don't fully understand about "other macros". Could you, please, provide an example? > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts > > of 'struct pcpu' that depend on the KTR_PERCPU being defined and they > > are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is > > KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am > > missing something? > > It's just not taken into account but AFAICT also dead code. Yes, seems like so. John, may be we can eliminate the only reference to KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be unused (grep'ped -CURRENT sources). -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ #Received on Thu Jun 04 2009 - 01:26:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:49 UTC