Hi Martin,
On Sat, Nov 1, 2014 at 6:51 PM, Martin Mares wrote:
> The support for hwdb has finally landed in mainline pciutils.
>
> I have modified your patch to bring it closer to the rest of device
> naming logic. Namely:
Great! Thanks for merging this, and for working on it.
> Aside of the
Hi Martin,
On Sat, Nov 1, 2014 at 6:51 PM, Martin Mares m...@ucw.cz wrote:
The support for hwdb has finally landed in mainline pciutils.
I have modified your patch to bring it closer to the rest of device
naming logic. Namely:
Great! Thanks for merging this, and for working on it.
Aside of
Hi Tom!
The support for hwdb has finally landed in mainline pciutils.
I have modified your patch to bring it closer to the rest of device
naming logic. Namely:
• The interface to HWDB now lives in a separate source file
lib/names-hwdb.c. It is called from the main entry point
to
Hi Tom!
The support for hwdb has finally landed in mainline pciutils.
I have modified your patch to bring it closer to the rest of device
naming logic. Namely:
• The interface to HWDB now lives in a separate source file
lib/names-hwdb.c. It is called from the main entry point
to
Hi!
> Ping?
Sorry for the delay, I was alternatingly ill and overloaded with other stuff...
As I said before, I do not like the current implementation of hwdb much (it's
too much tied to Linux, and hardware description strings, originally intended
for internal use between the kernel and its
On Wed, Feb 12, 2014 at 8:58 PM, Martin Mares wrote:
> Hi!
>
>> Ping?
>
> Sorry for the delay, I was alternatingly ill and overloaded with other
> stuff...
No worries. I hope you are better now.
> As I said before, I do not like the current implementation of hwdb much (it's
> too much tied to
On Wed, Feb 12, 2014 at 8:58 PM, Martin Mares m...@ucw.cz wrote:
Hi!
Ping?
Sorry for the delay, I was alternatingly ill and overloaded with other
stuff...
No worries. I hope you are better now.
As I said before, I do not like the current implementation of hwdb much (it's
too much tied
Hi!
Ping?
Sorry for the delay, I was alternatingly ill and overloaded with other stuff...
As I said before, I do not like the current implementation of hwdb much (it's
too much tied to Linux, and hardware description strings, originally intended
for internal use between the kernel and its
Ping?
On Wed, Jan 29, 2014 at 5:13 PM, Tom Gundersen wrote:
> Ping?
>
> On 30 Dec 2013 19:53, "Tom Gundersen" wrote:
>>
>> Hi Martin,
>>
>> On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares wrote:
>> > I see that a mechanism for fast lookup of hardware identification data
>> > is needed. However,
Ping?
On Wed, Jan 29, 2014 at 5:13 PM, Tom Gundersen t...@jklm.no wrote:
Ping?
On 30 Dec 2013 19:53, Tom Gundersen t...@jklm.no wrote:
Hi Martin,
On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares m...@ucw.cz wrote:
I see that a mechanism for fast lookup of hardware identification data
is
Hi Martin,
On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares wrote:
> I see that a mechanism for fast lookup of hardware identification data
> is needed. However, why should such a mechanism depend on udev, systemd,
> or Linux in general?
>
> What I would really like to have is a universal library
Hi Martin,
On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares m...@ucw.cz wrote:
I see that a mechanism for fast lookup of hardware identification data
is needed. However, why should such a mechanism depend on udev, systemd,
or Linux in general?
What I would really like to have is a universal
On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares wrote:
>> It does that per process doing that, and that's the problem for how
>> udev works/worked. The binary hwdb is on-disk and can be mmaped, and
>> there is no difference between initialization, first, or subsequent
>> queries.
>
> OK, point
Hello!
> It does that per process doing that, and that's the problem for how
> udev works/worked. The binary hwdb is on-disk and can be mmaped, and
> there is no difference between initialization, first, or subsequent
> queries.
OK, point taken.
I see that a mechanism for fast lookup of
On Sun, Dec 15, 2013 at 10:18 AM, Martin Mares wrote:
> Hello Kay,
>
>> Libpci and its linear search through megabytes of text files for evey
>> new query is too inefficient, that we cannot afford to use it during
>> early bootup. It was the largest hit left in bootup profiling on
>> machines
Hello Kay,
> Libpci and its linear search through megabytes of text files for evey
> new query is too inefficient, that we cannot afford to use it during
> early bootup. It was the largest hit left in bootup profiling on
> machines booting userspace in the sub-1-second range on common
> machines.
Hello Kay,
Libpci and its linear search through megabytes of text files for evey
new query is too inefficient, that we cannot afford to use it during
early bootup. It was the largest hit left in bootup profiling on
machines booting userspace in the sub-1-second range on common
machines. It
On Sun, Dec 15, 2013 at 10:18 AM, Martin Mares m...@ucw.cz wrote:
Hello Kay,
Libpci and its linear search through megabytes of text files for evey
new query is too inefficient, that we cannot afford to use it during
early bootup. It was the largest hit left in bootup profiling on
machines
Hello!
It does that per process doing that, and that's the problem for how
udev works/worked. The binary hwdb is on-disk and can be mmaped, and
there is no difference between initialization, first, or subsequent
queries.
OK, point taken.
I see that a mechanism for fast lookup of hardware
On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares m...@ucw.cz wrote:
It does that per process doing that, and that's the problem for how
udev works/worked. The binary hwdb is on-disk and can be mmaped, and
there is no difference between initialization, first, or subsequent
queries.
OK, point
On Sun, Dec 15, 2013 at 1:23 AM, Tom Gundersen wrote:
>> Also, did you consider the opposite, that is making hwdb call libpci
>> to resolve PCI IDs? What are the downsides?
>
> Well, part of the reason for introducing the hwdb was to avoid libpci for
> performance reasons (I added Kay in cc who
On Sun, Dec 15, 2013 at 1:23 AM, Tom Gundersen t...@jklm.no wrote:
Also, did you consider the opposite, that is making hwdb call libpci
to resolve PCI IDs? What are the downsides?
Well, part of the reason for introducing the hwdb was to avoid libpci for
performance reasons (I added Kay in cc
Hello and sorry for the delay,
> >> + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ]
> >> ; then
> >> + HWDB=yes
> >> + else
> >> + HWDB=no
> >> + fi
> >
> > Does this make sense? Does every version of libudev support hwdb?
>
> Good
Hello and sorry for the delay,
+ if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ]
; then
+ HWDB=yes
+ else
+ HWDB=no
+ fi
Does this make sense? Does every version of libudev support hwdb?
Good point. I'll replace it with a
On Fri, Sep 13, 2013 at 1:08 PM, Tom Gundersen wrote:
> On Wed, Sep 4, 2013 at 4:59 PM, Tom Gundersen wrote:
>> On Wed, Sep 4, 2013 at 3:57 PM, Martin Mares wrote:
>>> Hello!
>>>
>>> First of all: Sorry for not replying to the first mail. I do not follow
>>> linux-pci too much these days (or, I
On Fri, Sep 13, 2013 at 1:08 PM, Tom Gundersen t...@jklm.no wrote:
On Wed, Sep 4, 2013 at 4:59 PM, Tom Gundersen t...@jklm.no wrote:
On Wed, Sep 4, 2013 at 3:57 PM, Martin Mares m...@ucw.cz wrote:
Hello!
First of all: Sorry for not replying to the first mail. I do not follow
linux-pci too
On Wed, Sep 4, 2013 at 4:59 PM, Tom Gundersen wrote:
> On Wed, Sep 4, 2013 at 3:57 PM, Martin Mares wrote:
>> Hello!
>>
>> First of all: Sorry for not replying to the first mail. I do not follow
>> linux-pci too much these days (or, I do that in big batches).
>
> No problem, I guessed as much.
>
On Wed, Sep 4, 2013 at 4:59 PM, Tom Gundersen t...@jklm.no wrote:
On Wed, Sep 4, 2013 at 3:57 PM, Martin Mares m...@ucw.cz wrote:
Hello!
First of all: Sorry for not replying to the first mail. I do not follow
linux-pci too much these days (or, I do that in big batches).
No problem, I
On Wed, Sep 4, 2013 at 3:57 PM, Martin Mares wrote:
> Hello!
>
> First of all: Sorry for not replying to the first mail. I do not follow
> linux-pci too much these days (or, I do that in big batches).
No problem, I guessed as much.
>> This lets you select hwdb support at compile time.
>>
>>
Hello!
First of all: Sorry for not replying to the first mail. I do not follow
linux-pci too much these days (or, I do that in big batches).
> This lets you select hwdb support at compile time.
>
> hwdb is an efficient hardware database shipped with recent versions of udev.
> It contains among
This lets you select hwdb support at compile time.
hwdb is an efficient hardware database shipped with recent versions of udev. It
contains
among other sources pci.ids so querying hwdb rather than reading pci.ids
directly should give
the same result.
Ideally Linux distros using udev could stop
This lets you select hwdb support at compile time.
hwdb is an efficient hardware database shipped with recent versions of udev. It
contains
among other sources pci.ids so querying hwdb rather than reading pci.ids
directly should give
the same result.
Ideally Linux distros using udev could stop
Hello!
First of all: Sorry for not replying to the first mail. I do not follow
linux-pci too much these days (or, I do that in big batches).
This lets you select hwdb support at compile time.
hwdb is an efficient hardware database shipped with recent versions of udev.
It contains among
On Wed, Sep 4, 2013 at 3:57 PM, Martin Mares m...@ucw.cz wrote:
Hello!
First of all: Sorry for not replying to the first mail. I do not follow
linux-pci too much these days (or, I do that in big batches).
No problem, I guessed as much.
This lets you select hwdb support at compile time.
34 matches
Mail list logo
