[LinuxBIOS] winflashrom architecture (Windows port of flashrom) -- looking for suggestions

[Peter Stuge]

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:
> >> 1. 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.


> >> 2. 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. :)


> >1. 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