What vendor settings should I apply to cc_tests? (vendor or system?)
I noticed one of my cc_tests relied on libgcov which is only available on the system, which suggests to me that maybe tests are a system only thing. If my poor understanding of what cc_test does I'm also confused about what it even means to apply vendor settings to a cc_test.
In any case, I have many modules that are vendor: true, some of them are libs that the cc_tests rely on. Should my cc_tests also be on vendor? Or should any module that needs to be accessed by a cc_test by marked vendor_available and keep my cc_test on system?
Related
From my research I cannot find what kernel type is being used in eCos, such as monolithic or micro-kernel. All I could find from my research is that the kernel is a real-time one or websites just describe it as the eCos kernel, does this mean it is a custom made kernel?
What I know about eCos is that it is a hard RTOS although is somewhat vulnerable in terms of security, uses priority, queue based scheduling.
A micro-kernel is:
... the near-minimum amount of software that can provide the mechanisms
needed to implement an operating system (OS). These mechanisms include
low-level address space management, thread management, and
inter-process communication (IPC).
(Wikipedia 11 Dec 2018)
The eCos kernel is described in its Reference Manual thus:
It provides the core functionality needed for developing
multi-threaded applications:
The ability to create new threads in the system, either during startup
or when the system is already running.
Control over the various threads in the system, for example
manipulating their priorities.
A choice of schedulers, determining which thread should currently be
running.
A range of synchronization primitives, allowing threads to interact
and share data safely.
Integration with the system's support for interrupts and exceptions.
It is quite clearly by comparison of these descriptions a micro-kernel. Other services provided by eCos such as file-systems, networking and device drivers are external and separable from the kernel. That is to say, you can deploy the kernel alone without such services and it remains viable.
In a monolithic kernel, these services are difficult or impossible to separate as they are an intrinsic part of the whole. Unlike eCos mand most other RTOS they do not scale well to small hardware platforms common in embedded systems. Monolithic kernels are suited to desktop and general purpose computing platforms, because the platforms themselves are monolithinc - a PC without a filesystem, display, keyboard etc, is not really viable, whereas in an embedded system that is not the case.
While Linux, and even Windows are used in embedded systems, a micro-kernel is deployable on platforms with a few tens of kilo-bytes of memory, whereas a minimal embedded Linux for example requires several mega-bytes and will include a great deal of code that your application may never use.
Ultimately the distinction is perhaps irrelevant, as is the terminology. It is what it is. You do not choose your kernel or OS on this criteria, but rather whether it provides the services you require, runs on your target, and fits in the available resource.
I think it is a monolithic kernel. If you review this page: http://ecos.sourceware.org/getstart.html
It is used instead of linux kernel and linux kernel support monolithic kernels. In addition, if it was a micro kernel , they would highlight the kernel type like QNX Kernel type which is micro kernel
I need to know Does a operating system design for specific processors category?
and also can any operating system run on any microprocessor?
Generally speaking, an operating system is not designed for a specific processor; though some do make assumptions about the hardware and computer system over all that might not be available in all systems. That said, for an operating system to run on a partical architecture, there is usually code that performs some specific, critical functions that is implemented for a specific architecture, frequently being written in assembly (I know of no OS that doesn't do this). To enable a new architecture, this code needs to be rewritten for the new machine, so that means new assembly most of the time. As mentioned in the comments, there are operating systems that only run on a single architecture like Windows, while others have these specific components for a number of architectures and thus can run on a number of processors like Linux. Note however the same exactly binary will not run across architectures, the operating system needs to be rebuilt for each architecture and possibly even for the same architecture if the system itself is different enough (as can be the case with some small MCUs).
So to answer your two questions directly: no, an OS is not uaually designed for a specific processor, and no, any OS cannot run on any processor.
Historically, operating systems have been designed for specific hardware. In some cases, such as eunuchs, the system was reworked so that it could be ported to multiple systems.
M$ ported Windoze to the Alpha processor in order to placate Digital and avoid lawsuits.
[C]an any operating system run on any microprocessor?
No.
I am interested in writing a Vala program that will determine the present operating system and act accordingly (exactly how it will act I have not decided yet, but is not relevant to this question). So what I would like to know is how I might determine the present operating system (including the specific distribution in the case of Linux) in a Vala program at runtime.
Unless you are writing system level code (like package manager or OS configuration code), you shouldn't. A much better alternative is to use a library that already abstracts the distribution specifics for you.
If you absolutely have to there are two main ways to do it:
At build time
Here your build system should be responsible to detect the OS / distribution and either pass a define to the compiler (like -DDISTRO_UBUNTU) or write a config.vala file (possibly from a template config.vala.in with replacements, e.g. autotools has the AC_CONFIG_FILES facility to do this).
At runtime
Here your tool does the detection itself when it's running.
Which fits your application better is a design choice.
As to how to do it there are several things you can check:
uname -a (or other parameters, see man uname) will give you the kernel that is currently running.
lsb_release -a (not available on every distro, sometimes an optional package which you might have a package dependency to) will give you information on what distro and what distro version you are running on.
On Debian/Ubuntu derivates there is a file called /etc/debian_version which gives an indication of what release is currently installed. That information is not totally accurate though.
Some people are trying to read /etc/issue, but that is dangerous, since that file could be modified by the admin / the user.
You could ask the user which OS she is running.
There are also some os info libraries that you could use.
You might use the uname(2) syscall (how to do that in Vala is left as an exercise to the user), or read /proc/version (see proc(5)), or read /etc/issues or follow Linux Standard Base conventions (e.g.popen the output of lsb_release -a).
But as Jens Mühlenhoff answered, you should not do that, and avoid writing code depending on some particular distribution.
And some users might want to fake or hide that information (think of someone having some "Linux From Scratch" system).
I want to clarify before the question that I am not an established professional programmer in any position at any firm. This is solely to satisfy curiosity, and will not pertain to any task or project at this time.
As I understand it, firmware is software placed on hardware to grant it autonomous functionality from instructions, which is given through some form of input; As long as the input stream is readable, which is made possible through drivers. Drivers are software packages with pre-written reference libraries that recognize a specific set of instructions for each possible function in the attached device.
NOTE: not quoted, so I'm aware that this could be inaccurate.
What I want to know is how firmware or drivers are placed on devices without installation through an OS or storage medium; such as a DVD or USB? Specifically firmware installed by manufacturers, like bios and keyboard drivers that are present on all computers. I'm assuming these are less or not reliant on compilation in order to function properly, which is the sole reason I'm asking this question.
Can firmware be developed without compilation?
References
Demystifying Firmware
C++ Kernel Development
Starting Firmware Development
These just explain that an OS is a type of firmware, and that firmware is primarily developed in C with Assembly and C++ as plausible alternatives; pertaining to kernel development as well.
Yes, especially in the larger components. An example involving lua is http://nodelua.org/doc/index/
However, firmware development is typically an extremely memory (and frequently CPU) constrained environment.
C (or traditionally, assembler) is often preferred because it can produce extremely small executables, and is very efficient in stack usage. This matters when you're counting memory in bytes, or kilobytes.
Using a non-compiled language means you need to include a tiny interpreter, and you might not be able to set aside enough memory for this.
You've made an edit, wherein you suggest that an "OS is a type of firmware".
This can be true, in a manner of speaking.
Often firmware itself can consist of an operating system, with components. As an example, the firmware in some home internet routers will contain an OS (which might very well be linux!), however it is still regarded as firmware. There is a bit of a grey area between a computer that is an "embedded device with firmware", vs that of a 'regular computer with regular software', but generally firmware is a computer system running in a very constrained environment, often with very specific uses.
NetBSD includes Lua in it's kernel. Many systems have been developed that do not use Assembly (except for a small part of it), C, or C++, but instead use some other language - though it is typically still compiled for size and performance reasons.
As for the actual transfer of firmware (whatever the form it may be in), this depends on the device in question.
Some devices require that the firmware be burned into the components. (In ROM, though there are various types of ROM and some can be rewritten).
Other devices require that the firmware be transferred when the device is turned on.
And yet others have SDCards or battery-backed RAM or whatever that allow storing the firmware across reboots.
we start to write plug in for eclipse to work with some java frame work like hadoop (we want to edit hadoop eclipse plug in and merge it with other. our plug in must work in Linux operating system. Generally writing plug in for eclipse depend on operating system or not? if depend what benefits to write it for Linux?
Well, the previous answer is correct... in most cases. You should specifically check all the interfaces with the operating system.
SWT is a Java wrapper over native OS widgets. It behaves almost the same on all OSs, but not exactly. There are subtleties. For example, events that might be fired a bit differently, drawing of widgets, etc. My experience shows that you have to check on all OSs to be sure that it works as it should, especially if you are doing more complex UI rendering. In many cases I had to do some fine tuning to get it right. It is not a great deal of effort, but it should be considered.
Another issue is working with the file system. For example, make sure you are composing files paths correctly. It is always a good idea to test that part as well.
Eclipse plugins are platform independent (you are writing them in Java), unless your plugin requires some low-level calls to the operating system (i.e. JNI) or to invoke some tool found only in the Linux OS.
The only part of Eclipse tied - in part - to the OS is the SWT toolkit, since it's optimized for the graphic environment you are running it, but if Eclipse can run in the OS you are interested in, you should not be bothered by this.