trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: August 2012

Re: [trinity-devel] Tim: TDEHWLIB

From: "Timothy Pearson" <kb9vqf@...>
Date: Mon, 27 Aug 2012 14:08:56 -0500
> On 08/26/2012 04:55 PM, Timothy Pearson wrote:
>> Correct.  You can blame various upstream system developers for that. ;-)
>>
>> As an aside, if someone else would like to add a plugin to tie into DBUS
>> for automount and such, I would be willing to work with them on the TDE
>> API side to make sure that the task can be accomplished.  I just refuse
>> to
>> rely solely on projects which both use DBUS and are constantly being
>> replaced with a newer completely incompatible version.
>>
>> Tim
>
> What would it take to identify those upstream packages (a small reasonable
> list) that are critical to TDE function (the way you want it to function)
> and
> just bring that code over to prevent all of this incompatibility
> frustration.
> I know I feel it -- when it feels like the rug has been pulled out from
> underneath you -- by some whacky upstream change.

Well, that is why I designed the TDE HW library to function on top of
procfs.  Based on historical record, the chances of procfs disappearing
from the kernel are much, much smaller than the chances of a u* package
radically changing or becoming deprecated.

> Following upstream is surely easier, but when you cannot count on them
> being
> there, that seems like a shaky foundation to build a house on...

Precisely.

> HAL, pmount, udisk, udisk2 is a good example of a constantly moving target
> where key functionality of TDE is at risk.

Yes, I agreem.  Note however that the pmount dependency is very small; TDE
only calls it as an external program, and the only thing that would break
if pmount were to disappear would be mounting of disk/media devices.

As you look at the code I have written over the past year, you can see I
have been attempting to abstract all of these functions into a simple,
easy-to-use, standardized TDE API that new (or old) applications can use
to easily gain access to information that is normally very difficult to
retrieve.  Another main function of this structure is to effectively
separate the (complex and prone to upstream breakage) backend code from
the user application code, obviating the need for full rewrites of TDE
applications code when upstream backends change.

Tim