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

Summary: rework tdehwlib support to unify API
Product: TDE Reporter: Michele Calgaro <michele.calgaro>
Component: tdelibsAssignee: Timothy Pearson <kb9vqf>
Status: NEW ---    
Severity: normal CC: bugwatch, michele.calgaro, slavek.banko
Priority: P5    
Version: R14.1.x [Trinity]   
Hardware: Other   
OS: Linux   
See Also: http://bugs.pearsoncomputing.net/show_bug.cgi?id=2494
http://bugs.pearsoncomputing.net/show_bug.cgi?id=2495
http://bugs.pearsoncomputing.net/show_bug.cgi?id=2496
http://bugs.pearsoncomputing.net/show_bug.cgi?id=2702
Compiler Version: TDE Version String:
Application Version: Application Name:
Bug Depends on:    
Bug Blocks: 2967    

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.