syllable-kernel — The list is for discussion of Kernel issues by developers

Re: [Syllable-kernel] new scheduler and HyperThreading (was Re: dos2unix)

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

Daniel Gryniewicz wrote:
> 
> Yep, I'm keeping all that in mind.  HT is quite important to something
> like Syllable.  The goal is to optimize for the 2 physical (and possibly
> 4 logical) CPU case, for now, at least until dual-CPU-dual-core systems
> become common.

Sounds reasonable.

> PS I sent the patch, but I keep forgetting the 40kb limit on the list,
> so it's in moderation again. <sigh>  Next time, I'll CC you directly.

Thanks.  In the future, you may want to .bz2 your larger patches to 
bring them under the 40K limit.

-Jake

Re: [Syllable-kernel] new scheduler and HyperThreading (was Re: dos2unix)

[Daniel G. <da...@fp...>]

On Mon, 2005-01-31 at 19:11 -0800, Jake Hamby wrote:
> Daniel Gryniewicz wrote:
> > 
> > I can easily sync up and give you a new sched02 patch.  I'll do that.
> > Note that, after updating CVS today, I'm having tons on warnings on my
> > linux box.  These will likely show up with Vanders' experimental GCC, so
> > we should probably fix those too.  (The <atheos/typedefs.h> ->
> > "inc/typedefs.h" move had me fooled for a minute...)
> 
> Cool.  I'll test Vanders' new GCC and see how stable it is for kernel 
> builds.  I've been reading _The Unabridged Pentium 4 IA32 Processor 
> Genealogy_ at Safari.oreilly.com and I found some good tips on getting 
> the best performance with HT.  Are you keeping in mind the differences 
> between logical and physical CPUs in your scheduling logic?  Here are 
> the techniques that Intel recommends to optimize performance for 
> HT-enabled processors.
> 

<snip HT stuff>

Yep, I'm keeping all that in mind.  HT is quite important to something
like Syllable.  The goal is to optimize for the 2 physical (and possibly
4 logical) CPU case, for now, at least until dual-CPU-dual-core systems
become common.

Daniel

PS I sent the patch, but I keep forgetting the 40kb limit on the list,
so it's in moderation again. <sigh>  Next time, I'll CC you directly.

[Syllable-kernel] new scheduler and HyperThreading (was Re: dos2unix)

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

Daniel Gryniewicz wrote:
> 
> I can easily sync up and give you a new sched02 patch.  I'll do that.
> Note that, after updating CVS today, I'm having tons on warnings on my
> linux box.  These will likely show up with Vanders' experimental GCC, so
> we should probably fix those too.  (The <atheos/typedefs.h> ->
> "inc/typedefs.h" move had me fooled for a minute...)

Cool.  I'll test Vanders' new GCC and see how stable it is for kernel 
builds.  I've been reading _The Unabridged Pentium 4 IA32 Processor 
Genealogy_ at Safari.oreilly.com and I found some good tips on getting 
the best performance with HT.  Are you keeping in mind the differences 
between logical and physical CPUs in your scheduling logic?  Here are 
the techniques that Intel recommends to optimize performance for 
HT-enabled processors.

* The OS scheduler should schedule threads to be executed on logical 
processors within different physical processors before scheduling 
threads to be executed on both of the logical processors within the same 
physical processor.

* Eliminate spin-wait loops wherever possible.  I need to add a PAUSE 
instruction to our spinlock() function to keep the loop from spinning 
too fast on P4 systems and wasting power (on laptops) and cycles that 
could be used by the other logical CPU.  On older CPUs, PAUSE is a NOP.

* The OS scheduler should attempt to balance the load on each logical 
processor.

* Attempt to share code and data between threads executing on each 
logical CPU within a physical processor (the L1 data cache and L2/L3 
caches are shared).  Two threads in the same process running the same 
code and accessing the same data set will run faster when executing on 
the same physical processor.  This is related to the optimization of 
giving threads an affinity to prefer running on the same CPU as they 
last executed on, only in this case the logical CPU doesn't matter and 
the affinity should be tied to the physical CPU.

* Eliminate or decrease the amount of code and data sharing between 
threads executing on different physical processors.  The ideal situation 
for things like semaphores is that they should be in separate cache 
lines from each other and from the data they're protecting.  On P6 
processors, cache line size is 32 bytes.  On P4 processors, the L2 and 
L3 cache line size is 128 bytes and the L1 data cache line is 64 bytes. 
  I know the Linux kernel has some macros to pad data structures based 
on the cache line size of the CPU(s) that you have compiled it for, but 
we haven't really optimized that aspect of Syllable yet.

After I get SMP working on my P4 system, I'll update the startup code to 
store logical CPU information in the ProcessorInfo_s so you'll be able 
to distinguish between logical and physical processors.  In the meantime 
I wanted to bring up the topic so that you can plan ahead.

-Jake

[Syllable-kernel] Scheduler cleanup 02 rediff

[Daniel G. <da...@fp...>]

On Mon, 2005-01-31 at 17:19 -0500, Daniel Gryniewicz wrote:

> I can easily sync up and give you a new sched02 patch.  I'll do that.
> Note that, after updating CVS today, I'm having tons on warnings on my
> linux box.  These will likely show up with Vanders' experimental GCC, so
> we should probably fix those too.  (The <atheos/typedefs.h> ->
> "inc/typedefs.h" move had me fooled for a minute...)

Okay, attached is a rediff of sched-cleanup-02.  It's against current
CVS, and should be used instead of the previous one.

Daniel

Re: [Syllable-kernel] dos2unix

[Daniel G. <da...@fp...>]

On Mon, 2005-01-31 at 14:06 -0800, Jake Hamby wrote:
> Daniel Gryniewicz wrote:
> > Hey, Jake.
> > 
> > It looks like dlist.h got checked in as a DOS file, rather than as a
> > UNIX file (ie, it has \r\n).  CVS doesn't handle this very well.  Would
> > it be possible to run dos2unix on it, and check in the result?
> > 
> > Note that there are a number of other files with the same problem in the
> > kernel.  Since Syllable uses the Unix text file format, it seems to me
> > that we should standardize on that for our source.
> 
> Oops.  I got some messages about CR's being stripped when I applied your 
> patches but I didn't think about that when I added dlist.h.  I'll do a 
> search for DOS-formatted text files and update any that I find.  It's my 
> fault for saving your attachments from Thunderbird in Windows.

Thanks.   Saves me adding -b to all my diffs. ;)

> > I actually develop on Linux using Vim, 'cause Syllable's not yet ready
> > to be my main OS on my laptop.  I have dos2unix available.  However, I
> > don't have CVS access, so I can't fix things myself.  I can make the
> > changes locally, but then I end up with huge, annoying diffs locally...
> > (as would presumably happen with Sourcery, too.)
> 
> Have you tried Vim under Syllable?  If you set the Terminal background 
> color to white then the color syntax highlighting looks pretty good. 
> It's nice being able to use the same editor on Linux, Windows and 
> Syllable.

Actually, I do use Vim when I'm on Syllable, I just don't do my primary
development on Syllable, because it's not on my laptop.

>   But I assume you are using Linux on your laptop for other 
> reasons. 

Yes.  Main reasons are: Mail software (nothing on Syllable's as good as
Evolution yet), Browser (nothing on Syllable's as good as Firefox yet),
RSS reader (haven't found one on syllable yet... use LifeReader on
Linux), IM (I need AIM/Jabber in a single client.  I use Gaim on Linux).
That's really it.  The rest of the things I usually use on my laptop are
available on Syllable.  Of course, there's still the whole "AFS crashes
and takes everything with it" problem, but, as I'm the last person to
have touched AFS, I can't blame anyone but myself for not having fixed
that. :)

>  Out of curiosity, what 802.11 driver are you using, if any? 
> One of these days I would like to try to port the madwifi driver from 
> Linux so I can use the Atheros chipset in my Fujitsu.  I had to upgrade 
> the version of madwifi in FreeBSD a while back when I was using that OS 
> on my laptop so I know my way around the code a little bit.

I have IPW2200, which is coming along nicely under Linux.  It's entirely
GPL'd, so it should be fairly easy to port to Syllable.  It also
includes what will be the standard Linux 802.11 stack (originally from
the hostap driver), so it might be a great port to Syllable.  The IPW
team is about to realease 1.0.0 of it, and also about to release an
integrated IPW2200/IPW2100 driver.

Incidentally, I still have the ipw2100 mini-pci that originally came
with my laptop, so if someone beats me to a port, I can likely help with
testing...

> Anyway, if you haven't already, please merge your work with the current 
> version of the kernel ("Build 0002") in CVS.  Arno's patches changed a 
> number of function names and moved a few things around, so it'll be a 
> lot easier for me to integrate your next set of scheduler diffs when 
> you're ready.  I haven't yet merged your first two sched-cleanup 
> patches, but I'm assuming that I just need to change LIST_ to DLIST_. 
> I'll post a message here when I've committed those patches so you could 
> also wait until then to sync up.

I can easily sync up and give you a new sched02 patch.  I'll do that.
Note that, after updating CVS today, I'm having tons on warnings on my
linux box.  These will likely show up with Vanders' experimental GCC, so
we should probably fix those too.  (The <atheos/typedefs.h> ->
"inc/typedefs.h" move had me fooled for a minute...)

Daniel

Re: [Syllable-kernel] dos2unix

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

Daniel Gryniewicz wrote:
> Hey, Jake.
> 
> It looks like dlist.h got checked in as a DOS file, rather than as a
> UNIX file (ie, it has \r\n).  CVS doesn't handle this very well.  Would
> it be possible to run dos2unix on it, and check in the result?
> 
> Note that there are a number of other files with the same problem in the
> kernel.  Since Syllable uses the Unix text file format, it seems to me
> that we should standardize on that for our source.

Oops.  I got some messages about CR's being stripped when I applied your 
patches but I didn't think about that when I added dlist.h.  I'll do a 
search for DOS-formatted text files and update any that I find.  It's my 
fault for saving your attachments from Thunderbird in Windows.

> I actually develop on Linux using Vim, 'cause Syllable's not yet ready
> to be my main OS on my laptop.  I have dos2unix available.  However, I
> don't have CVS access, so I can't fix things myself.  I can make the
> changes locally, but then I end up with huge, annoying diffs locally...
> (as would presumably happen with Sourcery, too.)

Have you tried Vim under Syllable?  If you set the Terminal background 
color to white then the color syntax highlighting looks pretty good. 
It's nice being able to use the same editor on Linux, Windows and 
Syllable.  But I assume you are using Linux on your laptop for other 
reasons.  Out of curiosity, what 802.11 driver are you using, if any? 
One of these days I would like to try to port the madwifi driver from 
Linux so I can use the Atheros chipset in my Fujitsu.  I had to upgrade 
the version of madwifi in FreeBSD a while back when I was using that OS 
on my laptop so I know my way around the code a little bit.

Anyway, if you haven't already, please merge your work with the current 
version of the kernel ("Build 0002") in CVS.  Arno's patches changed a 
number of function names and moved a few things around, so it'll be a 
lot easier for me to integrate your next set of scheduler diffs when 
you're ready.  I haven't yet merged your first two sched-cleanup 
patches, but I'm assuming that I just need to change LIST_ to DLIST_. 
I'll post a message here when I've committed those patches so you could 
also wait until then to sync up.

-Jake

Re: [Syllable-kernel] dos2unix

[Daniel G. <da...@fp...>]

On Mon, 2005-01-31 at 16:37 -0500, Rick Caudill wrote:
> Daniel Gryniewicz wrote:
> 
> >Hey, Jake.
> >
> >It looks like dlist.h got checked in as a DOS file, rather than as a
> >UNIX file (ie, it has \r\n).  CVS doesn't handle this very well.  Would
> >it be possible to run dos2unix on it, and check in the result?
> >
> >Note that there are a number of other files with the same problem in the
> >kernel.  Since Syllable uses the Unix text file format, it seems to me
> >that we should standardize on that for our source.
> >
> >
> I ported fileutils awhile ago...  I just forgot to release it :)  My 
> sites host is down right now, but I will post it after I get home from 
> work tonight :)  BTW: Sourcery has dos2unix capabilities builtin...  
> Check the Convert  CRLF to LF  checkbox in the Settings dialog and then 
> open the file and just hit "Save".  Now the file is a unix based file :)
> 

I actually develop on Linux using Vim, 'cause Syllable's not yet ready
to be my main OS on my laptop.  I have dos2unix available.  However, I
don't have CVS access, so I can't fix things myself.  I can make the
changes locally, but then I end up with huge, annoying diffs locally...
(as would presumably happen with Sourcery, too.)

Daniel

Re: [Syllable-kernel] dos2unix

[Rick C. <syl...@ho...>]

Daniel Gryniewicz wrote:

>Hey, Jake.
>
>It looks like dlist.h got checked in as a DOS file, rather than as a
>UNIX file (ie, it has \r\n).  CVS doesn't handle this very well.  Would
>it be possible to run dos2unix on it, and check in the result?
>
>Note that there are a number of other files with the same problem in the
>kernel.  Since Syllable uses the Unix text file format, it seems to me
>that we should standardize on that for our source.
>
>Daniel
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Syllable-kernel mailing list
>Syl...@li...
>https://lists.sourceforge.net/lists/listinfo/syllable-kernel
>
>
>  
>
I ported fileutils awhile ago...  I just forgot to release it :)  My 
sites host is down right now, but I will post it after I get home from 
work tonight :)  BTW: Sourcery has dos2unix capabilities builtin...  
Check the Convert  CRLF to LF  checkbox in the Settings dialog and then 
open the file and just hit "Save".  Now the file is a unix based file :)

-- 
Rick Caudill
Development Website: 	www.syllable-desk.tk
Wedding Website: 	www.lstevensandrcaudillwedding.tk



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.2 - Release Date: 1/28/2005

[Syllable-kernel] dos2unix

[Daniel G. <da...@fp...>]

Hey, Jake.

It looks like dlist.h got checked in as a DOS file, rather than as a
UNIX file (ie, it has \r\n).  CVS doesn't handle this very well.  Would
it be possible to run dos2unix on it, and check in the result?

Note that there are a number of other files with the same problem in the
kernel.  Since Syllable uses the Unix text file format, it seems to me
that we should standardize on that for our source.

Daniel

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

[Saem G. <sae...@gm...>]

On Fri, 28 Jan 2005 17:37:06 -0500, Daniel Gryniewicz <da...@fp...> wrote:
> >  OTOH,
> > while d-bus seems to have some momentum, integration between it and
> > GNOME or KDE is still pretty minimal, as far as I can tell.
> 
> Not quite true.  Gnome 2.10 will have a considerable amount of dbus
> integration, and will require it to be installed to work properly.  For
> example, you mentioned Gnome Volume Manager.  There's also
> NetworkManager, which listens for interface events (loss of carrier, new
> wireless AP, etc.) and automatically configures networking.  Evolution
> will emit various dbus messages based on state of mail/calenders, etc.
> For example, it emits a new-mail message, and uses dbus to notify a
> watcher that a scheduled event has fired from the calender.  There are
> other examples as well.  By Gnome 2.12/3.0, dbus should be completely
> integrated into Gnome, and be a full requirement.  I don't follow KDE,
> so I don't know what it's doing, but dbus is the wave of the future for
> Gnome, and generally will be required for all Linux.

KDE has had DCOP it's own messaging system.  DBUS integration is
planned, basically AFAIK DCOP will sit on top of DBUS as a legacy
while everyone else will migrate to DBUS, KDE 4.0 is supposed to
herald this change.  There is HUGE momentum behind this stuff.

Re: [Syllable-kernel] Strace patch

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

Kristian Van Der Vliet wrote:
> 
> I know about the APM problems but when did PS/2 not work?  Is this the SiS 
> chipset PS/2 bug or something else?

All I know is that the Alps GlidePoint touchpad on my laptop (PS/2 
interface) never worked for me in Syllable until now (and yes it is a 
SiS chipset).

Most recently it wasn't detected at all (the v86 BIOS call in ps2aux was 
failing), but before that it would move the mouse pointer around the 
screen randomly when I tried to use it.  Since I prefer to use my $20 
Logitech Marble Mouse on the USB port, it wasn't a big priority, but 
it's nice to know that it's working again.

-Jake

Re: [Syllable-kernel] Strace patch

[Kristian V. D. V. <va...@li...>]

On Sunday 30 January 2005 21:38, Jake Hamby wrote:
> Kristian Van Der Vliet wrote:
>> Heres a tiny patch to fix errno printing in strace.  Untested but obvious
>> :)
>
> I'll put it in the batch with Daniel's scheduling cleanup patches that
> will become Build 0003.  Right now the version in CVS is Build 0002
> under my new versioning scheme, which includes Arno's big cleanup patch
> of 12/30/2004 and Daniel's cleanup patches of 1/27.

Cool.

> On my own system, I had to add "disable_smp=true" because the SMP stuff
> isn't working on my Pentium 4 HT now that the ACPI code finds the
> simulated SMP. 

If we don't get the kernel stable by 0.5.6 we'll add disable_smp=true to the 
default parameters.

> The error I get is that the init process gives a memory 
> access violation in getpid(), which is implemented in libc by returning
> the thread ID from a structure pointed to by the GS segment register.
> So perhaps the GS register is not getting initialized properly during
> the boot_ap_processors() phase.

This would make sense.  init is the first user space process to run, which is 
a good indication of the problem.  If GS was munged it's possible that it 
doesn't affect the (1:1 mapping) kernel memory space but it certainly would 
mess up the user space mappings, so we get segfaults in user threads but not 
earlier on in kernel threads.

> The good news is that Arno's patches fixed the v86 code and now the PS/2
> mouse driver and APM poweroff code are working again.

I know about the APM problems but when did PS/2 not work?  Is this the SiS 
chipset PS/2 bug or something else?

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

Re: [Syllable-kernel] Strace patch

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

Kristian Van Der Vliet wrote:
> Jake,
> 
> Heres a tiny patch to fix errno printing in strace.  Untested but obvious :)

I'll put it in the batch with Daniel's scheduling cleanup patches that 
will become Build 0003.  Right now the version in CVS is Build 0002 
under my new versioning scheme, which includes Arno's big cleanup patch 
of 12/30/2004 and Daniel's cleanup patches of 1/27.

On my own system, I had to add "disable_smp=true" because the SMP stuff 
isn't working on my Pentium 4 HT now that the ACPI code finds the 
simulated SMP.  The error I get is that the init process gives a memory 
access violation in getpid(), which is implemented in libc by returning 
the thread ID from a structure pointed to by the GS segment register. 
So perhaps the GS register is not getting initialized properly during 
the boot_ap_processors() phase.

The good news is that Arno's patches fixed the v86 code and now the PS/2 
mouse driver and APM poweroff code are working again.

-Jake

[Syllable-kernel] Strace patch

[Kristian V. D. V. <va...@li...>]

Jake,

Heres a tiny patch to fix errno printing in strace.  Untested but obvious :)

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

Re: [Syllable-kernel] Kernel warnings

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

Daniel Gryniewicz wrote:
> Hi, Jake.
> 
> During my work on the scheduler, I modified the kernel makefiles to
> build on my linux box (although it doesn't link), so that I could catch
> stupid compile errors without having to send the patches to my syllable
> box.  In addition, I added -Werror to my CFLAGS.  I'm using gcc 3.4.3,
> so this caught a bunch of warnings that don't show up on syllable.
> Attached are several patches that fix the most obvious of these
> warnings.

Awesome!  Thanks for the patches.  I will apply them right away.

-Jake

Re: [Syllable-kernel] more on EROS and KeyKOS..

[Mark W. <ma...@cl...>]

> On the whole, an interesting idea.  Unfortunately, I believe it dates
> itself.  Memory is way to large to be written to disk every 30 seconds.
 <snip>
> a fast application can already dirty memory faster
> than it can be written to disk with full-time streaming writes
<snip>

It seems to me you could do some tricks to get round these problems...

To me, this resembles the problems involved in live-migrating virtual 
machines.  For this purpose, the Xen (http://xen.sf.net) VMM tracks process' 
page dirtying by setting all the pages read only and recording the faults.  A 
similar mechanism could be used in a checkpointing OS to determine which 
pages changed between checkpoints.

In a paper on the "self-migration" scheme developed by Jacob Gorm Hansen 
(http://www.diku.dk/~jacobg/self-migration/), the possibility of temporarily 
"stunning" processes with high dirtying rates is mentioned - sounds like it 
could also be applied in this sort of system.

> Still, it's an interesting concept.

Yes.  I attended a talk by one of the EROS project leads and apparently the 
orthogonal persistance thing was also an aid to security proofs: (apparently) 
it's much easier to prove that the system will stay secure given a secure 
starting state than to start your argument with system startup, so 
eliminating true reboots makes life easier.

Cheers,
Mark

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

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

Michael Saunders wrote:
> 
> It's in the default install -- IIRC just entering SlbMgr in a terminal
> will fire it up. Failing that, go to the Dock menu and About, and there's
> an 'Advanced' (or similar) button which brings it up.
> 
> Along with processes it also displays some resource stats.

Cool.  In that case I will probably start from that codebase instead of 
trying to write my own GUI from scratch.  I am mostly interested in 
fleshing out the additional capabilities of Windows task manager not yet 
implemented and in using something like D-BUS to abstract this type of 
system info utility from the specific version of the kernel being used.

-Jake

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

[Daniel G. <da...@fp...>]

On Fri, 2005-01-28 at 06:29 -0800, Jake Hamby wrote:
> My understanding is this is basically what d-bus is about.  udev, the 
> Linux user-mode /dev management demon and replacement for devfs, 
> interfaces with the hardware using hotplug scripts and can fire events 
> to d-bus. 

This is basically correct.  Hotplug is migrating to kevents, rather than
callout scripts, but other than that, that's correct.

>  OTOH, 
> while d-bus seems to have some momentum, integration between it and 
> GNOME or KDE is still pretty minimal, as far as I can tell. 

Not quite true.  Gnome 2.10 will have a considerable amount of dbus
integration, and will require it to be installed to work properly.  For
example, you mentioned Gnome Volume Manager.  There's also
NetworkManager, which listens for interface events (loss of carrier, new
wireless AP, etc.) and automatically configures networking.  Evolution
will emit various dbus messages based on state of mail/calenders, etc.
For example, it emits a new-mail message, and uses dbus to notify a
watcher that a scheduled event has fired from the calender.  There are
other examples as well.  By Gnome 2.12/3.0, dbus should be completely
integrated into Gnome, and be a full requirement.  I don't follow KDE,
so I don't know what it's doing, but dbus is the wave of the future for
Gnome, and generally will be required for all Linux.

Daniel
(Who's happily running dbusified gnome 2.9.x)

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

[Michael S. <mi...@as...>]

On Fri, 28 Jan 2005, Jake Hamby wrote:
>
> > Well there is already Syllable Manager, which offers a process list
> > and some basic process control.
>
> Yeah, I remember seeing that but forgot what it was called.  Is it
> installed in the default Syllable install or do I have to download it
> from somewhere?

It's in the default install -- IIRC just entering SlbMgr in a terminal
will fire it up. Failing that, go to the Dock menu and About, and there's
an 'Advanced' (or similar) button which brings it up.

Along with processes it also displays some resource stats.

M

-- 
Michael Saunders
www.aster.fsnet.co.uk

Re: [Syllable-kernel] more on EROS and KeyKOS..

[Daniel G. <da...@fp...>]

On Fri, 2005-01-28 at 08:31 -0800, Jake Hamby wrote:
> Since I have read a lot of the EROS documentation and found it pretty 
> cool, I thought I'd write a quick summary.  As a working open-source OS, 
> it is still basically limited to "Hello, world", but the concepts behind 
> EROS are very cool and were in fact proven by KeyKOS which was a real 
> commercial OS for S/370 mainframes sold by a company called Key Logic 
> during the 1980s.  You can read more on EROS concepts here:
> 

<snip concepts>

On the whole, an interesting idea.  Unfortunately, I believe it dates
itself.  Memory is way to large to be written to disk every 30 seconds.
On my laptop, for example, it takes almost 30 seconds just to write the
1 GB of RAM to disk during suspend!  Granted, it could probably be
faster than that, but a fast application can already dirty memory faster
than it can be written to disk with full-time streaming writes (think
video capture).  I think our secondary storage is just too slow at the
moment, asside from even the problems of it being way to large.

Still, it's an interesting concept.

The "never reboot the OS" can be done now, with suspend-to-disk, both on
Linux and on Windows.  It's not a problem at all.  In fact, I use
suspend-to-ram on Linux on my laptop, and never reboot, except to change
kernels (which you would have to do, even with that design, I believe,
or never change in in-memory representations of data... which would be
very restricting).

Once Syllable has suspend-to-disk, we could just checkpoint (ie,
suspend-to-disk with immediate resume) every so often, and gain most of
the capabilities of this model, I believe.  Especially if
suspend-to-disk is fast.

Daniel

[Syllable-kernel] d-bus and HAL: another piece of the puzzle

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

Another piece of "Project Utopia", which was discussed on 
syllable-developer last month, that integrates with d-bus and udev is 
called HAL, and the project homepage for that is here:

http://www.freedesktop.org/Software/hal

In Gentoo Linux, according to this thread, eventually you will be able 
to do a simple "emerge dbus hal gnome-volume-manager".  Actually, it 
looks like you are able to do that now (only four months after the 
message was posted last Sept.) as long as you are using the 2.6.x Linux 
kernel.

http://forums.gentoo.org/viewtopic.php?t=217412

-Jake

[Syllable-kernel] more on EROS and KeyKOS..

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

Since I have read a lot of the EROS documentation and found it pretty 
cool, I thought I'd write a quick summary.  As a working open-source OS, 
it is still basically limited to "Hello, world", but the concepts behind 
EROS are very cool and were in fact proven by KeyKOS which was a real 
commercial OS for S/370 mainframes sold by a company called Key Logic 
during the 1980s.  You can read more on EROS concepts here:

http://www.eros-os.org/devel/00Devel.html

The two best things about EROS/KeyKOS:

  * The default access to any resource is no access (EPERM) unless the 
process has explicit permission.  That permission comes in the form of a 
key held in OS-controlled memory which can be manipulated or passed 
around to other processes via a secure IPC mechanism.  Keys are used to 
allocate all sorts of resources, including memory pages (up to the 
maximum VM size allowed to the process), network sockets, read-only or 
r/w access to a "file" (really, an anonymous shared region of VM), or 
even classes of CPU priority.  Each end of a pipe acts like a 
"capability" in that any process can pass its end of the pipe to any 
other process and, in so doing, transfer the "privilege" of that stream. 
  This allows for example a debugger or tracing utility to function by 
inserting itself in between two processes having a "conversation" and it 
would be impossible for either side to detect that there was an 
eavesdropper.  The middle process could pass data (messages and keys) 
across the pipe unchanged, or it could alter them (it couldn't send any 
keys it didn't already possess or receive, of course) or save the data 
and keys for later.  That sounds like a huge security flaw but there is 
a reason behind it which I don't recall at the moment.  :-) Anyway, I 
believe it is different from the Linux/BSD passing of unspoofable 
uid/gid/pid identities which is after all a very primitive form of 
access control tying a process to a single user and fixed number of 
groups, as opposed to having a bunch of "tokens" that are tied to 
particular resources and of which a single process can collect a large 
(but not too large, for performance reasons) number.  In KeyKOS/EROS, 
you can store a small number of keys within the process's key 
"registers", or swap keys out in between their registers and special key 
pages in virtual memory held by the kernel and only accessible through, 
yet another capability key.

  * There is no filesystem!  None at all.  Better yet, the system is 
completely checkpointed every 30 seconds so you can literally pull the 
plug on the PC and when you reboot you have lost at most 30 seconds 
worth of work.  Sound too good to be true?  KeyKOS made the bold 
decision to use almost the entire disk partition for a paging file. 
Every 30 seconds the system is paused, all of the memory pages are 
marked read-only, and the processes are restarted, while simultaneously 
the checkpoint thread copies the contents of RAM to the checkpoint 
journal.  The running processes slow down a bit during the checkpoint as 
every memory write operation triggers a page fault and the kernel has to 
block the app until the page becomes ready for r/w, but after each page 
is written to the journal, it can be returned to its previous read/write 
privilege and the system returns to full speed.  Presumably 
higher-priority regions of memory, e.g. a video streaming buffer, could 
be handled, instead of blocking the app, by swapping out some other page 
(that is already checkpointed), marking the original page r/w, and 
scheduling the checkpoint of that page from the r/o copy.  Meanwhile, 
any other page-outs would go to the checkpoint instead of to the normal 
destination on the disk so there is always at least one clean checkpoint 
that can be booted into.

Instead of storing user data in a traditional filesystem, you have one 
or more database server processes that hold the ENTIRE filesystem in 
virtual memory.  Since Syllable currently only runs on 32-bit 
architectures and we already have hard drives (and individual files!) 
much bigger than 4GB, this is not exactly practical for today's large 
media files and big hard drives.  OTOH, the Athlon 64 and PowerMac G5 
and upcoming Intel x86-64 chip are all 64-bit so perhaps this 
architecture would begin to make more sense in another five years.

Anyway, if the "big VM filestore" is going to be no different in 
practice from what we have now with AFS, and considering that AFS would 
likely have much better performace and reliability due to being 
optimized for on-disk layout, I would of course prefer to stick with AFS 
for our primary file storage, especially since it's already been written 
and works pretty well, and the POSIX semantics are well understood. 
OTOH, the KeyKOS concept of checkpointing the entire system state is 
still cool even in conjunction with a traditional FS, when you consider 
that you would NEVER have to worry about losing your e-mail composition 
or spreadsheet or source code file because of a power outage or system 
crash when you hadn't saved. And no need even to have a separate 
"Hibernate" option, just pull the plug!  The alternative is of course to 
have an "auto-save" feature in every application on the desktop 
explicitly, and that is not going to happen nor is it nice to require 
that all developers explicitly handle this when the entire system could 
be checkpointed atomically, once, in the kernel.

So the idea of checkpointing a very large virtual memory would still be 
a very cool thing for Syllable to be able to do at some unknown time in 
the future, even in addition to the traditional Linux/BeOS paradigm of 
having a separate filesystem accessible through read/write system calls 
(or mmap) with files and disks that can be larger in size than the 
address space.  But for implementing something like the registrar or 
d-bus, you don't have to figure out how to serialize your in-memory data 
structures to persistant storage:  you simply do nothing (or hint to the 
kernel what you are doing with certain pages or when you're doing an 
operation that must be atomic and can't be interrupted half-way by a 
checkpoint) but instead rely on the system to keep your in-memory trees 
and hashtables checkpointed.  You can afford to give all running 
processes the chance to give their approval before atomically 
checkpointing the RAM since it only has to run approximately every 30 
seconds.

Another follow-on consequence of this design is that you NEVER reboot 
the OS.  You might have to reboot the _computer_ after a power crash or 
to install a new kernel or new drivers but the cool thing is that after 
rebooting, the new kernel loads in the EXACT same big VM image from the 
previous checkpoint, updating any in-memory structures as necessary if 
the kernel was upgraded.  The flip side of this is that if something 
gets really screwed up, it is a pain to do a "hard reset" and the 
installation process is also a lot different.  Again, we avoid all of 
that nonsense by sticking with the conventional wisdom and retaining the 
ability to do a conventional boot from a conventional filesystem.. even 
though we will only be suspending or hibernating, never shutting down or 
cold-booting under normal circumstances!

-Jake

Re: [Syllable-kernel] Arno's kernel patches (part 2)

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

The link for EROS in my last e-mail was incorrect.  It should have been:

http://www.eros-os.org/

Since I didn't have a good example of d-bus/GNOME integration, here is 
one from the IBM article:

==
Even though D-BUS is relatively new, it has been adopted very quickly. 
As I mentioned earlier, udev can be built with D-BUS support so that it 
sends a signal when a device is hot-plugged. Any application can listen 
to these events and perform actions when they are received. For example, 
gnome-volume-manager can detect the insertion of a USB memory stick and 
automatically mount it; or, it can automatically download photos when a 
digital camera is plugged in.

A more amusing but far less useful example is the combination of 
Jamboree and Ringaling. Jamboree is a simple music player that has a 
D-BUS interface so that it can be told to play, go to the next song, 
change the volume, and so on. Ringaling is a small program that opens 
/dev/ttyS0 (a serial port) and watches what is received. When Ringaling 
sees the text "RING," it uses D-BUS to tell Jamboree to turn down the 
volume. The net result is that if you have a modem plugged into your 
computer and your phone rings, the music is turned down for you. This is 
what computers are for!
==

Pretty cool hack!  Even cooler would be to detect that your cellphone is 
ringing using some sort of Bluetooth notification, or you could try to 
detect if anyone's phone is ringing using a microphone and an FFT 
analysis to listen for "ringing" sounds.  Then you would only need to 
write a replacement for Ringaling and Jamboree, or in our case Coldfish, 
would continue to work unchanged.  A further hypothetical:  this "ring" 
notification app could be wired by the user to implement an arbitrary 
user or system-wide policy such as lowering the volume on all audio 
output devices, perhaps by triggering a script or a plugin dll.  Or 
there might be multiple apps that want to listen for this event.

On that note, I discovered another article describing a way in which you 
could abstract services using d-bus where it wouldn't matter which 
application you were using to do something.  It sounds somewhat like how 
Amiga apps could be scripting using ARexx or Mac apps could be scripted 
with AppleScript and OSA, but more generic between applications.

http://code.eikke.com/DesktopAbstractionLayer/presentation-1.txt

I had a CS professor at my university, Dr. Craig Rich, who had a pretty 
neat layout of his applications and documents on his Mac (this was 
before OS X).  He renamed all of his applications from whatever their 
original names were to generic names, for example Netscape was renamed 
to "Web Browser" and Eudora became "E-Mail Client".  In the Mac world, 
renaming the executable generally doesn't break anything.  He could then 
change e-mail clients, for example, and of course the icon would change, 
but the name would be the same and so the app would be alphabetized into 
the same place in the Apple quick launch menu.

Also notice that Windows only has user associations for certain types of 
Internet locations (HTML, e-mail, news) plus file extensions and events 
such as inserting a blank CD-R or a DVD movie.  You can choose the 
default audio output device or what happens when you double-click on a 
.mp3 file, but if there is a certain activity that isn't tied to a 
particular data file or URL, for example the default "TV tuner" app, I'm 
not sure how you would specify that except through some special registry 
key or something.

-Jake

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

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

Kristian Vandervliet wrote:
> 
> 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.

I think there is some dark voodoo involved in bringing up the additional 
CPU's correctly.  Wouldn't disabling interrupts on the active CPU with 
cli() prevent that processor from being able to receive any IPIs 
(inter-processor interrupts) that it needs to work correctly?  Perhaps 
that's the problem.

> 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.

Cool.  Simple BeOS style.  Yeah, app settings are not exactly rocket 
science to do at the libsyllable level, which is why it is so annoying 
that Microsoft has had so much trouble with the registry over the years.

> 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.

My understanding is this is basically what d-bus is about.  udev, the 
Linux user-mode /dev management demon and replacement for devfs, 
interfaces with the hardware using hotplug scripts and can fire events 
to d-bus.  An alternative API for routing events is the POSIX Tracing 
API, described here and implemented by RTL-POSIXTRACE as an add-on for 
RT-Linux:

http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_11.html

Since POSIX tracing isn't supported by Solaris or any of the other 
commercial UNIX's and is only available as an obscure add-on for 
RT-Linux, it's not a very useful "standard" for us to support.  OTOH, 
while d-bus seems to have some momentum, integration between it and 
GNOME or KDE is still pretty minimal, as far as I can tell.  Here's a 
good technical article on what d-bus is about, with some sample code:

http://www-106.ibm.com/developerworks/linux/library/l-dbus.html

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

Yeah, I remember seeing that but forgot what it was called.  Is it 
installed in the default Syllable install or do I have to download it 
from somewhere?

> 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.

Exactly.  It's a great idea and we can take advantage of the existing 
D-BUS codebase for Linux in addition to the registrar code we have now.

> 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!

Yeah, /proc is gross.  Something like d-bus could even be used, if fast 
enough, by a debugger to inspect and manipulate processes, instead of 
using /proc or ptrace().

There are a lot of security implications of course, but no different 
from the permission issues of a filesystem or any other resource.  I 
would assume that as part of the SylSec project, we will have some sort 
of global security token system where a process will have permission to 
access a certain branch of the hierarchy or a particular key/value pair 
based on the object's ACL and the process's credentials.  Slightly 
off-topic but I have found Windows NT's implementation of security in 
e.g. Active Directory or NTFS that supports BOTH "allow" and "deny" bits 
for many different operations, and supports different ways of 
propagating permissions up the hierarchy, extremely confusing!

Another aspect that may be challenging is how these security tokens and 
credentials could be manipulated and transferred between the kernel and 
user-mode for implementing objects and events in user-space.  One 
possibility is adding a special system call to allow one process to 
authenticate another over a message port, for example FreeBSD allows you 
to send the pid, uid, and group ID of the sending process to its peer on 
the other end of the socket (only over UNIX local domain sockets, not 
through TCP/IP) with SCM_CREDS (the Linux version is called SO_PEERCRED) 
using a special unspoofable message flag.  Sending credentials between 
machines would require something like Kerberos.  In the case of peer 
authenticating across a socket, you are not actually transferring any 
privileges between processes, just allowing a process to know for sure 
the uid/gid/pid of the process it's talking to.  A more useful thing 
would be a fully transferrable key system such as KeyKOS or EROS:

http://www.cis.upenn.edu/~KeyKOS/
http://www.cis.upenn.edu/~eros/

-Jake

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 
______________________________________________________________________