On 5/14/2012 11:46 AM, Noob wrote:
> Don Y wrote:
>
>> Noob wrote:
>>
>>> Linux makes sense in a growing number of scenarios, even
>>> in the (32-bit, virtual memory) embedded market : connected
>>> TVs, "smart" phones, decoder set-top boxes, routers, etc.
>>
>> And you will notice that desktop stacks take a *boatload*
>> of resources! Have you tried porting one to an environment
>> with (just) 10's or 100's of KB of total RAM?
>
> Connected TVs, "smart" phones, decoder set-top boxes, routers, etc
> have *WAY* more RAM than that; typically /hundreds/ of megabytes,
> up to 1 gigabyte (!) for the Galaxy S3. RAM prices have reached an
> all-time low, at 4-8 euros per GB.
How many GB are you going to put in your refrigerator? Freezer?
Washing machine? Dryer? Bluetooth earpiece? Household thermostat?
Irrigation system? Furnace? Range/stove? Telephone? Multimedia
system remote control? Toaster?
<http://www.uberreview.com/2005/09/netbsd-controlled-toaster.htm>
Where do you think all those IPv6 addresses are GOING??? Do you
really think consumers will be excited about the UNNECESSARY
ADDED COSTS of "megabytes" of RAM just so their microwave
oven can "know" the right defrost cycle for a 12 pound turkey?
Or, so their washing machine can inform them when the wash
cycle is complete??
>>> The TCP/IP stack in Linux is robust and mature, and the rare
>>> security bugs are fixed fast.
>>
>> Just because a bug is fixed in a Linux/*BSD release (or patch),
>> doesn't automatically convey those same fixes to the TV/phone/STB!
>
> Phones and STBs can easily be upgraded in the field (TVs too, but
> consumers may not feel comfortable doing it).
We've already seen how wonderfully unsolicited updates work!
You've never encountered a problem where your machine "broke"
after a SOLICITED update? "Gee, Bob, the TV was working
yesterday! Honest, I didn't *touch* it! And don't go
blaming the kids for this, either!!"
>> Also, the nature of attacks on a desktop/server is different
>> than from an embedded device. The desktop stack just has to
>> safeguard against being *crashed*.
>
> And DoS, and spoofing, and hijacking.
It doesn't have to continue to heat the house when under attack.
Or prevent the items in the freezer from thawing (because it
was commanded to raise the temperature setpoint to 10C).
Or ensure that the plants in the yard keep getting watered
despite any "schedule/weather updates" from external services
("Gee, is it Summer out there? Should I be watering more
often? Or, less? I sure wish I knew... but, someone is
pinging the hell out of my interface and I can't seem to
get any useful information...")
>> E.g., I do a *lot* of processing in and just above the network
>> driver (i.e., low in the stack) so I can discard "inappropriate"
>> incoming packets before they percolate up the stack (to the
>> appropriate level of abstraction where they might, otherwise,
>> be recognized as "inappropriate"). Outgoing traffic inherits
>> the priorities of the sending task, etc. I.e., the stack
>> is more of an extension of the application than a separate
>> "service" provided to it.
>
> FTR, lwip can be configured that way too.
Look at *where* the filtering happens. If you harvest a
packet, you have incurred cost. If you can discard it *in* the
driver, you haven't.
>> In a desktop stack, you either rely on hardware MMU/VM
>> mechanisms to move data between userland and the kernel
>> or do lots of copyin/out's. The stack has no idea how it
>> is being used/abused so has to take a generic approach
>> to how it provides its services (to the application).
>>
>> There are costs (time+space) for this generality. In a
>> desktop, you usually have (or can upgrade to have) these
>> resources. How much "slop" (extra cost) do you add to
>> your embedded device to safeguard against this *possibility*
>> (which may never come to pass)?
>>
>> Desktop stacks tend to be more focused on throughput at the
>> expense of all else. Embedded systems tend to be more concerned
>> with a particular "functionality" within a given resource set.
>>
>> Desktops are often overkill for *specific* markets/applications.
>> If you look carefully at your application and what it expects
>> of its environment, you can find many opportunities where a
>> "general purpose" network stack can be trimmed down to better
>> fit that application -- saving resources, improving resiliency
>> and "predictability" in the process.
>>
>> This sort of scrutiny is, IMO, invaluable in designing robust
>> products; how can you be comfortable with an implementation
>> if you don't understand the technology on which it relies
>> (to a level of detail that allows you to excise those portions
>> that are inappropriate, liabilities, etc.)?
>
> You sound like someone who enjoys reinventing the wheel again
> and again (and again).
I believe in coming up with the right solution for the problem.
Do you use long longs for all your "numbers"? Heck, you can
represent 1, 35099, 68736, 5003876555, etc. ALL as long longs!
Why bother with byte_t's, shorts, ints, longs and long longs
when you could just use long longs for ALL of them!!! Why
REINVENT all the arithmetic operations for each of these
different data type sizes?!
Hmmm... we'll have problems with floating point values, though.
OK, so we;ll use long *doubles* for all out numeric needs!
Why bother with integer data types, floats, doubles *and*
long doubles if we can just handle them all with long doubles?!
Why REINVENT all the math LIBRARIES to support each of these
types? Why burden printf with having to know which size
argument it is dealing with? "Numbers are numbers", right?
Of cource, we also haev to worry about numbers that can't be
accurately expressed in those representations. So, maybe
we should adopt the use of a *rational* data type. I.e.,
typedef struct {
long double numerator;
long double denominator;
} rational_t;
And, of course, that won't handle complex numbers so we need
a complex_rational_t as well...
Look at all the REINVENTING that we've been able to AVOID!
After all, memory is cheap! Put a few GB in your toaster
so you can implement:
turn_on_heating_element();
sleep( (rational) (5.0L, 1.0L) );
turn_off_heating_element();
eject_toast();
beep();
with those nice CONSISTENT numeric types! :>
Do you have ONE sort() routine in your toolbox? Heck, sort
is sort is sort. Why REINVENT such a trivial facility?
Just throw more CPU cycles/memory at "whatever" algorithm you
settle on and live with that! Of course, you will have to
make sure your sort() is completely parameterized so you can
sort arbitrary objects -- not just "numbers" (which we have
already decided will be complex_rational_t's) or "strings"
(which should all be of variable length -- do we do LR alpha
sorts? What if we're sorting some numerical strings? Do
we add a SWITCH to sort right justified??) Look at how much
we'll *save* by not reinventing specialized sort()'s! :>
And, we surely don't need gets(), fgets(), getchar(), fgetc(),
getc(), UNgetc(), scanf(), sscanf(), fscanf(), etc. Let's
just settle on *one* so we don't REINVENT any of the same
(and incompatible) mechanisms.
Nor, different window managers, operating systems, "computers",
mice, etc. Choice is bad. One size fits ALL! Need a pocket
calculator? Carry a laptop! Need a pencil and pad of paper?
Put your desk on wheels!! :-/
We'll take a VOTE next Tuesday and rid ourselves of all this
UNNECESSARY duplication!
> In my opinion, the main strength of
> open-source software is to free developers from /continuously/
> solving the same problems (what a waste of human brain-power).
People often mistake *code* reuse with *design* reuse.
The thought that cobbling some existing (hopefully *working*)
code into a new project somehow cuts a corner. Sure! If
you are making essentially the same *thing* as that for
which the code was originally created! (is your washing
machine essentially the same as your STB?? Or your
furnace? Granted, they each might have a network
connection -- but, are their roles and needs *that*
similar that they would benefit from the same network
stack as that used in your PC??? REGARDLESS OF IT'S
SOFTWARE COST??)
The real gains are in reusing *designs*, not *code*.
Approaching similar problems in similar ways.
Reusing *code* assumes the code works, you *understand*
it sufficiently to *know* that it addresses your problem
domain adequately and that you will be able to *maintain*
it (what good is developing a product "overnight" if
you have to answer the first customer complaint with,
"Gee, I'll post a message on the forum and hope someone
*there* can tell me what's going wrong..."). This is how
product counterfeiters often falter -- when something
goes wrong, they haven't the knowledge of how to *fix* it
(because they've COPIED instead of ENGINEERED).
[It's also a great way to *thwart* counterfeiters by
designing your product to "break" if subtly altered!]
Reinventing for the sake of reinventing is a non-starter.
Blindly *reusing* is even worse!