paul_c wrote: > On Thursday 18 September 2008, Sebastian Kuzminsky wrote: >> The fundamental problem is the low-level board drivers need to support >> multiple boards, and each board has multiple pwmgen and stepgen >> instances etc, each of which will need its own configuration information >> eventually. So really what's needed is an array of board-config >> structures. ... > Fortunately, the kernel already provides a mechanism for copying data to/from > user space that doesn't involve hijacking the firmware subsystem. Seeing as > your driver(s) will only work with 2.6.x series kernels, you can maximise the > use of the newer hooks for passing data.
I dont care at all about supporting 2.4. The problem is that the config information needs to be available before we can present the board to HAL, and that currently happens at insmod time. So either this userspace->kernel data copy operation needs to be synced with insmod somehow, or the structure of the driver needs to change to wait for both the firmware and the config info from userspace. I'm open to either solution. What I have now is adequate for early testing, but not acceptable for any kind of production driver. Paul, what kernel-driver config mechanism do you suggest? -- Sebastian Kuzminsky romano hip hop - romano hip hop in the house <http://www.youtube.com/watch?v=D-azvIwldYg> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
