2001-12-27 20:38:55

by Steven Walter

[permalink] [raw]
Subject: [RFC][PATCH] 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
--
-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;


2001-12-27 22:24:00

by Arnaldo Carvalho de Melo

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

Em Thu, Dec 27, 2001 at 02:38:12PM -0600, Steven Walter escreveu:
> 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.

Good job! But please consider splitting the patch per driver and sending it
to the respective maintainers.

- Arnaldo

2001-12-27 22:44:31

by Dave Jones

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Thu, 27 Dec 2001, Arnaldo Carvalho de Melo wrote:

> > 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.

--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs

2001-12-27 22:51:42

by Arnaldo Carvalho de Melo

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

Em Thu, Dec 27, 2001 at 11:44:12PM +0100, Dave Jones escreveu:
> On Thu, 27 Dec 2001, Arnaldo Carvalho de Melo wrote:
>
> > > 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

2001-12-27 23:25:27

by James A Sutherland

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Thursday 27 December 2001 10:44 pm, Dave Jones wrote:
> On Thu, 27 Dec 2001, Arnaldo Carvalho de Melo wrote:
> > > 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 :)

> 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"?)

> 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.

2001-12-27 23:32:28

by Andreas Dilger

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Dec 27, 2001 23:44 +0100, Dave Jones wrote:
> 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.

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/

2001-12-27 23:40:38

by Arnaldo Carvalho de Melo

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

Em Thu, Dec 27, 2001 at 04:31:30PM -0700, Andreas Dilger escreveu:
> On Dec 27, 2001 23:44 +0100, Dave Jones wrote:
>
> 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)

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

2001-12-27 23:42:10

by Dave Jones

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Thu, 27 Dec 2001, James A Sutherland wrote:

> 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.

> 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.

--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs

2001-12-27 23:52:20

by Dave Jones

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Thu, 27 Dec 2001, Andreas Dilger wrote:

> 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.

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.

--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs

2001-12-28 00:12:34

by Andreas Dilger

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Dec 27, 2001 21:40 -0200, Arnaldo Carvalho de Melo wrote:
> Em Thu, Dec 27, 2001 at 04:31:30PM -0700, Andreas Dilger escreveu:
> > 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)
>
> 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...

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/

2001-12-28 00:15:33

by Andreas Dilger

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Dec 28, 2001 00:51 +0100, Dave Jones wrote:
> On Thu, 27 Dec 2001, Andreas Dilger wrote:
> > 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.
>
> 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/

2001-12-28 00:25:35

by Arnaldo Carvalho de Melo

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

Em Thu, Dec 27, 2001 at 05:11:30PM -0700, Andreas Dilger escreveu:
> On Dec 27, 2001 21:40 -0200, Arnaldo Carvalho de Melo wrote:
> > 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...
>
> 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).

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

2001-12-28 00:33:54

by Alan

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

> 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

2001-12-28 09:49:57

by James A Sutherland

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Thursday 27 December 2001 11:40 pm, Dave Jones wrote:
> On Thu, 27 Dec 2001, James A Sutherland wrote:
> > 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.)

> > 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 <...>

> $ 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.

And tracking of filename<->module relationships, allowing you to look up who
would be interested in a given patch.

> 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.

2001-12-28 11:15:02

by Dave Jones

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Fri, 28 Dec 2001, James A Sutherland wrote:

> 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.

--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs

2001-12-28 18:35:46

by Riley Williams

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

Hi Andreas.

>> 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.

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.

2001-12-28 18:39:56

by Alan

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

> 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

2001-12-28 19:39:31

by Rik van Riel

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Fri, 28 Dec 2001, Alan Cox wrote:

> > 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
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/

http://www.surriel.com/ http://distro.conectiva.com/

2001-12-28 20:36:10

by Andreas Dilger

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Dec 28, 2001 18:34 +0000, Riley Williams wrote:
> 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===
> 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.

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/

2001-12-28 20:48:30

by James A Sutherland

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Friday 28 December 2001 6:48 pm, Alan Cox wrote:
> > 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.

2001-12-28 21:23:57

by Riley Williams

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

Hi Andreas.

>> 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===
>> 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.

> I'd rather just skip the WATCH part entirely (or limit it to people
> already in the MAINTAINERS list).

That's a policy decision for the maintainers to make.

> 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 ???

> 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.

2001-12-28 23:17:58

by Alan

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

> 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 ;)

2001-12-29 18:21:58

by Oliver Xymoron

[permalink] [raw]
Subject: Re: [RFC][PATCH] unchecked request_region's in drivers/net

On Thu, 27 Dec 2001, Dave Jones wrote:

> On Thu, 27 Dec 2001, Arnaldo Carvalho de Melo wrote:
>
> > > 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.

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.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."