Hello, my name is Mario Rugiero, and I'm in the process of resurrecting
the attempts to get the via driver in shape, and had a few questions on
the proper etiquette for such a thing.
As some may know, there are talks about removing dri1 support on X.org,
so we (the users interested) should update the kernel and userspace
drivers if we want to still be able to use them with newer
distributions, so I volunteered to try and get it done for the kernel
driver.
Looking at the driver code I found there are some style issues, along
with some potential code smell. I've found a lot of checkpatch and
sparse warnings. My original plan was to get it clean in those aspects
first, issue by issue, then start replacing deprectated interfaces and
lastly get it to work with dri2/3 and KMS, this based on James Simmons
work and the advices he got when he sent an RFC patchset.
First and foremost, I wanted to know if this roadmap makes sense for
some more experienced kernel developers, and if style patches are
accepted in the drm list (I know for staging they are, but could be
different there), as they would be the first ones.
Also, I was wondering what's the right approach when there is a
preexistent style issue in a line your patch touches. Should I fix the
issue in the same patch, send a patch fixing the issue first or just
send the patch as is and ignore the issue. For example, in a local copy
of drm-testing I have, I replaced all __inline__ by inline, as suggested
by checkpatch. One of the lines had a misplaced * operator, and thus
checkpatch complains about it. My plan for that patch was to send it as
is, and fix all misplaced operators in a later patch. What do you think
about this? Is this right? Wrong? Awfully wrong?
Sorry for the long mail, but I tried googling and found nothing
answering these questions, and I preferred to bother with the questions
first instead of wasting reviewers time with fundamentally wrong patches.
Thanks for any advice,
Mario Rugiero.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
