By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 2706 - rework tdehwlib support to unify API
Summary: rework tdehwlib support to unify API
Status: NEW
Alias: None
Product: TDE
Classification: Unclassified
Component: tdelibs (show other bugs)
Version: R14.1.x [Trinity]
Hardware: Other Linux
: P5 normal
Assignee: Timothy Pearson
URL:
Depends on:
Blocks: 2967
  Show dependency treegraph
 
Reported: 2016-10-02 04:53 CDT by Michele Calgaro
Modified: 2020-10-15 22:22 CDT (History)
3 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michele Calgaro 2016-10-02 04:53:11 CDT
If TDE is built without tdehwlib, changes are requires and several bugs have been reported for FTBFS. After discussion with Slavek, in order to minimize changes and FTBFS report, we have come up with the following idea.
This should assure a uniform API and ABI in tdelibs, regardless of whether tdehwlib support was used or not.

1) add a function to detect at runtime whether tdelibs was built with or without tdehwlib 
2) modify all method provided by tdehwlib so that the code would only be executed in case tdehwlib support was required. Id support was not necessary, empty/null values would instead be returned by the same methods
3) where applicable, rework tdehwlib code to separate code/method specific to udev and not. This would be useful for example for *bsd, allowing to add *bsd specific code where erquired. Again, a function detecting the presence of udev or not would be useful

This will not be part of R14.0 series.
Comment 1 Michele Calgaro 2018-08-03 10:57:40 CDT
tdehw should be integral part of TDE (no more optional) and reworked to be able to build with hal support (*bsd) or udev (linux)
Comment 2 Michele Calgaro 2018-11-11 07:42:38 CST
as part of the rework planned for R14.2, we should look at extending tdehw support for eudev and potentially other backends
Comment 3 Michele Calgaro 2020-10-15 22:22:50 CDT
tdehw should be a central module loaded once and that each application can refer too if needed (something like a kded module). Applications can send/receive signals from the daemon module instead of linking tdehw as static library.