I’m building an embedded device with QNX. The device will boot from flash, with the flash holding the IPL and filesystem.
I’ve studied the QNX documentation on building the filesystem image and it seems to make sense. Having come from a windows background, however, I am having difficulty understanding how I should organise the files in the file system, and knowing what ownership and rights to apply to files. The example x86 image that we have ‘looks’ linux-like, but having no unix/linux knowledge I am trying to locate some information or books to explain the rationale. Books on unix administration seem to explain how to manage existing systems, not describe which files you need to place where when building a small system. Books on embedding linux I have read for example explain how to strip down a system rather than build it up from scratch.
Apologies for the lengthy question - I hope I got the point across.
I’ll take the first stab at answering this and then others will likely chime in with ideas/questions of their own based on your answers.
First, I’m going to assume you read the ‘Making an OS Image’ in the helpviewer doc’s. If not, that’s definitely something you need to read and 90% of everything you need to know is in there. You should also look in /proc/boot on your QNX machine to see what’s in the default image to get an idea of what’s there (mostly drivers and shared libraries).
Second, when you say your building a device that boots from flash, just how much flash will you have (I assume you mean real flash and not a compact flash drive like a SanDisk)?
Normally you just include everything your program will need to run and nothing more. For example you need to include any shared libraries your program uses at runtime (not link time). If your not sure, you can just attempt to start your program and if there is a library missing, the program will fail to start listing the missing library and then you add that to the image. If you explain what your application is, it might help tell what files you’ll need (for example if there is no harddrive, compact flash drive (SanDisk), Cd-Rom etc you won’t need something like devb-eide in the image)
yes, I had read the ‘Making an OS Image’. I just re-read it again too.
I can’t say exactly what the device is (it’s a commercial product) but it is a device with on board flash, not external memory interfaces ( so no ide, cf-flash ) but it will have ethernet and perhaps a serial port for logging in to perform diagnostics.
I just assume that issues like mount points, having libraries in certain directories, rights on shadow password file etc follow some kind of ‘standard’.
Also, there are programs like ‘ncurses’ for example that are part of QNX but I have absolutely no idea what they do.
It’s not that I’m confused, but more a case that I am aware of my ignorance )
To add to your confusion: Yes they are standard or guidelines for directory structures and such. However QNX doesn’t enforce it. You are free to organize things the way you want them.
Selecting which file to include and which file to not include is a matter of experience, you can use the IDE and system builder to automate the process. Or you can do it manually and use a top down approach. For example you want networking that means network module io-net, then you must decide what network feature you want, tcpip, telnet, qnx etc and find which files handles what. Etc.
I don’t think there is anyplace in the doc’s that state ‘these are the standard directories/files’. As Mario said, most of it is learned through experience with QNX.
For example, most of the system configuration files are found in the /etc directory (user accounts, passwords, networking info etc). Most of the built in executables you can run from the shell like ‘ls’ are found in the /bin directory. But your not forced to put them there as Mario says (for example you could call /bin /exe and then just define your PATH environment variable to look in /exe instead of /bin).
While I understand you can’t talk much about the product, you definitely need to know what the final requirements are going to be before you’ll know what you will or won’t include. For example when you talk about logging in, if you mean with an actual shell/user account your going to have to include things like telnet, ksh (the shell), tinit (the console creator), user accounts, passwords, directories plus any executables you want the user to run like ‘ls’ for viewing files etc etc. But if you are just connecting to your application (via something like sockets) then you wouldn’t need all the above because your application will do it.
As far as permissions go on the files, if your logging in as root, it really won’t matter much since root can do anything. If your not logging in as root the easy rule of thumb is read access for anything you want the user to see/view and write access if you want them to change it.
I’ll try to cut through some of this for you. The permissions system is built to be very flexible. In most systems this flexibility is not needed, but is there anyway. In an embedded system, unless your device has some concept of different users, you need at most two levels, and maybe only one. You might have some programs whose abilities you want to limit, so you make them a user other than superuser. This causes them to inherit certain limitations. For example, they can only raise their priority so far, and cannot access hardware I/O ports. You can also limit their file access. This means you can prevent them from erasing the /bin directory, for example. Since you are writing all applications in your embedded system, this is merely a convience to help you protect yourself from yourself.
If your system is subject to hacking, for example if it has a web server, along with normal precausions, you can set up permissions to make it unlikely that a hacker could take advantage of some back door, eg. a buffer overrun. Of course you wouldn’t want to leave that back door in your program if you knew about it anyway.
As mentioned, the location of files is mostly arbitrary and by convention. It would be tricky to run a system without the passwd file in /etc, but executables can go anywhere as can data files. A subsystem like Photon will want some files in certain locations. Again, the flexibility is to help you in any way it can. A simple strategy would be to put all system files that you need where they normally live. This probably means you have /bin /lib and /etc. Then find a different place to put your application stuff. Under /home or /usr would be a typical choice. If you need to, give your application an owner, and run applications as that owner. If not, you can just run everything as root.
An important question is if your product will include graphical applications. If not, embedding is straight-forward. You only include those files you need. Which ones do you need? Go one by one - do you need a serial driver? Include it. Do you need networking? Include it. Which files you need for networking? Ha. That’s tricky. The QNX System Builder (IDE) is supposed to make things easier, but it doesn’t collect all files for you that are required for networking (io-net, devn-, npm-, and maybe more). You should look at some example build files to find out which files are needed for networking, for audio, for hard disk access (if you need it), etc. Fortunately, often it’s not more than 2-3 files. Put in your application as well and try to start it. Does it run and does it do what it should? Then you’re done. Does it fail because it’s missing a library? Then include the library. Oh, how to find out which libraries it tries to load? Try DL_DEBUG=1 yourapp - If you start yourapp this way, it will show you what it tries to load. This applies for QNX components as well!
)