bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] ext2fs: free inode warnings


From: Kevin Kreamer
Subject: Re: [patch] ext2fs: free inode warnings
Date: Sun, 5 Aug 2001 01:28:01 -0500
User-agent: Mutt/1.2.5i

Apparently, I sent this to Neal instead of the list.  So here it is 
for everyone else :-)

Kevin

----- Forwarded message from Kevin Kreamer <kkreamer@etherhogz.org> -----

Date: Sat, 4 Aug 2001 17:44:44 -0500
From: Kevin Kreamer <kkreamer@etherhogz.org>
To: Neal H Walfield <neal@cs.uml.edu>
Subject: Re: [patch] ext2fs: free inode warnings

On Sat, Aug 04, 2001 at 01:19:45PM +0200, Neal H Walfield said:
> > Ok, I've gotten tired of the free inode warnings that ext2fs 
> > displays if you use a partition in both Linux and HURD.  I've 
> > read the thread on this list from late June, so I know they 
> > are mostly harmless[1].  Jeff wanted to configure them out of 
> > existence[2], but I took a different approach and added a 
> > command-line variable, with the intention of that variable 
> > controlling any future hurd-specific warnings as well.  
> 
> I do not think that this is the correct approach, however:

Well, I am mostly interested in getting rid of the warnings, however 
the approach.  It's just that this way seemed the most direct approach 
to me.  If you want to do it a different (better) way, that's 
certainly cool.

> Use -p so we can see the function names.

Point noted for future patches.

> Do not use variables that start with an _.  There are reserved for
> system applications.

Likewise.

> 
> > +/* ---------------------------------------------------------------- */
> > +/* hurd specific features */
> > +
> > +#define DISABLED 0
> > +#define ENABLED 1
> 
> I feel that it is better to make the assumption that 0 is false and
> !false is true.

I did this this way because it seemed easier to read (hurd_warnings == 
ENABLED -> "hurd warnings are enabled"), and because I figured that 
if this variable controls all hurd-specific warnings, we may want 
more options that just on/off.  However, if you want, we can use the 
assumption that 0 is false, and !false is true.  It might be good, in 
that case, to change the variable name to something like 
enable_hurd_warnings or warnings_enabled to make sure it is easy to read.

Neal, thank you for your constructive criticism.  Do you want me to 
make these changes and submit another patch, or are these changes 
simple enough that a new patch isn't necessary?  Also, do you want 
me to find a way to configure them out of existence instead?

Kevin

-- 
Kevin Kreamer



reply via email to

[Prev in Thread] Current Thread [Next in Thread]