On 5/2/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Tue, May 01, 2007 at 11:20:20PM +0700, Darmawan Salihun wrote:
On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:
- The kernel mode code a.k.a kernel mode device driver is as
This would be OK, but there's a constant race between making the window large enough and new flash chips.
In my current experimental code. The "window" in the kernel driver is programmable, i.e. the user mode application passes the starting address of the MMIO range along with the size of the range to be mapped.
The problem with this is that the app could map ALL memory and destroy the system and/or data, even if by mistake. Not pretty.
I see, I overlooked the issue previously. This should be in my top list of consideration ;-).
- The kernel mode driver implements the majority of the flashrom
code and the usermode code is merely a "front-end" to the kernel mode device driver which provides all of the chip related logic.
I like this a bit better.
I see. My problem right now in this version is to define the interface between the kernel driver and the user mode code. Quite hard to define the interface because it will use a quite different approach than the "mmap" approach in point 1.
It depends on how high level the driver tasks should be.
I would model this after flashrom command parameters.
ok. This hint is helpful ;-).
Anyway, I'm also thinking about a quite "universal" interface
between the user mode code and the kernel mode code. Perhaps a well defined interface
This requires a lot of extra work but has the benefit of only one generic algorithm being implemented in the kernel, thus the kernel
yes. That's why I'm currently thinking about the "evolutionary path" to this kind of functionality
Sure. Better a hack that works than nothing. :)
- or 2. will be a lot less work though. Maybe start there.
I like 2.
I'll have a look at this approach more closely.
Maybe you can actually identify trivial things that change in flashrom and create a small protocol for the application to specify them to the kernel driver.
The app could enumerate the PCI devices in the system and compare that with a list of write enable functions that are implemented in the driver. (The driver tells the app which functions are available, the app decides which one to use.)
The current PCI device enumeration uses a cut-down version of the pciutils source code which I port to Windows (Quite trivial given the availability of inb,outb, ..., in the current kernel driver).
Most of the time a new flash chip can be added to flashrom just by
adding it's parameters to the chip table. If this table was in the application a lot would already be gained.
yes, of course this should be in the priority list.
-- Darmawan -------------------------------------------------------------------- -= Human knowledge belongs to the world =-