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.
- 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.
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.)
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.
//Peter