[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