[lkml]   [2004]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: DRM code reorganization
    Jon Smirl wrote:
    >>4) DRM code reorganization. There were several requests to reorganize
    >>DRM to more closely follow the Linux kernel guidelines. This
    >>reorganization should occur before new features are added.
    > What should be the model for reorganizing DRM? An obvious change is
    > eliminate the naming macros.
    > Another is to change to a personality with helper library model like
    > fbdev has. All of the common DRM code would go into a library module.
    > Each card would then have a small device specific module which depends
    > on the library module for common code.

    This would be *very* non-trivial to do. Doing the DRM like this has
    come up probably a dozen times (or more) over the last 3 years. The
    problem is that each driver has different needs based on hardware
    functionality. We've managed to classify these needs into a few groups,
    and drivers can select which functionality they need via a set of
    defines. These per-driver defines determine what code gets compiled
    into the different routines (as well as which routines even get built).

    Trying to make this into a library would just be a mess. It would
    either break cases where multiple DRMs are built (or loaded) into the
    kernel or result in a *ton* of unused, nearly duplicate routines being
    built into the library.

    If this is something that we really want to pursue, someone needs to dig
    in and figure out:

    1. How much / which code can be "trivially" shared?
    2. How much / which code can be shared with very little work?
    3. How much / which code would we rather get a root-canal than try to
    make shared?

    The concern has been that, by making a "generic" library layer, we'd
    actually make the DRM more difficult to maintain. Nobody has really had
    the time to do the research required to either substantiate or refute
    those claims. Based on the little experience I have in the DRM, I tend
    to believe them.

    > ian: what about splitting the current memory management code into a
    > module that can be swapped for your new version?

    AFAIK, the only drivers that have any sort of in-kernel memory manager
    are the radeon (only used by the R200 driver) and i830. That memory
    manager only exists to support an NV_vertex_array_range-like extension
    that some Tungsten customers needed. I don't think there would be any
    benefit to making that swappable.

    Once the new memory manager is in, 80% (or more) of the code will be in
    user-mode anyway. The code that will be in the kernel should be generic
    enough to be completely sharable (i.e., in a generic DRM library).

    > Are other structure changes needed?
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.022 / U:0.084 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site