From owner-freebsd-hackers Wed Feb 5 13:20:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA12733 for hackers-outgoing; Wed, 5 Feb 1997 13:20:29 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA12704; Wed, 5 Feb 1997 13:20:12 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-37.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA11639 (5.67b/IDA-1.5); Wed, 5 Feb 1997 22:19:38 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id VAA06016; Wed, 5 Feb 1997 21:52:45 +0100 (CET) Message-Id: <19970205215125.EX35606@x14.mi.uni-koeln.de> Date: Wed, 5 Feb 1997 21:51:25 +0100 From: se@freebsd.org (Stefan Esser) To: Andrew.Gordon@net-tel.co.uk Cc: se@freebsd.org, hackers@freebsd.org Subject: Re: PCI LKM: How to find object file from PCI ID ... References: <19970131213621.EQ13588@x14.mi.uni-koeln.de> <"271-970131231413-CE37*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> X-Mailer: Mutt 0.60-PL0 Mime-Version: 1.0 In-Reply-To: <"271-970131231413-CE37*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS>; from Andrew.Gordon@net-tel.co.uk on Jan 31, 1997 23:14:22 +0000 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 31, Andrew.Gordon@net-tel.co.uk wrote: > Note that CardBus is essentially PCI squeezed into a PCMCIA card shape, > so this stuff will also affect pccardd in due course. > > As people have been posting in the past few days about re-writing pccardd > and its config file format, perhaps this aspect needs considering > sooner rather than later? My amount of spare time is (still) rather limited, but I actually do agree, that all bus types that can be probed by directly asking a device for its ID (as is true for at least EISA, PCI and USB, but AFAIK also for PCMCIA in all its incarnations) should be dealt with by the same generic probe/attach loop. Bus types that support hot-pluggable devices will need special support, but that should not hurt for the other buses ... My current concept for a revised PCI bus driver has a loop over all possible device "positions" (with some short-cuts to reduce the name space :) and builds a linear list of devices found. After this list has been built, it can be handed over to the user_config code, and after leaving that, the attach will just try to initialize the driver that has already been identified to apply to the device in the probe() loop. At any later time (either because of an external event, or periodically polled) the bus can be re-scanned for new or removed devices. (This is not required for the PCI bus, which does not even try to support insertion or removeal of cards in operation). After new devices have been found with no driver attached, some user-land program should be notified, which will then obtain a list of devices with no driver, and will try to load an LKM for each one that might need it. An automatic driver shutdown on device removal is much harder to implement than the driver loading, but it is not too har dto support from the point of view of a generic bus driver. The hard part is left for the device driver's shutdown() procedure ... Regards, STefan