hal draft spec

[Dave Malcolm]

On Mon, 2003-09-22 at 22:37, David Zeuthen wrote:

[snip]

> 
> I'm currently looking into implementing this in HAL so I sat down to
> define the format tonight. I ended up with something like (big listing
> ahead):

[snip]

(Hope this email makes sense; it's got quite late since I started
writing it)

Perhaps all the <value> tags should be expressed with a more
strongly-typed format.  We could then write a schema that would mean we
could automatically validate deviceinfo files to stop certain kinds of
error.

Perhaps things like:
	<value type="boolean">
	<value type="translatable-string">

Or somesuch.  It also gives people writing XML editors (like me) a
chance to provide appropriate widgets.


> Most fields are obvious I hope. There is a <match> section to determine
> if a device matches and a <merge> section for merging properties. The
> former uses AND and OR to test properties. If the so formed statement
> evaluates to TRUE the device is identified and we proceed to the <merge>
> section.

If I understand this correctly, you have an object with a load of
key-value mappings, and you test if the device-info matches it.  You can
then add a load more key-value mappings containing the extra information
that the device-info file has told you. 

Since the keys and values have changed, do you now have to re-test the
object against all device-info files, in case it now matches some of the
other ones (including the ones you might have tested already)?


> The <merge> also uses <if> tags to test for different OS'es.
> 
> Note that instead of using the <equal> tag (meaning the property with
> that key must have that exact value) one could use tags that interpreted
> the value as a hex-number, decimal-number or version-number
> (major.minor.sub) and used ranges to check on. regexp tags could be
> introduced as well.

Aha - good.  Then we get validation etc as I mentioned above.

> 
> So, I quickly realized that if I added a <while> tag I would have my own
> little programming language.. 

Yes, but if you don't need such a tag don't add one! :-)

> 
> Now, no one should have to create programming languages for matching
> devices and device info files!

> So, in the best interest of using existing widely-deployed technology it
> would be good to use existing languages. The device-info files could
> perhaps be python scripts?

Or you could have an xml tag that invoked an external script, perhaps
something like this:
<match>
	<and>
		<external-script 
			filename="test-for-frobnicator.sh"
			needs-root="no"/>
		<internal-script lang="python">
some stuff here:
	and now we get into 
		horrible whitespace arguments</internal-script>
	</and>
</match>

XML gives you validation, and lets you use stylesheets as a query
language to autogenerate various kinds of useful report (e.g. "find all
USB drivers, make a table of them displaying the vendor/product IDs
along with their names in German") if you're that way inclined.

It lets you put metadata into the file that can be accessed without
having to execute the file.

You could also do neat stuff like embed SVG icons in the <device-info>
file.

> 
> Security considerations? Well, if we stayed with XML the malicious
> attacker could just put rouge code in BootProgram, so installing device
> info files would require root privileges anyway.. We could run the
> scripts as nobody and in chroot jail

With the XML approach the attacker can only do bad stuff in the
device-info file after it has been matched, and only in certain ways. 
With an arbitrary programming language the attacker can put bad stuff
into the device-info file at the matching stage: there's no way to
separate the match from the merge - you're just calling some script.

With the XML approach, you can download a device-info file (perhaps
automatically) and test if it's appropriate to your hardware without
needing any privileges.

Also, distributors could provide a web service which runs on a server
and can determine which device-info is appropriate.  If a user plugs
something unrecognised into their computer, the web service could be
invoked, and then the server can do the device-info match, and suggest a
package to the user.  I believe this would be much easier to do using an
XML approach than with scripts.

> Footprint? Only hald and applications wanting to assist users in
> selecting / composing device info files would link with this. Not libhal
> applications.
> 
> Performance? Good question.. In the worst case we would have to traverse
> all device info scripts whenever a new device is inserted. There may be
> thousands of there.

If you parse all the device-info XML files into a specialised in-memory
representation, and keep this around (at a cost of perhaps a k per
device-info file), then the pure XML approach is faster - you've got the
parse tree of all the programs to hand and you just walk them.  

Easier to code is to simply keep the DOM tree of the XML, which might
cost perhaps a few k per device-info file, and is somewhat more
expensive to walk.

Plus you can do the kinds of queries I mentioned above.

> 
> I guess, first of all we would embed the python interpreter and extend
> it with an object that the scripts access. 
> 
> Second, the scripts would terminate rather quickly since they do trivial
> tests in the beginning. Does anyone have any numbers on this?
> 
> Let me know what you guys think. Is it too much to embed a script
> interpreter in hald or too ugly not to use something as standard and
> accepted as XML?
> 
> (Python is of course just an example, but I like Python)

As you may have guessed, I like XML :-)

> 
> Thanks,
> David
> 
> 
> _______________________________________________
> Xdg-list mailing list
> Xdg-list at freedesktop.org
> https://www.redhat.com/mailman/listinfo/xdg-list
-- 
David Malcolm
www.conglomerate.org