1$NetBSD: mobile,v 1.1 2017/01/13 10:14:58 dholland Exp $ 2 3NetBSD Mobile Roadmap 4===================== 5 6This roadmap is meant to cover issues specifically pertaining to 7mobile use, that is, devices that run on batteries and get carried 8around. This includes: 9 - phones 10 - tablets 11 - tablet PCs 12 - laptops 13The typical assumption right now is that phones and tablets have one 14software stack (iOS, Android) and work one way, and laptops, including 15tablet PCs, have another software stack (Windows, MacOS, Linux) and 16work another way. The "laptop" software stack is more or less the same 17as the "desktop" software stack, modulo some laptop-specific issues. 18Those laptop-specific issues are covered in this file; the rest of 19that software stack is discussed in the "desktop" roadmap. This file 20also covers the phone/tablet software stack. 21 22The following elements, projects, and goals are considered strategic 23priorities for the project: 24 25 1. Tickless timers/scheduling 26 27These elements, projects, and goals are more or less long-term goals: 28 29 2. Power management concerns 30 3. Suspending 31 4. atrun considered harmful 32 5. (Wireless config issues are in the "desktop" roadmap) 33 34These elements, projects, and goals are for the time being pretty much 35blue sky: 36 37 6. Touchscreen (phone/tablet) UI 38 7. Support for phone hardware 39 40 41Explanations 42============ 43 441. Tickless timers/scheduling 45 46The basic premise with a tickless system is that instead of generating 47a timer interrupt HZ times a second, one programs a high-resolution 48timer on the fly to interrupt the next time something needs to happen. 49This can substantially reduce the number of timer interrupts taken, 50and also importantly it avoids waking the system up regularly when 51otherwise idle and reduces power consumption and heating. 52 53There has been a fair amount of talk about this but so far no real 54action. 55 56 - As of January 2017 nobody is known to be working on this. 57 - There is currently no clear timeframe or release target. 58 - Contact: ? (XXX) 59 60 612. Power management concerns 62 63NetBSD's power management infrastructure is fairly lacking. We don't 64have good CPU clock rate throttling, we mostly don't have the ability 65to power down idle devices, and we don't have a configuration and 66control setup to manage it either. On x86 we also don't support a 67number of important ACPI sleep/idle states. 68 69At the moment there isn't even a good inventory of what needs to be 70done in this department. Someone please write it and put it here. 71 72 - As of January 2017 nobody is known to be working on this. 73 - There is currently no clear timeframe or release target. 74 - Contact: ? (XXX) 75 76 773. Suspending 78 79Currently suspending mostly doesn't work, and the chances of being 80able to suspend any given laptop model successfully are low until 81someone using it gets annoyed enough to sit down and make it behave. 82 83We need to fix this, both by adding suspend hooks to drivers that are 84missing them and also (ideally) by coming up with a better way to cope 85with drivers that don't know how to suspend. 86 87 - As of January 2017 nobody is known to be specifically working on 88 this, although work on individual drivers occurs sporadically. 89 - There is currently no clear timeframe or release target. 90 - Contact: ? (XXX) 91 92 934. atrun considered harmful 94 95There are a number of things on the system that unnecessarily wake up 96and take cpu time and power on a regular basis. One of the big 97offenders is atrun -- it should be changed either to be a daemon that 98wakes up only when it has a job to run, integrated into cron to the 99same end, or changed around in some other similar fashion. 100 101One can always turn atrun off, but there's no particular reason that 102at(1) functionality should be unavailable on laptops. 103 104 - As of January 2017 nobody is known to be specifically working on 105 this, although work on individual drivers occurs sporadically. 106 - There is currently no clear timeframe or release target. 107 - Contact: ? (XXX) 108 109 1106. Touchscreen (phone/tablet) UI 111 112We'd rather like to be able to run on phones, and that means having a 113UI suitable for a phone -- a shell isn't going to cut it, and even a 114shell coupled with a keyboard app isn't really the ticket. 115 116This has many of the same kinds of issues as desktop software. Some of 117the specific issues are different; e.g. location handling is a lot 118more critical for phones than for desktops and even laptops. 119 120While we don't currently run on any phone platforms (see below) 121there's nothing stopping working on this using older PDA/palmtop 122hardware like hpcarm. 123 124 1257. Support for phone hardware 126 127We don't currently support any phone hardware platforms at all. It 128would be good to. Among other things this requires finishing arm64 129support, but there's also lot of drivers to write. 130 131