Re: [Lxde-list] Some udev related docs

It's more correct to say two things:
Your dependency is (the userspace library) libudev, not (the daemon) udevd.
The DeviceKit developers view libudev as the way forward for information that libudev provides. They viewed DeviceKit as duplicative and redundant for those areas. HAL was a V1 product that had severe limitations and instead of trying to fix it, they rewrote it into what is replacing it. I agree with that choice. (Someone who is rewriting pcmanfm might agree also that sometimes it is better to scrap what you have and start over.) Thus, the new design is that you should plan to use the combination of libudev, ConsoleKit, UPower in the future.
There are a few other areas where Linux is diverging from the other players, let us say FreeBSD and OpenSolaris. One other is kernel mode setting. The Intel driver has dropped support for user mode setting in its latest release. The result is only that if you are on a non-Linux platform, you are stuck on an older release. The other platform can recover from this by implementing the necessary features, the same as it can recover from the point you raise by implementing a libudev that acts properly. If there is sufficient interest in the non-Linux platform, they eventually will. If not, they may not.
So, the "from now on" prediction is overly pessimistic, given that non-Linux platforms can add the needed things. You are correct that if you want to run on Linux, you have to use the new stuff.
On 02/28/2010 07:38 AM, PCMan wrote:
> The upstream developers of HAL and devicekit are removing HAL along
> with many required features.
> They removed old features we needed from HAL, but refused to add them
> back in deviceKit.
> So, unfortunately, we have to directly use udev and back to the time
> when there is no corss-platform solution.
> For Linux-only solution, I found the documentation written by XFCE
> developer useful.
>
> http://wiki.xfce.org/dev/thunar-volman-udev
>
> For developers building hardware-related lxde components, read this.
> Linux-only is not a problem since the only cross-platform solution,
> HAL, is killed by upstream developer and it's impossible for BSD or
> others to have udev.
> It's a pain but we have no choices. Although theoratically free
> software is all about choices, but now we're left with no other
> choice.
> So let's face it. Writing Linux-only code, unfortunately, is
> inevitable from now on.
>
> Sigh...
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Lxde-list mailing list
> Lxde-list@...
> https://lists.sourceforge.net/lists/listinfo/lxde-list
>

Thread view

The upstream developers of HAL and devicekit are removing HAL along
with many required features.
They removed old features we needed from HAL, but refused to add them
back in deviceKit.
So, unfortunately, we have to directly use udev and back to the time
when there is no corss-platform solution.
For Linux-only solution, I found the documentation written by XFCE
developer useful.
http://wiki.xfce.org/dev/thunar-volman-udev
For developers building hardware-related lxde components, read this.
Linux-only is not a problem since the only cross-platform solution,
HAL, is killed by upstream developer and it's impossible for BSD or
others to have udev.
It's a pain but we have no choices. Although theoratically free
software is all about choices, but now we're left with no other
choice.
So let's face it. Writing Linux-only code, unfortunately, is
inevitable from now on.
Sigh...

It's more correct to say two things:
Your dependency is (the userspace library) libudev, not (the daemon) udevd.
The DeviceKit developers view libudev as the way forward for information that libudev provides. They viewed DeviceKit as duplicative and redundant for those areas. HAL was a V1 product that had severe limitations and instead of trying to fix it, they rewrote it into what is replacing it. I agree with that choice. (Someone who is rewriting pcmanfm might agree also that sometimes it is better to scrap what you have and start over.) Thus, the new design is that you should plan to use the combination of libudev, ConsoleKit, UPower in the future.
There are a few other areas where Linux is diverging from the other players, let us say FreeBSD and OpenSolaris. One other is kernel mode setting. The Intel driver has dropped support for user mode setting in its latest release. The result is only that if you are on a non-Linux platform, you are stuck on an older release. The other platform can recover from this by implementing the necessary features, the same as it can recover from the point you raise by implementing a libudev that acts properly. If there is sufficient interest in the non-Linux platform, they eventually will. If not, they may not.
So, the "from now on" prediction is overly pessimistic, given that non-Linux platforms can add the needed things. You are correct that if you want to run on Linux, you have to use the new stuff.
On 02/28/2010 07:38 AM, PCMan wrote:
> The upstream developers of HAL and devicekit are removing HAL along
> with many required features.
> They removed old features we needed from HAL, but refused to add them
> back in deviceKit.
> So, unfortunately, we have to directly use udev and back to the time
> when there is no corss-platform solution.
> For Linux-only solution, I found the documentation written by XFCE
> developer useful.
>
> http://wiki.xfce.org/dev/thunar-volman-udev
>
> For developers building hardware-related lxde components, read this.
> Linux-only is not a problem since the only cross-platform solution,
> HAL, is killed by upstream developer and it's impossible for BSD or
> others to have udev.
> It's a pain but we have no choices. Although theoratically free
> software is all about choices, but now we're left with no other
> choice.
> So let's face it. Writing Linux-only code, unfortunately, is
> inevitable from now on.
>
> Sigh...
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Lxde-list mailing list
> Lxde-list@...
> https://lists.sourceforge.net/lists/listinfo/lxde-list
>

On Sun, Feb 28, 2010 at 10:20 PM, Marty Jack <martyj19@...> wrote:
> It's more correct to say two things:
>
> Your dependency is (the userspace library) libudev, not (the daemon) udevd.
>
> The DeviceKit developers view libudev as the way forward for information that libudev provides. They viewed DeviceKit as duplicative and redundant for those areas. HAL was a V1 product that had severe limitations and instead of trying to fix it, they rewrote it into what is replacing it. I agree with that choice. (Someone who is rewriting pcmanfm might agree also that sometimes it is better to scrap what you have and start over.) Thus, the new design is that you should plan to use the combination of libudev, ConsoleKit, UPower in the future.
Since we're going to use libudev directly, what's the point in
providing upower as dbus service?
I don't understand this quite well.
> There are a few other areas where Linux is diverging from the other players, let us say FreeBSD and OpenSolaris. One other is kernel mode setting. The Intel driver has dropped support for user mode setting in its latest release. The result is only that if you are on a non-Linux platform, you are stuck on an older release. The other platform can recover from this by implementing the necessary features, the same as it can recover from the point you raise by implementing a libudev that acts properly. If there is sufficient interest in the non-Linux platform, they eventually will. If not, they may not.
Well, just like we don't like to fight with backward incompatibilities
and we don't like to be forced to use new solutions, those developers
on other platforms don't like to be forced to adopt Linux technology
everytime. So I think this is a technical + political issue, which is
hard to solve. Some abstraction + encapsulation + per-platform backend
is still needed here.
> So, the "from now on" prediction is overly pessimistic, given that non-Linux platforms can add the needed things. You are correct that if you want to run on Linux, you have to use the new stuff.
Maybe we can have our own wrapper lib?.
> On 02/28/2010 07:38 AM, PCMan wrote:
>> The upstream developers of HAL and devicekit are removing HAL along
>> with many required features.
>> They removed old features we needed from HAL, but refused to add them
>> back in deviceKit.
>> So, unfortunately, we have to directly use udev and back to the time
>> when there is no corss-platform solution.
>> For Linux-only solution, I found the documentation written by XFCE
>> developer useful.
>>
>> http://wiki.xfce.org/dev/thunar-volman-udev
>>
>> For developers building hardware-related lxde components, read this.
>> Linux-only is not a problem since the only cross-platform solution,
>> HAL, is killed by upstream developer and it's impossible for BSD or
>> others to have udev.
>> It's a pain but we have no choices. Although theoratically free
>> software is all about choices, but now we're left with no other
>> choice.
>> So let's face it. Writing Linux-only code, unfortunately, is
>> inevitable from now on.
>>
>> Sigh...
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Lxde-list mailing list
>> Lxde-list@...
>> https://lists.sourceforge.net/lists/listinfo/lxde-list
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Lxde-list mailing list
> Lxde-list@...
> https://lists.sourceforge.net/lists/listinfo/lxde-list
>

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details