131 lines
4.7 KiB
Plaintext
131 lines
4.7 KiB
Plaintext
$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.
|
|
|