Re: Right way to start a lightweight kernel thread without copying open file descriptors?
Hello Xiang, you wrote: > Michael, could you try it? Sorry for the delayed response. I was away from my computer for some time. I realized that the fix already went upstream. I tested the current tip of the master branch and the fix works fine for me. Thanks a lot for your help, Michael Am So., 30. Jan. 2022 um 19:21 Uhr schrieb Xiang Xiao < xiaoxiang781...@gmail.com>: > It's better to let kernel thread skip the duplication of caller's file > handler, here is the patch: > https://github.com/apache/incubator-nuttx/pull/5379 > Michael, could you try it? > > > On Mon, Jan 31, 2022 at 12:59 AM Michael Jung wrote: > > > Hi Xiang, Hi Matthew, > > > > Thanks for your responses. > > > > Matthew wrote: > > > Creating a kernel thread in an ioctl "lower-half" would probably cause > > the file descriptors from the calling task to get copied. > > > > Yes, that is exactly what is happening. The started kernel thread > actively > > polls for an event to happen and terminates afterwards, calling close on > > all the copied file descriptors (which includes the one the ioctl was > > called on). Currently I made my device driver more robust via reference > > counting, but I tend to agree with the referenced issues that kernel > > threads should not maintain file descriptors. > > > > Thanks! > > Michael > > > > Am Fr., 28. Jan. 2022 um 23:38 Uhr schrieb Matthew Trescott < > > matthewtresc...@gmail.com>: > > > > > On Fri, Jan 28, 2022 at 7:43 PM Michael Jung wrote: > > > > specific ioctl command implementation > > > > > > Creating a kernel thread in an ioctl "lower-half" would probably cause > > > the file descriptors from the calling task to get copied. Might this > > > be another case of > > > https://github.com/apache/incubator-nuttx/issues/1108 and > > > https://github.com/apache/incubator-nuttx/issues/2663 ? > > > > > >
Re: RNDIS and DHCPD
Hi Greg, On 1/25/22, Gregory Nutt wrote: >> Good question! Normally the computer/host is supposed to run the DHCP >> server, you need to check in the spec if there is some way to change >> it. >> > > I wrote a DHCP server a long time ago. It is at apps/netutils/dhcpd. > Haven't used it in a long time so I would expecit it to have some bit rot. > I think the DHCP server is working, see this tutorial: https://eadalabs.com/esp32-nuttx-and-bridged-networking/
Re: Right way to start a lightweight kernel thread without copying open file descriptors?
It seems to me that it is a security issue to permit an application to start kernel threads, albeit indirectly. Has anyone thought about this? Any user could bring the most protected system to its knees by causing many kernel threads to be generated. On Sun, Jan 30, 2022 at 12:21 PM Xiang Xiao wrote: > It's better to let kernel thread skip the duplication of caller's file > handler, here is the patch: > https://github.com/apache/incubator-nuttx/pull/5379 > Michael, could you try it? > > > On Mon, Jan 31, 2022 at 12:59 AM Michael Jung wrote: > > > Hi Xiang, Hi Matthew, > > > > Thanks for your responses. > > > > Matthew wrote: > > > Creating a kernel thread in an ioctl "lower-half" would probably cause > > the file descriptors from the calling task to get copied. > > > > Yes, that is exactly what is happening. The started kernel thread > actively > > polls for an event to happen and terminates afterwards, calling close on > > all the copied file descriptors (which includes the one the ioctl was > > called on). Currently I made my device driver more robust via reference > > counting, but I tend to agree with the referenced issues that kernel > > threads should not maintain file descriptors. > > > > Thanks! > > Michael > > > > Am Fr., 28. Jan. 2022 um 23:38 Uhr schrieb Matthew Trescott < > > matthewtresc...@gmail.com>: > > > > > On Fri, Jan 28, 2022 at 7:43 PM Michael Jung wrote: > > > > specific ioctl command implementation > > > > > > Creating a kernel thread in an ioctl "lower-half" would probably cause > > > the file descriptors from the calling task to get copied. Might this > > > be another case of > > > https://github.com/apache/incubator-nuttx/issues/1108 and > > > https://github.com/apache/incubator-nuttx/issues/2663 ? > > > > > >
enable the excute of install_tools in cibuild.sh
Hi team's
I'm try to add sparc to the daily ci,I add code to tools/ci/cibuild.sh
and tools/ci/testlist/other.dat,but when i start pull
requests,there's ci check error,beacuse "install_tools" function was not
executed,what resulte the build of xx3803:nsh can't find
sparc-gaisler-elf-gcc,to solve this problem,i change ./cibuild.sh -A -c
testlist/${{matrix.boards}}.dat to ./cibuild.sh -A -c -i
testlist/${{matrix.boards}}.dat in build.yml, but the excute of
function install_tools {
pushd .
for func in ${install}; do
${func}
done
popd
echo PATH="${EXTRA_PATH}"/"${PATH}" > "${prebuilt}"/env.sh
}
has other error when install kconfig-frontends
https://github.com/apache/incubator-nuttx/runs/5032993342?check_suite_focus=true
how solve this problem?
Best regards,
Zou
Re: Build Nuttx on MAC / ARM64 Ubuntu
Hi Flavio, let me share my latest findings. I’m down to setjmp/longjmp, which needs to be adapted to AARCH64. A preliminary version is available, but not fully working, yet. I can share my code, if you want to dig into that, too. /Piet > Am 31.01.2022 um 11:10 schrieb Flavio Castro Alves Filho > : > > Hi Peter, > > Yes, I intend to use it for simulation only. > > It is for a personal project. I already have a Ubuntu based desktop > machine, which works fine. But for mobility, if I could work on my MAC, it > would be better. > > I will try to figure out what is going on. > > Thank you for all your help. > > Best regards, > > Flavio > > > Em dom., 30 de jan. de 2022 10:28, Kalbus, Peter > escreveu: > >> Hi, >> >> are you only interested in the simulation or also have a real target in >> mind? >> >> Maybe you can try to get it working for your real target instead of the >> simulation. The simulation is definitely not working overall on M1 based >> host systems yet. >> >> I‘m using RP2040 based targets and they are working using my M1 based host >> system. >> >> /Piet >> >> >>> Am 30.01.2022 um 13:22 schrieb Flavio de Castro Alves Filho < >> flavio.al...@gmail.com>: >>> >>> That’s what I did. >>> >>> So it is not the problem. >>> On 29 Jan 2022, at 19:43, Peter Kalbus >> wrote: Hi Flavio, there’s an explanation in NuttX documentation: >> https://nuttx.apache.org/docs/latest/quickstart/install.html#kconfig-frontend >> < >> https://nuttx.apache.org/docs/latest/quickstart/install.html#kconfig-frontend >>> Check for the „MacOS, Ubuntu 18.04 LTS and earlier“ tab. It’s a couple of months back, as I did this … but I’m quite sure, that >> I followed that explanation. /Piet >> Am 29.01.2022 um 23:17 schrieb Flavio de Castro Alves Filho < >> flavio.al...@gmail.com>: > > Hi Peter, > > How did you install kconfig-frontends on your machine? > > Best regards, > > Flavio > >> On 29 Jan 2022, at 18:13, Kalbus, Peter >> wrote: >> >> Hi, >> >> I know, it‘s not complete. But you should get a different error … I >> see, ARM based CPU is now detected … next step will take longer. >> >> /Piet >> >>> Am 29.01.2022 um 22:03 schrieb Flavio de Castro Alves Filho < >> flavio.al...@gmail.com>: >>> >>> Hello Guys. Thank you for your fast response. >>> >>> @Alan, indeed it is an ARM-based Mac. >>> >>> @Peter, I added your patch in my NuttX project and ran again the >> configuration, but without success yet :-( >>> >>> Here is the output >>> >>> flavio@Flavios-MacBook-Pro nuttx % tools/configure.sh -m sim:nsh >>> Copy files >>> Select CONFIG_HOST_MACOS=y >>> Select CONFIG_HOST_ARM=y >>> Refreshing... >>> make[2]: Nothing to be done for `clean_context'. >>> CP: arch/dummy/Kconfig to >> /Users/flavio/mestrado/nuttx/nuttx/arch/dummy/dummy_kconfig >>> CP: boards/dummy/Kconfig to >> /Users/flavio/mestrado/nuttx/nuttx/boards/dummy/dummy_kconfig >>> LN: platform/board to >> /Users/flavio/mestrado/nuttx/apps/platform/dummy >>> LN: include/arch to arch/sim/include >>> LN: include/arch/board to >> /Users/flavio/mestrado/nuttx/nuttx/boards/sim/sim/sim/include >>> LN: drivers/platform to >> /Users/flavio/mestrado/nuttx/nuttx/drivers/dummy >>> LN: include/arch/chip to >> /Users/flavio/mestrado/nuttx/nuttx/arch/sim/include/sim >>> /Users/flavio/mestrado/nuttx/nuttx/tools/link.sh >> /Users/flavio/mestrado/nuttx/nuttx/arch/sim/include/sim include/arch/chip >>> LN: arch/sim/src/chip to >> /Users/flavio/mestrado/nuttx/nuttx/arch/sim/src/sim >>> LN: arch/sim/src/board to >> /Users/flavio/mestrado/nuttx/nuttx/boards/sim/sim/sim/src >>> touch .dirlinks >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/boot >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/canutils >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/crypto >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/examples >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/fsutils >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/gpsutils >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/graphics >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/industry >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/interpreters >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/math >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/mlearning >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/netutils >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/system/libuv >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/system >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/testing >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/wireless/bluetooth >>> mkkconfig in /Users/flavio/mestrado/nuttx/apps/wireless/ieee802154 >>> mkkconfig in /Users/flavio/mes
