linux-kernel - Re: HugeTLB: Driver example

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090917091408.GB13002@csn.ul.ie>
Date:	Thu, 17 Sep 2009 10:14:08 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	Alexey Korolev <akorolex@...il.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Eric Munson <linux-mm@...bm.net>,
	Alexey Korolev <akorolev@...radead.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: HugeTLB: Driver example

On Thu, Sep 17, 2009 at 06:42:20PM +1200, Alexey Korolev wrote:
> >> There is an example of simple driver which provides huge pages mapping
> >> for user level applications. The  procedure for mapping of huge pages
> >> to userspace by the driver is:
> >>
> >> 1. Create a hugetlb file on vfs mount of hugetlbfs (h_file)
> >
> > Note that to get your support code included at all you'll need a real
> > intree driver, not just an example.  That is if VM people are happy with
> > the general concept.
>
> Hi,
> The driver example listed here takes the same approach as already done
> inside ipc/shm.c. So people can refer this file for development. The
> patches just make existing functions more usable by drivers and this
> example is an extract of ipc/shm.c in order to give pretty simple
> how-to.

I think Christoph's point is that there should be an in-kernel user of the
altered interface to hugetlbfs before the patches are merged. This example
driver could move to samples/ and then add another patch converting some
existing driver to use the new interface. Looking at the example driver,
I'm hoping that converting an existing driver of interest would not be a
massive undertaking.

I tend to agree with him.

As I'm having trouble envisioning what a real driver would look like,
converting an in-kernel driver ensures that the interface was sane instead
of exporting symbols that turn out to be unusable later. It'll also force
any objectors out of the closet sooner rather than later.

As it stands, I have no problems with the patches as such other than they
need a bit more spit and polish. The basic principal seems ok.

> Seems I gave a not so good description for this patch set so it caused
> a lot of misunderstanding, sorry about that.
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/