linux-kernel - Re: [PATCH] PM

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20071004203952.GB19803@linux.intel.com>
Date:	Thu, 4 Oct 2007 13:39:52 -0700
From:	Mark Gross <mgross@...ux.intel.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	arjan@...radead.org, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	mark.gross@...el.com
Subject: Re: [PATCH] PM_QOS 1 of 2

On Thu, Oct 04, 2007 at 12:53:56PM -0700, Andrew Morton wrote:
> On Mon, 1 Oct 2007 16:45:28 -0700
> Mark Gross <mgross@...ux.intel.com> wrote:
> 
> > The following is the cleaned up patch implementing the power management
> > quality of service infrastructure discussed at the pm summit last June.
> > 
> > It is a genralization of the latency code put into the kernel last year
> > by Arjan.
> > 
> > I would like to get this code included in the MM tree and to get some
> > milage on it.
> > 
> > One thing to note about this implementation is that it exposes an
> > interface to user space for registering pm_qos constraints in addition
> > to the kernel exports.  Its a file based interface where a module can
> > register a constraint and the constraint is valid only as long as the
> > device node is held open.  Upon closing of the device node that
> > constraint is cleaned up.
> > 
> > The patch set is in two postings.  
> > 1) the base parameter code (this email)
> > 2) replacing of latency.c/latenc.h with pm_qos_params.c/pm_qos_params.h
> 
> I wouldn't really view this as an adequate changelog.
> 
> - The Subject:s are pretty pathetic (please see my suggesed replacements)

uhg.  Your right.

> 
> - There is no description of the proposed new kernel<->userspace
>   interfaces.
> 

the above description is light on specific details. 

>   As you are proposing new and permanent enhancements to the Linux API,
>   this is something which should be spelled out in some detail.  Because we
>   can change the implementation, but we can not ever change your interface.
> 
>   It would be nice to get that interface described in Documentation/
>   somewhere, but it is *critical* that the design be fully revealed right
>   now, during review.

I'll provide this.

> 
> 
> Anyway, I am not a suitable person to review this submission.
> 
> I'll put the patches in -mm for a bit of eyeball-and-test (not that anyone
> will know how to test it, due to the secret interfaces) but I do not want
> to move this code into mainline until someone who is familiar with the PM
> code has performed a detailed review of both the implementation and the
> design (whatever that is!).
> 
> Please send new, complete descriptions of these patches.  I don't think
> they can be effectively reviewed without that information.  Except perhaps
> by someone who was at the PM summit, but that's cheating.
> 

I will do this.

--mgross
-
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/