Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 09:25:22AM -0700, Linus Torvalds wrote: If a lot of this stuff really is that device independent, why don't we move it to a separate kernel module? That would save some memory when multiple DRM drivers are loaded at once. Kernel modules that depend on each other are a major pain in the butt, I can tell you. It's not worth it from a technical angle, and one argument against it has historically been that X binaries did something an insmod xxx and the people didn't want to break that by requireing multiple modules. This was exactly the reason I hesitated when you first suggested that I did exactly that for agpgart, but I figured you knew best... for what its worth, on my hard disk at home, there's a dri cleanup tree that is half done doing similar stuff mentioned in this thread. My intent was just pushing the drm_agpsupport.h stuff into the kernel proper, and having the drm modules calling that stuff instead of inlining its own agp routines each time. maybe I'll finish it up when I get back next week. Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Wed, 4 Jun 2003, Dave Jones wrote: This was exactly the reason I hesitated when you first suggested that I did exactly that for agpgart, but I figured you knew best... It's worked pretty well for AGP, and it sure as hell cleaned stuff up. It was a suggested thing for DRI too a _loong_ time ago (before the DRM() thing), but at least back then it was shot down by whoever did DRM due to user-level confusion. For what it's worth, I haven't seen any AGP confusion reports myself due to the move to helper core modules. Linus --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Wed, Jun 04, 2003 at 07:45:26AM -0700, Linus Torvalds wrote: This was exactly the reason I hesitated when you first suggested that I did exactly that for agpgart, but I figured you knew best... It's worked pretty well for AGP, and it sure as hell cleaned stuff up. no argument there.. It was a suggested thing for DRI too a _loong_ time ago (before the DRM() thing), but at least back then it was shot down by whoever did DRM due to user-level confusion. right. the DRM() stuff annoyed me enough to start hacking on it. If I get bored enough, I may recreate those changes locally, as I won't get home before the weekend to mail them out. For what it's worth, I haven't seen any AGP confusion reports myself due to the move to helper core modules. they were few and far between, but I did field a few mails from folks not loading the sub-driver, and then wondering why agpgart was failing. that's backed off since then, so hopefully its a non-issue, but it's something that's documented in the 2.5 changes doc I wrote[1] for any newcomers when we get to 2.6 anyways. Dave [1] for those that havent seen it, http://www.codemonkey.org.uk/post-halloween-2.5.txt --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 01:26:04AM +0100, José Fonseca wrote: I would also like to discuss the possibility of: - dropping the DRM(my_func)() for drm_my_func(). If I'm not mistaken, these symbols aren't exported to the rest of the kernel so there isn't any conflict when several DRM's are loaded simulatenously on the kernel (or is there?) Besides of reducing some visual clutter Is that also true when multiple DRM drivers are built-in to the kernel? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Mon, 2 Jun 2003, Ian Romanick wrote: I think you would be fine with multiple modules, but I think it would break if you had multiple drivers built into the kernel. I'm not sure about that, though. Yes. The reason for DRM(xxx) is that I personally _require_ that built-in modules work. If something works only as a loadable module, it's broken-by-design, and I will complain very very loudly. There have been other ways to solve the same thing (ie a common library works fine, and is what many other drivers use), but DRM has historically had slightly different functions for different drivers, and the DRM makefiles have always been pretty broken. If a lot of this stuff really is that device independent, why don't we move it to a separate kernel module? That would save some memory when multiple DRM drivers are loaded at once. Kernel modules that depend on each other are a major pain in the butt, I can tell you. It's not worth it from a technical angle, and one argument against it has historically been that X binaries did something an insmod xxx and the people didn't want to break that by requireing multiple modules. The only really sane approach is to just compile in the shared code. Loadable modules are _way_ overrated, there's no inherent goodness in them (and there are real downsides). The DRI project has been stuck with them only because development is done outside the kernel. I'd suggest making the truly common and hw-independent routines (and _stable_ stuff) just be compiled into the kernel. Make the module thing an option for development, but if it's really stable, it really is better off being in the standard kernel - the same way you already depend on AGP support being with the standard kernel. The library routines would be available as a module only for backwards compatibility reasons. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote: According with archives (http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS), Linus wanted the DRM drivers to be independent. I wanted that because the old code was total crap, and the makefiles could never get the compiled-in case to work. I don't think it's a goodness in itself, but it was basically a _requirement_ for DRI back then. The library routines were horribly hacky, and depended on config options, so they were impossible to compile in and then load one driver later. My only real underlying requirement is that compiled-in stuff works. I personally refuse to use modules, since I see no point to them when I compile the kernel for my machine _anyway_. To me modules are either - distribution kernels (either things like RedHat/SuSE, or just local MIS distrubutions) - development (load a module, test, unload, fix, load again) and make zero sense otherwise when you have full sources. I suspect that the DRI code these days is getting stable enough, and there are enough people with good kernel sense in the group, that the complete independence isn't required. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
José Fonseca wrote: According with archives (http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS), Linus wanted the DRM drivers to be independent. Don't know if he still feels the same, considering the ALSA/OSS modules, or the recent reorganization of AGPGART. Don't know as well if the old DRM sub-drivers would do the same thing as these examples. That's a slightly different logical structure than I was talking about. What Linus didn't want, IIRC, was a system where the user does 'insmod drm.o' and drm.o request that a specific driver be loaded. What I'm proposing here is moving the device-independent stuff to drm_util.o that would automatically get loaded when people do 'modprobe radeon'. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
Linus Torvalds wrote: To me modules are either - distribution kernels (either things like RedHat/SuSE, or just local MIS distrubutions) - development (load a module, test, unload, fix, load again) and make zero sense otherwise when you have full sources. We also have our binary driver updates to think about. It's bad enough that we have to rebuild a kernel module on the user's system at install time. If we had to rebuild the whole kernel, people would pitch fits. :) --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, 3 Jun 2003, David Dawes wrote: Does this go any way towards explaining why it seems to be getting harder and harder to build modules outside of the kernel source tree while still leveraging the kernel build mechanism? No. That is explained by the inevitable lack of testing, I think. Modules outside of the kernel can (by definition) not be tested by people who work on the kernel. It's not made any better by the fact that the outside modules tend to do horribly bad things because they try to be compatible across different configuration managers etc, so they tend to be quite fragile in the first place. Is the ability to build modules located outside of the kernel source tree a consideration at all in the kernel module build process, or am I going down the wrong path with this? It's certainly never been a consideration for the kernel proper, partly because the outside projects have never even tried to make it a consideration. And some outside projects have been totally misguided and seriously broken wrt kernel coding styles, making them actively disliked by the regular kernel people. (For example, the original OSS code eventually tried to evolve into a thing that encouraged binary module compatibility through the use of a shim layer designed for that - which is against all the design goals of a regular kernel). NOTE! It may be impossible to really solve this problem. A lot of the things that outside modules want are _by_design_ something the kernel proper does not like. In particular, the kernel proper has always put clean source code at a much higher priority than source-level compatibility within the kernel. So I encourage people to just switch around interfaces when that fixes some internal problem - rather than add a new new interface and leaving the old ones dangling for compatibility. (On the other hand, the system call ABI compatibility to user space is sacred, and outweighs any in-kernel beauty issues.) In other words: external projects have usually not worked very well. They often end up doign the wrong thing technically exactly _because_ they are external, and can't easily upgrade to modern interfaces because they want to be compatible with old systems. I don't really see that changing to any major degree. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 09:31:27AM -0700, Linus Torvalds wrote: On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote: According with archives (http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS), Linus wanted the DRM drivers to be independent. I wanted that because the old code was total crap, and the makefiles could never get the compiled-in case to work. I don't think it's a goodness in itself, but it was basically a _requirement_ for DRI back then. The library routines were horribly hacky, and depended on config options, so they were impossible to compile in and then load one driver later. My only real underlying requirement is that compiled-in stuff works. I personally refuse to use modules, since I see no point to them when I compile the kernel for my machine _anyway_. To me modules are either - distribution kernels (either things like RedHat/SuSE, or just local MIS distrubutions) - development (load a module, test, unload, fix, load again) and make zero sense otherwise when you have full sources. Thanks for the heads up and your POV in this matter. This will have to be more thoroughly discussed before any decision is made since it can affect other things (such as IHV DRM based drivers). But before we reach the merits discussion I'd like to know how the symbol linking differs when a driver is loaded as a module or is statically linked in the kernel. I tried to search about this: /usr/src/linux doesn't have much infor about it, google just gives rubish for all keywords combinations I can think of, but http://www.xml.com/ldd/chapter/book/ch02.html#t3 has some info. IIUC, at least for modules, the symbols which we want to make available to other modules usually have to be specificaly declared (with EXPORT_SYMBOL). Therefore each module it's own namespace, i.e., two different modules with some public symbol with the same name on each module doesn't lead to a duplicate symbol unless they both are exported. But for statically linked kernels, can we or not have two equally named non-static not-exported symbols living in two different source files? José Fonseca --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote: IIUC, at least for modules, the symbols which we want to make available to other modules usually have to be specificaly declared (with EXPORT_SYMBOL). Therefore each module it's own namespace, i.e., two different modules with some public symbol with the same name on each module doesn't lead to a duplicate symbol unless they both are exported. No. Exactly because both modules may be linked into the kernel, and the way C linkers work, there is only two namespaces: the per-file (static) one, and the global one. But for statically linked kernels, can we or not have two equally named non-static not-exported symbols living in two different source files? No, we can NOT have that. If they have the same name, they must be the same function. It's that simple. And if it's the same function and used by multiple different drivers, then it MUST NOT have CONFIG_xxx dependencies. This is exactly what was wrong with the old pre-DRM(xxx) code. So I would suggest: - create a new module, called drm, which holds truly generic functions. It gets linked in only _once_, and drm module users have to load it explicitly (possibly though modprobe, which knows about module dependencies, but _not_ by doing some kind of request_module() crap) Sane setups will just link this module directly into the kernel. This module does not know (or care) about what DRI drivers there are. It doesn't have a list of supported drivers, and it only has generic infrastructure stuff. Quite frankly, looking at the current DRI tree, there's not a lot of code like this there that I can see. Almost every single library function has intimate details about the hardware through macro expansion. - any library functions that behave differently for different cards must continue to use a card-specific prefix. So for example, the function DRM(setup)() is clearly _different_ for a Radeon card, since the radeon driver has a different DRIVER_PRESETUP() thing etc. As a result, it must not be called drm_setup(), since it is clearly radeon_setup(). The files I see that look like they could be true DRM library functions (without any major surgery, at least) are - drm_agpsupport.h - drm_lock.h - drm_memory.h but I may be misreading something. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 12:26:03PM -0700, Linus Torvalds wrote: If they have the same name, they must be the same function. It's that simple. And if it's the same function and used by multiple different drivers, then it MUST NOT have CONFIG_xxx dependencies. Ok. Thanks for clearing this up. This is exactly what was wrong with the old pre-DRM(xxx) code. So I would suggest: - create a new module, called drm, which holds truly generic functions. It gets linked in only _once_, and drm module users have to load it explicitly (possibly though modprobe, which knows about module dependencies, but _not_ by doing some kind of request_module() crap) Sane setups will just link this module directly into the kernel. This module does not know (or care) about what DRI drivers there are. It doesn't have a list of supported drivers, and it only has generic infrastructure stuff. Quite frankly, looking at the current DRI tree, there's not a lot of code like this there that I can see. Almost every single library function has intimate details about the hardware through macro expansion. By the contrary. Most functions in the drm_*.h templates are likely candidates. For the major part template costumization consists of have DMA, need AGP, use SG, ... but if the associated functions go into a new common module, there is no point to conditionaly enable them - they are always there, and it's up to the driver to use them or not. - any library functions that behave differently for different cards must continue to use a card-specific prefix. So for example, the function DRM(setup)() is clearly _different_ for a Radeon card, since the radeon driver has a different DRIVER_PRESETUP() thing etc. As a result, it must not be called drm_setup(), since it is clearly radeon_setup(). The files I see that look like they could be true DRM library functions (without any major surgery, at least) are - drm_agpsupport.h - drm_lock.h - drm_memory.h José Fonseca --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote: Quite frankly, looking at the current DRI tree, there's not a lot of code like this there that I can see. Almost every single library function has intimate details about the hardware through macro expansion. By the contrary. Most functions in the drm_*.h templates are likely candidates. For the major part template costumization consists of have DMA, need AGP, use SG, ... but if the associated functions go into a new common module, there is no point to conditionaly enable them - they are always there, and it's up to the driver to use them or not. The above is indeed true for some header files (I pointed out three, there may be others). However, look at things like drm_drv.h, drm_dma.h etc, which both use the DRM() macros and other macros to call functions that are very much card-specific. It may not be immediately obvious, but doing things like DRM(driver_irq_preinstall)(dev); immediately means that that function cannot be a generic library function. Some other header files use the DRM() prefix to create per-driver data structures, ie things like DRM(parse_options) use it to create separate option flag variables for separate drivers. But yes, part of this definitely can be cleaned up and shared. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial (New patch, covering AGP)
José Fonseca wrote: The new attached patch also covers the drm_agpsupport.h janitorial. As nobody stepped against it, I'll start commiting soon. Except for this first time, I don't plan to commit more than one header janitorial per day. This means that anybody can track regressions with the nightly snapshots. For the other branches out there, when merging/syncing with the trunk the only special thing to do is replace drm_agpsupport.h by drm_agp_tmp.h and so forth, in the *_drv.c file. José Fonseca The patch looks good to me... Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 11:52:42AM -0700, Linus Torvalds wrote: On Tue, 3 Jun 2003, David Dawes wrote: Does this go any way towards explaining why it seems to be getting harder and harder to build modules outside of the kernel source tree while still leveraging the kernel build mechanism? No. That is explained by the inevitable lack of testing, I think. Modules outside of the kernel can (by definition) not be tested by people who work on the kernel. It's not made any better by the fact that the outside modules tend to do horribly bad things because they try to be compatible across different configuration managers etc, so they tend to be quite fragile in the first place. Is the ability to build modules located outside of the kernel source tree a consideration at all in the kernel module build process, or am I going down the wrong path with this? It's certainly never been a consideration for the kernel proper, partly because the outside projects have never even tried to make it a consideration. And some outside projects have been totally misguided and seriously broken wrt kernel coding styles, making them actively disliked by the regular kernel people. I'm sorry if this wasn't clear, but I'm just focusing on the actual build mechanism right now, not internal interface or other code-related issues. I changed the DRI Makefiles so that they will invoke the kernel's top-level Makefile with SUBDIRS set to the external directory containing the module source. Various other stuff is done to provide a suitable environment for a wide range of kernels, both stock, and distro supplied. The goal here is that a single tarball with, say, DRM module source can be unpacked and easily built for as wide a range of kernel versions as possible. For example, this approach handles the difference in build details between 2.4.x modules (mod.o) and recent 2.5.x modules (mod.ko) fairly transparently, and ensures that the modules are complied with the correct compiler flags for the matching kernel. It works moderately well up until recent 2.5.x versions, where calling the top level Makefile with SUBDIRS overriden (as in 'make -C $(LINUXDIR) SUBDIRS=`pwd` modules') is getting harder to make work. So, my question is whether the new kernel build mechanism is intended to allow this type of thing, or did it work before more by accident than design? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, 3 Jun 2003, David Dawes wrote: So, my question is whether the new kernel build mechanism is intended to allow this type of thing, or did it work before more by accident than design? Hmm.. Sounds accidental, but it might be a good idea to contact Sam Ravnborg [EMAIL PROTECTED] Kai Germaschewski [EMAIL PROTECTED] about yoru issues - they are pretty responsive, and telling them about what you need will either get it fixed or at least cause a suggestion on how to work with the changes. As far as I know, the only build-related difference in 2.5.69-70 was to make the default build be less verbose, to show warnings more. So the breakage is almost certainly just totally accidental. (There's a few Kconfig changes too, it might be due to those). Linus --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
José Fonseca wrote: I would also like to discuss the possibility of: - dropping the DRM(my_func)() for drm_my_func(). If I'm not mistaken, these symbols aren't exported to the rest of the kernel so there isn't any conflict when several DRM's are loaded simulatenously on the kernel (or is there?) Besides of reducing some visual clutter this would allow to a better parity between the source code and the Doxygen generated documentation: at the moment those DRM(...) tags have to be eliminated before feeding into Doxygen to allow cross-referecing. I think you would be fine with multiple modules, but I think it would break if you had multiple drivers built into the kernel. I'm not sure about that, though. If it doesn't break (or if we don't care), I'd be in favor of killing the DRM(...) stuff. If a lot of this stuff really is that device independent, why don't we move it to a separate kernel module? That would save some memory when multiple DRM drivers are loaded at once. A more pratical issue (assuming that everbody is OK with what I'm proposing here) is about the commiting procedure: - should I committing each module as I write, perhaps posting before review before commiting? (my favorite) - should I setup a seperate branch (plz no - I'm sick of branching and merging and branching again and... 8( ) - or should I just setup a big patch once everything is done and do it in one go? I don't think this change is big enough to warrant a branch. I would do it one driver at a time, and post to dri-devel for review. After the first one or two everyone will probably be comfortable enough with it to just let you do the rest in peace. :) If you do one big patch it will be information over-load and you won't get many / any useful reviews. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Mon, Jun 02, 2003 at 09:07:16PM -0700, Ian Romanick wrote: José Fonseca wrote: I would also like to discuss the possibility of: - dropping the DRM(my_func)() for drm_my_func(). If I'm not mistaken, these symbols aren't exported to the rest of the kernel so there isn't any conflict when several DRM's are loaded simulatenously on the kernel (or is there?) Besides of reducing some visual clutter this would allow to a better parity between the source code and the Doxygen generated documentation: at the moment those DRM(...) tags have to be eliminated before feeding into Doxygen to allow cross-referecing. I think you would be fine with multiple modules, but I think it would break if you had multiple drivers built into the kernel. I'm not sure about that, though. If it doesn't break (or if we don't care), I'd be in favor of killing the DRM(...) stuff. If a lot of this stuff really is that device independent, why don't we move it to a separate kernel module? That would save some memory when multiple DRM drivers are loaded at once. I don't think the memory saving is very important, since multiple DRM modules must be a rare thing anyway. According with archives (http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS), Linus wanted the DRM drivers to be independent. Don't know if he still feels the same, considering the ALSA/OSS modules, or the recent reorganization of AGPGART. Don't know as well if the old DRM sub-drivers would do the same thing as these examples. Perhaps we can discuss again this after the janitorial is done, as I don't want to give steps greater than my legs. José Fonseca --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 09:31:27AM -0700, Linus Torvalds wrote: My only real underlying requirement is that compiled-in stuff works. I personally refuse to use modules, since I see no point to them when I compile the kernel for my machine _anyway_. Does this go any way towards explaining why it seems to be getting harder and harder to build modules outside of the kernel source tree while still leveraging the kernel build mechanism? I've been using a method for this based on what David Woodhouse suggested a while back, and it works for 2.4.x kernels and 2.5.x kernels up to 2.5.69. 2.5.70 seems to have presented another wrinkle to overcome. Is the ability to build modules located outside of the kernel source tree a consideration at all in the kernel module build process, or am I going down the wrong path with this? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
