RE: [Syllable-kernel] Arno's kernel patches

[Kristian V. <Kri...@an...>]

Jake Hamby wrote:
> Kristian Van Der Vliet wrote:
>> On Friday 28 January 2005 03:26, Jake Hamby wrote:
>> 
>>>Also, what is the verdict as far as the stability of Arno's patches?
>>>Did the Jan. 23 patch removing the cli()/put_cpu_flags() calls make
>>>things better or worse?  I'm concerned about Vander's reports of
>>>instability during compiles and I'd much rather have a stable kernel
>>>that only works on some machines than a kernel that boots on more
>>>machines but isn't reliable.
>> 
>> 
>> It fixed booting on SMP (& HT) machines at the expense of 
>> stability on SMP and uni machines.  I wouldn't consider it a
>> suitable final patch for inclusion in the next release of
>> Syllable without further work to stabalise it.
> 
> Okay, that's what I thought.  I was a little concerned because, if 
> anything, we should be _adding_ SMP sychronization mutexes, 
> not removing them, unless they are obviously unnecessary and not
> in the critical startup path.

The odd thing is that it fixes the SMP boot problems.  Quite why removing
syncronisation primitives should have that effect is still somewhat of a
mystery.  However Arno did say that he removed them from functions which
were already being called with interupts disabled, so they were redundent.

> In our case we have AFS attributes, and any app is free to use XML or 
> any other format to store settings so, outside of creating an 
> equivalent to the hidden "Application Data" and "Local Settings" folders 
> in Windows (perhaps ".config" if this hasn't already been decided?) in 
> each user's home directory for personal settings, we should be okay on
> that end. 

See os::Settings, which stores configuration data in
$HOME/Settings/<appname>/Settings  This settings file is a flattened
os::Message object streamed to disc, which in a way is a simple
key::value model with no tree structure.  It works very well.

> But for communications between the kernel and user programs, we need 
> something a little different..<snip>
> 
> Anyway, I will look into the capabilities of the registrar as well as 
> read through the d-bus mailing list archives to see how it's 
> being used, and see if perhaps we can begin to use the registrar for 
> communication of information between user processes and the kernel.

One idea I had was to add an events API to the kernel.  Any code, either
kernel space or user-space, could call event() which would queue up an
event in a message queue.  A user space process E.g. the Registrar, could
then pull these simple messages out of the queue.  Applications could
register with the Registrar to receive events that they are interested
in.

So E.g. inserting a USB device would cause the following to happen:

o USB HCI driver gets interupt, finds new hardware, raises an event with
  a "Hardware inserted" class.
o The Registrar sees the event in it's queue and checks to see which
  applications are waiting for "Hardware inserted" events.
o The Registrar constructs an os::Message object with the details from
  the event and posts the message to every Application currently waiting
  for "Hardware inserted" events.

> I would very much like for Syllable to have an equivalent to the Windows
> task manager (I want to write my own in order to learn the syllable API),
> and I don't want us to continue passing information in fixed length 
> structures, as we're currently doing in get_system_info().

Well there is already Syllable Manager, which offers a process list and
some basic process control.

What you seem to be proposing (& correct me if I'm wrong) is some way to
pass a dynamic tree of key::value pairs between application and kernel space
via. a consistent API.  Which is a brilliant idea which would simply the
entire
process of passing data between the kernel and user-space much much easier.
Just think, a /proc type system without the need to mess with parsing
human-readable text in the userspace process.  Forward *and* backward
compatability.  Complex data structures flowing seamlessly...mmm. If you
coupled this with the event model I describe above, just think of the
possibilities of kernel and user-space integration we could achieve!

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________