Date: Mon, 1 Aug 2011 13:44:18 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-current@FreeBSD.org Cc: Andriy Gapon <avg@freebsd.org> Subject: Re: print_INTEL_info/print_INTEL_TLB Message-ID: <201108011344.28449.jkim@FreeBSD.org> In-Reply-To: <201108011217.30206.jhb@freebsd.org> References: <4E35732A.8060807@FreeBSD.org> <4E36B805.6070804@FreeBSD.org> <201108011217.30206.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 01 August 2011 12:17 pm, John Baldwin wrote: > On Monday, August 01, 2011 10:28:21 am Andriy Gapon wrote: > > on 01/08/2011 15:47 John Baldwin said the following: > > > On Sunday, July 31, 2011 11:22:18 am Andriy Gapon wrote: > > >> Just an observation: > > >> - print_INTEL_info and print_INTEL_TLB are missing from amd64 > > >> identcpu.c - print_INTEL_TLB doesn't cover all the codes > > >> defined by Intel specs - not sure; perhaps print_INTEL_info > > >> should use deterministic cache > > > > > > parameters > > > > > >> as provided by CPUID 0x4 for a more complete coverage... > > > > > > It might be nice to create a sys/x86/x86/identcpu.c to merge > > > the two which would help with some of this. > > > > I agree with this suggestion regardless of the issue at hand. > > > > > print_INTEL_TLB() hasn't been updated since it > > > was added AFAIK which probably explains why it doesn't know > > > about all of the codes. > > > > Given the current state of this code - is it useful at all? > > Should we keep it in kernel provided that there are tools like > > cpuid, x86info, etc...? I would have no doubts if we gathered > > that information for some real use by kernel and then also > > printed it for user's convenience. But if the code is there just > > for printing (and under bootverbose), then I am not really sure. > > Yeah, I would be fine with just tossing it. Tossing print_INTEL_info() entirely or just print_INTEL_TLB()? If we are going to remove print_INTEL_info(), then I think we should do the same for print_AMD_info() (except for the last warning message in the function) because it's going to have the fate sooner or later, i.e., unmaintained and rot (if it isn't already). Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201108011344.28449.jkim>