They named a function slightly poorly. As if Linus has never done that.
Not only that. They introduced a obscure function, which inner workings are not clear and that is only used by their new code into a global header which is used by many other code parts, which means other people could start using it. This could lead to bugs since the semantics are not clear from the function name or if they change the function in the future. Also they added their pull request much too late to be properly reviewed.
Also that it was requested earky if it was going to be submitted.
Seems like Linus is accusing them of doing it last minute because they wanted to take advantage of him being busy as an intentional strategy, as he said and they didn’t even submit a good offering.
That last bit kind of sounds up that he might have accepted in spite of his difficulty due to travel, but they also fucked that up and wasted a whole lot of effort.
This really seems like a public lesson for everyone else using this submission as an example of what he does not want other people to do and then proceeds to explain exactly how he feels about it.
It’s definitely a rant, did seem like it had a purpose to it beyond him just letting out a rant
Cmon, this is not about naming, this is about non-generic code in generic header.
IMO hiding such a little operation behind a macro/function just hurt readability. Furthermore, considering that this function is only used once in the provided patch and that word ordering on RISC-V is not about to change anytime soon, it is perfectly fine to inline the code.
Making a u32 pointer from to u16’s isn’t a generic operation because it has to make assumptions about how the pointers work (in particular what endianess they have)
Yeah or they’ll say “fuck this” and quit.
It’s hardly a fuck up. They named a function slightly poorly. As if Linus has never done that.
I read is rant, seems more than just a poor naming issue
Not only that. They introduced a obscure function, which inner workings are not clear and that is only used by their new code into a global header which is used by many other code parts, which means other people could start using it. This could lead to bugs since the semantics are not clear from the function name or if they change the function in the future. Also they added their pull request much too late to be properly reviewed.
Also that it was requested earky if it was going to be submitted.
Seems like Linus is accusing them of doing it last minute because they wanted to take advantage of him being busy as an intentional strategy, as he said and they didn’t even submit a good offering.
That last bit kind of sounds up that he might have accepted in spite of his difficulty due to travel, but they also fucked that up and wasted a whole lot of effort.
This really seems like a public lesson for everyone else using this submission as an example of what he does not want other people to do and then proceeds to explain exactly how he feels about it.
It’s definitely a rant, did seem like it had a purpose to it beyond him just letting out a rant
Cmon, this is not about naming, this is about non-generic code in generic header.
IMO hiding such a little operation behind a macro/function just hurt readability. Furthermore, considering that this function is only used once in the provided patch and that word ordering on RISC-V is not about to change anytime soon, it is perfectly fine to inline the code.
(a << 16) | bis about the most generic code you can get. How is that remotely RISC-V specific?Making a u32 pointer from to u16’s isn’t a generic operation because it has to make assumptions about how the pointers work (in particular what endianess they have)
What makes you think it’s making a pointer? Nobody said anything about that.
Oh my bad I don’t know where I got that from lol
Nw. You’re also wrong about endianness. This function would be written exactly the same irrespective of endianness:
uint32_t u16_high_low_to_u32(uint16_t high, uint16_t low) { return (high << 16) | low; }That is endian agnostic.