openMosix

On Sun, Oct 27, 2002 at 02:59:07PM -0600, Bruce Knox wrote:
> We need your help responding to the openMosix Discussion Forums.  
> 
> The Forum postings are generally not noticed by our List participants since the Forums are web based, but you can have them monitored so that you receive an email for each Forum posting.  All of our Forums get far less traffic than this List, so monitoring them will not significantly increase your mail.
> 
> OK, if they don't see much traffic then why the concern?  Because, the openMosix project has a very good reputation for giving quick responses to any and all questions.  We rarely have unanswered questions on the List(s). 
> 
> But, questions posted to the Forums can go unanswered for a long time.  The easy way to help is to monitor a Forum by simply clicking on the Monitor Forum link on any of the Forums: https://sourceforge.net/forum/?group_id=46729
> 
> Thanks for your help! 
> 

Count me in. :)

Hi all,

On Sun, 27 Oct 2002 14:59:07 -0600
"Bruce Knox" <bknox@...> wrote:

BK> We need your help responding to the openMosix Discussion Forums.  

sourceforge now also has a news server, form which we can view/post data to
forums... details:

The hostname of the NNTP server is 'nntp.sourceforge.net' and the port
NNTP is listening on is 563. (nntps, SSL-protected NNTP)

We allow only SSL connections.

You need to use your SourceForge user name and password to login.


--- 
If you don't strike oil in twenty minutes, stop boring.

Amit Shah
http://amitshah.nav.to/

Hi folks

We need to revamp the openMosix logging facility to make it easier for 
users to understand what's going on and what is the problem when there are 
problems. 

We will work with structures like this in the kernel code 
whenever possible:

#ifdef CONFIG_oM_LOGGING
                printk ("Received a process from remote node with %d pages 
\n", m->pages_i_bring);
#endif /* CONFIG_oM_LOGGING */

This should be applied whenever an important event happened either 
successfully or when an error will lead to the user noticing it. Also we 
should from time to time print some log information about the health of 
the node and the load balancing status. 

The idea is that the we can then add a simple rule to the syslogd to have 
all openMosix messages go to /var/log/hpc. 

I encourage you all to start putting this code constructs whenever you see 
a code section worthy of it and send me the changes as patches. I will 
then go through them and commit them to CVS. 

Many thanks

Moshe

On Wed, Nov 20, 2002 at 12:30:05AM +0200, Moshe Bar wrote:
> Hi folks
> 
> We need to revamp the openMosix logging facility to make it easier for 
> users to understand what's going on and what is the problem when there are 
> problems. 
> 
> We will work with structures like this in the kernel code 
> whenever possible:
> 
> #ifdef CONFIG_oM_LOGGING
>                 printk ("Received a process from remote node with %d pages 
> \n", m->pages_i_bring);
> #endif /* CONFIG_oM_LOGGING */
> 

You might consider a logging level, or use the appropriate prefix so that
syslog can seperate that it is a warning, critical, or info message...

On Wed, Nov 20, 2002 at 12:30:05AM +0200, Moshe Bar wrote:

> We will work with structures like this in the kernel code 
> whenever possible:
> 
> #ifdef CONFIG_oM_LOGGING
>                 printk ("Received a process from remote node with %d pages 
> \n", m->pages_i_bring);
> #endif /* CONFIG_oM_LOGGING */

Yeech. 

Please consider using something like this: 

in a header file: 

#ifdef SCT_MODULE_DEBUG

#define SCTDBG(level, msg, args...) do {                                  \
        if ((debug_level & level))                                        \
                printk(KERN_DEBUG "[%s] " msg , __FUNCTION__ , ##args );  \
} while (0)

#else /* !defined(SCT_MODULE_DEBUG) */ 

#define SCTDBG(level, msg, args...) do { } while (0)

#endif /* SCT_MODULE_DEBUG */ 

and in the source files, you use

SCTDBG(DBG_FOO, "%s - %d", some_message, some_int), which is far
cleaner (no ifdefs anywhere except for one header file) *and* will be
optimized out if SCT_MODULE_DEBUG is not defined. 

As for debug_level and level, you keep a bitmask of which areas you
want debug (or log, same concept) messages for, and only messages
which are relevant get printed. For example, if you have

#define LOG_FOO 0x1
#define LOG_BAR 0x2

and your 'debug_level' is 0x1, this message will get printed

SCTDBG(LOG_FOO, "gargargar"); 

but this won't be 

SCTDBG(LOG_BAR, "fofofofof"); 

Adding a /proc file to control in run time which areas should be
logged and which shouldn't is trivial, and I'll be happy to send a
patch if you want it. 

> This should be applied whenever an important event happened either 
> successfully or when an error will lead to the user noticing it. Also we 
> should from time to time print some log information about the health of 
> the node and the load balancing status. 

This is exactly what the old MOSIX debug and diags code which you
removed did. 
-- 
Muli Ben-Yehuda				    http://www.mulix.org/
mulix@...:~$ sctrace strace /bin/foo  http://syscalltrack.sf.net/
Quis custodes ipsos custodiet?

On Wed, 20 Nov 2002 09:32:46 +0200
Muli Ben-Yehuda <mulix@...> wrote:

MBY> #ifdef SCT_MODULE_DEBUG
MBY> 
MBY> #define SCTDBG(level, msg, args...) do {   \
MBY>         if ((debug_level & level))          \
MBY>                 printk(KERN_DEBUG "[%s] " msg , __FUNCTION__ , ##args );\
MBY> } while (0)
MBY> 
MBY> #else /* !defined(SCT_MODULE_DEBUG) */ 
MBY> 
MBY> #define SCTDBG(level, msg, args...) do { } while (0)
MBY> 
MBY> #endif /* SCT_MODULE_DEBUG */ 

I personally think this is a better way of doing things, and a lot of kernel
code does handle debugging this way.

--- 
If you don't strike oil in twenty minutes, stop boring.

Amit Shah
http://amitshah.nav.to/

No, way too complicated. I want to keep it simple so people will 
actually use it. 

Moshe

On Wed, 20 Nov 2002, Muli Ben-Yehuda wrote:

> On Wed, Nov 20, 2002 at 12:30:05AM +0200, Moshe Bar wrote:
> 
> > We will work with structures like this in the kernel code 
> > whenever possible:
> > 
> > #ifdef CONFIG_oM_LOGGING
> >                 printk ("Received a process from remote node with %d pages 
> > \n", m->pages_i_bring);
> > #endif /* CONFIG_oM_LOGGING */
> 
> Yeech. 
> 
> Please consider using something like this: 
> 
> in a header file: 
> 
> #ifdef SCT_MODULE_DEBUG
> 
> #define SCTDBG(level, msg, args...) do {                                  \
>         if ((debug_level & level))                                        \
>                 printk(KERN_DEBUG "[%s] " msg , __FUNCTION__ , ##args );  \
> } while (0)
> 
> #else /* !defined(SCT_MODULE_DEBUG) */ 
> 
> #define SCTDBG(level, msg, args...) do { } while (0)
> 
> #endif /* SCT_MODULE_DEBUG */ 
> 
> and in the source files, you use
> 
> SCTDBG(DBG_FOO, "%s - %d", some_message, some_int), which is far
> cleaner (no ifdefs anywhere except for one header file) *and* will be
> optimized out if SCT_MODULE_DEBUG is not defined. 
> 
> As for debug_level and level, you keep a bitmask of which areas you
> want debug (or log, same concept) messages for, and only messages
> which are relevant get printed. For example, if you have
> 
> #define LOG_FOO 0x1
> #define LOG_BAR 0x2
> 
> and your 'debug_level' is 0x1, this message will get printed
> 
> SCTDBG(LOG_FOO, "gargargar"); 
> 
> but this won't be 
> 
> SCTDBG(LOG_BAR, "fofofofof"); 
> 
> Adding a /proc file to control in run time which areas should be
> logged and which shouldn't is trivial, and I'll be happy to send a
> patch if you want it. 
> 
> > This should be applied whenever an important event happened either 
> > successfully or when an error will lead to the user noticing it. Also we 
> > should from time to time print some log information about the health of 
> > the node and the load balancing status. 
> 
> This is exactly what the old MOSIX debug and diags code which you
> removed did. 
> 

--

On Wed, Nov 20, 2002 at 01:10:51PM +0200, Moshe Bar wrote:
> No, way too complicated. I want to keep it simple so people will 
> actually use it. 

actually, for the users of the interface, it's much simpler than your
suggestion. 

You suggested

#ifdef ... 
printk(KERN_FOO ...)
#endif 

I suggested

OMDBG(DBG_FOO, ...)

It takes all of 10 minutes to implement. I'll be happy to send you a
patch against current openmosix cvs. 
-- 
Muli Ben-Yehuda				    http://www.mulix.org/
mulix@...:~$ sctrace strace /bin/foo  http://syscalltrack.sf.net/
Quis custodes ipsos custodiet?

> #endif 
> 
> I suggested
> 
> OMDBG(DBG_FOO, ...)

It's ugly as hell. Come with a nice solution and we'll talk again. 

Moshe

On Wed, Nov 20, 2002 at 05:51:30PM +0200, Moshe Bar wrote:
> > #endif 
> > 
> > I suggested
> > 
> > OMDBG(DBG_FOO, ...)
> 
> It's ugly as hell. Come with a nice solution and we'll talk again. 
> 

You've got to be kidding me Moshe.  If you have any hope to ever get OM in
the mainline kernel, then you'll have to consider exactly this instead of
ifdefs everywhere.

I am not actually shooting to be part of the kernel for the time being. 
Life as a patch is not bad either. 

Moshe

On Wed, 20 Nov 2002, Mike Fedyk wrote:

> On Wed, Nov 20, 2002 at 05:51:30PM +0200, Moshe Bar wrote:
> > > #endif 
> > > 
> > > I suggested
> > > 
> > > OMDBG(DBG_FOO, ...)
> > 
> > It's ugly as hell. Come with a nice solution and we'll talk again. 
> > 
> 
> You've got to be kidding me Moshe.  If you have any hope to ever get OM in
> the mainline kernel, then you'll have to consider exactly this instead of
> ifdefs everywhere.
> 

--

On Thu, Nov 21, 2002 at 12:36:39AM +0200, Moshe Bar wrote:
> I am not actually shooting to be part of the kernel for the time being. 
> Life as a patch is not bad either. 
> 

Don't forget that any changes submitted to the kernel would have to take
into consideration openmosix once it's included in the kernel.  That's less
catchup work for you...