lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200704232106.29983.rjw@sisk.pl>
Date:	Mon, 23 Apr 2007 21:06:28 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	"Satyam Sharma" <satyam.sharma@...il.com>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Ingo Molnar" <mingo@...e.hu>, ego@...ibm.com,
	"Oleg Nesterov" <oleg@...sign.ru>, linux-kernel@...r.kernel.org,
	vatsa@...ibm.com, paulmck@...ibm.com, pavel@....cz
Subject: Re: [RFC][PATCH -mm 2/3] freezer: Introduce freezer_flags

Hi,

On Monday, 23 April 2007 06:09, Satyam Sharma wrote:
> Hi Rafael,
> 
[--snip--]
> 
> Also, I do have several gripes against the naming of some of these functions:
> 
> >  static inline int freezing(struct task_struct *p)
> 
> This could be called task_should_freeze().
> 
> >  /*
> > - * Sometimes we may need to cancel the previous 'freeze' request
> > + * Cancel the previous 'freeze' request
> >   */
> >  static inline void do_not_freeze(struct task_struct *p)
> 
> This definitely needs to be undo_freeze() or unfreeze().
> do_not_freeze() sounds like what freeze_exempt() does.
> 
> >  static inline void frozen_process(struct task_struct *p)
> 
> frozen_process() sounds like what frozen() is supposed to do. This
> could instead be mark_task_frozen(), or even mark_frozen(), because
> only the current task can ever mark *itself* frozen before freezing
> itself.
> 
> >  static inline void freezer_do_not_count(void)
> >  static inline void freezer_count(void)
> 
> These could be called freezer_skip() and freezer_do_not_skip(). Better
> to stick to consistent naming / terminology.

Well, I agree that the names are not the best ones, but I'd like to avoid
changing the existing names in this particular patch.

We can change them later, on top of it.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ