tir, 30.11.2004 kl. 14.25 skrev Avi Alkalay: > For people that still don't know the Elektra Project > (http://elektra.sourceforge.net), it provides an alternative back-end > for text configuration files. So instead, for example, the > human-readable-only xorg.conf file, we'll have a hierarchy of > key/value pairs easily and precisely accessible by X.org and also any > other programs through an API or command, and human beings too. > Same concept as GConf, but designed for system-wide use. > > We've been working on X.org source code to do exactly what we just > described above. And it is ready for use, tested even with very > complex X.org configurations. A patched X server will convert your > xorg.conf file automatically, even the most complex ones, including > non-documented parameters. > > It is available at > http://sourceforge.net/project/showfiles.php?group_id=117521 > http://sourceforge.net/project/showfiles.php?group_id=117521&package_id=136552 > > You'll find there the patch against X.org source, the patch against > Fedora Core 3 RPM spec file (to see how to build it), and the README > file, which is pasted in this e-mail bellow. > > We'll write patches for other software, and everybody is invited to > join this integration effort. > > Thank you, > Avi Alkalay > Elektra Project <http://elektra.sf.net> > > ----------------------README------------------------- > ELEKTRIFIED X.ORG: PRECISE AND PROGRAMATICALY EASY X CONFIGURATION > > Your X server has to work with your installed video card, monitor, find > your font server and dirs, modules, extensions, drivers, plugins. > You have to tell him how to integrate it all through its xorg.conf file. > If you need to change something, you start a text editor and use your > human brain and eyes to find the correct line, understand it, have the > skills to change it, and change it in order to work. > > This is good for advanced technical guys, but very bad for people that > don't have this skills, and in fact, don't really want to. He just > wants to change the screen resolution to make that projector work with his > laptop, and go ahead with his sales presentation. This is just an example. > > The point is: it is very difficult to make simple programs or scripts > that make simple changes to X configuration. Another example is a monitor > vendor that wants to support X, and for this he'd like to provide easy > installation of his product, without having to ask his user to read > documentation about horizontal Sync, and vertical refresh rates. For him > again is difficult to write some simple software that preciselly changes X > configuration to work correctly with his product. > > The xorg.conf file (as most Unix configuration files) was designed for > human beings. > > The Elektra Project (http://elektra.sourceforge.net) introduces a new way > to handle configurations through a clean API (or command line > tool) that accesses atomic configuration data, into a standarized > hierarchycal tree of key-value pairs. It is similar to GConf, but > designed for system-wide use, which also implies it does not have > dependencies. > > And this is what this patch is about: to make the X server look for its > configurations into a machine-ready tree of key-value pairs, instead of > the human-ready xorg.conf. > > So where you had to look for "Device radeon" into a "Section Device", > with the key/value tree, X and other programs can look for it > preciselly at > > system/sw/xorg/current/Devices/Videocard0/Driver = radeon > > > Where you once had to "vi" your "Section Monitor", now X and other > programs can do it accessing the keys: > > system/sw/xorg/current/Monitors/Monitor0/HorizSync = 31.5 - 48.5 > system/sw/xorg/current/Monitors/Monitor0/VertRefresh = 40.0 - 70.0 > system/sw/xorg/current/Monitors/Monitor0/ModelName = IBM T40 LCD Panel > system/sw/xorg/current/Monitors/Monitor0/VendorName = IBM > system/sw/xorg/current/Monitors/Monitor0/Options/dpms > > > Where once the salesman above had to "vi" the Screen Section to change > the resolution, color depth, etc, a program can help him accessing: > > system/sw/xorg/current/Screens/Screen0/Displays/00/Depth=24 > system/sw/xorg/current/Screens/Screen0/Displays/00/Modes=1024x768 > > > And so on.... > > We believe an elektrified X server can leverage more plug-and-play > configurations, providing configuration power to HW vendors in a > very simple way, and making users experience less painfull. > > > > > > > BEHAVIOR OF AN ELEKTRIFIED X SERVER > > A patched X server will look for its configuration keys under the > namespace: > > system/sw/xorg/current first, then if not found it tries > system/sw/xorg > > If not found, it will default to some xorg.conf file, parse it, and store > in its internal structures, then convert and commit it to a set of > keys under system/sw/xorg/current, and reload these keys. > > So you get automatic one-time conversion from xorg.conf to the > hierarchycal configuration key/value pairs > > Very complex examples of xorg.conf files were tested for conversion. Even > undocumented configuration parameters (because the original source was > used as the reference). > > The Elektrifyied X server also works for the Red Hat Graphical Boot, > where you still don't have mounted partitions, network, etc. > > > > > > ELEKTRIFING X.ORG > > You'll need the elektra-devel package installed in order to build X with > Elektra support. > > 1. Download and unpack X.org source code from > 2. Download the xorg-x11-6.8.1-elektra.patch file from > http://sourceforge.net/project/showfiles.php?group_id=117521&package_id=136552 > 3. Apply it: > ~/src/xc$ cd .. > ~/src$ patch -p0 < xorg-x11-6.8.1-elektra.patch > ~/src$ cd xc > ~/src/xc$ # ...configure your build in host.def > 4. Enable the patch: > ~/src/xc$ echo "#define UseElektra" >> config/cf/host.def > 5. Build X.Org > > You'll find the new X server as file xc/programs/Xserver/Xorg . > > The patch will add the following files: > > xc/programs/Xserver/hw/xfree86/parser/ > elektra.h (exported methods) > elektra.c (key fetching and X structs integration business logic) > xorg-example.conf (a very complex conf file to test conversion) > xelektrify.c (cmd to convert xorg.conf->keys and vice-versa) > README.Elektra (this file) > > And it will instrument > xc/programs/Xserver/hw/xfree86/common/xf86Config.c::xf86HandleConfigFile() > to trigger the one-time conversion, and key fetching logic. > > And instrument the Imakefiles for correct builds: > > xc/programs/Xserver/hw/xfree86/parser/Imakefile > xc/programs/Xserver/hw/xfree86/common/Imakefile > xc/programs/Xserver/Imakefile > > If "#define UseElektra" is not present in host.def, the patch is > completelly disabled, and you'll get a binary-identicall built as before > applying the patch. All patched code are surrounded by #ifdefs. > > > > > > ELEKTRA MEETS X.ORG SOURCE CODE > or how we wrote the patch.... > > X.org has an xorg.conf parser that takes this steps to handle > configuration: > > 1. Lexically parse the xorg.conf file > 2. Put each Section info in an equivalent struct > 3. Encapsulate all structs together and pass them to a validator > 4. Use structs to define X behavior > > This process is triggered by the xf86HandleConfigFile() method from > > xc/programs/Xserver/hw/xfree86/common/xf86Config.c > > Each xorg.conf Section has an equivalent structure defined in > > xc/programs/Xserver/hw/xfree86/parser/xf86Parser.h > > and the lexycall analyzer code to parse each Section is under > > xc/programs/Xserver/hw/xfree86/parser/ > > A fully parsed file has its equivalent structures encapsulated in a > parent XF86Config struct. We have: > > struct XF86ConfModuleRec for the "Section Modules" > struct XF86ConfMonitorRec for the "Section Monitor" > struct XF86ConfDeviceRec for the "Section Device" > etc... > > These structs are a pure computer representation of the text in each > Section, so the methods under "parser/" convert text to structs, and > the structs to text. This is how original X.org source handles xorg.conf. > > The Elektrification add methods that act in steps 1 and 2 above. And also > include methods to convert each struct to a KeySet. Both old (xorg.conf) > and new (Elektra) ways to get configuration information can live together > and they are actually used to automatically convert xorg.conf to keys. So > at the first time you'll run your elektrified X server, it will: > > 1. Not find configuration keys (because it is the first time) > 2. Parse xorg.conf into structs > 3. Convert structs to Keys > 4. Commit the keys to key database > 5. Reload configurations from the key database > > See the behavior in the previous section. > > After assembling the XF86Config C structure, X will decode all its info > into more practicall parameters for its further operation. > > As a side note, with a key/value pair configuration hierarchy paradigm, > the XF86Config assembling code (the parser) could be avoided, making X > look for its configurations in a programatically easier, yet > human-readable, configuration organization. > We worked at the parser level to keep compatibility and to not go too > deep in X.org source code. > > > http://elektra.sourceforge.net > The Elektra Project > Avi Alkalay > November 2004 While i am all for the *idea*, what happens if your X11 server breaks down and you *have* to use VIM to "save" it? While i am not opposed to creating an easily learned api for config-file configuration, i am *strongly* opposed to not be able to hack into that xorg.conf file from a crude command line (hell, i have vim'ed config files with /bin/bash as my init process and a half borked kernel that would boot 1/5 times...). I don't want my config's to be put all in the hands of some program, to *have* to use a config program (with all the odds and ends it migth have...) in order to fix a broken config. Now imagine that program needed another program, which needed a service wich needed ... the thing you where just trying to fix. Kyrre
