[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANVTcTaJdhBXRYDCPJ+UouPQZUzXSity+9mL8QJTCpz=ZugZLA@mail.gmail.com>
Date: Sun, 28 Jul 2013 00:54:20 +0800
From: rui wang <ruiv.wang@...il.com>
To: Bjorn Helgaas <bhelgaas@...gle.com>
Cc: Tony Luck <tony.luck@...el.com>, chaohong.guo@...el.com,
Chen Gong <gong.chen@...ux.intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Rui Wang <rui.y.wang@...el.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [RFC 0/3] IO Hook: Method for emulating h/w events
>
> This is a cool idea.
>
> I don't know if you want to merge this upstream, or if it's just a "I
> found this useful; here it is in case it's useful to you" sort of
> thing. So the comments below are only relevant if you want to try to
> merge it upstream.
>
Thanks. If you think it's a cool idea, then I would like to see it
merged upstream.
> I wouldn't really want all the gunk in drivers/pci/access.c. Most of
> it isn't related to PCI, and some of it is even x86-specific. It'd be
> nicer if you could factor it out so just the generic PCI-related
> things go in drivers/pci.
>
Sure. I'll keep only the PCI-related things in drivers/pci and move
other things out.
> It appears to be implemented only for x86. The MMIO & I/O port parts
> are x86-specific, but the PCI config stuff should work on any arch.
>
I had only x86 in mind. But yes it should be made platform neutral.
I'll split it into neutral and arch-specific parts, so that other
archs can be supported easily.
> I don't know whether it's worth supporting as a module. It seems like
> a development aid where building in statically would probably be fine.
> If it didn't have to work as a module, you wouldn't have to export
> any symbols.
>
Yes building it statically in the kernel would be cleaner and easier
to use. I'll roll out a new version for you to review.
Thanks
Rui
>> I tested the performance by repeatedly running lspci, which calls into
>> the
>> pci access functions. There's no added overhead observed.
>>
>> Regards,
>> Rui Wang
>> Intel Open Source Technology Center
>>
>> Rui Wang (3):
>> IO Hook: core functions and Register Override
>> IO Hook: kernel interface to manage the hook
>> IO Hook: sysfs interface to emulate h/w events
>>
>> Documentation/PCI/iohook.txt | 290 +++++++++++++++++
>> arch/x86/Kconfig | 7 +
>> arch/x86/boot/compressed/Makefile | 1 +
>> arch/x86/include/asm/io.h | 58 ++++-
>> arch/x86/vdso/Makefile | 2 +
>> drivers/misc/Kconfig | 1 +
>> drivers/misc/Makefile | 1 +
>> drivers/misc/iohook/Kconfig | 5 +
>> drivers/misc/iohook/Makefile | 1 +
>> drivers/misc/iohook/iohook.c | 503 +++++++++++++++++++++++++++++
>> drivers/pci/access.c | 630
>> +++++++++++++++++++++++++++++++++++++
>> include/linux/reg_ovrd.h | 55 ++++
>> 12 files changed, 1552 insertions(+), 2 deletions(-)
>> create mode 100644 Documentation/PCI/iohook.txt
>> create mode 100644 drivers/misc/iohook/Kconfig
>> create mode 100644 drivers/misc/iohook/Makefile
>> create mode 100644 drivers/misc/iohook/iohook.c
>> create mode 100644 include/linux/reg_ovrd.h
>>
>> --
>> 1.7.5.4
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists