3 ms·

>They don't have the processing power, memory, and storage necessary This is in my opinion, a sign of bloat. They darn-well do have the processing power to bu

by ibisum 12y ago

>They don't have the processing power, memory, and storage necessary This is in my opinion, a sign of bloat. They darn-well do have the processing power to build their own images! Its just 'not desirable to use a slow computer to do it' .. Well, where the build is slow: refactor until its fast. > It's far better to work on having a deterministic verifiable cross-compiling build system and continue to flash the firmware over JTAG. The new open networks will require a lot more crypto. I'd prefer to run an open network where signed binaries and such things are just part of the norm. But then, this is all just hot-air .. time better spent actually working on the problem of so much hardware, so little actually safe source code to run on it.

wmf 12y ago
Can you really compile anything, let alone the kernel, with 16 MB of flash and 128 MB of RAM? Isn't the kernel source alone bigger than 128 MB?
- MertsA 12y ago
  In theory you can strip out the majority of the kernel sources and I'm sure there's some automated way to do this with the kernel build process. Make already doesn't even have to look at the source for drivers that aren't being built. I think there's a lot of macros that depend on the config but there should still be a way to basically run the preprocessor over everything being compiled to strip out all of the pointless #ifdef blocks.
  - wtallis 12y ago
    The preprocessor's got nothing to do with it. As you've noted, the raw size of the source code is easily dealt with. (At least for parsing. We still haven't identified where it's being stored in the first place.) The problem is that when targeting an embedded system, you really want to use compiler optimizations (especially size optimizations), and those heuristics require more RAM than routers have. Ideally, you would compile large parts of the OS with link-time optimization, which is one of the most memory-intensive options you can pass to a compiler.

by ibisum 12y ago

wmf 12y ago

Can you really compile anything, let alone the kernel, with 16 MB of flash and 128 MB of RAM? Isn't the kernel source alone bigger than 128 MB?

MertsA 12y ago
In theory you can strip out the majority of the kernel sources and I'm sure there's some automated way to do this with the kernel build process. Make already doesn't even have to look at the source for drivers that aren't being built. I think there's a lot of macros that depend on the config but there should still be a way to basically run the preprocessor over everything being compiled to strip out all of the pointless #ifdef blocks.
- wtallis 12y ago
  The preprocessor's got nothing to do with it. As you've noted, the raw size of the source code is easily dealt with. (At least for parsing. We still haven't identified where it's being stored in the first place.) The problem is that when targeting an embedded system, you really want to use compiler optimizations (especially size optimizations), and those heuristics require more RAM than routers have. Ideally, you would compile large parts of the OS with link-time optimization, which is one of the most memory-intensive options you can pass to a compiler.