Re: [RFC] Refactoring of dix/dixutils.c
Tomas Carnecky wrote: > Fernando Carrijo wrote: > > > > I probably didn't understand quite well the reason for what you guys mean by > > server-side XCB. Google did't help too much either, although I wonder it > > might > > be not far from avoiding the burden of maintaining bulky and error-prone > > code > > by automatically generating server internal request dispatch stubs based on > > XML > > descriptions of the protocol. Is it better documented somewhere? > > A few weeks I slowly started to work on that. Currently I have the DPMS > extension protocol completely handled with code that I generate from > xml. Maybe it's time to submit my work so far for review. Btw, I've > chosen to put the source into a top-level directory proto/, because, > after all, it's related to the X11 protocol. Cool! That's a good direction for me to follow. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Refactoring of dix/dixutils.c
On 7/30/10 5:22 PM, Fernando Carrijo wrote: > I probably didn't understand quite well the reason for what you guys mean by > server-side XCB. Google did't help too much either, although I wonder it might > be not far from avoiding the burden of maintaining bulky and error-prone code > by automatically generating server internal request dispatch stubs based on > XML > descriptions of the protocol. Is it better documented somewhere? A few weeks I slowly started to work on that. Currently I have the DPMS extension protocol completely handled with code that I generate from xml. Maybe it's time to submit my work so far for review. Btw, I've chosen to put the source into a top-level directory proto/, because, after all, it's related to the X11 protocol. tom ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Refactoring of dix/dixutils.c
On Fri, Jul 30, 2010 at 12:22:23PM -0300, Fernando Carrijo wrote: > I probably didn't understand quite well the reason for what you guys mean by > server-side XCB. Google did't help too much either, although I wonder it might > be not far from avoiding the burden of maintaining bulky and error-prone code > by automatically generating server internal request dispatch stubs based on > XML > descriptions of the protocol. Correct! > Is it better documented somewhere? I think there have been a couple of GSoC projects along those lines. > Either way, I took notes of all people's opinions because I really plan to > further investigate these questions in the future, as soon as I finish some > other more immediate tasks. For the time being, I will deliver a patch series > based on this RFC, with minor stylistic modifications. Sounds fine to me, though my word is not gospel. :) Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Refactoring of dix/dixutils.c
Daniel Stone wrote: > > Fernando Carrijo wrote: > > > > Peter Hutterer wrote: > > > > > > You'll probably have some fun untangling the various ProcRequestName from > > > the dix source files (static files, file-specific defines, etc.). And tbh. > > > I'm not totally convinced that this is worthwile. What's the goal you're > > > trying to achieve? Just a cleanup? If so, could that be achived by simply > > > grouping the ProcRequestName in the respective files? > > > Or are you working towards that elusive goal of server-side xcb? :) > > > > No, I didn't plan nothing that big. On the contrary: after reading > > dixutils.c, > > I simply envisioned the possibility of relocating some functions which > > sounded > > cohesive enough to deserve their own files. If that represents the first > > step > > in the direction of more daring changes, God only knows! > > I think the cleanup is a worthwhile goal in and of itself, if it helps > us separate common utility functions we need to reuse, from the > drudgework of (de)marshalling. Especially if it helps us get even a > little bit closer to server-side XCB. I probably didn't understand quite well the reason for what you guys mean by server-side XCB. Google did't help too much either, although I wonder it might be not far from avoiding the burden of maintaining bulky and error-prone code by automatically generating server internal request dispatch stubs based on XML descriptions of the protocol. Is it better documented somewhere? Either way, I took notes of all people's opinions because I really plan to further investigate these questions in the future, as soon as I finish some other more immediate tasks. For the time being, I will deliver a patch series based on this RFC, with minor stylistic modifications. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Refactoring of dix/dixutils.c
Hi, On Thu, Jul 29, 2010 at 11:58:48PM -0300, Fernando Carrijo wrote: > Peter Hutterer wrote: > > I'd say use proto/ for the core protocol handling and put pure protocol util > > functions into /proto/protoutils.c. The dix util function can then stay in > > dix/dixutils.c. all the other protocol stuff is part of the extension > > directories anyway. > > I'm getting lost! Names proliferate too fast here! :) Sounds sensible to me. > > You'll probably have some fun untangling the various ProcRequestName from > > the dix source files (static files, file-specific defines, etc.). And tbh. > > I'm not totally convinced that this is worthwile. What's the goal you're > > trying to achieve? Just a cleanup? If so, could that be achived by simply > > grouping the ProcRequestName in the respective files? > > Or are you working towards that elusive goal of server-side xcb? :) > > No, I didn't plan nothing that big. On the contrary: after reading dixutils.c, > I simply envisioned the possibility of relocating some functions which sounded > cohesive enough to deserve their own files. If that represents the first step > in the direction of more daring changes, God only knows! I think the cleanup is a worthwhile goal in and of itself, if it helps us separate common utility functions we need to reuse, from the drudgework of (de)marshalling. Especially if it helps us get even a little bit closer to server-side XCB. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Refactoring of dix/dixutils.c
Peter Hutterer wrote: > Fernando Carrijo wrote: > > > > Would you guys mind if I chose /dix/core and /dix as the new homes for files > > related to the core protocol and the protocol support routines, > > respectively? > > Whenever possible, I prefer to avoid the names "utils" or "misc" for I > > believe > > they emphasize the less important side of the coin. > > I'd say use proto/ for the core protocol handling and put pure protocol util > functions into /proto/protoutils.c. The dix util function can then stay in > dix/dixutils.c. all the other protocol stuff is part of the extension > directories anyway. I'm getting lost! Names proliferate too fast here! :) > You'll probably have some fun untangling the various ProcRequestName from > the dix source files (static files, file-specific defines, etc.). And tbh. > I'm not totally convinced that this is worthwile. What's the goal you're > trying to achieve? Just a cleanup? If so, could that be achived by simply > grouping the ProcRequestName in the respective files? > Or are you working towards that elusive goal of server-side xcb? :) No, I didn't plan nothing that big. On the contrary: after reading dixutils.c, I simply envisioned the possibility of relocating some functions which sounded cohesive enough to deserve their own files. If that represents the first step in the direction of more daring changes, God only knows! ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Refactoring of dix/dixutils.c
On Thu, Jul 29, 2010 at 10:34:27PM -0300, Fernando Carrijo wrote: > Vignatti Tiago wrote: > > > Jamey Sharp wrote: > > > > > > The proposed "lookup.c" is mostly about protocol implementation, though, > > > and I'd be happy to see another patch after this series that reorganizes > > > dix/ to highlight the protocol implementation bits. Perhaps a separate > > > top-level proto/ tree? > > > > exactly. Someway of highlighting protocol implementation only is all that I > > tried to explain in my last email. A top-level proto/ with a proto/utils/ > > sounds nice for me. > > Would you guys mind if I chose /dix/core and /dix as the new homes for files > related to the core protocol and the protocol support routines, respectively? > Whenever possible, I prefer to avoid the names "utils" or "misc" for I believe > they emphasize the less important side of the coin. I'd say use proto/ for the core protocol handling and put pure protocol util functions into /proto/protoutils.c. The dix util function can then stay in dix/dixutils.c. all the other protocol stuff is part of the extension directories anyway. > Someone else oppose? You'll probably have some fun untangling the various ProcRequestName from the dix source files (static files, file-specific defines, etc.). And tbh. I'm not totally convinced that this is worthwile. What's the goal you're trying to achieve? Just a cleanup? If so, could that be achived by simply grouping the ProcRequestName in the respective files? Or are you working towards that elusive goal of server-side xcb? :) Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Refactoring of dix/dixutils.c
Vignatti Tiago wrote: > Jamey Sharp wrote: > > > > The proposed "lookup.c" is mostly about protocol implementation, though, > > and I'd be happy to see another patch after this series that reorganizes > > dix/ to highlight the protocol implementation bits. Perhaps a separate > > top-level proto/ tree? > > exactly. Someway of highlighting protocol implementation only is all that I > tried to explain in my last email. A top-level proto/ with a proto/utils/ > sounds nice for me. Would you guys mind if I chose /dix/core and /dix as the new homes for files related to the core protocol and the protocol support routines, respectively? Whenever possible, I prefer to avoid the names "utils" or "misc" for I believe they emphasize the less important side of the coin. Someone else oppose? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Refactoring of dix/dixutils.c
On Thu, Jul 29, 2010 at 05:59:06AM +0200, ext Jamey Sharp wrote: > > The proposed "lookup.c" is mostly about protocol implementation, though, > and I'd be happy to see another patch after this series that reorganizes > dix/ to highlight the protocol implementation bits. Perhaps a separate > top-level proto/ tree? exactly. Someway of highlighting protocol implementation only is all that I tried to explain in my last email. A top-level proto/ with a proto/utils/ sounds nice for me. Cheers, Tiago ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Refactoring of dix/dixutils.c
I like this series. I haven't had a chance to confirm that the code is moved unchanged into the new source files, or to think about your copyright notices question, but splitting distinct functionality out of dixutils.c seems like an excellent idea to me. On Wed, Jul 28, 2010 at 05:55:38PM +0300, Tiago Vignatti wrote: > Basically dix code is what is written and mandatory in the core protocol. This might be a good description of what DIX *should* be, but it certainly isn't a description of what it *is*. The bulk of the code that Fernando has pulled out is implementation details that are not protocol-visible. I think those are reasonable to treat as part of the beast named "DIX", since they are not only device-independent but also OS-independent; and since they aren't rendering-related they don't belong in the "machine-independent" part. The proposed "lookup.c" is mostly about protocol implementation, though, and I'd be happy to see another patch after this series that reorganizes dix/ to highlight the protocol implementation bits. Perhaps a separate top-level proto/ tree? I wouldn't hold up this series waiting for that reorganization, though. In my opinion any improvement to this codebase is welcome. Jamey signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Refactoring of dix/dixutils.c
On Wed, Jul 28, 2010 at 07:42:18AM +0200, ext Fernando Carrijo wrote: > My humble attempt to put some order in dix. For lack of inspiration > (or knowledge, if you prefer) I didn't touch the original copyright > notices, and simply copied them verbatim to the new files; exactly > like I did to headers. Ugly, I presume. But just a first try. > > Do people see any value in things like these? yeah, I like it and think we need more of this kind of organization in X code base. But I'm bit concerned about your actual changes. Basically dix code is what is written and mandatory in the core protocol. So before go and chop off the code, one thing to put in mind is the separation between what is in the protocol and what is just "utils", like the rest. The ideal would be to separate protocol description only in some files and the mechanism to drive them (utils) in other files. Things like ffs.c, ptrveloc.c and *utils.c could go somewhere else (maybe dix/utils), to make such distinction. That's my theory, let's see if other developers have something to say. Cheers, Tiago ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[RFC] Refactoring of dix/dixutils.c
My humble attempt to put some order in dix. For lack of inspiration (or knowledge, if you prefer) I didn't touch the original copyright notices, and simply copied them verbatim to the new files; exactly like I did to headers. Ugly, I presume. But just a first try. Do people see any value in things like these? -- dix/Makefile.am|7 +- dix/blockhandler.c | 243 dix/callback.c | 333 +++ dix/dixutils.c | 634 dix/lookup.c | 190 dix/sleepqueue.c | 184 +++ dix/workqueue.c| 176 +++ 7 files changed, 1132 insertions(+), 635 deletions(-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
