Re: [RFC] An idea for general kernel post-processing automation in FreeBSD

On 5/24/23 17:20, Jessica Clarke wrote:
>> 1.2) Compiletime sorting puts more requirements on the toolchain. Referring Jessica Clarke, this is a "gross hack". On the other hand, debugging and visibility makes this desirable.
> I’ve been deliberately staying out of my thread, but this is blatantly false. I said that in response to*one specific part of your proposed implementation*, which is completely different to saying it about the general concept. The full quote is:
> 
>>> 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.
> 
> So this is some pretty horrendous misquoting. Do not do that again. I am extremely unimpressed.

This e-mail is a side track into the LinuxKPI regarding the 
DEFINE_MUTEX() Jess asked about.

Hi Jess,

In FreeBSD DEFINE_MUTEX() is both a SYSINIT() and a mutex. The "lock" 
name propagates to both the mutex and the SYSINIT(). The problem is not 
the mutex part, but the SYSINIT() part:

#define DEFINE_MUTEX(lock) \
         mutex_t lock; \
         SX_SYSINIT_FLAGS(lock, &(lock).sx, mutex_name(#lock), SX_DUPOK)


Your answer is according to how DEFINE_MUTEX() is implemented in Linux:

#define	DEFINE_MUTEX(mutexname) \
         struct mutex mutexname = __MUTEX_INITIALIZER(mutexname)


This is a FreeBSD list, and here we discuss how things are working in 
FreeBSD and not Linux. In FreeBSD we don't have any equivalent of 
__MUTEX_INITIALIZER() for SX locks, yet. The DEFINE_MUTEX() macro in 
FreeBSD is then currently not 100% compatible with the one in Linux. 
This is probably something to work on. Right now, putting a 
SX_SYSINIT_FLAGS() inside the DEFINE_MUTEX() macro just works.


I have a feeling our background and experiences are somewhat different. 
We put different meaning behind the words in our e-mail changes, leading 
up to apparent frustration.


I see why you are burning in your mind, because you think FreeBSD tries 
to emulate Linux, and at the same time they are not fully compatible 
with Linux, and you don't get how that makes sense.

The LinuxKPI is mapping functionality in Linux to FreeBSD. Mapping means 
there is a transform. This sometimes leave FreeBSD in a corner, we need 
to patch Linux kernel code ported to FreeBSD, because the transforms 
being used, are not covering a particular case. This is the price 
FreeBSD has to pay, to use its kernel, internals and way of thinking.

I have no clue how much operating system work you've done, and at what 
level and without going into further details and explanations, I kindly 
ask you to accept: Linux code on Linux is not the same like Linux code 
on FreeBSD. It may behave differently, have different timing, different 
synchronization, but not always.

You can talk to me, manu@, emaste@, bz@ and several others about what is 
going on there and the history behind the LinuxKPI and why it ended up 
this "confusing" way.

If you already know all of this, and feel I'm teaching you basics again, 
please disregard this e-mail.

Thank you!

--HPS