We're looking at reorganizing the way DRM drivers are maintained.
Currently, the DRM kernel code lives deep in a subdirectory of the DRI
tree (which is a partial copy of the XFree86 tree). We plan to move it
"up" to its own module at the top level. That should make it *much*
easier for people that want to do things with the DRM but don't want all
the rest of X (i.e., DRI w/DirectFB, etc.).
When we do this move, we're open to the possibility of reorganizing the
file structure. What can we do to make it easier for kernel release
maintainers to merge changes into their trees?
This is cross-posted to LKML & dri-devel, and I'm not on LKML. If you
reply, please hit the 'Reply to all' button. :)
Ian Romanick <[email protected]> wrote:
>
> We're looking at reorganizing the way DRM drivers are maintained.
> Currently, the DRM kernel code lives deep in a subdirectory of the DRI
> tree (which is a partial copy of the XFree86 tree). We plan to move it
> "up" to its own module at the top level. That should make it *much*
> easier for people that want to do things with the DRM but don't want all
> the rest of X (i.e., DRI w/DirectFB, etc.).
>
> When we do this move, we're open to the possibility of reorganizing the
> file structure. What can we do to make it easier for kernel release
> maintainers to merge changes into their trees?
- Make sure that the files in the main kernel distribution are up to date.
- Prepare a shell script which does all the relevant file moves, send to
Linus, along with a diff which fixes up Kconfig and Makefiles.
- Start patching the files in their new locations.
--- Andrew Morton <[email protected]> wrote:
> Ian Romanick <[email protected]> wrote:
> >
> > We're looking at reorganizing the way DRM drivers are maintained.
> > Currently, the DRM kernel code lives deep in a subdirectory of the
> DRI
> > tree (which is a partial copy of the XFree86 tree). We plan to
> move it
> > "up" to its own module at the top level. That should make it
> *much*
> > easier for people that want to do things with the DRM but don't
> want all
> > the rest of X (i.e., DRI w/DirectFB, etc.).
> >
> > When we do this move, we're open to the possibility of reorganizing
> the
> > file structure. What can we do to make it easier for kernel
> release
> > maintainers to merge changes into their trees?
>
> - Make sure that the files in the main kernel distribution are up to
> date.
>
> - Prepare a shell script which does all the relevant file moves, send
> to
> Linus, along with a diff which fixes up Kconfig and Makefiles.
>
> - Start patching the files in their new locations.
>
>
we (as dri developers) should probably also sync the other way more
regularly too. sometimes there are changes in the kernel tree that
don't get back to the dri/drm tree in a timely manner.
Alex
__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
Andrew Morton wrote:
> Ian Romanick <[email protected]> wrote:
>
>>We're looking at reorganizing the way DRM drivers are maintained.
>>Currently, the DRM kernel code lives deep in a subdirectory of the DRI
>>tree (which is a partial copy of the XFree86 tree). We plan to move it
>>"up" to its own module at the top level. That should make it *much*
>>easier for people that want to do things with the DRM but don't want all
>>the rest of X (i.e., DRI w/DirectFB, etc.).
>>
>>When we do this move, we're open to the possibility of reorganizing the
>>file structure. What can we do to make it easier for kernel release
>>maintainers to merge changes into their trees?
>
> - Make sure that the files in the main kernel distribution are up to date.
>
> - Prepare a shell script which does all the relevant file moves, send to
> Linus, along with a diff which fixes up Kconfig and Makefiles.
>
> - Start patching the files in their new locations.
I'm not 100% sure what you mean. Right now the files in our CVS are
split between two directories. There's a "common" directory, which is
used on both Linux & BSD, and a Linux-specific directory. Our intention
is to shift around where some of the files are in our CVS. I don't
think we intend to move where things are in the Linux source tree.
That's part of why I'm asking. From talking to Linus in the past, I
know that merging in changes is a PITA due to our funky directory
structure. I'd like to make that easier. :)
Ian Romanick <[email protected]> wrote:
>
> >>When we do this move, we're open to the possibility of reorganizing the
> >>file structure. What can we do to make it easier for kernel release
> >>maintainers to merge changes into their trees?
> >
> > - Make sure that the files in the main kernel distribution are up to date.
> >
> > - Prepare a shell script which does all the relevant file moves, send to
> > Linus, along with a diff which fixes up Kconfig and Makefiles.
> >
> > - Start patching the files in their new locations.
>
> I'm not 100% sure what you mean. Right now the files in our CVS are
> split between two directories. There's a "common" directory, which is
> used on both Linux & BSD, and a Linux-specific directory. Our intention
> is to shift around where some of the files are in our CVS. I don't
> think we intend to move where things are in the Linux source tree.
>
> That's part of why I'm asking. From talking to Linus in the past, I
> know that merging in changes is a PITA due to our funky directory
> structure. I'd like to make that easier. :)
Oh. So what was the question again?
As far as I know, there's nobody in DRI-land who actually prepares and
sends patches. Fixing that would be a good first step ;)
I've had a 130k DRM patch in -mm since February 8th. Presumably it's out
of date. As far as I know nobody is pushing more recent patches upstream.
What's the process here, and who should I be dealing with?
Thanks.
--- Ian Romanick <[email protected]> wrote:
> That's part of why I'm asking. From talking to Linus in the past, I
> know that merging in changes is a PITA due to our funky directory
> structure. I'd like to make that easier. :)
Part of the pain could be caused by the shared/linux split in the DRM tree. The
kernel tree doesn't have that split.
Also DRM makefile.kernel and the kernel char/drm/Makefile are similar but not
the same. So any changes to the build procedure would need to be updated into
char/drm/Makefile.
drmstat.c/dristat.c should be pulled out of the driver directory and put it in a
directory for apps.
Where should Doxyfile and config.in go?
The savage driver is not currently in the kernel. Should the mach64 driver be
moved out of the branch and into the DRM project?
The best solution would be to have some kind of scipt in the DRM project that
builds a directory that can simply be copied into char/drm.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
On Mon, Mar 15, 2004 at 04:31:31PM -0800, Andrew Morton wrote:
> I've had a 130k DRM patch in -mm since February 8th. Presumably it's out
> of date. As far as I know nobody is pushing more recent patches upstream.
The patch you've been carrying for a while has a number of bogons,
like duplicating pci.ids inside the radeon driver for no good reason.
> What's the process here, and who should I be dealing with?
In the past most of the merges were done by Linus. I don't recall
seeing a 'dri maintainer' per se ever sending resync patches.
Dave