Re: New DRM driver model - gets rid of DRM() macros!

From: Dave Airlie (airlied_at_gmail.com)
Date: 09/29/04

  • Next message: Christoph Hellwig: "Re: Adaptec aic79xx driver status" 
    Date:	Wed, 29 Sep 2004 23:41:16 +1000
To: Christoph Hellwig <hch@infradead.org>, Jon Smirl <jonsmirl@gmail.com>, dri-devel <dri-devel@lists.sourceforge.net>, Xserver development <xorg@freedesktop.org>, lkml <linux-kernel@vger.kernel.org>

    >
    > - once we have Alan's idea of the graphics core implemented drm_init()
    > should go awaw
    > - drm_probe (and it's call to drm_fill_in_dev) looks a little fishy,
    > what about doing the full ->probe callback in each driver where it
    > can do basic hw setup, dealing with pci and calls back into the drm
    > core for minor number allocation and common structure allocations.

    We have mentioned this but 90% of the work done by the drivers would
    be common, we might do it the otherway I suppose have a driver probe
    that calls a function in the core,

    > This would get rid of the ->preinit and ->postinit hooks.
    > - isn't drm_order just a copy of get_order()?
    > - any chance to use proper kernel-doc comments instead of the bastdized
    > and hard to read version you have currently?

    I think we have doxygen comments in there at the moment - the Mesa/DRI
    documentation is done with doxygen...

    > - the coding style is a little strange, like spurious whitespaces inside
    > braces, maybe you could run it through scripts/Lindent

    there are a fair few of these in there in the kernel, it could
    probably do with a Lindent at some stage over the whole thing...

    > - care to use linux/lists.h instead of opencoded lists, e.g. in
    > dev->file_last/dev->file_first or dev->vmalist
    > - drm_flush is a noop. a NULL ->flush does the same thing, just easier
    > - dito or ->poll
    > - dito for ->read
    > - why do you use DRM_COPY_FROM_USER_IOCTL in Linux-specific code?
    > - drm__mem_info should be converted to fs/seq_file.c functions
    > - dito for functions in drm_proc.c

    I think I can apply a lot of these to the current kernel code so I'll
    probably just start doing patches up for these sort of issues
    separately....

    I'll get time to create a bitkeeper tree taking Jons changes ready for
    merging to Andrew at least, and maybe Linus for 2.6.10.

    Dave.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Christoph Hellwig: "Re: Adaptec aic79xx driver status"

    Relevant Pages

    • Re: Tracking writes to a global section.
      ... this allocation, which takes a few us's is not a real problem. ... The fact that it seems to work for several hours before things break suggest that the problem is not the allocation of lines in the common, ... both processes marks it as used. ... logging to the applications. ...
      (comp.os.vms)
    • Re: Multithreaded GC!
      ... .NET test app which uses 50% of 1 core for the GC. ... Even though the current garbage collector implementation in .NET is ... every allocation by your main thread ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Tracking writes to a global section.
      ... The common area has room for 60 "stations". ... this allocation, which takes a few us's is not a real problem. ... It might be something bad happening at a restart? ... Restarting a single "station" doesn't change the data in the common ...
      (comp.os.vms)
    • Re: "kern", "kernel", "nucleus", "core"
      ... but not "kern"; ... core", and the whole thing was called a "magnetic core memory". ... As it was the only kind of main memory in common use, ...
      (alt.usage.english)
    • Re: Tracking writes to a global section.
      ... this allocation, which takes a few us's is not a real problem. ... suggest that the problem is not the allocation of lines in the common, ... It might be something bad happening at a restart? ... both processes marks it as used. ...
      (comp.os.vms)