James Simmons | 1 Nov 01:52 2002

Re: What's left over.


> > Fbdev Rewrite
>
> This one is just huge, and I have little personal judgement on it.

The size has been cut in half now that the issue of AGP being intialized
to late is on hold. We can discuss that move post-halloween. All that is
in the fbdev tree are fbdev changes. So it is safe to pull it.

Bob Miller | 1 Nov 01:57 2002

[PATCH 2.5.45] Export blkdev_ioctl for raw block driver.

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.857   -> 1.858  
#	      kernel/ksyms.c	1.155   -> 1.156  
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/10/31	rem <at> doc.pdx.osdl.net	1.858
# Export blkdev_ioctl so that the raw device driver
# can be built as a module.
# --------------------------------------------
#
diff -Nru a/kernel/ksyms.c b/kernel/ksyms.c
--- a/kernel/ksyms.c	Thu Oct 31 16:47:14 2002
+++ b/kernel/ksyms.c	Thu Oct 31 16:47:14 2002
 <at>  <at>  -349,6 +349,7  <at>  <at> 
 EXPORT_SYMBOL(blkdev_open);
 EXPORT_SYMBOL(blkdev_get);
 EXPORT_SYMBOL(blkdev_put);
+EXPORT_SYMBOL(blkdev_ioctl);
 EXPORT_SYMBOL(ioctl_by_bdev);
 EXPORT_SYMBOL(read_dev_sector);
 EXPORT_SYMBOL(init_buffer);

--

-- 
Bob Miller					Email: rem <at> osdl.org
Open Source Development Lab			Phone: 503.626.2455 Ext. 17
(Continue reading)

James Simmons | 1 Nov 01:44 2002

Re: [Linux-fbdev-devel] [BK fbdev updates]


> > Sorry about not producing a regular diff. The final changes really did a
> > number on the framebuffer console code in fbcon.c so I had some massive
> > work to do. I still have a massive amount of cleaning up to do. Also a lot
> > of drivers stil haven't been ported.
> >
> > So here is the regular diff against 2.5.45
> >
> > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> >
>
> James,
>
> The diff you posted is still not the right one.

Ug. Try it again.

Alexander Viro | 1 Nov 01:11 2002
Picon

Re: [PATCH 2.5.45] Export blkdev_ioctl for raw block driver.


On Thu, 31 Oct 2002, Bob Miller wrote:

> diff -Nru a/kernel/ksyms.c b/kernel/ksyms.c
> --- a/kernel/ksyms.c	Thu Oct 31 16:47:14 2002
> +++ b/kernel/ksyms.c	Thu Oct 31 16:47:14 2002
>  <at>  <at>  -349,6 +349,7  <at>  <at> 
>  EXPORT_SYMBOL(blkdev_open);
>  EXPORT_SYMBOL(blkdev_get);
>  EXPORT_SYMBOL(blkdev_put);
> +EXPORT_SYMBOL(blkdev_ioctl);

Why not use ioctl_by_bdev() in the first place?  (and yes, it's very likely
my fault - I hadn't realized that raw.c went modular at some point).

Robert Love | 1 Nov 01:10 2002
Picon

Re: [PATCH 2.5.45] NUMA Scheduler (1/2)

On Thu, 2002-10-31 at 18:52, Martin J. Bligh wrote:

> Just wanted to add that everyone that's been involved in this is
> now in harmonious agreement about this combined solution. If you're
> curious as to where the benefits come from, the differences in 
> kernel profiles are included below from a 16-way NUMA-Q doing a
> kernel compile.

Linus, although these patches are fairly straightforward and
non-impacting in the !CONFIG_NUMA case, would you prefer it if a
non-NUMA person who knew the scheduler (say, me) went over these patches
and merged them with you?

Ingo, do you have an opinion either way?  I think basic NUMA support,
especially in the load balancer, should make it in before 2.6.

	Robert Love

Scott Murray | 1 Nov 01:23 2002

Re: bare pci configuration access functions ?

On Thu, 31 Oct 2002, Greg KH wrote:

> On Thu, Oct 31, 2002 at 05:50:06PM -0500, Scott Murray wrote:
> > On Thu, 31 Oct 2002, Greg KH wrote:
> > [snip]
> > > Anyway, this is a nice diversion from the real problem here, for 2.4,
> > > should I just backport the pci_ops changes which will allow pci
> > > hotplugging to work again on ia64, or do we want to do something else?
> >
> > It would be nice from a hotplug driver maintenance point of view if the
> > 2.4 and 2.5 interfaces were the same IMO.
>
> Yes it would be, but it's not a necessary thing :)

Yeah, yeah, I can deal. ;)

> > How about submitting the change in 2.4.21-pre?
>
> It is a _very_ big change.  It hits every architecture.  It was the
> right thing to do in 2.5, I'm just questioning if it's the right thing
> to do in 2.4 because of the magnitude of it.
>
> So, if people say it's ok, I'll do it.  But I would like to hear from
> the PPC64 group first, as I know I caused them a lot of grief and rework
> because of it.

I hadn't realized the magnitude of the changes from the previous
discussion here on the list, my apologies.

Scott
(Continue reading)

Bob Miller | 1 Nov 02:20 2002

Re: [PATCH 2.5.45] Export blkdev_ioctl for raw block driver.

On Thu, Oct 31, 2002 at 07:11:19PM -0500, Alexander Viro wrote:
> 
> 
> On Thu, 31 Oct 2002, Bob Miller wrote:
> 
> > diff -Nru a/kernel/ksyms.c b/kernel/ksyms.c
> > --- a/kernel/ksyms.c	Thu Oct 31 16:47:14 2002
> > +++ b/kernel/ksyms.c	Thu Oct 31 16:47:14 2002
> >  <at>  <at>  -349,6 +349,7  <at>  <at> 
> >  EXPORT_SYMBOL(blkdev_open);
> >  EXPORT_SYMBOL(blkdev_get);
> >  EXPORT_SYMBOL(blkdev_put);
> > +EXPORT_SYMBOL(blkdev_ioctl);
> 
> Why not use ioctl_by_bdev() in the first place?  (and yes, it's very likely
> my fault - I hadn't realized that raw.c went modular at some point).
Didn't know about ioctl_by_bdev()... I'll make a patch that converts
the raw driver to call it instead of blkdev_ioctl().

--

-- 
Bob Miller					Email: rem <at> osdl.org
Open Source Development Lab			Phone: 503.626.2455 Ext. 17
KOCHI, Takayoshi | 1 Nov 01:23 2002
Picon

Re: bare pci configuration access functions ?


On Thu, 31 Oct 2002 15:54:57 -0800
Greg KH <greg <at> kroah.com> wrote:

> > That's the way ACPI driver designers took and Linux can benefit
> > from other OS's feedback in OS-independent part.
> 
> Can I ask if any of the development for other OSs has actually helped
> Linux development?  I'm just curious.

FreeBSD's acpi project is a good example.
http://www.jp.freebsd.org/acpi/index.html
(though this page doesn't seem to reflect recent status)

They share the same code base (OS-independent part) as Linux
and troubles FreeBSD had are troubles Linux will have or vice versa.

Its mailing-list is based in Japan but most discussions
are in English and some intel developers are also in the list.

AFAIK the aic7xxx driver has similar structure.

Thanks,
--

-- 
KOCHI, Takayoshi <t-kouchi <at> cq.jp.nec.com/t-kouchi <at> mvf.biglobe.ne.jp>

Joseph Fannin | 1 Nov 01:24 2002
Picon

Re: [PATCH] [BK] 0/11 Ext2/3 Updates: Extended attributes, ACL, etc.

On Thu, Oct 31, 2002 at 03:28:29AM -0500, tytso <at> mit.edu wrote:
> Hi Linus,
> 
> I've updated the ext2/3 patches for 2.5.45.  All of these changes can
> also be grabbed by pulling from:
> 
> 	bk://extfs.bkbits.net/extfs-2.5-update
> 
> Linus, please pull; these patches have been tested as part of Andrew
> Morton's mm tree, and have minimal risks if the relevant config turned
> off.  (People have also been using the ACL and Extended Attributes
> patches enabled for quite some time as well.  :-)
> 
> A complete set of all of these patches can also be found at:
> 
>         http://thunk.org/tytso/linux/extfs-2.5
> 
> 						- Ted

   ld -m elf_i386  -r -o init/built-in.o init/main.o init/version.o init/do_mounts.o
        ld -m elf_i386 -e stext -T arch/i386/vmlinux.lds.s arch/i386/kernel/head.o
arch/i386/kernel/init_task.o  init/built-in.o --start-group  arch/i386/kernel/built-in.o 
arch/i386/mm/built-in.o  arch/i386/mach-generic/built-in.o  kernel/built-in.o  mm/built-in.o 
fs/built-in.o  ipc/built-in.o  security/built-in.o  crypto/built-in.o  lib/lib.a 
arch/i386/lib/lib.a  drivers/built-in.o  sound/built-in.o  arch/i386/pci/built-in.o 
net/built-in.o --end-group  -o vmlinux
fs/built-in.o(.text+0x42d8a): In function `ext3_xattr_put_super':
: undefined reference to `mb_cache_shrink'
fs/built-in.o(.text+0x42dc2): In function `ext3_xattr_cache_insert':
: undefined reference to `mb_cache_entry_alloc'
(Continue reading)

Jamie Lokier | 1 Nov 01:32 2002
Picon
Picon

Re: Unifying epoll,aio,futexes etc. (What I really want from epoll)

Rusty Russell wrote:
> I think a naive implementation of futex_set_wait would look like:

Vaguely.  We are looking for something with the queue-like semantics
of epoll and rt-signals: persistent (as opposed to one-shot)
listening, ordered delivery of events, scalable listening to thousands
at once (without the poll/select O(n) problem).

> Not sure I get the point about livelock though: deadlock is possible if
> apps seek multiple locks at once without care, of course.

I'm not sure what Alan meant either.

-- Jamie

-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Gmane