From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C9EDE3B2A4 for ; Thu, 26 Jul 2018 09:13:47 -0400 (EDT) Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 86B6125375; Thu, 26 Jul 2018 09:13:47 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7E9EF25406; Thu, 26 Jul 2018 09:13:47 -0400 (EDT) Received: from app33.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6178F25375; Thu, 26 Jul 2018 09:13:47 -0400 (EDT) X-Sender-Id: MAILER-DAEMON Received: from app33.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 26 Jul 2018 09:13:47 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app33.wa-webapps.iad3a (Postfix) with ESMTP id 4DE01A00DF; Thu, 26 Jul 2018 09:13:47 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 26 Jul 2018 09:13:47 -0400 (EDT) Date: Thu, 26 Jul 2018 09:13:47 -0400 (EDT) From: "dpreed@deepplum.com" To: "Mikael Abrahamsson" Cc: "Dave Taht" , cerowrt-devel@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: text/plain;charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <1532610827.31646803@apps.rackspace.com> X-Mailer: mobile/6.0.2 Subject: Re: [Cerowrt-devel] =?iso-8859-1?q?So_how_far_behind_is_the_embedded_?= =?iso-8859-1?q?router_world=2Cstill=3F?= X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 13:13:47 -0000 Embedded Linux is still a mess. I've been putting some serious (hacking) effort into RISC-V, using the near= desktop class HiFive Unleashed board. The vendor (SiFive) and the RISC-V g= uys use buildroot! There is a coreboot project, but nothing for the actual = hardware exists... Just a lashup for a qemu emulator of a vanilla system. No reason for lede really ... There is no standard network adapter for its = bus other than a GigE device. But this got me thinking about lede, Android, Yocto, Linaro. What a godawfu= l mess this world that *Linus doesn't care about* is in. Now the Linux kernel is OK. It can be made simple. But from the call to ini= t() onwards, Linux and BSD just suck. Baling wire and chewing gum. Even ini= tramfs is unmaintanable between releases. Part of this is package mania. Nothing is shrink wrapped. Everything needs = re testing, by every vendor, every time. And it usually breaks. Part of this is binaries tied to a particular instance of hardware. Blobs. = Why do they exist? To divide the OEMs among themselves and waste time and e= ffort, mostly. They do reduce the cost of supporting driver tweakers who do= n't understand how the hardware works, or build support that makes the vend= or unable to improve it's product, but maybe there's a better way ... Creat= e an Open Source Community? And then there are the buses/controllers. I blame Linux for blessing PCI ..= an overcomplex and downright weird Wintel abortion. With patents all over = the place, meaning one can't clone it without creating sales for Intel proc= essors. But Linux's original sin is that it was created solely for x86 environment.= Yeah people have pushed it, but design decisions in the IO world around it= have followed the path of least resistance. That is, letting Intel Corpora= tion (with its buddy AMD) control Linux design and implementation. Is it time for a new OS framework that can solve the embedded industry's pr= oblems of huge waste and obsolescence? Not black sheep Linaro. They get lit= tle respect. Outside the Linux Foundation's Party Secretariat's dominance. RISC-V suggests to me that an open hardware world can be better than Intel-= world. The proposed interconnect, called TileLink, exists, and has a simple= working version on the board I'm playing with. It is scalable and flexible= like modern PCI, but has no lock-in and legacy. The ISA is, of course, cle= an and extensible. So can an industrial strength OS, not based on the Linux spaghetti, be made= to replace Linux. Its network stack would be Internet v6 (v4 optional) and= it would have IO done in isolated address spaces, communicating via mapped= pages with devices and other processes. It would have the ability to launc= h POSIX processes, but keep all that out of the kernel address space, so yo= u could just avoid all that on devices like storage and network appliances = and IoT. Maybe one could even start with a Linux kernel, but only that. Init() would= be entirely different, and only a subset would be used. The ABI would be e= xtended for simpler user space coding of device, network, ... logic that di= rectly operates the hardware and presents simple queue based (rings?) IPC. Why not now? -----Original Message----- From: "Mikael Abrahamsson" Sent: Thu, Jul 26, 2018 at 4:53 am To: "Dave Taht" Cc: "Dave Taht" , cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] So how far behind is the embedded router world= ,still? On Wed, 25 Jul 2018, Dave Taht wrote: > There are still a few companies alive in this space (openrg being one=20 > that I know nothing about), but... There is no single answer to this. Lots of the home routing SoC space is=20 now converging on 4.4, but BCM decided to go for 4.1. They came from 3.2,= =20 3.4 and perhaps 3.10. When I talk to staff at SoC vendors, they seem to=20 live in a world where you take a linux kernel that's announced as LTS (in= =20 the best of worlds), work on that for 1-2 years during which you release=20 an SDK, which then the device manufacturers will take and start putting=20 their solutions on, which takes another 1-2 years before it reaches=20 customers. So already there is significant latency. This doesn't mean there are not devices out there today, newly installed,= =20 that have really ancient kernels (as you have discovered). This is=20 especially true for cheaper and simpler devices that are very cost=20 optimized. There is movement in the right direction, but revving kernels on older=20 platforms is still hard, as in all of IoT space, due to lack of revenue=20 from older platforms. Main model is still to sell a device and then there= =20 is no further income, so no money to continously develop the device. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel