xref: /src/doc/roadmaps/mobile

$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.