| Message ID | 20200401073249.340400-1-balbi@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Universal Serial Bus: Removing Acronyms | expand |
On Wed, Apr 01, 2020 at 10:32:42AM +0300, Felipe Balbi wrote:
> 764 files changed, 86304 insertions(+), 86304 deletions(-)
Ah, a nice tiny patchset, I'll try to sneak this in during the merge
window now :)
nice job...
greg "I know what day this is..." k-h
Hi, Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes: > On Wed, Apr 01, 2020 at 10:32:42AM +0300, Felipe Balbi wrote: >> 764 files changed, 86304 insertions(+), 86304 deletions(-) > > Ah, a nice tiny patchset, I'll try to sneak this in during the merge > window now :) That's great, Greg. It'll help hundreds of people, I'm sure. > nice job... Thank you > greg "I know what day this is..." k-h felipe "I've been mostly confined" balbi
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes: > > On Wed, Apr 01, 2020 at 10:32:42AM +0300, Felipe Balbi wrote: > >> 764 files changed, 86304 insertions(+), 86304 deletions(-) > > > > Ah, a nice tiny patchset, I'll try to sneak this in during the merge > > window now :) > > That's great, Greg. It'll help hundreds of people, I'm sure. > > > nice job... > > Thank you > > > greg "I know what day this is..." k-h > > felipe "I've been mostly confined" balbi > > -- Just one small comment, it may let the code line exceed 80 characters often, is it OK? Or the 80 characters per line is not mandatory? Peter
On Wed, Apr 01, 2020 at 10:26:25AM +0000, Peter Chen wrote: > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes: > > > On Wed, Apr 01, 2020 at 10:32:42AM +0300, Felipe Balbi wrote: > > >> 764 files changed, 86304 insertions(+), 86304 deletions(-) > > > > > > Ah, a nice tiny patchset, I'll try to sneak this in during the merge > > > window now :) > > > > That's great, Greg. It'll help hundreds of people, I'm sure. > > > > > nice job... > > > > Thank you > > > > > greg "I know what day this is..." k-h > > > > felipe "I've been mostly confined" balbi > > > > -- > > Just one small comment, it may let the code line exceed 80 characters often, > is it OK? Or the 80 characters per line is not mandatory? It's ok, it gives people who like running checkpatch.pl something to do :)
Hi, Peter Chen <peter.chen@nxp.com> writes: >> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes: >> > On Wed, Apr 01, 2020 at 10:32:42AM +0300, Felipe Balbi wrote: >> >> 764 files changed, 86304 insertions(+), 86304 deletions(-) >> > >> > Ah, a nice tiny patchset, I'll try to sneak this in during the merge >> > window now :) >> >> That's great, Greg. It'll help hundreds of people, I'm sure. >> >> > nice job... >> >> Thank you >> >> > greg "I know what day this is..." k-h >> >> felipe "I've been mostly confined" balbi >> >> -- > > Just one small comment, it may let the code line exceed 80 characters often, > is it OK? Or the 80 characters per line is not mandatory? 80-chars per line died once 4K monitors became mainstream. I thought that was documented in kernel-doc already. Isn't it? Looks like there's more work to be done.
On Wed, 1 Apr 2020, Felipe Balbi wrote: > > Hi, > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes: > > On Wed, Apr 01, 2020 at 10:32:42AM +0300, Felipe Balbi wrote: > >> 764 files changed, 86304 insertions(+), 86304 deletions(-) > > > > Ah, a nice tiny patchset, I'll try to sneak this in during the merge > > window now :) > > That's great, Greg. It'll help hundreds of people, I'm sure. > > > nice job... > > Thank you Yes indeed. Not to mention the admirable side effect of increasing the amount of exercise our fingers will get in the future while we write patches and new drivers. And a wonderful example of how a sizable _increase_ in the total size of the kernel source can lead to a _decrease_ in confusion for readers. (Plus this is a great illustration of how consistently violating the 80-column rule can be justifiable under the right circumstances.) Alan Stern
Hi, Felipe Balbi wrote: > Hi guys, > > in order to make our Universal Serial Community more welcoming, we have > decided to remove unnecessary acronyms from the code. This will be very > useful for newcomers as they won't have to guess what USB or XHCI means > and, instead, have it *always* spelled out. How did this decision come about? If the goal is to attract newcomers, I doubt more people recognize "universal serial bus" vs "usb". > I'm sure most of us here have suffered before trying to figure out what > an acronym means and we all know how much that hinders our hability to > focus on engineering. Let us all come together under an acronym-free > drivers/universal_serial_bus (note that renaming of directory will > happen in future commits after the code is completely cleaned up from > acronyms). While I agree that, for some, spelling out the acronym may help, but I don't think this is the right direction we should be heading. I can see a few issues with this approach. To list a few: 1) Can you immediately read and recognize this? My brain has to work extra hard for this: UNIVERSAL_SERIAL_BUS_UNIVERSAL_HOST_CONTROLLER_INTERFACE_BIG_ENDIAN_DESC vs USB_UHCI_BIG_ENDIAN_DESC 2) Backporting fix will be a pain 3) Grep won't be easy 4) Lines over 80 characters (I mean not just because of the screen size, but I think this is a good guideline to help with readability) IMHO, spelling out acronym should be in the documentation. Somehow, I doubt that newcomers reading this code will now have an "Aha!" moment and start to learn/contribute. Did we explore other ways to approach this? (such as adding more documentations where needed, and more sample codes?) > > Granted, the patches are a little big, but I think they can still be > squeezed during the merge window since there are no functional changes. > > Felipe Balbi (7): > universal serial bus: remove acronyms > open host controller interface: remove acronyms > universal host controller interface: remove acronyms > enhanced host controller interface: remove acronyms > extensible host controller interface: remove acronyms > designware cores universal serial bus3: remove acronyms > designware cores universal serial bus2: remove acronyms > > BR, Thinh
Thinh Nguyen wrote: > Hi, > > Felipe Balbi wrote: >> Hi guys, >> >> in order to make our Universal Serial Community more welcoming, we have >> decided to remove unnecessary acronyms from the code. This will be very >> useful for newcomers as they won't have to guess what USB or XHCI means >> and, instead, have it *always* spelled out. > How did this decision come about? If the goal is to attract newcomers, I > doubt more people recognize "universal serial bus" vs "usb". > you guys got me good... Thinh
On Wed, 2020-04-01 at 10:43 -0400, Alan Stern wrote: > On Wed, 1 Apr 2020, Felipe Balbi wrote: > > > > > Hi, > > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes: > > > On Wed, Apr 01, 2020 at 10:32:42AM +0300, Felipe Balbi wrote: > > >> 764 files changed, 86304 insertions(+), 86304 deletions(-) > > > > > > Ah, a nice tiny patchset, I'll try to sneak this in during the merge > > > window now :) > > > > That's great, Greg. It'll help hundreds of people, I'm sure. > > > > > nice job... > > > > Thank you > > Yes indeed. Not to mention the admirable side effect of increasing the > amount of exercise our fingers will get in the future while we write > patches and new drivers. And a wonderful example of how a sizable > _increase_ in the total size of the kernel source can lead to a > _decrease_ in confusion for readers. > I find that I will spend more time to read/write the code! e.g. -static void uhci_unlink_qh(struct uhci_hcd *uhci, struct uhci_qh *qh) +static void universal_host_controller_interface_unlink_qh(struct universal_host_controller_interface_hcd *universal_host_controller_interface, struct universal_host_controller_interface_qh *qh) > (Plus this is a great illustration of how consistently violating the > 80-column rule can be justifiable under the right circumstances.) > > Alan Stern >