Proposed F19 Feature: systemd features

Kay Sievers kay at vrfy.org
Wed Jan 30 10:55:36 UTC 2013


On Wed, Jan 30, 2013 at 11:42 AM, Gerd Hoffmann <kraxel at redhat.com> wrote:
> On 01/30/13 01:08, Kay Sievers wrote:
>> On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham <notting at redhat.com> wrote:
>>> Kay Sievers (kay at vrfy.org) said:
>>>>> Realistically, it's new textual files, replacing old textual files, which
>>>>> are then compiled into a binary file. I'm not sure why there's the
>>>>> intermediate step of a second textual format, but there is.
>>>>
>>>> Because the original text file is a hack and a format specific to the
>>>> PCI/USB IDs, and makes no sense at all for a generic hwdb.
>>>
>>> pci:v00000010*
>>>  ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc
>>>
>>> It's not like that's that much more of a generic format. :)
>>
>> It is entirely generic. It can carry arbitrary numbers of freely named
>> key/value pairs basically unlimited in their size. Is extensible, uses
>> flexible and extensible string matches like modaliases for kernel
>> modules. Nothing you would find in the PCI/USB IDs hack.
>>
>> So what do you criticize here?
>
> Still looks pointless.
>
> You convert the old-format into new-format, then compile new-format into
> the database.  It's not obvious why you don't go straight from
> old-format to the database.  hwdata package updates would directly show
> up in the database then, without having to touch systemd.

It's as pointless as shipping a parser for a foreign and irrelevant
format in the hwdb code.

And it is as pointless as adding weird code and ./configure stuff
again to udev to find these files in the place of the month, where
some distro poeple decided again where to put it, and every distro in
a different place, with different names or file types.

And it is as pointless as inventing magic rules in the hwdb to
overwrite the old files with possibly new data shipped in the new
format.

We don't want to pointlessly do any of that. Also, the textual strings
are just one, and not the interesting part of the hwdb, and all should
be uniform and not pull in some not convincing legacy formats, or
weird rules how things are located and overwritten.

Kay


More information about the devel mailing list