Messages in this thread | | | Date | Sun, 14 Jun 2009 13:19:01 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [RFC][GIT PULL][PATCH 0/10 -tip] cpu_debug patches 20090613 |
| |
Jaswinder,
[ I sanitized the cc list to restrict the annoyance to those who have to deal with that. Please stop adding people who are not affected by this. ]
On Sun, 14 Jun 2009, Jaswinder Singh Rajput wrote:
> On Sun, 2009-06-14 at 00:27 +0200, Thomas Gleixner wrote: > > On Sat, 13 Jun 2009, Jaswinder Singh Rajput wrote: > > > > > Please let me know how we can improve it and add more features so it > > > becomes more useful. > > > > I really have to ask, why this is useful at all. > > > > Currently for X86 I can do : > > 1. read complete state (dump all registers like for MTRR, APIC) > 2. read individual register > 3. write to individual register > 4. read/write these registers/info with shell through debugfs > 5. read these registers/info before getting shell > > And I did this for complete X86 CPU registers and info: > 1. Standard Registers > 2. Control Registers > 3. Debug Registers > 4. Descriptor Tables > 5. APIC Registers > 6. Model specific Register (MSRs) > 7. PCI configuration registers (for AMD) > 8. Basic cpuinfo > 9. CPUID Functions
I did not ask what it can do. I did ask what's the usefulness of it. Your answer is the same list on which I commented on already in technical detail, but you ignored those comments.
> This will be really useful for : > 1. developer who is porting/developing the kernel or drivers.
We can access all this information already with existing tools.
> 2. User who is reading hardware manual and want to see these value on > its CPU
Same here.
> Of course you need a Hardware manual to check address and detail > information. I do not want to keep detail for each register.
That's why anyone with common sense will use lspci, cpuid to get the information in both raw and decoded format.
> In X86 many tools are available which can read many registers but not > available for many architectures (I CCed some architecture maintainers > so that they can also specify issues they face when supporting new > CPU/architecture), they can also take advantage of it if we move
I have ported Linux to a couple of new platforms and the problem you face is that the kernel does not boot at all in the early stage of the boot process.
How does cpu_debug help in that situation ? It does not help at all.
> cpu_debug architecture independent portion outside X86.
There is nothing x86 independent in cpu_debug.
> I am not against of any tool but some issues about tools are : > 1. Not supported for all architectures
Again cpu_debug can not made generic as it is poking in architecture specific hardware.
> 2. Do not support latest or upcoming hardware
All these tools show the raw values, which also covers latest hardware.
> 3. You need to mount filesystem and execute some shell to give commands
Are you saying that the access to your debugfs based cpu_debug information does neither require a mounted file system nor a shell nor commands? It provides the information by telepathy, right?
> 4. you need different tools to access different registers
Write a wrapper script if that annoys you.
> So I want to know how can we can make cpu_debug more useful.
I have not yet seen a single technical argument for what it is useful at all.
So please stop hand waving about what it might do as long as you can not provide a single technical reason why cpu_debug should be in the kernel at all.
Go through the kernel.org bugzilla and show me _one_ single bug which I debugged with the bug reporter, which could have been resolved faster by using cpu_debug. And think careful about it before you provide me that information.
> > The reinvention of useful tools like lspci, cpuid, rdmsr, wrmsr inside > > of the kernel with a worse user interface and less information > > provided is just a waste of time and resources. > > > > what user interface and information you want ?
I'm happy to use the existing tools and their user interface. There is no value of having inferior reimplementations of those tools in the kernel.
Thanks,
tglx
| |