trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: August 2012

Re: [trinity-devel] Tim: TDEHWLIB

From: "David C. Rankin" <drankinatty@...>
Date: Mon, 27 Aug 2012 12:58:09 -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.

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...

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

I don't know if this even makes sense to do, but it just seems like TDE should 
pick the one it wants to dance with, and stick with it.

The inevitable downside of course is that there is some break at some point in 
the future (kernel or otherwise) that would make this solution not work, but 
it looks like doing it this was would allow you to recode once (whenever a 
major shift occurred) as opposed to recoding over-and-over for every little 
change in upstream personality (HAL, udisk, udisk2, pmount, ...)

Just food for thought for the smart folk.

-- 
David C. Rankin, J.D.,P.E.