[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: hal draft spec



On Thu, 2003-09-11 at 01:00, George wrote:
> On Thu, Sep 11, 2003 at 12:28:02AM +0200, David Zeuthen wrote:
> >   <set key="Vendor" value="SomeVendor">
> >   <set key="Vendor[da]" value="TheDanishNameOfTheVendor">
> 
> This is a little evil.  Note that AFAIK it presents lots of problems to
> put actual text inside attributes.  What would be wrong with:
> 
> <Vendor>SomeVendor</Vendor>
> <Vendor xml:lang="da">TheDanishNameOfTheVendor</Vendor>
> 
> That's both more XMLish and I find it more logical or perhaps a bit closer to
> your version:
> 
> <set key="Vendor">SomeVendor</set>
> <set key="Vendor" xml:lang="da">TheDanishNameOfTheVendor</set>
> 
> > This should be easy to parse. It's probably pretty inefficient too in
> > terms of storage and driver searching cost due to the quite simple
> > format yielding many drivers :-) 
> 
> That's just the ondisk format, that can be inefficient.  Plus I doubt
> you'll notice unless there's way too many entries.
> 
> > And it's probably useful to look into the discover format from Progeny -
> > they have done quite some thinking on device-info files.
> 
> That's probably worth some investigation ...
> 
> George

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):

        <deviceinfo version="0.1">
        
          <match>
            <and>
              <equal>
                <key>Bus</key>
                <value>usb</value>
              </equal>
            
              <equal>
                <key>usb.idVendor</key>
                <value>5dc</value>
              </equal>
            
              <equal>
                <key>usb.idProduct</key>
                <value>2</value>
              </equal>
        
              <equal>
                <key>usb.bcdDevice</key>
                <value>1</value>
              </equal>
            </and>
          </match>
        
          <merge>
            <set>
              <key>DeviceInfoFileIdentifier</key>
              <value>dk.fubar:LexarCFReader</value>
            </set>
            <set>
              <key>DeviceInfoFileAuthor</key>
              <value>David Zeuthen, david fubar dk</value>
            </set>
            <set>
              <key>Vendor</key>
              <value>Lexar</value>
            </set>
            <set>
              <key>Product</key>
              <value>Compact Flash Reader</value>
            </set>
            <set>
              <key>Category</key>
              <value>Storage</value>
            </set>
            <set>
              <key>BootProgram</key>
              <value>/bin/true; env; /bin/true; /bin/true</value>
            </set>
            <set>
              <key>ShutdownProgram</key>
              <value>/bin/true</value>
            </set>
            <set>
              <key>RequireDisable</key>
              <value>true</value>
            </set>
            <set>
              <key>Persistent</key>
              <value>true</value>
            </set>
        
            <if>
              <or>
                <equal>
                  <key>OS.kernel</key>
                  <value>FreeBSD</value>
                </equal>
                <equal>
                  <key>OS.kernel</key>
                  <value>OpenBSD</value>
                </equal>
                <equal>
                  <key>OS.kernel</key>
                  <value>NetBSD</value>
                </equal>
              </or>
              <then>
                <set>
                  <key>SomeOSValue</key>
                  <value>foo</value>
                </set>
              </then>
            </if>
        
            <if>
              <equal>
                <key>OS.kernel</key>
                <value>Linux</value>
              </equal>
              <then>
                <set>
                  <key>SomeOSValue</key>
                  <value>bar</value>
                </set>
              </then>
            </if>
        
          </merge>
        
        </deviceinfo>
        

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.

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.

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

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?

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

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.

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)

Thanks,
David




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]