1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
Ongoing items that always need work
-----------------------------------
- Valgrind once in a while to check / fix memory leaks / memory corruption
- Keep the spec in sync with the code
- Write / check / update docs of exported libraries
- Audit all code and drop privileges in helpers where appropriate
Items specifically planned for 0.5.10
(TODO: need to go through and nominate things for 0.5.10)
------------------------------------
- Rip out translation framework (.po files) since only deprecated
functions in libhal-storage have relied on it since the 0.5.8
release.
- Rip out hal-device-manager for good now that there is a
gnome-device-manager on the horizon
- Release engineering. Would be nice to have a set of Makefile
targets to automatically make a new release, upload it somewhere
and send announcement mail. Seems that cairo have something we
might be able to lift.
- Make sure we check if the optical drives supports the commands
we are sending to it (proposed by pjones)
- Singleton addons (s-addon); the idea that an add-on can attach to
several device objects at the same time.
- A s-addon would just implement, say, the interface
org.freedesktop.Hal.SingletonAddon with methods DeviceAdded(),
DeviceRemoved() through the hald direct connection.
- An s-addon would be identified by it's commandline; e.g.
info.s-addons = {"my-s-addon --foo", "my-s-addon --bar"} would
be two distinct addons.
- Bluez devs need this to start the Bluez daemon via HAL
- Can consolidate other things like hald-addon-keyboard
- Move /usr/libexec to /usr/lib/hal/ - drop /usr/lib/hal/scripts -
use /usr/lib/hal/methods. Need to provide backwards compat
for 3rd party so we need to retain /usr/lib/hal/scripts
- Think hard about the interfaces HAL exports to addons as
out-of-tree code like NUT and Bluez now starts to use it. Includes
interface stability thoughts and what we guarantee and what we
don't. Might have license implications too.
- LVM support
https://bugs.freedesktop.org/show_bug.cgi?id=6427
- Format volume methods
- Disk partitioning methods
- File system label renaming
- Provide mechanism for polling storage devices we can't poll regulary
e.g. PC floppy drives and Zip drives. When that it is, actually go back
to provide children for volumes detected like we did in HAL 0.4.x
- Provide mechanism for tuning the readahead size. For example, a DVD
player application (such as GNOME's Totem) might want to read ahead
several hundreds of megabyte so the drive only needs to spin up every
e.g. 20 minutes while watching a DVD movie. This enables the kernel
driver to put the drive in a low-power mode to get substantially better
battery life. Probably requires kernel work since the pages would
have to be pinned?
- Use udev data instead of probing (whenever possible). Here we need
the raw serial from udev; for e.g. USB drives, udev prepends it
with the make/model of the usb device.
- Configuration of serial and other legacy ports, see
http://lists.freedesktop.org/archives/hal/2006-August/005784.html
- Clean up what the user did by invoking methods on HAL
- e.g. unmount storage devices
- other things
- we can now sanely do this thanks to ConsoleKit
- depends on PolicyKit
- Make HAL unconditionally depend on pm-utils and rip out support
for distro-specific tools
- Devices of capability access_control could export an interface with
for requesting / dropping access to the device, e.g.
RequestAccess()
GiveupAccess() (better naming welcome)
which will change device file ownership or add/remove an ACL.
Depends on PolicyKit
- It would be nice if method calls could return string, bool int etc.
Perhaps use dbus-send style, e.g. int32:<number>' or 'string:the_string'
or 'bool:true'. Granted, this is already possible today through addons
so maybe not important.
Other items
-----------
- Device firmware. It would be nice to export a property and some
DeviceCondition when a device asked for firmware that was missing
and is such in a state where it cannot operate. Might need kernel
work. Same goes for drivers.
- Export ink levels for printers
https://bugs.freedesktop.org/show_bug.cgi?id=2295
- Signal when a USB device doesn't have enough power
https://bugs.freedesktop.org/show_bug.cgi?id=4452
(it appears that this is true IFF the kernel leaves
bConfigurationValue as zero)
- Teach HAL about multisession and partitioned optical discs - may
require reworking the 'fakevolume' code as we'd be adding more
than one fakevolume
Optimization
------------
- Port hal daemon core to use dbus glib bindings
- One proxy per hal device object
- hal device object is an GObject
- wants to export multiple D-Bus interfaces for a single GObject
- for some interfaces... need/want to handle all messages on myself
(for forwarding to addons)
- ie. need to partipate in Introspection() on "DBusGProxy" stuff
- Linux: Optionally drop sysfs coldplug code
- for starting up before udev and piggy tailing on udev's coldplug code
- Performance! Profile and optimize! Too big of a task to describe in
one bullet. Feel free to provide patches to this file to break it up
after some analysis.
External projects:
------------------
- We need to finish PolicyKit, at least get 0.3 out (in Spring 2007)
and work on bringing it to 1.0 rather fast (ideally before Fall
2007).
- Runtime power management in the kernel. This is still ongoing
and AFAIK there is no concrete idea about the user space interface.
Once the user space interface is set in stone we can easily
export this via HAL for selective suspend and/or tuning of knobs.
|