Hi Sebastien, Please once again, don't start a frame war, we need people to contribute to NuttX, to make our loved project great, not to destroy it.
That said, I want to say a famous phrase from Linus Torvalds: "Doers decide!" If you want to decide how ROMFS should work, please do it. It is an open-source project after all, so you are invited to contribute, instead of starting a frame war against does who really do and really contribute to make NuttX great. About the System-V init you can use it from some projects, I heard someone using it on NuttX: https://github.com/arachsys/init/tree/master BR, Alan On 2/2/23, Sebastien Lorquet <sebast...@lorquet.fr> wrote: > Hi, > > Once again please remember this project is Apache NuttX and not Xiaomi OS. > > The fact that your company is a major contributor and that you have > established your own local usage patterns does not mean these are the > only valid ones. > > Each user has its own vision of how such a flexible system should work, > and all users count. > > So please dont suggest "bandaid" solutions to me like /etc is the only > place to mount a romfs because the init script can "do things". > > It is perfectly valid to mount three romfs each at /foo /bar and /baz at > boot and NuttX should allow it without telling me what's better. > > And I'm sorry but nsh is a demo shell and not an init system, on my own > product there is NO WAY I want to give full shell access to my customer. > > This wont happen and nsh is not even part of my production build. > > FSes can be initialized in the board's _bringup routine and I dont want > a systemd/init/shell to read scripts to mount /proc and bind a littlefs > to a directory of my choosing. And _bringup is already used to init spi > and mtd. Because NuttX is a RTOS and is meant to be more lightweight and > flexible than a generic freebsd/macos/linux OS. > > > Patch will come, I think this is a good change for nsh, but I'm a bit > busy at work at this moment, stuck in a kind of dual-PIC18 cursed hell > with hard deadlines lol. > > I also have a kind of "raid0" to aggregate two MTD with compatible > geometries into one, because reasons. It needs more tests, but it could > be useful for other users. > > Sebastien > > > On 2/2/23 19:48, Xiang Xiao wrote: >> On Fri, Feb 3, 2023 at 2:06 AM Sebastien Lorquet <sebast...@lorquet.fr> >> wrote: >> >>> No, and this was exactly my problem. >>> >>> The romfs should NOT be mounted by nsh. >>> >>> >> It's an option and disabled by default. >> BTW, which place do you think is better than the current one? >> >> >>> Mounting to /etc/ is also NOT flexible enough. >>> >>> Because in a normal board the boot app is not nsh but the customer app. >>> >>> >> You can boot other applications/services from scripts. >> >> >>> At the moment this romfs mount is also closely coupled to the boot >>> script mechanism, which is very annoying if your boot script is on a >>> flash device (eg littlefs) and not on a romfs. >>> >>> I have decoupled this, but still not provided a pull request, that was >>> in fact easy and the result is cleaner than the current way it is done. >>> >>> >> Yes, the Kconfig option makes the romfs mount couple with boot script, >> but >> it is easy to decouple them. Patch is welcome. >> >>> You cant expect customers to follow a nsh-based design. The learning >>> curve for nuttx is hard enough, and if you add more constraints in apps >>> building it is even harder. >>> >>> >> It depends on the developer's background. If the developer has >> experience with other POSIX OS(Android, Ubuntu and macOS), all is >> natural. >> >> >>> Remember that NSH and apps are just "examples" and nuttx should work >>> with completely separated apps. >>> >>> >> Of course, all we discuss so far is the user space feature, not related >> to >> the kernel. >> >> Thats why I think nsh should not be responsible for too much. >>> >> nsh equals init pus sh. One improvement is split init from nsh like other >> OS. >> >> >>> Sebastien >>> >>> >>> Le 02/02/2023 à 17:47, Xiang Xiao a écrit : >>>> The infrastructure is there, you can: >>>> >>>> 1. Enable CONFIG_NSH_ROMFSETC >>>> 2. Add your files to RCSRCS/RCRAWS in board's Makefile >>>> >>>> Then nsh will auto mount it to /etc. sim already has a demo for this: >>>> https://github.com/apache/nuttx/tree/master/boards/sim/sim/sim/src/etc >>>> >>>> >>>> On Fri, Feb 3, 2023 at 12:33 AM Russell Haley <russ.ha...@gmail.com> >>> wrote: >>>>> On Thu, Feb 2, 2023 at 6:35 AM Alan C. Assis <acas...@gmail.com> >>>>> wrote: >>>>> >>>>>> It should be nice to have a simple logic to let users to use ROMFS. >>>>>> >>>>>> Currently everyone needs to duplicate it in their own >>>>>> code/application. >>>>>> >>>>>> I'm thinking something like apps/romfiles/ where people just put the >>>>>> files that they want to be in the ROM and it will be included >>>>>> automatically, instead reinventing the wheel. >>>>>> >>>>> This is what I was hoping to find. I thought that since nuttx was >>> already >>>>> building a root filesystem there would be a simple way to include >>>>> files >>>>> with the image. >>>>> >>>>> Cheers, >>>>> Russ >>>>> >>>>>> BR, >>>>>> >>>>>> Alan >>>>>> >>>>>> On 2/2/23, Sebastien Lorquet <sebast...@lorquet.fr> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Dont use boardctl for the romfs, this is too intertwined in the >>>>>>> mechanism used to initialize nsh, which is not suitable for >>>>>> customization. >>>>>>> This need to be decoupled, I've done this in my own apps. I'll send >>>>>>> it >>>>>>> later, maybe. >>>>>>> >>>>>>> >>>>>>> Here is the proper way to mount a romfs from your board bringup() >>>>>> routines: >>>>>>> I am using stm32 as example, the ROM fs directory holding the file >>>>>>> is >>> a >>>>>>> brother to board/ >>>>>>> >>>>>>> boarddir: >>>>>>> +-- romfs >>>>>>> +-- your files... >>>>>>> +-- board >>>>>>> +-- include >>>>>>> +-- src >>>>>>> >>>>>>> You can do something else if you change the makefile below >>>>>>> >>>>>>> First change your board/src makefile to add a dependency so that >>>>>>> stm32_bringup.c depends on romfs.h >>>>>>> >>>>>>> .PHONY: myromfs.h #might not be required >>>>>>> stm32_bringup.c: myromfs.h >>>>>>> myromfs.h: >>>>>>> @echo "ROMFS" >>>>>>> @genromfs -v -f my.romfs -d $(BOARD_DIR)/../romfs >>>>>>> @xxd -i my.romfs > myromfs.h >>>>>>> >>>>>>> Then do this in stm32_bringup.c: >>>>>>> >>>>>>> #include "myromfs.h" >>>>>>> #define SECTORSIZE 64 >>>>>>> #define NSECTORS(b) (((b)+SECTORSIZE-1)/SECTORSIZE) >>>>>>> #include <nuttx/fs/fs.h> >>>>>>> #include <nuttx/drivers/ramdisk.h> >>>>>>> #include <sys/mount.h> >>>>>>> >>>>>>> and then in stm32_bringup(void): >>>>>>> >>>>>>> ret = romdisk_register(0, // /dev/ram0 >>>>>>> myromfs, //var in the xxd header >>>>>>> NSECTORS(myromfs_len), >>>>>>> SECTORSIZE); >>>>>>> >>>>>>> ret = nx_mount("/dev/ram0", "/romfs", "romfs", MS_RDONLY, >>>>>>> NULL); >>>>>>> >>>>>>> Then you will have your files mounted in /romfs at boot. >>>>>>> >>>>>>> You can do symlinks: >>>>>>> >>>>>>> ret = symlink("/romfs/etc" , "/etc"); >>>>>>> _info("Linking /etc: %d\n", ret); >>>>>>> >>>>>>> Sebastien >>>>>>> >>>>>>> Le 02/02/2023 à 05:59, Russell Haley a écrit : >>>>>>>> I am mistaken. I understood that the rom image was part of the >>>>>>>> application >>>>>>>> on flash, but had mis-read the documentation of >>>>>>>> boardctl(BOARDIOC_ROMDISK, >>>>>>>> (uintptr_t)&desc); and thought that the command loaded the image >>>>>>>> into >>>>>>>> *RAM* >>>>>>>> (the BOARDIOC_MKRD command makes the RAM disk. oops!). >>>>>>>> >>>>>>>> Incidentally, neither the romfs example nor my attempt to re-create >>> it >>>>>>>> works in my sim: >>>>>>>> >>>>>>>> osboxes@osboxes ~/n/nuttx (master)> ./nuttx >>>>>>>> >>>>>>>> NuttShell (NSH) NuttX-12.0.0 >>>>>>>> nsh> romfs >>>>>>>> ERROR: Failed to create RAM disk: Unknown error >>>>>>>> nsh> rapp >>>>>>>> Starting Russells App 1... >>>>>>>> ERROR: Failed to create RAM disk: Unknown error >>>>>>>> nsh> >>>>>>>> >>>>>>>> I don't know how to debug this "unknown error". I guess I will try >>>>>>>> to >>>>>>>> find >>>>>>>> where that error message comes from and hook in GDB? I'm terrible >>>>>>>> at >>>>>> this >>>>>>>> stuff, someone needs to revoke my compiler license (tee hee). >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Russ >>>>>>>> >>>>>>>> On Wed, Feb 1, 2023 at 7:29 PM Xiang Xiao >>>>>>>> <xiaoxiang781...@gmail.com >>>>>>>> wrote: >>>>>>>> >>>>>>>>> romfs is part of your image as the const string. There is no >>>>> difference >>>>>>>>> from the below manual step. >>>>>>>>> >>>>>>>>> On Thu, Feb 2, 2023 at 10:00 AM Russell Haley >>>>>>>>> <russ.ha...@gmail.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Tue, Jan 31, 2023 at 6:16 AM Fotis Panagiotopoulos < >>>>>>>>> f.j.pa...@gmail.com >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Indeed the "proper" way of including a script would be to store >>>>>>>>>>> it >>>>> in >>>>>>>>>>> a >>>>>>>>>>> file system. >>>>>>>>>>> >>>>>>>>>>> However, when I needed to include a single and small script and >>>>>>>>>>> I >>>>>>>>> didn't >>>>>>>>>>> want to introduce a complete FS just for this, I used xxd. >>>>>>>>>>> xxd can convert any file to a C header file. >>>>>>>>>>> >>>>>>>>>>> You can then include the header, and access the whole file as a >>>>>>>>> variable. >>>>>>>>>>> Here is an example: >>>>>>>>>>> >>>>>>>>>>> I added this in my app Makefile: >>>>>>>>>>> >>>>>>>>>>> # Setup any special pre-build context >>>>>>>>>>> context: header >>>>>>>>>>> $(Q) cd path/to/libs/json.lua/ && xxd -i json.lua > >>>>>>>>>>> json_lua.h >>>>>>>>> && >>>>>>>>>>> echo -n "const " | cat - json_lua.h > temp && mv temp json_lua.h >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> And then I used the file like this: >>>>>>>>>>> >>>>>>>>>>> #include "lua.h"#include "lauxlib.h"#include <string.h> >>>>>>>>>>> #include "json_lua.h" >>>>>>>>>>> static int luaopen_json(lua_State * L); >>>>>>>>>>> >>>>>>>>>>> void ExtLibs_load(lua_State * L){ >>>>>>>>>>> // json.lua#ifdef CONFIG_EXT_LIB_JSON_LUA >>>>>>>>>>> luaL_requiref(L, "json", luaopen_json, 1); >>>>>>>>>>> lua_pop(L, 1);#endif} >>>>>>>>>>> >>>>>>>>>>> int luaopen_json(lua_State * L){ >>>>>>>>>>> const char * modname = lua_tostring(L, 1); >>>>>>>>>>> >>>>>>>>>>> if (strcmp(modname, "json") != 0) >>>>>>>>>>> return luaL_error(L, "cannot load json >>>>>>>>>>> module"); >>>>>>>>>>> >>>>>>>>>>> if (luaL_loadbufferx(L, (char*)json_lua, >>>>>>>>>>> json_lua_len, >>>>>>>>>>> "json", >>>>>>>>>>> "t") != LUA_OK) >>>>>>>>>>> return lua_error(L); >>>>>>>>>>> >>>>>>>>>>> lua_call(L, 0, 1); >>>>>>>>>>> >>>>>>>>>>> return 1;} >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I hope this helps... >>>>>>>>>>> >>>>>>>>>> That is very helpful, and not just for nuttx development! Thanks >>> for >>>>>>>>>> the >>>>>>>>>> tip. >>>>>>>>>> >>>>>>>>>> The romfs example actually uses xxd as well to convert the >>>>> filesystem >>>>>>>>> into >>>>>>>>>> hex code that is also stored in a header file. If I am reading >>>>>>>>>> the >>>>>> code >>>>>>>>>> correctly, the example app loads the entire filesystem into >>>>>>>>>> memory, >>>>>>>>>> which >>>>>>>>>> isn't very efficient and not at all what I wanted. Can someone >>>>>>>>>> tell >>>>> me >>>>>>>>>> if >>>>>>>>>> that's true? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Russ >>>>>>>>>> >>>>>>>>>>> On Sun, Jan 29, 2023 at 7:34 AM Xiang Xiao < >>>>>> xiaoxiang781...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> You can use the real file system on the device, there are many >>>>>>>>> choices: >>>>>>>>>>>> romfs, littlefs, fatfs, starmtfs and spiffs. >>>>>>>>>>>> >>>>>>>>>>>> On Sun, Jan 29, 2023 at 12:59 PM Russell Haley < >>>>>> russ.ha...@gmail.com >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Jan 28, 2023 at 7:35 PM Xiang Xiao < >>>>>>>>>> xiaoxiang781...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> You can enable CONFIG_FS_HOSTFS/CONFIG_SIM_HOSTFS, put your >>>>>>>>> scripts >>>>>>>>>>>> into >>>>>>>>>>>>>> some PC folder and run mount this folder from nsh: >>>>>>>>>>>>>> mount -t hostfs -o fs=/path/to/your/pc/folder. /data >>>>>>>>>>>>>> >>>>>>>>>>>>>> While I appreciate the answer, I am using the sim as a >>>>>>>>>>>>>> testing >>>>>>>>>>> platform >>>>>>>>>>>>> and hoping to move to either an STM32F4/7 or a Sony Spresense. >>>>>>>>>>>>> I >>>>> am >>>>>>>>>>>> hoping >>>>>>>>>>>>> for a solution that is applicable to an embedded project. If I >>>>>>>>> can't >>>>>>>>>>> just >>>>>>>>>>>>> add files to the initial image then I will look at the romfs >>>>>>>>> example >>>>>>>>>>> and >>>>>>>>>>>>> maybe the next best thing? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sun, Jan 29, 2023 at 2:24 AM Russell Haley < >>>>>>>>>> russ.ha...@gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Big thanks to Xiang Xiao for pointing me to the sim:lua >>>>>>>>>>>> configuration. >>>>>>>>>>>>> I >>>>>>>>>>>>>>> was unable to simply include the defconfig file that you >>> linked >>>>>>>>>> to, >>>>>>>>>>>>> but I >>>>>>>>>>>>>>> was able to reconfigure for the sim:lua configuration. I've >>>>>>>>> now >>>>>>>>>>> got >>>>>>>>>>>> an >>>>>>>>>>>>>> app >>>>>>>>>>>>>>> in the examples folder that includes the Lua interpreter. Is >>>>>>>>>> there >>>>>>>>>>> a >>>>>>>>>>>>>>> tutorial on how to include folders and lua scripts or extra >>>>>>>>> files >>>>>>>>>>> in >>>>>>>>>>>>> the >>>>>>>>>>>>>>> initial file system? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Much appreciated, >>>>>>>>>>>>>>> Russ >>>>>>>>>>>>>>> >
