Qtopia-interest Archive, April 2008
Musings of providing unified access to kernel interfaces
Message 1 in thread
Hey,
the kernel interfaces unifiy and Qtopia is not providing any convience
functionality for that
Examples:
- The new battery device class in 2.6.24
- The LCD/backlight device class
- The LED device class
- InputEvent handling to broadcast changes
- sysfs handling
....
Qtopia's current solution:
- Write code that works for one item of the class (where only the path name
is different)
- Everyone has his or her copy to read and write the page from sysfs files
- This is forcing duplication with copy and paste which is known to cause
errors... and makes maintainenance harder...
Proposal:
- What about providing c++ classes for the classes of devices the kernel is
exporting? This way an integrator just need to instantiate a base class
with the right model name, or pick the model from a list of available
models. Sounds sane doesn't it?
War story:
raster needed to provide battery stats for the neo in illume/enlightenment,
he saw the new battery device class, instead of just picking the values
presented by the model we have in the GTA02, he sat down, read the spec,
looked at the existing battery code mess, cleaned it up, added the battery
class. Now any battery we will use in future GTA models, laptops, you name
will just work. The power of abstraction...
comments?
z.
--
[ signature omitted ]
Message 2 in thread
Holger Freyther wrote:
> Hey,
>
> the kernel interfaces unifiy and Qtopia is not providing any convience
> functionality for that
>
> Examples:
> - The new battery device class in 2.6.24
> - The LCD/backlight device class
> - The LED device class
> - InputEvent handling to broadcast changes
> - sysfs handling
> ....
>
> Qtopia's current solution:
> - Write code that works for one item of the class (where only the path name
> is different)
> - Everyone has his or her copy to read and write the page from sysfs files
> - This is forcing duplication with copy and paste which is known to cause
> errors... and makes maintainenance harder...
>
>
> Proposal:
> - What about providing c++ classes for the classes of devices the kernel is
> exporting? This way an integrator just need to instantiate a base class
> with the right model name, or pick the model from a list of available
> models. Sounds sane doesn't it?
>
>
> War story:
> raster needed to provide battery stats for the neo in illume/enlightenment,
> he saw the new battery device class, instead of just picking the values
> presented by the model we have in the GTA02, he sat down, read the spec,
> looked at the existing battery code mess, cleaned it up, added the battery
> class. Now any battery we will use in future GTA models, laptops, you name
> will just work. The power of abstraction...
>
>
> comments?
Sounds good, except...
Doing this possibly means you are stuck using a 2.6.24+ kernel? Most of our customers are not using
the latest and greatest of anything. It's too new. It needs to be applyable on a variety of kernel
versions (even 2.4 if you can believe).
--
[ signature omitted ]
Message 3 in thread
On Thursday 03 April 2008 05:18:50 Lorn Potter wrote:
> > War story:
> > raster needed to provide battery stats for the neo in
> > illume/enlightenment, he saw the new battery device class, instead of
> > just picking the values presented by the model we have in the GTA02, he
> > sat down, read the spec, looked at the existing battery code mess,
> > cleaned it up, added the battery class. Now any battery we will use in
> > future GTA models, laptops, you name will just work. The power of
> > abstraction...
> >
> >
> > comments?
>
> Sounds good, except...
> Doing this possibly means you are stuck using a 2.6.24+ kernel? Most of our
> customers are not using the latest and greatest of anything. It's too new.
> It needs to be applyable on a variety of kernel versions (even 2.4 if you
> can believe).
Hehe,
the kernel interface is unlikely to be changed in the next 20 years, so you
can add a class/task for the generic battery, xyz, foo and the integrator, at
their will, can instantiate this task/class if it makes sense or implement
their battery method for a 2.4er kernel and their battery.
See the war story, the e gadget for battery is still supporting all old ways
of getting the battery information, just added one way for the generic
battery class in a generic way. ;)
Do you lose support for Linux1.2 and Linux2.4 when adding a class/task that
can support the generic battery class? You don't, your integrators will have
a more easy job, this is what a framework is all about. Making the job more
easy. Qtopia most of the time is failing here.
z.
--
[ signature omitted ]
