Am Mittwoch 06 August 2008 02:53:23 schrieb [EMAIL PROTECTED]: > I've been working on a port of DRM for Syllable.? Syllable doesn't support > drivers (or kernel modules) that are on the same level of abstraction & > communicate with each other.? For example our sound card drivers can't > communicate with any other driver normal driver, they can only communicate > with busmanagers (PCI, ISA, etc.).? With this in mind, I've been wondering > what the signifigance of having a drm kernel object that's seperate from > the video driver, but the video driver is dynamicly linked to it.? If I > have gotten something wrong, please let me know.? Also, is it a big deal to > just compile all of the drm driver code into the video drivers?? I ask > this, not because I'm trying to change the way you all do things, but only > because I'm trying to find a suitable solution for Syllable.
It's been a very long time since I last looked into Syllable, but if I remember things correctly, the setup was something like: 1. Hardware-specific video driver in the kernel 2. Hardware agnostic server in userspace that manages the desktop The Linux setup is like this: 1. Hardware-independent kernel module "drm" 2. Hardware-specific kernel module, e.g. "radeon" 3. Hardware-specific module in the Xserver Since you already have a hardware-specific module in the kernel, I think it's reasonable to merge the hardware-specific parts of the drm into that existing module. After all, when you have two hardware-specific modules in the kernel you only end up having to worry about interface compatibility issues when people run versions of the modules that don't match (alternatively you could force the module versions to be the same, but then why separate things into two different modules in the first place). As for the hardware-independent kernel bits (the "drm" module), perhaps you should think of them not as a driver but as a kind of shared library that contains utility functions for writing a driver? Once you're in that mindset of the "drm" bits being a library, and if the Syllable kernel really doesn't support shared library loading (that's a very odd design decision), you could always build them as a static library that is linked into each of the hardware-specific drivers. So if that was your original question, no, I don't think it's a big deal if that's the way Syllable works. The important thing is that it should be possible to do all this without touching the shared-core directory by putting the Syllable-specific things in their own directory (as is the case for Linux and BSD today). cu, Nicolai
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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=/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel