BeOS drivers are allowed to open files, but there are a few reasons why you don't want to do this to read settings. For one thing, if your driver is loaded before the file system, you can't open your settings file. If the boot volume's disk driver needs information from the settings file before it can access the disk, just opening a file won't work. Also, parsing settings files can be complicated by corrupt files, and a crash in driver code is fatal.

The next BeOS release will have an API for drivers and kernel modules to get settings. The API includes easy access to Boolean and string settings, and is available for all drivers and modules. For complex settings, a call is provided that returns the settings as a tree of parameters and values. The boot loader reads the settings files from the selected boot volume and passes them to the kernel for use by drivers. The boot loader also lets the user append settings at boot time. A line of the form "filename:parameters" in the advanced safemode menu will add "parameters" to the end of the specified settings file. This can be used to change debugging information, and to test different options on hardware where the driver doesn't work. For beta testers, all this should already work in 4.1b3.

The functions are defined as follows:

void* load_driver_settings(const char *drivername);

status_t unload_driver_settings(void *handle);

const char* get_driver_parameter(void* handle,
                                 const char* keyname,
                                 const char* unknownvalue,
                                 const char* noargvalue);

bool get_driver_boolean_parameter(void* handle,
                                  const char* keyname,
                                  bool unknownvalue,
                                  bool noargvalue);

const driver_settings* get_driver_settings(void* handle);

• drivername is the name of the settings file and should match the name of the driver.

• handle is the handle returned from load driver settings.

• keyname is the parameter name to search for in the file.

• unknownvalue is the value to return if the key is not found.

• noargvalue is the value to return if the key is found but no value is specified.

A driver calls load_driver_settings() with the name of the settings file as the argument.

settingshandle = load_driver_settings(drivername);

This returns a handle that is passed to the other driver settings functions. The driver can look for specific parameters by calling get_driver_parameter() and get_driver_boolean_parameter(), or it can get a pointer to the parsed settings from get_driver_settings(). When the settings have been processed, unload_driver_settings() will free the resources.

Let's look a simple example first. A driver "sample1" has one setting, "foo", that can be true or false. To specify the value of "foo", a line of form "foo value" is placed in the settings file. If there is no entry for "foo" in the file, the default is false; if there is an entry "foo" but no value is specified, we assume the value is true. The code for our example looks like this:

void *settingshandle;
bool foo;
settingshandle = load_driver_settings("sample1");

foo = get_driver_boolean_parameter(settingshandle, "foo",
                                   false, true);

unload_driver_settings(settingshandle);

Now let's look at how this works. If there is no settings file named "sample1" in ~/config/settings/kernel/drivers/, load driver settings will return NULL. Since we pass NULL to get_driver_boolean_parameter() it will return the value we specified for no entry: false. "foo" will therefore be false.

If the file exists, but doesn't contain an entry "foo", the result is the same. In this case, we get a valid handle and get_driver_boolean_parameter() will look for a "foo" parameter in the file. Since the file doesn't contain "foo", it returns false as requested.

If the file contains one line starting with "foo", the second word in this line is used as the value. If no value is specified, get_driver_boolean_parameter() will return the last argument passed. If a value is specified and is one of the strings "1", "true", "yes", "on", "enable", or "enabled", true will be returned. If the value is "0", "false", "no", "off", "disable", or "disabled", false is returned. If the value doesn't match any of these strings it is treated the same as if no entry was found; in this case, false.

If more than one line in the file starts with "foo", the last one is used. This allows the user to override settings from the boot loader.

Another simple case is when a driver has a string setting.

void *settingshandle;
const char *string;

settingshandle = load_driver_settings("sample1");

string = get_driver_parameter(settingshandle, "string",
                              NULL, "default");

unload_driver_settings(settingshandle);

This works the same way as get_driver_boolean_parameter(), except that the string value of string is returned instead of the logical value. If the file doesn't exist, or exists but has no line starting with "string", string will be NULL. If the last line starting with "string" has no values, string will be "default". If string has a value, it is returned as a string. Note that only one value is returned. If more than one value is needed for a key, use get_driver_settings() and search for your key.

For drivers that need complex settings, the get_driver_settings() will return the settings file as a tree. This tree allows a parameter to have multiple values and subparameters.

The following structure holds the root of the tree.

typedef struct driver_settings {
    int parameter_count;
    struct driver_parameter *parameters;
} driver_settings;

Each parameter is of the form:

typedef struct driver_parameter {
    char *name;
    int value_count;
    char **values;
    int parameter_count;
    struct driver_parameter *parameters;
} driver_parameter;

The settings file follows these rules:

• The file consists of parameters and comments.

• When a word starting with a '#' character is found, the rest of the line is treated as a comment.

• A parameter can have values and subparameters. A parameter has the following form in the settings file:

  name [value]* [{
  [parameter]*
  }] ['\n',',']
  

  ( [] optional part, []* optional repeated part )

• Names and values may not contain spaces unless they are preceded by a '\' or enclosed in quotes.

Here's an example that clarifies these points. For the file:

device 0 {
    attribute1 value
    attribute2 value
}
device 1 {
    attribute1 value
}

get_driver_settings() will return a pointer to the following tree:

driver settings = {
  parameter count = 2
  parameters = {
    {
      name = "device"
      value count = 1
      values = { "0" }
      parameter count = 2
      parameters = {
        {
          name = "attribute1"
          value count = 1
          values = "value"
          parameter count = 0
          parameters = NULL
        },
        {
          name = "attribute2"
          value count = 1
          values = "value"
          parameter count = 0
          parameters = NULL
        }
      }
    },
    {
      name = "device"
      value count = 1
      values = { "1" }
      parameter count = 1
      parameters = {
        {
          name = "attribute1"
          value count = 1
          values = "value"
          parameter count = 0
          parameters = NULL
        }
      }
    }
  }
}

Our thanks to the developers who attended last weekend's BeDC. It was great to meet you and to pass on our Media Kit knowledge to you. We promised you some sample code RealSoonNow(tm) at the conference, so here's the first delivery.

In the Node Track session, we presented a new class—the MotherNode -- as a work in progress for the next release. This class helps manage the events your node needs to handle. It's another virtual BMediaNode subclass, so you can mix it with all the other classes: BBufferConsumer, BBufferProducer, BControllable, BFileInterface, and TimeSource. Unlike these other classes, however, the MotherNode doesn't define any new services that your node must provide. Instead, it implements some basic node necessities for you.

In a nutshell, the MotherNode services the node's control port with its own thread. When BMediaNode messages come in, the MotherNode pushes events on to its BTimedEventQueue. In the main loop the MotherNode waits for new messages until it's time to handle a new event. Then it pops the event off the event queue and calls HandleEvent() with it.

Subclasses of the MotherNode will implement MessageReceived() and other time-related BMediaNode subclass hook functions (like BBufferConsumer::ProducerDataStatus()) to push events onto the event queue. The subclass will also implement HandleEvent() to do the actual work required to make sure the event is handled properly (i.e., the real work of the node).

You'll find the MotherNode class at

ftp://ftp.be.com/pub/samples/media_kit/MotherNode.zip

This code is only of use to people with access to the current beta CD.

Finally, it is certain that the MotherNode's functionality will find its way into the final release under another name. However, the API should stay pretty similar, so only minor code changes will be needed.

"I can't print."

These are words that strike fear in the hearts of many good men and women in call centers all over the world, including some who are reading this article right now. We are the knowledgeable and somewhat strained voices on the far end of "the help line." We need a vacation and a fresh look at humanity. We are tech support. Let's look at how the user got to us.

Some time in the past, your company—which consists of three developers respectively titled VP of Development 1, VP of Development 2, and King -- encountered a situation they were not entirely prepared for. The company just released Product, the coolest thing on the block, and made its first sales. Finally! There is great rejoicing.

Then, John Q. Pedestrian, famous for not knowing the difference between WALK and DON'T WALK, decides to buy your product. He pays his money, takes home your software, and installs it. OK, so far. But then something fails to happen exactly how, when, where, or why John expected. He sends e-mail to your company:

The person who read the mail thinks, "What do you MEAN you can't print? I spent weeks, months on this! It works fine here! We proved it! All our testing works fine! What could possibly be wrong?"

Let me stop here and say that it's easy to blame the user. But remember, John is a real person with family, friends, loved ones, a mortgage, a driver's license *shudder*, and a job. John can balance a checkbook. Sometimes he does his own taxes. He's had some college education. He's not stupid. He may or may not know the available resources. He may not speak your language. He may or may not have good communication skills. He's stuck.

Your development team has suddenly become its own tech support. This is a problem. It has to figure out what the company's users need, as well as what they expect—and what the company expects of them. It must determine what resources are available to meet users' needs and how to deploy those resources.

As Be's Customer Technical Support (CTS) manager, figuring these things out is my job. I make sure you can find the answers you need, and that someone is there to supply the answers you can't find. And if other support people can't help you, I'm the answer guy of last resort. My experience for that role comes from having worked for the world's largest supplier of outsourced technical support, on a variety of subcontracts ranging from hardware and software to operating systems and appliances. I know my share and have all the funny stories to prove it.

If you're interested in some background on technical support, one of the best articles I've read was written for "MacWorld" magazine, by David Pogue. He spent a day with Apple's support group just after it had changed from free to fee-based support. Based on the kind of service people were getting for the fee charged, he concluded that "... [Apple] should charge twice that [amount]." (See http://macworld.zdnet.com/pages/october.98/Column.4493.html.

So, why is support a problem?

I always feel nervous going to a developer conference, because we're going to meet the people who literally make us. It may be obvious but nonetheless bears repeating that an operating system has little or no value by itself. Applications determine its value—hence the vital role of software developers—and of events such as the BeDC. A developer conference is an opportunity to give a progress report on our work. We get vigorous feedback from people who are committed to the platform and, in return, we offer them information and suggestions on how they can make the best use of the APIs and development tools. And, of course, there are the T-shirts.

That's more or less the script we followed at last weekend's event. By all accounts, our opening act was a little flat—I know, I was part of it—but the main part, the Media Kit sessions, got the good reviews, much to our grateful delight. For this conference, we did some things differently: we charged admission; and we focused on the Media Kit, instead of addressing all aspects of the BeOS. We highlighted the Media Kit because it is the key to the most important application space -- digital media—and it provides the tools to produce "tangible" (I should probably say visible and audible) proofs of BeOS advantages.

The result was a happy, productive conference. Several attendees made unsolicited comments about the usefulness of the session and the productive use of their time. I even got the same feedback from a Be engineer who's been immersed in other parts of our work. This is not to say that we won't have general purpose conferences in the future, but for the introduction of the Media Kit—the keystone of the BeOS edifice -- we wanted to ensure that its concepts and facilities were treated with the attention its role in the BeOS architecture warrants.

At the beginning, I stated I was always nervous going to a developer's conference, but I should have added I always enjoy these events and come away more motivated than ever after meeting people who take our future in their own hands. My thanks to them and to the Be team for making this conference a success—and a great time for yours truly.