> But libraries are hard, for a number of distributional reasons.
I don't see why this is the case to be honest.
You can ask distros to ship your library, and if it's a sensible one,
they will. And if you can't wait, you can always bundle the library with
your application, it's really not a
But libraries are hard, for a number of distributional reasons.
I don't see why this is the case to be honest.
You can ask distros to ship your library, and if it's a sensible one,
they will. And if you can't wait, you can always bundle the library with
your application, it's really not a big
On Sat, 24 Mar 2007 07:57:52 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> >
> > But for non-programming reasons, we're just not there yet: people want to
> > program direct to the kernel interfaces simply because of the
> > distribution/coordination problems with libraries. It would be nice
On Sat, 24 Mar 2007 00:11:32 -0700 "Ken Chen" <[EMAIL PROTECTED]> wrote:
> On 3/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > a) Ken observes that obtaining private hugetlb memory via hugetlbfs
> >involves "fuss".
> >
> > b) the libhugetlbfs maintainers then go off and implement a
On 3/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
a) Ken observes that obtaining private hugetlb memory via hugetlbfs
involves "fuss".
b) the libhugetlbfs maintainers then go off and implement a no-fuss way of
doing this.
Hmm, what started this thread was libhugetlbfs maintainer
On 3/23/07, Andrew Morton [EMAIL PROTECTED] wrote:
a) Ken observes that obtaining private hugetlb memory via hugetlbfs
involves fuss.
b) the libhugetlbfs maintainers then go off and implement a no-fuss way of
doing this.
Hmm, what started this thread was libhugetlbfs maintainer
On Sat, 24 Mar 2007 00:11:32 -0700 Ken Chen [EMAIL PROTECTED] wrote:
On 3/23/07, Andrew Morton [EMAIL PROTECTED] wrote:
a) Ken observes that obtaining private hugetlb memory via hugetlbfs
involves fuss.
b) the libhugetlbfs maintainers then go off and implement a no-fuss way of
On Sat, 24 Mar 2007 07:57:52 +0100 Sam Ravnborg [EMAIL PROTECTED] wrote:
But for non-programming reasons, we're just not there yet: people want to
program direct to the kernel interfaces simply because of the
distribution/coordination problems with libraries. It would be nice to fix
>
> But for non-programming reasons, we're just not there yet: people want to
> program direct to the kernel interfaces simply because of the
> distribution/coordination problems with libraries. It would be nice to fix
> that problem.
What is then needed to get a small subset of user-space in
On Fri, 23 Mar 2007 22:32:31 -0700 "Nish Aravamudan" <[EMAIL PROTECTED]> wrote:
> > Probably the kernel team should be maintaining, via existing processes, a
> > separate libkernel project, to fix these distributional problems. The
> > advantage in this case is of course that our new hugetlb
On 3/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Fri, 23 Mar 2007 01:44:38 -0700 "Ken Chen" <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Adam Litke <[EMAIL PROTECTED]> wrote:
> > The main reason I am advocating a set of pagetable_operations is to
> > enable the development of a new hugetlb
On Fri, 23 Mar 2007 01:44:38 -0700 "Ken Chen" <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Adam Litke <[EMAIL PROTECTED]> wrote:
> > The main reason I am advocating a set of pagetable_operations is to
> > enable the development of a new hugetlb interface. During the hugetlb
> > BOFS at OLS last
On 3/23/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
On Fri, 23 Mar 2007, William Lee Irwin III wrote:
>> Lack of compiletesting beyond x86-64 in all probability.
On Fri, Mar 23, 2007 at 03:15:55PM +, Mel Gorman wrote:
> Ok, this will go kablamo on Power then even if it compiles. I
On 3/23/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
I like this patch a lot, though I'm not likely to get around to testing
it today. If userspace testcode is available that would be great to see
posted so I can just boot into things and run that.
Here is the test code that I used:
> -#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
> -unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long
> addr,
> - unsigned long len, unsigned long pgoff, unsigned long flags);
> -#else
> -static unsigned long
> +unsigned long
> hugetlb_get_unmapped_area(struct file
On Fri, 23 Mar 2007, William Lee Irwin III wrote:
>> Lack of compiletesting beyond x86-64 in all probability.
On Fri, Mar 23, 2007 at 03:15:55PM +, Mel Gorman wrote:
> Ok, this will go kablamo on Power then even if it compiles. I don't
> consider it a fundamental problem though. For the
On Fri, 23 Mar 2007, William Lee Irwin III wrote:
On Fri, 23 Mar 2007, Ken Chen wrote:
-#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
-unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long
addr,
- unsigned long len, unsigned long pgoff, unsigned long flags);
-#else
On Fri, 23 Mar 2007, Ken Chen wrote:
> >-#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
> >-unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long
> >addr,
> >-unsigned long len, unsigned long pgoff, unsigned long flags);
> >-#else
> >-static unsigned long
> >+unsigned long
On Fri, 23 Mar 2007, Ken Chen wrote:
On 3/21/07, Adam Litke <[EMAIL PROTECTED]> wrote:
The main reason I am advocating a set of pagetable_operations is to
enable the development of a new hugetlb interface. During the hugetlb
BOFS at OLS last year, we talked about a character device that would
On Fri, Mar 23, 2007 at 01:44:38AM -0700, Ken Chen wrote:
> I think we have enough infrastructure currently in hugetlbfs to
> implement what Adam wants for something like a /dev/hugetlb char
> device (except we can't afford to have a zero hugetlb page since it
> will be too costly on some arch).
>
On Fri, 23 Mar 2007, Ken Chen wrote:
On 3/21/07, Adam Litke [EMAIL PROTECTED] wrote:
The main reason I am advocating a set of pagetable_operations is to
enable the development of a new hugetlb interface. During the hugetlb
BOFS at OLS last year, we talked about a character device that would
On Fri, Mar 23, 2007 at 01:44:38AM -0700, Ken Chen wrote:
I think we have enough infrastructure currently in hugetlbfs to
implement what Adam wants for something like a /dev/hugetlb char
device (except we can't afford to have a zero hugetlb page since it
will be too costly on some arch).
I
On Fri, 23 Mar 2007, Ken Chen wrote:
-#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
-unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long
addr,
-unsigned long len, unsigned long pgoff, unsigned long flags);
-#else
-static unsigned long
+unsigned long
On Fri, 23 Mar 2007, William Lee Irwin III wrote:
On Fri, 23 Mar 2007, Ken Chen wrote:
-#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
-unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long
addr,
- unsigned long len, unsigned long pgoff, unsigned long flags);
-#else
On Fri, 23 Mar 2007, William Lee Irwin III wrote:
Lack of compiletesting beyond x86-64 in all probability.
On Fri, Mar 23, 2007 at 03:15:55PM +, Mel Gorman wrote:
Ok, this will go kablamo on Power then even if it compiles. I don't
consider it a fundamental problem though. For the purposes
-#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
-unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long
addr,
- unsigned long len, unsigned long pgoff, unsigned long flags);
-#else
-static unsigned long
+unsigned long
hugetlb_get_unmapped_area(struct file *file,
On 3/23/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
I like this patch a lot, though I'm not likely to get around to testing
it today. If userspace testcode is available that would be great to see
posted so I can just boot into things and run that.
Here is the test code that I used:
On 3/23/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
On Fri, 23 Mar 2007, William Lee Irwin III wrote:
Lack of compiletesting beyond x86-64 in all probability.
On Fri, Mar 23, 2007 at 03:15:55PM +, Mel Gorman wrote:
Ok, this will go kablamo on Power then even if it compiles. I don't
On Fri, 23 Mar 2007 01:44:38 -0700 Ken Chen [EMAIL PROTECTED] wrote:
On 3/21/07, Adam Litke [EMAIL PROTECTED] wrote:
The main reason I am advocating a set of pagetable_operations is to
enable the development of a new hugetlb interface. During the hugetlb
BOFS at OLS last year, we talked
On 3/23/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 23 Mar 2007 01:44:38 -0700 Ken Chen [EMAIL PROTECTED] wrote:
On 3/21/07, Adam Litke [EMAIL PROTECTED] wrote:
The main reason I am advocating a set of pagetable_operations is to
enable the development of a new hugetlb interface.
On Fri, 23 Mar 2007 22:32:31 -0700 Nish Aravamudan [EMAIL PROTECTED] wrote:
Probably the kernel team should be maintaining, via existing processes, a
separate libkernel project, to fix these distributional problems. The
advantage in this case is of course that our new hugetlb functionality
But for non-programming reasons, we're just not there yet: people want to
program direct to the kernel interfaces simply because of the
distribution/coordination problems with libraries. It would be nice to fix
that problem.
What is then needed to get a small subset of user-space in the
32 matches
Mail list logo
