On 5/21/23 23:58, Jessica Clarke wrote:
On 21 May 2023, at 22:37, Hans Petter Selasky <hsela...@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
