Perhaps you could use accessor functions to read/write 8, 16 32, 64 bit values.
Each scalar value will be properly aligned and, hence, will lie within a
page.Sent from my Galaxy
-------- Original message --------From: Ville Juven <ville.ju...@gmail.com>
Date: 4/18/23 3:48 AM (GMT-06:00) To: dev@nuttx.apache.org Subject: Re:
[Breaking change] Move nxmutex to sched Hi,Sorry for the spamfest. Forget what
I said about the alignment being asolution. It is not. Any object allocated
from heap that contains a sem_tstructure cannot guarantee that the alignment of
sem_t is correct.So I was just being dumb..Br,Ville JuvenOn Tue, Apr 18, 2023
at 11:39 AM Jukka Laitinen <jukka.laiti...@iki.fi>wrote:> Hi,>> I like the
alignment idea, thanks for bringing it up!>> I think forcing the alignment for
the semaphore, and accessing it> directly via page pool from the kernel is the
simplest and most trivial> thing. It implements what also Greg suggested +
fixes the issue of> semaphore being on the page boundary.>> Since the
semaphores in CONFIG_BUILD_KERNEL just don't work at all> currently, the best
option for now, IMHO, is to implement this solution> and always align the
semaphores as suggested in (and only in)> CONFIG_BUILD_KERNEL case. This just
makes the semaphores work with> minimal code changes.>> I still wouldn't bury
the idea of splitting the semaphore into user and> kernel parts entirely. To me
it would make perfect sense to cleanly> separate things which belong to kernel
from the things that belong to> user space. That solution just needs to
maintain the real time> properties, as discussed before, and not break existing
functionality or> increase memory consumption.>> Current semaphore solution,
even with the page-pool access, still has> the problem that user side code has
got access to structures belonging> to the kernel (lists which kernel loops
through while scheduling &> managing priority inheritance). So a user side
process corrupting it's> own semaphore structure can at least crash or jam the
kernel.>> But, first things first, the solution which Ville suggested below
would> fix the most burning issue for us for now.>> Thanks,>> Jukka>>> On
18.4.2023 10.26, Sebastien Lorquet wrote:> > Hi all,> >> > As Tomek said,
whatever you choose to do, please make sure everything> > of this is absolutely
kept optional, at least during the merge and> > community validation phase.> >>
> I dont think connecting these proposals to CONFIG_BUILD_KERNEL is> > granular
enough.> >> > Thanks,> >> > Sebastien> >> > Le 18/04/2023 à 09:18, Ville Juven
a écrit :> >> Hi all,> >>> >> Sorry, this is going a bit off topic.> >>> >> One
wild solution specifically to solve my/our problem> >> (CONFIG_BUILD_KERNEL)
might be to force a "next power-of-two> >> alignment" for> >> the semaphore.
This would ensure that the semaphore ALWAYS fits within a> >> single page and
remove the need for cross page checks / mappings in this> >> specific case.>
>>> >> Although I will still implement a more generic map function (it's
almost> >> done anyway), in the case of semaphores this would simply mean that
no> >> semaphore will ever need to be explicitly mapped into kernel memory,> >>
fetching the page pool mapping will be enough.> >>> >> For our case the size of
sem_t is 32 or 40 bytes (depending on> >> configuration), this would be aligned
to 32 ot 64-bytes which ensures> >> that> >> the entire structure fits in a
single page. The alignment requirement> >> can> >> also be flagged behind
CONFIG_BUILD_KERNEL, as such a requirement is not> >> necessary for the flat
addressing modes.> >>> >> What do you think? Too wild, or something worth
considering /> >> acceptable ?> >>> >> Br,> >> Ville Juven / pussuw on github>
>>> >> On Mon, Apr 17, 2023 at 8:58 PM Tomek CEDRO <to...@cedro.info> wrote:>
>>> >>> if it possible to add new functionality as optional feature?> >>>> >>>
--> >>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info> >>>>
