Keith Whitwell wrote:
>
> Eric Anholt wrote:
> >
> > On Mon, 2002-05-13 at 16:59, Jens Owen wrote:
> > > Eric,
> > >
> > > The watermark I would apply for measuring the success of OS-templating
> > > is device indepedence. If all device specific code can go into the
> > > shared/drm/kernel directory and only device independent code is found in
> > > the OS specific directories <os>/drm/kernel then this will be a huge
> > > step forward for the DRI. It's likely you'll end up with some OS
> > > specific #ifdef's in the shared directory, but if you can completely
> > > remove these ifdef's while supporting three or more OS's then we can be
> > > confident we have a great template interface, and you can focus more of
> > > your efforts on keeping up to date with general DRM functionality and
> > > less on each device specific implementation.
> >
> > The device-specific stuff (*_state.c, dma, cp, cce, etc) is almost
> > completely independent of OS.
"almost" is good--"completely" is best. Getting it "almost" independent
tells me an OS specific maintainer still needs to get involved--however
the work load on that maintainer is lighter. Reaching the point of
"completely" independent enables new enhancements and drivers to be
brought on line for all OS's simultaneously--only requiring the OS
maintainer to get involved if a driver is not working correctly on their
specific OS. I realize I am encourage work on the wrong side of the
80/20 rule: 80% of the functionality takes 20% of the time and the
other 20% of the functionality takes 80% of the time. However, the
extra time put into completing this abstraction, will enable the open
source development cycle to take over and yield much better parallel
testing and development.
> > The changes for those are macros like
> > DRM_OS_IOCTL, macros for copyin/copyouts, and watching how we deal with
> > return codes (they're positive on BSD).
Great. If we need to make changes on the Linux side to make things more
portable (like error codes), we can consider that as well--however, it
sounds like you have been abstracting this okay.
> > There's currently an ifdef for
> > each of the dma/cp/cce files for linux/FreeBSD because of different list
> > handling, but because it's common we could put it in drm_os_*.h.
I'll let Keith comment on this--he knows the code here better than me.
> > Overall there is very little changed in these files. I'm guessing that
> > adding Net/OpenBSD would not make any changes to this file, only to
> > drm_os_*bsd.h.
Great.
> > The bulk of the ifdefs are in stuff like drm_drv.h, but in my current
> > setup that is in the "shared directory" (I don't have it split into
> > directories yet). To clarify, do you want all the device-independent
> > (most drm_*.h) files to be split for Linux/BSD?
>
> I've got some time to take a look at this over the next couple of days. It
> really depends how big the differences are - but probably we need to come up
> with a way of doing things without too much #ifdef crud in the main code --
> whether this means we need an abstraction layer, more templating to account
> for OS differences, or other, I don't know. I don't really like the seperate
> directories idea as this means it is easy for them to get out-of-sync.
Keith, do you mean directories out of sync with each other, or out of
sync with their respective kernel repositories?
> I'd
> rather have the core logic in one place only, and have OS-specifics somehow
> mixed in.
If we had everything in one directory, would the kernel maintainers
accept all the files, or would they end up pruning out the OS specific
files they weren't interested in?
> Is your latest code available somewhere?
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________________________
Hundreds of nodes, one monster rendering program.
Now that's a super model! Visit http://clustering.foundries.sf.net/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
