Peter Stuge wrote: > On Thu, Jul 12, 2007 at 05:13:38PM +0700, Darmawan Salihun wrote: > >>> As for the EPIA board, well, where is that base specified? In a >>> PCI config register or where? >>> >> The base is in a PCI config register. Relevant code as follows: >> >> base = pci_read_word(dev, 0x88) & 0xFF80; >> >> val = inb(base + 0x4D); >> val |= 0x80; >> outb(val, base + 0x4D); >> > > Ok! Put all of board_enable.c in the kernel driver and add some way > for the app to call any function in the board_pciid_enables list, in > the kernel driver. Sort of RPC but over a app/kernel split instead of > over a network. > > Then compile board_enable.c also into the app, but not to call any of > the functions (which would fail anyway) but only to get the same > board_pciid_enables list. The struct may have to be extended to have > a unique index for each entry so that the driver and app can agree on > which function is which. > I'm thinking about creating a board_enable.h file which will hold the "board_pciid_enables list". It may be easier this way because both the app and the driver will refer to it. Therefore, whenever a change is happening, both will conform to the change immediately. Of course board_enable.c will exist in the app and the driver as well. Is that acceptable? or perhaps is it opening too much of access into a "should be private" entity (in this case "board_pciid_enables list")?
> All of the device detection should be done where it is easiest to do > it. Since the driver will need to do safe PCI accesses for board > enables perhaps it makes sense to contain all PCI accesses in the > driver. > > On the other hand, perhaps the app will need to do some PCI accesses > to choose the right board_enable function and then it's better to do > most of them in the app. > > What do you think? > I think it's better to move it to the kernel driver and only provides a function call to it in the app. I think that's the way to go. However, that would be a huge #ifdef in the beginning of the transition into a new unified architecture :-(. > Another general matter, make sure the app and driver can exchange > version numbers. That way both the driver and the app could have > compatiblity code in order to be backwards compatible. > It's quite easy to add this capability in the driver initialization. > I would like the app to exit with an error message if it can't agree > with the kernel driver on a "protocol version" that both of them > support. Need not be fancy right now, a simple two-way version check > is plenty good. > roger that ;-). --Darmawan Salihun -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
