+1 from here as well. POSIX compliance should take precedence over everything
else including introduction of regressions.
-Ville
From: Tomek CEDRO
Sent: Tuesday, April 29, 2025 2:38 PM
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Change setlogmask behavior to PO
t, BETTER.
11-16: +1
17: +1 and if this ever happens it should be severely punished.
-Ville Juven
From: Tomek CEDRO
Sent: Tuesday, February 11, 2025 1:37 AM
To: dev@nuttx.apache.org
Subject: [VOTE] NuttX Contributing Guidelines update 202502.
Hello world :-)
As d
red by the
process and all its threads.
-Ville
From: Gregory Nutt
Sent: Tuesday, November 5, 2024 3:35 PM
To: dev@nuttx.apache.org
Subject: Re: POSIX environ variable
On 11/5/2024 6:57 AM, Ville Juven wrote:
> For direct user level access, one option
For direct user level access, one option is to move tg_envp to TLS /
task_info_s. This way the user could access the memory without boring a hole
into the kernel.
In KERNEL mode this issue is very simple; every process has its own instance of
environ** anyway so there is no need to use TLS or a
Issue seen with rv-virt:knsh64 as well. After first ostest run the memory usage
rises by ~500 bytes, but the consequent runs do not increase it further.
Something is allocated once from kheap that is never freed again.
nsh> free
total used freemaxusedmaxfree
Hi,
If help with code review is still needed, I'd like to volunteer for that work.
I can help with changes that touch arm64, risc-v and especially the memory
protected modes (CONFIG_BUILD_KERNEL) / address environments.
You might know me as pussuw on Github.
Br,
Ville
issue, any and all is greatly
appreciated.
Br,
Ville Juven
well if you wish.
Br,
Ville Juven
On Wed, Oct 25, 2023 at 5:55 PM Gregory Nutt wrote:
> On 10/25/2023 8:48 AM, Gregory Nutt wrote:
> > On 10/25/2023 8:18 AM, Alan C. Assis wrote:
> >> On 10/25/23, Nathan Hartman wrote:
> >>> On Wed, Oct 25, 2023 at 5:16 AM Ville
sched_lock())?
My reason for removing the scheduler lock is obviously that I lose all
real-time assurances of the OS when I'm starting a process, e.g. I start
losing sensor data during the process load time.
Any and all help on this is greatly appreciated.
BR,
Ville Juven / pussuw on github
do a full context
save in up_cpu_paused ? Meaning integer + FPU registers both ? Now it only
saves the integer registers which I think is the issue here.
Any insight on this is greatly appreciated!
Br,
Ville Juven
t this solution is workable I think.
Br,
Ville
On 27.4.2023 12.28, Xiang Xiao wrote:
Yes, this is what I said before. You don't need to validate the stack
allocated list since it comes from the kernel stack which can't be modified
or even read by the userspace code.
On Thu, Apr 27, 20
uld not work.
Am I missing something?
On 4/26/2023 2:14 PM, Ville Juven wrote:
Hi,
But, why need involve kheap here? If the security is your concern, you
should enable per-thread kernel stack in the first place. It's safe to
allocate waitlist/holder from this stack directly, since use
ly also modifies
the semaphore counter value, so it needs access to the userspace counter.
This I will do by mapping the page where the counter exists to kernel
(implement something like kmap() / vmap()).
If you have an alternative suggestion on how to fix sem_waitirq() I will
gladly implement it.
Br
unsafe to do that. Spoofing the id can cause the user
process to crash, but the kernel integrity remains.
Br,
Ville Juven
On Wed, Apr 26, 2023 at 9:09 PM Xiang Xiao
wrote:
> But why not allocate list entry and holder temporally inside the kernel
> thread stack? Both data is just used wh
Hi,
Thanks for the explanation, it makes sense. I had an idea to move struct
sem_s entirely to kernel and make the user use it via a handle (in KERNEL
build) but due to the ubiquitous init macros, that is not a feasible
solution.
I will explore allocating the kernel structures on-demand next.
Wh
e the one to remove this
legacy, as the risk is too great.
I'll figure out something else for my specific problem, with a smaller
chance for regression to working targets.
Br,
Ville Juven
On Wed, Apr 26, 2023 at 6:23 PM Gregory Nutt wrote:
> On 4/26/2023 4:10 AM, Ville JUven wrote:
t and
pthread_cond_t. Trying to get rid of the initializer macro proves to be
too much re-factoring of code I'm not very familiar with (big risk
something will break) -> I'll try to figure out something else.
Br,
Ville Juven
On 26.4.2023 12.53, Petro Karashchenko wrote:
Hi,
Some time
it and
I can wrap around the issue keeping any existing code functional/intact.
I just think it is a bit odd and confusing to have such non-standard
quirks in the otherwise well defined user API.
BR,
Ville Juven / pussuw
To clarify, I am _not_ proposing we remove NXSEM_INITIALIZER
ow to fix this ?
Br,
Ville Juven / pussuw
(the process can be killed for being naughty but the kernel
survives). But in those two exception cases, the kernel needs access to the
semaphore.
Br,
Ville Juven
On Wed, Apr 19, 2023 at 5:42 PM Ville Juven wrote:
> Hi, thanks again for the responses and bearing with me
>
> > I beli
d that the lists are not accessible by the kernel unless the
correct process is running, which means the correct user mappings are
active and the user memory is visible to the kernel.
Br,
Ville Juven
On Wed, Apr 19, 2023 at 4:53 PM Gregory Nutt wrote:
>
> >> However, as I said, the
is a perfectly valid
point. Now the dq waitlist and the semaphore holder list are in user
memory, which means the user process can mess those lists up, crashing the
kernel.
Br,
Ville Juven
PS. Whatever solution is implemented shall in no way increase code size or
modify functionality in the flat ad
Hi,
Sorry for the spamfest. Forget what I said about the alignment being a
solution. It is not. Any object allocated from heap that contains a sem_t
structure cannot guarantee that the alignment of sem_t is correct.
So I was just being dumb..
Br,
Ville Juven
On Tue, Apr 18, 2023 at 11:39 AM
s 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 wrote:
> if it possible to add new functionality as optional feature?
>
> --
say, the COPY data, not refer to
it) for that will just simply destroy the scheduling performance.
I also thought that mqueue:s would need a similar fix but I think I'm wrong
on that one, the mqueue memory is kernel memory and the user accesses it
via a file descriptor handle only.
Br,
Ville
which
means that whatever is inside '' is just a string litral. Or do you mean
that the variable expansion support is already there ?
Does posix say something about shells?
>
Yes POSIX demands that the aliases are stored per session only.
BR, Ville Juven
>
On Thu, Mar 9, 2023 at 12:35
ares the
same aliases, is this seen as a problem or should I make the aliases stick
to a shell session only ?
This is my first time posting on this board, so apologies if I did
something improper.
Br, Ville Juven
27 matches
Mail list logo
