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

[Jake H. <jh...@po...>]

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.  Correctness before optimization and all that.  Syllable 
is already Fast Enough on most machines.

Anyway, after my Windows woes, which thankfully did not involve the 
dreaded registry, I was thinking that the Windows registry is actually a 
fairly useful concept to have available to third parties as an 
abstraction for storing key/value pairs in a simple hierarchy that can 
be browsed and edited by a knowledgeable user.  You may have gripes with 
Microsoft's failings in the implementation, but it is a useful concept 
in these days of plug-and-play devices, bluetooth discovery, etc., not 
to mention tracking shared dll and driver installations and a whole set 
of software configuration options.  It's the over-use of the last one 
(storing third-party application settings that can get messed up) that 
has caused the most grief for users over the years.  Even Microsoft is 
admitting they screwed up and is now offering not one but four different 
APIs for storing application settings in .NET apps: .config files (XML), 
the registry, "special folders" (I assume this is implemented with NTFS 
attributes or some sort of hidden file on FAT), and finally "isolated 
storage" which is like special folders but stored in some special 
location where the program doesn't have to know where it is.  Not much 
of an improvement, really.  :-)

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. 
But for communications between the kernel and user programs, we need 
something a little different.  In the Linux world this is communicated 
through files in the virtual /proc FS (and the newer /sys FS) and the 
user can get and set flags through sysctl.  For the initial startup 
configuration, simple command-line options, as with Syllable, are 
sufficient.

For the plug-and-play situation and especially for integration between 
the kernel and the GUI desktop, first there was hotplug, now devfs or 
the newer user-mode "udev".  Under at least Gentoo and probably other 
distros, you can choose either devfs or udev.  At the GUI level, the 
FreeDesktop project is working on something called d-bus, which appears 
to be roughly equivalent to our registrar.

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.  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().  If we can require init to 
be running at all times, I don't think it's a big sacrifice to require 
the registrar to be running as well.  Then we can have the equivalent of 
sysctl, /proc, and udev/d-bus, or equivalent to the Windows registry 
only better of course.  :-)

-Jake