unchecked request_region's in drivers/net
RFC PATCH 1/1 unchecked request_region's in drivers/net
This patch corrects the request_region calls in drivers/net to have their return value checked, and fail appropriately. Additionally, the check_region calls have been removed where prudent.
I'd like volunteers to test and comment on the patch; if the general consensus is that it's good, I'd like to see it integrated.
Patch is against kernel 2.4.17, should apply to 2.5 as well.
Thanks
Signature · 498 lines
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
He's alive. He's alive! Oh, that fellow at RadioShack said I was mad!
Well, who's mad now?
-- Montgomery C. Burns
diff -Nru clean-2.4.17//drivers/net/appletalk/ltpc.c linux/drivers/net/appletalk/ltpc.c
--- clean-2.4.17//drivers/net/appletalk/ltpc.c Mon Nov 5 19:22:09 2001
+++ linux/drivers/net/appletalk/ltpc.c Thu Dec 27 13:28:17 2001
@@ -1081,7 +1081,8 @@
if(io) {
/* found it, now grab it */
- request_region(io,8,"ltpc");
+ if (!request_region(io,8,"ltpc"))
+ return -1;
} else {
/* give up in despair */
printk ("LocalTalk card not found; 220 = %02x, 240 = %02x.\n",
diff -Nru clean-2.4.17//drivers/net/arcnet/com90io.c linux/drivers/net/arcnet/com90io.c
--- clean-2.4.17//drivers/net/arcnet/com90io.c Mon Nov 5 19:24:25 2001
+++ linux/drivers/net/arcnet/com90io.c Thu Dec 27 13:30:57 2001
@@ -241,7 +241,8 @@
return -ENODEV;
}
/* Reserve the I/O region - guaranteed to work by check_region */
- request_region(dev->base_addr, ARCNET_TOTAL_SIZE, "arcnet (COM90xx-IO)");
+ if (!request_region(dev->base_addr, ARCNET_TOTAL_SIZE, "arcnet (COM90xx-IO)"))
+ return -EBUSY;
/* Initialize the rest of the device structure. */
dev->priv = kmalloc(sizeof(struct arcnet_local), GFP_KERNEL);
diff -Nru clean-2.4.17//drivers/net/arcnet/com90xx.c linux/drivers/net/arcnet/com90xx.c
--- clean-2.4.17//drivers/net/arcnet/com90xx.c Mon Nov 5 19:24:25 2001
+++ linux/drivers/net/arcnet/com90xx.c Thu Dec 27 13:32:25 2001
@@ -479,7 +479,9 @@
dev->irq = airq;
/* reserve the I/O and memory regions - guaranteed to work by check_region */
- request_region(ioaddr, ARCNET_TOTAL_SIZE, "arcnet (90xx)");
+ if (!request_region(ioaddr, ARCNET_TOTAL_SIZE, "arcnet (90xx)"))
+ goto err_release;
+
request_mem_region(dev->mem_start, dev->mem_end - dev->mem_start + 1, "arcnet (90xx)");
dev->base_addr = ioaddr;
diff -Nru clean-2.4.17//drivers/net/de4x5.c linux/drivers/net/de4x5.c
--- clean-2.4.17//drivers/net/de4x5.c Mon Nov 5 19:23:11 2001
+++ linux/drivers/net/de4x5.c Thu Dec 27 13:34:03 2001
@@ -1296,9 +1296,10 @@
barrier();
- request_region(iobase, (lp->bus == PCI ? DE4X5_PCI_TOTAL_SIZE :
+ if (!request_region(iobase, (lp->bus == PCI ? DE4X5_PCI_TOTAL_SIZE :
DE4X5_EISA_TOTAL_SIZE),
- lp->adapter_name);
+ lp->adapter_name))
+ return -EBUSY;
lp->rxRingSize = NUM_RX_DESC;
lp->txRingSize = NUM_TX_DESC;
diff -Nru clean-2.4.17//drivers/net/de600.c linux/drivers/net/de600.c
--- clean-2.4.17//drivers/net/de600.c Mon Nov 5 19:23:11 2001
+++ linux/drivers/net/de600.c Thu Dec 27 13:34:28 2001
@@ -689,7 +689,8 @@
return -EBUSY;
}
#endif
- request_region(DE600_IO, 3, "de600");
+ if (!request_region(DE600_IO, 3, "de600"))
+ return -EBUSY
printk(", Ethernet Address: %02X", dev->dev_addr[0]);
for (i = 1; i < ETH_ALEN; i++)
diff -Nru clean-2.4.17//drivers/net/eepro.c linux/drivers/net/eepro.c
--- clean-2.4.17//drivers/net/eepro.c Fri Nov 23 11:11:44 2001
+++ linux/drivers/net/eepro.c Thu Dec 27 13:35:30 2001
@@ -828,7 +828,9 @@
}
/* Grab the region so we can find another board if autoIRQ fails. */
- request_region(ioaddr, EEPRO_IO_EXTENT, dev->name);
+ if (!request_region(ioaddr, EEPRO_IO_EXTENT,
+ dev->name))
+ return -EBUSY;
((struct eepro_local *)dev->priv)->lock = SPIN_LOCK_UNLOCKED;
diff -Nru clean-2.4.17//drivers/net/ewrk3.c linux/drivers/net/ewrk3.c
--- clean-2.4.17//drivers/net/ewrk3.c Mon Nov 5 19:23:12 2001
+++ linux/drivers/net/ewrk3.c Thu Dec 27 13:40:31 2001
@@ -537,7 +537,6 @@
lp->mPage <<= 1; /* 2 DRAMS on module */
sprintf(lp->adapter_name, "%s (%s)", name, dev->name);
- request_region(iobase, EWRK3_TOTAL_SIZE, lp->adapter_name);
lp->irq_mask = ICR_TNEM | ICR_TXDM | ICR_RNEM | ICR_RXDM;
@@ -1271,7 +1270,7 @@
}
for (; (i < maxSlots) && (dev != NULL); iobase += EWRK3_IOP_INC, i++) {
- if (!check_region(iobase, EWRK3_TOTAL_SIZE)) {
+ if (request_region(iobase, EWRK3_TOTAL_SIZE, dev->name)) {
if (DevicePresent(iobase) == 0) {
if ((dev = alloc_device(dev, iobase)) != NULL) {
if (ewrk3_hw_init(dev, iobase) == 0) {
@@ -1315,7 +1314,7 @@
for (i = 1; (i < maxSlots) && (dev != NULL); i++, iobase += EISA_SLOT_INC) {
if (EISA_signature(name, EISA_ID) == 0) {
- if (!check_region(iobase, EWRK3_TOTAL_SIZE)) {
+ if (request_region(iobase, EWRK3_TOTAL_SIZE, dev->name)) {
if (DevicePresent(iobase) == 0) {
if ((dev = alloc_device(dev, iobase)) != NULL) {
if (ewrk3_hw_init(dev, iobase) == 0) {
diff -Nru clean-2.4.17//drivers/net/gt96100eth.c linux/drivers/net/gt96100eth.c
--- clean-2.4.17//drivers/net/gt96100eth.c Mon Nov 5 19:24:01 2001
+++ linux/drivers/net/gt96100eth.c Thu Dec 27 13:55:39 2001
@@ -493,7 +493,8 @@
printk(KERN_INFO "gt96100_probe1: ioaddr 0x%lx, irq %d\n",
ioaddr, irq);
- request_region(ioaddr, GT96100_ETH_IO_SIZE, "GT96100ETH");
+ if (!request_region(ioaddr, GT96100_ETH_IO_SIZE, "GT96100ETH"))
+ return -EBUSY;
cpuConfig = GT96100_READ(GT96100_CPU_INTERF_CONFIG);
if (cpuConfig & (1 << 12)) {
diff -Nru clean-2.4.17//drivers/net/hamradio/baycom_ser_fdx.c linux/drivers/net/hamradio/baycom_ser_fdx.c
--- clean-2.4.17//drivers/net/hamradio/baycom_ser_fdx.c Thu Aug 16 15:50:30 2001
+++ linux/drivers/net/hamradio/baycom_ser_fdx.c Thu Dec 27 13:58:40 2001
@@ -417,7 +417,8 @@
return -ENXIO;
if (bc->baud < 300 || bc->baud > 4800)
return -EINVAL;
- if (check_region(dev->base_addr, SER12_EXTENT))
+ if (!request_region(dev->base_addr, SER12_EXTENT,
+ "baycom_ser_fdx"))
return -EACCES;
memset(&bc->modem, 0, sizeof(bc->modem));
bc->hdrv.par.bitrate = bc->baud;
@@ -431,7 +432,6 @@
if (request_irq(dev->irq, ser12_interrupt, SA_INTERRUPT | SA_SHIRQ,
"baycom_ser_fdx", dev))
return -EBUSY;
- request_region(dev->base_addr, SER12_EXTENT, "baycom_ser_fdx");
/*
* set the SIO to 6 Bits/character; during receive,
* the baud rate is set to produce 100 ints/sec
diff -Nru clean-2.4.17//drivers/net/hamradio/baycom_ser_hdx.c linux/drivers/net/hamradio/baycom_ser_hdx.c
--- clean-2.4.17//drivers/net/hamradio/baycom_ser_hdx.c Thu Aug 16 15:50:30 2001
+++ linux/drivers/net/hamradio/baycom_ser_hdx.c Thu Dec 27 13:58:08 2001
@@ -476,7 +476,7 @@
if (!dev->base_addr || dev->base_addr > 0x1000-SER12_EXTENT ||
dev->irq < 2 || dev->irq > 15)
return -ENXIO;
- if (check_region(dev->base_addr, SER12_EXTENT))
+ if (!request_region(dev->base_addr, SER12_EXTENT, "baycom_ser12"))
return -EACCES;
memset(&bc->modem, 0, sizeof(bc->modem));
bc->hdrv.par.bitrate = 1200;
@@ -488,7 +488,6 @@
if (request_irq(dev->irq, ser12_interrupt, SA_INTERRUPT | SA_SHIRQ,
"baycom_ser12", dev))
return -EBUSY;
- request_region(dev->base_addr, SER12_EXTENT, "baycom_ser12");
/*
* enable transmitter empty interrupt
*/
diff -Nru clean-2.4.17//drivers/net/hamradio/scc.c linux/drivers/net/hamradio/scc.c
--- clean-2.4.17//drivers/net/hamradio/scc.c Mon Nov 5 19:24:25 2001
+++ linux/drivers/net/hamradio/scc.c Thu Dec 27 14:00:34 2001
@@ -1788,7 +1788,6 @@
#ifndef SCC_DONT_CHECK
disable_irq(hwcfg.irq);
- check_region(scc->ctrl, 1);
Outb(hwcfg.ctrl_a, 0);
OutReg(hwcfg.ctrl_a, R9, FHWRES);
udelay(100);
@@ -1842,8 +1841,9 @@
if (found)
{
- request_region(SCC_Info[2*Nchips+chan].ctrl, 1, "scc ctrl");
- request_region(SCC_Info[2*Nchips+chan].data, 1, "scc data");
+ if (!request_region(SCC_Info[2*Nchips+chan].ctrl, 1, "scc ctrl") ||
+ !request_region(SCC_Info[2*Nchips+chan].data, 1, "scc data"))
+ continue;
if (Nchips+chan != 0)
scc_net_setup(&SCC_Info[2*Nchips+chan], device_name, 1);
}
diff -Nru clean-2.4.17//drivers/net/hamradio/yam.c linux/drivers/net/hamradio/yam.c
--- clean-2.4.17//drivers/net/hamradio/yam.c Mon Nov 5 19:23:12 2001
+++ linux/drivers/net/hamradio/yam.c Thu Dec 27 14:02:40 2001
@@ -848,7 +848,7 @@
dev->irq < 2 || dev->irq > 15) {
return -ENXIO;
}
- if (check_region(dev->base_addr, YAM_EXTENT)) {
+ if (!request_region(dev->base_addr, YAM_EXTENT), dev->name) {
printk(KERN_ERR "%s: cannot 0x%lx busy\n", dev->name, dev->base_addr);
return -EACCES;
}
@@ -865,7 +865,6 @@
printk(KERN_ERR "%s: irq %d busy\n", dev->name, dev->irq);
return -EBUSY;
}
- request_region(dev->base_addr, YAM_EXTENT, dev->name);
yam_set_uart(dev);
diff -Nru clean-2.4.17//drivers/net/irda/ali-ircc.c linux/drivers/net/irda/ali-ircc.c
--- clean-2.4.17//drivers/net/irda/ali-ircc.c Mon Nov 5 19:23:13 2001
+++ linux/drivers/net/irda/ali-ircc.c Thu Dec 27 14:08:34 2001
@@ -291,15 +291,13 @@
self->io.fifo_size = 16; /* SIR: 16, FIR: 32 Benjamin 2000/11/1 */
/* Reserve the ioports that we need */
- ret = check_region(self->io.fir_base, self->io.fir_ext);
- if (ret < 0) {
+ if (!request_region(self->io.fir_base, self->io.fir_ext, driver_name)) {
WARNING(__FUNCTION__ "(), can't get iobase of 0x%03x\n",
self->io.fir_base);
dev_self[i] = NULL;
kfree(self);
return -ENODEV;
}
- request_region(self->io.fir_base, self->io.fir_ext, driver_name);
/* Initialize QoS for this device */
irda_init_max_qos_capabilies(&self->qos);
diff -Nru clean-2.4.17//drivers/net/irda/irport.c linux/drivers/net/irda/irport.c
--- clean-2.4.17//drivers/net/irda/irport.c Mon Nov 5 19:23:13 2001
+++ linux/drivers/net/irda/irport.c Thu Dec 27 14:06:16 2001
@@ -169,13 +169,11 @@
self->io.fifo_size = 16;
/* Lock the port that we need */
- ret = check_region(self->io.sir_base, self->io.sir_ext);
- if (ret < 0) {
+ if (!request_region(self->io.sir_base, self->io.sir_ext, driver_name)) {
IRDA_DEBUG(0, __FUNCTION__ "(), can't get iobase of 0x%03x\n",
self->io.sir_base);
return NULL;
}
- request_region(self->io.sir_base, self->io.sir_ext, driver_name);
/* Initialize QoS for this device */
irda_init_max_qos_capabilies(&self->qos);
diff -Nru clean-2.4.17//drivers/net/irda/nsc-ircc.c linux/drivers/net/irda/nsc-ircc.c
--- clean-2.4.17//drivers/net/irda/nsc-ircc.c Mon Nov 5 19:23:13 2001
+++ linux/drivers/net/irda/nsc-ircc.c Thu Dec 27 14:08:03 2001
@@ -282,15 +282,13 @@
self->io.fifo_size = 32;
/* Reserve the ioports that we need */
- ret = check_region(self->io.fir_base, self->io.fir_ext);
- if (ret < 0) {
+ if (!request_region(self->io.fir_base, self->io.fir_ext, driver_name)) {
WARNING(__FUNCTION__ "(), can't get iobase of 0x%03x\n",
self->io.fir_base);
dev_self[i] = NULL;
kfree(self);
return -ENODEV;
}
- request_region(self->io.fir_base, self->io.fir_ext, driver_name);
/* Initialize QoS for this device */
irda_init_max_qos_capabilies(&self->qos);
diff -Nru clean-2.4.17//drivers/net/irda/w83977af_ir.c linux/drivers/net/irda/w83977af_ir.c
--- clean-2.4.17//drivers/net/irda/w83977af_ir.c Mon Nov 5 19:23:13 2001
+++ linux/drivers/net/irda/w83977af_ir.c Thu Dec 27 14:07:23 2001
@@ -190,14 +190,12 @@
self->io.fifo_size = 32;
/* Lock the port that we need */
- ret = check_region(self->io.fir_base, self->io.fir_ext);
- if (ret < 0) {
+ if (!request_region(self->io.fir_base, self->io.fir_ext, driver_name)) {
IRDA_DEBUG(0, __FUNCTION__ "(), can't get iobase of 0x%03x\n",
self->io.fir_base);
/* w83977af_cleanup( self); */
return -ENODEV;
}
- request_region(self->io.fir_base, self->io.fir_ext, driver_name);
/* Initialize QoS for this device */
irda_init_max_qos_capabilies(&self->qos);
diff -Nru clean-2.4.17//drivers/net/isa-skeleton.c linux/drivers/net/isa-skeleton.c
--- clean-2.4.17//drivers/net/isa-skeleton.c Mon Nov 5 19:24:01 2001
+++ linux/drivers/net/isa-skeleton.c Thu Dec 27 14:09:17 2001
@@ -281,7 +281,8 @@
spin_lock_init(&np->lock);
/* Grab the region so that no one else tries to probe our ioports. */
- request_region(ioaddr, NETCARD_IO_EXTENT, cardname);
+ if (!request_region(ioaddr, NETCARD_IO_EXTENT, cardname))
+ return -EBUSY;
dev->open = net_open;
dev->stop = net_close;
diff -Nru clean-2.4.17//drivers/net/ni5010.c linux/drivers/net/ni5010.c
--- clean-2.4.17//drivers/net/ni5010.c Mon Nov 5 19:23:13 2001
+++ linux/drivers/net/ni5010.c Thu Dec 27 14:10:35 2001
@@ -308,7 +308,8 @@
memset(dev->priv, 0, sizeof(struct ni5010_local));
/* Grab the region so we can find another board if autoIRQ fails. */
- request_region(ioaddr, NI5010_IO_EXTENT, boardname);
+ if (!request_region(ioaddr, NI5010_IO_EXTENT, boardname))
+ return -EBUSY;
dev->open = ni5010_open;
dev->stop = ni5010_close;
diff -Nru clean-2.4.17//drivers/net/ni65.c linux/drivers/net/ni65.c
--- clean-2.4.17//drivers/net/ni65.c Mon Nov 5 19:23:13 2001
+++ linux/drivers/net/ni65.c Thu Dec 27 14:11:21 2001
@@ -473,7 +473,8 @@
/*
* Grab the region so we can find another board.
*/
- request_region(ioaddr,cards[p->cardno].total_size,cards[p->cardno].cardname);
+ if (!request_region(ioaddr,cards[p->cardno].total_size,cards[p->cardno].cardname))
+ return -EBUSY;
dev->base_addr = ioaddr;
diff -Nru clean-2.4.17//drivers/net/sb1000.c linux/drivers/net/sb1000.c
--- clean-2.4.17//drivers/net/sb1000.c Mon Nov 5 19:23:13 2001
+++ linux/drivers/net/sb1000.c Thu Dec 27 14:13:18 2001
@@ -262,8 +262,9 @@
/* Lock resources */
- request_region(ioaddr[0], 16, dev->name);
- request_region(ioaddr[1], 16, dev->name);
+ if (!request_region(ioaddr[0], 16, dev->name) ||
+ !request_region(ioaddr[1], 16, dev->name))
+ return -EBUSY;
return 0;
}
@@ -962,8 +963,9 @@
/* rmem_end holds the second I/O address - fv */
ioaddr[1] = dev->rmem_end;
name = dev->name;
- request_region(ioaddr[0], SB1000_IO_EXTENT, "sb1000");
- request_region(ioaddr[1], SB1000_IO_EXTENT, "sb1000");
+ if (!request_region(ioaddr[0], SB1000_IO_EXTENT, "sb1000") ||
+ !request_region(ioaddr[1], SB1000_IO_EXTENT, "sb1000"))
+ return -EBUSY;
/* initialize sb1000 */
if ((status = sb1000_reset(ioaddr, name)))
diff -Nru clean-2.4.17//drivers/net/tokenring/smctr.c linux/drivers/net/tokenring/smctr.c
--- clean-2.4.17//drivers/net/tokenring/smctr.c Mon Nov 5 19:22:12 2001
+++ linux/drivers/net/tokenring/smctr.c Thu Dec 27 14:15:50 2001
@@ -521,7 +521,8 @@
r2 = mca_read_stored_pos(tp->slot_num, 2);
r2 &= 0xF0;
dev->base_addr = ((__u16)r2 << 8) + (__u16)0x800;
- request_region(dev->base_addr, SMCTR_IO_EXTENT, smctr_name);
+ if (!request_region(dev->base_addr, SMCTR_IO_EXTENT, smctr_name))
+ return -EBUSY;
/* IRQ */
r5 = mca_read_stored_pos(tp->slot_num, 5);
@@ -974,7 +975,8 @@
return (-ENODEV); /* Adapter Not Found */
/* Grab the region so that no one else tries to probe our ioports. */
- request_region(ioaddr, SMCTR_IO_EXTENT, smctr_name);
+ if (!request_region(ioaddr, SMCTR_IO_EXTENT, smctr_name))
+ return -EBUSY;
b = inb(ioaddr + BDID);
if(b != BRD_ID_8115T)
diff -Nru clean-2.4.17//drivers/net/wan/comx-hw-comx.c linux/drivers/net/wan/comx-hw-comx.c
--- clean-2.4.17//drivers/net/wan/comx-hw-comx.c Mon Nov 5 19:22:12 2001
+++ linux/drivers/net/wan/comx-hw-comx.c Thu Dec 27 14:21:17 2001
@@ -466,16 +466,16 @@
}
if (!twin_open) {
- if (check_region(dev->base_addr, hw->io_extent)) {
- return -EAGAIN;
- }
if (request_irq(dev->irq, COMX_interrupt, 0, dev->name,
(void *)dev)) {
printk(KERN_ERR "comx-hw-comx: unable to obtain irq %d\n", dev->irq);
return -EAGAIN;
}
+ if (!request_region(dev->base_addr, hw->io_extent, dev->name)) {
+ free_irq(dev->irq, dev);
+ return -EAGAIN;
+ }
ch->init_status |= IRQ_ALLOCATED;
- request_region(dev->base_addr, hw->io_extent, dev->name);
if (!ch->HW_load_board || ch->HW_load_board(dev)) {
ch->init_status &= ~IRQ_ALLOCATED;
retval=-ENODEV;
diff -Nru clean-2.4.17//drivers/net/wan/comx-hw-locomx.c linux/drivers/net/wan/comx-hw-locomx.c
--- clean-2.4.17//drivers/net/wan/comx-hw-locomx.c Mon Nov 5 19:22:12 2001
+++ linux/drivers/net/wan/comx-hw-locomx.c Thu Dec 27 14:20:11 2001
@@ -154,11 +154,9 @@
return -ENODEV;
}
- if (check_region(dev->base_addr, hw->io_extent)) {
+ if (!request_region(dev->base_addr, hw->io_extent, dev->name)) {
return -EAGAIN;
}
-
- request_region(dev->base_addr, hw->io_extent, dev->name);
hw->board.chanA.ctrlio=dev->base_addr + 5;
hw->board.chanA.dataio=dev->base_addr + 7;
diff -Nru clean-2.4.17//drivers/net/wan/cosa.c linux/drivers/net/wan/cosa.c
--- clean-2.4.17//drivers/net/wan/cosa.c Mon Nov 5 19:22:12 2001
+++ linux/drivers/net/wan/cosa.c Thu Dec 27 14:16:43 2001
@@ -547,7 +547,8 @@
cosa->usage = 0;
cosa->nchannels = 2; /* FIXME: how to determine this? */
- request_region(base, is_8bit(cosa)?2:4, cosa->type);
+ if (!request_region(base, is_8bit(cosa)?2:4, cosa->type))
+ goto bad1;
if (request_irq(cosa->irq, cosa_interrupt, 0, cosa->type, cosa))
goto bad1;
if (request_dma(cosa->dma, cosa->type)) {
diff -Nru clean-2.4.17//drivers/net/wan/lmc/lmc_main.c linux/drivers/net/wan/lmc/lmc_main.c
--- clean-2.4.17//drivers/net/wan/lmc/lmc_main.c Mon Nov 5 19:22:13 2001
+++ linux/drivers/net/wan/lmc/lmc_main.c Thu Dec 27 14:22:37 2001
@@ -945,7 +945,13 @@
* later on, no one else will take our card away from
* us.
*/
- request_region (ioaddr, LMC_REG_RANGE, dev->name);
+ if (!request_region (ioaddr, LMC_REG_RANGE, dev->name)) {
+ printk(KERN_ERR "%s: request_region failed.\n", dev->name);
+ lmc_proto_detach(sc);
+ kfree(dev->priv);
+ kfree(dev);
+ return NULL;
+ }
sc->lmc_cardtype = LMC_CARDTYPE_UNKNOWN;
sc->lmc_timing = LMC_CTL_CLOCK_SOURCE_EXT;
diff -Nru clean-2.4.17//drivers/net/wan/sdlamain.c linux/drivers/net/wan/sdlamain.c
--- clean-2.4.17//drivers/net/wan/sdlamain.c Mon Nov 5 19:22:13 2001
+++ linux/drivers/net/wan/sdlamain.c Thu Dec 27 14:17:44 2001
@@ -603,8 +603,9 @@
/* Reserve I/O region and schedule background task */
- if(card->hw.type != SDLA_S514 && !card->wandev.piggyback)
- request_region(card->hw.port, card->hw.io_range, wandev->name);
+ if(card->hw.type != SDLA_S514 && !card->wandev.piggyback) {
+ if (!request_region(card->hw.port, card->hw.io_range, wandev->name))
+ return -EBUSY;
/* Only use the polling routine for the X25 protocol */
diff -Nru clean-2.4.17//drivers/net/wan/sealevel.c linux/drivers/net/wan/sealevel.c
--- clean-2.4.17//drivers/net/wan/sealevel.c Mon Nov 5 19:23:14 2001
+++ linux/drivers/net/wan/sealevel.c Thu Dec 27 14:18:21 2001
@@ -219,12 +219,11 @@
* Get the needed I/O space
*/
- if(check_region(iobase, 8))
+ if(!request_region(iobase, 8, "Sealevel 4021"))
{
printk(KERN_WARNING "sealevel: I/O 0x%X already in use.\n", iobase);
return NULL;
}
- request_region(iobase, 8, "Sealevel 4021");
b=(struct slvl_board *)kmalloc(sizeof(struct slvl_board), GFP_KERNEL);
if(!b)
diff -Nru clean-2.4.17//drivers/net/wavelan.c linux/drivers/net/wavelan.c
--- clean-2.4.17//drivers/net/wavelan.c Mon Nov 5 19:24:01 2001
+++ linux/drivers/net/wavelan.c Thu Dec 27 14:23:08 2001
@@ -4019,7 +4019,8 @@
dev->irq = irq;
- request_region(ioaddr, sizeof(ha_t), "wavelan");
+ if (!request_region(ioaddr, sizeof(ha_t), "wavelan"))
+ return -EBUSY;
dev->mem_start = 0x0000;
dev->mem_end = 0x0000;Em Thu, Dec 27, 2001 at 02:38:12PM -0600, Steven Walter escreveu:
Quoted 7 lines
This patch corrects the
request_regioncalls indrivers/netto have their return value checked, and fail appropriately. Additionally, thecheck_regioncalls have been removed where prudent.I'd like volunteers to test and comment on the patch; if the general consensus is that it's good, I'd like to see it integrated.
Patch is against kernel 2.4.17, should apply to 2.5 as well.
Good job! But please consider splitting the patch per driver and sending it to the respective maintainers.
- Arnaldo
Quoted 3 lines · Arnaldo Carvalho de Melo
Quoted 1 line
Patch is against kernel 2.4.17, should apply to 2.5 as well.
Good job! But please consider splitting the patch per driver and sending it to the respective maintainers.
Someone with far too much time on their hands would be my personal hero[*] if they were to write a script (in language of their choice) to parse a diff, extract filename, and do lookup in a flat text file to find a list of maintainers/interested parties.
Imagine a patch against devfs..
$ cclist my.devfs.patch.diff Richard Gooch <[email protected]> Alexander Viro <[email protected]>
SCNR 8-)
This 'little black book of addresses' doesn't have to be anything wonderful, but its tedious work for someone to make the textfile mapping the various source files to email addresses.
Someone (Alan?) suggested having something like a web interface allowing anyone interested in any particular file to register their interest, and get added to the cclist for that file. Which is also a cool idea.
Dave.
[*] At least for a while. I'm fickle.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 10 lines · Dave Jones
Quoted 4 lines · Arnaldo Carvalho de Melo
Quoted 1 line
Patch is against kernel 2.4.17, should apply to 2.5 as well.
Good job! But please consider splitting the patch per driver and sending it to the respective maintainers.
Someone with far too much time on their hands would be my personal hero[*] if they were to write a script (in language of their choice) to parse a diff, extract filename, and do lookup in a flat text file to find a list of maintainers/interested parties.
Sounds like a good idea; I'll give it a shot over the next few days, unless someone already has one :)
Quoted 5 lines
Imagine a patch against devfs..
$ cclist my.devfs.patch.diff Richard Gooch <[email protected]> Alexander Viro <[email protected]>
I'd add one level of abstraction: have each filename map to a "module" name. In this case, each filename relating to devfs would map to module "devfs"; there would then be an entry mapping devfs <-> Richard.
(Perhaps a hierarchy - fs.devfs - with people like Al listed for "fs"?)
Quoted 3 lines
This 'little black book of addresses' doesn't have to be anything wonderful, but its tedious work for someone to make the textfile mapping the various source files to email addresses.
It should be a little easier having a mapping to a module - in most cases, there's a clear "module" to which each file belongs. Then just track who's "subscribed to" that module...
James.
Quoted 4 lines · James A Sutherland
I'd add one level of abstraction: have each filename map to a "module" name. In this case, each filename relating to devfs would map to module "devfs"; there would then be an entry mapping devfs <-> Richard.
(Perhaps a hierarchy - fs.devfs - with people like Al listed for "fs"?)
Could work, but there are some bits that have no maintainer as such, eg, the pci irq routing. There have been several interested parties hacking on it however. A means of having people add themselves to the list would be a 'must have' feature.
Quoted 3 lines
It should be a little easier having a mapping to a module - in most cases, there's a clear "module" to which each file belongs. Then just track who's "subscribed to" that module...
Having a mapping from kernel source filename -> email address would still be preferred personally.
$ cclist devfs
is really not much of an improvement over
$ grep -C3 -i devfs MAINTAINERS
Other than the addition of extra 'interested, cc me too' people.
The only problem with my original idea is that its a pita to keep up to date. kernel files get added and removed on a weekly (sometimes daily) basis. Whoever is dumb^Wwonderful enough to volunteer to maintain such a database is likely to have their work cut out for them, so maybe your module idea is preferable.
Hmmm..
Dave.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 10 lines · Dave Jones
Quoted 4 lines · James A Sutherland
I'd add one level of abstraction: have each filename map to a "module" name. In this case, each filename relating to devfs would map to module "devfs"; there would then be an entry mapping devfs <-> Richard. (Perhaps a hierarchy - fs.devfs - with people like Al listed for "fs"?)
Could work, but there are some bits that have no maintainer as such, eg, the pci irq routing. There have been several interested parties hacking on it however. A means of having people add themselves to the list would be a 'must have' feature.
Yes. Something like mailman's approach, perhaps? (You set a password when you subscribe, then you can see and change which modules you are subscribed to using that password.)
Quoted 6 lines
Quoted 3 lines
It should be a little easier having a mapping to a module - in most cases, there's a clear "module" to which each file belongs. Then just track who's "subscribed to" that module...
Having a mapping from kernel source filename -> email address would still be preferred personally.
You would still have that feature: my script was intended to take patches, filenames or modulenames as input, and list the interested parties and/or module names.
So...
$ cclist -m big_patch fs/devfs arch/x86
$ cclist -f fs/devfs/base.c Richard Gooch <...> Al Viro <...>
Quoted 7 lines
$ cclist devfsis really not much of an improvement over
$ grep -C3 -i devfs MAINTAINERSOther than the addition of extra 'interested, cc me too' people.
And tracking of filename<->module relationships, allowing you to look up who would be interested in a given patch.
Quoted 5 lines
The only problem with my original idea is that its a pita to keep up to date. kernel files get added and removed on a weekly (sometimes daily) basis. Whoever is dumb^Wwonderful enough to volunteer to maintain such a database is likely to have their work cut out for them, so maybe your module idea is preferable.
In the way I'm suggesting, it just simplifies matters a little: rather than having to list RG and AV separately for every single file in devfs, just say "this new file is part of devfs" and it "inherits" them that way.
James.
Quoted 3 lines · James A Sutherland
In the way I'm suggesting, it just simplifies matters a little: rather than having to list RG and AV separately for every single file in devfs, just say "this new file is part of devfs" and it "inherits" them that way.
gotcha, sounds ok to me, still quite a bit of work to build the database needed for this, but as several others have pointed out, this would save so much time for anyone who sends out lots of patches.
Dave.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 19 lines · Dave Jones
Quoted 3 lines · Arnaldo Carvalho de Melo
Quoted 1 line
Patch is against kernel 2.4.17, should apply to 2.5 as well.
Good job! But please consider splitting the patch per driver and sending it to the respective maintainers.
Someone with far too much time on their hands would be my personal hero[*] if they were to write a script (in language of their choice) to parse a diff, extract filename, and do lookup in a flat text file to find a list of maintainers/interested parties.
Imagine a patch against devfs..
$ cclist my.devfs.patch.diff Richard Gooch <[email protected]> Alexander Viro <[email protected]>SCNR 8-)
Quoted 8 lines
This 'little black book of addresses' doesn't have to be anything wonderful, but its tedious work for someone to make the textfile mapping the various source files to email addresses.
Someone (Alan?) suggested having something like a web interface allowing anyone interested in any particular file to register their interest, and get added to the cclist for that file. Which is also a cool idea.
The easy way to do this is to build a tree mirroring the kernel tree with each file containing the addresses of the interest list. Directories would contain a .interest file to indicate interest in the entire directory.
Then a 'curl http://www.kernel.org/interest?file=foo/bar/baz' gets you the interest list.
Unfortunately you need some sort of confirmation step around the 'add interest' bit to avoid people adding you to the root of the tree.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Em Thu, Dec 27, 2001 at 11:44:12PM +0100, Dave Jones escreveu:
Quoted 10 lines · Arnaldo Carvalho de Melo
Quoted 4 lines
Quoted 2 lines
Patch is against kernel 2.4.17, should apply to 2.5 as well.
Good job! But please consider splitting the patch per driver and sending it to the respective maintainers.
Someone with far too much time on their hands would be my personal hero[*] if they were to write a script (in language of their choice) to parse a diff, extract filename, and do lookup in a flat text file to find a list of maintainers/interested parties.
Humm, wouldn't it be the case to update MAINTAINERS? Or having something like another file INTERESTED or other better name with addresses of the right person/mailing list to send patches to?
But I like the idea of a web interface so that people interested in specific drivers/files could register and receive it when patches are submitted, maybe this can be coupled with the patchbot idea, that would lookup this database (plain text file, don't worry) and send the message to the interested people.
/me thinks... I think we have this in our linux distribution buildsystem, for people to register interest in particular packages, but that may well be coupled with bugzilla, and that would be too much for this simple system... ok, I'll look into this with the distro folks here.
- Arnaldo
Quoted 13 lines · Dave Jones
Someone with far too much time on their hands would be my personal hero[*] if they were to write a script (in language of their choice) to parse a diff, extract filename, and do lookup in a flat text file to find a list of maintainers/interested parties.
Imagine a patch against devfs..
$ cclist my.devfs.patch.diff Richard Gooch <[email protected]> Alexander Viro <[email protected]>SCNR 8-)
Quoted 8 lines
This 'little black book of addresses' doesn't have to be anything wonderful, but its tedious work for someone to make the textfile mapping the various source files to email addresses.
Someone (Alan?) suggested having something like a web interface allowing anyone interested in any particular file to register their interest, and get added to the cclist for that file. Which is also a cool idea.
Well, in the past I had suggested to ESR (and he agreed) that it would be nice to split up the MAINTAINERS file (and maybe even Configure.help) to be more heirarchical in nature, so that there would be a MAINTAINER file in each directory, and maybe even MAINTAINER.<file> for files in common directories like drivers/net/foo.c. In the top-level MAINTAINER file would only be something like "Marcello Tosatti" to cover the entire tree, and e.g. "David Miller" in the net/MAINTAINER, "Al Viro" in the fs/MAINTAINER, "Stephen Tweedie" in fs/ext3/MAINTAINER, etc.
This way the entire tree has coverage, and if a high-level maintainer gets email for stuff that isn't relevant to them then they create a sub-MAINTAINER file for the things they want to delegate. It could be possible to add a keyword to the file which says "I have full authority for this tree and don't include a higher-level maintainer in cclist output". This would mean that for people like DaveM or arch maintainers who want ALL patches to go through them, it would not list Marcello or Linus in the cclist. For "unmaintained" areas (e.g. drivers) the only person listed would be the top-level maintainer, and it would be easy for him to say "you are the first person to care about this driver in a while, you are now the maintainer".
It might be good (for compatibility sake) to build the top-level MAINTAINERS file from all of the sub-MAINTAINER files in the tree.
This approach doesn't have the "scalability" of the web-based subscription model, but it _does_ have the benefit that it is kept in-sync with the tree that it is distributed with, and it would be a simple script to determine whom to send patches to (i.e. the proposed "cclist" script above would be very easy to write and could be CLI only). I would think the two are complimentary.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Quoted 4 lines · Andreas Dilger
common directories like
drivers/net/foo.c. In the top-level MAINTAINER file would only be something like "Marcello Tosatti" to cover the entire tree, and e.g. "David Miller" in the net/MAINTAINER, "Al Viro" in the fs/MAINTAINER, "Stephen Tweedie" infs/ext3/MAINTAINER, etc.
Indeed, this solves the keeping the list up to date with whats in the tree, and has provision for arbitary numbers of METOO:
fields (Though that could get messy, whats to stop Linus getting bombed with a zillion additions from people who just want to get their name in a kernel tarball for free). One way could be approval from the actual maintainer "Yes, he's sent lots of patches, add him to METOO:".
It does seem a little messy having them scattered all over the tree too. Extending top-level MAINTAINERS to add necessary fields could also be done I suppose.
Dave.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 6 lines · Dave Jones
Quoted 4 lines · Andreas Dilger
common directories like
drivers/net/foo.c. In the top-level MAINTAINER file would only be something like "Marcello Tosatti" to cover the entire tree, and e.g. "David Miller" in the net/MAINTAINER, "Al Viro" in the fs/MAINTAINER, "Stephen Tweedie" infs/ext3/MAINTAINER, etc.
Quoted 7 lines
Indeed, this solves the keeping the list up to date with whats in the tree, and has provision for arbitary numbers of METOO:
fields (Though that could get messy, whats to stop Linus getting bombed with a zillion additions from people who just want to get their name in a kernel tarball for free). One way could be approval from the actual maintainer "Yes, he's sent lots of patches, add him to METOO:".
I'd rather avoid having Linus become a human mailing-list administrator.
Rather, the "METOO" section would be handled by just adding a mailing list address in the relevant MAINTAINER file. The above examples would be covered by linux-kernel, linux-net, linux-fsdevel, and ext2-devel.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Quoted 3 lines
Rather, the "METOO" section would be handled by just adding a mailing list address in the relevant MAINTAINER file. The above examples would be covered by linux-kernel, linux-net, linux-fsdevel, and ext2-devel.
99% of the problem can IMHO be solved by notifying after the event since we have pre-patches and stuff can be handled after a pre anyway. Then its
grep diff for filenames
mail anyone whose regexp matched the list of filename matches
Alan
Hi Andreas.
Quoted 5 lines
Quoted 4 lines
Someone (Alan?) suggested having something like a web interface allowing anyone interested in any particular file to register their interest, and get added to the cclist for that file. Which is also a cool idea.
Quoted 9 lines
Well, in the past I had suggested to ESR (and he agreed) that it would be nice to split up the
MAINTAINERSfile (and maybe even Configure.help) to be more heirarchical in nature, so that there would be a MAINTAINER file in each directory, and maybe even MAINTAINER.<file> for files in common directories likedrivers/net/foo.c. In the top-level MAINTAINER file would only be something like "Marcello Tosatti" to cover the entire tree, and e.g. "David Miller" in the net/MAINTAINER, "Al Viro" in the fs/MAINTAINER, "Stephen Tweedie" infs/ext3/MAINTAINER, etc.
Can I suggest an alternative: Retain the MAINTAINERS file as it currently is, but add a PATCHES-TO file in each subdirectory that states how to handle patches relating to that directory, and have these files follow a strict format, possibly...
===8<=== CUT ===>8===
HomeDir = linux/subsystem/
List = [email protected]
Maintainer = Guess Who <[email protected]> Watch * = Interested <[email protected]> Watch PATCHES-TO = John Doa <[email protected]>
===8<=== CUT ===>8===
...where the lines are as follows...
HOMEDIR = relative-path
The directory in the tree that this PATCHES-TO file belongs in. Must occur exactly once, and must start with linux/ to indicate the base directory this tree has been installed in.
LIST = mailing-list-email-address
A mailing list dealing with this part of the kernel tree. Can be repeated if multiple lists need to be specified, or omitted if there is no specific mailing list for this subsystem.
NEWS = newsgroup
A newsgroup dealing with this part of the kernel tree. Can be repeated if multiple newsgroups need to be specified, or omitted if no newsgroups are relevant to this section of the tree.
MAINTAINER = name <email-address>
The name and email address of the primary maintainer for files in this directory. Can be repeated if multiple maintainers need to be specified. Must occur in the file in the base directory, but can be omitted in any subdirectory in which case it indicates that the maintainer of the parent also maintains this subdirectory.
WATCH filespec = name <email-address>
Specifies that the email address specified is also interested in patches relating to the specified files, and should be CC'd patches relating to just the files specified. Files of interest are selected using ls style wildcards. Can be repeated as often as required for either the same or different files. The filespec can not contain / characters, and only matches files in the current directory.
...and all unrecognised lines are taken to be valid comments and are ignored by all tools.
Comments?
Best wishes from Riley.
Quoted 3 lines
currently is, but add a PATCHES-TO file in each subdirectory that states how to handle patches relating to that directory, and have these files follow a strict format, possibly...
Add the patches to to the maintainers as another field. If the patches go to someone who isnt claiming to be a maintainer something is wrong
Quoted 6 lines · Alan Cox
Quoted 3 lines
currently is, but add a PATCHES-TO file in each subdirectory that states how to handle patches relating to that directory, and have these files follow a strict format, possibly...
Add the patches to to the maintainers as another field. If the patches go to someone who isnt claiming to be a maintainer something is wrong
We'll have to educate viro, then. I bet he won't like it if VFS patches don't get send to him, but he's not listed as a maintainer ...
Rik
Signature · 3 lines
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ http://www.surriel.com/ http://distro.conectiva.com/
Quoted 3 lines
We'll have to educate viro, then. I bet he won't like it if VFS patches don't get send to him, but he's not listed as a maintainer ...
Well you can educate Al, or everyone submitting patches. Al may be a hard nut to crack but there is only one of him ;)
Quoted 6 lines · Alan Cox
Quoted 3 lines
currently is, but add a PATCHES-TO file in each subdirectory that states how to handle patches relating to that directory, and have these files follow a strict format, possibly...
Add the patches to to the maintainers as another field. If the patches go to someone who isnt claiming to be a maintainer something is wrong
Except it seems maintainers is, er, unmaintained... Dave's/my solution looks good from this point of view, allowing others to "subscribe" to track patches to subsystems they care about. As well as allowing Al to remain a "closet maintainer", rather than putting him in maintainers :)
James.
Quoted 16 lines · Riley Williams
Can I suggest an alternative: Retain the
MAINTAINERSfile as it currently is, but add a PATCHES-TO file in each subdirectory that states how to handle patches relating to that directory, and have these files follow a strict format, possibly...===8<=== CUT ===>8===
HomeDir = linux/subsystem/
List = [email protected]
Maintainer = Guess Who <[email protected]> Watch * = Interested <[email protected]> Watch PATCHES-TO = John Doa <[email protected]>===8<=== CUT ===>8===
WATCH filespec = name <email-address>
Quoted 8 lines
Specifies that the email address specified is also interested in patches relating to the specified files, and should be CC'd patches relating to just the files specified. Files of interest are selected using ls style wildcards. Can be repeated as often as required for either the same or different files. The filespec can not contain / characters, and only matches files in the current directory.
I'd rather just skip the WATCH part entirely (or limit it to people already in the MAINTAINERS list). If someone is interested in part of the code, they can subscribe to the mailing list.
Also, if the PATCHES-TO file already lives in a particular subdirectory, I don't see the benefit of HomeDir, except to increase the maintenance work.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Hi Andreas.
Quoted 25 lines
Quoted 16 lines
Can I suggest an alternative: Retain the
MAINTAINERSfile as it currently is, but add a PATCHES-TO file in each subdirectory that states how to handle patches relating to that directory, and have these files follow a strict format, possibly...===8<=== CUT ===>8===
HomeDir = linux/subsystem/
List = [email protected]
Maintainer = Guess Who <[email protected]> Watch * = Interested <[email protected]> Watch PATCHES-TO = John Doa <[email protected]>===8<=== CUT ===>8===
WATCH filespec = name <email-address>Quoted 8 lines
Specifies that the email address specified is also interested in patches relating to the specified files, and should be CC'd patches relating to just the files specified. Files of interest are selected using ls style wildcards. Can be repeated as often as required for either the same or different files. The filespec can not contain / characters, and only matches files in the current directory.
Quoted 2 lines
I'd rather just skip the WATCH part entirely (or limit it to people already in the
MAINTAINERSlist).
That's a policy decision for the maintainers to make.
Quoted 2 lines
If someone is interested in part of the code, they can subscribe to the mailing list.
What if there isn't a mailing list for that part of the code and they can't handle the volume on L-K ???
Quoted 3 lines
Also, if the PATCHES-TO file already lives in a particular subdirectory, I don't see the benefit of HomeDir, except to increase the maintenance work.
Basically, it confirms that you're looking at the right PATCHES-TO file.
Best wishes from Riley.
Em Thu, Dec 27, 2001 at 04:31:30PM -0700, Andreas Dilger escreveu:
Quoted 4 lines · Dave Jones
Well, in the past I had suggested to ESR (and he agreed) that it would be nice to split up the
MAINTAINERSfile (and maybe even Configure.help)
this already happens for the net/ directory to some degree, look at net/README, the problem, as with MAINTAINERS, is that is way outdated, listing Alan, for example, as the maintainer for net/core...
- Arnaldo
Quoted 7 lines · Arnaldo Carvalho de Melo
Em Thu, Dec 27, 2001 at 04:31:30PM -0700, Andreas Dilger escreveu:
Quoted 2 lines
Well, in the past I had suggested to ESR (and he agreed) that it would be nice to split up the
MAINTAINERSfile (and maybe even Configure.help)this already happens for the
net/directory to some degree, look at net/README, the problem, as withMAINTAINERS, is that is way outdated, listing Alan, for example, as the maintainer for net/core...
Well, if the MAINTAINERS file isn't up-to-date (which I know it isn't, see "Remy Card" as ext2 maintainer) then there isn't much that can be done by users/developers to submit patches to the right people at all. I think part of the problem is Linus' hesitance to be authoritarian and add/remove people from the MAINTAINERS list if they don't specifically ask for the change (and submit a patch to that effect).
Yes, long time readers of l-k know that Dave (and Alexy) is the contact for net stuff, and Al is the contact for VFS stuff, but nobody else does. Also, how many emails (in addition to my own) were sent to Remy Card for ext2 fixes (who is even listed with "Maintained" after his name), yet in the entire time I've been working on Linux I have never seen a single email from him (in private or public). Urgh, Remy is also listed in the under the ext3 entry, how did _that_ happen Andrew? MAINTAINERS != CREDITS
Someone (sadly not me) needs to take over MAINTAINERS like ESR took over Configure.help and "ping" all of the maintainers that haven't been heard from and either do some searching for new email addresses, or delete them entirely from the file. This may ruffle a few feathers, but in the end it will just be documenting what "the old boys' network of l-k" already knows and does for patch submission today.
Having a heirarchical MAINTAINER file as I proposed also means:
a) It is closer to the code in question, and _someone_ will be on the hook for the code in that tree, at least until they delegate it elsewhere. The descriptions in the current MAINTAINERS file are sometimes hard to link to specific files if you don't really understand what is going on.
b) It is easier to update more frequently because there are less chances of patch conflicts (minor issue I know).
c) It is easier to keep external patchsets, as they can have their own MAINTAINER (and Configure.help) within the tree.
As for "interested parties", this could rather easily be handled by adding an entry to the MAINTAINER for various parts of the heirarchy which is a mailing list (e.g. [email protected] in mm/MAINTAINER, linux-scsi@... in drivers/scsi/MAINTAINER, etc). These would also be listed by the hypothetical "cclist" tool included with the kernel.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Em Thu, Dec 27, 2001 at 05:11:30PM -0700, Andreas Dilger escreveu:
Quoted 11 lines · Arnaldo Carvalho de Melo
Quoted 3 lines
this already happens for the
net/directory to some degree, look at net/README, the problem, as withMAINTAINERS, is that is way outdated, listing Alan, for example, as the maintainer for net/core...Well, if the
MAINTAINERSfile isn't up-to-date (which I know it isn't, see "Remy Card" as ext2 maintainer) then there isn't much that can be done by users/developers to submit patches to the right people at all. I think part of the problem is Linus' hesitance to be authoritarian and add/remove people from theMAINTAINERSlist if they don't specifically ask for the change (and submit a patch to that effect).
Yup, Linus told this in a recent thread (this one?), and Al seems still not interested in having his name there, its his right, but the fact is that he _is_ the one doing maintainance for the VFS, so I don't think that putting his name there would be something bad for him or whatever, but hey, if Linus isn't authoritarian wrt this and Al doesn't want to have his name listed there, what can we do? Ditto for other de-facto maintainers that are not listed there.
And BTW, a janitor did something like: look at maintainers? nothing there? send a message to all the addresses in the source file touched, what did he got? some responses, yes, but _tons_ of bounces...
- Arnaldo