Re: CVS commit: src/sys
Yeah, in retrospect that would probably have been a simpler course to
follow.
I'd be happy to re-work this if you want, but it will probably take a
couple days - the day job needs some attention right now.
On Tue, 25 May 2010, David Young wrote:
On Mon, May 24, 2010 at 08:29:49PM +, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Mon May 24 20:29:49 UTC 2010
Modified Files:
src/sys/arch/i386/pci: gcscehci.c
src/sys/dev/cardbus: ehci_cardbus.c ohci_cardbus.c uhci_cardbus.c
src/sys/dev/pci: azalia.c cs4280.c ehci_pci.c ohci_pci.c uhci_pci.c
Log Message:
Update all callers of the pci_find{vendor,product} routines to now call
these routines through their global pointers.
It was not necessary to change all of the pci_find{vendor,product}
calls, was it? You could have tucked the call through
pci_find{vendor,product}_vec into pci_find{vendor,product}() like this:
const char *
pci_findvendor(pcireg_t id)
{
return (*pci_findvendor_vec)(id);
}
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 278-3933
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: CVS commit: src/sys
On Mon, May 24, 2010 at 08:29:49PM +, Paul Goyette wrote:
> Module Name: src
> Committed By: pgoyette
> Date: Mon May 24 20:29:49 UTC 2010
>
> Modified Files:
> src/sys/arch/i386/pci: gcscehci.c
> src/sys/dev/cardbus: ehci_cardbus.c ohci_cardbus.c uhci_cardbus.c
> src/sys/dev/pci: azalia.c cs4280.c ehci_pci.c ohci_pci.c uhci_pci.c
>
> Log Message:
> Update all callers of the pci_find{vendor,product} routines to now call
> these routines through their global pointers.
It was not necessary to change all of the pci_find{vendor,product}
calls, was it? You could have tucked the call through
pci_find{vendor,product}_vec into pci_find{vendor,product}() like this:
const char *
pci_findvendor(pcireg_t id)
{
return (*pci_findvendor_vec)(id);
}
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: CVS commit: src/sys/dev/ieee1394
On May 24, 10:32pm, kiyoh...@kk.iij4u.or.jp (KIYOHARA Takashi) wrote: -- Subject: Re: CVS commit: src/sys/dev/ieee1394 | Hi! | | | From: Izumi Tsutsui | Date: Mon, 24 May 2010 22:08:21 +0900 | | > > Why you revert it all? | > | > Wasn't it broken? | | Yes. It knows I was broken, too. However, it worked on my ofppc and | it booted my amd64. Try booting with DIAGNOSTIC. If you make any changes to the kernel you should be really compiling with DIAGNOSTIC. | > > I had been investigating the problem of kmem since last week. Was not | > | > There is no reason to leave kernels broken even if | > you have some idea for proper fixes. | | In many cases, there is a case that cannot be fixed in several days. For | instance, MIPS cannot be booted since merge mips64. This is not also not acceptable it has pissed off everyone owning a MIPS box who cannot boot current. If I had a MIPS box and could test this, I would have reverted the MIPS changes too. (Hi Matt!). I just want to highlight that this is not personal and it does not matter who makes the changes. If you break HEAD and you leave it broken for days, without communicating status, consider your changes a candidate for backout. I want to also stress that I tried to fix the firewire code; I fixed two issues already, and then I saw that it would require a lot of reworking to fix the xfer code. I filed a PR, and I backed out the changes because in my judgement there is no quick and easy fix for it. Prove me wrong and commit today or tomorrow a change that works. christos
Re: CVS commit: src/sys/dev/ieee1394
> In many cases, there is a case that cannot be fixed in several days. For In any case you should revert your changes first if you know you broke the tree and you can't fix it soon. --- Izumi Tsutsui
Re: CVS commit: src/sys/dev/ieee1394
Hi! From: Izumi Tsutsui Date: Mon, 24 May 2010 22:08:21 +0900 > > Why you revert it all? > > Wasn't it broken? Yes. It knows I was broken, too. However, it worked on my ofppc and it booted my amd64. > > I had been investigating the problem of kmem since last week. Was not > > There is no reason to leave kernels broken even if > you have some idea for proper fixes. In many cases, there is a case that cannot be fixed in several days. For instance, MIPS cannot be booted since merge mips64. Thanks, -- kiyohara
Re: CVS commit: src/sys/dev/ieee1394
> Why you revert it all? Wasn't it broken? > I had been investigating the problem of kmem since last week. Was not There is no reason to leave kernels broken even if you have some idea for proper fixes. You can put them even after you (or other guys) revert the previous changes, can't you? --- Izumi Tsutsui
Re: CVS commit: src/sys/dev/ieee1394
On May 24, 2:23pm, kiyoh...@kk.iij4u.or.jp (KIYOHARA Takashi) wrote: -- Subject: Re: CVS commit: src/sys/dev/ieee1394 | Hi! Christos, | | | From: Christos Zoulas | Date: Sun, 23 May 2010 14:56:59 -0400 | | > Module Name:src | > Committed By: christos | > Date: Sun May 23 18:56:59 UTC 2010 | > | > Modified Files: | > src/sys/dev/ieee1394: firewire.c firewirereg.h fwdev.c fwdma.c fwmem.c | > fwohci.c fwohcivar.h if_fwip.c sbp.c | > | > Log Message: | > Revert all previous kmem_ commits. This needs to be done in a different way | > because we cannot call kmem_ from an interrupt context. I opened PR/43341 for | > it. | | Why you revert it all? | I had been investigating the problem of kmem since last week. Was not | I reading the message from you? It is all in CVS, none of the changes are lost so I don't see the problem. If you sent mail saying that you were working on it and when you expected to have it fixed, sorry I missed it. The code has been broken since the 15th, so I thought I should do something. christos
