Messages in this thread |  | | Date | Mon, 14 May 2001 15:27:28 -0400 | From | Jeff Garzik <> | Subject | Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified |
| |
kuznet@ms2.inr.ac.ru wrote: > > Hello! > > > Note that using dev->name during probe was always incorrect. Think > > about the error case: > ... > > So, using interface name in this manner was always buggy because it > > conveys no useful information to the user. > > I used to think about cases of success. 8) > In any case the question follows: do we have some another generic > unique human-readable identifier? Only if device is PCI?
Each bus should come up with its own way to uniquely identify devices... such is required for SCSI and EthTool ioctls which request bus information (as a text string) for a given device. PCI is simply the one example I know well... pci_dev->slot_name.
Note, however, I have come to think that "tulip0: ...", "tulip1: ...", etc. is more user-friendly than "00:f0.1: ...".
> Actually, I am puzzled mostly with Andrew's note about "simplicity". > Andrew's patch was evidently much __simpler__ than yours, at least, > it required one liner for each device and surely was not a "2.5 material".
Are you talking about his 140k patch?
I think a key point of my patch is that drivers now follow the method of other kernel drivers: perform all setup necessary, and then register the device in a single operation. After register_foo(dev), all members of 'dev' are assumed to be filled in and ready for use. This is not the case with init_etherdev() normal usage, nor using dev->init()...
Tangent - IMHO having register_netdev call dev->init is ugly and unusual compared to other driver APIs in the kernel. Your register function should not call out to driver functions, it should just register a new, already-set-up device in the subsystem and return.
> > I'm all for removing it... I do not like removing it in a so-called > > "stable" series, though. alloc_etherdev() was enough to solve the race > > and flush out buggy drivers using dev->name during probe. Notice I did > > not remove init_etherdev and fix it properly -- IMHO that is 2.5 > > material. > > Nope, guy. Fixing fatal bug is always material of released kernel.
So you say a fatal bug remains in 2.4.5-pre1? If so please elaborate...
> In any case the question remains: what is the sense of dev_probe_lock now?
I dunno. Andrew? I just looked at all users and it looks like it can be removed.
Jeff
-- Jeff Garzik | Game called on account of naked chick Building 1024 | MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |