Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jun 2005 14:25:07 -0600 (MDT)
From:      Warner Losh <imp@bsdimp.com>
To:        brooks@one-eyed-alien.net
Cc:        vova@fbsd.ru, dmp@bitfreak.org, matt@gsicomp.on.ca, freebsd-current@freebsd.org
Subject:   Re: HEADSUP: OpenBSD dhclient incoming
Message-ID:  <20050616.142507.85367515.imp@bsdimp.com>
In-Reply-To: <20050616164747.GB21733@odin.ac.hmc.edu>
References:  <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> <20050616164747.GB21733@odin.ac.hmc.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
From: Brooks Davis <brooks@one-eyed-alien.net>
Subject: Re: HEADSUP: OpenBSD dhclient incoming
Date: Thu, 16 Jun 2005 09:47:47 -0700

> On Wed, Jun 15, 2005 at 05:38:10PM -0700, Darren Pilgrim wrote:
> > From: Brooks Davis
> > > There are two issues here.  First, if we're going to keep
> > > network_interfaces around, /etc/rc.d/dhclient should honor
> > > it and not start dhclient on interfaces not in either
> > > network_interfaces or removable interfaces.
> > 
> > I think network_interfaces should be gotten rid of entirely for two
> > reasons:
> > 
> > 1: It creates a synchronization issue between it and the ifconfig_*
> > lines and duplicates functionality.  IIRC, rc.conf being out of sync in
> > this way has tripped up users in the past.
> > 
> > 2: There are real configurations in which some interfaces are not
> > available when netif is run at boot.  One example is the many newer
> > mini-PCI wireless NICs that require a firmware upload.  Devd is the
> > accepted tool for performing such tasks, but rcordering puts devd after
> > NETWORKING.  The actions taken by devd must therefore include steps
> > taken by netif.  Calling the rc.d scripts directly from devd avoids
> > local scripts that duplicate rc.d functionality.  A similar situation
> > occurs for removable interfaces.
> 
> I'm seriously considering removing the following variables:
> 
> network_interfaces
> removable_interfaces
> pccard_ether

pccard_ifconfig you mean?

> If I do that I'll probably add a pair of new start/stop targets to
> /etc/rc.d/netif to replicate the remaining functions of pccard_ether
> and nuke /etc/pccard_ether.

I invented pccard_ifconfig to be done whenever a new device appeared
on the system.  I test about 20 different drivers these days, and
having that many different ifconfig_foo= lines was burdonsome.  I'd
love to see the fallback functionality that this provided retained
somehow.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050616.142507.85367515.imp>