Forums

Embedded RTOS - features poll

Started by Stargazer September 19, 2010
Greetings,

I am writing my own RTOS, which I intend to use in my projects and
license for anyone who would like to use it. At first I will use it in
my own projects, so that it achieves a certain level of real-life
performance and stability, then release it.

The idea is to employ a "classic" embedded RTOS design (single address
space, multiple tasks, "hard" RT scheduling) with as much common
interfaces as possible (POSIX I/O, sockets, pthreads, standard C
library), with small storage and RAM footprint, with much higher
responsiveness than most of OS commonly used and without a need in
MMU. There's no need in a filesystem, everything runs from a single
binary. Most of the components are optional, it's easy even to use the
OS without a task manager as one big loop but with h/w, memory
management and filesystems support, for example.

I intend to use it in projects that would otherwise use embedded
Linux, but need better performance / responsiveness / free resources,
without increase in platform's cost. I experienced and witnessed many
problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding
software quality, support and unnecessary amount of proprietary
interfaces where industry-standard interfaces exist. I believe that
those problems with dedicated RTOSes led to embedded Linux taking over
areas for which Linux wasn't even intended, and I hope to offer
similar (to Linux'es) advantages over them.

For now I want to give a shape to my offer and strengthen the most
popular use cases for the OS. I don't have resources to make it
"relatively good for anything" like Linux, and I don't want to take
this direction in order to not complicate interfaces and development
procedures.

Now I'd like to ask everybody who is willing to express his/her
opinion (as applicable):

- What features, supported architectures/platforms/hardware support,
interfaces and available frameworks would make you use a new OS (if
you already use an RTOS)?

- Why wouldn't you use a new OS (if you don't like the whole idea or
you're satisfied with the existing offer, etc.)?

- What will make you use an OS (if you currently don't use an OS at
all)?

Please write what platform(s) your answer relates to and what is the
project's field (even in general terms, e.g. "low-end media gateway",
"network filtering appliance", "high-end router", "surveillance DVR",
"IP camera" etc.)

Thanks,
Daniel


On 19/09/2010 16:31, Stargazer wrote:
> Greetings, >=20 > I am writing my own RTOS, which I intend to use in my projects and > license for anyone who would like to use it. At first I will use it in > my own projects, so that it achieves a certain level of real-life > performance and stability, then release it. >=20 > The idea is to employ a "classic" embedded RTOS design (single address > space, multiple tasks, "hard" RT scheduling) with as much common > interfaces as possible (POSIX I/O, sockets, pthreads, standard C > library), with small storage and RAM footprint, with much higher > responsiveness than most of OS commonly used and without a need in > MMU. There's no need in a filesystem, everything runs from a single > binary. Most of the components are optional, it's easy even to use the > OS without a task manager as one big loop but with h/w, memory > management and filesystems support, for example. >=20 > I intend to use it in projects that would otherwise use embedded > Linux, but need better performance / responsiveness / free resources, > without increase in platform's cost. I experienced and witnessed many > problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding > software quality, support and unnecessary amount of proprietary > interfaces where industry-standard interfaces exist. I believe that > those problems with dedicated RTOSes led to embedded Linux taking over > areas for which Linux wasn't even intended, and I hope to offer > similar (to Linux'es) advantages over them. >=20 > For now I want to give a shape to my offer and strengthen the most > popular use cases for the OS. I don't have resources to make it > "relatively good for anything" like Linux, and I don't want to take > this direction in order to not complicate interfaces and development > procedures. >=20 > Now I'd like to ask everybody who is willing to express his/her > opinion (as applicable): >=20 > - What features, supported architectures/platforms/hardware support, > interfaces and available frameworks would make you use a new OS (if > you already use an RTOS)? >=20 > - Why wouldn't you use a new OS (if you don't like the whole idea or > you're satisfied with the existing offer, etc.)? >=20 > - What will make you use an OS (if you currently don't use an OS at > all)? >=20 > Please write what platform(s) your answer relates to and what is the > project's field (even in general terms, e.g. "low-end media gateway", > "network filtering appliance", "high-end router", "surveillance DVR", > "IP camera" etc.) >=20 > Thanks, > Daniel >=20 >=20
Just what the world needs - another RTOS. Line up. Regards, Richard. + http://www.FreeRTOS.org Designed for Microcontrollers. More than 7000 downloads per month. + http://www.SafeRTOS.com Certified by T=DCV as meeting the requirements for safety related systems= =2E --=20 Regards, Richard. + http://www.FreeRTOS.org Designed for Microcontrollers. More than 7000 downloads per month. + http://www.SafeRTOS.com Certified by T=DCV as meeting the requirements for safety related systems= =2E
Stargazer wrote:

> Greetings, > > I am writing my own RTOS, which I intend to use in my projects and > license for anyone who would like to use it. At first I will use it in > my own projects, so that it achieves a certain level of real-life > performance and stability, then release it.
The question you should ask is:- "Do you really need an RTOS for the application?". It can often be surprising to list the feature set you need and see how you can do that easily without the RTOS. However, when you need an RTOS you need to have a really good one. As one who uses Forth for quite a number of things, I have never felt the need to think of needing an RTOS. If I am dealing with an application that is so complex that it needs an RTOS then I am usually into the realms of commercial PLC's which already come with one. -- ******************************************************************** Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Hi Daniel,

[comments interspersed with no real intent at a cogent argument]

Stargazer wrote:

> I am writing my own RTOS, which I intend to use in my projects and > license for anyone who would like to use it. At first I will use it in > my own projects, so that it achieves a certain level of real-life > performance and stability, then release it.
If you've not written an RTOS before, I would suggest you add a step *before* "public release" (I would actually suggest you add it before you finish any of *your* projects, as well!): namely, "lather, rinse, repeat". You'll find many of the classic features offered in MTOS's and RTOS's are, in practice, redundant and/or superfluous. Once you've *used* them, you will be able to recognize which fit this mold and how you can trim down a "bullet point feature list to a true *core* of useful features -- though you might have to look at things in a different way to see the duality hidden there. Then, revise your platform to more effectively use a smaller set of features (IMO, this has led to more robust and responsive implementations)
> The idea is to employ a "classic" embedded RTOS design (single address > space, multiple tasks, "hard" RT scheduling) with as much common > interfaces as possible (POSIX I/O, sockets, pthreads, standard C > library), with small storage and RAM footprint, with much higher
It looks like you are already following the "kitchen sink" approach. Where is your priority: footprint (TEXT/DATA) or features?
> responsiveness than most of OS commonly used and without a need in > MMU. There's no need in a filesystem, everything runs from a single
Note that "filesystem" need not carry the bloat of a *disk* (or "memory") filesystem. E.g., I like using fwrite, fread, etc. in my "tasks" (lets not argue terminology) with the sort of interface one typically thinks of with a namespace residing atop a filesystem.
> binary. Most of the components are optional, it's easy even to use the > OS without a task manager as one big loop but with h/w, memory > management and filesystems support, for example.
Wait -- first *no* filesystem ("no need in a filesystem") now there *is* one ("with ... and filesystems support")? Or, have I misread something?
> I intend to use it in projects that would otherwise use embedded > Linux, but need better performance / responsiveness / free resources, > without increase in platform's cost. I experienced and witnessed many > problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding > software quality, support and unnecessary amount of proprietary > interfaces where industry-standard interfaces exist. I believe that
"Proprietary interfaces" need not be *closed* interfaces. E.g., you can design your API in such a way that it offers the same functionality as "industry-standard interfaces" without adopting the same *syntax* as them. Personally, I find products that *tout* "industry standard" API's more annoying than those that make no effort to "fit" those molds. How often do you dig through such an API and then discover something is "not supported" -- for what the vendor/developer *thinks* was a "good reason". (e.g., does your C library support fread, fwrite, fseek, etc.? Or, do you want to rely on the RATIONALIZATION that not supporting a filesystem means you don't have to support these functions? etc.)
> those problems with dedicated RTOSes led to embedded Linux taking over > areas for which Linux wasn't even intended, and I hope to offer > similar (to Linux'es) advantages over them.
I think you will find the biggest hook to acceptance is ease of development. I.e., if you can write your code on platform X and port it to playform Y (think: X == desktop PC, Y == embedded hardware) then folks are more likely to use it (since most folks are lacking hardware skills and could never build on bare iron)
> For now I want to give a shape to my offer and strengthen the most > popular use cases for the OS. I don't have resources to make it > "relatively good for anything" like Linux, and I don't want to take > this direction in order to not complicate interfaces and development > procedures. > > Now I'd like to ask everybody who is willing to express his/her > opinion (as applicable): > > - What features, supported architectures/platforms/hardware support, > interfaces and available frameworks would make you use a new OS (if > you already use an RTOS)? > > - Why wouldn't you use a new OS (if you don't like the whole idea or > you're satisfied with the existing offer, etc.)?
Because an {MT,RT}OS is such a tiny part of a real application! Why bother figuring out how to *bend* someone else's design to fit the needs of your application? I typically write a new {MT,RT}OS for each application to best suit the needs of *that* application (my software is usually a tight fit with the resources available in a particular application). Of course, much of this effort is cutting and pasting from previous designs -- with suitable tweaks to data types, algorithm enhancements, other architectural consequences, etc. (the same sort of effort applies to my libraries as they can often be tweaked to better fit the application than a "one size fits all" implementation) Rather than focus on writing something that (you *hope*!) others can reuse, I would, instead, suggest you look harder at what you could do to better fit your "OS" to the needs of *your* applications ("projects"). Explore the value of different mechanisms to supply particular services/features to your application -- what works well in one application may be clumsy in another. Rethink the way you implement particular services -- what ASSUMPTIONS are you making (or, have others made *for* you!) that don't really *need* to apply? What assumptions can you rely on (that might not be true of "all" application) that you could leverage to your advantage to produce a better platform? E.g., in one of my RTOS's, I adopted the philosophy of augmenting *every* system call with timers and mutexes. This allowed consumers to get the simplicity of traditional function/procedure calls with some of the benefits of asynchronous service requests (i.e., not having to risk blocking indefinitely). [In a later revision of this RTOS, the timer implementation allowed consumers to determine how *long* a service had taken to complete] This required careful consideration on how timers were implemented -- since they needed to be very cheap and efficient (as they could, potentially, see lots of use). In another RTOS, I implemented a global namespace for all system objects and an LDAP-like procedure for locating and accessing objects within that namespace. This overhead allowed me to move objects in-to and out-of memory dynamically (without worrying about "pointers" getting munged). I redesigned the APIs in my MMRTOS to facilitate moving *large* quantities of data with low overhead (e.g., lots of zero-copy semantics throughout). Again, shifting the "cost"-performance point to favor the needs of that particular class of application. Bottom line, add some value to your implementation instead of being "yet another RTOS". (and, if you really *want* to be an RTOS, go to great pains to explain the mechanisms that you employ that let you use this term -- "Real Time doesn't mean Real Fast")
> - What will make you use an OS (if you currently don't use an OS at > all)? > > Please write what platform(s) your answer relates to and what is the > project's field (even in general terms, e.g. "low-end media gateway", > "network filtering appliance", "high-end router", "surveillance DVR", > "IP camera" etc.)
I work on a wide range of products of varying complexity. Currently, the projects I am working on are very *small* and VERY LARGE -- in whatever terms you care to use (KB to GB, fractional MHz to GHz, a few $ to 10's of $K). A "one size fits all" RTOS is just "too funny" in this context! :> Finally, make sure you take a good survey of what's out there before you start. In particular, look at the works from academia (most commercial offerings are pretty boring/uninspired... "me too"). Good luck!
On 09/19/2010 09:29 AM, FreeRTOS info wrote:
> On 19/09/2010 16:31, Stargazer wrote: >> Greetings, >> >> I am writing my own RTOS, which I intend to use in my projects and >> license for anyone who would like to use it. At first I will use it in >> my own projects, so that it achieves a certain level of real-life >> performance and stability, then release it. >> >> The idea is to employ a "classic" embedded RTOS design (single address >> space, multiple tasks, "hard" RT scheduling) with as much common >> interfaces as possible (POSIX I/O, sockets, pthreads, standard C >> library), with small storage and RAM footprint, with much higher >> responsiveness than most of OS commonly used and without a need in >> MMU. There's no need in a filesystem, everything runs from a single >> binary. Most of the components are optional, it's easy even to use the >> OS without a task manager as one big loop but with h/w, memory >> management and filesystems support, for example. >> >> I intend to use it in projects that would otherwise use embedded >> Linux, but need better performance / responsiveness / free resources, >> without increase in platform's cost. I experienced and witnessed many >> problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding >> software quality, support and unnecessary amount of proprietary >> interfaces where industry-standard interfaces exist. I believe that >> those problems with dedicated RTOSes led to embedded Linux taking over >> areas for which Linux wasn't even intended, and I hope to offer >> similar (to Linux'es) advantages over them. >> >> For now I want to give a shape to my offer and strengthen the most >> popular use cases for the OS. I don't have resources to make it >> "relatively good for anything" like Linux, and I don't want to take >> this direction in order to not complicate interfaces and development >> procedures. >> >> Now I'd like to ask everybody who is willing to express his/her >> opinion (as applicable): >> >> - What features, supported architectures/platforms/hardware support, >> interfaces and available frameworks would make you use a new OS (if >> you already use an RTOS)? >> >> - Why wouldn't you use a new OS (if you don't like the whole idea or >> you're satisfied with the existing offer, etc.)? >> >> - What will make you use an OS (if you currently don't use an OS at >> all)? >> >> Please write what platform(s) your answer relates to and what is the >> project's field (even in general terms, e.g. "low-end media gateway", >> "network filtering appliance", "high-end router", "surveillance DVR", >> "IP camera" etc.) >> >> Thanks, >> Daniel >> >> > > Just what the world needs - another RTOS. Line up. >
You beat me to the punch. RTOS's are too attractive a target, and it's too easy to make a mediocre one that convinces you that quality is just around the corner. I may write one for my own amusement, but I couldn't see attempting to make one for the masses -- it's been done. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html

Stargazer wrote:

> Greetings, > > I am writing my own RTOS, which I intend to use in my projects and > license for anyone who would like to use it. At first I will use it in > my own projects, so that it achieves a certain level of real-life > performance and stability, then release it.
Congratulations. Every embedded developer writes a RTOS upon reaching a certain point in his career. Some even build a bunch of applications around their RTOSes. It's perfectly normal. Writing a RTOS is also a very useful exercise in understanding how stuff works and why certain things have to be done in the certain ways.
> The idea is to employ a "classic" embedded RTOS design (single address > space, multiple tasks, "hard" RT scheduling) with as much common > interfaces as possible (POSIX I/O, sockets, pthreads, standard C > library), with small storage and RAM footprint, with much higher > responsiveness than most of OS commonly used and without a need in > MMU. There's no need in a filesystem, everything runs from a single > binary. Most of the components are optional, it's easy even to use the > OS without a task manager as one big loop but with h/w, memory > management and filesystems support, for example.
Yea, been there, done that :))))) After floundering in a sandbox for a while, you will realize that you need the MMU, filesystem, USB host, TCP/IP stack, etc. What makes you think that your RTOS is going to be different from many existing ones?
> I intend to use it in projects that would otherwise use embedded > Linux, but need better performance / responsiveness / free resources, > without increase in platform's cost. I experienced and witnessed many > problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding > software quality, support and unnecessary amount of proprietary > interfaces where industry-standard interfaces exist. I believe that > those problems with dedicated RTOSes led to embedded Linux taking over > areas for which Linux wasn't even intended, and I hope to offer > similar (to Linux'es) advantages over them. > > For now I want to give a shape to my offer and strengthen the most > popular use cases for the OS. I don't have resources to make it > "relatively good for anything" like Linux, and I don't want to take > this direction in order to not complicate interfaces and development > procedures. > > Now I'd like to ask everybody who is willing to express his/her > opinion (as applicable): > > - What features, supported architectures/platforms/hardware support, > interfaces and available frameworks would make you use a new OS (if > you already use an RTOS)?
Just look into any RTOS (VxWorks, OSEK, etc.) I assure you all features provided are necessary and useful in one way or another.
> - Why wouldn't you use a new OS (if you don't like the whole idea or > you're satisfied with the existing offer, etc.)?
I would avoid using *any* new OS because of the learning curve.
> - What will make you use an OS (if you currently don't use an OS at > all)?
I will have to switch to a new RTOS only if it supports the already available hardware platform which is too complicated to be controlled as the bare metal.
> Please write what platform(s) your answer relates to and what is the > project's field (even in general terms, e.g. "low-end media gateway", > "network filtering appliance", "high-end router", "surveillance DVR", > "IP camera" etc.)
A platform with 100+ MHz and 1+ megabyte. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
On Sep 19, 6:31=A0pm, Stargazer <stargazer3...@gmail.com> wrote:
> Greetings, > > I am writing my own RTOS, which I intend to use in my projects and > license for anyone who would like to use it. At first I will use it in > my own projects, so that it achieves a certain level of real-life > performance and stability, then release it. > > The idea is to employ a "classic" embedded RTOS design (single address > space, multiple tasks, "hard" RT scheduling) with as much common > interfaces as possible (POSIX I/O, sockets, pthreads, standard C > library), with small storage and RAM footprint, with much higher > responsiveness than most of OS commonly used and without a need in > MMU. There's no need in a filesystem, everything runs from a single > binary. Most of the components are optional, it's easy even to use the > OS without a task manager as one big loop but with h/w, memory > management and filesystems support, for example. > > I intend to use it in projects that would otherwise use embedded > Linux, but need better performance / responsiveness / free resources, > without increase in platform's cost. I experienced and witnessed many > problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding > software quality, support and unnecessary amount of proprietary > interfaces where industry-standard interfaces exist. I believe that > those problems with dedicated RTOSes led to embedded Linux taking over > areas for which Linux wasn't even intended, and I hope to offer > similar (to Linux'es) advantages over them. > > For now I want to give a shape to my offer and strengthen the most > popular use cases for the OS. I don't have resources to make it > "relatively good for anything" like Linux, and I don't want to take > this direction in order to not complicate interfaces and development > procedures. > > Now I'd like to ask everybody who is willing to express his/her > opinion (as applicable): > > - What features, supported architectures/platforms/hardware support, > interfaces and available frameworks would make you use a new OS (if > you already use an RTOS)? > > - Why wouldn't you use a new OS (if you don't like the whole idea or > you're satisfied with the existing offer, etc.)? > > - What will make you use an OS (if you currently don't use an OS at > all)? > > Please write what platform(s) your answer relates to and what is the > project's field (even in general terms, e.g. "low-end media gateway", > "network filtering appliance", "high-end router", "surveillance DVR", > "IP camera" etc.) > > Thanks, > Daniel
My suggestion will be: do what you feel is right and will serve you. Chances are if something is useful to you it will be useful to other people as well. And ignore the "why yet another RTOS" sort of replies, what you do with your time is your choice - which I am sure you know anyway. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Didi wrote:

> On Sep 19, 6:31 pm, Stargazer <stargazer3...@gmail.com> wrote: > >>Greetings, >> >>I am writing my own RTOS, which I intend to use in my projects and >>license for anyone who would like to use it. At first I will use it in >>my own projects, so that it achieves a certain level of real-life >>performance and stability, then release it. >> >>The idea is to employ a "classic" embedded RTOS design (single address >>space, multiple tasks, "hard" RT scheduling) with as much common >>interfaces as possible (POSIX I/O, sockets, pthreads, standard C >>library), with small storage and RAM footprint, with much higher >>responsiveness than most of OS commonly used and without a need in >>MMU. There's no need in a filesystem, everything runs from a single >>binary. Most of the components are optional, it's easy even to use the >>OS without a task manager as one big loop but with h/w, memory >>management and filesystems support, for example. >> >>I intend to use it in projects that would otherwise use embedded >>Linux, but need better performance / responsiveness / free resources, >>without increase in platform's cost. I experienced and witnessed many >>problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding >>software quality, support and unnecessary amount of proprietary >>interfaces where industry-standard interfaces exist. I believe that >>those problems with dedicated RTOSes led to embedded Linux taking over >>areas for which Linux wasn't even intended, and I hope to offer >>similar (to Linux'es) advantages over them. >> >>For now I want to give a shape to my offer and strengthen the most >>popular use cases for the OS. I don't have resources to make it >>"relatively good for anything" like Linux, and I don't want to take >>this direction in order to not complicate interfaces and development >>procedures. >> >>Now I'd like to ask everybody who is willing to express his/her >>opinion (as applicable): >> >>- What features, supported architectures/platforms/hardware support, >>interfaces and available frameworks would make you use a new OS (if >>you already use an RTOS)? >> >>- Why wouldn't you use a new OS (if you don't like the whole idea or >>you're satisfied with the existing offer, etc.)? >> >>- What will make you use an OS (if you currently don't use an OS at >>all)? >> >>Please write what platform(s) your answer relates to and what is the >>project's field (even in general terms, e.g. "low-end media gateway", >>"network filtering appliance", "high-end router", "surveillance DVR", >>"IP camera" etc.) >> >>Thanks, >>Daniel > > > My suggestion will be: do what you feel is right and will serve you. > Chances are if something is useful to you it will be useful to > other people as well. > And ignore the "why yet another RTOS" sort of replies, what you do > with your time is your choice - which I am sure you know anyway. > > Dimiter
The RTOS + hardware drivers is not a big deal. Giving RTOS to the other people opens entirely different set of problems. First problem is support for all kinds of emulators running on all kinds of hosts. Next problem is support for all kinds of connectivity (USB, 1394, IPv6...) and filesystems on the HDD and flash. Of course, each of those things could be developed. But, even if they pay well for that, I have more interesting things to do rather then re-implementation of a bunch of dull protocols and trivial algorithms by hand. Life is short and it is unreasonable to waste it on the things that had been done 10000 times already. VLV
On Sep 19, 8:00=A0pm, "Paul E. Bennett" <Paul_E.Benn...@topmail.co.uk>
wrote:

Hi,

thanks for your reply.

> The question you should ask is:- "Do you really need an RTOS for the > application?". It can often be surprising to list the feature set you nee=
d
> and see how you can do that easily without the RTOS. However, when you ne=
ed
> an RTOS you need to have a really good one.
Indeed I did ask this question (no. 3). Embedded projects is such a broad field with very different needs. My objective with this poll is to get a feel of different needs. I'm not into convincing people that do well without an OS that they need one, but if such people complain about missing software features, I'd think what I can offer. Daniel
Greetings,

thanks for detailed answer. Please see clarifications and discussion
inline.

> If you've not written an RTOS before, I would suggest you add a > step *before* "public release" (I would actually suggest you add it > before you finish any of *your* projects, as well!): =A0namely, > "lather, rinse, repeat". =A0You'll find many of the classic features > offered in MTOS's and RTOS's are, in practice, redundant and/or > superfluous. =A0Once you've *used* them, you will be able to recognize > which fit this mold and how you can trim down a "bullet point > feature list to a true *core* of useful features -- though you might > have to look at things in a different way to see the duality hidden > there. =A0Then, revise your platform to more effectively use a smaller > set of features (IMO, this has led to more robust and responsive > implementations)
I think you misunderstand how features in embedded OS are usually implemented. Features exist in independent modules; if your current project doesn't need them, then you don't build/link them in, save memory and storage and get more robust and responsive application. But if your next project needs them, you just build them in and may be quite happy to have them handy. It's the same as configuring Linux kernel if you are familiar with it. [...]
> It looks like you are already following the "kitchen sink" approach. > Where is your priority: =A0footprint (TEXT/DATA) or features?
It depends on the project. One project will not start if some features can't be provided, and another needs smaller footprint. See above.
> > responsiveness than most of OS commonly used and without a need in > > MMU. There's no need in a filesystem, everything runs from a single > > Note that "filesystem" need not carry the bloat of a *disk* (or > "memory") filesystem. =A0E.g., I like using fwrite, fread, etc. > in my "tasks" (lets not argue terminology) with the sort of interface > one typically thinks of with a namespace residing atop a filesystem.
fwrite(), fread() etc. are standard C library functions. They are not directly related to a filesystem but rather to streams concept of ISO C standard. By filesystems I mean real data structures that represent files and control information on some storage (ext2, FAT, JFFS2, cramfs, etc.).
> > binary. Most of the components are optional, it's easy even to use the > > OS without a task manager as one big loop but with h/w, memory > > management and filesystems support, for example. > > Wait -- first *no* filesystem ("no need in a filesystem") now there > *is* one ("with ... and filesystems support")? =A0Or, have I misread > something?
Filesystems' support are features that may be built in if your project needs them (you work with storage), or left out. In Linux, LynxOS and other UNIX-inspired embedded OSes you may possibly leave all filesystems out of kernel build, but then the OS won't boot - it must load /sbin/init from a filesystem. My OS follows the line of "classical" (my term) one-binary embedded OS that don't have a requirement to boot from a filesystem, but you have them in order to support storage devices.
> "Proprietary interfaces" need not be *closed* interfaces. > E.g., you can design your API in such a way that it offers > the same functionality as "industry-standard interfaces" > without adopting the same *syntax* as them.
yes I can. But that's exactly what I don't want to do - I want to provide industry-standard APIs with defined and well-known semantics. Real-life story: a couple of years ago I sold a port of sockets library for iTRON from my OS, then in early development. iTRON provides networking APIs that are exactly what you describe: mostly functionally equivalent to Berkeley sockets, but with different syntax, structures etc. The company that produces heavily-networking C framework and libraries, that wanted to support iTRON, decided to pay me for the port rather than learn new interface and change their core code - and I have to agree with their decision (from their point of view).
> Personally, I find products that *tout* "industry standard" > API's more annoying than those that make no effort to "fit" > those molds. =A0How often do you dig through such an API and > then discover something is "not supported" -- for what the > vendor/developer *thinks* was a "good reason". =A0(e.g., does > your C library support fread, fwrite, fseek, etc.? =A0Or, do > you want to rely on the RATIONALIZATION that not supporting a > filesystem means you don't have to support these functions? > etc.)
Yes, my C library supports fread(), fwrite(), fprintf(), fscanf(), notion of stdin, stdout, stderr and most of other standard C library. (It also supports regular POSIX I/O calls open(), read(), write(), ioctl(), dup(), sockets API, pthreads and "process" emulation: execve(), system(), exit(), atexit() etc.). Particular fread(), fwrite(), fseek() use read(), write(), lseek() back-ends, which may interface devices or sockets rather than filesystem. I have my own internal interface that connects POSIX I/O calls to filesystems implementation; in some special situations you may implement your own filesystem (or pseudo-filesystem) and use those functions to interface it. The whole C library is optional, as nearly everything else you may leave it out of build. If you insist on compiling in standard C file I/ O with no streams that may be read/written, it's possible but IMO useless. fopen() will always fail and obviously consequent fread()s/ fwrite()s will fail also.
> > those problems with dedicated RTOSes led to embedded Linux taking over > > areas for which Linux wasn't even intended, and I hope to offer > > similar (to Linux'es) advantages over them. > > I think you will find the biggest hook to acceptance is ease > of development. =A0I.e., if you can write your code on platform X > and port it to playform Y (think: =A0X =3D=3D desktop PC, Y =3D=3D embedd=
ed
> hardware) then folks are more likely to use it (since most > folks are lacking hardware skills and could never build on bare iron)
That's what I think too. I can build on bare iron, but in my own projects I always consider ease of porting of existing software. It results in different amounts of work, and customers are always more willing to pay less (money and time) than to pay more :-)
> Rather than focus on writing something that (you *hope*!) others > can reuse, I would, instead, suggest you look harder at what you > could do to better fit your "OS" to the needs of *your* applications > ("projects"). =A0Explore the value of different mechanisms to supply > particular services/features to your application -- what works well > in one application may be clumsy in another. =A0Rethink the way you > implement particular services -- what ASSUMPTIONS are you making > (or, have others made *for* you!) that don't really *need* to apply? > What assumptions can you rely on (that might not be true of "all" > application) that you could leverage to your advantage to produce a > better platform?
You're asking right questions, but the problem is that they can't be answered before doing real projects. Thinking and considering without real projects will not produce anything meaningful. I'd like to use results of this poll to get in "better shape" to full-scale projects and possibly even to shape fields where I will offer services.
> E.g., in one of my RTOS's, I adopted the philosophy of augmenting > *every* system call with timers and mutexes. =A0This allowed consumers > to get the simplicity of traditional function/procedure calls with > some of the benefits of asynchronous service requests (i.e., not > having to risk blocking indefinitely). =A0[In a later revision of this > RTOS, the timer implementation allowed consumers to determine how > *long* a service had taken to complete] =A0This required careful > consideration on how timers were implemented -- since they needed to > be very cheap and efficient (as they could, potentially, see lots of > use).
I think that high-resolution timers need only to increment/decrement counter, which the timing code will just read and subtract. If platform is custom, I would also consider using dedicated hardware timer or a CPU that has it. Regarding asynchronous requests - may be your consumers would be happier if those were implemented with industry-standard select() / poll(), did you ask them? I undertand that embedded/RTOS won't fit all needs. One benefit is that application runs on system level and may interface some hardware directly independently of OS, while using OS services where they are suitable.
> Bottom line, add some value to your implementation instead of > being "yet another RTOS". =A0(and, if you really *want* to be an > RTOS, go to great pains to explain the mechanisms that you employ that > let you use this term -- "Real Time doesn't mean Real Fast")
I believe that the major value of an OS is that it provides the feature list that it declares and implements them well. Most "established" RTOSes simply don't provide the declared functionality. Most customers that I did works for in the past decade do projects over embedded Linux; and those are kind of projects where you would expect to see a dedicated embedded/RTOS, and despite that Linux is not RT and wasn't even intended to be an embedded OS. The situation looks beyond repair - we have Windriver and LynuxWorks selling Linux distributions instead of fixing and improving their RTOS offers.
> I work on a wide range of products of varying complexity. =A0Currently, > the projects I am working on are very *small* and VERY LARGE -- in > whatever terms you care to use (KB to GB, fractional MHz to GHz, a few > $ to 10's of $K). =A0A "one size fits all" RTOS is just "too funny" > in this context! :>
Why, Linux is just almost "one size fits all" Thanks, Daniel