Re: git: 805d759338a2 - main - mlx4: Move DEFINE_MUTEX() outside function body.

On 5/21/23 23:58, Jessica Clarke wrote:
> On 21 May 2023, at 22:37, Hans Petter Selasky <hselasky@freebsd.org> wrote:
>> On 5/21/23 21:41, Jessica Clarke wrote:

>>
>> I can not know what you know before you tell me. I'm not a mind reader and I for sure don't think you are an idiot. Those are in such case your own words about yourself and not mine, to make it clear.
> 
> You can’t know, though you could go look at commit history to see that I have made changes to the build system and thus probably have an understanding. Or you could assume that I know what I’m talking about when I choose to engage. Both are good things to do that show some amount of respect, otherwise you are at risk of insulting people by assuming that you need to explain the basics to them.

Hi Jess,

I also have a commit history, but I don't use the number of commits I've 
made in the past as an argument to gain respect. Respect is something 
your earn from others and not something you give yourself.

A good way to resolve disputes is to go through the basics to find out 
where differences occur. It is simply echoing back what the other person 
is saying in your own words. It has nothing to do about insulting 
people. That is something you need to accept as a method of resolving 
problems, because in this world there are many different people, and 
many different minds.

> 
>>>> If you are worried multiple DEFINE_MUTEX(lock) will result in multiple global symbols having the same "lock" name, all you need to do is pass through the ${.TARGET} variable from "make" as a define, stripping a few invalid characters, and macro-concat that to the locally generated global variable name, and you are all good.
>>
>>> You could. But that’s a pretty gross hack IMO, and depending on how you do it may still not be unique. Not to mention it’s going to further bloat the symbol tables with these long names.
>>
>> Why do you think I don't know what a hack is?
> 
> I didn’t. I said “IMO”. *My* opinion.

It is a hack and that is what I do for a living. I write code, I don't 
buy code. I make solutions, I don't buy solutions. And regular people 
call me a hacker. And when newspapers write about hackers they show a 
screenshot of Linux Ubuntu and a terminal with green letters and black 
background. In the next sentence they usually write something about 
viruses spreading or Bitcoin dissappearing. According to the "world" I'm 
a criminal. And when you say "that's a pretty gross hack IMO", maybe I 
should take that as a compliment. Yeah, I'm a hacker after all, and my 
hacks are pretty gross. The worst hacker out there you can get ....

> 
>> In the case about the "lock" name being global:
>>
>> - My solution is to pass a define to the compiler to help make the identifier unique across the monotolithic kernel build.
>>
>> - When building the LINT target, the linker will fail if there are duplicate global symbols. Then the debug information output by the linker will tell the file and line. Go there and change the identifier. It should be rare. Problem solved.
>>
>> - All symbols being made global for the sake of processing them, are listed by name. And after the final sorted sysinit table is created and linked, all those symbol names can be stripped away from the resulting binary, and then only the relocations remain, if I'm not mistaken. I didn't do that in my differential review, because it is a prototype. The argument about symbol table bloat, because of prefixing or suffixing global symbols is not valid the way I see it.
>>
>>> Given the sysinit subsystem still needs to be able to merge in new sysinits registered dynamically, one might as well just do the sort dynamically, it’s very little added complexity on top, especially when sorting functions are just a libkern call away. Much less complexity than all this scripting to generate tables.
>>
>> Do you agree about the following statement or not?
>>
>> If you have two already sorted lists and a pointer to each of them, then:
>>
>> Method a) place the two lists after each other in memory and then call qsort() on the resulting list, is relatively slow.
>>
>> Method b) look at the next element from each list, and store the smallest one into the destination list, and repeat until the end of both source lists are reached, is relatively much faster.
> 
> Clearly merging is faster. But compared with qsort it’s unlikely to be all that significant; lg n grows slowly.

Right, and invoking a sorting function on an already sorted list, is not 
needed if you think about it.

>>>> Your comment is correct based on your prior knowledge about Linux and compilers. But at this point FreeBSD is different. That's why porting code from Linux to FreeBSD is sometimes difficult, because you need to keep track of how source files are renamed. You cannot just use "meld Linux/blah FreeBSD/blah" to compare directories ...
>>> DEFINE_MUTEX is Linux’s API, implemented in LinuxKPI. So Linux’s behaviour is absolutely relevant. Any deviation from Linux’s semantics is an incompatibility that requires patching any sources that are built for FreeBSD using LinuxKPI. It is generally best to minimise that.
>>
>> One side of this is compile time issues. If a developer needs to change something to make the code compile for FreeBSD, that's acceptable. And then the developer can also say the code was made for FreeBSD and not Linux, which is good with regards to the GPLv2 license, and not just copying solutions from Linux or being force to implement things exactly like on Linux, so-called bug-by-bug compliance.
>>
>> The other side is runtime issues. Here the goal should be to minimise issues to zero and try to outperform Linux.
> 
> I don’t have any clue what you’re going on about here. Tweaking Linux code to be compatible with FreeBSD’s LinuxKPI doesn’t suddenly render the code free from GPLv2, it’s still Linux-derived code, but you’ve had to modify it rather than be able to use it as-is, which is the goal of LinuxKPI, where possible. And so ideally *no* changes would be acceptable. So I disagree with your statement that needing to change things is acceptable; it’s only acceptable where there is no good alternative.

This is about implementing the LinuxKPI itself and the APIs provided by 
the Linux kernel. Because the LinuxKPI is BSD licensed the code vendors 
have an option to dual license their kernel code between Linux and 
FreeBSD. Like I wrote, implementing APIs differently than in Linux, is 
good thing resolving disputes about licensing. And other times it is 
more difficult to do that. I hope these clues help you see what is going 
on there.

> 
> I don’t see what “outperform Linux” has to do with any of this discussion.
> 
That's about something else.

--HPS