$NetBSD: mobile,v 1.1 2017/01/13 10:14:58 dholland Exp $ NetBSD Mobile Roadmap ===================== This roadmap is meant to cover issues specifically pertaining to mobile use, that is, devices that run on batteries and get carried around. This includes: - phones - tablets - tablet PCs - laptops The typical assumption right now is that phones and tablets have one software stack (iOS, Android) and work one way, and laptops, including tablet PCs, have another software stack (Windows, MacOS, Linux) and work another way. The "laptop" software stack is more or less the same as the "desktop" software stack, modulo some laptop-specific issues. Those laptop-specific issues are covered in this file; the rest of that software stack is discussed in the "desktop" roadmap. This file also covers the phone/tablet software stack. The following elements, projects, and goals are considered strategic priorities for the project: 1. Tickless timers/scheduling These elements, projects, and goals are more or less long-term goals: 2. Power management concerns 3. Suspending 4. atrun considered harmful 5. (Wireless config issues are in the "desktop" roadmap) These elements, projects, and goals are for the time being pretty much blue sky: 6. Touchscreen (phone/tablet) UI 7. Support for phone hardware Explanations ============ 1. Tickless timers/scheduling The basic premise with a tickless system is that instead of generating a timer interrupt HZ times a second, one programs a high-resolution timer on the fly to interrupt the next time something needs to happen. This can substantially reduce the number of timer interrupts taken, and also importantly it avoids waking the system up regularly when otherwise idle and reduces power consumption and heating. There has been a fair amount of talk about this but so far no real action. - As of January 2017 nobody is known to be working on this. - There is currently no clear timeframe or release target. - Contact: ? (XXX) 2. Power management concerns NetBSD's power management infrastructure is fairly lacking. We don't have good CPU clock rate throttling, we mostly don't have the ability to power down idle devices, and we don't have a configuration and control setup to manage it either. On x86 we also don't support a number of important ACPI sleep/idle states. At the moment there isn't even a good inventory of what needs to be done in this department. Someone please write it and put it here. - As of January 2017 nobody is known to be working on this. - There is currently no clear timeframe or release target. - Contact: ? (XXX) 3. Suspending Currently suspending mostly doesn't work, and the chances of being able to suspend any given laptop model successfully are low until someone using it gets annoyed enough to sit down and make it behave. We need to fix this, both by adding suspend hooks to drivers that are missing them and also (ideally) by coming up with a better way to cope with drivers that don't know how to suspend. - As of January 2017 nobody is known to be specifically working on this, although work on individual drivers occurs sporadically. - There is currently no clear timeframe or release target. - Contact: ? (XXX) 4. atrun considered harmful There are a number of things on the system that unnecessarily wake up and take cpu time and power on a regular basis. One of the big offenders is atrun -- it should be changed either to be a daemon that wakes up only when it has a job to run, integrated into cron to the same end, or changed around in some other similar fashion. One can always turn atrun off, but there's no particular reason that at(1) functionality should be unavailable on laptops. - As of January 2017 nobody is known to be specifically working on this, although work on individual drivers occurs sporadically. - There is currently no clear timeframe or release target. - Contact: ? (XXX) 6. Touchscreen (phone/tablet) UI We'd rather like to be able to run on phones, and that means having a UI suitable for a phone -- a shell isn't going to cut it, and even a shell coupled with a keyboard app isn't really the ticket. This has many of the same kinds of issues as desktop software. Some of the specific issues are different; e.g. location handling is a lot more critical for phones than for desktops and even laptops. While we don't currently run on any phone platforms (see below) there's nothing stopping working on this using older PDA/palmtop hardware like hpcarm. 7. Support for phone hardware We don't currently support any phone hardware platforms at all. It would be good to. Among other things this requires finishing arm64 support, but there's also lot of drivers to write.