Date: Wed, 24 May 2023 23:15:08 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Jessica Clarke <jrtc27@freebsd.org> Cc: Emmanuel Vadot <manu@bidouilliste.com>, Kyle Evans <kevans@freebsd.org>, John Baldwin <jhb@freebsd.org>, Mark Johnston <markj@freebsd.org>, Warner Losh <imp@bsdimp.com>, Konstantin Belousov <kostikbel@gmail.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: [RFC] An idea for general kernel post-processing automation in FreeBSD Message-ID: <12525a96-04aa-56d7-c79b-a24a52165490@selasky.org> In-Reply-To: <47B35276-B92A-49BC-A0FB-B71BA38ADA2A@freebsd.org> References: <b0461320-fb92-95cf-609b-3550eb30a589@selasky.org> <CANCZdfowk1oQnw30hk%2BA-pSq0_QK52dahF6x3AUi=A76J18R9w@mail.gmail.com> <ZGq03_RdpqXppA-h@kib.kiev.ua> <394775eb-1000-60d9-2ddd-5c2aca6c99ea@selasky.org> <CANCZdfq4D3N12c6h_Hy7Mvyg_d%2BpZBnN39CvpDU14-qDEhMFXQ@mail.gmail.com> <b6300144-41bb-53c9-b103-117547ff8a27@selasky.org> <08ba506f-66c5-35eb-e992-ecf9dfeccf93@selasky.org> <ZGy_3w4nUmTNxTm9@nuc> <eac6b35d-0d00-45d3-5925-7fcaccedac7e@FreeBSD.org> <CACNAnaHvz-BFRW193ZEr1wx%2BO7G_%2B1B68yHQ-TpYbX6=ferA1Q@mail.gmail.com> <20230524082850.ffc8793b6bb1b47325ae0139@bidouilliste.com> <39e6793a-33f9-8f48-30d3-eaa30d321452@selasky.org> <47B35276-B92A-49BC-A0FB-B71BA38ADA2A@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12525a96-04aa-56d7-c79b-a24a52165490>