Re: [Openmosix-devel] What's new in openMosix today and tomorrow ?

[Evan H. <eh...@gm...>]

Tab-
  Just read this thread, When can we expect the om/ to be read for
testing? That will be a huge boon to the userland tools. That was one
of the things we had trouble making a good solution for.

Evan

On 1/28/06, Matt Rechenburg <mos...@t-...> wrote:
> Hi Vincent,
>
> the omctrlfs sounds great :)
>
> many thanks,
>
> Matt
>
>
> Vincent Hanquez wrote:
>
> >What's in openMosix today and tomorrow ?
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > * debug interface moved to debugfs
> > ----------------------------------
> > I rewrited the debug code, which was available through /proc/hpc/debug
> > to use debugfs. so now to have access to debug files, you need to activ=
ate
> > CONFIG_OPENMOSIX_DEBUG_FS and then mount debugfs somewhere:
> >
> >       mount -t debugfs none /debug/
> >
> > then you'll have an "om" directory there, that contains the needed file=
 to
> > have verbose (migration | syscall | copyuser | files sharing)
> >
> > This cleanup lead me to more cleanup in the hpc/proc.c and to the next =
point.
> >
> > * openMosix control filesystem
> > ------------------------------
> > Instead of hacking into an already messy directory (/proc/) for having
> > an openMosix interface (/proc/hpc/ and /proc/$PID/om/), a new filesyste=
m
> > will be add to provide an efficient clean interface for all openMosix
> > purpose: migration and statistics collection.
> >
> > Here the benefit:
> >  . remove hack into procfs, which is seriously frown upon these days.
> >  . provide efficient interface to the userspace tools:
> >     - not have to read every task /proc/$PID/om/ directory every X ms.
> >     - give a list of migratable tasks, blocked tasks, .. in a single re=
ad.
> >     - provide various statistics.
> >     - add scheduler helper in the kernel for userspace.
> >
> > So, here an example of what will be available there (number are tasks p=
ids):
> >
> >               (mount -t omctrlfs none /om)
> > /om/
> >
> > /om/blocked/                  -> list of task that are blocked
> > /om/blocked/34                           for a reason or another
> > /om/blocked/574                  (user request, stay reason)
> >
> > /om/migratable/               -> list of task that are good candidate f=
or
> > /om/migratable/93                migration, provided by some heuristic
> > /om/migratable/7623              in kernel
> >
> > /om/deputy/                   -> list task that are sent to $ip
> > /om/deputy/$ip/456
> > /om/deputy/$ip2/345
> > /om/deputy/$ip2/7899
> >
> > /om/remote/                   -> list task that come from $ip
> > /om/remote/$ip/56
> >
> > /om/migration                 -> migration order
> >
> >
> > This is not done, so don't try to mount any omctrlfs yet.
> >
> > * openMosix dev tree using git
> > ------------------------------
> > I've now setup a public git tree, instead of the svn tree.
> >
> > URI: git://openmosix.snarc.org/kernel/
> >
> > here the command that you are likely to use:
> > clone it  =3D=3D=3D>  git clone git://openmosix.snarc.org/kernel/ linux=
-2.6-om
> > update it =3D=3D=3D>  (in the directory) git pull
> >
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> openMosix-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
>